FHIR + openEHR

Home · Insights · FHIR + openEHR
Date posted
29 November 2019
Reading time
27 Minutes
Alastair Allen

FHIR + openEHR

I recently presented at an openEHR event in London where I talked about my experience of working with FHIR and openEHR. You can check out a recording of my talk here, or if you would rather not listen to my strange Northern Irish accent for 20 minutes then read on for a summary of the key points.

Having worked on FHIR projects for a number of years now I am starting to see needs emerge that I feel could benefit from an approach that combines FHIR with openEHR, not an approach that is predicated on selecting one or the other. This is an evolution of some of the points I made in previous posts (FHIR vs openEHR pt1, and pt2), the headlines of which unfortunately add to the hype around these two standards being somehow competitive. My emerging view is that these are in fact two complementary standards, who as a whole are greater than the sum of their two respective parts . My talk (and this post) aim to outline why I think this is the case.

Before jumping in at the deep end it is worth setting some context and reflecting on the evolution and adoption of healthcare standards during my time working with Kainos.

/></figure> <p></p> <p></p> <p>When looking back at each of the transitions we made during the timeline above, we always embraced a new approach/standard/technology in response to a problem we needed to solve, not in response to a new shiny thing that everyone was talking about. In 2012 we adopted open REST API's to solve the problem of allowing external mobile applications to interface with our product. When we first adopted FHIR we did so in response to a set of interoperability needs we were working on. Now when we look to the future and consider the use of openEHR it is in response to finding a better way to solve a set of problems we are faced with. The key point is to select the approach/standard/technology that best meets your need. Don't identify everything as a nail, just because you have a hammer.</p> <p ><strong> FHIR Use Cases</strong></p> <p>Before considering the use case for FHIR + openEHR I reflected on the FHIR use cases I have implemented or observed over the last number of years, summarised in the slide below.</p> <figure ><img src=Thomas Beale in posts such as this.

Analytics and Business Intelligence ? Exploring data stored within databases is largely a solved problem. Business Analyst's have being using SQL for decades and there are a wide range of tools available that support this approach. When it comes to exploring healthcare data, many business analysts expect there to be a relational data model which can be explored using SQL. This is not unsurprising as the concepts modelled within a healthcare domain are largely relational (e.g. patients have encounters, encounters will have diagnosis(s) etc. etc.). Even if these concepts are implemented using non-relational technology, analysts typically expect to be able to explore or report on this data using traditional relational techniques. By default FHIR provides a set of REST APIs which can be used to explore the data, however the scope and flexibility of what you can explore is limited. This can be overcome by going below the API and querying the data directly. The challenge with this approach is that the data is most likely stored in a non-relational format, so you will have to use more complex and less understood SQL dialects to explore this data. You can overcome this in other ways but you get the point, there are a number steps to follow in order to expose a simple interface that can be quickly and easily used. When contrasted with openEHR, there is a native query language called AQL. It is not quite SQL (that would even better) but it provides an interface that is very close and with some training a person familiar with SQL should be able to pick it up easily**.

Versioning ? HL7 are trying to minimise the introduction of breaking changes as the FHIR standard evolves, but it is starting to become clear that this is not going to be possible across board. In the case of FHIR v4, breaking changes have been introduced, and in some cases the semantics of what is being modelled have also changed. An example is the AllergyIntolerance* resource where ??assertedDate?� has been changed to ??recordedDate?�. In this case it is not only the name that has changed, but the semantics of what is being modelled. This presents a challenge in all of my use cases, but when you are storing the data natively in the FHIR format it represents a greater challenge as you either have to migrate your data or introduce another translation layer. openEHR is more mature and is designed to embrace change. The base Reference Model provides the core set of generic base types and classes. On top of this the clinical Archetypes are modelled and then finally Templates are used to describe specific use cases. Importantly, only the Reference model is implemented in software creating a modelling environment that is more robust and adaptable to change.

FHIR + OpenEHR

To address these challenges we have the opportunity to combine FHIR and openEHR. The approach to this will be different for each use case. If we look back at each of the 3 models outlined earlier where does openEHR fit?

/></figure> <p></p> <p><strong>Exchange </strong>? as outlined earlier, FHIR works well in this model. If you are exchanging summary information between applications then keep using (or adopting) FHIR. A good example is Transfer of Care in the NHS where a summary of Inpatient, ED and Outpatient attendances need to be sent to the patients GP. FHIR is (in the process) of being adopted across the NHS to support this use case and is a great choice to address this need. If however you have a different use case and, for example, need to store a broad collection of complex datasets from a range of care settings then the robustness of openEHR will give you more control going forward. If adopting this approach my view is that writes should be performed directly against the openEHR API as opposed to performing these writes through another layer of abstraction such as a FHIR API. In doing so you will hopefully avoid introducing other problems as per the <a href=Law of Leaky Abstractions.

Facade ? in this model we have already added a FHIR API on top of an existing application. This is great and the first step towards making data more open and accessible (adhering to all necessary security and privacy controls). So, unless you want/need to change your underlying data model from its current format into the openEHR format there really is no place for openEHR here. Of course, if you are storing data in a closed and/or proprietary format then I would encourage you to review this position and consider how you could adopt a more open design. After all?�

??Data is for life, not just for one clinical system?�
?� Rachel Dunscombe, EY Healthcare Summit, 2019

Persistence ? This is the model that has the best place for openEHR. Similar to the Exchange model I would suggest performing writes natively against the openEHR API, especially when capturing rich or complex datasets. There may be some use cases where it makes sense to expose a FHIR API for writes (for example, receiving data from apps or wearables). This is absolutely fine. Go ahead and do this if it makes sense. Select the right tool for the job. However, when it comes to reads I would like to be more clear and suggest we should use FHIR for all reads, where at all possible. The reason for this is simple. FHIR is here to stay (IMO) and is continuing to increase in adoption worldwide. Companies ranging from the small boutique app developer through to the tech giants like Apple are using FHIR within their apps. The openEHR community need to embrace this, not resist it. In doing so the opportunity exists to help establish an even bigger eco-system of apps that can interact around a central openEHR platform.

Learns

Data is diverse ? We are still a long way of any kind of plug n' play interoperability, whether that is delivered through a collection of FHIR apps all using the same set of profiles to communicate, the creation of a central openEHR data platform that all source systems interact with, or a hybrid of both. The real world is one that contains lots of diversity. Data is often dirty, is not documented and is difficult to access. When you do get access to the data it typically still needs to be translated when being sent from A to B (as per model 1 above). When you are tasked with doing this translation the learn is clear ? this translation needs to be performed by domain experts, not technologists. You need to understand the meaning of the data in order to perform any kind of translation on it. This is why the adoption of openEHR is important as it presents the opportunity to capture the semanticsFH and context of the data at source, avoiding the need to perform complex translations.

More FHIR and openEHR translations please ? Before I delivered my talk at the openEHR event my view was that there was still a long way to go in maturing how we translate between FHIR and openEHR (necessary for models 1 and 3). However, since then I have spoken to a number of people who have not only been doing a-lot of great work in this area but have also open sourced it? a good example being Rob Tweed and his work on the QewdJS Jumper. This is fantastic and the more of this ??bottom-up?� work the better. However it would be even better if some of this was also driven ??top-down?�. It's great that InterOpen have helped curate the CareConnect FHIR profiles for the NHS but imagine if this work originated from openEHR Templates and by default we had published translations between the two standards. This is the sort of thing that people can really get behind and because it is ??top-down?� would carry a lot more weight, influence and visibility.

Get beyond the hype ? Standards are great, but as per the GDS Service Manual, always start with user needs and work back from the problem you are trying to solve. Too often I have seen procurements or projects that are based on a set of technical outputs, not business or user outcomes. The danger with this is you implement a thing, which maybe complies with a standard, but doesn't infact solve an entire user problem. What I have outlined in this post are a couple of models, but as with all patterns they are to be used as a baseline or blueprint of how to approach a particular kind of problem. They can be customised and reused but they do not represent the answer. The key point is to select the approach/standard/technology that best meets your need. Don't identify everything as a nail, just because you have a hammer.

Summary

/></figure> <p>*Credit to <a rel=John Meredith for pointing me in the direction of this example

**Note, I am not suggesting AQL will be the correct choice for all analytics use cases. There will be a number of use cases that may necesitate operating on the data in different ways.

About the author

Alastair Allen