Introducing FHIR Connect

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? 

• Mapping definitions are open and vendor-neutral -  Following the approach we have adopted for Better Studio Widgets (see this link), we plan to open source the core mapping specification, enabling a community to emerge around FHIR and openEHR convergence. 
• Mappings are re-usable globally and configurable locally – We have created an innovative dual mapping approach that allows a core set of re-usable mappings between openEHR archetypes and FHIR resources to be established. An additional layer of contextual mappings allows the context of a specific use case to be defined using openEHR templates and the matching FHIR artefact — a resource, profile, bundle, or implementation guide2. 
• Mappings are bi-directional – Many existing mapping solutions can only apply mappings in one direction. We have designed FHIR Connect to implicitly apply a single set of mappings in either direction — FHIR to openEHR or openEHR to FHIR. 
• It provides a platform for citizen development - According to Gartner, “by 2023, the number of active citizen developers at large enterprises will be at least four times the number of professional developers”. We believe this movement will include interface development, in addition to traditional user-facing applications. FHIR Connect has been designed in a way that will allow the definition of FHIR and openEHR mappings to be expressed using low-code tooling¹.

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 guide². 

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. 

• Pattern 1 —  Facade — A translation component is introduced to translate inbound and outbound FHIR requests to an openEHR repository.  Typically, alongside this, openEHR APIs will be used to support a complete set of functionalities.  Note – in this model FHIR Connect is not intended to support the full set of FHIR server capabilities, but instead is focused on the mapping functionality aligned with core create, read, update and search operations.  
• Pattern 2 — Message Broker — An integration engine acts as a message broker to translate incoming messages from external applications. 
• Pattern 3 — Sync Agent — A sync agent exists to copy a defined group of data items between a FHIR and openEHR repository. 

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 below³. 

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. 

• FHIR Connect specification – we will soon publish the specification for FHIR Connect so the community can contribute to this emerging initiative.  
• Default Mappings – we will work towards publishing a core set of mappings aligned to the most common FHIR and openEHR artefacts. 
• Low-code studio – Providing a user interface that will allow mapping files to be configured in a more visual way. 

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.