HL7 was founded in 1987 to produce a standard for the exchange of data with hospital information systems. Over 35 years later, HL7 v2 remains the backbone of real-time healthcare communication across hospitals, labs, imaging centers, and EHR systems, with more than 90–95% of US healthcare organizations relying on it for critical data exchange.
History of HL7
HL7 (Health Level 7) was established in 1987 as a response to the healthcare industry's pressing need for interoperability. The first version of the HL7 messaging standard was released in October 1987 as an Application Protocol for Electronic Data Exchange in Healthcare Environments. Since then, HL7 has evolved through multiple major releases, each iteration refining the standard to address emerging clinical and technical requirements.
The name "Health Level 7" refers to the seventh layer of the ISO Open Systems Interconnection (OSI) model — the application layer where healthcare data exchange occurs. This positioning reflects the standard's focus on semantic interoperability at the highest level of the communications stack, independent of underlying transport mechanisms.
HL7 v2 Family Explained
HL7 v2 encompasses a family of messaging standards that spans from v2.1 through v2.8.2. Each version builds on its predecessor while maintaining backward compatibility:
- v2.1 to v2.2: Early versions establishing the fundamental message structure, segment definitions, and field encoding
- v2.3: Introduced more sophisticated data types and began adding specialty messages
- v2.4 and v2.5: Added expanded support for laboratory, imaging, and pharmacy domains
- v2.5.1: Refined field definitions and introduced more granular data-type components
- v2.7: Modernized terminology and added new segment types for evolving use cases
- v2.8 and v2.8.2: Latest developments incorporating lessons from decades of clinical deployment
Despite the emergence of newer standards like FHIR, HL7 v2 remains the de facto standard for operational healthcare messaging. The HL7 v2 family is characterized by:
- Lightweight event-driven design: Segments, fields, and repetitions convey meaning efficiently without verbose XML or JSON overhead
- Flexible extensibility: Organizations can accommodate local variations and custom fields while maintaining core interoperability
- Broad vendor support: Nearly all major EHR, HIS, LIS, RIS, and pharmacy systems understand HL7 v2
- Proven track record: Decades of clinical deployment have proven the standard's reliability in mission-critical scenarios
Why HL7 Still Dominates Clinical Messaging
Despite emerging standards, HL7 v2 remains dominant for several interconnected reasons:
Ubiquitous Support: Every major healthcare information system — from Epic and Cerner to regional and niche solutions — implements HL7 v2 parsing and generation. This universal coverage means integrators can exchange data with virtually any endpoint without custom translation layers.
Lightweight and Event-Driven: HL7 v2 works because it is lightweight and event-driven. A single ADT message announcing a patient admission weighs only a few hundred bytes and can be transmitted, parsed, and acted upon in milliseconds. This efficiency matters in real-time environments like emergency departments and ICUs.
Flexible Enough for Real-World Variation: Healthcare is messy. HL7 v2's flexible encoding and tolerance for locally-extended fields allow organizations to fit the standard to their actual clinical workflows without completely breaking interoperability. Systems can ignore fields they don't use and add new ones as needed.
Proven Stability: Millions of ADT, ORM, and ORU messages cross healthcare networks every day. The standard has been battle-tested over 35 years, and critical bugs have long been identified and worked around by the industry.
Cost of Migration: Organizations have invested heavily in HL7 v2 integrations. The cost and risk of migrating to FHIR or another standard is high, and many clinical workflows depend on HL7 v2's specific semantics. Until FHIR reaches feature parity and cost parity, migration is not a business priority.
Real-World Use Cases
HL7 v2 excels in several high-impact clinical scenarios:
Admission/Discharge/Transfer (ADT) Feeds: The ADT message family synchronizes patient demographics, encounters, and clinical flags across hospital information systems. When a patient is admitted to a bed, the HIS sends an ADT^A01 message to the EHR, lab information system, and billing system. When discharged, an ADT^A03 message notifies all downstream systems. This real-time notification is the heartbeat of hospital operations.
Laboratory Order and Result Exchange: The ORM (Order Message) carries lab orders from the EHR to the laboratory information system (LIS), and the ORU (Observation Result) message returns results. The tight coupling and fast cycle time make HL7 v2's event-driven model ideal for high-volume result delivery.
Radiology Order and Image Integration: DICOM systems and radiology information systems (RIS) speak HL7 v2 to receive orders and confirm completion. The ORM message carries the imaging procedure request; the ORU message confirms the study is ready for interpretation.
Pharmacy Integration: When a clinician orders a medication in the EHR, an ORM message flows to the pharmacy system. When the medication is dispensed or the order is modified, confirmation messages flow back. This feedback loop is critical for medication safety and inventory management.
Departmental System Integration: Hospitals integrate radiology, pharmacy, laboratory, and billing systems via HL7 v2 interfaces. Each system can send and receive messages without knowing the full architecture, because the standard defines the meaning of each segment and field.
Glossary Callouts
Understanding HL7 v2 requires familiarity with a few key terms:
Segment: A segment is a named unit of information that forms a logical grouping of one or more fields. Every segment starts with a three-letter identifier (e.g., MSH, PID, OBR) followed by a field separator. Segments are always encoded on a single line and separated by carriage returns or line feeds. Examples: MSH (message header), PID (patient identification), OBR (observation request).
Field: A field is a named data element within a segment, identified by its position number. The MSH segment's first field is MSH-1 (field separator); the second is MSH-2 (encoding characters). Fields are separated by the field-separator character (usually |). A field may be simple (a single string like "John") or complex (a composite data type like XPN, which carries name components).
Component: A component is a named sub-element within a complex field. The PID-5 field (patient name) is an XPN data type with components: XPN-1 (family name), XPN-2 (given name), XPN-3 (middle name), etc. Components are separated by the component-separator character (usually ^). A field may have zero, one, or many component values.
Sub-component: A sub-component is a named sub-element within a component, separated by the sub-component-separator character (usually &). For example, the CX data type (extended composite ID with check digit) has component CX.4 (assigning authority), which itself has sub-components: CX.4.1 (namespace ID), CX.4.2 (universal ID), and CX.4.3 (universal ID type).
Related pages
- HL7 Message Structure: Segments, Fields, Components, and Delimiters
- HL7 v2 Versions: Timeline 2.1 to 2.8.2 and Which to Use
- HL7 Acknowledgements: ACK/NACK, AA/AE/AR, and the MSA Segment
- ADT Message: Admission, Discharge, Transfer
- ORM Message: Order Message
- ORU Message: Observation Result
