Which FHIR version is faster to implement?

R4, because EHR sandboxes, test servers and US Core profiles are ready for it. R5 projects often need extra mapping where partners only speak R4.

Which FHIR version do regulators prefer?

US rules point to R4-based profiles. ONC certification criterion 170.315(g)(10) requires certified EHRs to offer a standardized FHIR API built on US Core, which is an R4 implementation guide.

Should I start a new project on R4 or R5 in 2026?

R4, unless you have a specific reason not to. It's what EHRs, payers, and US regulations target. Start on R5 only for a closed system where you control both ends and need an R5-specific feature.

Not for production. HL7's version directory still lists R6 as a draft in ballot, with the second full ballot in July 2026. Follow it for roadmap planning, but do not build external interoperability on it.

How hard is an R4 to R5 migration?

Manageable if you isolated FHIR versioning behind a domain model and mapping layer. Many resources are backward-compatible in spirit, but some structures changed, so budget for mapping updates and re-validation against profiles.

Which FHIR version do US Core and USCDI require?

R4. US Core profiles are built on FHIR R4, and the USCDI data classes that US patient-access and CMS interoperability rules reference are expressed through those R4-based profiles. If you're meeting US regulatory requirements, R4 isn't just the safe choice: it's effectively the required one today.

What does "normative" mean in FHIR R4?

Normative means a part of the standard is locked and backward-compatibility is guaranteed going forward: it won't change out from under you in later releases. R4 was the first version to make core resources like Patient and Observation normative, which is a big reason it became the stable base everyone builds and integrates on.

Will R4 be deprecated when R6 ships?

No. Newer FHIR releases don't retire R4: the ecosystem, US Core, and vendor APIs remain on it, and normative resources stay compatible. R5 and R6 add capability for teams that need it, but R4 will remain the production interoperability target for the foreseeable future.

Three generations of connector plugs, the first glowing green

Version Decision Framework

FHIR R4, R5 or R6: which is right for your project?

Build on FHIR R4 today. Epic, Oracle Health (Cerner), payer patient-access APIs and US Core all target R4, and its core resources are normative. R5, published in 2023, has thin EHR support. R6 is still in ballot, so track it for planning only.

15-Minute Scoping Call All Comparisons

What is the difference between FHIR R4, R5 and R6?

Quick answer

Choose FHIR R4 for anything that must exchange data with EHRs, payers or US regulatory APIs, because that is where US Core and vendor support sit. Use R5 only in closed systems where you control both ends and need a specific R5 feature. Treat R6 as a roadmap item until HL7 publishes it.

Criterion	R4	R5 / R6
Published	R4 in 2019 (4.0.1)	R5 in March 2023; R6 still in ballot
Subscriptions	Topic-based subscriptions through a backport guide	Topic-based subscriptions in the core spec (R5)
Status	Normative core, stable	R5 published; R6 in development
EHR support	Broad (Epic, Oracle, etc.)	Limited / emerging
US regulatory target	Yes (USCDI, CMS)	No (not yet)
US Core profiles	Built on R4	Catching up
Tooling & libraries	Most mature	Improving
Best for	Production interoperability	Closed systems, forward design

What are FHIR R4, R5 and R6?

What is R4

FHIR R4 (2019) is the first release with normative core resources and the industry baseline. Epic, Oracle Health and the US patient-access ecosystem target R4, and US Core profiles build on it. When a partner says "FHIR" without a version, they mean R4.

What is R5 / R6

FHIR R5 (2023) improves many resources, workflow and subscriptions, but production EHR adoption is limited and it isn't the US regulatory target. R6 is still in ballot. Both show where the standard is heading: useful to design toward, risky to ship on today.

Key differences

Real-world support is the deciding factor

The version debate is less about features than about who you have to talk to. Because Epic, Oracle Health, payers, and US regulations target R4, that's where interoperability actually happens. Choosing R5 for an externally-integrated product means fighting the ecosystem for marginal gains.

What R5 actually adds

R5 tightens many resources, matures workflow patterns, and significantly improves the Subscriptions framework (topic-based, more reliable event delivery). If you control both ends of an integration and genuinely need those improvements, R5 can be worth it, but you lose the broad interoperability R4 gives you.

Designing for the future

The right hedge isn't picking R5 early: it's isolating FHIR version specifics behind your own domain model and mapping layer, so moving R4→R5 later is a bounded upgrade. Avoid leaking raw version-specific resource shapes throughout your codebase.

When should you choose R4, R5 or R6?

When to use FHIR R4

You need to integrate with real EHRs and payer APIs today.
You're meeting US regulatory requirements (USCDI, CMS interoperability, patient access).
You want maximum tooling, library, and community support.
You value stability and normative resources over the newest features.

When to use FHIR R5 / R6

You're building a closed system with no external EHR dependency and want R5 features.
You need a specific R5 improvement (e.g. refined Subscriptions) and control both ends.
You're prototyping or contributing to the standard and want the latest resources.
You're planning architecture now for a multi-year horizon and want R6 on the roadmap.

How do you move from R4 to R5 later?

Keep FHIR version details behind your own domain model and mapping layer, so an upgrade changes the mappers, not the whole codebase.

Re-validate every profile you rely on after the move, and run old and new endpoints side by side until partners switch.

Which sources does this comparison rely on?

FHIR development services FHIR Integration & API Development SMART on FHIR App Development USCDI vs US Core version mapping FHIR vs HL7 v2: Which to Use EMR vs EHR Epic vs Oracle Health (Cerner) integration

Frequently Asked Questions

R4 for most teams. Its tooling, libraries and partner support are mature, so there is less custom work to maintain. R5 can pay off in a closed system that needs its newer features.

Not sure which fits your build?

Tell us about your product, integration targets, and timeline. We'll map the trade-offs to your context and recommend the path that gets you to a compliant launch fastest.

15-Minute Scoping Call Explore Solutions