HL7 v2 Explained

What is HL7 v2?

HL7 version 2 is the most widely used standard for exchanging clinical and administrative data in healthcare. If you've worked in healthcare IT for more than a day, you've encountered HL7 v2 messages - even if you didn't realize it.

Developed in the 1980s, HL7 v2 was designed to solve a simple problem: hospitals needed to send patient information between different systems. The lab system needs to tell the EHR about test results. The admission system needs to notify billing when a patient arrives. HL7 v2 became the universal language for these conversations.

Why It's Still Everywhere

Here's the thing about HL7 v2: it's old, it's quirky, and nearly every healthcare system on the planet uses it. While newer standards like FHIR get more attention, HL7 v2 quietly powers the majority of healthcare data exchange happening right now.

Why? Because it works. Hospitals have decades of investment in HL7 v2 integrations. The people who understand it are valuable. The interfaces are stable. Moving to something new means rebuilding integrations that already work, and in healthcare, "already working" is a powerful argument against change.

How HL7 v2 Works

HL7 v2 messages are text files with a specific structure. They look cryptic at first, but once you understand the pattern, they're straightforward to read.

Message Structure

A message consists of segments, and each segment contains fields:

• Segments: Lines that start with a 3-character code like MSH, PID, or OBX
• Fields: Separated by pipe characters (|)
• Components: Within fields, separated by carets (^)
• Subcomponents: Within components, separated by ampersands (&)

Let's break down that first line (the MSH segment):

• MSH = Message Header (every message starts with this)
• SENDING_APP = Which system sent this message
• ADT^A01 = Message type (ADT = Admit/Discharge/Transfer, A01 = Patient Admission)
• 2.5 = HL7 version being used

Common Message Types

HL7 v2 defines different message types for different scenarios:

• ADT (Admit, Discharge, Transfer): Patient movement and demographics
• ORM (Order Message): Lab orders, medication orders, imaging orders
• ORU (Observation Result): Lab results, test results
• SIU (Scheduling): Appointment scheduling and updates
• MDM (Medical Document): Clinical documents and notes
• DFT (Detailed Financial Transaction): Billing and charges

Real-World Scenarios

Scenario 1: Patient Admission

A patient arrives at the ER. The registration system creates an ADT^A04 message (patient registration) and sends it via HL7 to:

• The EHR (so doctors can see the patient)
• The lab system (so they know who to associate results with)
• The billing system (so charges can be tracked)
• The pharmacy system (so they can fill orders)

One event, one HL7 message, multiple systems updated. This happens thousands of times daily in every hospital.

Scenario 2: Lab Results

A blood test is ordered. When results are ready, the lab system sends an ORU^R01 message to the EHR. The doctor gets notified, the results appear in the chart, and if values are critical, alerts fire. All triggered by an HL7 message arriving.

Scenario 3: Patient Discharge

A patient is discharged. An ADT^A03 message goes out, and systems across the hospital update their records. Billing starts final charge reconciliation. The bed management system marks the bed available. The outpatient scheduling system enables follow-up appointment booking.

HL7 v2 Versions

There isn't just one HL7 v2 - there are versions. The most common are:

• 2.3: Widely used, especially in older systems
• 2.4: Added features for orders and results
• 2.5: Current workhorse, most new implementations
• 2.6, 2.7, 2.8: Newer versions, less common

The versions are mostly backward compatible, but differences exist. A system expecting 2.5 messages might struggle with 2.3 format. Integration engines like Mirth Connect handle version translation.

The Challenges

Flexibility Is a Double-Edged Sword

HL7 v2 is intentionally flexible. The standard defines optional fields and allows custom Z-segments for organization-specific data. This flexibility means every vendor implements HL7 v2 slightly differently.

You might have two systems both claiming HL7 2.5 support, but their messages look different. One uses field 5 for patient name, another uses field 9. One includes middle initials, another doesn't. This is why healthcare IT has an entire profession built around HL7 interface development.

No Built-in Query Mechanism

HL7 v2 is message-based, not query-based. Systems push messages to each other. If you want to ask "What's this patient's current medication list?" HL7 v2 doesn't have a clean way to do that. You'd need either a query interface (QRY messages, rarely used) or access to the source system's database.

This is where FHIR shines - it's query-based by design. Need data? Make an API call. With HL7 v2, you usually need to have received and stored the messages beforehand.

Hard to Read

HL7 v2 messages aren't human-friendly. New developers often struggle with the pipe-delimited format. There's no official JSON representation (though some tools convert it). You need specialized knowledge to read and troubleshoot messages effectively.

HL7 v2 vs FHIR

These standards serve different purposes:

When HL7 v2 Is Better

• Real-time alerts and updates between tightly coupled systems
• Internal hospital infrastructure already using it
• Scenarios where you need guaranteed message delivery
• When the other system only supports HL7 v2

When FHIR Is Better

• Building new applications and APIs
• Patient-facing applications and mobile apps
• Query-based data access
• When you need JSON/XML for modern web development

Getting Started with HL7 v2

If you're new to HL7 v2:

• Get comfortable reading pipe-delimited messages - practice makes perfect
• Learn the common message types (ADT, ORM, ORU) thoroughly
• Use a viewer tool - don't try to read raw messages in a text editor
• Understand MLLP (Minimal Lower Layer Protocol) - it's how HL7 messages are transmitted
• Study one vendor's implementation deeply before trying to learn them all

For developers:

• Use a library - don't parse HL7 with string splits
• Good libraries exist for Java, Python, C#, and JavaScript
• Learn Mirth Connect or another integration engine
• Build test harnesses - you'll need to simulate messages for development

The Future of HL7 v2

HL7 v2 isn't dying, it's evolving. As FHIR adoption grows, organizations are building FHIR façades over their HL7 v2 infrastructure. Messages still flow as HL7 v2 internally, but APIs exposed externally are FHIR.

New hospitals still implement HL7 v2 interfaces because their vendors support it and it's proven. The skill set remains valuable. If you're entering healthcare IT, understanding HL7 v2 isn't optional - it's table stakes.

The Bottom Line

HL7 v2 is the engine room of healthcare IT. It's not glamorous. It's not modern. But it works, and it's everywhere. While FHIR gets attention for its modern API approach, HL7 v2 quietly ensures patients get admitted, results get delivered, and medications get ordered.

Learning HL7 v2 means understanding how healthcare systems actually communicate today. The standard has quirks born of being designed in the 1980s, but those quirks are part of healthcare IT reality. Master HL7 v2, and you'll understand the foundation that healthcare interoperability is built on.