Health Level Seven (HL7)

What is Health Level Seven?

The Health Level Seven (HL7) organization is an ANSI accredited Standards Developing Organization. Volunteers
from around the world gather in quarterly meetings called HL7 Working Groups. During these HL7 Working Group
meetings, volunteers work to refine, gain consensus, and produce documentation that describes how clinical
information will be exchanged between disparate healthcare applications.

What is the HL7 standard?

Practically speaking, HL7 is the standard to which healthcare application vendors adhere when developing
application interfaces to exchange patient data. The HL7 standard defines a method of moving clinical data between
independent medical applications in near real time.
As Chapter 1 of the HL7 Version 2.3 states, “HL7 provides a common framework for implementing interfaces
between disparate vendors”. The HL7 standard is intentionally flexible.
HL7 is the acknowledged healthcare industry standard and the best protocol available to date for exchanging clinical
data among disparate healthcare systems.
Read about the different HL7 standard versions or visit HL7Standards.com, our healthcare integration resource
community site.

WHAT ARE THE HL7 MESSAGE TYPES?

HL7 terms to better understand what is HL7. There are four primary HL7 standard
message types:
 Patient Administration (ADT)
 Orders (ORMs)
 Results (ORUs)
 Charges (DFTs)

WHAT IS AN ORU MESSAGE?

HL7 terms to better understand what is HL7. In the HL7 Standard, an Observation Result
(ORU) is usually in response to an order and provides clinical observations.
In HL7 messaging, ORU messages provide structured patient-oriented clinical data between
systems (e.g., EKG results to a physician’s office). ORU messages also can be used for linking
orders and results to clinical trials (e.g., new drugs or new devices).

Clinical observations can include:

  Clinical laboratory results
 Imaging studies (i.e., text)
 EKG pulmonary function studies
 Interpretation

WHAT IS AN ADT MESSAGE?

HL7 terms to better understand what is HL7. Patient Administration (ADT) messages are
used to exchange the patient state within a healthcare facility. ADT messages keep patient
demographic and visit information synchronized across healthcare systems.
ADT is the most commonly used HL7 messaging type, with most clinical applications enabled to
receive key ADT messages.

ADT messages within the HL7 standard are typically initiated by the Hospital Information
Systems (HIS), or a registration application, to inform ancillary systems that a patient has been
admitted, discharged, transferred, merged, that other demographic data about the patient has
changed (name, insurance, next of kin, etc.) or that some visit information has changed (patient
location, attending doctor, etc.).

HL7 ADT – Admit Discharge Transfer

ADT messages carry patient demographic information for HL7 communications but also provide important information
about trigger events (such as patient admit, discharge, transfer, registration, etc.). Some of the most important
segments in the ADT message are the PID (Patient Identification) segment, the PV1 (Patient Visit) segment, and
occasionally the IN1 (Insurance) segment. ADT messages are extremely common in HL7 processing and are among
the most widely used of all message types.
There are 51 different types of ADT messages that are used for various trigger events. Some of the most commonly
used ADT messages include:
 ADT-A01 – patient admit
 ADT-A02 – patient transfer
 ADT-A03 – patient discharge
 ADT-A04 – patient registration
 ADT-A05 – patient pre-admission
 ADT-A08 – patient information update
 ADT-A11 – cancel patient admit
 ADT-A12 – cancel patient transfer
 ADT-A13 – cancel patient discharge
 
ADT messages are important in HL7 communications because they provide vital data about the patient and why the
message is being sent. Trigger events are instrumental in driving message flow, because they determine when and
where messages go based on the type of event that has occurred.
For instance, an ADT-A01 (patient admit) message might be sent to an Emergency Department system while an
ADT-A04 (patient registration) message might be sent to an HIS system. The level of urgency and pace at which the
message is transmitted might also be different depending on the trigger event.
Additional information can be found on the HL7 Standards resource site or visit the Corepoint Health blog for
additional insights and observations on healthcare IT news.

HL7 Batch File Protocol

HL7 batch files allow one or more messages to be sent in a single file, using specialized segments in a structure that
mirrors HL7 defined message types. These segments include the batch header segment (BHS), batch trailer segment
(BTS), file header segment (FHS) and file trailer segment (FTS). HL7 batching is useful for systems that are not
connected via real-time transmission protocols (such as those systems that do not transmit via TCP/IP connections).
The HL7 Standard specifies the following format for batch files:
[FHS] (file header)

{ [BHS] (batch header)

{ [MSH (HL7 messages)

....

....

....

]}

[BTS] (batch trailer)

[FTS] (file trailer)

HL7 batch files usually consist of only one type of message (i.e. ADT, ORM, ORU, etc.), but there are no rules in the
standard restricting the batch to only one message type. The batch file’s headers and trailers are important because
they include a field that supplies a count of messages expected within the batch. Therefore conformance checking
can be done with an HL7 batch file, whereas it cannot be done in the same way with a batch file only containing HL7
messages and no other information.
Batch files using HL7 batch protocol are not widely implemented because of the challenges associated with using
files for HL7 communications. Using HL7 batch files may present sequencing problems and/or file access issues that
must be remedied by solutions such as file locking, a staging directory, or reader delay.
Note: It is very common to have multiple messages put into a single file without utilizing HL7 batch protocol (i.e.
without batch headers and trailers) or instead utilizing some other custom format. Working with non-HL7 formatted
batch files requires some specialized processing to read and parse the messages, and may present some additional
interfacing challenges.
 How are HL7 batch files acknowledged?
The general process for HL7 acknowledgements (ACKs) of batch files is to acknowledge the entire batch at once,
and only process errors on an exception basis. However the individual messages can be acknowledged in a manner
chosen and appropriate for the application. These options include:
 Acknowledging all messages in the response batch.
 Generating a batch control report that is manually delivered to the sending system’s personnel.
 Acknowledging only those messages that contain errors by using an automated acknowledgement batch;
this involves use of an empty ACK batch (an HL7 batch file without any HL7 ACK messages).

References

http://www.hl7standards.com/blog/2006/10/05/what-are-the-hl7-message-types/

http://www.corepointhealth.com/resource-center/hl7-resources

Appendix
HL7 Encoding Characters
Encoding Characters are special characters used to construct an HL7 message. Encoding characters are important
because it defines how data is separated in an HL7 message. Below are the encoding characters:
 Field Separator (normally |)
 Component Separator (normally ^)
 Subcomponent Separator (normally &)
 Field Repeat Separator (normally ~)
 Escape Character (normally \)
Encoding characters are defined dynamically in the MSH segment. The character immediately following the segment
“MSH” is the first encoding character, which is the field separator. The rest of the encoding characters are defined in
MSH-2, where the four characters in this field define the component separator, repetition separator, escape
character, and subcomponent separator in that respective order.
An HL7 implementation note: In an HL7 message , sometimes the actual data in a field may contain an encoding
character, which will require some data manipulation for the message to be sent correctly. For example, keep in mind
that the escape character for the subcomponent separator is "&", data in a message may contain the following:
"Patient must rest & ice the knee". In this case, a system may treat the field in which this data is located as two
subcomponents, although it really should be treated as a single field because the "&" is meant to mean “and” and not
a subcomponent separator.
HL7 SEPARATOR CHARACTERS

ShareThis
inShare1
September 24th, 2007 by Sonal PatelPrint Friendly
In HL7 messaging, the separator characters are also known as the message delimiters or
special encoding characters. The following are the HL7 recommended values:
Segment Separator
|              Field separator, aka pipe
^         Component separator, aka hat
&           Sub-component separator
~           Field repeat separator
\             Escape character

The segment separator is not negotiable. It is always a carriage return (ASCII 13 or HEX 0D).
The others are suggested values only, but usually used as indicated above. The HL7
standard lets you choose your own as long as you show them in the MSH segment.
The MSH is the first segment of all HL7 messages (except HL7 batch messages). The field
separator is presented as the 4th character in the message and it also represents the first field
of the MSH segment. Since the first field of the MSH is typically only a pipe,’|', counting MSH
fields becomes tricky. Field 2 of the MSH (MSH-2) contains the other separator characters in
this order: component, field repeat, escape, and sub-component.
Thus, the following is an example of the beginning of an HL7 message:
MSH|^~\&|…

The delimiter values used in the MSH segment are supposed to be the delimiter values used
throughout the entire message. Encoding HL7 messages in this manner allows an application
parser to simply use the special characters in the MSH to parse the message. However, beware
that many application parsers just use hard coded values and ignore MSH-1 (Field Separator)
and MSH-2 (Encoding Characters).

HL7 Data Types

HL7 data types define the kind of data that can be included in a field, and are used throughout the HL7 message
structure. Examples would be a string, formatted text, timestamp, address, or coded element. Each data type may
contain additional data types that are referenced as components or subcomponents. Complex data types use other
data types to define the kind of data they can contain.
Certain data types cannot reference each other due to the nature of the components. For instance, a data type
cannot reference data types that already reference multiple components, because there is no way to code the
information at that level.
Below is a list of the HL7 data types:
DATA TYPE CATEGORY/ DATA DATA TYPE NAME
TYPE

 
Alp hanumeric
ST String

TX Text data

FT Formatted text

Numerical  

CQ Composite quantity with units

MO Money

NM Numeric

SI Sequence ID

SN Structured numeric

Identifier  

ID Coded values for HL7 tables

IS Coded values for user-defined tables

HD Hierarchic designator

EI Entity identifier

RP Reference pointer

PL Person location

PT Processing type

Date/Time  
DT Date

TM Time

TS Time stamp

Code Values  

CE Coded element

CF Coded element with formatted values

CK Composite ID with check digit

CN Composite ID number and name

CX Extended composite ID with check

digit

XCN Extended composite ID number and

name

Generic  

CM Composite

Demographics  

AD Address

PN Person name

TN Telephone number

XAD Extended address

XPN Extended person name

XON Extended composite name and ID

number for organizations
XTN Extended telecommunications
number

Specialty/Chapter specific  

CD Channel definition

MA Multiplexed array

NA Numeric array

ED Encapsulated data

CP Composite price

FC Financial class

Extended Queries  

QSC Query selection criteria

QIP Query input parameter list

RCD Row column definition

Master Files  

DLN Driver’s license number

JCC Job code/class

VH Visiting hours

Medical Records/Info Mgmt  

PPN Performing person time stamp

Time Series  

DR Date/time range

RI Repeat interval
SCV Scheduling class value pair

TQ Timing/quantity

Understanding components and subcomponents

A data type may reference one or more additional data types as components or subcomponents. For example, the
CK (composite ID with check digit) data type can be broken down into four components, each referencing a specific
data type. One of these components (HD) also references three other data types as subcomponents.
CK data type:
SEQ DATA TYPE COMPONENT NAME

1 NM ID Number

2 ST Check Digit

3 ID Code Identifying the Check Digit Scheme Employed

4 HD Assigning Authority

HD component:
SEQ DATA TYPE COMPONENT NAME

1 IS Namespace ID

2 ST Universal ID

3 ID Universal ID Type