“HL7 v2 to FHIR migration” is a slightly misleading phrase, because for almost every organization it does not mean replacing v2 with FHIR. HL7 v2 runs an enormous share of real clinical messaging today, it works, and it is not going away any time soon. What “migration” actually means in practice is bridging — adding FHIR for the modern use cases that need it (apps, APIs, regulatory requirements) while v2 keeps doing the job it already does, and translating between the two at the boundary. This guide is a practical look at how to do that: why bridging beats rip-and-replace, how v2 messages map to FHIR resources, where the translation gets tricky, and a realistic approach to running both worlds together.
A scope note: this is a technical guide, not legal advice, and any real data moving through a v2-to-FHIR bridge is PHI that must be protected with appropriate security and a BAA where applicable.
Why Both HL7 v2 and FHIR Exist
HL7 v2 is the decades-old, pipe-delimited messaging standard that still carries the bulk of clinical interoperability — admissions, orders, results, and more, flowing as event-driven messages between systems. It is deeply entrenched, battle-tested, and supported everywhere. FHIR is the modern, resource-based, RESTful standard built for apps, APIs, and the kind of integration v2 was never designed for, and it is what US regulation increasingly requires. The key insight is that these are not competitors where one replaces the other; they coexist, each suited to different jobs. For a fuller comparison of the two, see our HL7 vs FHIR guide. The practical consequence: plan for coexistence, not replacement.
The Reality: Bridge, Don’t Rip and Replace
Attempting to rip out working HL7 v2 interfaces and replace them wholesale with FHIR is rarely feasible or worth it — the v2 interfaces are numerous, embedded, and functioning, and replacing them all is enormous risk for little gain. The realistic and almost universal approach is to bridge: keep v2 running for the interfaces and systems that use it, add FHIR where new capabilities require it, and translate between v2 and FHIR at the boundary so both worlds interoperate. This lets you adopt FHIR incrementally, driven by actual need, without disrupting the messaging that keeps operations running. An honest partner will steer you toward this coexistence model rather than selling a risky big-bang replacement.
Why Move Toward FHIR at All
If v2 works, why add FHIR? Because the things v2 does poorly are exactly the things modern healthcare increasingly needs: app and API integration (FHIR is built for it; v2 is not), regulatory requirements (US rules center on FHIR — see our CMS interoperability compliance work), patient and third-party access, and easier, more standardized integration for new development. So the driver is not replacing v2’s messaging but enabling new use cases v2 cannot serve well. You add FHIR where it earns its place, and leave v2 doing what it already does.
The Mapping Problem: v2 Messages to FHIR Resources
The technical heart of bridging is mapping HL7 v2’s segments and fields onto FHIR’s resources and elements. The two models are structured very differently — v2’s event messages and segments versus FHIR’s discrete, referenced resources — so this is real translation, not a format conversion. Concretely, common mappings look like this: a patient’s demographics from the PID segment map to a Patient resource; visit information in PV1 maps to an Encounter; observation results in OBX segments map to Observation resources (often gathered into a DiagnosticReport); orders in ORM/OMG-type messages map to ServiceRequest; and allergy information in AL1 maps to AllergyIntolerance. Helpfully, HL7 maintains a v2-to-FHIR mapping implementation guide that provides standardized guidance for these mappings, so you are not inventing them from scratch — building on that guidance is far more reliable than ad hoc mapping. This work rests on solid HL7 and FHIR engineering.
Terminology Mapping
Mapping the data structures is only half the job; the codes have to map too. HL7 v2 uses its own tables and code sets, while FHIR binds elements to value sets built on standard terminologies (LOINC, SNOMED CT, RxNorm, and others). A correct bridge maps v2’s coded values to the appropriate FHIR value sets and standard codes, rather than passing raw v2 codes into FHIR resources where they will not be understood. Weak terminology mapping is a common cause of bridges that technically move data but produce FHIR resources that do not actually interoperate, so it deserves the same care as the structural mapping.
Coexistence and Bridging Patterns
In practice the bridge is usually implemented as a translation layer, frequently in an interface engine. Mirth Connect (NextGen Connect) is a common choice for exactly this — receiving v2 messages and emitting FHIR (and the reverse), acting as the translation point between the two worlds. See our Mirth Connect integration practice, and our Mirth vs Redox comparison for choosing an integration approach. The pattern is typically a facade: v2 in, FHIR out for systems and apps that speak FHIR, with v2 continuing to flow natively where it always has. Adoption is incremental — you stand up the bridge for the first use case that needs FHIR, then expand to others over time, rather than converting everything at once.
Where Translation Gets Tricky
Honesty matters here: not everything in HL7 v2 maps cleanly to FHIR. v2 has nuances, local customizations, and Z-segments (site-specific extensions) that may have no direct FHIR equivalent, and some semantics are ambiguous or lossy in translation. A naive mapping can silently drop or distort clinically meaningful data, which is a patient-safety concern, not just a data-quality one. A good bridge handles these edge cases deliberately — mapping what maps cleanly, making considered decisions about what does not, using extensions where appropriate, and validating that nothing important is lost. The places where v2 and FHIR do not line up are exactly where experience and care pay off.
Validation
Because translation can distort data, the FHIR output of a bridge should be validated, not assumed correct. Validate the resulting resources against the relevant FHIR profiles — US Core for US interoperability — to confirm they are well-formed and conformant, and reconcile against the source v2 to confirm the translation preserved the clinical content. Validating the bridge’s output continuously catches mapping and terminology errors early, before they reach the systems and apps consuming the FHIR data.
A Practical Bridging Approach
Inventory v2 Interfaces and Use Cases
Catalog the existing v2 interfaces and identify which use cases actually need FHIR, so you bridge with purpose rather than converting indiscriminately.
Decide What Needs FHIR
Determine where FHIR adds real value — new apps, APIs, regulatory requirements — and leave working v2 interfaces that do not need it alone.
Choose the Translation Approach
Select how you will translate, commonly an interface engine like Mirth Connect acting as the v2-to-FHIR translation layer.
Map Messages and Terminology
Map v2 segments and fields to FHIR resources (building on the HL7 v2-to-FHIR guidance) and map v2 codes to FHIR value sets and standard terminologies.
Build and Validate
Build the translation, then validate the FHIR output against profiles and reconcile against the source v2 to confirm nothing important is lost.
Run in Coexistence and Expand
Run v2 and FHIR side by side for the first use case, then expand the bridge incrementally to additional use cases over time.
How Taction Helps
We bridge HL7 v2 and FHIR — building translation layers, commonly in Mirth Connect, that map v2 messages to FHIR resources and back, handle terminology mapping to standard value sets, and run v2 and FHIR in coexistence so you adopt FHIR incrementally without disrupting working messaging. We build on the HL7 v2-to-FHIR mapping guidance, validate the FHIR output against US Core, and handle the tricky edge cases where v2 and FHIR do not align cleanly. With deep experience in both standards, ISO 27001-certified security, and PHI handled under a signed BAA, we make the bridge reliable. Our HL7 integration and FHIR API development practices, within our healthcare software work, cover the full scope.
Related reading: FHIR R4 Implementation Guide for Developers · HL7 ADT Messages Explained
Frequently Asked Questions
Should we replace HL7 v2 with FHIR?
Almost never wholesale. HL7 v2 runs a huge share of working clinical messaging and is not going away, so ripping it out and replacing it with FHIR is risky and rarely worth it. The realistic approach is to bridge — keep v2 running, add FHIR where new use cases require it, and translate between them at the boundary.
How do HL7 v2 messages map to FHIR?
v2’s segments and fields map to FHIR’s resources and elements — for example PID to Patient, PV1 to Encounter, OBX to Observation (often within a DiagnosticReport), order messages to ServiceRequest, and AL1 to AllergyIntolerance. HL7 maintains a v2-to-FHIR mapping implementation guide that provides standardized mappings, which is far more reliable than mapping ad hoc.
What tool is used to translate v2 to FHIR?
Commonly an interface engine, and Mirth Connect (NextGen Connect) is a frequent choice — it can receive v2 messages and emit FHIR (and the reverse), acting as the translation layer between the two worlds. The right choice depends on your broader integration needs.
Does everything in v2 map cleanly to FHIR?
No. v2 has nuances, local customizations, and site-specific Z-segments that may have no direct FHIR equivalent, and some semantics are lossy or ambiguous in translation. A naive mapping can silently drop or distort clinically meaningful data, so the edge cases must be handled deliberately and the output validated.
How do we make sure the translation is correct?
Validate the resulting FHIR resources against the relevant profiles (US Core for US interoperability) and reconcile them against the source v2 to confirm the clinical content was preserved. Validating continuously catches mapping and terminology errors early, before they reach the systems consuming the FHIR data.
Can we adopt FHIR incrementally?
Yes, and you should. Stand up the bridge for the first use case that genuinely needs FHIR, prove it, then expand to additional use cases over time, with v2 continuing to flow natively throughout. Incremental adoption driven by real need is lower-risk than converting everything at once.
Bridging HL7 v2 and FHIR? Schedule a free consultation →
This article is a technical guide, not legal advice. Reviewed by Taction Software’s healthcare integration engineering team. ISO 27001-certified information security management. PHI in a v2-to-FHIR bridge is protected under a signed BAA.
