OpenELIS Global 2

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

CI Status

All badges report the status of the latest merge to develop (event=push), not per-PR runs.

CI Architecture

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.

Contributing

We welcome community contributions to help improve OpenELIS Global!

1. Read our Dev Environment Setup Instructions on the project wiki.
2. Check out our CONTRIBUTING guide for detailed contribution practices and pull request tips.
3. To report a security vulnerability, follow SECURITY.md (private reporting — not public issues).

Requirements

1. You need to install Docker and Docker compose

2. For development , you need to install Java 21

For Offline Installation Using the OpenELIS Global2 Installer

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

For running OpenELIS Global2 in Docker with default Settings out of the Box

see OpenELIS-Docker setup

For Running OpenELIS Global2 from Source Code

Use the same launcher from any clone or worktree:

bash scripts/setup-workspace.sh
scripts/dev-stack up
scripts/dev-stack url

Install the development prerequisites, including mkcert, first. On the first start on a machine, up sets up trusted local HTTPS and may request administrator authentication. Later starts reuse that trust. Use the printed localhost URL; no manual certificate generation, browser warning bypass, domain setup or port selection is needed.

The launcher builds the backend WAR from the checkout and runs it, with the frontend source mounted, in the published development images; it does not build container images. Its containers, ports and data belong to this worktree. Frontend edits hot reload; re-run up after backend changes. Run scripts/dev-stack up --build to build the images from the checkout instead, which frontend dependency, Dockerfile, Analyzer Bridge and mock changes need. Native builds, focused tests, domain setup and published-image deployment are described in the development guide.

The Instances can be accessed at

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!

If you see a certificate warning, confirm you are using the URL printed by scripts/dev-stack url and that scripts/dev-stack up completed its trust setup. Restart the browser to refresh its trust settings. If the warning persists, follow the development guide; do not bypass it.

Formating the Source code after making changes

1. After making UI changes to the frontend directory , run the formatter to properly format the Frontend code

   cd frontend
   npm run format
   

2. After making changes to the backend directory, run the formatter to properly format the Java code

   mvn spotless:apply
   

Run the local CI test package

scripts/run-ci-checks.sh
scripts/run-ci-checks.sh --list-jobs
scripts/run-ci-checks.sh --job frontend-static

The 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 & Compliance-Scoped Result Evaluation

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:

1. 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.

2. When placing an environmental order, select the applicable compliance standards in the Applicable Compliance Standards section. These are stored in the sample_compliance_standards join table.

3. On result entry, the system evaluates each entered value against the compliance_threshold rows for that test + standard combination and returns complianceStatuses (array of {standardId, standardName, pass}) alongside each result row.

4. The result entry screen renders green PASS — <standard> or red FAIL — <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 standard
• compliance_threshold — per-test threshold with type and bounds
• sample_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.

AI-Assisted Development (SpecKit)

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

Testing Resources

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

Test Data Setup

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.

Pull request guidelines

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.

code of conduct

Please see our Contributor Code of Conduct