What Is HL7 v2.x?
HL7 version 2.x (often called HL7 v2 or HL7 2.x) is the dominant standard for electronic data interchange between healthcare information systems. Despite being more than 30 years old, it continues to carry the majority of clinical message traffic in hospitals worldwide β patient admissions, laboratory orders and results, scheduling events, financial transactions, and clinical documentation. Most hospital interface engines (Mirth Connect, Rhapsody, Ensemble, Cloverleaf) are still primarily routing HL7 v2.x messages.
The Anatomy of an HL7 v2.x Message
An HL7 v2.x message is a pipe-delimited text file where each line is a segment. Every segment starts with a three-letter code (e.g., MSH, PID, OBX), followed by fields separated by the pipe character |. Fields are numbered by position β MSH.9 is the 9th field and contains the message type. Fields can contain sub-components separated by carets (^) and repetitions separated by tildes (~).
A complete HL7 v2.x message is a sequence of these segments, where each segment carries a specific category of clinical or administrative information. The MSH (Message Header) always comes first and establishes the message type, version, and routing information. Patient demographics live in PID. Visit information is in PV1. Observation results appear in OBX.
The Most Important Segments
While the HL7 v2.x specification defines hundreds of segment types, a handful appear in nearly every integration scenario:
- MSH β Always the first segment. Contains message type (MSH.9), control ID for deduplication (MSH.10), sending and receiving application/facility, and HL7 version.
- PID β The core patient identifier segment. PID.3 contains the patient identifier list (MRN, national ID), PID.5 the patient name, and PID.7 the date of birth.
- PV1 β Patient visit details: patient class (inpatient/outpatient), assigned location, attending doctor, and admission type. Critical for ADT workflows.
- OBR β The order request segment in ORM and ORU messages. OBR.4 contains the universal service identifier (test code) and is the key field for mapping lab orders to your test catalog.
- OBX β Individual observation or result in an ORU message. OBX.2 declares the value type (NM for numeric, ST for string, CWE for coded), OBX.3 the observation identifier, and OBX.5 the actual value.
- EVN β Event type metadata for ADT messages. Contains the event type code (EVN.1) that distinguishes A01 (admit), A03 (discharge), A08 (update), and other patient movement events.
HL7 Data Types
Like DICOM's Value Representations, HL7 defines data types that govern how field values are encoded. Key data types include:
- ST (String) β Plain text up to a defined max length. Used for free-text fields like notes and descriptions.
- TS (Timestamp) β Date/time string in YYYYMMDDHHMMSS format. HL7 allows partial precision (YYYYMMDD for dates only).
- CX (Extended Composite ID) β A structured identifier with assigning authority and identifier type code. Used for MRNs, account numbers, and national patient IDs.
- XPN (Extended Person Name) β Structured name with family name, given name, middle initial, suffix, prefix, and name type code separated by carets.
- CE/CWE (Coded Element / Coded with Exceptions) β A coded value with identifier, description, and coding system (ICD-10, LOINC, SNOMED). The standard way to transmit coded clinical data.
- NM (Numeric) β Decimal number as a string. Used for test results, quantities, and measurements.
- HD (Hierarchic Designator) β An application or facility identifier. Used in MSH.3/4/5/6 for message routing.
Message Type Structure
HL7 v2.x defines message types as combinations of a message code and event code, written as Code^Event. For example: ADT^A01 (Admit), ORM^O01 (Order), ORU^R01 (Result), SIU^S12 (New Appointment), and MDM^T02 (Document). Each message type has a defined segment grammar specifying which segments are required, which are optional, and in what order they appear. The Message Types tab in this browser shows these grammars for the 10 most common message types.
Practical Use Cases for This Browser
Interface analysts and integration engineers use this segment browser in several everyday scenarios:
- Writing interface specifications: Reference field positions and data types when documenting mapping logic from source system fields to destination system fields.
- Debugging missing or misplaced data: When a receiving system reports a missing value, look up the segment to confirm the expected field position and data type.
- Understanding a new message type: Browse the ADT^A31 or DFT^P03 schema to understand what segments to expect when building a new interface.
- Training new analysts: The combination of segment definitions and message schemas makes a self-contained HL7 v2.x primer for team onboarding.