HL7 v2.x Messaging
HL7 Version 2 is the most widely deployed healthcare messaging standard in the world. First published in 1989, HL7 v2 uses a pipe-delimited text format to transmit clinical and administrative data between healthcare systems. Despite the emergence of FHIR, HL7 v2 remains the backbone of most hospital interface engines, with versions 2.3 through 2.5.1 being the most commonly deployed. The standard is maintained by HL7 International, with the most recent version being v2.9 (published 2019).
Message Structure
An HL7 v2 message consists of segments separated by carriage return characters. Each segment begins with a three-character segment ID followed by a pipe delimiter. Fields within segments are separated by the pipe character (|). Components within fields use the caret (^), and subcomponents use the ampersand (&). Repeating fields are separated by the tilde (~).
MSH|^~\&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20240115120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1|||AL|NE EVN|A01|20240115120000 PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A^^MR||19800215|M|||123 MAIN ST^^ANYTOWN^CA^90210^US||^PRN^PH^^^^555^5551234 PV1|1|I|3NORTH^301^A^HOSP||||1234567890^SMITH^JAMES^A^^^MD|9876543210^JONES^SARAH^B^^^MD||||||||1234567890^SMITH^JAMES^A^^^MD|IN|||||||||||||||||||HOSP|||||20240115120000
Encoding Characters
The encoding characters are defined in MSH-1 (field separator) and MSH-2 (encoding characters). The standard default is:
| Character | Symbol | Purpose |
|---|---|---|
| Field Separator | | | Separates fields within a segment (MSH-1) |
| Component Separator | ^ | Separates components within a field |
| Repetition Separator | ~ | Separates repetitions of a field |
| Escape Character | \ | Escape sequences for special characters |
| Subcomponent Separator | & | Separates subcomponents within a component |
Message Types
HL7 v2 defines message types identified by a three-character code in MSH-9. Each message type is associated with trigger events that describe the real-world event that caused the message to be sent. The message type and trigger event are combined in the format TYPE^EVENT (e.g., ADT^A01 for patient admission).
| Type | Name | Events | Description |
|---|---|---|---|
| ADT | Admit/Discharge/Transfer | A01-A62 | Patient movement events: admission, discharge, transfer, registration, pre-admit, merge. Most commonly used HL7 v2 message category. |
| ORM | Order Message | O01 | General order messages for laboratory, radiology, pharmacy, dietary, and supply orders. |
| ORU | Observation Result | R01, R30, R31, R32 | Unsolicited transmission of observation results from labs, radiology, and other diagnostic departments. |
| SIU | Scheduling | S12-S26 | Scheduling information: appointment booking, cancellation, modification, and notification events. |
| MDM | Medical Document Management | T01-T11 | Document notifications and content: original, addendum, replacement, status change for clinical documents. |
| DFT | Detail Financial Transaction | P03, P11 | Charge posting and financial transaction messages between clinical and financial systems. |
| BAR | Add/Change Billing Account | P01, P02, P05, P06, P12 | Patient account creation, updates, and end-of-visit billing events. |
| RDE | Pharmacy/Treatment Encoded Order | O11, O25 | Pharmacy-specific order messages with structured encoding for medications. |
Common Segments
Segments are the building blocks of HL7 v2 messages. Each segment contains a set of fields defined by the standard. Segments can be required or optional depending on the message type and trigger event.
| Segment | Name | Description |
|---|---|---|
| MSH | Message Header | Present in every message. Contains sending/receiving application and facility, message type, control ID, processing ID, version, and encoding characters. |
| PID | Patient Identification | Patient demographics: name, date of birth, sex, address, phone, MRN, SSN, race, marital status, citizenship. |
| PV1 | Patient Visit | Visit-specific data: patient class (inpatient/outpatient/emergency), assigned location, attending/referring/consulting physicians, admit date/time. |
| OBX | Observation/Result | Individual observation result: observation ID (LOINC code), value, units, reference range, abnormal flags, observation date/time, status. |
| ORC | Common Order | Order control information: order control code, placer/filler order number, order status, ordering provider, entry date/time. |
| OBR | Observation Request | Observation request details: universal service ID, requested/scheduled date, ordering provider, result status, relevant clinical info. |
| NK1 | Next of Kin | Next of kin and associated parties: name, relationship, address, phone, contact role, organization. |
| IN1 | Insurance | Insurance information: plan ID, company name, group number, insured name, policy number, authorization info. |
| DG1 | Diagnosis | Diagnosis information: coding method, diagnosis code (ICD), description, type (admitting/working/final), clinician. |
| AL1 | Allergy Information | Patient allergy data: allergy type (drug/food/environmental), allergen code/description, severity, reaction. |
Acknowledgment Protocol
HL7 v2 uses an acknowledgment protocol to confirm message receipt and processing. When a receiving system processes a message, it returns an ACK message containing an MSA (Message Acknowledgment) segment with an acknowledgment code:
| Code | Meaning | Description |
|---|---|---|
| AA | Application Accept | Message accepted and processed successfully |
| AE | Application Error | Message accepted but contains errors; review ERR segment for details |
| AR | Application Reject | Message rejected; not processed (e.g., unsupported message type, invalid format) |
| CA | Commit Accept | Enhanced mode: message committed to safe storage (processing may be deferred) |
| CE | Commit Error | Enhanced mode: message not committed due to error |
| CR | Commit Reject | Enhanced mode: message rejected at commit level |
Official Specification
The HL7 v2.x standard is maintained by HL7 International. Access to the full specification requires an HL7 membership. The v2.5.1 specification is the version most commonly cited in US regulatory requirements and is referenced in the CMS Electronic Health Record Incentive Programs.