openEHR, FHIR and CDA: differences, complementarities and coexistence

AIHealth

On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.

Discover AIHealth →

Digital Health

Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.

Discover →

Three standards, three purposes

A recurring misunderstanding in the healthcare interoperability debate is treating CDA R2, FHIR and openEHR as alternatives to choose between. In reality they address structurally different purposes: the fact that all three model healthcare data does not make them competing products. They are rather layers of an architecture, each with its natural use and well-defined points of contact. Alongside sits OMOP CDM, orthogonal to the three: an observational data model, neither for exchange nor for clinical persistence, but for aggregate analysis, which we have discussed elsewhere.

Every architectural choice for a healthcare system — whether for a single organisation, a Region or a national programme — plays out on the composition of these layers. Forcing a standard into a role that is not its own — for example using CDA R2 as a transactional API, or FHIR as a legal archive — produces frictions that no technical optimisation resolves.

CDA R2: the document

HL7 CDA R2 (Clinical Document Architecture Release 2, ANSI 2005) answers the question: how do I represent a clinical document so that it is storable, signable, preservable over time and interpretable in the absence of the system that produced it?

Its design principles are those of the document: persistence, stewardship, potential for authentication, wholeness, default context, human readability. A CDA R2 document has an identified author, a custodian organisation, a potential legal signature, a content readable without the originating system thanks to rendering XSLT. It is a self-contained archival unit.

CDA R2’s natural purpose is archival and documentary: discharge letter, laboratory report, patient summary, emergency department record as entities with their own legal identity and lifecycle. In first-generation European Electronic Health Record architectures (including Italy’s) CDA R2 is the format of published documents, shared via IHE XDS.b and XCA.

Its limits are equally well known:

• Complexity inherited from HL7 v3’s RIM, with a steep learning curve
• Single XML serialisation (no JSON variant)
• No native API — exchange is handed over to external frameworks (IHE XDS)
• Entry granularity hard to aggregate for analytics

FHIR: transactional exchange

HL7 FHIR (Fast Healthcare Interoperability Resources, first DSTU 2014, R4 in 2018, R5 in 2023) answers a different question: how do I transactionally and granularly exchange healthcare data between systems using modern web conventions?

Its principles are those of the API: atomic resources with URL identity, composition via references, REST with HTTP verbs, two equivalent serialisations (JSON and XML), extensibility via Extension, conformance-driven design with machine-readable Profile.

FHIR’s natural purpose is applicative: consulting a patient’s clinical state from an app, integrating decision-support services (CDS Hooks), feeding Clinical Data Repositories, exchanging single observations or requests, bulk export for analytics. FHIR excels where granularity and frequent interaction between systems are needed — scenarios in which the CDA document model would be heavy and the XDS archive inappropriate.

FHIR is not designed as a long-term archival format. A FHIR resource does not by its nature have the documentary characteristics of a CDA (sole author, sole signature, stewardship, lifecycle as an act). The document Bundle covers documentary scenarios but still requires an external preservation framework to satisfy archival and statutory preservation requirements.

openEHR: native persistence with clinical governance

openEHR (openEHR Foundation, evolving specifications since 2003, ISO 13606 as equivalent standard) answers yet another question: how do I store clinical data so that the clinical model can evolve over time without breaking databases and applications?

The answer is the two-level model: a stable, generic Reference Model for the technical schema, a clinical level governed by clinicians through archetypes in ADL, with templates composing archetypes for the specific use case. Data are persisted according to the RM and annotated with archetype paths; an AQL query interrogates data independently of the underlying physical database.

openEHR’s natural purpose is the persistence of structured clinical data in contexts where model evolution is a requirement — regional Clinical Data Repositories, next-generation clinical records, longitudinal research platforms. Clinical governance of archetypes through the Clinical Knowledge Manager is a specific asset: the same Blood pressure archetype is used in the United Kingdom, Norway, Germany.

openEHR is not an exchange format in the strict sense: when an openEHR system must communicate with others, it does so through FHIR (with automatic mappings from archetypes to FHIR resources), CDA (document export), or specific protocols (HIP, openEHR REST API). It is a persistence layer that opens outwards through exchange standards.

Synthesis

Real coexistences

In the real world, a mature healthcare platform does not use a single standard: it combines them. Some typical combinations, observable in European implementations in 2025:

CDA R2 + FHIR side by side

This is the current scenario of the Italian FSE 2.0: Italian CDA R2 structured documents and Italian FHIR profiles coexist on the FSE Gateway. The Gateway exposes both interfaces — SOAP/XDS.b for legacy systems, FHIR REST for modern applications — with automatic converters where required. The transition is multi-year: documents born in CDA stay CDA, new ones are born in FHIR, the consumer chooses how to query.

openEHR as CDR + FHIR as API

This is the pattern adopted by some European regional healthcare systems (Slovenia, parts of NHS UK, Italian university projects). The regional Clinical Data Repository stores clinical data natively in openEHR, with archetypes governed through the CKM. External access — from clinical records, patient apps, research systems — passes through a FHIR API that translates on the fly from openEHR data to the FHIR profiles required by the consumer. openEHR is never exposed externally; FHIR is never the persistence format.

FHIR for exchange, OMOP for analytics

This is the pattern of European observational research (EHDEN, DARWIN EU): data acquisition via FHIR API (from production systems or regional EHRs), ETL to OMOP CDM for longitudinal analysis. FHIR carries the data, OMOP makes it analysable in a federated way. They are complementary models, not competing.

openEHR + OMOP for longitudinal research

For research contexts where both governed clinical persistence and an analytical model are needed, some platforms keep openEHR as CDR and OMOP as analytical data mart. openEHR → OMOP mappers are the subject of active research, with pilot projects in Germany and other contexts.

Choice criteria

An organisation designing a new healthcare system faces a series of questions that shape the standard choices:

• What is the main unit of exchange? Documents with legal identity (CDA), clinically granular entities (FHIR), longitudinal observations (openEHR or FHIR)?
• What is the access pattern? Publication/consultation (CDA + XDS), frequent transactional API (FHIR), persistence with longitudinal queries (openEHR)?
• Who governs the clinical model? The IT/vendor team (CDA, FHIR), the international clinical community (openEHR)?
• What is the evolution horizon? Stable model for years (CDA, national FHIR profiles), continuous clinical evolution (openEHR)?
• What is compatibility with national programmes? (in Italy: FHIR IT for FSE 2.0, CDA R2 for legacy documents)
• What is the research interface? OMOP via ETL, FHIR Bulk exposure, openEHR AQL queries?

The answer rarely involves a single standard. More often, the typical 2025 architecture in an advanced context is:

• FHIR as exchange API (with national profiles — FHIR IT in Italy, US Core in the US)
• CDA R2 for archival documents with legal signature and for backward compatibility with first-generation EHRs
• openEHR or FHIR-native databases as persistence layer (architectural choice)
• OMOP CDM as data model for analytics and secondary use (EHDEN, DARWIN EU, EHDS)
• IHE as profile-orchestration framework when data must be carried across different administrative domains

In the EHDS context

The European Health Data Space — Regulation (EU) 2025/327 in force since March 2025 — does not impose a single standard but specifies harmonised reference standards. Indications emerging from preparatory work and the Commission’s first implementing acts:

• FHIR R4/R5 as the main format for cross-border primary use (MyHealth@EU) and for citizens’ access to healthcare data
• IPS FHIR as content of the European patient summary
• FHIR or equivalent exposure expected of EU-certified EHR systems
• OMOP CDM as natural secondary-use format, with support from DARWIN EU and HealthData@EU

CDA R2 does not disappear — historical archives remain — but is no longer the reference format for the European harmonised specifications. openEHR continues to exist as a persistence layer chosen by individual systems, with FHIR compatibility at exposure.

Convergences

A structural trend of the decade is semantic convergence among these standards. The same clinical concepts — blood pressure, blood glucose, allergy, drug in use — have compatible representations in CDA R2, FHIR and openEHR, often with identical LOINC/SNOMED CT codes. The work of HL7 International and the openEHR Foundation on Common Clinical Models goes in this direction: a clinical concept modelled once, with bindings towards FHIR StructureDefinition and openEHR Archetype.

In the limit, the distinction among standards will increasingly concern less semantics and more the architectural layer: producers use what the internal system offers, consumers see a coherent presentation layer, mappers do the translation work. It is a realistic goal for the end of the current decade.

The choice is not permanent

A lesson the history of Italian healthcare systems has taught — from the HL7 v2 to CDA R2 to FHIR transition — is that the choice of standards is not permanent. A system designed today in FHIR IT with CDA as fallback will likely be in FHIR R6 or R7 in ten years, with openEHR or FHIR-native databases as persistence, and OMOP as a parallel data lake. Architectural stability comes from separating layers well, not from anchoring to one specific standard. It is a recurring but costly lesson — every generation of systems that did not follow it ended up rewriting large-scale integrations.

References: HL7 Clinical Document Architecture, Release 2. HL7 FHIR R4 (Normative) and R5. openEHR Foundation specifications, ISO 13606. OMOP Common Data Model (OHDSI). IHE IT Infrastructure Technical Framework. Regulation (EU) 2025/327 EHDS.