Health Level 7: in search of increasing the interoperability of medical data

9 May 2022

6 mins read

Matylda Chmielewska

Business Researcher

The healthcare sector may be one of the most technologically advanced industries for obvious reasons – it is focused on saving human lives, but it comes at a price and has a unique set of challenges. One such challenge is storing, managing and sharing medical data in a way that’s accessible and secure.

In this blog post, I’ll focus on how this challenge was addressed by Health Level 7, the medical data standard that’s now widely used in the US and whether it is successful in achieving that. The article was prepared in collaboration with Lukasz Sliwowski, an HL7 expert and Principal Business Analyst at Spyrosoft.

If you want to know more about the changes in the EU healthcare industry regulations, please read our series on Medical Device Regulation.

What is Health Level 7

Health Level 7 is a set of healthcare sector norms aimed at standardising how medical data is shared and transferred within the medical system. It was created by the Health Level Seven International, a global organisation with over 1600 members from 50 countries, including the largest healthcare providers in the US – for more information on the origin of these guidelines, please visit the relevant section on the history of HL7 below.

Currently, in addition to the Health Level 7 v1 standard, there are Health Level 7 v2 and Health Level 7 v3 standards that are currently used in most of the large hospitals in the US with a certified system class called EHR (Electronic Health Record) used for managing patients’ data.

The history of HL7

Back in the 80’s all of these hospitals started to digitalise their medical data with sometimes a hundred different systems implemented at one hospital at the same time. This created the problem of how to integrate these systems or exchange data between them. Without any universal standard for medical data, it was extremely difficult, especially when patients used several healthcare services at once.

To address that problem, Health Level 7 v1 was created to serve as a Proof of Concept to show how medical data can be shared. Then, Health Level 7 v2 was a more mature iteration that has been the most popular medical standard in the US. HL7 2 was created by IT clinicians – so people deeply involved in the operations of hospitals and who know exactly how the system works. Their idea for this standard and the integration was for it to be following the organic flow of patients’ data in the healthcare data management systems.

They also decided that the data needs to be human-readable yet easily transferable between different systems. In HL7 v2, medical data are exchanged through ‘messages’. Each message consists of multiple segments that include a specific type of data, i.e. the dates of the patient’s visits to the hospital, their age, their place of birth and name, etc. For example, general patient data are sent using “PID” segment, while patient visits are stored in PV1 segment.

Please see this example ‘message’ to see how it may look like:

Source: http://sil-asia.org/exploring-hl7-standards/

While HL7 v2 has unified the terms used by system integration teams and allowed them to focus on actual problems rather than naming, which sped up the integration process, integration projects can still last months at a time. Parsing this data when transferring it from one system to another is also still a challenge. We can safely say that HL7 v2 was not successful in dealing with the most common medical data management issues, but it can now serve as a baseline for the next iterations of this and other standards.

Despite that, HL7 v2 has quickly become the most widely used medical data system in the US.

According to Lukasz Sliwowski, during any type of data integration, customising it to the hospital’s needs will be crucial as each company has a slightly or completely different setup.

In 2015, the HL 7 released a new standard called HL7 v3, but the adoption rate is very low, mainly because of its complexity. – the guidelines themselves have over 900 pages.

Eventually – in 2015 – American Senate started looking at the topic of interoperability of medical data and issued an act that forced medical software companies to make their systems more accessible and easily integrated with different data management systems.

While HL7 itself may have not addressed all issues related to the interoperability of medical data, it most definitely laid the groundwork for FHIR, and it’s now being implemented in the majority of US hospitals.

In 2022, US Senate has begun working on 21st Century Cures Act that will force hospitals to use FHIR starting this year, with 2023 the deadline for all medical systems to operate according to this standard.

What are the benefits of using HL7

As you may already be aware, some of the assumptions made in the HL7 v2 might have posed a bigger challenge than expected, but some of the commonly agreed benefits of using this standard in medical practise include:

Increasing accessibility and interoperability of medical data and setting a standard for how this type of data should be stored and shared.
Improving clinical efficiency due to a unified way to manage patients’ data and storing all information about a patient in one place.

How do we approach Health Level 7 integration projects at Spyrosoft?

Our first question is always: ‘Why do you want to integrate and what do you want to achieve by doing that?’

Then we meet with the hospital’s IT team and discuss what version of Health Level 7 they are using and what exceptions/special issues do we need to accommodate for.

Once we know what data we need to use, we need to access their sandbox environment to start the integration process. Then, we check whether we can correctly parse all messages.

Another solution that we may employ is an integration engine that serves as a middle layer between our interface and a customer’s interface with the data exiting the customer’s system in a HL7 v2 format and processed within the engine. What we get are raw data that are easily transferable to any format, i.e. JSON and .xml. We can then send this data to any system, including FHIR.