Ask a vendor sales deck and you'd think HL7v2 is a relic and FHIR has already replaced it. Ask anyone who actually runs interface engines in production, and the picture looks different: HL7v2 still carries the overwhelming majority of real-time clinical messaging traffic — lab results, ADT feeds, orders — in the U.S. today, and it will for years. FHIR is winning the newer ground: APIs, patient access, bulk data exchange, and the CDC's public health modernization push. Any real interoperability strategy has to support both, translating between them, not picking one and hoping the other disappears.
What each standard is actually built for
| Dimension | HL7v2 | FHIR |
|---|---|---|
| Transport model | Message-based, typically over MLLP/TCP | RESTful API over HTTP(S), resource-based |
| Data model | Pipe-delimited segments, loosely standardized | Structured JSON/XML resources with defined schemas |
| Strength | Mature, near-universal EHR/lab support, real-time ADT and results | Modern APIs, granular queries, bulk data export, app ecosystem |
| Where it dominates | Hospital ADT feeds, lab interfaces, existing legacy pipelines | Patient access APIs, registries, public health case reporting (eCR) |
Where organizations get the transition wrong
The most common mistake is treating a FHIR migration as a lift-and-shift: standing up a FHIR server and expecting existing HL7v2-speaking systems to just start talking to it. They won't. The realistic architecture is a conversion layer — HL7v2 messages get transformed into FHIR resources (and back, when needed) at the interface engine, so legacy systems keep speaking the protocol they already speak while anything new is built FHIR-native.
This is exactly the pattern behind electronic case reporting (eCR), which most public health agencies are now standing up under CDC's Data Modernization Initiative: EHRs generate an eICR (electronic Initial Case Report) as a FHIR/CDA document, it routes through AIMS or a similar platform, and the case data ultimately needs to reconcile against systems that are often still HL7v2 underneath.
Building the conversion layer without a proprietary interface engine license
Commercial interface engines (Rhapsody, Cloverleaf, and similar) handle this translation well, but license per interface or per connection — and that cost compounds as your integration count grows. The open alternative uses tools like Microsoft's FHIR Converter or open HL7v2-to-FHIR mapping libraries running on Azure Health Data Services or a self-hosted equivalent, giving you the same transformation capability without a per-connection fee attached to every new system you bring online.
If a system already exists and works, leave it speaking HL7v2 and translate at the boundary. Build anything new — patient-facing apps, registries, analytics pipelines — FHIR-native from the start. Don't force a legacy lab interface into a FHIR rebuild just because FHIR is newer; that's cost and risk with no real benefit.
What to actually ask when evaluating your interoperability layer
- Does it handle both HL7v2 ingestion and FHIR resource output, or does it force a single standard?
- Is the mapping logic something your team can inspect and modify, or is it a vendor black box?
- What happens to the pipeline if CDC updates the eICR/RCTC content requirements — is that a support ticket or a re-architecture?
The right answer, for most public health and healthcare organizations right now, is a hybrid pipeline built on open standards and open tooling — not a bet on either format winning outright.
Tell us what's not talking to what.
Whether it's a data lake that needs building, an EMPI that needs replacing, or a document pipeline eating your team's time — start with a real conversation.
Start a Conversation