Health Level Seven (also known as “HL7”) is a set of international standards, rules, and definitions used to exchange and transfer medical information between healthcare providers through electronic health records (EHRs). You can learn more about what HL7 is in our article on the subject, but there’s a bit of a difference between knowing what something is and how to use it.
In this article, we’ll be giving you a bit of an HL7 tutorial by covering some of the most common HL7 messages as well as how you’d use them. Let’s dive in!
What are HL7 Messages?
HL7 messages are used to transfer data electronically between various healthcare providers and are sent whenever an event happens with a patient, such as admitting them to the hospital or ordering them a prescription.
Some common HL7 message segments include:
- ACK (General Acknowledgement)
- ADT (Admit, Discharge, Transfer)
- DFT (Detailed Financial Transaction)
- ORU (Observation Result Unsolicited)
- BAR (Add/Change Billing Account)
Components of an HL7 Message
Think of HL7 as a unique language healthcare systems use to talk to each other…
HL7 messages (or transactions) consist of a number of components in a specific sequence. An HL7 message is a unit of data that can be transferred between different systems. It is comprised of a group of segments in a particular sequence.
Each message type has a different purpose. For example, an ADT Message type is commonly used to transmit different parts of a patient’s Patient Administration (ADT) data from one system to another. A three-character code contained within each message identifies what its type is.
The exchange of messages between systems is initiated when a real-world event (trigger event) occurs, such as a patient being admitted.
Segments consist of the logical grouping of data fields. They tend to occur only once or repeat in a given message. Segments can either be required or optional. Each segment is given a name for simple reference. For example, an ADT message might include segments such as:
- Message Header (MSH)
- Event Type (EVN)
- Patient ID (PID)
- Patient Visit (PV1)
Segments are easily identifiable by their unique three-character codes, called Segment IDs.
Fields are made up of a string of characters and also appear as such once they have been transmitted. HL7 data fields can take on a null value, except where noted. Sending a null value is different from omitting an optional data field. The difference is notable when the contents of a message are used to update a record in a database, as opposed to creating a new one. If no value is sent the old value should remain unchanged. If the null value is sent, the old value should be changed to that null value.
Data field characteristics:
- Position: The ordinal position or sequence of the data field within the segment.
- Maximum Length: Maximum number of characters that one occurrence of the data field can occupy.
- Type of Data: Restrictions on the contents of the data field.
- Optionality: Whether the field is required, optional, or conditional in a segment.
- Repetition: Whether the field might or might not repeat, or the number of times the field can repeat.
- Table: The manner in which HL7 defines the valid values for tables varies depending on the institution, data type, reference, etc.
- ID Number: Small integer that uniquely identifies the data field throughout the Standard.
- Name: Descriptive name for the specific field.
In HL7 messaging, the separator characters are known as the message delimiters or encoding characters. They are the specific predefined characters used to define the beginning and end of a message component. These include the segment terminator, the component separator, the subcomponent separator, the repetition separator, the field separator, and the escape character.
Escape Sequences in Text
HL7 defines character sequences to represent ’special’ characters not otherwise permitted in HL7 messages. These sequences typically begin and end with the message’s Escape character and contain an identifying character, followed by 0 or more additional characters.
HL7 Message Types
Every transaction uses a certain HL7 message type to explain why you’re sending that specific message. These message types have a code of three characters and a trigger event. What’s a trigger event? Great question. A trigger event is a real-life event that starts the communication needed for a message. Both the message type and trigger event are found in the MSH-9 field of the message—let’s take ADT-A03 as an example. “ADT” is the message type, and “A03” is the trigger event. This is known in HL7 Standard as a “patient discharge” message.
There are over 80 HL7 message types, not to mention all sorts of other segments and codes for pretty much everything and anything you can think of. For the sake of brevity, let’s go over four of the most commonly used kinds.
- ADT – Patient Administration
- ORM – Orders
- ORU – Results
- DFT – Charges
Most Common Types of HL7 Messages and How to Use Them
Patient Administration (ADT)
ADT is one of the most common HL7 message types because it covers a lot of use cases, including patient admissions, discharges, transfers, merging of patient data, and more.
ORM is a general order message that’s used to transmit information about an order, which could be anything from placing a new order, canceling an order, discontinuation, and so forth. Trigger events for this message deal with any changes to an order, so whenever an order is created, canceled, or modified, you’d use an ORM message.
You’ll usually use ORU in response to an order to provide clinical observations. Types of observations reported in an ORU message include imaging study reports, clinical lab results, EKG pulmonary functions study results, or patient conditions (such as vital signs, symptoms, notes, etc.)
A DFT message describes a financial transaction transmitted between systems and is used for patient accounting purposes (so that claims can be generated). Trigger events for a DFT message include procedures ordered, scheduled, or completed.
Partnering with HL7 Experts
As you can see, these are just a handful of the many, many, many variations of HL7 messages you can use. Folks in the healthcare industry sometimes refer to the HL7 messaging standard (somewhat dubiously) as the “non-standard standard” because it is a standard that healthcare organizations need to adhere to, but the way they implement this framework can be different.
Add in the new options and features that come out with every upgraded version of HL7, and things get even more complicated. But if you’re looking to implement a new solution or solve integration issues in your healthcare facility, you don’t have to go it alone. That’s where our team at Surety Systems comes in to help.
Getting Started with Us
By partnering with someone who can tackle your unique challenges and ensure you’re in compliance with HL7 standards, you can look forward to some smooth sailing. Surety Systems, for example, has a wide network of senior-level healthcare interoperability consultants who can tackle just about any EHR system or platform.
To get started on your healthcare IT project, contact us today!