Explanation of HL7v2 ADT (ELI5)
In previous blogs we have explored overall HL7 healthcare data structures, and a detailed analysis of HL7 v4 (FHIR) data. In this article, we will go back in time and look at HL7v2, also interchangeably called ADT. It is the first digitally standard of healthcare data adopted globally (HL7v1 was purely experimental) created in 1989. It is still used today.
As usual, some bullet points to get everyone on-track:
“ADT” stands for Admit Discharge Transfer. A single ADT message describes a single patient action and the information surrounding it. An ADT message cannot describe multiple hospital visits, otherwise it would be more than one message. The HL7 global standards committee knew that tracking and exchanging information on patients would be the first digital use case of electronic health data, so the HL7v2 standard was heavily built around this to start. While the aim of HL7v2 is to do this, they also slipped in the opportunity to include plenty of patient information.
ADT messages are strings of text. They are often stored as “.hl7“, “.txt“ or “.dat“ text files. They are encoded in a method unique to HL7v2 called “ER7“ (Encoding Rules 7). There are zero specifications about how they are transferred and how they should be stored. Here is an example:
ADT messages are still regularly used for healthcare operations! You might think that old versions of HL7 would no longer be used, but versions 2, 3, and 4 are all used for different purposes, even though they are loosely capable of the same tasks. The patient tracking aspect of HL7v2, and it’s stable existence over a long period of time has made it very valuable and highly utilized. The long term plan, whether or not it happens, is for everything to be done on FHIR v4.
HL7v2 failed in many ways! The variability of healthcare data over time has permitted more “loose“ standards that allow customizations. For example, HL7v3 and HL7v4 allow the attaching of generalized data. HL7v4 allows a user to even add custom fields, like hair color for example, if they want to. The rigid HL7v2 did not easily permit this, and ultimately was not able to be used to fully describe unique healthcare datasets. It also couldn’t handle wider use cases in healthcare directly like HL7v4 can.
HL7v2 also failed at narrowly referencing other coding systems. HL7v3 uses OIDs (e.g. 2.16.840.1.113883.6.238 for race) and HL7v4 uses URLs (e.g. http://terminology.hl7.org/CodeSystem/v3-Race). HL7 simply has a text field for this and does not specify how to reference external coding systems used all over healthcare data - a spot for OIDs does exist but is rarely used and not required.
Yes, there are multiple versions. v2.5.1 is the most commonly used version. v2.1 is the earliest and v2.8 is the most recent. More recent versions often have more fields to place data in. They also have differences in required data, datatypes, data field names, and in rare instances data field structures.
Structure
ADT messages have 3 levels: Triggers, Segments, and Fields. The diagram below roughly shows the relationship between Triggers and Segments in a payload.
Triggers: These are the “reason for the message“. The most common ones have lower numbers. The list below is for v2.5.1. There are other uncommon message types not shown here such as Order Message (“ORM“), “Unsolicited Transmission Of An Observation Message (“ORU”) and Pharmacy/treatment Administration Message (“RAS”).
Segments: Each Trigger has a specified number of segments that can come with it. Some are optional and some are required, depending on the Trigger type. The below are the segments for an A01 Admit a Patient Trigger on v2.5.1. Note that only a few segments are required.
A single ADT message can sometimes have multiple of the same type of segment. For example, a A01 ADT message is permitted to have multiple DG1 (diagnosis) segments.
Fields: Each segment, like PID shown below, has fields, some of which are required whenever the segment is present.
Additional Specification
Beyond the overall data structure, HL7v2 also specifies how data is structured and validated. Each Field, such as those shown for PID, have a datatype. ST = String Data. XAD = Extended Address.
Tables are also predefined for SOME fields. As discussed earlier, this is not the case for large and maintained coding systems, but it is for generalized information like Administrative Sex (0001), Patient Class (0004), and Race (0005). The Administrative Sex table (0001) looks like the following:
A Ambiguous F Female M Male N Not applicable O Other U UnknownParsing and Converting an ADT Message
The highly unique structure of ADT messages makes them a pain to parse. Fortunately many people have already done this and there are a few options to choose from if not building a custom solution:
HL7v2 Documentation: Full documentation may be found here on how each version of HL7v2.
HL7v2 Interactive Website: A well organized website that has trigger events, segments, data types, and tables for each standard displayed in an interactive way. It even has version selection so you may view what it looks like in each sub-version of HL7v2.
Inspector: A tool web tool for analyzing ADT messages in a simple way.
HL7apy: A python package for creating, parsing, and validating ADT HL7v2 messages. This package can also be used to transform a message structure into a dictionary and list-type structure like a JSON. Simply install with pip install hl7apy. It also includes information on each individual version of HL7v2. It is not affiliated with HL7.
HAPI: A java package for creating, parsing and validating HL7v2 messages. It is not affiliated with HL7.
HL7 version 2 to FHIR mappings: HL7 has defined how to properly map version 2 to FHIR on their website.
Code for HL7 to FHIR conversion: This is a JAVA for parsing and converting the data with the previously mentioned mappings, created and endorsed by HL7.
Tenasol: As a regular part of our services, we can extract and represent ADT message information for any use case. Some examples of this include the TRC (Transitions of Care) HEDIS measure for quality, as well as for prior authorization, disability, and risk operations.
Conclusion
In summary, effectively parsing ADT HL7v2 messages is crucial for healthcare organizations to ensure accurate data exchange and maintain high-quality patient care. Utilizing established tools can significantly simplify this complex process, allowing for the transformation of intricate message structures into manageable formats that are easier to interpret and analyze. Additionally, the ability to map HL7v2 to FHIR enhances interoperability across diverse healthcare systems, facilitating seamless communication and integration. Leveraging services like Tenasol can further streamline the extraction and representation of ADT information for various use cases, including the TRC HEDIS measure, ultimately contributing to improved patient outcomes and operational efficiency in healthcare settings. This leads to better resource allocation and timely patient care. Get in touch today so we can see how we can help you achieve these critical goals!