HL7 v2

HL7 v2 messages use a non-XML, delimited format where fields are separated by pipes (|), components by carets (^), sub-components by ampersands (&), and repetitions by tildes (~). This compact, positional syntax was designed to minimize bandwidth on legacy serial connections. For example, a patient name segment might appear as PID||12345^5^M11^ADT1^MR^UH|. Parsing requires strict adherence to the segment-specific grammar defined in the standard.

Communication in HL7 v2 is driven by trigger events—real-world occurrences like a patient admission (A01), discharge (A03), or lab order (ORM^O01). Each trigger event maps to a specific message type that defines the required and optional segments. This event-driven architecture ensures that data flows automatically in response to clinical workflow state changes, reducing manual data entry.

A defining feature of HL7 v2 is its extensibility through Z-segments. Vendors and healthcare organizations can define custom segments (e.g., ZPD for custom patient demographics) to transmit data not covered by the standard. While this flexibility drove widespread adoption, it also created a major interoperability challenge: Z-segments are site-specific and require custom mapping in interface engines like Mirth Connect to normalize data across systems.

HL7 v2 implements a robust application-level acknowledgment (ACK) mechanism to ensure reliable delivery. A receiving system must return an acknowledgment message confirming successful processing. The standard defines multiple acknowledgment codes:

• AA: Application Accept
• AE: Application Error
• AR: Application Reject This protocol is critical for patient safety, ensuring that a lab order or pharmacy request was not lost in transit.

The standard has evolved through versions, with v2.5.1 and v2.7 being the most common in production. A key design principle is backward compatibility: a v2.7 system can parse a v2.3 message. However, forward compatibility is not guaranteed. Interface engines must often handle multiple versions simultaneously, translating between them to bridge legacy ADT systems and modern clinical applications.

Every HL7 v2 message is composed of a hierarchical sequence of segments, each identified by a three-character code. Key segments include:

• MSH: Message Header (control information)
• PID: Patient Identification
• PV1: Patient Visit
• OBR: Observation Request
• OBX: Observation Result Each segment occupies a separate line and contains a defined sequence of fields, making the message human-readable but structurally rigid.

A design pattern that defines a single, standard, application-independent data format to which all incoming HL7 v2 messages are translated. Instead of building point-to-point mappings between every system pair, each interface only needs to map to and from the canonical model.

• Drastically reduces mapping complexity from O(n²) to O(n)
• Provides a consistent semantic layer across the enterprise
• Simplifies onboarding of new systems

The process of defining field-level correspondences between a source HL7 v2 segment and a target system's schema. A mapper must understand that PID-3 in an ADT message maps to the patient identifier field in the receiving EHR.

• Handles code set translation (e.g., local codes to LOINC)
• Manages structural transformation (v2 segments to XML or JSON)
• Requires deep knowledge of both sending and receiving system data dictionaries

A message queuing mechanism ensuring no clinical message is ever lost in transit. When an interface engine receives an HL7 v2 message, it persists the message to disk and only deletes it after the receiving system sends a positive ACK (acknowledgment) message.

• Protects against network failures and system downtime
• Uses sequence numbering to detect gaps
• Critical for patient safety in lab result and medication order workflows

An integration architecture where all clinical applications connect to a central interface engine rather than directly to each other. The engine receives HL7 v2 messages from any source, applies routing rules, and delivers transformed data to the appropriate destination.

• Replaces brittle point-to-point interfaces
• Centralizes monitoring, logging, and error handling
• Simplifies compliance auditing with a single data flow map