openEHR vs FHIR: why the best health platforms often use both

Different jobs

A helpful way to see it, set out in one comparison of openEHR, FHIR and CDA, is as layers rather than rivals: FHIR for transactional exchange, openEHR for native persistence with clinical governance, and CDA for archival documents¹.

What two-level modelling buys you

openEHR's central idea is separating the software model from clinical content. A stable reference model sits at the first level. Archetypes, each describing one clinical concept such as blood pressure, and templates, which combine and constrain archetypes for a specific use such as a discharge summary, sit at the second². Clinicians can define and evolve content without the software changing underneath.

Archetypes are governed centrally and reused globally through the Clinical Knowledge Manager⁶. In community discussions, practitioners argue that archetypes express domain semantics independent of technology, while FHIR profiles tend to be scoped to particular implementations³. That's a perspective from the openEHR side, but the point about governance is fair: a well-reviewed archetype for blood pressure means the same thing in every system that uses it.

What FHIR does better

FHIR was built for exchange: resources, RESTful APIs and a web-developer-friendly approach⁵. It has become the default in regulation and procurement. US interoperability rules, prior authorisation APIs and bulk data access all build on it, as covered in CMS-0057-F and FHIR Bulk Data pipelines. Developers can be productive with FHIR quickly, and tools, libraries and test servers are plentiful.

Using a FHIR server as the primary store is where opinions diverge. One practitioner write-up argues it works for simpler cases but struggles with complex documents, temporal queries and archetype-level governance⁴. That is a vendor perspective; plenty of organisations do run FHIR-native repositories successfully. The question is how much clinical modelling depth and long-term governance you need.

The pattern I use: three layers

1. Persistence. Where the organisation needs deep, governed clinical records over decades, an openEHR clinical data repository holds the source of truth, with templates agreed with clinicians.
2. Exchange. FHIR APIs expose data to apps, partners, payers and national exchanges. A facade maps between openEHR compositions and FHIR resources, a pattern described in practice write-ups⁴.
3. Analytics. An OMOP CDM, built downstream, serves research, quality and AI, with standard vocabularies as described in clinical terminologies and OMOP and the pipeline in FHIR to OMOP.

Where deep clinical modelling isn't needed, for example a digital health start-up with a narrow product, a FHIR-native store plus OMOP for analytics is often simpler and perfectly adequate.

How to decide

• Who is the customer? National or regional health systems planning decades ahead lean towards openEHR for persistence. Products integrating with many partners lean towards FHIR first.
• Who owns clinical content? If clinicians need to define and govern data models directly, openEHR's tooling is built for that.
• What does regulation require? Exchange obligations almost always mean FHIR, whatever you store internally.
• What skills can you hire? FHIR skills are more widely available; openEHR expertise is concentrated in particular regions and vendors.
• What will you analyse? Neither is an analytics model. Plan for OMOP or a similar layer from the start.

Why it matters for AI

Clinical AI depends on data that means the same thing across sources and over time. Governed archetypes, consistent FHIR profiles and standard vocabularies all serve that goal. The worst foundation for AI is a mix of local models with no shared semantics, whatever standard name is on the label. That is an ontology problem first, and the same principles apply as in ontology, knowledge graph and semantic layer.

How I can help

I design clinical data platforms that combine persistence, exchange and analytics standards sensibly, for health systems and health tech companies in the US, Europe and the Gulf. See healthcare data architecture, or analyse your challenge and bring the result to a call.