FHIR R4 vs R5 vs R6
Build on FHIR R4 today. It's the version every major EHR, patient-access API, and US regulation (USCDI, CMS rules) actually targets, and it's a normative, stable base. R5 (2023) refines resources and adds capability but has thin real-world EHR support, so treat it as forward-looking. R6 is still in development — track it, don't build on it. Design your data layer so a future R4→R5 move is an upgrade, not a rewrite.
Quick answer
Production in 2026 → R4. R5 → selective/forward-looking use. R6 → watch only, not yet shippable.
Decision table at a glance
| Criterion | R4 | R5 / R6 |
|---|---|---|
| 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 they are
What is R4
R4 (2019) is the first release with normative (locked) core resources and the de-facto industry baseline. Epic, Oracle Health, and the US patient-access ecosystem target R4, and US Core profiles are built on it. If a partner or regulator says "FHIR" without a version, they mean R4.
What is R5 / R6
R5 (2023) improves many resources, workflow, and subscriptions, but adoption across production EHRs is limited and it isn't the US regulatory target. R6 is still under active ballot/development. Both are where the standard is heading — useful to design toward, risky to ship on for external interoperability right now.
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 to use each
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.
Frequently Asked Questions
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.