Why HL7 v2 Still Rules Interoperability Despite FHIR's Hype

The Misconception: HL7 v2 Is Legacy and Should Be Replaced

Ask most health IT professionals about HL7 v2, and you'll hear it's a 'legacy standard' that should be replaced by FHIR. But that's wrong. I work with interoperability every day, and I've seen HL7 v2 move billions of messages across hospitals, labs, and payers. It's not legacy—it's the backbone. Replacing it outright would be like tearing up the interstate system because we have faster cars. The real question isn't 'Which standard is better?'—it's 'How do we get the best of both?'

The Question I'm Asking: Can We Realistically Move Everything to FHIR?

Given the momentum behind FHIR—with its RESTful APIs, modern JSON, and support from regulators—should we be pushing to retire HL7 v2? The answer is a resounding no, at least for the foreseeable future. Let's reason through why.

Why HL7 v2 Is Still the Workhorse

First, consider adoption. HL7 v2 has been around since 1987, and it's still used by more than 95% of US healthcare organizations (HL7 International). That's not just a legacy footprint—that's a thriving ecosystem. Hospitals, labs, and public health agencies rely on v2 for high-throughput messaging: orders, results, ADT (admit, discharge, transfer). It's optimized for real-time, event-driven exchange, and it works. The HL7 Version 2 Product Brief notes that v2.7, the latest update, was published in 2011—hardly a dead standard. It's stable, predictable, and battle-tested.

Now, look at FHIR. Yes, FHIR R4 was the first release with normative content (HL7 FHIR Version History), and R5, published in March 2023, defines 157 resources (HL7 FHIR Resource Index). It's designed for modern web APIs and mobile apps. But here's the catch: FHIR is still evolving. R5 is a Standard for Trial Use, not fully normative. That's not a criticism—it's a reality. Standards that are still moving targets are risky for mission-critical systems that need to guarantee uptime and data integrity.

The comparison becomes clear when you think about what each standard excels at. HL7 v2 is the engine for high-throughput legacy workflows, while FHIR is favored for developer-facing, mobile, and cloud-native applications (HL7 International). That's not a competition—it's a division of labor. I'd argue we need both.

The Real Cost of Forced Migration

Let's talk money and risk. Migrating an entire hospital's interface engine from v2 to FHIR is not a weekend project. It involves rewriting every interface, retraining staff, and validating that clinical workflows don't break. The HITECH Act already poured billions into EHR adoption—by 2021, 96% of US non-federal acute care hospitals had adopted certified health IT (ONC Report to Congress). That investment is built on v2. Tearing it out would be a colossal waste.

Moreover, the regulatory push isn't actually mandating FHIR for everything. For example, the CMS Interoperability and Patient Access final rule requires Medicare Advantage organizations and certain other payers to implement a Patient Access API using FHIR R4.0.1 (Federal Register, CMS-9115-F). That's for patient-facing access—a perfect use case for FHIR. But it doesn't force the underlying clinical data exchange between providers to switch. The ONC HTI-1 rule, which took effect in March 2024, focuses on certification requirements and algorithm transparency, not on retiring v2 (ONC HTI-1 Final Rule).

A Table to Put It in Perspective

Let's compare the two standards across the criteria that matter to me:

The differences are complementary, not oppositional. I've seen v2 handle millions of lab results daily with nary a hiccup. Meanwhile, my team builds FHIR-based APIs for patient access apps because that's what the developers expect. No one wants to parse v2 in a mobile app.

Semantics and the Real Interoperability Problem

Here's the deeper issue: even if we switched everything to FHIR, we'd still face the same semantic interoperability problems. FHIR gives us the structure, but what goes inside the resources matters. That's where terminology standards come in—LOINC for lab observations, SNOMED CT for clinical terms, and RxNorm for medications (HL7 International). Without these, a FHIR Observation resource with a code '12345' is meaningless. The US Core Implementation Guide, based on FHIR R4, defines minimum constraints, but it relies on USCDI data elements (US Core Implementation Guide). And USCDI v3, which becomes the baseline for certification as of January 1, 2026, expanded to 94 data elements in 19 classes (ONC Standards Bulletin 2022-2). That's progress, but it's about content, not transport.

The real interoperability challenge is not the wire format—it's making sure that a 'positive' result in one system means the same thing in another. HL7 v2 has the same problem, and we've solved it with vocabularies, not by changing standards. So, to my mind, the debate over v2 versus FHIR is a distraction from the harder work of standardizing clinical meaning.

What I'd Actually Do

If I were in charge of a health system's interoperability strategy, I would not plan to retire HL7 v2. Instead, I'd invest in a hybrid architecture: keep v2 for real-time, high-throughput transactions between internal systems and external partners, and deploy FHIR for patient-facing APIs and any new app development. I'd also put my resources into ensuring that both sides speak the same terminology—mapping every v2 segment to LOINC, SNOMED, and RxNorm where appropriate.

Concretely, I'd pilot a project where a legacy v2 ADT feed feeds a FHIR-based notification service for care coordination. That's not fantasy—I've seen it done. The v2 message is parsed, transformed into a FHIR Encounter resource, and pushed to a patient's smartphone app. The result: the patient gets real-time updates, and the hospital doesn't have to rip out its interface engine. That's the pragmatic path.

I know some purists will say we need to move to FHIR entirely. But look at the numbers: 96% of hospitals are on certified EHRs (ONC Report to Congress). Those systems are deeply entrenched. Forcing a complete migration would cost billions and risk patient safety. Instead, let's bridge the two standards. HL7 v2 isn't going anywhere soon, and that's okay. The future is not about choosing one standard—it's about making them work together.

Sources

• HL7 International - https://www.hl7.org/fhir/
• HL7 V2 Product Brief - https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
• HL7 FHIR Version History - https://www.hl7.org/fhir/history.html
• HL7 FHIR Resource Index - https://www.hl7.org/fhir/resourcelist.html
• ONC Report to Congress - https://healthit.gov/news/onc-outlines-health-it-interoperability-progress-report-congress/
• US Core Implementation Guide - https://hl7.org/fhir/us/core/