HL7 ADT
Admit, Discharge & Transfer
HL7 ADT (Admit, Discharge and Transfer) messages are used to communicate patient demographics, visit information and patient state at a healthcare facility.
ADT (Admit, Discharge & Transfer)
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.
In a healthcare setting, all patient information is entered into a Hospital Information System (HIS) or Electronic Medical Record (EMR). New patients or updates in these systems are distributed to ancillary systems through ADT messages to maintain synchronization of current patient data.
To communicate the various patient and event information, there are over 50 different types of ADT messages.
Common HL7 ADT messages:
- ADT^A01 – Patient Admit/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 Admit
- ADT^A12 – Cancel Patient Transfer
- ADT^A13 – Cancel Patient Discharge
Sample ADT Message
The segment composition of an ADT message varies based on the type of ADT event as well as the HL7 version. The following sample message depicts a typical HL7 version 2.4 ADT^A04, Patient Registration message.
MSH|^~\&|MESA_ADT|XYZ_ADMITTING|iFW|ZYX_HOSPITAL|||ADT^A04|103102|P|2.4||||||||
EVN||200007010800||||200007010800
PID|||583295^^^ADT1||DOE^JANE||19610615|M-||2106-3|123 MAIN STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434~(919)277-3114||S||PATID12345001^2^M10|123456789|9-87654^NC
NK1|1|BATES^RONALD^L|SPO|||||20011105
PV1||E||||||5101^NELL^FREDERICK^P^^DR|||||||||||V1295^^^ADT1|||||||||||||||||||||||||200007010800||||||||
PV2|||^ABDOMINAL PAIN
OBX|1|HD|SR Instance UID||1.123456.2.2000.31.2.1||||||F||||||
AL1|1||^PENICILLIN||PRODUCES HIVES~RASH
AL1|2||^CAT DANDER
DG1|001|I9|1550|MAL NEO LIVER, PRIMARY|19880501103005|F||
PR1|2234|M11|111^CODE151|COMMON PROCEDURES|198809081123
ROL|45^RECORDER^ROLE MASTER LIST|AD|CP|KATE^SMITH^ELLEN|199505011201
GT1|1122|1519|BILL^GATES^A
IN1|001|A357|1234|BCMD|||||132987
IN2|ID1551001|SSN12345678| Segment | Description |
|---|---|
| MSH | Message Header. Not every segment in an ADT message is mandatory, however 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, { } = repeating | |
For more information on implementing various HL7 message types, please refer to the HL7 Messaging Standard Implementation Guides corresponding to your required version.
Working With ADT Messages
Are you working with HL7 ADT messages? Successfully processing ADT messages requires more than simply receiving and forwarding them. Each sending system may format messages slightly differently depending on the HL7 version (2.3, 2.4, 2.5.1, etc.), local configuration, optional segments, or custom "Z-segments." Even small discrepancies, such as missing fields, unexpected data types, or formatting inconsistencies, can cause downstream systems to reject messages or behave unexpectedly.
To ensure end-to-end compatibility, integration teams must:
-
Validate message structure and required segments
- Normalize field values and data formats
- Map data between different HL7 versions
- Handle custom extensions
- Manage acknowledgements (ACK/NACK) and error workflows
- Monitor message flow in real time
Without the right tools, this quickly becomes time-consuming and difficult to maintain.
How Iguana Simplifies HL7 ADT Integration
Iguana is a healthcare integration engine designed specifically to process, transform, and manage HL7 integration—including high volume ADT feeds.
Iguana comes with built-in schema for HL7 messages, allowing you to parse HL7 ADT messages into structured data that is easy to work with. By leveraging a scripting environment, you can customize mappings to support different HL7 versions, and standardize inconsistent formatting. Iguana supports any system, allowing you to transform HL7 ADT messages into other formats such as JSON, XML, FHIR, and database records.
Due to its lightweight architecture, Iguana can process millions of messages daily, enabling your integration to scale on demand. Centralized monitoring and notifications simplify interface management. Iguana securely logs message activity for auditing and troubleshooting.
Discover how Iguana helps Teletracking handle HL7 ADT integration.
Other HL7 Message Types
- HL7 ADT (Admit, Discharge and Transfer)
- HL7 ORM (Order Entry)
- HL7 ORU (Observation Result)
- HL7 MDM (Medical Document Management)
- HL7 DFT (Detailed Financial Transactions)
- HL7 BAR (Billing Account Record)
- HL7 SIU (Scheduling Information Unsolicited)
- HL7 RDS (Pharmacy/treatment Dispense)
- HL7 RDE (Pharmacy/Treatment Encoded Order)
- HL7 ACK (Acknowledgement Message)
References:
