FHIR R4 vs R5: What Changed and When to Migrate

Posted in Healthcare Integration

FHIR R4 vs R5 is a version question with a regulatory answer. FHIR R4 is the release that US certification and payer rules name, and FHIR R5 is the release HL7 published in 2023 with a reworked subscription model, more resources, and no new normative content. HL7’s own version policy lists Release 4 as Normative plus STU, Release 5 as STU, and Release 6 as Normative. That one line explains most of the adoption pattern: R4 is the floor the regulators locked onto, R5 is a trial-use step, and R6 is the next locked release. This guide covers what R5 changed at the specification level, how HL7’s compatibility rules decide what can break, what the current US rules require, where vendor support sits, where R6 is in ballot, and the conditions under which a move from R4 to R5 is worth the cost. 

What is R4 in FHIR? 

FHIR R4 is HL7’s fourth release of the Fast Healthcare Interoperability Resources standard and the first to carry normative content. It was published on December 27, 2018 as version 4.0.0. The 4.0.1 technical correction of October 30, 2019 is the version US regulators cite.

HL7’s version policy classes R4 as Normative plus STU. The RESTful interactions, core data types, and a set of base resources such as Patient and Observation are locked under compatibility rules. The remainder is Standard for Trial Use and open to change. A later R4B release, version 4.3.0, applied STU-only changes to the same base.

R4 is the installed base, and that is its strength:

• ONC certification at 45 CFR 170.215(a)(1) names FHIR 4.0.1
• Every US Core version from 6.1.0 to 9.0.0 is built on it
• The CMS Interoperability and Prior Authorization final rule names it
• Epic and Oracle Health publish their FHIR resources on it

Any FHIR R4 vs R5 decision starts from the fact that R4 is where the regulators, the payers, and the EHRs currently are.

What Is FHIR R5?

FHIR R5 is HL7’s fifth release, version 5.0.0, published in late March 2023. HL7 classes it as a Standard for Trial Use release. HL7 New Zealand’s release note states that it contains no new normative content and brings the resource count to 158. What R4 had already made normative stays normative in R5; nothing was added to that set.

R5’s value is in what it added and restructured:

• Topic-based subscriptions moved into the core specification
• New resources with no R4 equivalent, such as Permission, Transport, GenomicStudy, InventoryReport, and NutritionIntake
• Structural changes to a number of trial-use resources, published in full on HL7’s generated difference page

FHIR R4 vs R5: Primary Differences

Area	FHIR R4	FHIR R5
Version and date	4.0.0, December 27, 2018; 4.0.1 technical correction October 30, 2019	5.0.0, late March 2023
HL7 status	Normative plus STU	STU (trial use); no new normative content
Compatibility guarantee	Normative content locked under HL7 rules; STU content may change	Same normative set as R4; all R5 additions are trial use and may change
Resource count	Base set, all carried into R5	158 per HL7 New Zealand release note
Subscription model	Push on a criteria string; topic model available via the R5 Backport guide	Topic-based model in core: SubscriptionTopic, Subscription, SubscriptionStatus
Resources with no counterpart	None relative to R5 baseline	Permission, Transport, GenomicStudy, InventoryReport, NutritionIntake, ArtifactAssessment, DeviceAssociation, and others
ONC certification (170.215)	Named: FHIR 4.0.1 with US Core 6.1.0; approved advances 7.0.0 and 9.0.0, all R4-based	Not named
CMS-0057-F payer rule	Named: FHIR 4.0.1 and US Core 3.1.1; updated ONC-approved versions permitted	Not named; no approved advanced version is R5-based
Epic and Oracle Health	R4 published (Epic also DSTU2 and STU3)	No R5 endpoint documented
Cross-version support	HL7 extension packages to and from R4B, R5, R6	HL7 extension packages to and from R4, R4B, R6
Successor	R4B (STU changes only), then R5	R6, fully normative, in second normative ballot since July 2026

Release Status and Numbering

R4 was published on December 27, 2018 as the first FHIR release with normative content. The 4.0.1 technical correction that regulators cite followed on October 30, 2019. R5 was published in late March 2023.

HL7’s version history records that nearly 3,000 change proposals were applied between R3 and R4, including 339 labelled non-compatible. That volume is why HL7 stopped publishing a single consolidated change list and moved to automatically generated difference pages.

HL7 numbers its releases on a modified semantic versioning scheme:

• The major number increments when HL7 publishes a significant new Trial Use or Normative release
• A minor number increment can include limited breaking changes, which HL7 notes is a deliberate departure from ordinary semantic versioning
• R4B, version 4.3.0, is STU changes only on the R4 base
• Technical corrections such as 4.0.1 never add or change elements

Compatibility Rules

The single most useful fact for a FHIR R4 vs R5 decision is that HL7’s compatibility rules apply only to normative content. HL7’s version management page states that Draft and Trial Use content can change between versions, including breaking changes, with no rules for maintaining compatibility.

Once an artifact is normative, a defined set of rules takes over:

• Resource names do not change
• Existing element names and paths do not change
• Minimum cardinalities do not change
• Required bindings stay required
• Search parameters and operations may be added but never removed or renamed

HL7 also separates forward and backward compatibility. Forward compatibility, meaning content valid in an old release stays valid in a new one, is what the rules enforce for normative content. Backward compatibility, meaning instances created on a newer version work with older systems, is not guaranteed.

HL7 lists the behaviours a receiver can adopt to improve its odds across versions: ignore unexpected elements, ignore references to unrecognised resources, ignore unrecognised codes in required and extensible bindings unless the element is a modifier, and ignore unrecognised search criteria. It also notes that many healthcare implementers choose not to adopt these because of clinical risk or schema-based processing.

New Resources

R5 added resources that have no equivalent in R4. HL7’s cross-version package for carrying R5 content in R4 lists the resource types that lack a direct R4 equivalent: 

• GenomicStudy
• InventoryReport
• NutritionIntake
• Permission
• Transport
• ArtifactAssessment
• BiologicallyDerivedProductDispense
• ConditionDefinition
• DeviceAssociation

Permission is the one most often cited as a reason to move. It holds access rules for a given set of data and context, which R4 handles through Consent plus local extensions. Whether that justifies a version change depends on whether the counterpart systems can read a Permission resource, and the vendor section below answers that for the EHR side.

How Do Subscriptions Differ Between FHIR R4 and R5?

R5 moved topic-based subscriptions into the core specification, and that is the largest functional change in FHIR R4 vs R5. The good news for R4 teams is that the same model is already available to them through an HL7 guide.

In R4, a client creates a Subscription resource with a criteria string. The server pushes a notification over the chosen channel whenever a newly created or updated resource matches that criteria. The server evaluates the search for every subscription on every change.

In R5, three resources share the work:

• SubscriptionTopic defines the event
• Subscription references that topic and sets the channel and payload
• SubscriptionStatus carries delivery state inside the notification bundle

R4: Already Has a Path to This Model

HL7 published the Subscriptions R5 Backport Implementation Guide so that servers on R4 and R4B can implement a subset of R5 subscriptions in a standard way. It uses the R4 Subscription.criteria element to hold the canonical URL of the topic. US Core 9.0.0 includes a Patient Data Feed page that documents FHIR Subscriptions for US Core content while remaining an R4 guide. A team that wants topic-based notifications today can have them without leaving R4.

What does change at the boundary is the notification format. The backport guide notes that R5 introduced a new Bundle type that uses SubscriptionStatus for status information, while R4 notifications are based on a history Bundle with SubscriptionStatus carried as meta-information. 

Which FHIR R5 Changes Break an Existing R4 Implementation?

Only changes to content that was still trial use in R4 can break an R4 implementation, and the exact list depends on which resources your system reads or writes. The normative core carries forward unchanged: the RESTful interactions, the core data types, and resources such as Patient and Observation. Everything else was open to restructuring, and R5 added no resources to the normative set.

Where the authoritative list lives. HL7 does not publish a prose list of FHIR R4 vs R5 breaking changes. It publishes an automatically generated list of structural differences between R4 and R5, organised by data type and resource. That page checks five things:

1. Elements added, deleted, or renamed
2. Changes to minimum or maximum cardinality
3. Changes to allowed types
4. Changes to required or extensible bindings, including code changes in required bindings
5. Changes to an element’s modifier status

The same page lists type changes that HL7 treats as compatible, such as string to markdown and code to uri, because every legal value of the old type is a legal value of the new one.

FHIR R4 vs R5: Resource-Level Changes 

Resource	FHIR R4	FHIR R5
Patient	Existing patient data structure	No changes to element names, types, or cardinality; some terminology bindings changed
Observation	value[x] supports standard clinical result types	Adds types including Attachment and Reference
Encounter	period represents encounter dates	Renamed to actualPeriod
Encounter	class uses one Coding value	Supports multiple CodeableConcept values
DeviceUseStatement	Used to record device usage	Renamed and restructured as DeviceUsage
RequestGroup	Represents a coordinated set of requests	Renamed and restructured as RequestOrchestration

How to find your own breaking changes. The method is simple and can start today:

1. List the resource types your system reads or writes
2. Open each one’s entry on the R5 difference page
3. Classify every line as additive, compatible type change, or breaking
4. Add the subscription notification-format change if your system consumes notifications

Anything in the breaking bucket is work: a removed element, a renamed element, a minimum cardinality raised from 0 to 1, or a code removed from a required binding. Claims about specific resources that do not trace back to a line on that page should be checked against it before they enter a plan.

Is FHIR R5 Required in the United States?

No. Current US regulations do not require FHIR R5. The two largest US EHR vendors, Epic and Oracle Health, also do not document FHIR R5 endpoints.

For healthcare applications that must follow US regulations or connect with these EHRs, FHIR R4 remains the supported choice. Under current rules, R4 gives development teams a stable standard to follow for the rest of the decade.

The regulatory requirements and EHR vendor support are explained below.

What ONC and CMS Require

The Office of the National Coordinator for Health Information Technology (ONC) requires FHIR R4.0.1 for health IT certification.

Here are the current ONC requirements:

• FHIR version: Section 170.215(a)(1) specifies FHIR Release 4, Version 4.0.1, dated October 30, 2019, including Technical Correction 1.
• US Core requirements: Section 170.215(b)(1) specifies US Core 6.1.0 as the required implementation guide.
• Approved newer versions: ONC also allows voluntary adoption of US Core 7.0.0 and 9.0.0. US Core 9.0.0 became available on August 29, 2026. Both versions still use FHIR 4.0.1.
• Updated certification requirements: Under ONC’s HTI-1 final rule, USCDI v3 and US Core 6.1.0 replaced the previous requirements on January 1, 2026.

The Centers for Medicare & Medicaid Services (CMS) also requires FHIR R4 for payer APIs.

Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F):

• Required standards: USCDI, FHIR Release 4.0.1, and US Core STU 3.1.1.
• Compliance deadline: API requirements generally take effect on January 1, 2027.
• Use of newer versions: CMS allows affected payers to use newer ONC-approved standards, provided the change does not interrupt users’ access to required healthcare data.

However, all versions approved by ONC through this process still use FHIR R4. This means the flexibility does not currently extend to R5.

What does this mean for healthcare organizations?

Organizations seeking certification under § 170.315(g)(10), or preparing for the January 2027 CMS API requirements, must build their systems around FHIR 4.0.1.

Even though HL7 has released newer FHIR versions, moving to R5 is not a current US compliance requirement.

EHR Vendor Support

Epic and Oracle Health, the two largest EHR vendors in the United States, currently provide FHIR R4 APIs. Neither vendor documents an R5 endpoint.

Their published support includes:

• Epic: Its public FHIR catalog lists resources for DSTU2, STU3, and R4.
• Oracle Health: Its Millennium Platform documentation confirms that DSTU 2 FHIR APIs are no longer supported. R4 replaces that functionality, and Oracle recommends moving applications to R4 to avoid service interruptions.

What does this mean for EHR integrations?

• Healthcare applications must use the FHIR version supported by the EHR they connect with.
• If an application uses FHIR R5 but needs to exchange data with an R4-based EHR, it requires an additional translation layer to convert the data on each API call.
• HL7 provides cross-version extensions to help transfer information that cannot be directly represented in the other version. 
• However, this adds development and integration work without a corresponding benefit until the EHR itself supports R5.

Should You Use FHIR R4 or R5 for a New Healthcare Application in the US?

Use FHIR R4 (4.0.1) unless the application has none of the regulatory, payer, or EHR dependencies above and needs something R4 cannot represent. For most new US healthcare applications at least one of those dependencies applies, and R4 is the answer before any technical comparison starts. The one remaining variable for a system with no such dependencies is R6.

R6 and Timing

R6 changes the FHIR R4 vs R5 calculation for anyone deciding whether to move to R5 now. HL7’s intent, stated on the R6 ballot’s own version page, is that R6 will be the first full normative version of the standard with no trial-use content, moving most Foundation, Base, and Clinical resources to normative status.

HL7’s published release plan ran the first normative ballot in January 2026. A second out-of-cycle normative ballot opened on July 17, 2026, and a third is listed as to be determined if needed. As of this writing the current published version on hl7.org remains 5.0.0.

HL7 also notes that it expects adoption of new versions to slow as the implementation base grows. Read together with the regulatory section, the likely sequence is:

• R4 in regulation for the rest of this decade’s current rules
• R6 as the next version that reaches normative status
• R5 as the release most US systems adopt selectively, taking the parts that help, such as topic-based subscriptions, which already have an R4 path

The Five Conditions

Five conditions, each traceable to a source above, decide FHIR R4 vs R5 for a given system, new or existing, and whether a move is warranted now.

1. A US certification or payer rule governs the system. Build to FHIR 4.0.1 and the ONC-adopted US Core version. ONC and CMS name R4; nothing names R5.
2. An EHR’s published FHIR API is a dependency. Match its version. Epic and Oracle Health publish R4 and no R5 endpoint.
3. The driver is subscriptions. Implement the Subscriptions R5 Backport guide on R4 first. The topic model is available without a version change.
4. The driver is a resource that does not exist in R4, such as Permission, Transport, or GenomicStudy, and every exchange partner can consume it. This is the one case where R5 adds something R4 cannot represent natively.
5. The system is new, has none of the dependencies above, and will run for years. Weigh R5 against waiting for R6, since R6 is the release whose content will be locked by the compatibility rules and R5 is not.

Where more than one condition applies, the first that matches wins, because regulatory and endpoint constraints are fixed and the others are choices. A team that can name which condition it is in has finished the hardest part of the assessment, and the R5 difference page is where the rest of it starts.

Folio3 Digital Health for HL7 FHIR Work

Folio3 Digital Health works with health systems, digital health product companies, and device makers on standards-based data exchange, including FHIR R4 and R5 profiles, US Core, and cross-version work. If your team is deciding which FHIR version a product should target, or has an R4 estate with R5 pressure from a partner, our HL7 and FHIR integration services team can assess it against the rules above.

Closing Note

Every claim about FHIR R4 vs R5 in this guide traces to HL7’s own specification pages and ballot documents, ONC’s standards listings, CMS’s rule fact sheet, or the vendors’ developer documentation. R4 is a stable, well-supported target, R5 brings useful additions that R4 teams can adopt selectively, and R6 is on a clear path to becoming the next locked release.

Frequently Asked Questions

1. Can an R4 system and an R5 system exchange data?

Yes, FHIR R4 and R5 systems can exchange data, but they may need an additional integration layer to communicate correctly. This is because both versions organize and handle some healthcare data differently. The integration layer converts the information into a format the receiving system can understand, helping prevent errors, missing information, or data loss.

2. Does moving to R5 give access to more normative content?

No. R5 contains no new normative content. What R4 made normative stays normative in R5, and all R5 additions are trial use. R6 is the release HL7 intends to make fully normative.

3. Will US regulations move to R6 once it is published?

Not immediately. HL7 has decided that the next version of US Core will use FHIR R6 instead of R5. However, US regulators have not confirmed when R6 will become a requirement. For now, healthcare organizations must continue following the existing FHIR R4 requirements until new regulations are officially introduced.

About the Author