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, shall we? 

What are HL7 Messages? 

HL7 messages are used to transfer data electronically between various healthcare providers. Think of it as a special language healthcare systems use to talk to each other. These messages are sent whenever an event happens with a patient, such as admitting them to the hospital or ordering them a prescription. HL7 messages are made up of segments in a specific sequence, but some of those segments aren’t required every time and sometimes they’re even repeatable. 

Components of an HL7 Message

  • 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

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

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.

Message Delimiters

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, subcomponent separator, repetition separator, field separator, and 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 as well as merging of patient data and more.

Orders (ORM)

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.

Results (ORU)

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.)

Charges (DFT)

A DFT message describes a financial transaction transmitted between systems and is used for patient accounting purposes (and so that claims can be generated). Trigger events for a DFT message include procedure 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 option 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. 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.