openFHIR
bridging 
and
openFHIR is an engine that implements FHIR Connect specification and facilitates bidirectional mappings between openEHR and FHIR.
and
openFHIR is an engine that implements FHIR Connect specification and facilitates bidirectional mappings between openEHR and FHIR.
position within your architecture
Your typical data-centric setup includes an openEHR clinical data repository with well-modeled templates and archetypes. To make this data easily accessible through the FHIR standard, you might have an additional FHIR facade or server on top.
Without a mapping engine between these components, you end up with two separate clinical data repositories that can't communicate or sync data effectively.
The openFHIR engine solves this problem by acting as an intermediary component within your ecosystem. It can be invoked as needed to perform the necessary mappings, without tightly coupling to other systems or disrupting existing openEHR or FHIR functionalities. Users can still query both openEHR and FHIR directly.
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
Specification itself strongly builds upon existing patterns and syntax, such as FHIRPath, flat format of 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.
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.
Demo of the product
Standalone, easy to set-up and to integrate within your existing architecture
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.
It is dockerized, making installation quick and easy with built-in scalability, and it can be run on any operating system.
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.
We offer support for setting up and configuring the openFHIR engine, as well as for writing and maintaining FHIR Connect mappings.
As the FHIR Connect specification evolves, our top priority is to stay aligned with its improvements and changes.
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.
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.