HL7 v2 Messaging

Regardless of whether a healthcare organization deploys Epic, Cerner, or an amalgamation of legacy systems, clinical data must flow seamlessly across disparate network boundaries.

For decades, Health Level Seven Version 2 (HL7 v2) has served as the undisputed workhorse of healthcare interoperability. It is an event-driven, highly transactional messaging standard operating at the application layer (Layer 7) of the OSI model.

HL7 v2 is composed of reusable, standardized segments delimited by specific ASCII characters.

Message Structure

• MSH: Message Header (routing, sending/receiving apps)
• PID: Patient Identification (demographics)
• PV1: Patient Visit (location, admission type)
• OBX: Observation/Result (clinical data)
• Segments are delimited by ASCII characters

Transport: MLLP Protocol

The primary transportation mechanism is the Minimal Lower Layer Protocol (MLLP) operating over standard TCP/IP connections.

ADT (Admit, Discharge, Transfer) messages are the lifeblood of hospital synchronization, ensuring that patient demographics and visit locations are identical across all ancillary systems.

ADT Trigger Events

ADT Workflow Example

1. Patient registers at front desk → ADT^A04
2. Patient admitted to inpatient → ADT^A01
3. Patient transferred to ICU → ADT^A02
4. Insurance updated → ADT^A08
5. Patient discharged → ADT^A03

ADT messages flow from the Patient Administration System (PAS) to all downstream systems to maintain synchronized patient demographics and visit information.

Clinical diagnostic workflows are managed by Order Message (ORM) and Observation Result (ORU) messages.

ORM: Order Message

When a physician orders a test, the EHR generates an ORM message containing patient demographics, specific tests requested, ordering provider ID, and urgency level (STAT).

ORU: Observation Result

Once the LIS completes analysis, it transmits an ORU message back to the EHR. The ORU contains the structured clinical result within an OBX segment, completing the transactional loop.

Order-Result Loop

1. ER physician suspects myocardial infarction
2. EHR generates ORM for cardiac enzymes (Troponin I, CK-MB)
3. ORM flows from EHR to LIS
4. LIS completes analysis
5. LIS transmits ORU with OBX segment results
6. Results appear in patient chart for review

The order-result loop demonstrates bidirectional messaging between EHR and diagnostic systems for clinical workflows.

This sequence shows the complete order-result lifecycle: provider places order (ORM), LIS acknowledges and processes sample, analyzer generates results, LIS transmits results (ORU) back to EHR for provider review.

The following table compares the primary HL7 v2 message types.

While highly efficient for internal, real-time event exchange, HL7 v2 suffers from critical, systemic architectural limitations.

Localization Problem

The standard permits extreme localization; segments contain highly optional and repetitive fields. Consequently, an HL7 message formatted natively by a Cerner system may require intensive, tedious middleware mapping to be parsed correctly by an Epic system's Bridges engine.

Technical Debt

• Reliance on constant data transformation
• Semantic translation creates technical debt
• Prevents seamless plug-and-play interoperability
• Requires expensive integration consultants
• Version compatibility issues (v2.3, v2.4, v2.5, v2.5.1)

HL7 v2 and MLLP were designed in an era before modern security threats, requiring additional safeguards.

Security Requirements

• Dedicated VPNs for HL7 traffic
• TLS tunneling for encryption in transit
• Network segmentation for interface engines
• Access control on MLLP ports (typically 2000-3000)
• Audit logging of all message transactions

The Minimal Lower Layer Protocol (MLLP) provides the essential framing layer for HL7 v2 message transmission over TCP/IP.

MLLP Frame Structure

• Start Block: 0x0B (Vertical Tab, VT) – marks message beginning
• End Block: 0x1C (File Separator, FS) – marks message end
• Carriage Return: 0x0D (CR) – follows end block for acknowledgment
• TCP/IP carries the framed payload between interface endpoints

Acknowledgment Modes

• MSA^AA (Application Accept): Message processed successfully
• MSA^AE (Application Error): Processing error occurred
• MSA^AR (Application Reject): Message rejected (validation failure)
• Commit Acknowledgment: Two-phase ACK for critical transactions

Modern healthcare organizations leverage AWS services to build scalable, resilient HL7 v2 integration architectures.

Mirth Connect on ECS/Fargate

• Containerized Mirth Connect interface engine on ECS/Fargate
• Auto-scaling based on message queue depth
• Multi-AZ deployment for high availability
• EFS for shared channel configurations and scripts
• CloudWatch for message throughput and error monitoring

AWS B2B Data Interchange

• Managed EDI/HL7 translation service
• Validates and transforms HL7 messages
• Integrates with S3 for message storage
• Reduces custom interface development effort
• Supports X12 and HL7 v2 standards

API Gateway + Lambda

• API Gateway exposes REST endpoints for HL7 operations
• Lambda functions transform HL7 to FHIR JSON
• Event-driven architecture via EventBridge
• SQS queues buffer high-volume message bursts
• Step Functions orchestrate complex multi-step workflows

HL7 v2 remains the workhorse of healthcare interoperability despite its limitations, with billions of messages transmitted daily.

Core Concepts Recap

• HL7 v2: Layer 7 application messaging standard
• MLLP: TCP/IP transport protocol (no native encryption)
• ADT: Patient administration (A01-A12 trigger events)
• ORM: Order messages (EHR → LIS/RIS)
• ORU: Observation results (LIS/RIS → EHR)
• Segments: MSH, PID, PV1, OBX, ORD

Architectural Limitations

• Extreme localization requires middleware mapping
• Version compatibility challenges
• No native security (requires VPN/TLS)
• Technical debt from transformation logic

For further reading on HL7 v2 messaging standards: