The False Dichotomy in Clinical Data Standards
In health IT discussions, openEHR and HL7 FHIR are frequently positioned as competing approaches to clinical data management. Vendors and consultants often frame the choice as binary: either you adopt FHIR for everything, or you invest in openEHR as an alternative. This framing fundamentally misunderstands what each standard does.
FHIR is an interoperability standard. It defines resources and APIs for exchanging health data between systems. openEHR is a clinical information modeling standard. It defines archetypes and templates for representing clinical knowledge in a computable, vendor-neutral format. These are different layers of the clinical data architecture, and conflating them leads to poor architectural decisions.
The organizations building the most resilient clinical data platforms use both standards deliberately, assigning each to the layer where it provides the most value.
Where FHIR Excels: Transport and Integration
FHIR provides a modern, RESTful API standard for health data exchange. Its resource model is broadly supported by EHR vendors, payer platforms, and public health systems. The FHIR specification includes search parameters, operations, and subscription mechanisms that enable real-time data access across system boundaries.
For integration use cases — pulling patient demographics from an EHR, submitting a prior authorization request to a payer, publishing a clinical document to a health information exchange — FHIR is the clear standard of choice. Its adoption is mandated by US regulation, its tooling ecosystem is mature, and its community is active.
However, FHIR resources are designed for data exchange, not data persistence. A FHIR Patient resource is a representation of patient data at a point in time, not a master patient record. FHIR profiles and extensions allow customization, but this customization can create semantic drift between organizations that use the same resource type with different profiles.
Where openEHR Excels: Clinical Knowledge and Persistence
openEHR provides a formal methodology for defining clinical data structures that are independent of any specific technology platform. Archetypes define the maximal data set for a clinical concept, and templates constrain archetypes for specific use cases. This two-level modeling approach means that the clinical knowledge is maintained separately from the technical implementation.
For clinical data persistence — storing longitudinal patient records, building clinical decision support repositories, managing population health analytics platforms — openEHR archetypes provide semantic stability that FHIR profiles alone cannot guarantee. The archetype governance process ensures that clinical definitions are reviewed by domain experts and maintained across versions.
openEHR also provides a query language (AQL) designed specifically for clinical data, enabling queries against the archetype model rather than the physical storage model. This allows clinical analysts to write queries using clinical concepts rather than database column names.
The Integrated Architecture: openEHR for Persistence, FHIR for Exchange
The most effective clinical data architectures use openEHR for the persistence and governance layer and FHIR for the integration and exchange layer. Clinical data is stored using openEHR archetypes in a vendor-neutral clinical data repository. When that data needs to be exchanged with external systems, it is transformed into FHIR resources using well-defined mappings between archetypes and FHIR profiles.
This architecture provides semantic stability for internal clinical data management, standards-based interoperability for external data exchange, a clear separation between clinical knowledge governance and technical integration, and the ability to evolve integration patterns independently of the clinical data model.
Implementing this architecture requires expertise in both standards and a clear understanding of where each provides value. It is not a trivial undertaking, but it produces a clinical data platform that is significantly more resilient and governable than either standard used alone.