Interoperability with Open Standards Let’s Kindle a Debate about FHIR

Interoperability with Open Standards: Let’s Kindle a Debate about FHIR

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.

But 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.