FHIR R4 vs R5 vs R6: Which to Implement?

FHIR (Fast Healthcare Interoperability Resources) is the modern standard for healthcare data exchange. Developed by HL7 International, FHIR provides a RESTful, resource-based framework for building healthcare APIs. If you are building patient-facing applications, integrating with EHR systems, exchanging data with payers, or connecting clinical systems, FHIR is almost certainly part of your architecture.

But FHIR is not a single specification. There are three active versions: R4 (the current production standard), R5 (the next generation, published in 2023), and R6 (currently in ballot, expected late 2026). Each version adds capabilities, but not every version is appropriate for every project. Implementing the wrong version can lead to compatibility issues, wasted development effort, or regulatory non-compliance.

This guide compares all three versions in detail and provides a practical decision framework for choosing the right one.

What Is FHIR?

For readers encountering FHIR for the first time, here is a brief overview. FHIR stands for Fast Healthcare Interoperability Resources. It is a standard published by HL7 International that defines how healthcare data should be structured, queried, and exchanged between systems.

FHIR organizes clinical and administrative data into resources. A resource is a discrete unit of data with a defined structure. The Patient resource holds demographic information. The Observation resource holds lab results, vital signs, and other measurements. The Condition resource holds diagnoses. There are approximately 150 resource types covering everything from medication orders to insurance claims to genomic data.

FHIR resources are exchanged using standard web technologies. The API follows REST conventions: you create resources with POST, read them with GET, update them with PUT, and search for them with GET plus query parameters. Data is formatted as JSON or XML. Authentication uses OAuth 2.0, specifically the SMART on FHIR profile that adds healthcare-specific context like patient and encounter scoping.

Every major EHR vendor — Epic, Oracle Health (Cerner), athenahealth, MEDITECH, Allscripts — exposes FHIR APIs. US federal regulations (ONC Cures Act, CMS Interoperability rules) require certified health IT systems to support FHIR-based patient access. FHIR is not optional for modern healthcare IT. The question is which version to implement.

FHIR R4: The Current Standard

Release and Maturity

FHIR R4 was published in January 2019. It was the first FHIR release to include normative content. Normative means the specification is stable and will not introduce breaking changes. Specifically, the RESTful API, the Patient resource, the Observation resource, and several other core components were declared normative in R4. This was a deliberate signal to the industry: you can build production systems on R4 with confidence that the foundation will not shift.

Prior FHIR releases (DSTU2, STU3) were explicitly labeled as drafts and could change between versions. This made organizations reluctant to invest heavily in FHIR implementations. R4’s normative status removed that barrier.

Regulatory Foundation

R4 is the version required by US federal regulation. The ONC Cures Act Final Rule mandates that certified EHR technology support the FHIR-based US Core Implementation Guide, which is built on R4. The CMS Patient Access API, Provider Directory API, and Drug Formulary API all require R4. If your project must comply with federal interoperability rules, R4 is not just recommended — it is required.

US Core, the foundational implementation guide for FHIR in the United States, has published multiple versions on R4. US Core v3.1.1 was the initial regulatory baseline. US Core v6.1 and v7.0 added additional profiles and requirements while remaining on R4. The entire US FHIR ecosystem — Da Vinci (payer/provider exchange), CARIN Blue Button (claims data), Validated Healthcare Directory, and dozens of others — is built on R4.

EHR Vendor Support

Every major EHR vendor’s FHIR API is based on R4. Epic’s open FHIR APIs support R4. Oracle Health (Cerner) Millennium’s FHIR APIs support R4. athenahealth’s FHIR APIs support R4. If you are building an application that reads or writes data from an EHR system, you are using R4.

Some vendors have begun experimental R5 support, but it is not their primary offering. Production integrations run on R4.

Key Capabilities

R4 provides comprehensive support for common healthcare integration scenarios:

• SMART on FHIR v1: Standardized OAuth 2.0 flows for EHR launch, standalone launch, and backend services.
• US Core profiles: Constrained resource definitions that ensure interoperability across certified systems.
• Bulk Data Access: The $export operation for extracting population-level data in NDJSON format.
• FHIR Subscriptions (R4 backport): While the original R4 Subscription resource was limited, a backport of R5’s improved Subscriptions framework is available for R4 servers.
• Search API: Comprehensive search parameters for each resource type, including chained searches, reverse includes, and composite parameters.

Limitations

R4 was published in 2019. Since then, the healthcare industry has identified gaps that R5 and R6 address:

• Limited Subscription model: R4’s native Subscription resource requires a client to define a search criteria string that the server evaluates on every resource change. This is inefficient and hard to scale. (The R5 backport addresses this, but it is not part of the base R4 specification.)
• Missing resource types: Several resource types that the industry needs were not mature enough for R4, including NutritionIntake, InventoryReport, and others added in R5.
• Search limitations: Some search operations that developers commonly need (e.g., searching across multiple resource types efficiently) are not well-supported in R4’s search specification.

FHIR R5: The Next Generation

Release and Status

FHIR R5 was published in March 2023 as a Standard for Trial Use (STU) with additional normative content. It builds on R4’s foundation while adding significant new capabilities. The additional normative content in R5 includes expansions to the core data types and the RESTful API specification.

R5 is a published standard. It is not a draft or a preview. Organizations can implement it today. However, the healthcare industry moves slowly, and R5 adoption in production is still limited. Most of the momentum is in new projects, research environments, and forward-thinking organizations that want the improved Subscription framework or new resource types.

Key New Features

Improved Subscriptions Framework

The most significant change in R5 is the redesigned Subscriptions model. R4’s Subscription resource was a single resource with a criteria string that the server had to evaluate on every resource change. R5 replaces this with a multi-resource model:

• SubscriptionTopic: Defines what events can be subscribed to (e.g., “a new Encounter was created,” “an Observation with a critical value was recorded”). SubscriptionTopics are defined by the server and discovered by clients.
• Subscription: A client’s request to receive notifications for a specific SubscriptionTopic, with filters (e.g., “only Encounters for patients in my organization”).
• SubscriptionStatus: Communicates the current state of a subscription, including event counts and error information.

This model is dramatically more scalable and flexible than R4’s approach. Servers can implement SubscriptionTopics efficiently (pre-compiled event detection rather than per-change criteria evaluation), and clients can discover what events are available without guessing.

{
  "resourceType": "Subscription",
  "status": "requested",
  "topic": "http://example.org/SubscriptionTopic/encounter-create",
  "reason": "Notify when new encounters are created",
  "filterBy": [
    {
      "resourceType": "Encounter",
      "filterParameter": "patient",
      "value": "Patient/123"
    }
  ],
  "channelType": {
    "system": "http://terminology.hl7.org/CodeSystem/subscription-channel-type",
    "code": "rest-hook"
  },
  "endpoint": "https://my-app.example.com/fhir-notifications",
  "contentType": "application/fhir+json",
  "content": "id-only"
}

New Resource Types

R5 introduces several new resource types that address gaps in R4:

• NutritionIntake: Tracks what a patient actually consumed (as opposed to NutritionOrder, which tracks what was ordered). Important for clinical nutrition monitoring.
• InventoryReport: Tracks medical supply and medication inventory. Relevant for pharmacy and supply chain management.
• Permission: Provides a framework for expressing patient consent and access control decisions as computable resources.
• EvidenceReport: Supports clinical evidence and research findings as structured FHIR resources.
• Transport: Represents the movement of items (specimens, medications, equipment) between locations.

Enhanced Search

R5 improves search capabilities in several ways:

• _filter parameter: Provides a more expressive query syntax beyond the basic search parameter model. You can construct complex boolean expressions combining multiple search criteria.
• Improved _include and _revinclude: Better support for iterative includes, reducing the number of API calls needed to retrieve related resources.
• Canonical references: Improved handling of references to canonical resources (CodeSystem, ValueSet, ImplementationGuide), making it easier to build and query knowledge management systems.

Other Improvements

• Cross-version extensions: A framework for carrying R4 data in R5 resources and vice versa, easing migration.
• Improved CodeSystem and ValueSet operations: Better support for terminology services, including improved $validate-code and $expand operations.
• Genomics support: Enhanced resources and profiles for genomic data, including improvements to MolecularSequence and related resources.

Who Is Using R5 Today

R5 adoption is primarily in:

• Organizations that need the improved Subscriptions framework for real-time notification workflows.
• Health information exchanges (HIEs) and FHIR server vendors building next-generation platforms.
• Research institutions working with genomic data or clinical evidence resources.
• Implementation guide authors who want to build on the latest specification capabilities.

Limitations

• Limited EHR vendor support: Epic, Oracle Health, and athenahealth do not yet offer production R5 APIs. Until they do, applications that need to read/write EHR data must use R4.
• US Core is on R4: The US Core Implementation Guide, which is the regulatory baseline for US FHIR implementations, has not moved to R5. US Core v7.0 targets R4.
• Smaller ecosystem: Fewer implementation guides, fewer reference implementations, and fewer developers with R5 experience compared to R4.

FHIR R6: On the Horizon

Current Status

FHIR R6 is in active development. The third ballot version (v6.0.0-ballot3) was published in December 2025. HL7 expects to publish the final R6 specification in late 2026, assuming the ballot process proceeds on schedule.

R6 is not a published standard yet. It is a ballot draft, meaning the specification is subject to change based on ballot comments and reconciliation. Implementing R6 today means building against a moving target.

Expected Changes

Based on the ballot drafts, R6 is expected to include:

• More normative content: Additional resource types and operations elevated to normative status, expanding the stable core of the specification.
• Improved cross-version compatibility: Better tooling and specification support for systems that need to handle multiple FHIR versions simultaneously.
• Refined Subscriptions: Further improvements to the R5 Subscriptions framework based on implementation experience.
• International profiles: Better support for non-US healthcare systems, including International Patient Summary (IPS) alignment.
• Matured R5 resources: Resources introduced as STU in R5 (NutritionIntake, InventoryReport, etc.) may reach normative status in R6 based on implementation feedback.

US Core and R6

HL7 has announced that US Core v10 is planned for R6, with a target date of May 2027 — contingent on R6 being published by September 2026. This is significant because US Core is the regulatory foundation for FHIR in the United States. When US Core moves to R6, the regulatory baseline moves with it (after an adoption period).

However, the R4-based US Core versions will remain valid during a transition period. HL7 has indicated an R4 sunset window of 4-6 years after R6 is published and aligned with regulatory enforcement timelines. In practical terms, this means R4 will remain a valid implementation target well into the early 2030s.

Version Comparison Table

Decision Framework: Which Version to Implement

Choosing a FHIR version is a pragmatic decision driven by your project’s requirements, timeline, and integration partners. Here is a decision framework.

Implement R4 If…

You need to go live in the near term. R4 has the broadest ecosystem support. Every EHR vendor, every major FHIR server (HAPI, Firely, Microsoft AHDS, Google Cloud Healthcare API, AWS HealthLake), and every implementation guide you are likely to need is available for R4. You will not hit ecosystem gaps.

You must comply with US federal regulations. ONC and CMS mandate R4. Period. If your project involves certified health IT, patient access APIs, payer interoperability, or any other federally regulated data exchange, R4 is required.

You are integrating with Epic, Oracle Health, or athenahealth. These vendors’ FHIR APIs are R4-based. If your application reads or writes data through an EHR FHIR API, you are implementing R4 whether you choose to or not.

You need production-proven stability. R4 has been in production since 2019. Seven years of implementation experience have surfaced and addressed edge cases, performance characteristics, and interoperability issues. The normative components are stable by specification.

Implement R5 If…

You have advanced real-time notification requirements. If your architecture relies heavily on event-driven workflows — triggering actions when specific FHIR resources are created or updated — R5’s SubscriptionTopic framework is a significant improvement over R4’s basic Subscription resource. The R5 Subscriptions backport to R4 is available, but implementing native R5 is cleaner.

You are building a platform or FHIR server. If you are a health IT vendor building a FHIR server or platform, implementing R5 positions your product ahead of the market. You can still support R4 clients through version negotiation, but your internal data model benefits from R5’s improvements.

Your project timeline extends into 2027-2028. If your project will not go live until 2027 or later, the ecosystem will have shifted further toward R5 by then. Starting with R5 avoids a near-term migration.

You need new resource types. If your use case involves clinical nutrition tracking (NutritionIntake), inventory management (InventoryReport), or consent management (Permission), these resources only exist in R5 and later.

Important caveat: If your R5 application needs to exchange data with R4-based EHRs (which is almost certainly the case), you need a cross-version translation layer. Your application can be built on R5 internally, but it must speak R4 to external systems. Plan for this complexity.

Monitor R6 (Do Not Implement Yet) If…

R6 is still in ballot. The specification is subject to change. Implementing against a ballot draft means you may need to rework your implementation when the final version is published. This is acceptable for research prototypes but not for production systems.

No EHR vendor supports R6. There are no production FHIR APIs offering R6 resources today.

No implementation guides target R6 yet. US Core v10 for R6 is planned but not published.

The appropriate action for R6 today is to monitor the ballot process, participate in HL7 ballot review if your organization is a member, and plan for an eventual R4-to-R6 migration in the 2027-2028 timeframe.

Migration Considerations

R4 to R5

Migrating from R4 to R5 involves several categories of changes:

Non-breaking changes: R5 adds new resources and new elements to existing resources. If your application only uses resources and elements that existed in R4, it will largely work against an R5 server with minimal changes. The normative components of R4 (Patient, Observation, REST API) are stable in R5.

Subscription migration: If you use R4 Subscriptions, you need to migrate to the SubscriptionTopic model. This is a structural change, not just a version bump. Your subscription management logic needs to be rewritten.

Search parameter changes: Some search parameters have been renamed or restructured in R5. Review the R5 change log for resources your application uses.

Terminology changes: Some code systems and value sets have been updated. If your application validates data against specific value sets, you may need to update validation rules.

Strategy: The recommended approach is to implement a version-aware abstraction layer in your application. Define your internal data model independently of the FHIR version, and use version-specific serializers/deserializers to convert between your model and FHIR R4 or R5 resources. This lets you support both versions simultaneously during the transition.

R4 to R6 (Future)

The R4-to-R6 migration will be the big transition for the US healthcare industry. When US Core v10 is published on R6 and ONC/CMS update their regulations to require R6, the entire ecosystem will need to migrate. Based on HL7’s stated timeline, this transition will happen between 2027 and 2030, with R4 remaining valid throughout a multi-year sunset period.

Organizations that design their systems with version awareness today will have an easier migration path. Specifically:

• Store data in a version-independent internal representation.
• Use FHIR libraries that support multiple versions (HAPI FHIR supports R4 and R5; R6 support will come).
• Avoid hard-coding FHIR version assumptions in business logic.
• Abstract FHIR API interactions behind service interfaces that can be updated independently.

Impact on Implementation Guides

Implementation guides (IGs) are constrained FHIR profiles that define how FHIR resources should be used for specific use cases. The version of the underlying FHIR specification determines which IGs are available.

US Core

US Core is the most important IG for US healthcare. It defines minimum data elements and API interactions required by regulation. The current version alignment:

• US Core v3.1.1: FHIR R4, regulatory baseline (USCDI v1)
• US Core v6.1: FHIR R4, USCDI v3
• US Core v7.0: FHIR R4, USCDI v4
• US Core v10 (planned): FHIR R6, USCDI v5+ (target May 2027)

There is no US Core version targeting R5. HL7 has indicated that US Core will skip R5 and move directly from R4 to R6. This is a significant signal: for US regulatory compliance, the path is R4 today, R6 in the future.

Da Vinci

The Da Vinci project defines FHIR IGs for payer/provider data exchange, including Prior Authorization (PAS), Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and others. All current Da Vinci IGs are built on R4. Da Vinci IGs will likely move to R6 when US Core does.

CARIN Blue Button

CARIN Blue Button (C4BB) defines how payers expose claims and benefit data through FHIR APIs. It is built on R4 and aligned with CMS requirements. Like Da Vinci, it will move to R6 in the future.

International Patient Summary (IPS)

The IPS IG defines a minimal patient summary for cross-border exchange. It is currently published on R4 with R5 versions in development. IPS is more likely to adopt R5 before R6 because it is not bound to US regulatory timelines.

Our Recommendation

Based on the current state of the ecosystem in March 2026:

For production systems: implement R4. It is the regulatory standard, the EHR vendor standard, and the IG ecosystem standard. You will not encounter compatibility issues, and you will meet compliance requirements.

Design with R5 awareness. Even if you implement R4, be aware of R5’s improvements. Use the R5 Subscriptions backport if you need real-time notifications. Structure your code to support version upgrades.

Monitor R6 ballot progress. Subscribe to HL7’s FHIR R6 ballot announcements. Review the ballot drafts to understand what is coming. If your organization is an HL7 member, participate in ballot review to influence the final specification.

Plan for R4-to-R6 migration in 2027-2028. When R6 is published and US Core v10 follows, the migration clock starts. Organizations that plan ahead will have a smooth transition. Those that wait will face a compressed timeline when regulations catch up.

Build version-aware systems. Regardless of which version you implement today, design your architecture to support multiple FHIR versions. Use abstraction layers, version-aware FHIR libraries, and configuration-driven version selection. The healthcare industry is still maturing its FHIR version strategy, and flexibility is a competitive advantage.

Next Steps

Choosing a FHIR version is the first decision in a FHIR implementation project, but it is far from the last. You also need to select the right implementation guides, design your resource profiles, set up authentication, build or select a FHIR server, and integrate with EHR systems, payers, and other data partners.

• FHIR API Integration Services — Our team delivers FHIR implementations from design through production, supporting R4 with R5 and R6 migration planning.
• Epic Integration Services — Building on Epic’s FHIR R4 APIs for patient access, clinical decision support, and population health.
• HL7 v2 vs FHIR — If you are deciding between HL7 v2 and FHIR (or need to support both), this comparison guide covers the trade-offs.
• Azure FHIR Migration Guide — If you are running Azure API for FHIR and need to migrate to Azure Health Data Services before the September 2026 deadline.