07 Sep
FHIR R6 will not go normative this year. It probably won’t go normative next year either, not fully. So why is a spec that’s still working through HL7’s ballot process showing up in your budget conversations right now?
Because HL7’s calendar and your procurement calendar are not the same calendar, and the gap between them is exactly where EHR vendors get caught flat-footed. By the time R6 is finished, the window to prepare for it quietly, on your own schedule, will already be closed. What you fund this cycle and next determines which side of that window you’re on.
R6 won't ship this year. Your budget still has to move.
Here’s the trap. R6 is currently mid-ballot, with a full round underway through 2026 and final publication realistically landing somewhere between late 2026 and 2027. Ballot reconciliation has historically pushed these dates further out, not pulled them in. So the instinct to say “we’ll deal with R6 when it’s actually final” feels reasonable.
It isn’t, and here’s why: certification requirements, vendor roadmaps, and CMS enforcement dates don’t wait for a spec to be printed. They start moving the moment the direction is clear enough to build regulation around. That moment is closer than most EHR leadership teams think.
What normative actually buys you
If you’ve been half-following FHIR versioning, “normative” might sound like just another release label. It isn’t. It’s the difference between a spec you can build on and a spec you have to keep re-checking.
R4 was the first release to carry normative content, and it’s still the global production standard because of that stability. R5, by contrast, was published as trial-use. Nothing new in it reached normative status. That’s a big part of why adoption across major EHR vendors and national programs has stayed thin. Nobody wants to build a certification pathway on a spec that might still change shape under them.
R6 changes that math. The current plan takes most of the FHIR core, resources that have proven themselves through years of real implementation, and locks them against breaking changes. Anything not mature enough for that gets pulled out into a separate incubator track owned by individual HL7 workgroups, so it can keep evolving without dragging the stable core along with it.
For an EHR company, that split matters more than the version number. Normative status is what regulators point to when they write the next mandate. It’s what large health systems ask about before signing a multi-year contract. R5’s trial-use label gave everyone permission to wait. R6’s normative core removes that permission, eventually.
R4 isn't dying. It's getting a long goodbye.
None of this means rip out your R4 implementation. HL7 has been fairly direct about the sunset window: several years past R6’s publication, timed to regulatory enforcement rather than to the release date itself. Read between the lines and R4 stays a legitimate target well into the early 2030s.
That’s the detail that should lower the temperature in your next planning meeting, not raise it. A five-year runway is not an emergency. It’s a normal technology transition, the kind your engineering team has managed before with other standards. The mistake isn’t moving slowly. The mistake is moving blind, waiting so long that when the real deadline does show up, you’re negotiating vendor contracts and hiring FHIR talent at the same time everyone else in the market is doing exactly that.
The real trigger isn't R6. It's US Core v10.
Here’s the piece that gets lost in most R6 coverage: the version number is not what forces your hand. US Core is. That’s the implementation guide that actually functions as the regulatory floor for FHIR in the United States, and HL7 has indicated the next version, US Core v10, is being built against R6, with a rough target around mid-2027 contingent on R6 actually publishing on schedule.
When US Core moves, the compliance conversation moves with it, on a delay measured in an adoption period rather than overnight. For payer-facing capabilities in particular, current federal interoperability and prior authorization requirements are still anchored to R4-based implementation guides. That won’t flip the day R6 ships. But it will flip, and the companies caught unprepared will be negotiating implementation timelines under a countdown clock instead of on their own terms.
So the question worth asking isn’t “when does FHIR R6 go normative.” It’s “when does US Core v10 become the thing our contracts and our RFPs start requiring.” That’s a narrower, more useful question, and it’s the one your budget should actually be built around.
Budget cycle one: pay for information
This is the cycle where restraint is the right call, not because the topic doesn’t matter but because spending big on migration before there’s anything stable to migrate to is how budgets get wasted. Three things earn a line item this year:
- A gap assessment. Map your current R4 implementation against the resources and structures R6 is expected to touch. You’re not fixing anything yet. You’re finding out how far the distance actually is, in specific terms, not vibes.
- A vendor and partner scorecard. Ask every FHIR-adjacent vendor and integration partner you work with what their R6 posture actually is, not their marketing page’s posture. Most will have no real answer yet. That’s useful information too.
- Training hours for your integration team. The FHIR talent market gets tighter every time a major version shift approaches. Building internal fluency now, while there’s no fire to put out, is cheaper than hiring under pressure later.
None of this requires a large check. It requires a decision to not treat R6 as someone else’s problem for one more year.
Budget cycle two: pay for the build
The following cycle is where real dollars should move, and the trigger for that spend is not a calendar date. It’s a signal: R6 publishes, or US Core v10’s timeline solidifies into something a compliance team would actually cite in a contract.
When that signal arrives, this cycle’s budget should cover the work your gap assessment already scoped: updated resource mappings, certification testing against whichever US Core version has become the working target, and contract language with your interoperability partners that accounts for a phased R4-to-R6 transition rather than a hard cutover.
The advantage of doing cycle one properly is that cycle two stops being a scramble. You already know your gaps. You already know which vendors are ready and which aren’t. The budget conversation becomes “execute the plan” instead of “figure out what the plan should be while the deadline is already ticking.”
What waiting actually costs
Skip cycle one and cycle two collapses into a single, much more expensive event. You’ll be doing the gap assessment, the vendor negotiations, and the actual implementation work at the same time, on whatever timeline CMS or your largest health system client sets for you. Integration talent will cost more because everyone else waited too, and they’re all hiring from the same shallow pool at once.
There’s also a quieter cost: credibility. Health system procurement teams are already asking EHR vendors about their FHIR roadmap during RFPs, well before any mandate forces the issue. “We’re watching it” is a fine answer this year. In eighteen months, it starts sounding like you weren’t paying attention.
What to put in front of your CFO this quarter
Keep it small and specific. Request funding for a gap assessment against R6’s expected resource changes, a written scorecard of where your current interoperability vendors and integration partners actually stand, and a fixed block of training hours for the team that will own this transition. Set a review date tied to US Core v10’s timeline, not to the R6 version number, and revisit the larger build budget when that milestone actually moves.
That’s not a dramatic ask. It’s a two-cycle plan built on the timeline that’s actually in front of you, instead of a guess about a spec that hasn’t shipped yet.
FAQs
Normative status means a resource is locked against breaking changes. Once FHIR R6 goes normative, most of the core specification stops shifting under implementers, unlike R5, which was published as trial-use with no new normative content. That stability is the entire point of R6, and it's what regulators and vendors will build the next generation of certification requirements on.
HL7 is running R6 through its ballot process now, with a full ballot round underway in 2026. Final publication is targeted for late 2026 or 2027, and ballot reconciliation has a track record of pushing these dates back. Nobody should build a 2026 plan around an exact R6 ship date.
No. No EHR vendor currently supports R6, and there's nothing to certify against yet. What matters right now is positioning, not migration: understanding your R4 gaps, watching US Core v10, and building the internal skill set so that when the certification clock does start, you're not starting from zero.
R4 doesn't disappear. HL7 has signaled a sunset window running several years past R6's publication, aligned to regulatory enforcement timelines rather than the spec's release date. Realistically, R4 stays a valid target well into the early 2030s, which is exactly why panic-driven migration budgets are the wrong move.
This cycle's line item should be small and informational: a gap assessment against R6 changes, a vendor and partner scorecard, and training hours for your integration team. Save the larger build budget for the cycle when US Core v10 timing and CMS enforcement dates are actually confirmed.
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.
