Health Level Seven (HL7) represents a foundational interoperability standard used for healthcare data exchange. Despite the rapid adoption of modern RESTful FHIR APIs, HL7 Version 2 (HL7 v2.x) remains widely used for real-time transactional workflows across hospitals, laboratories, imaging systems, and other healthcare environments. For healthcare software teams, building resilient digital health applications, clinical staffing platforms, and diagnostic pipelines requires a practical understanding of HL7 messaging and integration architecture.
Executing an HL7 integration is not simply about parsing delimited text strings. It requires an understanding of the Minimal Lower Layer Protocol (MLLP), socket connection management, acknowledgment workflows, custom vendor Z-segment variations, and terminology normalization using standards such as LOINC, SNOMED CT, RxNorm, and ICD-10-CM.
These capabilities are also important in EHR Software Development, where reliable data exchange with existing clinical systems is a core architectural consideration.
This comprehensive technical guide explains how HL7 v2 messaging works, analyzes core clinical message structures, explains MLLP network transport, compares legacy HL7 messaging with modern HL7 FHIR R4, and outlines practical engineering best practices for building reliable healthcare integrations.
HL7 Integration: HL7 v2 Message Structure and Segments
An HL7 v2.x message is a human-readable, event-driven string composed of ordered collections of data segments. Each segment begins with a 3-character uppercase identifier, such as MSH, PID, or OBX, and is terminated by an ASCII carriage return (<CR>, hexadecimal 0x0D).
Data fields within segments are separated by specialized delimiters defined in the MSH-2 encoding characters field.
Anatomy of an HL7 v2.x Clinical Message: Structure and Delimiters
Figure 1: Anatomy of an HL7 v2.x Message showing segment hierarchy, delimiter specifications, and annotated field mappings.
5 Standard HL7 Delimiters and Their Uses
Field Separator (|): Separates individual data elements within a segment, such as
PID|1||MRN100234.Component Separator (^): Separates sub-elements within a composite field, such as
DOE^JOHN^A.Subcomponent Separator (&): Separates tertiary values within a component.
Repetition Separator (~): Indicates that a field repeats multiple times, such as multiple phone numbers or address values.
Escape Character (\): Used to escape formatting characters or represent special symbols, such as
\F\for the field separator and\S\for the component separator.
Essential HL7 v2 Segments for Healthcare Data Exchange
Segment Code | Segment Title | Clinical Purpose & Content | Key Fields & Data Elements |
|---|---|---|---|
MSH | Message Header | Defines message routing metadata, sender and receiver applications, timestamps, message event types, and control identifiers. | MSH-3 (Sending Application), MSH-9 (Message Type, such as ADT^A01), MSH-10 (Control ID), MSH-12 (Version, such as 2.5) |
PID | Patient Identification | Provides administrative and demographic information for the patient subject. | PID-3 (Patient Identifier List / MRN), PID-5 (Patient Name), PID-7 (Date of Birth), PID-8 (Administrative Sex), PID-11 (Address) |
PV1 | Patient Visit | Contains clinical encounter metadata, hospital location, attending physician, and admission information. | PV1-2 (Patient Class), PV1-3 (Assigned Patient Location), PV1-7 (Attending Doctor), PV1-44 (Admit Date) |
OBR | Observation Request | Acts as the clinical order header for diagnostic tests, imaging studies, laboratory panels, and related workflows. | OBR-2 (Placer Order Number), OBR-3 (Filler Order Number), OBR-4 (Universal Service Identifier), OBR-7 (Observation Date) |
OBX | Observation / Result | Delivers qualitative or quantitative clinical results, laboratory values, vital signs, and other observations. | OBX-2 (Value Type), OBX-3 (Observation Identifier), OBX-5 (Observation Value), OBX-6 (Units), OBX-7 (Reference Range) |
DG1 | Diagnosis Information | Communicates clinical diagnoses, problem list items, and admitting or discharge conditions. | DG1-3 (Diagnosis Code), DG1-4 (Diagnosis Description), DG1-6 (Diagnosis Type) |
HL7 Integration with MLLP: Message Framing and Transport
HL7 v2 messages are commonly transmitted as raw text streams. Because a TCP connection does not inherently identify where one HL7 message ends and another begins, healthcare interfaces commonly use the Minimal Lower Layer Protocol (MLLP) for message framing.
MLLP wraps each HL7 payload in control characters that identify the beginning and end of a message:
Start Block Character (<VT>): ASCII Vertical Tab, hexadecimal 0x0B, marking the beginning of the transmission.
HL7 Payload: The carriage-return-delimited HL7 message content.
End Block Characters (<FS><CR>): ASCII File Separator, hexadecimal 0x1C, followed by Carriage Return, hexadecimal 0x0D.
Figure 2: MLLP Transport Handshake Flow and Message Framing
HL7 ACK and NACK Message Handling
After transmitting a framed message, the sending system commonly waits for an acknowledgment from the receiving system. The acknowledgment communicates the processing status of the message.
Application Accept (AA): Indicates that the receiving application accepted the message.
Application Error (AE): Indicates that an application-level processing error occurred. Depending on the interface agreement, the sender may retry or route the message for review.
Application Reject (AR): Indicates that the message was rejected. The interface may route the message to an error queue or operational workflow for investigation.
Ready to Simplify Your HL7 Integration?
HL7 v2 Message Types and Clinical Event Triggers
HL7 v2 uses message types and event triggers to communicate clinical and administrative events. When an event occurs within a healthcare system, such as patient admission, laboratory result finalization, or appointment scheduling, the source system can generate an appropriate HL7 message.
1. HL7 ADT Messages for Patient Admission and Transfer
ADT messages manage patient lifecycle and demographic workflows across healthcare systems.
ADT^A01: Patient Admission / Inpatient Check-In
ADT^A02: Patient Transfer
ADT^A03: Patient Discharge
ADT^A08: Patient Demographic or Insurance Information Update
ADT^A40: Merge Patient Identifier Records
2. HL7 ORM Messages and Order Management
Order-related HL7 workflows can transmit clinical requests from computerized physician order entry systems to laboratory, radiology, pharmacy, and other ancillary systems.
ORM^O01: General Clinical Order
OMP^O09: Pharmacy Prescription Order
3. HL7 ORU Messages for Clinical Results
ORU messages communicate structured clinical results from laboratory, diagnostic, and other clinical systems back to the EHR.
ORU^R01: Unsolicited Transmission of an Observation / Laboratory Result
MDM^T02: Medical Document Management
4. HL7 SIU Messages for Healthcare Scheduling
SIU messages support appointment and scheduling workflows across outpatient clinics and other healthcare environments.
SIU^S12: New Appointment Booking
SIU^S14: Appointment Modification / Reschedule
SIU^S15: Appointment Cancellation
HL7 Integration Architecture: Interface Engine and Routing Pipeline
Enterprise healthcare architectures often use an interface engine or integration layer to mediate between hospital systems, HL7 interfaces, and downstream clinical applications. Depending on the environment, this layer may use custom services, interface-engine platforms, or cloud-based event infrastructure.
End-to-End HL7 Interface Engine Architecture covering inbound MLLP listeners, parsing, message buffering, terminology mapping, and downstream FHIR transformation.
Key Stages in an HL7 Integration Pipeline
Inbound Transport & Decoupling: MLLP listeners receive HL7 v2 messages through the agreed network transport configuration and publish payloads to an asynchronous processing layer where appropriate.
Segment Tokenization & Filtering: The integration layer parses delimiters, identifies relevant segments, handles duplicate detection where required, extracts custom Z-segments, and applies routing rules.
Terminology Normalization & ConceptMap Translation: Local laboratory, medication, diagnosis, and clinical codes can be mapped to standardized terminologies such as LOINC, RxNorm, SNOMED CT, and ICD-10-CM where appropriate.
FHIR Transformation & Outbound Distribution: Normalized HL7 data can be transformed into FHIR R4 resources and distributed to portals, mobile applications, analytics platforms, data stores, or other downstream systems.
Ready to Simplify Your HL7 Integration?
HL7 Integration: HL7 v2 vs. C-CDA vs. FHIR
Healthcare interoperability has evolved through multiple standards and architectural approaches. HL7 v2 remains important for event-driven messaging, while C-CDA supports document-based exchange and FHIR provides a resource-oriented approach aligned with modern web application architectures.
Evolution of Healthcare Interoperability Standards: HL7 v2 Message Streams, C-CDA Documents, and HL7 FHIR APIs.
Healthcare Interoperability Standards Comparison
Interoperability Dimension | HL7 Version 2.x | HL7 Version 3 & C-CDA | HL7 FHIR Release 4 |
|---|---|---|---|
Data Format & Syntax | Pipe-and-hat delimited text using separators such as | XML-based clinical documents and models associated with HL7 Version 3 and C-CDA implementations. | Resource-oriented JSON or XML representations designed for modern web-based interoperability. |
Transport | Commonly transmitted using MLLP over TCP/IP connections. | Commonly associated with document- and service-oriented exchange patterns depending on the implementation. | Commonly implemented through HTTP/HTTPS RESTful APIs, with additional asynchronous patterns available depending on the implementation. |
Security & Authentication | Security is generally provided through the surrounding network, transport, identity, and interface architecture. | Security mechanisms vary according to the document exchange architecture and implementation. | SMART on FHIR can provide OAuth 2.0-based authorization and OpenID Connect capabilities where supported. |
Granularity & Querying | Event-driven message exchange; individual data elements are typically delivered as part of messages. | Document-level exchange, with clinical information represented within structured documents. | Supports granular resource-based querying, such as retrieving an individual Observation or Condition. |
Typical Use | Patient administration, orders, results, scheduling, and other operational workflows. | Clinical document exchange and continuity-of-care workflows. | Modern applications, patient access, clinical applications, interoperability services, and resource-based data exchange. |
HL7 Integration Case Studies and Healthcare Engineering Examples
A strong healthcare software engineering partner should demonstrate practical experience across healthcare applications, interoperability, automation, connected health, and data governance. These examples reflect different areas of healthcare engineering that can support HL7 integration and broader digital health initiatives.
Digital Healthcare and Clinical Integration Platform: Developed healthcare applications with secure architectures, interoperability capabilities, appointment workflows, vitals tracking, and secure doctor-patient communication.
SaaS-Based Clinical Staffing and Credentialing Solution: Built a healthcare workforce platform supporting credential verification, licensing information, scheduling, and operational workflows.
AI-Powered Health and Diagnostic Applications: Applied structured healthcare data to AI-enabled workflows, including vital-sign analysis, anomaly detection, and clinical decision-support use cases.
Fitness Tracker and Remote Patient Monitoring App: Developed connected health capabilities for collecting wearable and Bluetooth device data and synchronizing relevant health information with cloud-based platforms.
Healthcare Record Governance and Compliance: Implemented healthcare data workflows involving audit trails, role-based access control, validation, and governance mechanisms to support secure data operations.
Ready to Simplify Your HL7 Integration?
HL7 Integration Best Practices and Key Takeaways
Master HL7 v2 to Connect With Existing Hospital Systems: Many healthcare environments continue to depend on HL7 v2 for operational messaging, making reliable MLLP connectivity, parsing, acknowledgment handling, and message processing important integration capabilities.
Bridge Legacy HL7 to Modern FHIR R4: An integration layer can ingest HL7 v2 messages and transform normalized clinical data into appropriate FHIR resources for downstream applications.
Buffer Socket Feeds With Message Queues: Message queues can help decouple inbound HL7 processing from downstream transformations and services where asynchronous processing is appropriate.
Accommodate Custom Z-Segments Early: Healthcare interfaces may contain implementation-specific Z-segments. Integration architectures should therefore use extensible parsing and transformation logic.
Work With Experienced Healthcare Software Engineers: Healthcare integration requires knowledge of interoperability standards, distributed systems, security, clinical workflows, data mapping, and EHR-specific integration constraints.
Conclusion
HL7 integration remains an important part of healthcare interoperability, particularly for connecting hospitals, laboratories, EHR platforms, and clinical applications through HL7 v2 messaging. While FHIR is increasingly used for modern API-based data exchange, many healthcare environments still depend on established HL7 workflows for admissions, orders, results, scheduling, and other clinical operations.
A reliable HL7 integration requires more than message parsing. MLLP transport, acknowledgment handling, terminology mapping, custom Z-segments, message routing, error handling, and integration with downstream FHIR-based systems all need to be considered as part of the architecture. With the right integration approach, healthcare organizations can connect existing systems while creating a path toward more modern interoperability.
At Zignuts, we help healthcare organizations build, integrate, and modernize healthcare software with HL7, FHIR, EHR integration, secure data workflows, and scalable healthcare architectures. Contact us today to discuss your HL7 integration requirements and explore an approach aligned with your healthcare systems and interoperability goals.
Swati Bais
Business Enthusiast | Curious about how businesses evolve, connecting ideas with insights to discover opportunities and shape better ways of working.
