openEHR vs FHIR: two paradigms for the electronic health record

1. What openEHR is

openEHR is an open specification suite maintained by openEHR International (formerly the openEHR Foundation, founded in 2003 in the UK and Australia). The goal of openEHR is not to design an exchange format but to define the entire architecture for an electronic health record system that can survive for decades — the philosophy of "write once, use across the patient's lifetime."

openEHR's core idea is to separate software from clinical knowledge. The software only implements a small, stable Reference Model; every clinical concept (blood pressure, respiration, allergy) is described at the archetype layer and can evolve without rebuilding the system. The international clinical community curates these archetypes in the Clinical Knowledge Manager (CKM), a public knowledge repository governed through a peer review process.

The full openEHR specification is published under a Creative Commons license. Common implementations include EhrBase (open source), Better Platform (Marand, Slovenia), and DIPS Arena (Nordic countries).

2. Two-level modeling: Reference Model and Archetype

The most distinctive feature of openEHR is its two-level architecture. The upper level is the Reference Model — a small, stable data model implemented in the software code. The lower level is Archetype and Template — which define clinical concepts, sit entirely outside the code, and can evolve independently.

Software layer  ────  openEHR Reference Model
                       (Composition, Section, Entry, DataValue...)
                       Stable, rarely changes
                       ─────────────────────────────────
                       Continuously evolves
Knowledge layer ────  Archetype + Template
                       (Blood Pressure, Body Temperature, Allergy...)

What this means in practice: when the clinical community needs to add a "blood pressure measurement site" or "patient posture" field, they simply publish a new archetype version. The EHR application reads the new archetype and renders the matching form — no software release required. This is fundamentally different from the way FHIR evolves through standard versions (DSTU2, STU3, R4, R5).

The two-level modeling formalism is not exclusive to openEHR. ISO 13606-2 formally adopted the archetype formalism from openEHR, but ISO 13606-1 itself is a separate standard for EHR communication between systems. In other words, openEHR is not an implementation of ISO 13606 — they are two parallel specification lines that share an architectural heritage.

3. Archetype, Template, and the Clinical Knowledge Manager

An openEHR archetype describes the maximum dataset for a clinical concept. For example, the Blood Pressure archetype on CKM defines more than 30 fields: systolic, diastolic, measurement site (right arm, left arm, thigh), posture (sitting, lying, standing), cuff size, notes about the measuring device, reliability of the value, and the reason if a measurement could not be taken.

A Template assembles multiple archetypes into a specific form for a specific use case. For example, an "Outpatient general examination" template might include the Blood Pressure archetype (with only a few mandatory fields selected), Body Weight, Body Height, Heart Rate, plus a section for clinical examination notes.

The CKM governance process is fairly rigorous: a clinician proposes a new archetype, the community reviews it across multiple rounds, versions follow semantic versioning, and every change is tracked. This is a double-edged strength — it ensures the quality of clinical knowledge, but it is also a high bar for organizations that lack long-term clinical informatics expertise.

4. AQL: a semantic query language

AQL (Archetype Query Language) is openEHR's dedicated query language. It lets you write statements over archetypes rather than over the physical database schema. The AQL syntax resembles SQL, but every path points into a node within an archetype.

SELECT
  obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value AS systolic,
  obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value AS diastolic
FROM EHR e
   CONTAINS COMPOSITION c
      CONTAINS OBSERVATION obs[openEHR-EHR-OBSERVATION.blood_pressure.v2]
WHERE c/context/start_time > '2026-01-01T00:00:00Z'
ORDER BY c/context/start_time DESC

Reusing an AQL statement across data versions depends on stable archetype paths, versioning rules, and the repository's migration strategy; the specification does not create a fixed-duration guarantee. By comparison, FHIR Search defines a REST query mechanism, while FHIRPath is an expression language used in invariants and other computable definitions—not a general REST query API.

5. 10-axis comparison table

Each row summarizes how openEHR and FHIR approach a specific technical dimension. Note: this is a comparison table, not a scorecard — there is no "winner" column.

6. When to choose openEHR

openEHR is an architecture candidate when the core requirement is a longitudinal record, archetype-based clinical-model governance, and AQL querying. Before selecting it, an organization should verify these conditions through a prototype or pilot:

• Clinical governance: named roles and review, versioning, and approval processes exist for archetypes and templates.
• Data requirements: longitudinal queries and model reuse have been demonstrated with representative data, including archetype-version changes.
• Operating capability: the team can govern models, terminology, APIs, migration, and data safety; staffing should be estimated from the pilot.
• Substitutability: export, platform migration, and version compatibility are tested; the “vendor-neutral” label does not by itself eliminate product-level lock-in.

7. When to choose FHIR

FHIR is a candidate when the primary requirement is a testable data-exchange contract between systems. Factors to assess include:

• Integration boundary: partners agree on the FHIR/IG/package release, canonical URLs, terminology, and interactions in the CapabilityStatement.
• Multiple exchange channels: RESTful API, documents, or messages are selected for the workflow; not every use case is assumed to use REST.
• Implementation capability: the team can profile, validate, operate terminology, and govern versions; familiarity with REST and JSON is only a starting point.
• Substitutability: a test suite proves profile-conformant import/export and extension handling; adopting FHIR does not automatically eliminate product lock-in.

FHIR Resources may be persisted, but the specification does not prescribe a database architecture or guarantee that an arbitrary Resource set satisfies every EHR requirement. Suitability should be evaluated using the Implementation Guide, CapabilityStatement, query model, retention requirements, and representative organizational data.

8. The hybrid pattern: openEHR for storage, FHIR for exchange

This is a viable architecture pattern, not a default prescribed by openEHR or FHIR. The official Brazil RNDS documentation establishes FHIR R4 at the interoperability layer; it is not evidence of the storage technology used by every state or hospital. Likewise, a data-sharing programme does not by itself establish that source systems use openEHR.

[Clinician data entry]
       │
       │ Form (openEHR Template)
       ▼
[openEHR EHR Server (semantically rich storage, internal AQL queries)]
       │
       │ AQL → mapping logic
       ▼
[FHIR Façade] ──── REST API ───→ [Mobile app, AI, national portal, BHYT]

An openEHR CDR such as EHRbase can be combined with a FHIR server or adapter. Features and conformance must, however, be verified for the specific product version. The FHIR layer becomes an exchange contract only when its output conforms to the published Profiles, terminology, and CapabilityStatement.

The cost of a hybrid is complexity: two data models, bidirectional mappings, terminology, and explicit handling of information that has no equivalent representation. FHIR does not itself establish legal compliance; authentication, authorization, audit, consent, and retention remain separate implementation controls.

9. Reading international implementation evidence

Snapshot of public sources reviewed through 18 July 2026. Rather than inferring country-level market share, this table separates what a primary source supports from what it does not support.

A standard, affiliate, or vendor listing is not equivalent to country-wide adoption. Any deployment statistic should identify its snapshot date, unit of measure, sample, and primary source.

10. Vietnam: separating the exchange contract from storage architecture

Decision 2146/QĐ-BYT of 15 July 2026 names HL7 FHIR R4 in Vietnam's health-data interoperability path. That supports the exchange layer; it does not require a hospital to use FHIR or openEHR as its internal persistence model. Architecture should therefore separate these questions:

• Exchange contract: APIs and documents must pin the FHIR/IG version, CapabilityStatement, and terminology.
• Internal store: relational, document, FHIR-native, or openEHR persistence should follow query, lifecycle, and governance needs.
• Mapping layer: a dual-model architecture needs versioned mappings, provenance, round-trip tests, and explicit loss-handling rules.
• Operational evidence: staffing, cost, and performance assumptions should come from the organization's own pilot rather than international trend claims.

Technical guidance for a project applying VN Core:

• Use FHIR R4 with the VN Core IG as a trial-use boundary contract when partners agree on the package and CapabilityStatement.
• Evaluate openEHR independently for use cases requiring archetype governance or longitudinal querying; do not decide from the “EHR” label alone.
• Select a hybrid architecture only when the organization accepts two operating models and has demonstrated the mapping with representative fixtures.
• Do not treat this article as a substitute for an architecture dossier, safety assessment, or procurement decision.

11. Frequently asked questions

Can openEHR replace FHIR?

They should not be treated as wholesale substitutes. openEHR focuses on an EHR platform and archetype governance; FHIR focuses on information models and exchange contracts. They may be implemented separately or together depending on the conformance scope; this choice cannot be inferred from country-level adoption because no suitable public measurement is available here.

Is FHIR enough for EHR storage?

FHIR resources can be persisted, but the specification does not prescribe one database architecture or longitudinal-record model. Suitability depends on use case, queries, lifecycle, and governance, and should be tested with a profile suite and representative data.

How do ISO 13606, openEHR, and FHIR differ?

ISO 13606 is the international standard for EHR communication (especially ISO 13606-1). openEHR is an independent open specification and platform, not an implementation of ISO 13606 — both share the two-level modeling formalism, and ISO 13606-2 adopted the archetype formalism from openEHR. FHIR is a different paradigm based on Resources and REST APIs. All three can coexist in a single architecture.

Should Vietnam wait for openEHR to mature before deploying EMR?

Interoperability work should not wait for another technology, but exchange requirements should not be mistaken for a storage mandate. A project can implement a FHIR boundary contract and evaluate openEHR separately, provided the mapping and operating model are tested.

12. References and further reading

Primary sources

• openEHR International — openehr.org
• openEHR Specifications (Reference Model, ITS-REST 1.0.3 published 19/12/2022, ITS-REST 1.1.0 in trial) — specifications.openehr.org
• Clinical Knowledge Manager — ckm.openehr.org
• openEHR Affiliates and tools/products registry — openehr.org/affiliates, openehr.org/tools-and-products
• EhrBase open source openEHR backend — ehrbase.org
• RNDS Brazil (FHIR-based national interoperability) — rnds-guia.saude.gov.br, rnds-fhir.saude.gov.br
• NHS England Connecting Care Records Programme — england.nhs.uk
• ISO 13606-1:2019 — iso.org/standard/67868.html
• HL7 FHIR R4 Search — hl7.org/fhir/R4/search.html
• HL7 FHIR R4 FHIRPath — hl7.org/fhir/R4/fhirpath.html

Vietnamese legal documents

• Circular 13/2025/TT-BYT — Electronic medical records (issued 06/06/2025, effective 21/07/2025)
• Decree 102/2025/NĐ-CP — Health data management (effective 01/07/2025)
• Decree 278/2025/NĐ-CP — Mandatory data connection and sharing (effective 22/10/2025)

Continue reading in the knowledge hub