31 Jul
Key takeaways
- HL7 v2 remains embedded in core hospital workflows, and full replacement carries a level of operational risk most organizations are unwilling to accept.
- Modernization does not require removing HL7 v2. A FHIR facade layered on top of existing interfaces can expose modern APIs without touching the underlying message flow.
- The 2025 State of FHIR survey, conducted by HL7 International and Firely, found that running HL7 v2 and FHIR in parallel remains standard practice across the industry, not a temporary workaround.
- A phased rollout, resource by resource, gives teams a way to validate each piece of the new architecture before the next one goes live.
- Testing against real, messy production-like data catches problems a clean synthetic test environment misses entirely.
- Rollback plans matter as much as rollout plans, since a facade layer that fails needs a way to fall back to the existing HL7 v2 path without disrupting care.
- The organizations that modernize successfully treat this as a multi-year architectural shift, not a single migration project with a fixed end date.
Every few years, someone proposes retiring HL7 v2 entirely and rebuilding a hospital’s data exchange on FHIR alone. The plan sounds clean on a slide. It rarely survives contact with the systems already running admissions, lab orders, and results delivery, because those interfaces were never designed to be swapped out in one move.
That is the real starting point for any modernization project: HL7 v2 is not a legacy mistake waiting to be corrected. It is working infrastructure that a hospital depends on every hour of every day, and a modernization plan that treats it as disposable usually stalls before it ships.
This piece looks at what modernizing around HL7 v2, rather than against it, actually involves, including where a FHIR facade fits, how a phased rollout should be sequenced, and where teams tend to move faster than their own testing can support.
Table of contents
Why do healthcare organizations keep running HL7 v2 instead of replacing it?
HL7 v2 was never meant to be permanent, but decades of integration built on top of it made it permanent in practice. Admissions, discharge, transfer messages, lab orders, and results all flow through interfaces that were configured years ago, often by people no longer at the organization, connecting systems from several different vendors.
Removing that infrastructure means removing every downstream dependency at the same time, with no fallback if a connection breaks mid-transition. Most hospitals decide, correctly, that the operational risk of a full replacement outweighs the benefit of a cleaner architecture on paper.
What does modernizing without replacing actually mean?
Modernizing around HL7 v2 means building new capability on top of the existing interface layer instead of underneath it. New applications, patient-facing tools, analytics platforms, and clinical decision support systems can consume FHIR-based data, while the core HL7 v2 message flow keeps running exactly as it does today.
This separates two concerns that a rip-and-replace approach tends to bundle together: exposing modern, standards-based data access, and keeping the operational systems that generate that data stable. Solving the first does not require touching the second.
What does a FHIR facade layer look like in practice?
A facade sits between the existing HL7 v2 interfaces and any new application that expects FHIR. It converts messages into FHIR resources on the way out, and it can convert FHIR requests back into HL7 v2 transactions on the way in, without requiring the source systems to change how they operate.
Rip-and-replace vs. facade-based modernization
| Factor | Rip-and-Replace | Facade-Based Modernization |
|---|---|---|
| Risk to existing operations | High, since core interfaces are replaced directly | Low, since existing interfaces keep running unchanged |
| Rollback options | Limited once the transition begins | Straightforward, since the old path still exists underneath |
| Timeline | Often compressed into a single large project | Spread across incremental phases |
| New capability exposure | Available only after full migration | Available as each facade component goes live |
| Vendor and system dependencies | All must transition together | Can be addressed one at a time |
How should a phased rollout be sequenced?
Sequencing matters more than speed. Starting with the highest-value, lowest-risk data type gives a team a real production test without exposing the whole organization to a new failure mode at once.
A phased rollout by resource priority
| Phase | Resource Focus | Why Start Here |
|---|---|---|
| Phase 1 | Read-only Patient and Observation data | Lower risk, since nothing is written back into the source system |
| Phase 2 | Condition and MedicationRequest (read-only) | Higher clinical value while still avoiding write-back risk |
| Phase 3 | Scheduling and Encounter data | Operationally useful for new applications with moderate implementation complexity |
| Phase 4 | Write-back capability, where required | Highest scrutiny, introduced only after the read-side facade is proven stable |
What testing and rollback safeguards does this require?
- Treating the facade as a one-time project instead of an ongoing layer. Terminology mappings and resource definitions need continued maintenance long after go-live.
- Skipping the read-only phases to get to write-back sooner. This removes the lower-risk learning period that makes write-back safer later.
- Testing only against clean sample data. Production HL7 v2 traffic is messier than most test environments account for.
- Underestimating how many systems actually depend on the existing interfaces. A dependency map built before the project starts avoids surprises mid-rollout.
- Assuming one phase’s success guarantees the next. Each new resource type and each new consuming application introduces its own risk profile.
What mistakes do teams make when they try to move too fast?
- Treating the facade as a one-time project instead of an ongoing layer. Terminology mappings and resource definitions need continued maintenance long after go-live.
- Skipping the read-only phases to get to write-back sooner. This removes the lower-risk learning period that makes write-back safer later.
- Testing only against clean sample data. Production HL7 v2 traffic is messier than most test environments account for.
- Underestimating how many systems actually depend on the existing interfaces. A dependency map built before the project starts avoids surprises mid-rollout.
- Assuming one phase’s success guarantees the next. Each new resource type and each new consuming application introduces its own risk profile.
Where does this leave teams planning modernization?
HL7 v2 is not an obstacle to work around until it disappears. It is infrastructure worth building on top of, deliberately, in phases that match the risk each new capability actually carries. A facade layer, sequenced from read-only data toward write-back, gives an organization real modernization without the operational gamble of a full replacement.
The teams that get this right are not the ones moving fastest. They are the ones testing against real production conditions at every phase and keeping a rollback path ready, so a setback in one phase never threatens the systems the rest of the hospital depends on.
For a closer look at why the underlying conversion work remains difficult even with modern tooling in place, see why converting HL7v2 to FHIR is still a challenge for healthcare teams.
FAQs
Not on any fixed timeline most organizations can commit to. The 2025 State of FHIR survey found parallel operation of HL7 v2 and FHIR is standard practice industry-wide, and most hospitals should plan around that reality rather than a full retirement date.
No. A facade exposes FHIR-based access on top of existing HL7 v2 infrastructure. A full migration would mean replacing the underlying systems themselves, which is a much larger and riskier undertaking.
Read-only access carries far less risk, since it cannot alter the patient record. Starting there lets a team validate the facade's reliability before introducing the higher scrutiny that write-back requires.
It varies by organization size and system complexity, but this is realistically a multi-year architectural effort, not a single project with a fixed end date.
A well-planned rollout includes a rollback path to the direct HL7 v2 interface, defined before the facade goes live, not improvised after something breaks.
No. Most interface engines already in production, like Rhapsody or Mirth Connect, can support a facade layer as an added component rather than requiring a separate platform.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
