CDA R2, FHIR and openEHR answer three different technical questions, and the most common mistake in health system architecture is treating them as alternatives to choose between. All three model clinical data, but a shared domain does not make them interchangeable: they sit at different layers of a system. The question to ask is not which of the three to adopt, but which problem each one solves and what happens when you put it where it does not belong.

Context

HL7 Clinical Document Architecture Release 2 (CDA R2) has been an ANSI standard since 2005, and derives from the HL7 v3 Reference Information Model. HL7 Fast Healthcare Interoperability Resources (FHIR) had its first draft in 2014, the R4 release with normative parts in 2018, and R5 in March 2023. openEHR has been specified by the openEHR Foundation since 2003, with ISO 13606 as the formally equivalent standard for communicating electronic health record extracts.

Three dates, three settings, three different problems. It is worth reconstructing them before putting them side by side, because the comparison only holds if you start from each one’s original question.

CDA R2: the archival unit

CDA R2 answers a precise question: how to represent a clinical document so that it stays readable and valid even when the system that produced it no longer exists. Its load-bearing traits are those of a document, written plainly into the specification: persistence, stewardship (an identified custodian organisation), the possibility of authentication, integrity, context, and guaranteed human readability.

A CDA document is an entity closed in on itself. It has an author, a custodian, a possible legal signature, and an XSLT stylesheet that guarantees its visual rendering whatever application opens it. A discharge letter, a laboratory report, a patient summary, an emergency-department record: each is an act with its own legal identity and its own lifecycle.

In first-generation European electronic health record programmes — the Italian one included — CDA R2 is the format of the published, shared documents, carried by the IHE XDS.b and XCA profiles. Its limits are equally well known: a single serialisation, in XML; no exchange API defined by the standard, which delegates it to external frameworks such as IHE; and an entry-level granularity that lends itself poorly to analytical aggregation. The complexity inherited from the RIM makes the learning curve steep.

FHIR: the transactional resource

FHIR answers another question: how to exchange clinical data granularly and frequently between different systems, with the conventions of the web. The unit is not the document but the resource — Patient, Observation, MedicationRequest — atomic, identified by a URL, composable by reference.

The model is that of a REST API: HTTP verbs, two equivalent serialisations (JSON and XML), extensibility through Extension, a conformance-driven design in which Profile definitions are machine-readable. FHIR is at its best where frequent interaction and fine-grained data are needed: an app reading clinical state, decision-support integration via CDS Hooks, feeding a repository, bulk export for analytics.

What FHIR does not give on its own is the archival dimension. A resource does not carry a single author, a signature, a custodian: these are not part of how it is built. The Bundle of type document covers documentary scenarios, but to meet regulated retention obligations an external framework is still needed: a FHIR document is a composition of resources, not a preserved unit in its own right.

openEHR: persistence that evolves

openEHR answers a third question: how to store clinical data so that the clinical model can change over time without rewriting databases and applications. The answer is the two-level model. A technical Reference Model, stable and generic, defines the data schema. Above it, a clinical level governed by clinicians, made of archetypes written in ADL (Archetype Definition Language); templates compose the archetypes for the concrete use case.

Data is stored according to the Reference Model and annotated with archetype paths. Queries go through AQL (Archetype Query Language), which works on clinical paths regardless of the database’s physical schema. Adding a field to an archetype does not require a schema migration: the technical level stays still, the clinical annotation changes.

Its natural ground is keeping structured data where model evolution is a stated requirement: regional clinical repositories, longitudinal records, research platforms. Archetype governance through the Clinical Knowledge Manager is a trait of its own — the same blood-pressure archetype is shared across systems in different countries. openEHR is not an exchange standard in the strict sense: when it has to communicate outward it does so by exposing FHIR, exporting CDA documents, or through its own REST API.

The critical point

The serious architectural problem appears when a standard is put in another’s role. Three sources of friction that come up often.

Using CDA as a transactional API. A document is made to be published and retrieved whole, not queried field by field. Treating it as a granular resource means parsing heavy XML on every read, without the verbs and search mechanisms FHIR offers on its own. Frequent exchange becomes costly and brittle.

Using FHIR as a legal archive. A resource or a Bundle does not, by construction, carry CDA’s documentary guarantees. They can be reconstructed — signature, custody, immutability — but outside the standard, with a retention framework that brings back precisely the documentary complexity one was trying to avoid. You end up reimplementing CDA on top of FHIR.

Exposing openEHR as an exchange format. Archetypes serve internal governance and retention, not to act as the contract with third parties. The intended route is to map them onto FHIR on exposure: openEHR stays the way data is stored, FHIR the way it is seen from outside. Publishing raw archetypes as an interface means exporting your internal model, and from that point on whoever consumes it stays bound to it.

The common thread is a single one: each standard carries constraints that come from its original question. Forcing it elsewhere does not cancel them, it pushes them downstream as adaptation code.

Implications

Mature architectures do not pick a single standard, they arrange them across different layers. Two combinations seen in European systems:

  • CDA and FHIR side by side. This is the scenario of the Italian electronic health record: existing CDA documents and Italian FHIR profiles coexist on the gateway, which exposes both SOAP/XDS interfaces for legacy systems and FHIR REST for new applications. Documents born as CDA stay CDA, new ones are born FHIR.
  • openEHR as repository, FHIR as API. Clinical data is stored natively in openEHR with governed archetypes; external access goes through a FHIR layer that translates on the fly. This is the pattern of several European regional systems. openEHR is never seen from outside, FHIR is never the storage format.

On the regulatory side, Regulation (EU) 2025/327 establishing the European Health Data Space entered into force on 26 March 2025, with phased application over the following years. It does not mandate a single standard, but designates FHIR as the reference format for cross-border primary use through MyHealth@EU, with the International Patient Summary in a FHIR profile as the content of the European patient summary. CDA R2 does not disappear — historical archives remain and must be preserved — but it stops being the reference format of the harmonised European specifications.

Limits

This map is an abstraction, and abstractions lose detail. Three cautions.

The boundaries are not as sharp as a three-column table suggests. FHIR covers documentary scenarios with the Bundle, openEHR can also be used for exchange in closed settings, and part of the industry stores directly on FHIR-native databases, skipping openEHR. The document/transaction/persistence split is a design criterion, not a law of physics.

The cost of a multi-layer architecture is real: every mapping is code to write, test and maintain, and the semantic convergence between standards — clinical concepts with shared LOINC and SNOMED CT codes — reduces translation friction but does not remove it. A single-standard system is simpler, until it meets the requirement that one standard cannot serve.

Finally, the choice is not for ever. The history of Italian systems, from the move from HL7 v2 to CDA and on to FHIR, says that a standard’s life is shorter than a health system’s. Stability comes from separating the layers well, so that changing one layer’s standard does not force a rewrite of the others. It is a lesson that returns with every generation, and those who did not apply it paid the bill by rewriting their integrations.

https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 https://hl7.org/fhir/R5/ https://hl7.org/fhir/versions.html https://specifications.openehr.org/ https://www.iso.org/standard/67868.html https://eur-lex.europa.eu/eli/reg/2025/327/oj/eng https://www.ihe.net/resources/technical_frameworks/ https://www.noze.it/en/insights/openehr-fhir-cda-comparison/

Cover image: Class diagram of the HL7 Reference Information Model: connected boxes representing the core classes of the healthcare information… — diagram by Darek098, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Hl7rim.jpg