HL7 stands for Health Level Seven and refers to both a standards development organization — Health Level Seven International — and the family of healthcare data exchange standards it maintains.
The “Seven” references OSI layer 7, the application layer, because HL7 standards operate at the level where applications communicate rather than at the network or transport layer.
HL7 standards help systems such as EHRs, lab information systems, radiology systems, billing platforms, pharmacies, and public health agencies exchange clinical and administrative data in a consistent format.
Without HL7, each connection between systems would require custom translation — and in a hospital running dozens of clinical applications, that quickly becomes unmanageable.
HL7’s FHIR specification describes HL7 v2 as one of HL7’s most widely adopted standards, prominent in inpatient settings worldwide. The HL7 blog lists the main product families as HL7 v2, CDA, C-CDA, v3, and FHIR.
Here is what this guide covers:
- Common HL7 use cases
- An annotated HL7 message example
- The main HL7 standards (v2, CDA, FHIR)
- How HL7 works in real healthcare systems
- How HL7 differs from FHIR and from HIPAA
- Implementation challenges and a practical checklist
TLDR
HL7 is a family of healthcare interoperability standards used by hospitals, labs, imaging centers, billing systems, pharmacies, and payer platforms to exchange clinical and administrative data.
HL7 v2 remains the most widely used standard for real-time hospital messaging (admissions, orders, results).
CDA handles clinical document exchange. FHIR is the modern API-focused HL7 standard.
HL7 is not a coding language, not the same as HIPAA, and not being replaced by FHIR — all three (v2, CDA, FHIR) often coexist in the same organization.
How does HL7 work in practice?
HL7 exchange typically involves a sending system, a receiving system, a standard message format, a transport mechanism, and an acknowledgement workflow.
When a patient is admitted, a lab order is placed, or a result is finalized, the source system generates an HL7 message describing the event.
The message travels through an interface engine — middleware that routes, transforms, maps, and monitors messages between systems — to the receiving application, which processes the data and sends back an acknowledgement (ACK) confirming receipt.
HL7 EXCHANGE WORKFLOW
How an HL7 message moves between systems
Event triggers message
Admission, order, result, discharge
Interface engine routes
Maps, transforms, monitors
Receiver processes
Lab, EHR, billing, pharmacy
ACK returned
Confirms receipt or flags error
Most HL7 v2 messages travel over TCP/IP connections using MLLP (Minimal Lower Layer Protocol).
The exchange is event-driven — a trigger event (patient admitted, order placed, result finalized) generates a specific message type that the receiving system processes according to its interface specification.
What does an HL7 message look like?
HL7 v2 messages use pipe-delimited text organized into segments, fields, and components. Each segment represents a group of related data.
MSH|^~\&|EHR|Hospital|LAB|LabSystem|202607061030||ADT^A01|12345|P|2.5
PID|||987654||Smith^Alex||19850101|F
PV1||I|3N^302^1|||1234^Jones^Taylor
| Segment | Meaning | What it contains |
| MSH | Message header | Sender, receiver, message type, timestamp, version |
| PID | Patient identification | Patient identifiers, name, date of birth, sex |
| PV1 | Patient visit | Encounter type, location, attending provider |
| OBR | Observation request | Lab or diagnostic order details |
| OBX | Observation result | Test results, values, and interpretations |
| ACK | Acknowledgement | Confirms receipt or reports processing error |
This is a simplified ADT-A01 (admission) message. Real production messages are much longer and often include custom Z-segments for organization-specific data that the standard doesn’t cover natively.
What are the main HL7 standards?
HL7 International maintains several standards. Three are most relevant to current healthcare operations.
HL7 v2
The most widely deployed HL7 standard for real-time, event-driven messaging in hospital environments. Common message types include
- ORM (orders)
- SIU (scheduling)
- ACK (acknowledgement)
- DFT (detailed financial transaction)
- ADT (admission, discharge, transfer)
- ORU (unsolicited observation results)
CDA and C-CDA
The Clinical Document Architecture is an XML-based standard for structured clinical documents such as discharge summaries, continuity of care documents, and progress notes. C-CDA is the U.S. implementation guide for CDA.
FHIR
The modern HL7 standard using modular resources and RESTful APIs. FHIR is designed for web-based exchange, app integration, patient access, payer data exchange, and quality reporting. ONC describes FHIR as an API-focused standard for exchanging health information.
How does HL7 differ from FHIR?
HL7 is the standards organization and ecosystem. FHIR is one specific HL7 standard — the modern, API-first one.
| Topic | HL7 v2 | FHIR |
| Model | Event-driven messages | Resource-based APIs |
| Format | Pipe-delimited text | JSON, XML |
| Common use | Hospital interfaces (ADT, orders, results) | Apps, APIs, patient access, payer exchange |
| Granularity | Message segments | Independently addressable resources |
| Relationship | Older HL7 standard | Modern HL7 standard |
FHIR does not replace v2 overnight.
HL7’s own documentation describes an evolutionary path from v2 and CDA to FHIR, with all three coexisting in production systems.
Many hospitals run v2 for internal messaging while building FHIR APIs for external access and new integrations.
How does HL7 differ from HIPAA?
HL7 and HIPAA both involve healthcare data, but they address different problems.
| Topic | HL7 | HIPAA |
| Type | Standards family for data exchange | U.S. federal law |
| Focus | How data is structured and communicated between systems | How protected health information is used, disclosed, and safeguarded |
| Applies to | Healthcare systems and integration workflows | Covered entities, business associates, and PHI handling |
HL7 messages often carry PHI (protected health information), which means HL7 interfaces must be implemented with appropriate security controls — encryption, access controls, audit logging, and transport security — wherever HIPAA applies.
HL7 defines the structure of the exchange. HIPAA governs what can be shared, with whom, and under what protections.
What are common HL7 use cases?
Here are the common HL7 use cases:
| Use case | Typical HL7 message or workflow | Systems involved |
| Patient admission | ADT-A01 | EHR, registration, bed management |
| Patient discharge | ADT-A03 | EHR, billing, care coordination |
| Lab order | ORM or electronic order | EHR, laboratory information system |
| Lab result | ORU-R01 | LIS, EHR |
| Radiology order and result | Order/result workflows | EHR, RIS, PACS |
| Billing and charges | DFT | EHR, billing system |
| Scheduling | SIU | EHR, scheduling system |
| Immunization reporting | VXU | EHR, immunization registry |
| Public health surveillance | ADT feeds, case reporting | EHR, public health agency |
ONC reported that 70% of U.S. hospitals engaged in all four domains of interoperable exchange (send, find, receive, integrate) in 2023, up from 46% in 2018.
However, only 43% engaged routinely in all four — showing that having interfaces and using them reliably are different achievements.
What are the challenges of implementing HL7?
HL7 standards are flexible by design. That flexibility is also the source of most implementation problems.
IMPLEMENTATION REALITY
Why HL7 is harder than it sounds
Local variations — vendors implement fields differently, creating mapping work for every new connection
Optional fields — missing or inconsistent data breaks downstream workflows when systems assume fields will be populated
Custom Z-segments — organization-specific data may not be understood by other systems
Version mismatches — systems running different HL7 versions need translation and testing
Monitoring gaps — failed messages can delay care or billing when error queues, ACK failures, and latency go untracked
The most common mistakes in HL7 projects include
- Not defining who owns the interface once it is live
- Logging PHI in error logs without appropriate safeguards
- Not monitoring ACK failures, queue backlogs, or latency after go-live
- Assuming “HL7 compliant” means two systems will connect without mapping work
- Skipping test messages for edge cases (missing fields, unusual characters, long notes)
What should an HL7 implementation checklist include?
A practical pre-launch checklist
- Define the workflow and business event driving the interface
- Identify sending and receiving systems
- Choose the HL7 standard and version (or FHIR IG)
- Define message types, trigger events, and required fields
- Map local data fields to standard segments
- Agree on terminology and code systems
- Define transport, authentication, and encryption
- Configure interface engine routing and transformations
- Test normal cases, edge cases, and error handling
- Validate ACK behavior and retry logic
- Monitor queues, failed messages, and latency
- Document ownership, escalation, and change management
When interoperability connects to revenue
HL7 interfaces carry the data that drives clinical operations, billing, authorization, and compliance.
When those interfaces break, claims stall, results disappear, and revenue cycles slow down.
MedHeave helps healthcare providers keep the operational pipeline between clinical systems and billing workflows running cleanly.
- EHR and billing system integration support
- Claims workflow management tied to clinical data exchange
- Denial tracking connected to data completeness and interface quality
- Compliance documentation for payer and accreditation requirements
Contact MedHeave to align your HL7 integration health with your revenue cycle performance.
Frequently asked questions
Here are some commonly asked questions about HL7:
HL7 stands for Health Level Seven. The name references layer 7 (the application layer) of the OSI model, because HL7 standards operate at the level where healthcare applications exchange data — not at the network or transport layer. HL7 also refers to Health Level Seven International, the ANSI-accredited standards development organization that creates and maintains HL7 v2, CDA, FHIR, and other healthcare interoperability standards used worldwide by hospitals, labs, payers, pharmacies, and public health systems.
No. HL7 is a family of standards and specifications for structuring and exchanging healthcare data. Developers use programming languages such as Java, Python, C#, or JavaScript to build software that generates, parses, transforms, validates, or monitors HL7 messages and interfaces. Integration engines like Mirth Connect, Rhapsody, and Cloverleaf provide configuration-based environments for managing HL7 message routing and transformation without writing code from scratch.
HL7 International is the standards organization. FHIR is one specific HL7 standard — the modern, API-focused one built on resources, RESTful interactions, and web formats like JSON and XML. HL7 v2 is an older, widely used messaging standard designed for event-driven hospital interfaces (admissions, orders, results). CDA is an HL7 document standard for clinical summaries. FHIR, v2, and CDA often coexist because they serve different integration patterns and workflows within the same organization.
Yes. HL7 v2 remains one of the most widely deployed healthcare messaging standards globally, especially for internal hospital interfaces handling admissions, lab orders, lab results, radiology, billing, and pharmacy workflows. FHIR is growing for API-based exchange, patient access, and new integrations, but it does not automatically replace existing v2 interfaces. Many organizations operate both v2 and FHIR simultaneously during a transition period that may last years depending on the systems involved.
HL7 defines how healthcare data is structured and exchanged between systems. HIPAA is a U.S. federal law that governs the privacy, security, and permitted use of protected health information. HL7 messages frequently contain PHI, which means HL7 interfaces must be implemented with encryption, access controls, audit logging, and transport security wherever HIPAA applies. The two are complementary rather than interchangeable — HL7 addresses data format and exchange, while HIPAA addresses data protection and privacy.
