openEHR vs FHIR: storage model vs exchange standard, and when to use both

Direct answer

openEHR specifies how to store and query a lifelong clinical record: a stable Reference Model, clinical content defined in archetypes and templates, and a query language (AQL) over that data. FHIR specifies how systems exchange data: resources, profiles and a REST API. They overlap less than the "vs" suggests. A common European pattern keeps the persistent record in an openEHR clinical data repository (CDR) and exposes FHIR at the edges for apps, partners and EHDS exchange.

What openEHR specifies

openEHR is built on two-level modelling. Software and clinical content are separated on purpose.

Level 1: the Reference Model (RM). A small set of generic classes that rarely changes: EHR, COMPOSITION, OBSERVATION, EVALUATION, INSTRUCTION, ACTION, ELEMENT, and data types such as DV_QUANTITY and DV_CODED_TEXT. A CDR, its persistence layer and its APIs are written against the Reference Model only. The RM also carries versioning: every committed change is a new version inside a contribution with audit details (who, when, why).

Level 2: archetypes and templates. An archetype is a reusable constraint on the RM for one clinical concept: blood pressure, a problem/diagnosis, a medication order. Archetypes are designed to be maximal, covering everything any clinician might reasonably record about that concept. A template combines and narrows archetypes for one use case, such as an emergency triage form or a discharge summary.

Both are written in ADL (Archetype Definition Language). In practice:

• ADL 1.4 is still what most CDRs and modelling tools exchange today.
• ADL 2 is the current specification (ADL2, AM Release 2.3.0, marked stable). Support across products is uneven, so check before you commit to it.
• Operational Template (OPT). The compiled, flattened template a CDR loads. It is the runtime schema. You upload an ADL 1.4 OPT as XML with POST /definition/template/adl1.4.

The practical consequence: when a hospital needs a new form, the team loads a new template. Nobody migrates a database schema.

Clinical Knowledge Manager

Archetypes are reviewed by clinicians and published in the international Clinical Knowledge Manager (CKM). Several countries run their own CKM instance for national content; Norway's is at arketyper.no. This is the governance layer that FHIR has no direct equivalent for: content review is done by clinical modellers, separately from the people who write the API spec.

AQL: querying by archetype path

The Archetype Query Language (AQL) queries across compositions and across EHRs using archetype paths, regardless of which application or template recorded the data. The current spec is AQL in QUERY Release 1.1.0, which added LIMIT and OFFSET. A synthetic example that pulls raised blood pressure readings for one EHR:

SELECT
  c/context/start_time/value AS recorded_at,
  o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude AS systolic,
  o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude AS diastolic
FROM EHR e
  CONTAINS COMPOSITION c
    CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v2]
WHERE e/ehr_id/value = $ehr_id
  AND o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude >= 140
ORDER BY c/context/start_time/value DESC
LIMIT 10

The at0004 and at0005 codes are node IDs inside the blood pressure archetype (systolic and diastolic). The same query returns readings captured by a ward chart, a GP template or a home-monitoring app, as long as each used that archetype. Drop the WHERE e/ehr_id/value clause and it runs as a population query, which is why research platforms like openEHR.

The openEHR REST API

The REST spec (ITS-REST) defines the HTTP surface a CDR exposes. ITS-REST Release 1.1.0 was published in July 2026, the first minor release since 1.0.3 in 2022. It reworks the simplified (FLAT and structured) formats and adds a Demographic API, an Admin API and a "SMART on openEHR" app launch, the last three at development maturity. The calls most integrations use:

What FHIR specifies

FHIR defines resources (Patient, Observation, Condition, MedicationRequest, Encounter and many more), a REST API, plus messaging and document paradigms. Resources follow an 80/20 design: the core covers what most systems already store, and anything else goes in extensions. Profiles constrain resources for a context and are published in implementation guides such as HL7 Europe Base and Core or US Core.

Most production work still pins FHIR R4 (4.0.1). R6 was in normative ballot during 2026 and is not the version to build national exchange on today. If you need the end-to-end view of resources, search and SMART, start with the HL7 FHIR integration guide.

The design difference matters: a FHIR resource is a minimal exchange shape plus extensions, and an openEHR archetype is a maximal clinical model narrowed by templates. Mapping between them is lossy in both directions unless someone decides, field by field, what each side means.

Key differences

On the CDR side, EHRbase is the best-known open-source option (Apache 2.0), alongside commercial platforms. On the FHIR side, compare server options in FHIR servers compared.

Where both run together in Europe

Examples with public sources:

• Norway. The Norwegian Directorate of Health notes that DIPS Arena, the hospital EHR in the South-Eastern region, uses vendor-independent information models based on openEHR archetypes.
• Slovenia. The national Centralised Registry of Patient Data stores data in openEHR on the Better platform, with more than 250 million clinical records after ten years according to Better.
• Catalonia. The regional health service runs a population-scale openEHR CDR, described in vitagroup's Catalonia whitepaper.
• United Kingdom. OneLondon's Universal Care Plan runs on an openEHR platform with a persistent data layer separated from applications (Better case study).
• Germany. University hospitals in the HiGHmed consortium built openEHR-based data integration centres for research. The open-source FHIR Bridge, a broker between FHIR clients and an openEHR server, came out of the German university medicine research network.

Several of these sources are vendor publications. Treat the figures as vendor-reported.

Combination patterns

1. openEHR CDR as the store, FHIR façade for exchange. Applications write compositions through templates. A façade maps selected archetypes to FHIR profiles on read (and sometimes write). Partners, SMART apps and national services see FHIR. Clinicians and analysts keep AQL.

2. Mapping engines instead of hand-written code. FHIRconnect is a YAML-based mapping language for bidirectional openEHR–FHIR mappings. Better started it, stopped maintaining its original repository in 2024, and the community spec now lives in the FHIRconnect-spec repository. The authors' 2025 paper reports mapping 24 international archetypes to 15 FHIR profiles. openFHIR, first announced by Medblocks in 2025, is an Apache 2.0 engine that executes FHIRconnect mappings without storing clinical data itself. Its README says the open-source edition is not intended for production (no authentication or terminology server integration). Version-pin the mapping files like code.

3. FHIR server as the store, openEHR not used. Valid when the product is an app or exchange hub with a narrow data scope. You give up AQL and archetype governance, and you will add extensions as scope grows.

EHDS relevance

Under EHDS, the European electronic health record exchange format (EEHRxF) governs exchange, not storage. The Commission must adopt the implementing acts with its technical specifications by 26 March 2027, and they are widely expected to build on HL7 Europe's FHIR implementation guides. Until the acts are adopted, treat that as direction, not law. An openEHR-based EHR system will therefore need a FHIR export path for patient summaries, ePrescriptions, lab results, imaging reports and discharge reports. See FHIR EU Core and EHDS for the IGs and the EHDS guide for dates and obligations.

Decision guidance

Common failures in practice:

• Mapping late. Teams build the CDR, then discover that a FHIR profile needs a code system or cardinality their template never captured. Map the priority FHIR profiles while designing templates.
• Local archetypes everywhere. Forking CKM archetypes for convenience destroys the cross-system AQL benefit. Specialise or extend instead.
• Two sources of truth. If a FHIR façade also accepts writes, define which side is authoritative and how conflicts are versioned.
• Ignoring terminology. Both sides need SNOMED CT, LOINC and ICD bindings; neither format fixes local codes. The interoperability primer covers the terminology layer.

If you are deciding between a FHIR-native store and an openEHR CDR, or designing the mapping layer between them, that is the kind of architecture work covered under digital health interoperability.