Interoperability with open standards: let’s kindle a discussion about FHIR
- 1 June 2022
The future of healthcare systems may be open, but how are we going to get there? asks Vivek Krishnan, chief technology officer at Alcidion Group. There’s no doubt that OpenEHR and FHIR will both have a role to play, however, the UK seems to be focusing on OpenEHR – when FHIR has a lot to offer trusts and suppliers.
The future of healthcare systems lies in open standards that free data from traditional, stand-alone silos and make it available to the many applications that need it. But how are we going to reach that future?
Realistically, we have two options: open Electronic Health Record, better known as openEHR and Fast Healthcare Interoperability Resources, or FHIR. I’m not going to argue that one is better than the other. They both have advantages and disadvantages and they will both have a role to play in the digitisation of the NHS.
However, it sometimes feels like openEHR has become the focus of attention in the UK and I’d like to see more debate about the role of FHIR and open platform architectures that use FHIR to natively extract, store and re-export data to applications.
This is the model that Alcidion uses in its Miya Precision platform, and I assert that it has some benefits for innovative suppliers, trusts and Integrated Care Systems.
OpenEHR and FHIR
OpenEHR and FHIR both aim to address a long-standing problem in healthcare, which is that conventional healthcare systems tend not to share information – to interoperate – with each other.
Conceptually the most important difference between them is that openEHR uses multi-level modelling while FHIR adopts an 80/20 rule. In other words, openEHR operates with a stable reference information model, that sets out to capture every use case for data in the medical world and archetypes and templates that enable it to be used and re-used in the real-world.
While FHIR is built from discrete resources that cover 80% of the data elements that are used in existing healthcare systems. This leaves the remaining 20% for specific use cases that can be customised, extended and handled by FHIR profiles.
The obvious attraction of openEHR is that it paves the way for disparate systems to operate to a pre-determined standard thus claiming ultimate interoperability. It also allows organisations to build a stable representation of their data and to use it to build and manage their own healthcare system from the ground-up.
However, openEHR requires a strong commitment from organisations and clinicians to maintain and extend the underlying model, while the need for the whole openEHR community to move forward together can make it difficult to implement localised changes.
FHIR is less grand in scope and is a lot easier to use. Indeed, FHIR resources were built to make it easy to integrate disparate systems. They are easy to understand and to transmit over well-understood network protocols and modern, web-based technologies.
This makes it easier for suppliers to build applications that can ‘plug and play’ with other systems and for trusts and ICS’s to adopt them to deliver the changes that matter most to them.
FHIR: not ‘just’ a messaging standard
So, why isn’t there more discussion of the role of FHIR in UK healthcare? I think one issue is that FHIR is often catalogued as a ‘messaging standard’ when it is far more than that.
FHIR resources represent generic clinical data models and templates containing data elements for different types of clinical and administrative functions in healthcare settings. There are approximately 150 FHIR resources for concepts such as ‘patients’, ‘encounters’, ‘observations’, ‘medicines’, ‘allergies’ and so on.
All of these are actively developed and nurtured by the HL7 Organisation, so they can be used as a model to store data as well as to exchange data. This means it is possible to use FHIR as the basis of an open platform architecture; one in which data is extracted, stored and re-exported as native FHIR messages.
Alcidion was an early adopter of FHIR and our Miya Precision platform is unique in using this model. In passing, it means we separate the data layer from the application layer, which is what the UK government, NHS England, and the transformation directorate that has absorbed NHSX, say they want to do.
Benefits of FHIR thinking
There are some significant benefits to adopting FHIR thinking. One is that it works well for the microservices architecture approach that Alcidion has also embraced for Miya Precision. Because FHIR supports RESTful architecture and modern web standards, it’s possible to create business-focused applications that can be deployed at speed, while remaining highly configurable.
Native FHIR data extract, storage and re-export also offers significant benefits when it is used to power an event bus that orchestrates communication between different micro-services and applications. The data store in the Miya Precision platform is constantly being updated with information and analysed in real-time for variations in a patient’s condition.
This enables alerts to be sent to Alcidion’s suite of mobile first applications to improve patient safety (Miya Observations) and operational efficiency (Miya Flow). In effect, it not only separates the data layer from the application layer but makes the data layer active and useful.
At the same time, the universal event bus makes it easier for new and innovative suppliers to join a trust ecosystem; without having to interact with the API layer or facade that traditional vendors put over their systems or adopt the entirety of the openEHR conceptual framework.
This last point should appeal to forward thinking trusts and ICSs. If you want to store information from disparate systems at an ICS level and to use it in new pathway apps and analysis, without going ‘full openEHR’, you should be thinking about doing it in FHIR native format, so you get mature interoperability from the outset.
Let’s FHIR up a debate
The NHS needs innovation and it needs to adopt approaches that will allow it to reach that open future in order to make the most of it. That means there’s a big market out there and plenty of scope for both openEHR and FHIR to demonstrate their value.
It also means we shouldn’t let a single philosophy of open standards drive our product engineering. Instead, we should remain focused on what we all want to achieve, which is not just a longitudinal health record, but one that helps clinicians to focus on patient safety, patient care, and patient satisfaction.
I think that means we need to kindle that conversation about FHIR, because FHIR can lead us to the point at which, as a colleague of mine puts it, we’re doing ‘the cool stuff’ – faster.
Contact Alcidion:
Web: https://alcidion.uk/
Email: marketing@alcidion.com
6 Comments
A bit of background here: FHIR compared to openEHR – https://wolandscat.net/2017/01/29/fhir-compared-to-openehr/
The biggest problem in NHS IT is silo mentality. Systems do not interoperate except in circumstances that are rare and after a well-directed effort. I was around in the early 1980s when clinical labs in each NHS region were all coerced into buying the same systems (HW, SW etc). It came as a shock when they did not interoperate, because no-one required them use the same coding schemes. The reason why GP2GP works is because different practices use the same sets of codes and where there are differences, there are mappings between different schemes.
FHIR (Release 4 and onwards) has learnt all the major lessons of the past and supports data interchange via APIs. messages, documents and Webhooks. If you can exchange data without loss you get persistance, although, as Ewan said, FHIR was not designed for native use in systems. FHIR is relatively young – it has been led by Grahame Grieve in Melbourne and FHIR R4 came out in 2019. FHIR has now been endorsed by every country in the World that has examined the problem in detail. Not to adopt FHIR R4 for interoperability is a very odd form of xenophobia.
I don’t think anyone is suggesting not adopting FHIR for interoperability between heterogeneous systems, It’s clearly the best tool for the job.
However, if you want an open vendor and technology neutral standard for the persistence and querying of data openEHR is the only show in town that’s been proven to work at scale.
Both openEHR and FHIR require a massive effort to model content with perhaps 10,000 bits of content (FHIR Profiles or openEHR archetypes) to cover the whole of health and social care. If you want to do this modelling once for both the only option is to use openEHR to do the modelling as its maximal data set approach to creating archetypes allows it cover all of the data elements needed in a FHIR profile, while the reverse is not true. Add to this that tooling already exists to automatically create FHIR observation profiles ( a bit part of the challenge) from openEHR templates and it becomes even more attractive to model with openEHR.
Making this happens requires some modest technical changes to align fully align datatypes and a will to work together. Sadly the existential threat that open platforms and openEHR represent to the established vendors, who rely on data lock in to lock their customers in, means that there is a lack of willingness from some to cooperate.
Agree with Ewan.
One of the problems here is the use of the term interoperability, here I’m presuming the CCIO/clinical version which is probably how to structure medical records.
As an interop developer I don’t really mind how that is done but on the wire between systems and clinicians in different organisations what I’m after is RESTful, JSON, open shared apis (not ye old traditional message/data dumps), HL7 FHIR R4 (or HL7 v2 if it’s already developed), OpenId for authentication and OAuth2 for authorisation.
What’s really happening on the ground is we are still stuck with a very large number of fax like document exchanges. We are still largely unstructured, openEHR does a lot to tackle that (the recording of data in an EPR) and FHIR (the exchange of data) can enable the sharing of this structured data quite easily.
Have a look at this for a better informed view of FHIR and openEHR
https://medium.com/@alastairallen/fhir-openehr-2022-53716f837340
To present FHIR and openEHR as competing alternatives is to present a false dichotomy. Both have a role, often working together.
HL7 FHIR was designed for the exchange of data between heterogeneous systems via APIs, messaging or as documents. It was not designed for the persistence of data.
openEHR provides a methodology for defining and curating clinical content and
a specification of clinical data repository with an open API and query language that allows openEHR content to be stored and queried. It’s designed to support persistence with built in support for versioning and audit.
It’s possible to use FHIR to persist data or to use openEHR as the common format for the exchange of data between heterogeneous, just as it is possible to hammer in a screw, but neither is a great idea.
In practice if you want to exchange data between heterogeneous systems, including those built with openEHR then FHIR is the best choice. If you want to create an open platform ecosystem based on common data specifications then openEHR is the proven solution.
Comments are closed.