ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

— May 16, 2026 · 10 min read

FHIR and HL7 v2 coexist: 2026 hybrid architectures

The idea that FHIR will replace HL7 v2 remains, in 2026, a vendor prophecy rather than a hospital reality. Mature hospital architectures combine both protocols through gateways, a strangler-fig model, and dual-write discipline. Three patterns built to last.

The myth of replacement

When FHIR was published for ballot in 2014, many observers announced the imminent end of HL7 v2: modern REST, JSON, sector IGs, reference profiles — the case was seductive. Eleven years later, FHIR R5 (published March 2023) is massively deployed for patient-facing interfaces, coordination tools, and inter-organisation exchanges; HL7 v2.5.1 remains massively deployed for internal hospital flows — ADT, ORM, ORU, MDM in particular.

The reasons for this coexistence are structural. HL7 v2 carries considerable installed weight (estimated at over 95% of active US hospitals in 2025 per HIMSS), tens of thousands of bidirectional integrations with ADT, LIS, RIS, PACS, EMR systems, and contractual SLAs that mandate keeping historical flows. Replacing all that at once means in effect replacing the hospital's information system — a $50-100 million project for an average academic medical centre.

Pattern 1: Strangler-fig migration

The strangler-fig pattern, popularised by Martin Fowler in 2004, consists in growing a new system alongside the old, redirecting responsibilities progressively. Applied to FHIR vs HL7 v2:

  • Install a FHIR server (HAPI FHIR, Microsoft FHIR Service, Google Cloud Healthcare API, etc.) alongside the v2 interface engine (Mirth, Rhapsody, Cloverleaf).
  • Configure routes in the interface engine that duplicate ADT and ORM events to the FHIR server. On every ADT^A01 received, for instance, the engine creates or updates a Patient resource and an Encounter in FHIR.
  • New applications (mobile, patient portal, clinical decision support) consume the FHIR server exclusively, with GET /Patient/{id} or GET /Observation?patient=....
  • Historical applications (PACS, RIS, lab IS) keep consuming v2 over TCP/MLLP as before.
  • Over time, application by application, v2 consumers are switched to FHIR. The ramp is measured in years, not months.

The strangler-fig avoids the big-bang and keeps production live throughout the migration. Its cost: duplicated infrastructure (FHIR server to maintain in parallel) and synchronisation discipline (consistency between v2 and FHIR).

Pattern 2: v2-FHIR Gateway

The gateway pattern consists in exposing a FHIR API to the consumer, and translating each REST call to/from HL7 v2 behind it. The original engine is not modified.

Concretely:

  • An incoming POST /Observation triggers an outbound ORU^R01 v2 to the internal LIS, after translating FHIR fields to OBR/OBX segments.
  • A GET /Patient/{id} triggers an outbound QRY^A19 v2 to the ADT, whose RSP^K23 response is translated to a FHIR Patient resource returned to the client.
  • The gateway typically maintains an LRU cache with invalidation on ADT^A01/^A08 events, to absorb high-frequency read load without saturating the legacy ADT.

This pattern is less invasive than strangler-fig — the original v2 engine is not modified — but it introduces a strong coupling between gateway and v2 semantics. Any v2 evolution (new Z-segments, qualifier changes) must be reasoned on the gateway side.

Dedicated commercial products exist: 1upHealth FHIR Bridge, InterSystems IRIS for Health (with its HSI Health Connect productions), Redox Engine, Rhapsody FHIR Gateway. On open source, Apache Camel HL7 coupled with HAPI FHIR allows implementing this pattern.

Pattern 3: Controlled dual-write

Dual-write consists in writing every business event simultaneously to both systems — v2 AND FHIR. Technically practical, but error-prone on consistency if poorly disciplined.

Three safeguards are indispensable:

  • Single source of truth: one database is authoritative. The other is derived. If v2 stays authoritative, FHIR is an eventual projection; if FHIR becomes authoritative, v2 is downgraded to a compatibility outbound flow for legacy systems.
  • Idempotency on both writes: each v2 message (MSH-10) and each FHIR resource (resource.id) must carry a stable identifier that allows deduplication on replay. Bundle FHIR with Bundle.entry.request.method = PUT on a business identifier fits particularly well.
  • Periodic reconciliation: a daily comparison job identifies gaps between the two stores and raises alerts. Without that, drift is inevitable.

A concrete example: a 2026 French CHU

To fix ideas, here is what a modern French university hospital architecture looks like:

  • Legacy v2 engine (Mirth Connect or OpenPaaS-PI depending on the site): 4,000 to 8,000 messages/day ADT, ORM, ORU, DFT, SIU between ~30 internal applications (ADT, LIS, RIS, PACS, EMR, pharmacy, biomedical).
  • FHIR server (HAPI FHIR or IRIS for Health): exposes Patient, Encounter, Observation, MedicationRequest resources for the patient portal (DMP, espace de santé), for mobile applications (eParcours, connected prescription), and for inter-organisation exchanges over the eINS national health identity network.
  • v2→FHIR Gateway: translates ADT and ORU flows to FHIR resources consumable by modern applications. The core SIH stays v2, the periphery is FHIR.
  • National interconnect: out-of-organisation exchanges (DMP, INSi, MSSanté) are FHIR R4 (the French DMP aligns with the IHE PDC FHIR profile, published by ANS). Historical legacy flows still go through v2.5 on dedicated gateways.

This coexistence is not a transition. It is a stable state, because the two protocols have distinct strengths: v2 is more frugal for high-frequency internal flows (pipe-delimited is 2-3x more compact than JSON), FHIR dominates for reads by heterogeneous applications and for network exchanges.

2026 recommendations

  1. Do not replace v2. The cost of a big-bang migration far exceeds expected benefits. Keep v2 on high-frequency internal flows.
  2. Build a FHIR layer for new applications. Every new interface (mobile, portal, coordination tool) should consume FHIR — it is the modern interoperability layer.
  3. Pick one coexistence pattern and stick to it. Mixing strangler-fig and gateway creates architectural debt that is hard to repay; better to pick one dominant pattern per perimeter.
  4. Invest in terminology governance. SNOMED-CT, LOINC, ICD-10/11, RxNorm — the consistency of codifications between v2 and FHIR is the most underestimated stake.
  5. Align on national profiles. In France: IHE PDC, INSi, eINS. In the US: US Core, USCDI v4 published in 2024. These profiles are binding for certifications and RFPs.

Coexistence is the steady state

In 2026, FHIR and HL7 v2 are not competing: they cohabit in pragmatic hospital architectures where each occupies the territory it is good at. The right reflex is not to choose one against the other, but to explicitly designate each one's perimeter and invest in the gateways. To dig further, the Introduction to FHIR page provides the basics, and the FHIR R5 vs HL7 v2.5.1 post details the respective strengths. On the technical reference side, FHIR at ediverse and HL7 v2.x at ediverse catalogue the most exchanged resources and messages.