What Are HL7 Message Types?
HL7 v2 messages are text-based, pipe-delimited records sent between healthcare systems whenever something happens, such as an admission or a new lab result. Each message has a message type, a trigger event and a set of segments containing the data. Together, they tell the receiving system what happened and what to do. Most hospital interfaces still run on HL7 v2, so these message types remain essential knowledge for integration teams.
The MSH Header Segment
Every message starts with MSH, which defines encoding characters, sending and receiving applications and facilities, timestamp, message type, control ID, processing ID and HL7 version. Receivers route and validate messages using it.
MSH|^~\&|EHR|GENHOSP|LAB|LABSYS|20260929083000||ADT^A01^ADT_A01|MSG00001|P|2.5.1Message Type and Trigger Event
MSH-9 combines a message type and a trigger event, such as ADT^A01 for an admission. The type describes the category, while the trigger event identifies the exact real-world action behind it.
Segments, Fields and Components
Each line is a segment identified by three letters, such as PID or OBX. Fields are separated by pipes, components by carets, and repetitions by tildes, following the encoding characters in MSH.
Acknowledgement Messages
Receivers reply with an ACK message containing an MSA segment. Code AA means accepted, AE means application error and AR means rejected. Missing or incorrect ACKs are a frequent cause of duplicate messages.
Core HL7 Message Types
A small set of HL7 message types carries most interface traffic in hospitals and clinics. Each supports a specific workflow, such as registration, ordering, resulting, scheduling, billing or documentation, and each has its own required segments. Knowing which HL7 v2 segments matter for each type helps you write accurate specifications, test the right scenarios and troubleshoot faster when a downstream system rejects or misinterprets a message during production operations. Each type is explained below.
ADT: Admit, Discharge, Transfer
HL7 ADT messages share patient demographics and encounter events. Key segments, used across EHR/EMR integration work, are PID for identity, PV1 for visit details, and optional NK1, AL1, DG1 and IN1 for contacts, allergies, diagnoses and insurance.
ORM: Orders
HL7 ORM messages, usually ORM^O01, send new, changed or cancelled orders to labs, radiology or other departments. ORC carries order control, and OBR carries the requested test or procedure details.
ORU: Observation Results
HL7 ORU messages, usually ORU^R01, return results. OBR describes the order, while each OBX carries one result value, units, reference range, abnormal flag and status. Our lab integration services map codes to LOINC.
OBX|1|NM|2345-7^Glucose^LN||98|mg/dL|70-99|N|||FSIU: Scheduling
SIU messages communicate appointment events, such as S12 for new bookings, S14 for modifications and S15 for cancellations. SCH, AIS, AIL and AIP segments describe the appointment, services, locations and staff.
DFT: Detailed Financial Transactions
DFT^P03 messages send charges from clinical systems to billing. FT1 segments carry procedure codes, quantities and amounts. Errors here cause lost revenue, because charges never reach the billing system correctly.
MDM: Medical Document Management
MDM messages, such as T02, notify systems about clinical documents like discharge summaries or reports. TXA describes document status and authorship, while OBX segments can carry document content or references.
Common ADT Trigger Events
ADT is the most commonly built HL7 interface, and its trigger events drive patient identity across the whole organization. Registration, bed management, lab, radiology and billing systems all rely on ADT to stay synchronized. Misunderstanding a single trigger event can create duplicate patients, orphaned results or incorrect billing. The events below appear in almost every ADT interface specification, and each needs explicit handling rules agreed with downstream system owners. Here is what each one means.
A01: Admit or Visit Notification
A01 signals an inpatient admission. Downstream systems create or update the encounter and often trigger workflows like bed assignment, dietary orders and nursing documentation for the admitted patient. Timing accuracy matters here.
A03: Discharge or End Visit
A03 closes an encounter. Receiving systems must stop accepting new charges or orders for that visit and finalize documentation, which makes accurate discharge timestamps important for billing and reporting. Late A03s cause errors.
A04: Register a Patient
A04 registers an outpatient or emergency patient without an inpatient admission. Many receiving systems treat it like A01, but the distinction matters for encounter class and billing rules. Specify handling explicitly.
A08: Update Patient Information
A08 updates demographics or visit details. It is usually the highest-volume ADT event, so receivers must process updates efficiently and avoid overwriting newer data with older, delayed messages. Timestamp checks prevent this.
A40: Merge Patient
A40 merges duplicate patient records. It is where most ADT feeds break, because every downstream system must move results, orders and documents correctly from the old identifier to the surviving one.