openEHR vs FHIR: What Each Standard Does, How They Work Together, and Where OMOP Fits

openEHR vs FHIR is not a choice between two versions of the same thing. HL7 FHIR is a standard for exchanging health data between systems through APIs; openEHR is a standard for modelling and storing the clinical record itself so it stays meaningful and queryable for decades. Use FHIR for exchange, use openEHR for the longitudinal record, and expect that many large programmes end up running both, with a mapping layer between them. If your product must meet US certification or CMS API rules, FHIR is mandatory and openEHR is optional. If you are building a national or regional clinical record in Europe, openEHR is often the persistence layer and FHIR the door in and out.

This guide is written for architects, CTOs and health IT leads who have to make that decision with real constraints. It compares the two standards element by element, shows the same blood pressure reading in both, walks through the mapping options that exist today, and ends with a decision matrix by scenario. It also answers the question that sits next to this one in almost every data programme: FHIR vs OMOP. (Some people search for it as "open EHR vs FHIR"; the standard's name is written openEHR.)

If you are planning an implementation rather than reading around it, our openEHR integration services team works on both sides of this boundary.

openEHR vs FHIR: the short answer

FHIR vs openEHR comes down to purpose: FHIR defines how data moves, openEHR defines how the record is built. They sit at different layers of an architecture, the way an HTTP API and a database schema do, which is why "which one wins" is the wrong question and "which layer needs which" is the right one.

• Choose FHIR when you need to exchange data with EHRs, payers, apps or national networks, when regulation names it (US ONC certification, CMS APIs, the European exchange format), or when your data already lives in a commercial EHR you do not control.
• Choose openEHR when you own the clinical data layer, need a vendor-neutral record that clinicians can model and evolve without database migrations, and need precise clinical queries across years of data.
• Choose both when you are building a platform that must be the system of record and also speak to the outside world. It is also the direction the HL7 and openEHR communities are now working on together.
• Add OMOP when the goal is research and population analytics rather than care delivery. OMOP is an analytics model, not an exchange or record standard.

Free to share: you can use this cheat sheet in presentations or docs with a link to this page.

What is FHIR, and what does "the FHIR standard" actually cover?

HL7 FHIR (Fast Healthcare Interoperability Resources) is an exchange standard: a set of modular resources such as Patient, Observation, Condition and MedicationRequest, plus a RESTful API, search rules and a profiling mechanism that lets each country or use case constrain those resources. The FHIR standard specifies the wire format and the interactions; it deliberately says little about how a server stores data internally.

FHIR R4 (version 4.0.1) is the release most regulation points to, and core resources such as Observation became normative in R4, meaning they are expected to stay backward compatible (HL7 FHIR R4, Observation). Around the core sit implementation guides: US Core in the United States, UK Core in England (UK Core on Simplifier), HL7 Europe Base and Core for the European Health Data Space, and hundreds more. For a deeper introduction to building on it, see our FHIR integration services page.

Three properties matter in the comparison with openEHR:

• Resources are deliberately general. FHIR aims to cover common needs in the base resource and push the rest into profiles and extensions.
• Versioning is per resource. Servers can keep a history of each resource and support version reads (FHIR RESTful API), but how much history is kept depends on the server.
• Regulation pulls it. The US certification criterion for patient and population APIs requires FHIR R4.0.1, US Core, SMART App Launch 2.0.0 and Bulk Data (ONC, 170.315(g)(10)), and the CMS Interoperability and Prior Authorization rule requires payers to run FHIR APIs, most of them from 1 January 2027 (CMS-0057-F fact sheet).

What openEHR is

openEHR is an open specification for building the electronic health record itself: a small, stable reference model, clinical content models called archetypes that clinicians author and review, templates that combine and constrain archetypes for a specific form or use case, and a query language (AQL) that queries data by clinical meaning rather than by table and column. It is maintained by openEHR International and its specifications are published at specifications.openehr.org.

The idea that makes openEHR different is two-level modelling. Engineers build software once against the reference model; clinicians define what "blood pressure" or "medication order" contains in archetypes, reviewed internationally in the Clinical Knowledge Manager (CKM). When clinical requirements change, you publish a new template, not a new database schema. Our guide to what openEHR is covers the basics, and openEHR explained for developers goes deep on compositions, archetypes and templates.

openEHR also has a published REST API specification for clinical data repositories (openEHR REST API), and every change to a record is versioned inside the reference model through versioned objects and contributions (openEHR Common Information Model). The archetype approach is also standardised in ISO 13606 Part 2 (NRCeS on openEHR). For hands-on API work, see our openEHR REST API integration guide.

openEHR vs FHIR side by side

Side by side, openEHR and FHIR differ on almost every axis that matters to an architect, because one was designed for the record and the other for the message. The table below is the comparison we use in architecture reviews.

The same blood pressure reading in FHIR and in openEHR

The fastest way to understand openEHR vs FHIR is to record one systolic and diastolic reading in each. FHIR puts it in an Observation resource coded with LOINC; openEHR puts it in a composition built from the international blood pressure archetype, addressed by archetype paths.

In FHIR: an Observation resource

The FHIR vital signs profile for blood pressure uses LOINC 85354-9 for the panel, 8480-6 for systolic and 8462-4 for diastolic, with UCUM units of mm[Hg] (FHIR R4 blood pressure profile):

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs" }] }],
  "code": { "coding": [{ "system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel" }] },
  "subject": { "reference": "Patient/example" },
  "effectiveDateTime": "2026-09-20T09:30:00Z",
  "component": [
    { "code": { "coding": [{ "system": "http://loinc.org", "code": "8480-6" }] },
      "valueQuantity": { "value": 142, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]" } },
    { "code": { "coding": [{ "system": "http://loinc.org", "code": "8462-4" }] },
      "valueQuantity": { "value": 91, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]" } }
  ]
}

In openEHR: a composition from the blood pressure archetype

The published international archetype openEHR-EHR-OBSERVATION.blood_pressure.v2 defines Systolic as at0004, Diastolic as at0005, the default event as at0006, and the patient's position as a state element at0008 with coded values such as Standing (at1000) and Sitting (at1001) (openEHR CKM mirror). Sent through the REST API in the FLAT format, where keys are derived from the template, the same reading looks like this (openEHR simplified formats):

{
  "vital_signs.v1/blood_pressure/any_event:0/systolic|magnitude": 142,
  "vital_signs.v1/blood_pressure/any_event:0/systolic|unit": "mm[Hg]",
  "vital_signs.v1/blood_pressure/any_event:0/diastolic|magnitude": 91,
  "vital_signs.v1/blood_pressure/any_event:0/diastolic|unit": "mm[Hg]",
  "vital_signs.v1/blood_pressure/any_event:0/position|code": "at1001",
  "vital_signs.v1/blood_pressure/any_event:0/time": "2026-09-20T09:30:00Z"
}

Inside the repository the systolic value lives at the canonical archetype path /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value. That path is identical in every system that uses the international archetype, whatever template or vendor sits on top, which is the core of openEHR's vendor-neutrality argument.

Querying it: AQL vs FHIR search

Querying is where the two standards feel most different. FHIR search lets a client ask one server for resources that match parameters; AQL lets you query the whole record by clinical meaning, including context such as position. To find systolic readings of 140 or above in FHIR, you use the composite search parameter component-code-value-quantity (Observation search parameters):

GET [base]/Observation?patient=Patient/example
    &code=http://loinc.org|85354-9
    &component-code-value-quantity=http://loinc.org|8480-6$ge140|http://unitsofmeasure.org|mm[Hg]
    &date=ge2026-01-01

The equivalent in AQL, following the pattern in the AQL specification (AQL, Release 1.1.0), can also filter on position, because position is part of the archetype:

SELECT
  o/data[at0001]/events[at0006]/time/value AS measured_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
  AND o/data[at0001]/events[at0006]/state[at0007]/items[at0008]/value/defining_code/code_string = 'at1000'
ORDER BY measured_at DESC

The FHIR query is simpler to write and works against any certified EHR. The AQL query is more expressive, runs across every composition in the record, and does not depend on which search parameters a given server chose to implement.

Terminology: LOINC in FHIR, SNOMED CT bindings in the archetype

Terminology is bound differently in each standard, and that difference is where most mapping work lives. FHIR binds elements to ValueSets with one of four strengths: required, extensible, preferred or example (FHIR terminologies). The openEHR blood pressure archetype binds its own nodes to SNOMED CT: systolic to 271649006 and diastolic to 271650006. So a correct FHIR to openEHR mapping has to carry LOINC codes on one side and archetype node identifiers with SNOMED CT bindings on the other, and decide which code travels with the data.

Where each standard struggles

Each standard has a known weak spot, and naming them honestly is what makes the architecture decision easy. FHIR's weak spot is profile sprawl; openEHR's is that it is voluntary in the markets where FHIR is mandatory.

FHIR: profile sprawl

Because base resources are general, almost every real use of FHIR adds profiles, and profiles multiply. A study of almost 3,000 FHIR profiles from 125 implementation guides found that Observation and Extension alone accounted for half of them, and that FHIR's intended 80/20 split between base resources and profiling looks closer to 65/35 in practice (Reducing FHIR "Profiliferation", PubMed). An analysis of more than 1,300 FHIR packages found the same pattern, and that countries with strong central governance, such as Germany and the Netherlands, reuse profiles far more (Firely). The practical consequence: a US Core Patient and a UK Core Patient are both valid FHIR, and still not interchangeable without work.

FHIR: storage is out of scope

FHIR does not tell you how to store a decade of clinical history, how to evolve a model without migrations, or how to query across every resource type at once. Many teams run a FHIR server as their system of record and that works well for portals, app back ends and exchange hubs. It gets harder when the record itself is the product.

openEHR: optional where FHIR is mandatory

No US federal rule requires openEHR, so a US organisation adopts it for architectural reasons, never for compliance. openEHR also asks for something FHIR projects can often skip: clinical modelling governance. Someone has to choose archetypes, design templates and own their evolution, and that needs clinical informatics skills alongside engineering.

openEHR: its API is not what the outside world calls

The openEHR REST API is well specified for talking to a clinical data repository, but EHRs, payer systems, SMART apps and national networks call FHIR. An openEHR system that needs to be part of that ecosystem needs a FHIR layer, which is the subject of the rest of this guide. For running SMART apps against an openEHR back end, see openEHR and SMART on FHIR.

How openEHR and FHIR work together

openEHR and FHIR work together by splitting the architecture into layers: openEHR as the clinical data repository and system of record, FHIR as the exchange and API layer, and a transformation layer that maps between them. The two standards bodies now formally back this direction.

openEHR International and HL7 International held a joint workshop in Amsterdam on 2 and 3 June 2025, identified five strategic areas for collaboration and set up joint groups for each (openEHR press release; HL7 blog). They met again in Dublin on 12 and 13 May 2026 and committed to a permanent international forum, with next steps covering technical alignment, governance and education, policy, tooling, and closer work with SNOMED International (joint statement). Academic work points the same way: a peer-reviewed analysis of openEHR, ISO 13606 and FHIR for health data spaces argues for selecting each standard by the job it does rather than picking one (PMC10784985).

What each layer is responsible for

In the layered design, each layer has one job, and keeping those jobs separate is what keeps the system maintainable.

The gateway is the only thing the outside world sees, so it carries your compliance obligations. The repository is the only place clinical truth lives, so it carries your data governance. The transformation layer between them is where most of the engineering effort goes, which is why it deserves its own tests, owners and release process.

When a FHIR server alone is enough

A FHIR server as the system of record is the right call more often than openEHR advocates admit. It fits patient portals, app back ends, lab result delivery, claims and payer exchange, and any product whose data model is close to US Core. The case for adding openEHR gets strong when you need one or more of these:

• Deep longitudinal queries across many years and many kinds of clinical data, with the clinical context intact.
• One clinical model across jurisdictions, with country-specific FHIR profiles only at the edges.
• Clinician-owned modelling, where forms and data definitions change often and must not require database migrations.
• Research-grade detail that general-purpose FHIR resources do not capture without heavy extension.
• Portability of the record between repository vendors, because the data sits in an open, published model rather than a proprietary schema.

Four architecture patterns are common for running both:

1. FHIR facade over an openEHR CDR. The openEHR repository is the only store; a facade translates FHIR reads and writes into compositions and AQL. Cleanest data ownership, most mapping effort up front.
2. Dual write. The application writes to a FHIR server and to the openEHR repository. Fast to start, but you now own consistency between two stores.
3. Asynchronous bridge through an event bus. One store is primary; changes flow to the other through events. Resilient and scalable, with eventual consistency you must design for.
4. Gateway orchestrator. A gateway routes each request to the store best suited to it and assembles responses. Flexible, and the most moving parts.

Each pattern, with a blood pressure reading traced through it and its production pitfalls, is in 4 architecture patterns for running openEHR and FHIR together.

Mapping between openEHR and FHIR

An openEHR FHIR mapping transforms data between the two models. Mapping between openEHR and FHIR means transforming FHIR resources into openEHR compositions and back, element by element, including terminology. There are four ways to do it today, and the right one depends on whether you need both directions, how many archetypes are in scope, and who will maintain the mappings.

FHIR Mapping Language

The FHIR Mapping Language has a concrete text syntax and an abstract form in the StructureMap resource, with enough detail for automated conversion of instances; maps run from a source structure to a target, and no reverse map is implied (FHIR Mapping Language). It is a good choice when you already run FHIR tooling and only need one direction, for example openEHR to FHIR for an outbound API.

openFHIR, the FHIRconnect engine

FHIRconnect is a YAML-based domain-specific language for bidirectional openEHR and FHIR transformation, published in November 2025 (arXiv 2511.14618). Its authors mapped 24 international archetypes to 15 FHIR profiles across seven clinical domains and reported 65% mapping reuse across projects, because mappings are written against archetype paths that templates do not change. openFHIR is the open-source engine that executes those mappings over a REST API; it supports FHIR STU3, R4, R4B and R5, is licensed Apache 2.0, and its README states that the open-source version is not intended for production use because it lacks authentication, terminology server integration and performance work (openFHIR on GitHub). If you searched for "open FHIR", this openFHIR engine is most likely what you were after.

Bidirectional mapping and document transformation in practice

A bidirectional FHIR openEHR mapping, and any FHIR openEHR document transformation, is only as good as its round trip. The things that break in real projects, in our experience:

• Granularity mismatch. One openEHR composition often becomes several FHIR resources plus a Composition or Bundle, and a FHIR document has to be split back into entries on the way in.
• Context. openEHR keeps state such as position and cuff size inside the archetype; FHIR often needs extensions or a separate Observation to carry the same detail, so plan where each fact lands.
• Terminology. Decide which terminology is authoritative per element, and run a terminology server so codes are translated, not copied.
• Versions on both sides. US Core releases and archetype revisions move independently. Version your mappings from day one.
• Real data. Mappings that pass synthetic tests fail on free text where codes were expected, local code systems and missing elements. Test with realistic, de-identified records early.

For element-level detail across vital signs, labs, medications, problems and documents, use our FHIR to openEHR resource mapping matrix.

Using an integration engine

When legacy HL7 v2 feeds also have to land in the openEHR repository, an integration engine is often the natural place for the transformation. Our Mirth Connect and openEHR integration guide shows HL7 v2 messages converted into FLAT compositions end to end.

Working out which layer needs which standard? We run standards decision workshops for health systems and product teams: your use cases, markets and regulations in, a written target architecture for openEHR, FHIR or both out. Book an openEHR and FHIR architecture review.

Which to use: a decision matrix by scenario

The right answer to openEHR vs FHIR depends on who owns the data layer and which rules apply to you. This matrix covers the scenarios we see most often.

One lesson carries across all of them: if you need both, get the FHIR layer working first. It delivers compliance and ecosystem access immediately, and it gives you a stable contract while the openEHR repository and mappings are built behind it.

Where openEHR and FHIR are used: regulation and adoption by region

Where you operate largely decides the mix. FHIR is required by rule in the United States and is the basis of Europe's exchange format work; openEHR is chosen for national and regional records, mostly in Europe.

• United States. FHIR is mandatory for certified health IT APIs (ONC (g)(10)) and for payer APIs under CMS-0057-F. openEHR is voluntary.
• European Union. The European Health Data Space Regulation (EU) 2025/327 was published on 5 March 2025 and entered into force on 26 March 2025 (EUR-Lex). It requires EHR systems to support the European electronic health record exchange format, with patient summaries and ePrescriptions from 26 March 2029 and images, laboratory results and discharge reports from 26 March 2031 (Taylor Wessing). HL7 Europe has published Base and Core FHIR implementation guides to support it, and the Commission's implementing acts on the format are expected in early 2027 (HL7 News).
• openEHR programmes. Germany's HiGHmed consortium summarises national and regional use: Slovenia's national EHR stores data for 98% of the population in openEHR, Catalonia's health platform uses openEHR, seven Swedish regions use it, and in the UK the One London shared care record programme is listed among NHS users (HiGHmed, openEHR worldwide). Catalonia's platform serves a region of more than 8 million people (vitagroup).
• United Kingdom. FHIR exchange in England is profiled through UK Core (UK Core), alongside openEHR-based shared records.

For choosing a repository in these markets, see our openEHR CDR vendor comparison.

India: ABDM uses FHIR, the national EHR standards reference ISO 13606

In India, health data exchange under the Ayushman Bharat Digital Mission uses FHIR R4 profiles published by NRCeS, the national resource centre for EHR standards (FHIR Implementation Guide for ABDM). The Electronic Health Record Standards for India notified by the Ministry of Health and Family Welfare in 2016 include ISO 13606, and reference the openEHR service model for archetype-based records (EHR Standards for India, NRCeS). In practice, an Indian product needs FHIR to connect to ABDM; openEHR is an architectural choice for the record behind it.

FHIR vs OMOP: what each one is for

FHIR vs OMOP (or OMOP vs FHIR, as it is often searched) is a question of care versus research. FHIR moves data between clinical systems in real time; the OMOP Common Data Model restructures data from many sources into one analytics schema with standardised vocabularies so researchers can run the same study across many databases. You do not choose one instead of the other; you usually feed OMOP from FHIR or openEHR.

OHDSI describes OMOP as an open community data standard designed to standardise the structure and content of observational data for efficient, reliable analysis, and its standardised vocabularies are central to that (OMOP CDM). Converting between FHIR and OMOP now has its own HL7 implementation guide: the Vulcan FHIR to OMOP guide provides logical models of OMOP tables and FHIR Mapping Language maps for the transformation (FHIR to OMOP IG).

FHIR vs openEHR vs OMOP at a glance

A common and sound design is: openEHR as the record, FHIR for exchange, and a scheduled pipeline from either into OMOP for research. The openEHR record keeps clinical context that OMOP discards; OMOP gives researchers a model their tools already understand.

Alternatives to FHIR, and when each fits

The main FHIR alternatives are other standards that solve neighbouring problems: HL7 v2 messaging, C-CDA documents, openEHR for records, OMOP for analytics, X12 for US claims and eligibility, and DICOM for imaging. None of them replaces FHIR for modern API exchange; each is the better fit for its own job. The US Interoperability Standards Advisory lists which standard applies to which exchange need (ONC ISA).

• HL7 v2: still the backbone of in-hospital feeds such as ADT, orders and results. See our HL7 integration services.
• C-CDA: structured clinical documents, still widely exchanged between US EHRs.
• openEHR: the alternative when the problem is the record, not the exchange.
• OMOP CDM: the alternative when the problem is research.
• X12: the HIPAA standard for claims, eligibility and prior authorization transactions in the US (see our X12 EDI integration work).
• DICOM: images and imaging metadata.

Migrating between the two

Moving from a FHIR-only store to an openEHR repository, or from a custom schema to openEHR with a FHIR layer, is a modelling project first and a data project second. The sequence that works:

1. Inventory the concepts, not the tables. List the clinical concepts you actually store and match each to an international archetype in CKM before designing anything local.
2. Design templates per use case. One template per form or document type, constraining the archetypes to what that workflow records.
3. Build the mapping once, test it both ways. Use the mapping approach you chose above and require round-trip tests on realistic records.
4. Keep the FHIR contract stable. External consumers should not notice the storage change; the FHIR layer is your compatibility promise.
5. Migrate history as versions. openEHR can hold the history of each record; decide how much of the old audit trail becomes versions and how much stays archived.

For the database side of this, including schema analysis and cutover, see migrating from a custom EHR schema to openEHR.

Common mistakes when combining openEHR and FHIR

The mistakes below cost teams the most time, and each one is avoidable at the design stage.

1. Treating it as either or. Choosing one standard for a job it was not built for, then rebuilding the other badly inside it.
2. Designing local archetypes first. Reusing international archetypes is what makes mappings reusable and data portable.
3. Letting mappings live in scattered code. Keep them versioned, reviewed and tested as first-class artefacts.
4. Ignoring terminology until the end. Code translation is where round trips break.
5. Skipping governance. Decide early who owns archetype selection, template changes and mapping updates, and give that group clinical and technical members.
6. Building both layers at once. Ship the FHIR layer first, then the repository behind it.
7. Assuming one FHIR profile set fits every market. US Core and UK Core differ; keep the clinical model underneath and vary the profiles at the edge.

Deciding between openEHR, FHIR or both for a real programme? Our healthcare interoperability engineers design the record, the FHIR layer and the mappings between them, and our healthcare product engineering team builds the platform around them. Book an architecture review and we will run a standards decision workshop on your use cases and leave you with a written target architecture.