FHIR agility: HL7 is dead, long live HL7!

FHIRworks Series: The barriers for sharing documentation and data in healthcare are breaking down, helped by standardization, digital technologies and collaborationIn this blog series we will focus on the use of HL7 FHIR in the real-world, and how it can be used to drive further adoption and innovation in Healthcare. This is the third blog in the series.

The excitement over HL7 FHIR (Fast Healthcare Interoperability Resources) might be causing us to throw the baby out with the bathwater. Undoubtedly, health integration is a primary objective, but there is no need to abandon the thousands of interfaces in our landscape that work every day delivering results to clinical systems, or admission messages to hospital food management systems. Each of these needs to continue to run while we think about our new approach to HL7. Furthermore, replacing all our existing interfaces with FHIR is difficult and means retesting every interaction in our ecosystem.

Today, instead of sending thousands of data packets around the organisation in a data avalanche, healthcare is embracing methods that allow data to be published and clients to subscribe only to the data they need. This transformation in how data and information is shared and used is changing for reasons other than having a new standard. It is being driven by changing factors in healthcare, including:

  • An increasing need to involve patients (and their carers) more actively in their own care
  • A growing number of network-connected devices within the hospital assessing each patient’s health attributes
  • Greater use of their own internet-connected devices by consumers to manage and monitor their health and well-being

With these changes in mind, we can start to think about reshaping our digital transformation for interoperability – not by changing a set of existing HL7 version 2 message interfaces with corresponding FHIR versions, but by looking at how challenges are being addressed using these new patterns.

One challenge that I see regularly is the need for practitioners to see a list of appointments for a patient on a mobile app, and then providing additional information to the patient for his or her appointment. In an HL7 v2 message pattern this can be difficult because app developers don’t really understand HL7. This is where FHIR comes in, allowing developers to use the knowledge they have in XML and JSON formats to build beautiful apps with the data that we have locked up in our systems.

From this vantage point, we can design a set of FHIR resources that we might need, such as appointment, and think about how we deliver this capability. This is a simpler and less intrusive way of addressing a problem, rather than changing one interface, which can have a detrimental effect on all the downstream systems, requiring developers to look into what additional system testing needs to be performed, and which key stakeholders need to be brought in to work on that project.

By taking a softer approach, we can try to identify the systems that contain this appointment data, determine how to gain access to it, and then decide how we can provide this in an HL7 FHIR format for consumption by a mobile app. One method is to query the data based on FHIR requests and respond with the list of appointments; another is to bring the data into a repository in a FHIR format and then simply serve it up when asked for it. Note: When I say “to query the data” I mean that we wouldn’t hook directly into the production database due to security concerns, so we want to ensure that this is included in our understanding of the problem and how we solve it.

Now that we have an area of interoperability that is separated from existing system integration challenges, we can work to implement this through agile delivery techniques. We can start with getting the data from one system, presenting it on our app, and then moving on to add in the next system. In this way, we can start to expand the capability of our application delivered to our end users, who may be patients, without disrupting the entire interface.


Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.