OpenELIS Global is open enterprise-level laboratory information system software tailored for public health laboratories. OpenELIS is used at a national scale in a variety of settings, from small general hospital labs, all the way up to national reference labs, and all sizes in between.
Thousands of users use OpenELIS daily to make their laboratory jobs easier by automating work plans, importing results from clinical analyzers, and supporting complex workflows like pathology and cytology, reducing turnaround times, and increasing result accuracy for better patient care.
OpenELIS Global meets all relevant ISO and SLIPTA requirements for the accreditation of labs.
OpenELIS adheres to the strictest of security standards to keep your data safe and supports fully featured, standards-based interoperability to make it easy to receive lab orders and send results to other systems
Please vist our website for more information.
You can find more information on how to set up OpenELIS at our docs page
All badges report the status of the latest merge to develop
(event=push), not per-PR runs.
For the current fork/non-fork E2E validation design, artifact contracts, and
checkpoint/status model, see
specs/plans/ci-e2e-architecture-spec.md.
For operational troubleshooting of the E2E wrapper and downstream execution, see
specs/plans/e2e-ci-operator-model.md.
We welcome community contributions to help improve OpenELIS Global!
- Read our Dev Environment Setup Instructions on the project wiki.
- Check out our CONTRIBUTING guide for detailed contribution practices and pull request tips.
- To report a security vulnerability, follow SECURITY.md (private reporting — not public issues).
-
You need to install Docker and Docker compose
-
For development , you need to install Java 21
Download the OpenELIS Global Installer for each Release from the Release Assets
Supported versions, branches, and the versioning policy are described in RELEASES.md.
see full installation instructions for Offline Installation
Use the same launcher from any clone or worktree:
bash scripts/setup-workspace.sh
scripts/dev-stack up
scripts/dev-stack urlThe launcher builds the backend, frontend, Analyzer Bridge and mock from the
checkout and pinned submodules. Its containers, images, ports and data belong to
this worktree. Frontend edits hot reload; re-run up after backend or
dependency changes. Native builds, focused tests, domain setup and
published-image deployment are described in
the development guide.
| Instance | URL | credentials (user : password) |
|---|---|---|
| Legacy UI | <scripts/dev-stack url>/api/OpenELIS-Global/ |
admin: adminADMIN! |
| New React UI | output of scripts/dev-stack url |
admin: adminADMIN! |
Note: If your browser indicates that the website is not secure after accessing any of these links, simply follow these steps:
- Scroll down on the warning page.
- Click on the "Advanced" button.
- Finally, click on "Proceed to https://localhost" to access the development environment.
-
After making UI changes to the frontend directory , run the formatter to properly format the Frontend code
cd frontend npm run format -
After making changes to the backend directory, run the formatter to properly format the Java code
mvn spotless:apply
scripts/run-ci-checks.sh
scripts/run-ci-checks.sh --list-jobs
scripts/run-ci-checks.sh --job frontend-staticThe default runs the complete local code-check package on committed source in
isolated environments. --job is repeatable and includes each selected job's
setup; its result is labeled partial. Run the full command after a push while
GitHub runs. Publishing and GitHub administration remain hosted operations. See
the development guide for job mapping and evidence.
Environmental orders support multi-standard compliance evaluation. When an order is placed with one or more compliance standards selected (e.g. PP No. 22/2021, WHO-DWG-4), the result entry screen shows per-standard PASS/FAIL pills inline with each test result under a Status — Per Regulation column.
How it works:
-
Admin configures compliance standards and their per-test thresholds under Administration → Compliance Standards. Each standard has parameter groups with thresholds (RANGE, MINIMUM, MAXIMUM, etc.) linked to specific tests.
-
When placing an environmental order, select the applicable compliance standards in the Applicable Compliance Standards section. These are stored in the
sample_compliance_standardsjoin table. -
On result entry, the system evaluates each entered value against the
compliance_thresholdrows for that test + standard combination and returnscomplianceStatuses(array of{standardId, standardName, pass}) alongside each result row. -
The result entry screen renders green
PASS — <standard>or redFAIL — <standard>pills. The column is hidden when no compliance standards are attached to the loaded result set.
Key entities:
compliance_standard— the regulatory standard (e.g. PP No. 22/2021)parameter_group— groups thresholds within a standardcompliance_threshold— per-test threshold with type and boundssample_compliance_standards— join table linking a sample to its standards
Non-environmental and non-compliance orders are unaffected; the existing normal/abnormal background-colour logic is unchanged.
This project uses GitHub SpecKit for Spec-Driven Development (SDD). AI coding agents can use slash commands to create specifications, plans, and tasks.
Available Commands:
/speckit.specify- Create feature specification/speckit.plan- Generate implementation plan/speckit.tasks- Generate task breakdown/speckit.implement- Execute implementation/speckit.analyze- Validate consistency
Reference Documentation:
- AGENTS.md - Comprehensive guide for AI coding agents
- Constitution:
.specify/memory/constitution.md- Governance principles - Feature Example:
specs/001-sample-storage/- Complete SDD example
For comprehensive testing guidance, see:
- Testing Roadmap:
.specify/guides/testing-roadmap.md- Complete testing guide for both agents and humans - Test Templates:
.specify/templates/testing/- Standardized test templates - AGENTS.md: Testing Strategy section - Overview of testing approach
- Test Data Strategy:
.specify/guides/test-data-strategy.md- Unified test data management guide
scripts/dev-stack up creates development scenarios through application
services. The local CI runner prepares the workflow's fixtures in fresh,
isolated test databases. Do not run fixture resets against the interactive
development stack. For fixture maintenance and backend integration datasets, see
the test data guide.
Please follow the pull request tips in order to make life easy for the code reviewers by having a well defined and clean pull request.
Please see our Contributor Code of Conduct