openEHR and FHIR: best of both worlds.

For vitagroup, which has been building its portfolio for several years on the basis of openEHR and FHIR, and has deployments in over 30 hospitals in Germany, the cooperation is highly welcomed.

openEHR: the open platform for native interoperability.

As HIP’s value proposition is vendor-neutral digitalization, we started with the definition of an internationally standardized and 100% open data layer.

openEHR International provides (opens in new tab) free specifications to build an open platform which serves as the foundation for a central data hub and enabler of an application ecosystem of natively interoperable apps.

Its standardized system and information architecture provides the foundation for a transactional data backend, which serves in systems including:

• electronic medical records
• care management applications
• decision support systems
• and more.

In this sense, you can think about openEHR as the equivalent of the databases you find in EMR systems like Cerner or Epic. Of course with the big difference that openEHR is vendor-neutral, open, standardized and comes with a powerful software development, modelling framework and a globally active tooling ecosystem.

The clinical content in openEHR is based on an international, community-driven modelling approach, which provides a growing library of carefully curated data models (called Archetypes). Archetypes aim for a maximum dataset, which means they can be reused across different clinical domains and use-cases to unambiguously capture information for the electronic health record. The openEHR system can digest new Archetypes at any time and thereby flexibly enhance the clinical domains and data points covered.

In our HIP, openEHR provides the technology to store data long-term and build an ecosystem of natively interoperable apps. The combination of a shared architecture, strong software development capabilities combined with the clear separation of applications from data, allows for the long-term management of data “for life”.

FHIR: breaking up data silos

The capabilities of openEHR are complemented by using FHIR. FHIR provides (opens in new tab) technical resources, tools and methods to define standardized APIs in clinical application systems. This way, existing systems can provide a standardized way of accessing and exchanging healthcare information. In today’s world of proprietary system architectures, it provides healthcare systems with the ability to enhance interoperability by mandating vendors to use this standard.

FHIR also provides a foundation to connect applications like patient portals and apps to platforms through its API, helps standardizing the authentication and authorization workflows of third party applications (through SMART on FHIR) as well as the definition and orchestration of clinical processes, complementing the messaging exchange of HL7 v2.

OpenEHR & FHIR: winning combination

Patients, care providers and the healthcare system at large greatly benefits from the combination of both standards as applied in HIP:

Data Management / Data Governance

• By using openEHR Archetypes, organizations can build comprehensive data dictionaries with detailed metadata. A unique feature is that this metadata is actionable, as it can be directly used for data validation, database queries, design of clinical forms, storage etc.
• Clinicians easily understand Archetypes as they are expressed in a domain language. This way, information managers and clinicians are put in the driver’s seat of health data management. No nuance gets “lost in translation”.
• Many CDRs in the market provide a combination of a proprietary storage layer along with a FHIR API implemented through a façade. This is done because only a small fraction of actual healthcare data is represented in standardized FHIR models and modelling complex documents (like surgery theatre protocols) is tedious. By using openEHR instead of a proprietary storage layer, the need to represent the depth and breadth of health care is addressed while keeping the data in an open format.

Application Development

• When building new application systems using openEHR, systems share the electronic health record architecture and data models, enabling interoperability “by design”. Data is accessed through a standardized API including a powerful query language (“Archetype Query Language”), makings applications portable between different implementations of openEHR. As its architecture is designed to build transactional application systems, we find smaller apps as well as full-blown EMR systems based on openEHR.
• Because of the separation of data and applications, systems don’t “exchange” data, but access them through a shared data layer in the CDR. This means that tedious data integration using messages and semantically lossy copies of healthcare data is avoided.
• In openEHR, the design of forms always starts with the data model (no matter if using low-code tools or programming manually). This approach ensures that all data entries in the health record are properly defined with rich metadata instead of ad-hoc structures which might require extensive mappings later.

Data Integration and Exchange

• FHIR allows to create an extract from the detailed and comprehensive electronic health record and aggregate into resources and bundles to address specific use-cases like reports, health information exchange (like medication plans, discharge letters and more). Typically, these reports are not hard copies of data but need to be dynamically assembled from different data points in the health record.
• This ability is especially useful when different FHIR implementation guides require the use of the same data in different profiles. Also, changes in the version of the API, for example changing from FHIR R4 to R5, will not induce costly data migrations of billions of database rows.
• As increasingly more interfaces based on FHIR are demanded in many countries, integration of data into the CDR is facilitated. However, adaption is slow and still only a fraction of available data points is typically covered as mappings from internal models to FHIR APIs requires considerable effort by the system vendors.

Actionable Healthcare Data

• A platform based on openEHR and FHIR increases the capabilities to make all relevant patient information available to healthcare providers at the point of care. This comprehensive data access can lead to more informed decision-making, timely treatments, and personalized care plans.
• It also enhanced data consistency and availability help in managing chronic conditions, where long-term data tracking and accurate history are crucial. Because openEHR and FHIR both abstract from the underlying technology layer, systems are efficiently maintainable, and data remains accessible over the lifespan of patient.
• The platform sets the foundation for clean data that can serve the training of machine learning algorithms and the execution of rule-based clinical decision support systems.

As FHIR was developed with the goal in mind to provide an API for “blackbox” systems and does not strongly interfere with system internals, it provides good capabilities to play nicely a broad range of system designs. In combination with openEHR, users get these advantages plus the benefits of a standardized “whitebox” system with strong data governance and modelling as well as software development capabilities.

Collaboration between openEHR and FHIR: important steps

From this point of view, the collaboration between openEHR and FHIR can only further advance this combed approach. From our perspective of using both standards in our product, we see some potential fields of collaboration for the benefits of healthcare providers, patients, and system vendors:

• Joint Modeling: Initiatives like the Australian SPARK initiative (opens in new tab) have shown ways how the detailed models from openEHR can information FHIR profiles to allow for seamless integration. A great starting point can be the use of shared value sets based on SNOMED-CT and LOINC.
• Shared data governance: Advanced governance tooling should allow to directly represent mappings and relations between both standards.
• Technical specifications: while data types can be mapped between openEHR and FHIR, some further alignment of the software classes can make the integration easier.
• Standardized mappings: providing packages of reusable mappings can help to build a library across vendors and communities to enable plug and play integration.

Both standards on their own are very valuable for the healthcare system and the joint use provides even greater benefits and a real-vendor independent data platform. The dual approach not only ensures that medical data is readily accessible when and where it’s needed but also maintains its accuracy and relevance over time, which is vital for chronic disease management, comprehensive care, and overall patient safety.

The prospect of the collaboration of HL7 and openEHR International only makes us more excited to build the foundation of the data platform, the operating system, for tomorrow’s healthcare systems.