· Dec 8, 2022 11m read

Types of HL7 ADT message and an example of ADT^A04

In the previous article, we've discussed the origin of the standard HL7v2, the structure and the types of messages. Let's now look at one of the most used types of messages and an example of its structure. I'm talking about ADT.

HL7 ADT messages (Admit, Discharge, Transfer) are used to communicate basic patient information, visit information and patient state at a healthcare facility. ADT messages are one of the most widely-used and high volume HL7 message types, as it provides information for many trigger events including patient admissions, registrations, cancellations, updates, discharges, patient data merges, etc. 

All patient information is entered into a Hospital Information System (HIS) or Electronic Medical Record (EMR) in a healthcare setting. New patients or updates in these systems are distributed to ancillary systems through ADT messages to maintain the synchronization of current patient data.

There are quite a few subtypes of this message that depend on the situation and the action to be taken. Here are some of them.

Subtype Description
ADT^A01 Patient admission/visit 
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 admission
ADT^A12 Cancel patient transfer
ADT^A13 Cancel patient discharge

If we look at the general structure of this type of message, it will consist of the following segments. Considering that different versions f the HL7v2 support backward compatibility, in higher versions you may have more fields.

Segments of HL7 ADT

Segment Description
MSH Message Header. Each message must contain a message header, known as an MSH segment within an ADT. The header contains information about the sending system and location, the receiving system and location, the date and time of when the message was created, the type of trigger event being communicated, and the HL7 message version being used.
EVN Event Type. Communicates the event that occurred in order for the message to be generated. This segment is a crucial part of the data flow, as it indicates where and when a message is sent based on the type of event.
PID Patient Identification. Important patient identification information, including patient demographics.
[{NK1}] Next of Kin. Contact information of the patient’s closest living relative(s) in case they need to be contacted. This segment can be repeated as necessary.
PV1 Patient Visit. Information about a patient’s account or any visit-specific details, such as servicing facility, attending doctor, and visit ID are held in this segment.
[PV2] Patient Visit - Additional Info. This segment is a continuation of information specific to the patient’s visit, and is the segment where the Admit Reason is communicated. It is an optional segment if a DG1 segment is included in the message. If there is no DG1 segment, then the PV2 segment is required.
[{OBX}] Observation/Result. Each OBX segment carries information about a single medical observation or result. This segment is more frequently used in ORU (Observational Report) messages. It can be repeated as necessary.
[{AL1}] Allergy Information. Contains information about a patient’s allergies including allergen type, reaction and severity. This segment can be repeated as necessary.
[{DG1}] Diagnosis Information. This segment contains information about a patient’s diagnosis and uses ICD coding standards to communicate specific diseases, signs, symptoms, abnormalities, patient complaints, etc.
[{PR1}] Procedures. Holds information about the various procedures that can be performed on a patient, and can be repeated to communicate information about multiple procedures.
[{ROL}] Role. The personnel and event involvement information necessary to add, update, correct and delete from the patient record.
[{GT1}] Guarantor Information. Information about a patient’s guarantor (i.e. the person financially responsible for the patient’s account) is held in this segment. This segment is particularly useful when communicating with insurance billing applications.
[{IN1..2..3}] Insurance Information. The insurance policy coverage information, such as plan and provider identifiers, necessary to produce patient and insurance bills.

[ ] = optional segment, { } = repeating segment

Now that we know the building blocks of this type of messages, let's look at an example.

Example of HL7 ADT^A04 message

Let's say we have the following message:

PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 MYSTREET AVE^^MYTOWN^OH^44123^USA||(216)123-4567|||M|NON|400003403~1129086|
PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN MYLASTNAME^BONNIE^^^^|||||||||| ||2688684|||||||||||||||||||||||||202211031408||||||002376853

In this example, you will notice that we have 5 distinct segments separated by the carriage return character: MSH, EVN, PID, NK1 and PV1.

You will also notice that each segment contains a number of composites. For example, in the first line, the pipe character (|) separates the SMS and SMS ADT segments.

Finally, on the second line, the first name sub-field JOHN is separated from the last name DOE using the ^ character.

Also, there is always an indicator of the version of the used HL7v2 standard so that the receiving application knows what to expect in which field. In this instance, the version is 2.5.

Now let's look at each segment of this message and learn what info it carries.

Segment MSH
Segment EVN
Segment PID
Segment NK1
Segment PV1

This is it for now. Find out more about HL7v2 on the official portal.

Any comments/suggestions are welcome in the comments section.

Discussion (1)3
Log in or sign up to continue