FHIR Connect is an exciting new service on the Better Digital Health Platform (DHP) with an open, vendor-neutral framework that can be used to integrate Fast Healthcare Interoperability Resources (FHIR) applications with an openEHR clinical data repository.
It is designed to support the translation of the majority of FHIR resource types through an open, configuration-based specification. Citizen developers — with appropriate knowledge of FHIR and openEHR — from independent software vendors, system integrators, and healthcare providers will be able to use FHIR Connect to quickly build or re-use bi-directional FHIR interfaces that communicate seamlessly with an openEHR repository.
Why are we doing this?
FHIR has established itself as the “de facto” standard for exchanging health and care information, with an increasing number of applications now providing native FHIR support. Alongside this, many healthcare systems are putting openEHR at the centre of their architectures, helping them establish ecosystems of disruptive and innovative services centred around the patient (see Why openEHR is Eating Healthcare).
At Better, we believe FHIR and openEHR are two complementary standards that should be combined to create an open, interoperable ecosystem. We have published our thoughts on this in a variety of posts (including FHIR + openEHR) but it is a view now increasingly held by a wider community, including Microsoft who recently announced their support for openEHR and the importance of complementing it with FHIR.
Up to now, it has been possible to combine these standards, but it was a complex task typically involving software development or complex mappings within a proprietary integration engine. Additionally, many existing solutions do not support bi-directional mappings or require information to be duplicated in caches. Where mappings have been defined, they typically cannot be re-used, limiting the adoption of these standards working better together.
What are the benefits of FHIR Connect?
How will it work?
The core idea behind FHIR Connect is its dual mapping approach that allows a core set of re-usable mappings to be established, with an additional group of contextual mappings — aligned to a specific use case — to be configured locally by implementers.
The first set of mappings — called Model Mappings — are between openEHR archetypes and FHIR resources. This represents a mapping between the two smallest comparable units of semantic information by both standards and as a result, allows these mappings to be globally re-usable where the given archetypes and FHIR version are deployed.
The second set of mappings — called Contextual Mappings — allows the context of a specific use case to be handled. In openEHR this context is always represented by a template. On the FHIR side, this context could be a variety of FHIR artefacts including a resource, profile, bundle, or implementation guide2.
At runtime, a mapping engine will evaluate the context of each request and apply the appropriate mapping logic. As openEHR is more descriptive — due to its maximal modeling approach — the approach to processing Model Mappings is always in the direction of FHIR to openEHR.
Additionally, the mapping specification will allow for functional keywords to be used that will apply conditional business logic. For example, to filter a list of observations to match a given SNOMED or LOINC Code. As the scope of FHIR Connect is specifically targeted to FHIR and openEHR we can be specific and opinionated regarding the keywords we support and how they are implemented.
The diagram below presents a high-level overview of the architecture.
What use cases will FHIR Connect support?
The following architectural patterns are the ones we have seen most often when working with our customers. We have designed FHIR Connect to be modular so it can be plugged into any of these scenarios.
Illustration by example
At HIMSS Europe this week we launched FHIR Connect. As a lot of the functionality runs as a background service, we have used a simple scenario, with the following user personas to illustrate it in action.
In this example, FHIR Connect has been configured to run inside a Sync Agent, alongside Azure Health Data Services. The scenario starts with our Paediatrician, Patrick, completing a form built using the Better low-code Studio. This openEHR data is converted to FHIR and saved in Azure Health Data Services. To illustrate how this technology can be used to facilitate the development of an eco-system, a third-party growth charts application from the Boston Children’s Hospital — which communicates using FHIR — will be accessed by our Paediatric Endocrinologist, Andjela, via Microsoft Teams.
How are the mappings evaluated?
When the form is completed by Patrick, an event is triggered that is consumed by FHIR Connect. The event metadata contains information about the openEHR template, so we have all the information we need to identify the context. An example of the Contextual Mapping for this use case is shown below3.
With the Contextual Mapping at hand, we now have a list of the openEHR archetypes to expect in the payload. Each published Model Mapping is then evaluated against the payload — which is filtered to only contain the current archetype’s scope. The mappings are applied and the associated FHIR resources are collected in a bundle.
The Model Mapping for body height is shown below.
The processing logic if going in the other direction — FHIR to openEHR — would be slightly different, but the mappings themselves would remain unchanged, ensuring our mappings are bi-directional for all use-cases.
Once we have the assembled FHIR Bundle in place, this is then posted to Azure Health Data Services, allowing this data to then be used by the wider Azure ecosystem — including PowerBI or other analytical tools such as Azure Synapse or Data Bricks.
What’s next?
We will continue to work with our customers and partners to develop FHIR Connect to support their use cases. Our focus will initially be on the following areas, but we would welcome feedback on how we can best develop FHIR Connect to accelerate the convergence of FHIR and openEHR.
We have had some fantastic feedback on FHIR Connect during HIMSS and are looking forward to developing this product further to help provide access to better data and better care. Please feel to reach out to any of the authors of this article if you would like to discuss in more detail.
Authors
Jake Smolka
Matija Polajnar
Alastair Allen
Boštjan Lah
Andjela Pavlović
Notes
1 A Low code mapping studio is on the roadmap.
2 FHIR Profiles and implementation guides are on the roadmap.
3 The FHIR Connect mapping format for Contextual Mappings and Model Mappings is still subject to change as we implement additional use cases.