The openEHR health record server, written in Rust, with every conformance claim measured.

Documentation · Live sandbox · Quick start · Commercial licence

Project

Quality and security

openEHR conformance
<sub>Against the released openEHR specifications

Against the development openEHR specifications (master)</sub>

Compliance

What FerroEHR does

FerroEHR stores patient health records. It keeps them in openEHR, an open standard that describes clinical information (a blood pressure, a diagnosis, a discharge letter) independently of any one software product. Every change is kept as a new version, so the full history of a record stays readable and nothing is ever overwritten.

Applications such as an electronic patient record, a nursing app or a research dashboard all read and write through one standard interface. The data does not belong to the application that wrote it: you can replace an application, or add a new one, and the records stay where they are. That ends the usual lock-in, where moving to a new system means a migration project and a loss of history.

Who it is for

• Hospitals and care providers that want to own their clinical data and choose their applications freely.
• Software vendors and integrators that build clinical applications and need a standard back end to store and query records.
• Research groups that need structured, queryable clinical data.

Why you can trust what it claims

Every release is signed and comes with a software bill of materials (the list of every component inside) and SLSA build provenance, so you can check that what you install is what was built here. The source is public, and every feature is in this repository: there is no paid edition with extra functions. The conformance reports link each run, with the openEHR specification as the reference, so you can check a result against the standard yourself.

Part of FerroHEALTH

FerroEHR is one of five FerroHEALTH servers. Each does one job and reaches the others only over published standards: FerroEHR stores the record, FerroBRIDGE translates it to FHIR and the OMOP research model, FerroFED connects records across organisations and borders, FerroPIX matches patient identities, and FerroTERM serves the code systems (the shared lists of medical terms). You can run FerroEHR alone or beside products from other vendors. Sign-in, the audit trail and the web consoles come from three shared libraries: FerroAUTH, FerroAUDIT and FerroUI.

Quick start

Try it without installing anything in the live sandbox (ferroehr / ferroehr, demo data, reset nightly). To run it yourself you need Docker Compose 2.23.1 or newer:

curl -LO https://github.com/FerroHEALTH/FerroEHR/releases/latest/download/docker-compose.yml
docker compose up

Then create an EHR and query it with AQL (development credentials ferroehr / ferroehr):

curl -u ferroehr:ferroehr -X POST -i http://localhost:8080/ferroehr/rest/openehr/v1/ehr

curl -u ferroehr:ferroehr -H 'Content-Type: application/json' \
  -d '{"q":"SELECT e/ehr_id/value FROM EHR e"}' \
  http://localhost:8080/ferroehr/rest/openehr/v1/query/aql

The API documentation is at http://localhost:8080/ferroehr/rest/swagger-ui (same credentials), and docker compose --profile viewer up adds the viewer on http://localhost:3000.

The quickstart asks FerroPIX, an IHE patient identity source, for the pseudonym an EHR_STATUS subject carries. To keep the subject-to-EHR cross-reference in FerroEHR instead, so a subject is named by its own namespace and identifier and GET /ehr?subject_id=&subject_namespace= finds it, start with one variable:

FERROEHR_EHR_INDEX=local docker compose up

These defaults are for evaluation only. The getting started guide continues from here, and Kubernetes & Helm covers production.

What ships today

Clinical records

• openEHR REST API (ITS-REST 1.1.0) for EHRs, compositions, folders and contributions, in JSON and XML
• AQL queries, the openEHR query language, with stored queries and cohort queries
• Templates and validation for ADL 1.4 and ADL 2.4, checked on every write
• Full version history: every commit kept, point-in-time reads, logical delete
• Version signing with digest or PGP signatures
• Demographics, a versioned store of persons, organisations and their relationships
• EHR Extract, export and import of whole records between systems
• A choice of specification generation: the released openEHR versions or the development ones

Integration

• Terminology through any FHIR terminology server, such as FerroTERM
• Change events for every commit over a cursor feed, without patient data; delivery to an AMQP broker moves to FerroBRIDGE, where it is in progress
• Multimedia storage in any S3-compatible store, with integrity checks
• The FerroEHR Viewer, a web interface over the same public API
• The openehr-* Rust crates, the openEHR specifications as libraries (listed below)

Security and privacy

• Sign-in with Basic or OpenID Connect (Keycloak, Active Directory), with SMART scopes
• Access control by role and by attribute-based policy
• Pseudonymisation: clinical data and identities kept apart in the database
• Audit trail of every access and refusal, in the IHE ATNA format
• One instance per organisation, each with its own database

Operations

• Docker Compose and a Helm chart, with multi-arch images (amd64, arm64)
• Observability: Prometheus metrics, OpenTelemetry traces, health probes
• Backup and point-in-time recovery on PostgreSQL
• Measured conformance and performance
• Verifiable releases: signed, with provenance and a software bill of materials

Published crates (9)

Crate	What it does	Version	Docs	Downloads
openehr-rm	The Reference Model: compositions, EHR status, entries, data structures and data types
openehr-base	BASE: the foundation and base types, such as identifiers and intervals
openehr-am	The Archetype Model in both generations, AOM 1.4 and AOM 2.4
openehr-adl	The ADL engine: parser, AOM2 validity rules, flattener, OPT2 generator and ADL 1.4 to 2 conversion
openehr-its	Canonical JSON and XML codecs, the ITS-REST contract, and the OPT 1.4 and AOM2 XML codecs
openehr-sdt	The Simplified Formats (WebTemplate, FLAT, STRUCTURED), instance validation and the SMART scope grammar
openehr-query	The AQL 1.1 lexer, parser and syntax tree
openehr-term	The terminology model and the bundled openEHR terminology
openehr-lang	The BMM object model and the ODIN reader

Learn more

• Documentation and the FerroHEALTH book
• Why FerroEHR exists
• Compliance overview: EHDS, CRA and data protection
• Changelog and milestones
• Security policy and threat model
• Contributing, code of conduct, support, governance, maintainers and the AI statement

Licence

Business Source License 1.1 (LICENSE), with Apache License 2.0 as the Change License four years after each version; the licensing page says when you need a commercial licence from Cadasto B.V.