By: Alex Baumberg & Uri Lerner, PhD
Note: this is a continually updating piece. Come back every couple of months for an update!
Background:
Over the last 20 years, healthcare has changed dramatically. In the past, it was hard to access important health information, which made it difficult for doctors to coordinate care and fully understand a patient’s medical history.
Thanks to advances in technology, we’ve made great strides in solving these issues. Today, new standards like HL7 and FHIR are helping to lower healthcare costs, improve the quality of care, and make it easier to share medical information securely. HL7 has introduced several standards for handling data, including versions V2, V3, and FHIR.
While FHIR is part of the HL7 family, it’s quite different from the other standards in how it works and what it offers.
What is, HL7® V2:
introduction to HL7 V2
Initially released in 1989, HL7® V2 became one of the most widely implemented healthcare standards globally. According to HL7®, 95 percent of U.S. healthcare organizations today use a version of this standard for daily operations to ensure that different systems, such as electronic health records (EHRs), laboratory information systems (LIS), and radiology information systems (RIS), can communicate effectively. This standard supports a wide array of clinical applications and helps healthcare providers streamline operations, reduce errors, and improve patient care by facilitating timely and accurate data exchange across various healthcare platforms. The HL7® V2 standard was designed to be highly customizable and flexible with a primary target of increasing interoperability between different IT systems and securing straightforward integration processes within the healthcare organization.
HL7 V2 Message Structure
The language standard is comprised of ASCII text-based messages containing segments and fields. The segment represents a group of fields associated with a specific logical type. Fields are populated with atomic values within each segment and separated by ‘|’ sign. The combination of segments comprises an HL7 V2 message, with the type dictated by a three-character code, which indicates the logical entity described by the message and triggered event.
Example of HL7 V2 Message
In the following example, we can see the ADT-A01 type message:
—————————————————————————————————————–
MSH|^~\&|EPICADT|DH|LABADT|DH|201301011226||ADT^A01|HL7MSG00001|P|2.3|
PID|||MRN12345^5^M11||APPLESEED^JOHN^A^III||19710101|M||C|1^DATICA STREET^^MADISON^WI^53005-1020|GL|(414)379-1212|(414)271-3434||S||MRN12345001^2^M10|123456789|987654^NC|
PV1|1|I|2000^2012^01||||004777^GOOD^SIDNEY^J.|||SUR||||ADM|A0|
—————————————————————————————————————-
Overview of ADT Messages and Key Segments in HL7 V2
The Admission, Discharge, Transfer (ADT) notification is commonly used to exchange the patient’s status within a healthcare facility. ADT messages are used to synchronize patient demographics, such as contact information, address, medical record number, insurance, next of kin, and visit information. The A01 indicates the triggered event – patient admit notification.
The Message Header (MSH): a mandatory segment that includes data about the sender and the recipient.
The Patient Identification (PID): includes demographic data of a specific patient (name, date of birth, location). This segment is also mandatory.
Patient Visit (PV1): includes information about patient visit details, such as time, visit ID, caregiver, and servicing facility.
Variability and Integration Challenges in HL7 V2
Despite the common segments definition across different HL7® V2 message types, the order and position of values within the specific segment are not always the same across different systems and strongly depend on the Schema Version, which in fact describes the message structure. Thus, the Medical Record Number (MRN) value in the example above is located within the PID segment, third position (PID3), valid just for HL7® V2 Schema Version 2.3 as defined in the message header segment.
Hence, the mandatory requirement for straightforward integration between IT systems is the identical Schema version; otherwise, schema conversion, including mappings and transformation, will be required to be applied on the target system. Due to the existence of various schema versions / sub-versions and the lack of one common standard, the interoperability process in many cases requires organizations to rely heavily on custom coding and interfaces engines to achieve interoperability.
Extensibility Limitations and Implementation Complexities
Besides, the extensibility mechanism aimed to add custom values to the standard messages in HL7® V2 suffers from a lack of semantic rules and the ability to understand the meaning without prior manual explanation by the sender. The extensibility in HL7® V2 is performed through the use of “Z-segments” populated with values according to the custom specification done by the sender application, introducing a complete lack of interoperability between source and target systems. And finally, HL7® V2 extensions are supposed to be restricted to data elements that do not affect the meaning of the “standard” segments.
Another complication, especially for developers and integrators, is the difficulty in understanding a message value meaning (messages are not self-describable) which requires comprehensive schema analysis as the first step of integration activities.
On the communication layer, the HL7® V2 standard supports a point-to-point message exchange between the source and target systems triggered by specific events in the source system. However, no one-to-many data exchange capabilities are supported, which reduces the interoperability on the organizational level.
To Summarize
The main limitations of the HL7® V2 standard are:
- Implicit information model, not explicit. Inconsistency across message types
- requires controlled vocabularies
- Limited to a single encoding syntax
- No explicit support for object technologies
- No explicit support for security functions
- Long implementation times
- No one-to-many data exchange capabilities are supported.
🔥🔥🔥🔥🔥🔥🔥🔥
What is HL7® FHIR®
Example
In the example below, you can see the extension defining the sex as assigned at birth (Birth Sex Extension) .The extension implementation guide and StructureDefinition resources are accessible using the extension URL:
“extension”:[
{
“url”:”http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex”,
“valueCode”:”M”
}
]
Mobile Apps
Advantages of FHIR for Mobile Health Apps
- Real-time Data Access: FHIR APIs facilitate real-time data access, which is essential for mobile health applications that depend on up-to-date patient information to provide timely care interventions. For instance, a mobile app can quickly retrieve a patient’s medication list from a hospital’s FHIR server to ensure that a prescribed treatment aligns with the existing medications, thereby preventing adverse drug interactions.
- Interoperability Across Systems: One of the most significant advantages of FHIR for mobile applications is its ability to integrate seamlessly with various health IT systems. This interoperability is crucial for developers who aim to create applications that can operate across different healthcare environments without needing significant reconfiguration.
- Enhanced User Experience: FHIR enables a more interactive and user-friendly experience on mobile devices. Developers can use FHIR APIs to pull in diverse types of health data (like laboratory results, medical histories, and treatment plans) and present it in a cohesive, easy-to-navigate interface. This capability is particularly important for patient-facing apps, where ease of use is critical.
Momentum of FHIR in Mobile Health
The momentum for FHIR in the mobile health landscape has been bolstered by initiatives like the SMART on FHIR project. Launched in 2014, SMART on FHIR has established a framework for developers to build apps that can be easily integrated and reused across different health systems. This project has led to the creation of a robust ecosystem of medical apps that can access data from any FHIR-enabled system, offering tools that providers can adapt to their specific needs without extensive customization.
Future Directions and Innovations
The future of FHIR in mobile health looks promising, with continuous enhancements to the standard and growing adoption among healthcare providers. Innovations are likely to focus on using machine learning algorithms with FHIR APIs to offer predictive insights directly through mobile devices, thus enhancing clinical decision-making. Additionally, there is a trend towards using FHIR in conjunction with wearable technologies to monitor patient health in real-time, providing a seamless flow of health data from individuals to healthcare providers.
In summary, FHIR’s compatibility with mobile technology not only supports the current needs of healthcare delivery but also paves the way for future advancements that will further transform patient care and health system operations.
To Summarize Thus far:
The main differences between HL7® V2 and HL7® FHIR® are detailed below:
| HL7® V2 |
HL7® FHIR® |
| Implicit information model, not explicit. Inconsistency across message types. Lack of standard approach to extensions management. | An explicit and hierarchical information model employs syntax and semantic interoperability between various implementations, standard approach and strict rules to resource extension. |
| Lack of message semantic validation capabilities. | Automatic resource validation against the profile previously specified and ingested into the FHIR server. |
| Limited to a single and flat encoding syntax (ASCII) | Supports a hierarchical data model approach by supporting XML, JSON, and RDF data formats |
| No one-to-many data exchange capabilities are supported | RESTful API approach enabling one-to-many data exchange capabilities by deploying FHIR server aggregating and managing organizational information and providing easy and standard data access and exchange, as well as SMART on FHIR support for mobile application |
| No explicit support for security functions | RESTful TLS (HTTPS)support – standard approach for secured data exchange |
| Long implementation times | The streamlined implementation provides easily understood specifications and enables developers to capitalize on common Web technologies. |
| Extensibility is not interoperable | Extensions are formally defined and can be recognized and re-used by different parties. |
HL7 V2 to FHIR Transformation
FHIR is becoming increasingly popular in healthcare ecosystems around the world, but many clinical systems still use HL7 V2. This has led to a growing need for HL7 V2 to FHIR transformation.
In this section, we will discuss the main points of HL7 V2 to FHIR transformation based on our experience.
Data structure
One of the fundamental differences between HL7 V2 and HL7 FHIR is the data structure. HL7 V2 messages are based on a traditional message-oriented structure, with each message containing multiple segments corresponding to specific data types. The combination of segments comprises an HL7 V2 message, with the type dictated by a three-character code, which indicates the logical entity described by the message and triggered event. For example, ADT_A01 defines a patient admit notification message comprised of mandatory and optional segments defined by specific HL7 V2 schema. This means each message may contain various information from patient demographic information, visit information defined as mandatory to background disease, insurance-related information, and others. Another example is the ORU message having various numbers of covered business cases related to observations, e.g., blood pressure, laboratory test results, pathology findings and others.
Here is a sample for such a message:
MSH|^~\&|1^Autolab^3.02|110^some_place|34^HL7_PDF|2400^HL7_PDF|20240726083203||ORU^R01|12345678|P|2.3||0^^||||||5||
PID|1234567||987654321^^^|1111111-1^^^^1|last name^^^^^|first name||F|||street 23 apt ^^^city^””^11111111^””^0^||0544444444||||||unit_short_name^unit_long_name||||||||||||0|0||||
ORC||2222222222^^^^^^^|||CM||||20240725154900|207^first^last^^^^||1234567^first^last|||||general^^^^||^|N|N|555555555|N^Y||403aa3gec5fb33efd666666cd45b1e5a|
NTE||O| Clinical_diagnosis:MDS|0|
OBR|1||33333333333^^^^^^^||||20240718195000||0^|^^auto^^^^||||20240718210300|0^^^^^^^||||||||||||^^0^^^^^^|||||||||||||||||0|4^green^^^^|1^Blood^^^^|
NTE|15151515|O|new_sample|1|
OBX|10|TX|0813321000^esccol^^^Escherichia coli^||.|0^””^^^^|^|N|||F|M|104^714^ Micro_lab|20240725154900|9999^Micro|1234567-8^First^last^^^^^||0|0^^^^^|^AutoComm^16^^^^^|9999^Micro^^^^|207^general^^^^||0810109809^genct^^^^||1|^system^routing^^^^^|20240725150000|^^|N|1111111111|2222222222|33333333333|
NTE|15471137|O|updated_result|1|
Unlike HL7 V2, FHIR is based on a resource-oriented model, where each message contains a single resource that represents a specific piece of healthcare information. The business meaning and context of each HL7 V2 segment are similar to the FHIR resource structure. For example, the OBX HL7 V2 segment contains observation results, which can be transformed into the FHIR Observation message, and OBR segment describes the order that led to those observation results, including specimen-related information, which can be transformed into a Specimen Resource. In addition, the entire HL7 V2 message can be represented as a Bundle resource with references between the Resources contained in the Bundle. For example, the Observation Blood Pressure result represented by the HL7 V2 message can be transformed into a Bundle containing the Patient (HL7 V2 PID segment), Specimen (OBR), and Observation resources (OBX) with references between them. In some specific cases, each HL7 V2 segment will contain data that can be represented by more than one FHIR resource.
Data Conformity
As previously discussed, HL7 V2 messages are very organization-specific. Due to the limited extensibility defined by the standard itself, understanding the data structure might be a challenge, especially when trying to map the different segments’ content to FHIR resources.
For example, when parsing the above HL7 V2 message (using https://hl7messageparser.azurewebsites.net/ for demonstration purposes only), we get the following interpretation (partial screenshot):
We can see that a large portion of the data is not understandable, lacking a description for the field within the different segments.
In this case, and many alike, some of the “unknown” fields contain crucial information. For example, field OBX.33 is a unique key, used to reference from a result to a given order or specimen, as elucidated in field OBR.3. similarly, OBR.46 not shown in this screenshot) contains code and value representing specimen type / material, in this case Blood sample.
Another issue arises from the way HL7 V2 message is constructed, i.e. row-by-row.
Looking at the above sample. NTE segments denote notes. The short message we show here, that contain one lab order, one specimen and only one result, have three separate notes within – one referring to the order (describing clinical background), the other referring to the specimen to show it Is a new sample, while the third refers to the lab result, having been updated. However, following HL7 V2 structure, (v2.3 in this case) – a unique key is not a defined part of NTE segments. Only the order of rows defines to which segment each note refers (one row above).
These two examples demonstrate one aspect of the challenge behind HL7 V2 to FHIR conversion. There are tools online that aim at this important transition, some claim for a “seamless” or “plug & play” solution, “out of the box”. Unfortunately, in most cases, this is not a feasible scenario. When dealing with HL7 V2 messages. especially with the more complex ones, it is very important to understand the structure (including out-of-scheme fields) and relations between the different segments prior to the actual step of detailed mapping, segmentsàresources.
Data exchange approach
Another fundamental aspect affecting the transformation from HL7 V2 to FHIR is the data exchange approach. HL7 V2 is a point-to-point, event-based protocol. The message is then structured accordingly, versus the RESTful API approach defined by the FHIR standard, enabling one-to-many data exchange capabilities by deploying a FHIR server aggregating and managing organizational information. In practice, the HL7 V2 message contains a complete data structure needed for event triggering. For example, an ORU message, containing blood pressure results will always keep patient-related information (PID segment) even if the target system previously received this info in the context of another event (e.g., Admit Patient to the hospital). In the FHIR ecosystem, the FHIR client will send the Observation resource with reference to the Patient stored in the organizational FHIR Server. The main question comes up from the differences described above: should FHIR reflect Patient Information during the transformation by converting the PID segment to a Patient resource, or ignore Resource creation and create a reference based on the identifier\id populated into the PID segment? Furthermore, the target system receiving HL7 V2 messages may be configured to trigger Patient Update on every message type received, which means the event definition for each of HL7 V2 message type is flexible. In this scenario, the Patient resources will be created as a result of PID segment transformation, and updates will be done using standard Bundle interactions, such as Conditional Updates.
🔥🔥🔥🔥🔥🔥🔥🔥
Conclusion
The transformation rules for HL7 V2 message conversion to FHIR Bundles vary between different workflows and business rules/events. Said rules should be defined by a data analyst prior to implementation, as it is a complex transformation that should be handled with care. The analyst must be well versed in both FHIR and V2, as the differences can be stark. A clinical/business expert is also a crucial part of the process from its initial effort, especially when there is no complete documentation of the organizational use and extension from the basic data model.
