Achieving your long term data strategy and vision
In modern healthcare, seamless data exchange is essential—but building a future-proof data strategy matters even more. By combining openEHR with FHIR, you can create a clinical data repository that ensures long-term reliability while leveraging FHIR’s widespread adoption for accessibility and interoperability.
Unlocking interoperability with the openFHIR Engine
A typical data-centric setup includes an openEHR repository and a FHIR server for accessibility. Without a mapping engine, these systems remain isolated, unable to sync data. The openFHIR engine bridges this gap, enabling seamless mapping without disrupting openEHR or FHIR functionalities, while allowing direct queries to both.
data for life stored in vendor neutral openEHR
exchange through widely and nationally adopted FHIR
compliance to frameworks that enforce FHIR
non-disruptive, incognito component with all native openEHR and FHIR functionalities kept intact
Want to see how it works?
Get a clear understanding of how FHIR and openEHR integration can transform your data workflows. Watch our detailed explainer video for an in-depth look at the technology, its capabilities, and real-world applications.
Building Bridges Between Healthcare Standards
openFHIR is an engine that implements FHIR Connect specification and facilitates bidirectional mappings between openEHR and FHIR.
FHIR Connect mapping specification
FHIR Connect is an open, vendor-neutral specification for mapping openEHR to FHIR and vice-versa. By following this specification, you can write a single mapping in YAML format that can be used for both directions: FHIR to openEHR and openEHR to FHIR. This vendor-neutral approach ensures that any engine capable of running these mappings can execute them. openFHIR is one such engine.
Querying openEHR
When querying an openEHR CDR through a FHIR facade, the query
returns a Composition that must be mapped to a FHIR response before being sent to the FHIR facade
and, subsequently, the FHIR caller.
This ensures that the FHIR requestor receives a proper FHIR
response with data from the openEHR repository. This approach maintains a data-centric and "data for
life" philosophy without data duplication or silos.
Storing to openEHR
When a FHIR data source stores data (FHIR Resources) into your system, the openFHIR engine translates the incoming FHIR data into an openEHR Composition for proper storage in an openEHR repository. This method keeps your openEHR clinical data repository accessible through a FHIR facade, maintaining a data-centric openEHR approach without creating data duplication or silos.
A clean fit into your arhitecture
Standalone, easy to set-up and to integrate within your existing architecture
Standalone
The openFHIR engine is a standalone, self-sufficient component that integrates seamlessly into your existing architecture. It has zero impact on the functionality of other components, ensuring that native openEHR and FHIR capabilities remain intact.
Dockerized
It is dockerized, making installation quick and easy with built-in scalability, and it can be run on any operating system.
RESTful API & Queues
The engine can be invoked in two ways: through a RESTful API for real-time message transformation, or by hooking into message queueing systems for background mappings.
Support
We offer support for setting up and configuring the openFHIR engine, as well as for writing and maintaining FHIR Connect mappings.
Continuous development
As the FHIR Connect specification evolves, our top priority is to stay aligned with its improvements and changes.
Future roadmap
Key items on our near-future roadmap include the ability to translate FHIR to AQL, and the development of a user interface for creating FHIR Connect mappings.
Frequently asked questions
Got more questions?
openFHIR engine is packaged as a docker container that you set up within your environment. Extensive documentation together with a support of a consultant is offered to set it up as well as to integrate it with other components of your architecture.
openFHIR engine stores no data other than the mappings. Any and all (clinical or operational) data that needs to be mapped from FHIR to openEHR and vice versa is mapped on the fly. Nothing is stored or cached in any way, shape or form.
openEHR CKM has recently introduced an additional tab where mappings such as FHIR Connect ones can be published together with a published Archetype ( source ). To write you own mapping, it's best to follow the official github repository where you can also find a JSON schema that (at least to some extent) simplifies writing one.
openFHIR engine can map bidirectionally between openEHR and FHIR. It provides an RESTful API where a consumer can either map from a FHIR Resource to an openEHR Composition or from an openEHR composition to a FHIR Resource. All of this with a single mapping definition. Mapping of queries (FHIR query to openEHR AQL) is currently not yet supported, but is on the highest of the todo items.
It offers a RESTful API with 2 endpoints (for mapping). One accepts an openEHR Composition and returns a mapped FHIR Resource; another accepts a FHIR Resource and returns a corresponding mapped openEHR Composition.
Ready to Transform Your Healthcare Data?
Empower your organization with advanced solutions for seamless FHIR and openEHR integration. Contact us to explore how we can support your data-driven transformation.