"Should I upgrade to FHIR R5?" This is, without exaggeration, the most frequently asked question in every FHIR developer forum, Zulip channel, and architecture review meeting in 2026. And now, with R6 on the horizon, the question has evolved into something more complex: "Should I skip R5 entirely?"
The answer is not as simple as "always use the latest version." FHIR version selection has real consequences for regulatory compliance, vendor compatibility, development timelines, and long-term maintainability. A wrong choice can lock you into a migration path that costs hundreds of thousands of dollars and months of engineering time.
This guide provides a definitive, technically grounded decision framework. We analyze the concrete differences between R4, R5, and R6, examine what the major EHR vendors actually support (not what they claim on marketing pages), and give you a step-by-step migration strategy based on where you are today.
The FHIR Version Landscape in 2026
FHIR has come a long way since its first Draft Standard for Trial Use (DSTU1) in 2014. The specification has grown from 49 resources in DSTU2 to 145 resources in R5, reflecting the expanding scope of healthcare interoperability beyond clinical data into administrative, financial, and public health domains.
Here is where each version stands as of early 2026:
- FHIR R4 (v4.0.1) — Released March 2019. First version with normative content. The global production standard. Required by US Core IG, India's ABDM Implementation Guide, and the foundation for the EU's European Health Data Space (EHDS) profiles.
- FHIR R5 (v5.0.0) — Released March 2023. A Standard for Trial Use (STU) release with significant new features but also breaking changes. Not adopted by major EHR vendors. No regulatory mandate references it.
- FHIR R6 — Normative ballot process started January 2026, with final publication expected in 2027 or later. Promises backward compatibility with R4's normative resources. Currently in early ballot review at hl7.org/fhir/6.0.0-ballot1.
The Firely State of FHIR 2025 survey puts hard numbers behind the adoption picture: 40% of respondents use R4 as their primary version, and 54% expect strong increases in FHIR adoption over the next two years (up from 39% in 2024). Meanwhile, R5 adoption remains in the single digits.
Perhaps even more telling: Firely's global survey found that 78% of countries now have regulations for electronic health data exchange, and 73% of those either mandate or advise the use of FHIR. Nearly all of these mandates reference R4.
The HL7 FHIR compliance market reflects this momentum. According to market research cited by Morningstar/AccessWire, the market was valued at $2.3 billion in 2025 and is projected to reach $8.6 billion by 2036, a compound annual growth rate driven by regulatory mandates worldwide.
FHIR R4: The Proven Standard
R4 is not just the most widely adopted FHIR version. It is the only version with normative resources, meaning HL7 has committed to their stability. The Patient, Observation, and Bundle resources (among others) in R4 carry a normative maturity level, which guarantees backward compatibility in future versions.
This normative commitment is what separates R4 from every prior FHIR release. When you build against R4 normative resources, you are building on a specification that HL7 has promised will not break in R5, R6, or beyond.
Regulatory Backing
Every major interoperability regulation in the world currently references R4:
- United States: The ONC's US Core Implementation Guide is built on R4. The 21st Century Cures Act and CMS Interoperability and Patient Access rules require FHIR R4 for Patient Access and Provider Directory APIs. The HTI-5 proposed rule (December 2025) goes further, proposing to remove legacy C-CDA certification requirements in favor of a FHIR-first approach. For a deeper dive into what these rules mean for your organization, see our guide to CMS interoperability rules in 2026. Organizations with legacy systems often adopt a FHIR Facade pattern to meet these mandates without replacing existing infrastructure.
- India: The Ayushman Bharat Digital Mission (ABDM) Implementation Guide mandates FHIR R4 for all health information exchange, covering M1 (registration), M2 (discovery and linking), and M3 (consent-based data sharing). We cover the India ABDM vs US TEFCA comparison in a separate analysis.
- European Union: The European Health Data Space (EHDS) regulation, adopted in 2025, references FHIR-based profiles built on R4 for cross-border health data exchange. The HL7 Europe FHIR IG uses R4 as its base.
- Australia: HL7 Australia's AU Core IG is based on R4 and is being referenced in the My Health Record modernization program.
Vendor Ecosystem
R4 is the only version with broad EHR vendor support. Epic's FHIR APIs are R4. Oracle Health (formerly Cerner) exposes R4 endpoints. Every major FHIR server implementation (HAPI FHIR, Firely Server, Google Cloud Healthcare API, AWS HealthLake, Azure Health Data Services) has production-grade R4 support. If you are evaluating FHIR data stores, our comparison of HAPI, Google, AWS HealthLake, and Azure covers the specifics.
What R4 Gets Right
- Normative stability: Core resources (Patient, Observation, Bundle, CapabilityStatement) are normative and will not change in breaking ways.
- Mature tooling: Every major FHIR library (HAPI FHIR for Java, Firely SDK for .NET, fhir.resources for Python, node-fhir for JavaScript) has robust R4 support.
- Implementation Guide ecosystem: US Core, IPA (International Patient Access), SMART App Launch, Bulk Data Access, mCODE (oncology), Da Vinci (payer exchange) are all R4-based.
- Testing infrastructure: Inferno (ONC's official testing framework), Touchstone, and Crucible all have comprehensive R4 test suites.
FHIR R5: The Awkward Middle Child
R5 was published in March 2023 with genuine technical improvements. The problem is not that R5 is bad. The problem is that it introduced breaking changes at a time when the ecosystem was still catching up to R4, and no regulatory body or major vendor committed to it.
What R5 Brings to the Table
R5 includes meaningful improvements that address real limitations in R4:
- Subscriptions rewrite: The R4 Subscription resource was limited to a single channel per subscription and used a criteria-based model. R5 replaces this entirely with a topic-based subscription model using the new SubscriptionTopic and SubscriptionStatus resources, offering better scalability and more granular control.
- New data types: R5 introduces CodeableReference (combining CodeableConcept and Reference), integer64 for large identifiers, and RatioRange for complex dosage calculations.
- ActorDefinition and Requirements resources: New resources for formally defining system actors and implementation requirements within the specification.
- SubscriptionTopic-based architecture: Servers define topics, clients subscribe to them. This is architecturally superior to R4's polling or criteria-matching model.
- Improved search: New search parameters, better composite search support, and the _filter parameter for complex queries.
What R5 Breaks
This is where the practical problems begin. R5 includes several breaking changes that make migration non-trivial:
- Media resource removed: The Media resource is gone entirely. All media content must now use DocumentReference, which has a different structure, different search parameters, and different semantics.
- Subscription completely rewritten: R4 Subscription resources are not compatible with R5. This is not an incremental change; it is a full replacement of the subscription model.
- Consent model restructured: The Consent resource has been significantly reworked, breaking existing consent management implementations.
- DeviceComponent merged into Device: Two separate R4 resources become one in R5.
- MedicinalProductDefinition refactored: The pharmaceutical product resources were reorganized.
- Element-level changes across core resources: While normative resources maintain backward compatibility for their normative elements, many STU-level elements within those resources have changed names, cardinality, or types.
Why Vendors Are Not Adopting R5
The vendor situation is stark. As documented by Health Samurai's analysis, Epic and Oracle Health officially do not support R5. These two vendors collectively cover a majority of the US hospital market. When your EHR vendor does not support a FHIR version, building against that version means you cannot interoperate with most health systems.
The InterSystems Developer Community and dev.to discussions reflect the developer community's consensus: R5 adoption is being skipped by most organizations. The common plan is to wait for R6 and jump directly from R4.
HAPI FHIR server supports R5 for development and testing, as does Firely Server. But support from a FHIR server is not the same as support from the EHR ecosystem you need to exchange data with.
FHIR R6: The Promised Land
R6 is where the FHIR community's attention is now focused. The HL7 FHIR working group announced that the R6 normative ballot process started in January 2026, with the first ballot cycle available at hl7.org/fhir/6.0.0-ballot1. Final publication is expected in 2027 at the earliest, though HL7 ballot timelines have historically been optimistic.
What We Know About R6
- Backward compatibility commitment: R6 is being designed with an explicit goal of maintaining backward compatibility with R4's normative resources. A valid R4 Patient resource should be processable by an R6 server without modification.
- Expanded normative content: More resources are expected to achieve normative status in R6, reducing the surface area of potential breaking changes in future versions.
- R5 features stabilized: The R5 improvements (topic-based subscriptions, new data types, CodeableReference) will be carried forward and refined, giving them a path to normative status.
- Improved versioning strategy: HL7 is developing a clearer approach to version migration, including better tooling for version detection and translation.
What R6 Means for Your Roadmap
R6 is the next version that will matter for production deployments. If you are currently on R4, R6 represents the natural upgrade path. The backward compatibility commitment means that your R4 normative resource implementations should survive the transition with minimal changes.
However, R6 is not here yet. It is in ballot, and ballot processes involve multiple cycles of review, comment, and revision. Making engineering decisions based on an unfinished specification is risky. The prudent approach is to build on R4 today and track R6 ballot progress so you can plan your migration once the specification stabilizes.
Breaking Changes: A Technical Deep-Dive
Abstract comparisons are not enough to make engineering decisions. Let us look at the specific changes that affect real implementations.
Resource-Level Changes Across Versions
| Area | R4 (v4.0.1) | R5 (v5.0.0) | R6 (ballot) |
|---|---|---|---|
| Patient | Normative. Stable. | Normative elements unchanged. New communication.preferred behavior. | Expected normative. Backward compatible. |
| Observation | Normative. Widely implemented. | New triggeredBy element. Observation.component refined. | Expected normative. Additive changes only. |
| Subscription | Criteria-based. Single channel per resource. | Completely replaced: SubscriptionTopic + SubscriptionStatus model. | R5 subscription model carried forward and refined. |
| Media | Standalone resource for images, video, audio. | Removed. Use DocumentReference with content.attachment. | Media remains removed. DocumentReference is the path forward. |
| Consent | Consent.provision with nested rules. | Restructured: Consent.decision, Consent.provision simplified. | R5 consent model carried forward. |
| DeviceComponent | Separate resource. | Merged into Device. | Remains merged in Device. |
| Bundle | Normative. Stable. | Normative elements unchanged. | Expected normative. Backward compatible. |
| CapabilityStatement | Normative. | New elements for subscription topics, R5-specific features. | Extended for R6 capabilities. |
Code Example: R4 Subscription vs. R5 Topic-Based Subscription
The Subscription change is the most impactful breaking change for systems that rely on real-time notifications. Here is the concrete difference:
R4 Subscription (criteria-based):
{
"resourceType": "Subscription",
"status": "requested",
"criteria": "Observation?patient=Patient/123&code=http://loinc.org|85354-9",
"channel": {
"type": "rest-hook",
"endpoint": "https://your-app.example.com/fhir-notifications",
"payload": "application/fhir+json",
"header": [
"Authorization: Bearer your-secret-token"
]
},
"reason": "Monitor blood pressure observations for Patient 123",
"end": "2026-12-31T23:59:59Z"
}R5 Subscription (topic-based):
{
"resourceType": "Subscription",
"status": "requested",
"topic": "http://example.org/SubscriptionTopic/new-observation",
"filterBy": [
{
"resourceType": "Observation",
"filterParameter": "patient",
"value": "Patient/123"
},
{
"resourceType": "Observation",
"filterParameter": "code",
"value": "http://loinc.org|85354-9"
}
],
"channelType": {
"system": "http://terminology.hl7.org/CodeSystem/subscription-channel-type",
"code": "rest-hook"
},
"endpoint": "https://your-app.example.com/fhir-notifications",
"contentType": "application/fhir+json",
"content": "full-resource",
"heartbeatPeriod": 120,
"timeout": 60,
"maxCount": 100
}Note the structural differences: the flat criteria string is replaced by structured filterBy entries. The channel object is flattened into top-level elements. The topic reference connects to a separately defined SubscriptionTopic resource that the server publishes. This is a fundamentally different architecture, not a simple field rename.
Code Example: Media to DocumentReference Migration
The Media resource removal affects any system that stores or references clinical images, diagnostic media, or audio recordings.
R4 Media resource:
{
"resourceType": "Media",
"status": "completed",
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/media-type",
"code": "image",
"display": "Image"
}
]
},
"subject": {
"reference": "Patient/123"
},
"createdDateTime": "2026-03-15T10:30:00Z",
"operator": {
"reference": "Practitioner/456"
},
"content": {
"contentType": "image/jpeg",
"url": "https://imaging.example.com/wound-photo-001.jpg",
"title": "Wound assessment photograph - left lower leg"
},
"width": 1920,
"height": 1080
}Equivalent R5 DocumentReference:
{
"resourceType": "DocumentReference",
"status": "current",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "72170-4",
"display": "Photographic image"
}
]
},
"subject": {
"reference": "Patient/123"
},
"date": "2026-03-15T10:30:00Z",
"author": [
{
"reference": "Practitioner/456"
}
],
"content": [
{
"attachment": {
"contentType": "image/jpeg",
"url": "https://imaging.example.com/wound-photo-001.jpg",
"title": "Wound assessment photograph - left lower leg",
"width": 1920,
"height": 1080
}
}
]
}The migration is not a simple rename. The element mappings are different: operator becomes author (an array), content becomes content[].attachment (nested within an array), and width/height move from the resource level into the attachment. Any code that parses Media resources needs to be rewritten, not just re-mapped.
Code Example: Patient Resource (Stable Across Versions)
For contrast, here is what stability looks like. The Patient resource is normative, and a valid R4 Patient works identically in R5 and R6:
{
"resourceType": "Patient",
"id": "example-patient",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]
},
"identifier": [
{
"system": "http://hospital.example.com/mrn",
"value": "MRN-20260402-001"
}
],
"active": true,
"name": [
{
"use": "official",
"family": "Sharma",
"given": ["Priya"]
}
],
"gender": "female",
"birthDate": "1985-07-14"
}This resource is valid in R4, R5, and R6 without modification. This is the power of normative content and the reason R4's normative resources are a safe foundation for long-term investment.
The Decision Framework
Based on the technical analysis above, here is a concrete decision framework for choosing your FHIR version in 2026.
Scenario 1: Starting a New Project
Recommendation: Use R4.
Every new FHIR implementation in 2026 should start with R4. The regulatory landscape requires it, the vendor ecosystem supports it, and the tooling is mature. Starting with R5 gains you nothing that cannot be achieved through R4 extensions and backport Implementation Guides, while cutting you off from the majority of the EHR ecosystem.
If you are building a FHIR-based platform, our guide to creating a FHIR store on Google Cloud Healthcare API walks through production setup using R4.
Scenario 2: Already on R4, Considering Upgrade
Recommendation: Stay on R4. Prepare for R6.
If your system is running on R4 and working, there is no compelling reason to migrate to R5. The breaking changes (Media removal, Subscription rewrite, Consent restructuring) impose real engineering cost with no corresponding regulatory or business benefit. Instead, invest that engineering time in preparing for R6:
- Abstract your FHIR version dependencies behind an internal API layer.
- Avoid deep coupling to STU-level resources that are likely to change.
- If you need R5 features like topic-based subscriptions, use the Subscriptions R5 Backport IG, which provides the R5 subscription model on top of R4.
Scenario 3: On an Older Version (STU3 or DSTU2)
Recommendation: Migrate to R4 immediately.
STU3 and DSTU2 are legacy versions with declining support. Many FHIR servers have already deprecated or are actively removing DSTU2 endpoints. The migration path from STU3 to R4 is well-documented, and the ROI is clear: regulatory compliance, vendor interoperability, and access to the modern IG ecosystem. For organizations moving from older HL7 standards, our HL7v2 to FHIR migration guide covers the end-to-end process.
Scenario 4: Need a Specific R5 Feature
Recommendation: Use R4 with backport IGs or extensions.
HL7 publishes backport Implementation Guides that bring R5 capabilities to R4 systems. The Subscriptions R5 Backport IG is the most mature example. For other features, R4 extensions can represent R5 data elements without requiring a version migration. This gives you the functionality you need while maintaining ecosystem compatibility.
Scenario 5: Building a FHIR Server or Platform
Recommendation: Support R4 as primary. Add R5 support for forward compatibility. Track R6.
If you are building infrastructure (a FHIR server, integration engine, or data platform), you have a different calculus. Your users may need R5 for testing or development, and you will want to be ready for R6 when it arrives. Design your architecture to support multiple FHIR versions simultaneously, with R4 as the default and R5 as an opt-in capability.
Version Migration Strategy
When R6 reaches normative status (expected 2027), organizations on R4 will need a migration plan. Here is a practical strategy you can start executing today.
Phase 1: Inventory and Abstraction (Now)
- Catalog your FHIR resource usage. Document every resource type your system creates, reads, updates, or deletes. Flag which resources are normative (safe) and which are STU-level (may change).
- Introduce a FHIR version abstraction layer. Do not let your business logic directly depend on FHIR resource structures. Use an internal model that maps to FHIR through a translation layer. This is the single highest-ROI investment for version migration.
- Identify your R5 exposure. If you use Media, Subscription, Consent, or DeviceComponent resources, you have direct exposure to R5 breaking changes. Quantify the effort required to migrate each one.
Phase 2: Dual-Version Testing (When R6 Ballot Stabilizes)
- Set up R6 test environments. Use HAPI FHIR server's multi-version support to stand up an R6 endpoint alongside your R4 production system.
- Run your test suite against both versions. Automated integration tests should validate that your R4 resources are accepted by R6 endpoints. Normative resources should pass without changes.
- Build version-aware API endpoints. Implement content negotiation using the
fhirVersionMIME type parameter (application/fhir+json; fhirVersion=4.0) so clients can request specific versions. For guidance on API security across versions, see our healthcare API security guide covering OAuth, SMART on FHIR, and HIPAA.
Phase 3: R6 Pilot (Post-Publication)
- Migrate non-critical systems first. Analytics dashboards, research data pipelines, and internal tools are lower-risk candidates for early R6 migration.
- Run dual-version production. Serve both R4 and R6 from the same system. Route traffic based on client capability. This is how the industry migrated from STU3 to R4, and it works.
- Validate with trading partners. Confirm that your EHR vendors, payers, and HIE partners can consume your R6 resources before cutting over.
Phase 4: Production Migration
- Migrate resource by resource. Start with normative resources (Patient, Observation, Bundle), which should require minimal changes. Then migrate STU resources that changed between R4 and R6.
- Update Implementation Guide conformance. Ensure your CapabilityStatement reflects R6 support and your resource profiles are validated against R6 StructureDefinitions.
- Deprecate R4 endpoints on a published timeline. Give your consumers 12-18 months of dual support before retiring R4 endpoints.
Regional Considerations
FHIR version selection is not just a technical decision. It is constrained by the regulatory environment where you operate.
United States
R4 is non-negotiable for US healthcare. The US Core IG (currently at version 7.0.0) requires R4. The USCDI (United States Core Data for Interoperability) data classes map to R4 profiles. CMS Interoperability rules reference R4. The HTI-5 proposed rule (published December 2025) signals an even deeper commitment to FHIR by proposing to remove C-CDA certification in favor of FHIR-native exchange.
No US regulatory body has referenced R5. The earliest R6 could appear in US regulations is 2028-2029, given the typical 2-3 year lag between HL7 publication and ONC rulemaking.
India
India's ABDM mandates FHIR R4 through its NDHM Health Data Interchange (HDI) specification. All Health Information Providers (HIPs) and Health Information Users (HIUs) must support R4 for M2 (discovery/linking) and M3 (consent-based data sharing) flows. The ABDM FHIR IG references R4 resources for Bundle composition, and all certified integrations are validated against R4 profiles.
European Union
The EHDS regulation (adopted 2025) establishes the framework for cross-border health data exchange. The technical specifications under development by the EU eHealth Network reference R4-based profiles. HL7 Europe's base IG uses R4. The EU is unlikely to mandate a newer version until R6 reaches normative status and member states have had time to evaluate it.
Australia and New Zealand
HL7 Australia's AU Core IG (based on R4) is becoming the standard for government health programs. The My Health Record system's modernization roadmap includes FHIR R4 APIs. New Zealand's Health Information Standards Organisation (HISO) references R4 in its interoperability standards.
Implications for Global Systems
If your system operates across multiple regions, R4 is the only version that satisfies all regulatory environments simultaneously. There is no jurisdiction that requires R5, and R6 is not yet published. A multi-region system built on R4 today will be compliant everywhere.
Frequently Asked Questions
Will R4 be deprecated when R6 is published?
No. HL7 does not deprecate FHIR versions in the way that software vendors deprecate product versions. R4 normative resources are guaranteed to remain valid. US Core and other IGs will eventually publish R6-based versions, but the R4 versions will continue to work. Expect a multi-year coexistence period, similar to the STU3/R4 overlap that persisted from 2019 through 2023.
Can I use R5 resources within an R4 system?
Not directly in the same API endpoint. However, you can achieve much of R5's functionality within R4 through backport Implementation Guides and FHIR extensions. The Subscriptions R5 Backport IG is the most prominent example, providing the topic-based subscription model on R4 infrastructure. For custom needs, define R4 extensions that carry R5 data elements.
How long will the R6 ballot take?
HL7 ballot processes are multi-cycle. The first ballot opened in January 2026. Based on historical precedent (R4 went through three ballot cycles over approximately 18 months), R6 final publication is most likely in mid-to-late 2027. However, delays are common; plan for 2027 as optimistic and 2028 as realistic.
Should I use FHIR R4B?
R4B (v4.3.0) was a minor update published in 2022 that introduced a small number of changes to support IGs that needed features between R4 and R5. It is not widely adopted and adds complexity without significant benefit for most implementations. Stick with R4 (v4.0.1) unless you have a specific IG dependency on R4B.
What about CDS Hooks and SMART on FHIR across versions?
CDS Hooks and SMART App Launch are independent specifications that are version-aware but not version-locked. SMART App Launch 2.0 works with both R4 and R5. CDS Hooks use FHIR resources in their payloads but support version negotiation. Your SMART on FHIR apps built for R4 will work with R6 servers that support R4 resources.
Is there a tool that converts R4 resources to R5 automatically?
HL7 publishes FHIR R4 to R5 conversion maps for many resources. HAPI FHIR includes a version converter module. However, automatic conversion has limits: it handles structural transformations but cannot resolve semantic differences (such as the complete Subscription model change). Conversion tools are useful for data migration but should not be relied upon for API-level version support. For a broader view of healthcare standards and how they interrelate, see our guide to interoperability standards including FHIR, HL7, and more.
The Bottom Line
The FHIR version decision in 2026 is clear for the vast majority of organizations:
- Build on R4. It is normative, regulatory-mandated, vendor-supported, and will remain valid through and beyond R6.
- Skip R5. It has real technical improvements, but the breaking changes and lack of vendor/regulatory adoption make it a poor investment for production systems.
- Prepare for R6. Abstract your FHIR dependencies, monitor the ballot process, and plan a migration timeline for 2027-2028.
The organizations that will migrate most smoothly from R4 to R6 are those that invest in version abstraction today. An internal API layer that shields your business logic from FHIR version specifics is the single best engineering investment you can make right now.
This is not a theoretical concern. The $8.6 billion FHIR compliance market projected for 2036 will be built on the foundation being laid today. Whether you are a health system, a digital health startup, a payer, or an integration vendor, your FHIR version strategy determines your interoperability ceiling for the next decade.
At Nirmitee, we build FHIR-native healthcare platforms across R4 with forward-compatible architectures designed for the R6 transition. Whether you need a greenfield FHIR implementation, a version migration strategy, or a custom integration with Epic, Oracle Health, or ABDM, our engineering team has done it in production. Talk to us about your interoperability roadmap.
