FHIR and openEHR represent different architectural approaches to EHR systems.
openEHR is centered on a hierarchical (tree-like) data structure, making the data model easier to standardize and transfer between organizations. Both have their own structures for data.
openEHR focuses on the Reference Model (RM), archetypes, and templates; which separate the clinical knowledge from the technical infrastructure.
FHIR resources, which carry their technical infrastructure directly, can easily be represented in formats like XML and JSON, and rely on their resource schema to provide structure. while openEHR also uses API-based data transfer in JSON and XML. openEHR mandates a high degree of validation on data transfer, as the clinical data must strictly conform to the Archetype and Template constraints in the CDR, often resulting in a “hard server stop” if the rules are breached.
Architectural Roles and Implementation
This core divergence in structure and validation dictates their primary architectural role in a modern health system.
FHIR’s focus on lightweight resources and a simple RESTful API makes it the ideal standard for data exchange and application integration. It is designed for short-lived, transactional workflows like a mobile app quickly requesting a patient’s current medication list or posting a new allergy.
openEHR, conversely, is built for long-term data persistence and semantic consistency. By making versioning and audit trails a mandatory part of its Reference Model, openEHR is designed to be the vendor-neutral, medico-legally sound Clinical Data Repository (CDR) for a patient’s entire life.
Consequently, many modern implementations are adopting a hybrid architecture, where openEHR stores the deep clinical history and FHIR is used as the public API layer to expose that data for quick consumption by third-party applications.
Hybrid Architecture: FHIR as the API, openEHR as the Data Core
The consensus across modern health IT is that FHIR and openEHR are complementary. Their architectural roles are distinct and address different layers of the modern EHR stack.
1. openEHR as the Clinical Data Repository (CDR): openEHR serves as the single source of truth for all patient information. Its robust versioning, audit trails, and stable Reference Model are essential for maintaining the medico-legal soundness and semantic integrity of health records over the patient’s entire life.
2. FHIR as the Data Exchange Facade: A mapping engine or “FHIR Facade” sits in front of the openEHR CDR. This engine translates the rich, granular data stored in openEHR’s Compositions and Archetypes into the more lightweight, transactional FHIR Resources (like Patient, Observation, or MedicationRequest) in real-time.
Real-World Practice Examples
National Health Systems:
Countries like Slovenia and parts of the UK (NHS) use openEHR to build their foundational, vendor-neutral clinical data layer. This separation allows them to swap out application vendors (the user interface) without risking their patient data, which remains structured and intact in the openEHR CDR. FHIR is then the standard mechanism to deliver this data to external apps.Third-Party App Integration:
In a hospital environment using this hybrid model, a doctor's mobile application would use a FHIR API request to quickly pull the patient's current vital signs. The FHIR Facade fetches the complex, versioned data from the openEHR CDR, simplifies it into a FHIR Observation Resource, and sends the quick response. The app only needs to understand the simple FHIR structure, not the underlying complexity of the openEHR data model.Application Development (Exchange Priority) Apple Health Records Integration:
1. Apples Health Records feature on the iPhone uses FHIR APIs to securely pull data (lab results, immunizations, medications) from hundreds of US health systems. While the backend systems (Epic, Cerner) may not use openEHR but EHR data, this demonstrates the power of FHIR as the universal exchange layer that allows a lightweight, consumer-facing application to work across heterogeneous EHR systems.
2. Remote Patient Monitoring (RPM):
2.1 FHIRs role: A patients at-home blood pressure monitor sends readings as simple FHIR Observation resources (JSON objects) via an API gateway. This is fast, easy, and standardized for quick exchange.
2.2 openEHRs potential role: A sophisticated RPM program might store this raw FHIR data into the openEHR CDR, where it can be combined with other clinical context (e.g., the care plan, the related diagnosis) and subjected to AQL queries for clinical decision support.The common thread in all these examples is the recognition that FHIR excels at interoperability and moving data, while openEHR excels at modeling and governing data once it is permanently stored.
Note: Does Apple Health Records Use openEHR?
No! The integration relies entirely on FHIR.
Epic and Cerner do not use openEHR for their core clinical data storage. They use their own proprietary database models. Apple Health Records works by requiring these EHR systems to expose a publicly available FHIR API endpoint (specifically using the SMART on FHIR standard).
Editors
openEHR Editor Tools
1. Archetype and Template Designers (Modeling)
These graphical tools are primarily used by clinical domain experts and informaticians to define what data can be captured and how that data relates to clinical concepts.
1.1 Archetype Editor (e.g., Ocean Archetype Editor, ADL Workbench) Used to create and edit Archetypes; the granular, reusable building blocks of clinical data (e.g., “Blood Pressure,” “Problem/Diagnosis”).
1.2 Template Designer (e.g., openEHR Archetype Designer, LinkEHR) Used to assemble multiple Archetypes into an Operational Template (OPT), which represents a specific data set or clinical document (e.g., “Maternity Discharge Summary”).
2. AQL Query Editors (Querying)
The Archetype Query Language (AQL) is openEHRs query language. Since AQL queries the semantic structure defined in the archetypes (rather than the physical database schema), specialized tools are needed.
FHIR Profiling Tools
Forge (Firely): The official tool for creating, editing, and validating FHIR Profiles, Extensions (to add missing data elements), and Logical Models. It’s the most widely used visual modeling tool.
FHIR Shorthand (FSH) / SUSHI: Used by developers who prefer a simple, text-based code to define profiles and implementation guides. The SUSHI tool compiles the FSH code into the FHIR JSON/XML formats.
API Testing Tools (Development/Integration)
Postman / Insomnia: Used to perform all FHIR API transactions (GET, POST, etc.) and test the search parameters against a live FHIR server.
FHIR and openEHR are not substitutes for one another, but rather specialists in different domains of health informatics. FHIR is the indispensable tool for interoperability and application development, maximizing the flow of information. openEHR is the ideal tool for clinical data governance and long-term storage, maximizing the quality and longevity of information. The most sustainable and powerful modern EHR systems recognize and embrace this division of labor, leveraging the simplicity of the FHIR API on the frontend while relying on the structural depth of openEHR for the clinical backend.