An open source, FHIR native Electronic Health Record
Zantrix is a modern, transparent alternative to closed EHR platforms. It is built around international healthcare standards, an immutable audit trail, and a modular architecture, so that a small clinic and a large hospital can run the same core.
Milestones 0 and 1 are feature complete at beta quality. The repository now provides a one-command local stack, a secured FHIR R4 facade, patient and outpatient encounter workflows, scheduling, problems, allergies, medications, orders and results, clinical notes, vitals, task worklists, consent, emergency access review, terminology integration, administration, and a usable clinical workspace. These paths are audited and covered by unit, architecture, real-infrastructure integration, and browser tests.
Zantrix is not yet production ready, medically certified, or certified against NEN 7510, ISO 27001, or a national EHR program. A production deployment still needs jurisdiction-specific profiles and policy, infrastructure hardening, operational validation, and licensed terminology content. See the roadmap for the exact boundary, and production readiness for the complete list of what is missing before real clinical use.
The roadmap is the source of truth for what is built and what comes next.
If you are looking for the design of the system, start with the documentation.
Zantrix is delivered as source code. It is not a certified medical device and it is not placed on any market as one.
The project supplies software. It does not supply a CE marking, an MDR or FDA conformity assessment, a NEN 7510 or ISO 27001 certificate, a clinical safety case, or an approval under any national EHR programme. No such certification is planned, and the maintainers do not obtain one on a deployment's behalf.
An organization that deploys Zantrix to deliver care takes on the obligations that come with that. Depending on the jurisdiction, that includes at least:
- Determining whether the deployed system is regulated software in that jurisdiction, and completing whatever classification and conformity assessment follows. In the European Union, a health institution that manufactures and uses software within its own organization may fall under the in-house exemption of the Medical Device Regulation, which carries its own conditions. Whether that applies is the deploying organization's assessment to make.
- Clinical risk management, clinical safety governance, and validation of the system for its intended use.
- Information security certification, data protection obligations, and a lawful basis for processing.
- Terminology licensing, jurisdictional profiles, infrastructure hardening, and operational controls.
This is a description of the project's position, not legal advice. Any organization intending to use Zantrix in real care should obtain its own regulatory and legal assessment.
The AGPLv3 licence text governs warranty and liability, and it disclaims both. See LICENSE.
Electronic Health Records are typically locked behind proprietary vendors, with closed data models and hard vendor lock in. Zantrix takes the opposite position:
- Open source and transparent. Control stays with the care provider, under the AGPLv3 license.
- Standards first. HL7 FHIR R4 is the canonical data model and the backend exposes a secured FHIR R4 facade. Snowstorm provides FHIR terminology operations over deployment-supplied SNOMED CT content. There are no private clinical storage formats.
- International first. The core is region neutral. Country specific concerns, such as the Dutch BSN, national exchange networks, and reimbursement rules, live in optional adapter packs that are disabled by default.
- Modular. Capabilities can be turned on or off, so the same platform fits an independent treatment centre or an academic hospital.
- Task driven. The interface is designed to reduce the registration burden on clinical staff and to run like a real clinical application, not a marketing website.
Zantrix is a modular monolith: one deployable application with strictly separated internal domains, ready to split into services later if a domain needs it.
| Layer | Technology |
|---|---|
| FHIR platform | HAPI FHIR R4 JPA server as the canonical resource store and REST API |
| Backend | Java 21, Spring Boot 3, Spring Modulith |
| Frontend | React 19, TypeScript 6, Vite 8, Tailwind CSS 4, i18next, PWA |
| Database | PostgreSQL 16 |
| Identity | Keycloak, OAuth2 and OpenID Connect, SMART scope enforcement in the backend |
| Terminology | Snowstorm 10.11 backed by Elasticsearch 8.11; licensed SNOMED CT RF2 is operator supplied |
| Interoperability (planned) | HL7 v2 and FHIR bridges via Apache Camel |
For the reasoning behind these choices, see the architecture decision records.
Zantrix targets NEN 7510 and ISO 27001 as design goals. These are goals, not certifications.
- Implemented: stateless JWT authentication, Keycloak realm-role mapping, SMART resource-scope checks, patient-context checks, FHIR Consent enforcement, justified emergency access with review tasks, tamper-evident audit search and integrity reporting, FHIR AuditEvent export, security headers, and a durable FHIR mutation journal with reconciliation.
- Deployment work: production MFA and session policy, TLS and secret management, encryption and backup policy, rate limiting, organization/relationship policy, jurisdiction-specific privacy rules, and independent security assessment.
See security and privacy for the full model.
Requirements: Docker and Docker Compose, a Java 21 JDK, and a Node.js version supported by Vite 8 (^20.19.0 or >=22.12.0). CI uses Java 21 and Node 20.
# 1. Build and start the full local stack
docker compose up --build -d
# Or run the backend and frontend outside Compose while developing:
# backend: Spring Boot API on port 8080
cd backend
./mvnw spring-boot:run # Windows: .\mvnw.cmd spring-boot:run
# 3. Start the frontend (Vite dev server)
cd frontend
npm ci
npm run devKeycloak imports synthetic test users from realm-export.json on first start. Snowstorm starts without terminology content: import an edition your organization is licensed to use before entering SNOMED-coded clinical data. See development for setup, terminology loading, test accounts, and verification commands.
Contributions are welcome. Please read CONTRIBUTING.md and CODE_OF_CONDUCT.md first. Security issues should follow SECURITY.md.
Licensed under the GNU Affero General Public License v3.0 (AGPLv3). Improvements to the codebase must be shared back with the community. See LICENSE.