HL7v2 Is Not Dead: Why Your AI Agent Still Needs It

TL;DR

• HL7v2 still powers real-time hospital messaging. FHIR layers on top; it has not replaced HL7v2, and will not for years.
• Over 95% of US hospitals use HL7v2 for ADT (Admit, Discharge, Transfer) per HL7 International and industry surveys.
• Most lab results (HL7v2 ORU) and orders (HL7v2 ORM) still flow this way. FHIR subscriptions remain inconsistent across EHR vendors.
• If your AI agent needs real-time hospital events, it must speak HL7v2 as a first-class path, not an afterthought.

The protocol everyone ignores

If you have been building healthcare AI recently, you have probably spent most of your integration time on FHIR. FHIR R4 is well-documented, has clean JSON, and every EHR vendor has a public sandbox (though those sandboxes have significant limitations).

Meanwhile, the protocol that actually moves data through most US hospitals is HL7v2. It has been doing so since the late 1980s. Despite years of FHIR adoption, HL7v2 is not going anywhere soon.

The numbers tell the story. Over 95% of US hospitals use HL7v2 for ADT messaging per HL7 International and KLAS surveys. Most lab results flow through ORU messages. Most orders go via ORM. FHIR is growing, but it is layered on top of HL7v2 infrastructure, not replacing it.

"HL7 Version 2 is the most widely implemented standard for healthcare in the world. It supports about 95% of hospital information systems in the United States."

HL7 International, official standard documentation

If your agent only speaks FHIR, you are missing the real-time event stream that powers hospital operations.

Why FHIR has not replaced HL7v2

Three factors keep HL7v2 entrenched.

Existing integration engines. Hospitals run Mirth Connect, Rhapsody, and Cloverleaf that route thousands of HL7v2 messages per day with years of custom transformations. Ripping them out is a multi-year, multi-million-dollar project most health systems will not prioritize. HIMSS research confirms integration engines remain the dominant backbone even at systems investing in FHIR (HIMSS).

Real-time event semantics. HL7v2 ADT is event-driven by design. An A01 fires the moment of admission. FHIR Subscriptions offer similar functionality, but adoption is still early and inconsistent across EHR vendors.

Regulatory and payer integration. Many payer integrations, public health reporting systems, and state immunization registries still require HL7v2. Until those downstream systems migrate, hospitals maintain HL7v2 infrastructure.

What ADT messages contain

ADT messages track physical patient movement. They are the backbone of census, bed assignment, billing triggers, and care coordination.

• A01 Admit. Inpatient admission. Demographics (PID), visit info (PV1), insurance (IN1/IN2), admitting diagnosis (DG1). Often the first signal of a new encounter.
• A02 Transfer. Patient moved between units. PV1 updates location.
• A03 Discharge. Patient leaves. Disposition, final diagnoses, attending physician. Triggers follow-up and claims.
• A04 Register. Outpatient or ED registration.
• A08 Update. Demographics, insurance, or next-of-kin changed. Fires often, must not be treated as a new encounter.

For agents doing care coordination, discharge planning, or revenue cycle, these are the primary data source. They arrive in real time, before equivalent FHIR resources are typically available.

Anatomy of a message

MSH|^~\&|EPIC|HOSPITAL|AGENT|VERIAL|20260328120000||ADT^A01|MSG00001|P|2.5.1
EVN|A01|20260328120000
PID|||MRN12345^^^HOSP^MR||DOE^JOHN^A||19800115|M|||123 MAIN ST^^ANYTOWN^CA^90210
PV1||I|4NORTH^401^A^^^HOSP||||1234567^SMITH^JAMES^A^^^MD
IN1|1|BCBS001|BCBS^BLUE CROSS BLUE SHIELD|||||||GROUP123
DG1|1||R06.02^Shortness of breath^ICD10|||A

Fields delimited by pipes. Components by carets. Subcomponents by ampersands. Repetitions by tildes. The first three characters of MSH (|^~\&) define these delimiters. Compact and efficient for serial point-to-point communication, but it creates real challenges for modern software.

Common parsing challenges

Delimiters are not always standard. Most messages use |^~\&, but the spec allows custom delimiters. Read MSH first and configure accordingly.

Z-segments are everywhere. Custom segments prefixed with Z (ZPD, ZIN, ZDG) carry hospital-specific data. They are not in the standard. Get documentation from each integration partner.

Escapes. \F\ = pipe, \S\ = caret, \T\ = tilde, \R\ = backslash, \E\ = escape, \.br\ = line break. Addresses with apartment numbers, names with special characters, free-text clinical notes all need proper escaping.

Repeating fields and segments. Multiple insurance plans (IN1), multiple diagnoses (DG1), multiple addresses (PID-11). Handle cardinality correctly.

Null vs empty. "" means "explicitly null," empty means "no value." The distinction matters for A08 updates where "clear this" and "no change" must be different.

Testing HL7v2 feeds

Testing HL7v2 is harder than FHIR for several reasons.

No public test servers. There is no equivalent of hapi.fhir.org. You stand up your own MLLP listener and generate your own messages.

MLLP transport. Messages wrap in start-of-block (0x0B) and end-of-block (0x1C, 0x0D) over raw TCP. Not HTTP.

Realistic sequences. Production sends A01, A08, A02, A03 for the same visit, sometimes out of order. Isolated messages miss these bugs. See the HL7v2 ADT testing guide for scenario design.

Vendor variations. Epic A01 is not Cerner A01. Z-segments, field usage, and ordering all differ.

A good setup includes an MLLP endpoint, realistic message generator, vendor-specific templates, scenario playback for patient journeys, and error injection for malformed and out-of-order delivery.

Building agents that handle both protocols

The pragmatic approach is an abstraction layer that normalizes HL7v2 and FHIR into a shared internal model.

• Separate ingestion, shared processing. The HL7v2 parser and the FHIR client both produce the same internal patient event objects. Business logic is protocol-agnostic.
• Event mapping. A01 maps to patient_admitted. A03 maps to patient_discharged. FHIR Encounter status changes map to the same events.
• Graceful degradation. HL7v2 may carry fields FHIR lacks, and vice versa. Handle optional fields.
• Test both paths. Include scenarios where the same journey is represented in both HL7v2 and FHIR, and verify equivalent agent outputs.

Key Takeaways

• HL7v2 still powers 95%+ of US hospital ADT messaging. FHIR is layered on top, not replacing it.
• Integration engines (Mirth, Rhapsody, Cloverleaf) with deep custom logic are why HL7v2 persists. Replacement is a multi-year capital project.
• Z-segments carry operationally relevant data, which means vendor-specific documentation is required for useful parsing.
• Build ingestion as two paths with one shared event model, and test both against the same patient journeys.
• For message types, MLLP details, and scenario design, see the HL7v2 ADT testing guide.

FAQ

Is FHIR going to replace HL7v2 soon?

Not in the next three to five years. FHIR adoption is growing, but it sits on top of HL7v2 infrastructure in most hospitals. Real-time event semantics and regulatory reporting still flow through HL7v2.

What percent of US hospitals use HL7v2?

Over 95% for ADT messaging per HL7 International. ORU (lab results) and ORM (orders) adoption is similarly dominant.

What version of HL7v2 should my agent support?

HL7v2.5.1 is the most common production version in US hospitals, with 2.3 and 2.4 still present in older systems. Your parser should tolerate version differences via the MSH-12 field.

How does HL7v2 testing differ from FHIR testing?

HL7v2 needs an MLLP listener, realistic multi-message sequences, vendor-specific profiles, and ACK handling. FHIR testing can use public sandboxes (with caveats) and HTTP. The ADT testing guide covers the practical setup.