FHIR R6 is moving through ballot in 2026. If you lead a healthcare IT team, FHIR R6 readiness should already have a line item on your roadmap, even though the standard hasn’t reached final status yet.
Therefore, teams that start planning FHIR R6 readiness early save budget, avoid rushed rework, and keep patient data flowing without interruption.
Table of Contents
Where Healthcare Interoperability Standards Stand Today?
Before getting into what’s new, it helps to remember where things stand. FHIR R4, finalized in December 2018, is still the backbone of most healthcare interoperability standards in production today. It’s stable, well-supported, and it’s the version referenced by US Core and most federal interoperability mandates.
FHIR R4B came next, in 2022, as a bridge release. It backported a handful of R5 features into an R4-compatible shell, so teams could test new functionality without fully committing to a new major version.
Then FHIR R5 arrived in March 2023, with more than fifty new resources. However, a good number are still trial-use only, not production-ready.
FHIR R5 vs R6: What’s Actually Changing
So what does FHIR R5 vs R6 look like in practice? The honest answer: R6 isn’t primarily about new features. It’s about stability. FHIR product leadership has described R6 as the release that moves most clinical and administrative resources to normative status, meaning they stop changing in ways that break existing implementations. That’s a real shift from R5, where a large share of resources were still trial-use and open to revision.
None of this is locked in yet. The current ballot, v6.0.0-ballot4, published in May 2026, is described by HL7 as the first full ballot of R6. A further voting round runs through mid-August 2026. HL7 has indicated the final specification will be published sometime in 2026 or 2027, depending on how reconciliation goes.
Why FHIR R6 Readiness Can’t Wait for the Final Spec?
Here’s the part most teams get wrong: they treat FHIR R6 readiness as a task for after publication. But the resources most likely to change in the final release are already visible in the current ballot drafts.
Reviewing your existing FHIR R4 or R5 implementation against those drafts now, while changes are still cheap to absorb, is far less painful than discovering a breaking change after go-live. This matters most for organizations planning long-lived integrations or anything with a multi-year lifespan. If a system you’re building today won’t go live until 2027 or later, designing around R6 can cut real work out of your later FHIR version migration.
Therefore, plan for that overlap to last well into the early 2030s. HL7 has signaled an R4 sunset window stretching several years past R6, largely because US Core won’t shift its baseline overnight. US Core v10, aligned with R6, is targeted for around May 2027, considering R6 itself is published on schedule.
In other words, a sound FHIR R6 readiness strategy is layered, not sudden:
- Keep your current production environment stable.
- Stand up a parallel sandbox for R6 ballot testing.
- Track which trading partners and payer connections have published their own move dates.
For more on how these standards fit into the broader data-exchange picture.
FHIR Server Upgrade Considerations
A FHIR server upgrade touches more than a version number in a config file. It touches validation rules, search parameters, terminology bindings, and every downstream integration that assumes a particular resource shape.
Gauging FHIR R6 readiness starts with knowing exactly what you’re running. Before you touch that FHIR server upgrade, map out the resources you’re using in production and see what the R6 ballot changes mean for them.
Vendors differ widely in how they handle this. For example, FUSION is built to support multiple FHIR versions concurrently.
Testing for FHIR Compatibility Early
FHIR compatibility testing shouldn’t wait for a normative release. HL7 runs its ballot process so you can catch and fix major flaws before they get locked into the standard.
Therefore, standing up a sandbox against the current ballot build, running your test suites against it, and logging every failure gives your team a concrete list of what needs attention. That kind of early testing is really at the heart of practical FHIR R6 readiness.
Teams with in-house FHIR expertise can go further by joining an HL7 consensus group or connectathon, often the fastest way to see how a proposed change behaves in practice.
A Practical FHIR R6 Readiness Checklist:
- Audit current FHIR resource usage against R6 ballot changes, not just headline features.
- Stand up a sandbox on the latest ballot build and run existing validation suites against it.
- Map which trading partners, payers, and vendors have published their own R6 timelines.
- Budget for running R4 and R6 in parallel for several years, not months.
- Track US Core v10 planning, since that will pull regulatory deadlines forward.
- Loop procurement in early if a future FHIR server upgrade will need new vendor contracts.
Most of this work doesn’t need R6 to be final. It needs attention now, while there’s time to influence outcomes.
Unlock Seamless Healthcare Interoperability with FUSION
Built by Helixbeat, FHIR server FUSION leverages RESTful APIs for seamless connectivity with legacy systems, modern EHRs, wearable devices, and telehealth platforms.
Certified Excellence
FUSION is officially certified by the Drummond Group for FHIR-based interoperability, validating its conformance with healthcare data exchange standards HL7, FHIR, and SMART on FHIR. This certification demonstrates that FUSION meets industry-recognized benchmarks for secure, standardized data exchange.
The Bottom Line
FHIR R6 is still a moving target, and details in the current ballot could shift before final publication. But the direction is clear enough to act on. Healthcare interoperability standards evolve in cycles, and organizations that treat each cycle as a planning exercise, rather than a fire drill, keep patient data flowing without disruption.
Start your FHIR R6 readiness work with Helixbeat. Get in touch with us!
FAQs
- When will FHIR R6 be officially released?
HL7 hasn’t set a fixed publish date. The current ballot, v6.0.0-ballot4, is running through 2026, and HL7 has said final publication is likely in 2026 or 2027, depending on how reconciliation and voting go.
- Do we need to migrate from FHIR R4 straight to R6, or go through R5 first?
Not necessarily. Think of R6 as an upgrade to R5, not a total rewrite. However, moving straight from R4 to R6 is a reasonable path for organizations that haven’t already invested heavily in R5. The right choice depends on your existing systems and your trading partners.
- What’s the main differenceinFHIR R5 vs R6?
R5 introduced many new resources, a good number of which stayed trial-use. R6 brings stability by settling those resources into normative status, putting an end to surprise breaking changes R6 also refines the Subscriptions framework and adds better support for handling multiple FHIR versions at once.
- Will FHIR R4 stop working once R6 is published?
No. HL7 has signaled an R4 sunset window of several years after R6 publishes, and US Core will keep supporting R4-based versions during a transition period. R4 should remain a valid target well into the early 2030s.
- How do we start testing FHIR compatibility before R6 is final?
Stand up a sandbox against the latest public ballot build, run your existing validation and integration test suites against it, and log where things break. That gives you a concrete list to work from instead of a guess about what might change.
