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

An AQL statement written today can run against data captured 10 years ago using an older archetype version, as long as the archetype paths remain compatible — that is the "future-proof" promise that openEHR markets as its main selling point. Compared with FHIR: FHIR uses FHIR Search for REST queries, while FHIRPath is an expression language used for invariants, slicing, and search parameter definitions — not a general-purpose query API exposed over REST.

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 delivers the most value when an organization commits long-term to clinical knowledge governance and is willing to invest in dedicated staff. A few typical situations:

• Country or regional EHR backbones — like Slovenia (national EHR), several NHS England ICBs, or regions in Brazil. When data must persist for decades and the clinical model needs to evolve without rebuilding the system, openEHR is the right architecture.
• Large hospital systems with clinical informaticians — organizations with at least 2-3 full-time experts dedicated to archetype design, template review, and engagement with the international CKM community.
• Research projects or specialty registries — cancer, diabetes, or rare-disease registries. These use cases need rich semantic descriptions and data that outlives the software lifecycle.
• Sufficient budget and timeline — typically 18-36 months from selecting openEHR to a stable production deployment, given the work required to build a template suite, train the team, and integrate with source systems.

7. When to choose FHIR

FHIR fits the majority of real-world situations in Vietnam and across most of the developing world today. Four signals to prioritize FHIR:

• You need an open API — to connect mobile apps, AI services, the Vietnam Social Security (BHXH) portal, or the personal health record on VNeID (Vietnam's national digital identification app). FHIR REST is the broadly accepted standard for data exchange.
• Greenfield project with a tight deadline — Circular 13/2025/TT-BYT (Ministry of Health) requires non-hospital healthcare facilities to complete EMR adoption by 31/12/2026. A FHIR-first deployment is significantly faster than openEHR.
• Web-standard developer team — backend engineers already know REST + JSON. The FHIR learning curve is much shorter than learning the Reference Model and AQL.
• Avoiding vendor lock-in — FHIR has a diverse tooling ecosystem (HAPI FHIR, Firely, Microsoft FHIR Service). Migrating data between vendors is easier than from a proprietary openEHR data store.

Important: FHIR R4 is fully sufficient for EHR storage at the scale of an average hospital. Although FHIR has no CKM-style clinical knowledge governance mechanism, a well-built Implementation Guide with thoroughly documented Profiles and Extensions can meet most real-world requirements.

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

This is the pattern that several leading countries are pursuing to capture the benefits of both. Brazil — through its national Rede Nacional de Dados em Saúde (RNDS) system — uses FHIR R4 as the national interoperability layer, while many states and hospitals continue to maintain openEHR stores behind it. NHS England deploys openEHR at the level of individual Integrated Care Boards (ICBs) or specific vendors, paired with the Connecting Care Records programme that uses FHIR for cross-facility sharing.

[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]

A common toolset for this pattern combines EhrBase (open source openEHR storage) with a FHIR server or adapter; the commercial Better Platform also ships with a built-in FHIR endpoint. The benefit is semantically rich, governed data internally, while the outside world only sees standard FHIR Resources.

The cost of the hybrid is complexity: you must maintain two data models, build and maintain a mapping layer, and handle terminology differences between archetypes and profiles. The pattern only makes sense when an organization is already committed to openEHR for other reasons (governance, data lifecycle) and needs to expose data externally through FHIR for compliance or connectivity reasons.

9. Adoption around the world

The adoption picture as of early 2026, based on public documentation from national health authorities:

Note: this table reflects publicly documented status; real-world adoption may differ since many projects remain unannounced. Sources for the Brazil and UK rows are in the References section at the end of the article.

10. The Vietnam context: why FHIR is the viable path

As of May 2026, based on OmiGroup's public survey, Vietnam has virtually no openEHR deployments at the hospital or national level. Several structural reasons explain this:

• Lack of clinical informatics expertise — training in archetype design, AQL, and ADL is essentially absent from Vietnamese medical schools and health-IT programs.
• HIS vendors do not yet support openEHR — major Vietnamese vendors (Vietsens, Hop Nhat, FPT.eHospital, OmiGroup) are all investing in FHIR R4. None has announced an openEHR roadmap.
• The legal framework targets interoperability — Circular 13/2025/TT-BYT on electronic medical records, Decree 102/2025/NĐ-CP on health-data management, and Decree 278/2025/NĐ-CP on mandatory data sharing all focus on data exchange and place no specific requirements on storage architecture.
• EMR timelines are very tight — hospitals were required to complete EMR adoption by 30/9/2025 (deadline already passed for that group), and other healthcare facilities by 31/12/2026. There is not enough runway for a meaningful migration to openEHR.

OmiGroup's recommendation for the 2026-2028 horizon:

• Adopt FHIR R4 with the VN Core IG as the official national standard for EMR and data exchange.
• Track openEHR for specialty registries where clinical knowledge governance value is decisive — for example, the national cancer registry, rare-disease tracking, or interventional cardiology registries.
• Consider a hybrid (EhrBase + FHIR façade) for hospital chains with 5+ facilities, where the cost of archetype governance can be amortized across many sites.
• If a research hospital (Bach Mai Hospital, K Hospital, Cho Ray Hospital, or HCMC University Medical Center) wants to pioneer openEHR, prioritize research use cases rather than replacing the production HIS.

11. Frequently asked questions

Can openEHR replace FHIR?

No, because the two standards solve different problems. openEHR is designed for semantically rich EHR storage with archetype governance; FHIR is designed for data exchange via REST APIs. You can use openEHR without FHIR (inside a single hospital) or FHIR without openEHR (the case for most of Vietnam today), but framing this as "replacement" is the wrong question.

Is FHIR enough for EHR storage?

Yes, for most hospitals. FHIR R4 provides 146 Resources with a data model rich enough for the vast majority of clinical use cases. The main limitation is the absence of CKM-style knowledge governance — which must instead be addressed through a strong Implementation Guide review process and a well-built profile suite.

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?

No. The legal framework has already locked in deadlines (Circular 13/2025), and domestic communities and vendors have chosen FHIR. Waiting equals missing compliance. If openEHR is later needed for a specific use case, you can layer openEHR storage underneath without discarding the FHIR investment.

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
• 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