12 Oct
A legacy EHR doesn’t run on FHIR internally, and it doesn’t need to. It runs on HL7 v2 for admissions, orders, and results, the way it has for years, and that core isn’t the problem. The problem is every conversation with a provider customer or a payer partner now assumes FHIR connectivity is already there, and January 1, 2027 is the date that assumption stops being negotiable for a large part of the market.
What does the January 2027 deadline actually require, and who does it apply to?
The deadline itself is a payer-side mandate, not a direct requirement on EHR vendors. CMS’s Interoperability and Prior Authorization Final Rule requires impacted payers, Medicare Advantage plans, state Medicaid and CHIP programs, and QHP issuers on the federally facilitated exchange, to implement Prior Authorization, Provider Access, and Payer-to-Payer FHIR APIs by January 1, 2027. That regulation binds payers directly.
It reaches an EHR indirectly but forcefully. A payer’s Provider Access API is only useful if the providers on the other end can actually pull that data into a workflow, which means the EHR sitting between the payer and the clinician needs to speak FHIR too. Providers evaluating EHR systems in the next year are going to ask whether the system can consume payer FHIR APIs as a baseline requirement, not a differentiator. Losing that conversation isn’t a compliance violation. It’s a lost deal.
What do EHR vendors already have to meet under ONC certification, separate from the payer deadline?
Unlike CMS-0057-F, this part applies directly. ONC’s HTI-1 Final Rule adopted USCDI Version 3 as the new baseline standard within the ONC Health IT Certification Program, effective January 1, 2026, which is already in effect. Certified health IT modules must accommodate USCDI v3 data elements using FHIR US Core 6.1.0 and the C-CDA Companion Guide Release 4.1. This is the certification floor a legacy EHR has to clear regardless of what any individual payer partner requires, and it was due before the CMS-0057-F deadline even arrives.
Why can't a legacy EHR just drop HL7 v2?
Because the operational core of a hospital or health system runs on it, and none of the FHIR mandates require replacing that core. ADT admission and discharge events, lab and order messages, pharmacy transactions: these workflows are built on HL7 v2 interfaces that have been tuned over years to a specific health system’s quirks. Ripping that out to build FHIR-native from the ground up is a multi-year rewrite with a real chance of breaking something that currently works, in exchange for meeting a requirement that only demands FHIR at the edges, not underneath.
Every credible interoperability roadmap for a legacy EHR in 2026 assumes a hybrid model: HL7 v2 continues doing what it already does well internally, and a FHIR layer sits at the boundary where payers, patient apps, and provider-facing integrations actually need it. The deadline is about what the EHR exposes at its edge, not what it runs internally.
| Approach | What it requires | What it risks |
|---|---|---|
| Rip and rebuild FHIR-native | Multi-year rewrite of core admissions, orders, and results processing | Missed deadline, regression risk in workflows that already work |
| FHIR facade over existing HL7 v2 core | A conversion layer at the API boundary, tested against real message types | Ongoing maintenance of the facade as message types evolve, but a realistic timeline |
| Do nothing | No near-term engineering cost | Lost provider deals as FHIR connectivity becomes a baseline evaluation criterion |
What does a FHIR-facade approach actually look like in practice?
The pattern is straightforward: the HL7 v2 interfaces stay exactly where they are, and a conversion layer sits between that core and any FHIR-facing API. An ADT message still triggers the same internal workflow it always has. When a payer’s Provider Access API or a patient-facing app needs that same event as a FHIR resource, the facade converts it on the way out, mapping ADT segments to Patient and Encounter resources, ORU results to Observation and DiagnosticReport, without touching the v2 processing underneath.
This is not a theoretical shortcut. It’s the same pattern most of the market is already converging on, because it lets an EHR meet a FHIR-facing requirement on a realistic timeline without betting the core system on a rewrite that has to be perfect on the first attempt.
Sequencing matters more than completeness on the first pass. An EHR doesn’t need every FHIR resource type mapped before the facade is useful. Provider Access and Patient Access integrations tend to lean hardest on Patient, Encounter, Observation, Condition, and MedicationRequest resources, so prioritizing the HL7 v2 message types that feed those, ADT and ORU first, covers the bulk of what a payer or provider integration will actually request before broader coverage becomes necessary.
How do you test the facade before a customer or auditor does?
The facade only helps if the FHIR output it produces is actually correct, and that has to be verified against real message types before it ships, not discovered after a payer integration fails in production. Hgear’s free HL7 to FHIR Converter takes v2 messages such as ADT, ORU, and ORM and returns validated FHIR R4 resources, which makes it a fast way to check whether a proposed mapping approach actually holds up against the message types an EHR’s own HL7 v2 core produces, using synthetic or de-identified sample messages rather than a live customer feed.
- Pull sample HL7 v2 messages the EHR’s core actually generates, not generic test data, and run them through a converter to see the resulting FHIR R4 output.
- Check the converted resources against what US Core 6.1.0 expects for the relevant profiles, since certification and payer integrations will both test against that baseline.
- Flag any message type where local customization or Z-segments produce incomplete or ambiguous FHIR output before building the facade around it.
- Treat the facade as a permanent architectural layer, not a stopgap, since the underlying HL7 v2 core isn’t going away on any current roadmap.
Hgear also has a FHIR server product, Fusion, in development, aimed at the production endpoint a facade architecture eventually needs. It isn’t live yet, so it’s not part of a near-term build plan, but it’s worth watching for teams mapping out where this architecture goes next.
The facade also isn’t a one-time build to check off before the deadline and forget. New payer partners bring their own connection requirements, US Core profiles get revised, and the EHR’s own HL7 v2 messages accumulate local customizations over time the way any long-running interface does. Treating the conversion layer as infrastructure that gets revisited each time a new integration or certification cycle comes up keeps it accurate instead of quietly drifting out of date the way an unmaintained mapping layer tends to.
Want to see how your EHR's HL7 v2 messages actually convert?
Hgear’s free HL7 to FHIR Converter is built for exactly this kind of pre-build check. Run a synthetic or de-identified sample from your own HL7 v2 core through it and see the FHIR R4 output before committing an architecture to it.
FAQs
Not directly. CMS-0057-F is a payer-side mandate requiring Medicare Advantage plans, state Medicaid and CHIP programs, and QHP issuers to implement FHIR-based Prior Authorization, Provider Access, and Payer-to-Payer APIs by January 1, 2027. EHR vendors are affected indirectly, since providers need their EHR to consume those payer APIs, making FHIR connectivity a practical requirement for competing in the market.
ONC's HTI-1 Final Rule adopted USCDI Version 3 as the certification baseline effective January 1, 2026, requiring certified health IT to support USCDI v3 data elements using FHIR US Core 6.1.0 and the C-CDA Companion Guide Release 4.1. This requirement applies directly to certified health IT and took effect before the CMS-0057-F payer deadline.
No. Neither CMS-0057-F nor ONC's certification requirements mandate replacing an HL7 v2 core. The common approach is a FHIR facade or conversion layer at the API boundary, which lets HL7 v2 continue handling internal workflows like admissions, orders, and results while exposing FHIR resources where payers, patient apps, or provider integrations require them.
ADT messages, covering admissions, transfers, and discharges, and ORU messages, covering lab and observation results, are typically the highest-priority message types, since they map to the Patient, Encounter, Observation, and DiagnosticReport resources most FHIR integrations need first.
Yes. Hgear's free HL7 to FHIR Converter is designed to be evaluated using synthetic or de-identified HL7 v2 messages, so an engineering team can validate a proposed mapping approach before any real patient data is involved in testing.
No. Fusion is a FHIR server product currently in development and is not yet live. It's referenced here as a direction to watch, not a capability available today.
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.
