What Is HL7? Standards, Definition & v2 Reference
HL7 (Health Level Seven) is the most widely adopted messaging standard in healthcare IT — the HL7 definition covers a family of standards for exchanging clinical and administrative data between systems. First published in 1987, the HL7 standard remains the backbone of clinical data exchange in over 95% of US hospitals as of 2026. Despite the emergence of FHIR, HL7 v2 messages power the vast majority of real-time interfaces between EHRs, lab systems, radiology, pharmacy, and ancillary departments.
This resource center covers HL7 v2 message types, segment reference guides, integration tools, and protocol documentation for healthcare IT professionals.
What is HL7?
Section titled “What is HL7?”HL7 (Health Level Seven) refers to a set of international standards for the transfer of clinical and administrative health data between software applications. The name “Level Seven” refers to the seventh layer (application layer) of the OSI model, reflecting its focus on the interface between applications rather than lower-level network concerns.
Key HL7 versions
Section titled “Key HL7 versions”- HL7 v2.x — The pipe-delimited messaging standard (
MSH|^~\&|...) used for real-time, event-driven data exchange. Versions range from 2.1 (1990) through 2.9 (2019), with v2.3, v2.3.1, and v2.5.1 being the most commonly deployed in production today. - HL7 v3 / CDA — An XML-based standard and the Clinical Document Architecture (CDA) for document exchange. Widely used in public health reporting and Consolidated CDA (C-CDA) for care summaries.
- HL7 FHIR — Fast Healthcare Interoperability Resources, the modern RESTful API standard built on web technologies (JSON/XML over HTTP). Increasingly mandated by CMS and ONC regulations.
HL7 v2 Message Basics
Section titled “HL7 v2 Message Basics”An HL7 v2 message is a structured text string composed of segments, each beginning with a three-character identifier. Segments contain fields separated by pipe (|) characters, with sub-components delimited by ^, ~, \, and &.
Common message structure
Section titled “Common message structure”A typical ADT (Admit/Discharge/Transfer) message includes:
- MSH — Message Header: encoding characters, sending/receiving application, message type, timestamp
- EVN — Event Type: the trigger event (e.g., A01 for admission)
- PID — Patient Identification: MRN, name, date of birth, address, demographics
- PV1 — Patient Visit: patient class, attending physician, location, admit date
- NK1 — Next of Kin: emergency contact information
- IN1 — Insurance: payer, group number, policy details
Common message types
Section titled “Common message types”| Message Type | Description | Use Case |
|---|---|---|
| ADT^A01 | Admit/Visit Notification | Patient admitted to facility |
| ADT^A08 | Update Patient Information | Demographics change |
| ORM^O01 | Order Message | Lab/radiology order placed |
| ORU^R01 | Observation Result | Lab results returned |
| SIU^S12 | Schedule Information | Appointment booked |
| MDM^T02 | Document Notification | Transcription available |
| DFT^P03 | Post Detail Financial Transaction | Charge posted |
Explore each message type in detail:
See the Message Types Overview for a categorized guide to all HL7 v2 message types.
For a blog-style walkthrough, see our HL7 Message Types Explained guide.
HL7 v2 vs FHIR
Section titled “HL7 v2 vs FHIR”HL7 v2 and FHIR are complementary standards that coexist in modern healthcare environments. Understanding when to use each is critical for integration architects.
| HL7 v2 | FHIR | |
|---|---|---|
| Format | Pipe-delimited text | JSON or XML over REST |
| Transport | TCP/IP (MLLP) | HTTPS |
| Approach | Event-driven messaging | Resource-based API |
| Maturity | 35+ years in production | R4 (2019), R5 (2023) |
| Adoption | 95%+ of US hospital interfaces | Growing rapidly, CMS-mandated for payers |
| Best for | Real-time clinical events (ADT, results) | Patient-facing apps, bulk data, APIs |
Most organizations run both: HL7 v2 for internal, real-time clinical workflows and FHIR for external APIs, patient access, and regulatory compliance. The practical strategy is not “migrate everything to FHIR” but rather to build a bridge between the two where needed.
HL7 v2 Segment Reference
Section titled “HL7 v2 Segment Reference”Segments are the building blocks of HL7 messages. Each segment begins with a three-character identifier and contains fields that carry specific clinical or administrative data.
See the Segment Reference Overview for all 17 documented segments organized by clinical workflow.
Reference Guides
Section titled “Reference Guides”HL7 Integration Architecture
Section titled “HL7 Integration Architecture”A production HL7 integration environment typically includes:
- Integration engine — Mirth Connect, Rhapsody, or similar engine that routes, transforms, and monitors HL7 messages between systems
- HL7 parser / validator — Tools for inspecting message structure, validating against profiles, and debugging interface issues
- Interface monitoring — Dashboards and alerting for message throughput, errors, and queue depths
- Version control — Git-based tracking of channel configurations, code templates, and deployment history
Common integration patterns
Section titled “Common integration patterns”- Point-to-point — Direct TCP connections between two systems (simple but does not scale)
- Hub-and-spoke — Central integration engine receives all messages and routes to destinations
- Publish-subscribe — Systems subscribe to message types they need; the engine fans out
- Store-and-forward — Messages queued and retried on failure, ensuring delivery
Related Blog Posts
Section titled “Related Blog Posts”Professional HL7 Integration Services
Section titled “Professional HL7 Integration Services”Need help with an HL7 integration project? Saga IT provides HL7 integration services including interface design, engine deployment, message transformation, and ongoing support. We work with Epic, Oracle Health, MEDITECH, and other EHR platforms.