FHIR R4 vs R5: What Changed and When You Actually Need to Migrate

FHIR R5 was published in January 2023, and plenty of vendors will tell you it’s time to upgrade. But ONC’s 2027 compliance deadline still requires R4, and most production systems running FHIR today are nowhere near ready to change.

I had this exact conversation with an engineering lead two weeks ago. A vendor had just told his team they should be on R5. His CMS compliance review was the following week, and every implementation guide named in that review runs on R4. Both things are true at once: R5 is real and better in several concrete ways, and it is also not what the regulator is asking for.

This guide separates the two questions: what actually changed in R5, and when you actually need to move, because most of what I read online collapses them into one pitch.

FHIR R4 vs R5: The Two-Sentence Version

FHIR (Fast Healthcare Interoperability Resources) R4, released in 2019, is the regulatory floor in the US. ONC and CMS mandate it. FHIR R5, released in January 2023, is the current HL7 normative specification, with meaningful improvements in Subscriptions, Permissions, and data modeling. They are not interchangeable without migration work.

R4 was published in November 2019 as HL7’s first normative FHIR release, meaning the spec was locked and backward compatibility was guaranteed going forward (HL7 International). R5 followed in January 2023 as the second normative release. Both are real, both are actively used, and confusing “current spec” with “required spec” is where a lot of the vendor messaging goes wrong.

Here’s where the regulatory weight sits today. ONC’s HTI-1 final rule (2024, 89 FR 1192) requires certified health IT to support USCDI v3 (United States Core Data for Interoperability, the federally defined dataset every certified system exchanges) via US Core IG v6.1.0, which is built on FHIR R4, by January 1, 2026 (HealthIT.gov).

Same story on the payer side. CMS-0057-F (2024, 89 FR 8758) requires Patient Access, Provider Access, and Payer-to-Payer APIs to run on US Core IG STU 3.1.1, built on FHIR 4.0.1, expiring January 1, 2026, in favor of a newer IG version, still R4-based (CMS-0057-F rule text, cms.gov). TEFCA, the national exchange framework connecting 11 Qualified Health Information Networks and roughly 889 million documents, also runs operationally on FHIR R4.

For the full version history, not just R4 and R5, see our FHIR versions explained guide.

What Actually Changed in FHIR R5 (The Technical Summary)

R5 is not a wholesale redesign. It’s a maturation. Most R4 concepts carried forward; specific areas got real architectural improvement.

The change that gets the most engineering attention is Subscriptions. R4 used a polling-based Subscription resource, which works but gets fragile in high-volume environments. Every consumer has to keep asking “anything new?” R5 replaces it with SubscriptionTopic (defines what you’re subscribing to) plus SubscriptionStatus (tracks delivery state), making event-driven, topic-based push a first-class pattern instead of something you bolt on yourself.

Second is Permission. R4 had no standard resource for consent and access control. Teams handled it with custom extensions, which meant every FHIR server did it slightly differently. R5 adds Permission as a real resource, which matters more for platforms managing granular, patient-directed data sharing than for a single-EHR integration.

Third, Appointment recurrence. R4 had no clean way to model a recurring appointment series. R5 adds Appointment.recurrenceId and a RecurrenceTemplate resource, closing a gap that scheduling-heavy systems had been working around with application-layer logic.

R5 also adds five new resources outright: Permission, InventoryReport, Transport, FormularyItem, and BiologicallyDerivedProductDispense. InventoryReport and Transport are aimed at supply chain and care-delivery logistics, relevant if you’re building for home health, NEMT, or anything that tracks physical movement of goods or people.

And ConceptMap got version-aware mapping, useful specifically for cross-version interoperability, which is a nice bit of self-awareness from HL7 given how many systems are going to run R4 and R5 side by side for years.

For how this fits into broader FHIR compliance work, see our guide on navigating FHIR standards.

R5 Breaking Changes: What R4 Clients Need to Check

R5 improved things, but not all changes are additive. If you’re evaluating an R4-to-R5 migration, these are the changes that can break an existing client, not just extend it.

SubscriptionTopic replacing Subscription is the one that surprises teams most. Existing R4 Subscription resources don’t migrate to R5 automatically; there’s no compatibility shim. If you’ve built a real-time notification system on R4 Subscriptions, you’re looking at a meaningful rebuild, not a minor version bump.

Appointment. requested-period got restructured between versions. R4 used requestedPeriod as a Period element; R5 changed the shape. Any scheduling system writing directly to that element needs an update, not just a recompile.

MedicationRequest.dosageInstruction’s timing model became more flexible in R5, which sounds like a pure improvement until you realize “more flexible” also means “more complex,” and existing serialization logic built around R4’s simpler timing model may need real adjustment, not a find-and-replace.

DiagnosticReport.presentedForm handling also changed, so systems that attach rendered reports (PDFs, images) to a DiagnosticReport can see validation failures they didn’t have on R4. And binding strength tightened on several resource profiles across the spec, which means codes that passed R4 validation cleanly can fail an R5 validator on the same data. That last one is easy to miss in testing because it’s not a structural change; it’s a stricter gate on values you were already sending.

The Regulatory Reality: Why R4 Is Still the Floor

Here’s the part vendor presentations tend to skip. No US regulation currently names FHIR R5 as a required implementation guide. Every IG named in the current compliance deadlines is built on R4.

ONC’s HTI-1 final rule requires certified health IT to support USCDI v3 via US Core IG v6.1.0, effective January 1, 2026, and that IG is R4-based (HealthIT.gov HTI-1 overview and key dates fact sheet).

CMS-0057-F requires Patient Access, Provider Access, and Payer-to-Payer APIs to run on US Core IG STU 3.1.1, built on FHIR 4.0.1. CMS-0062-P, the 2026 proposed rule extending similar FHIR-based reporting to prior authorization for drugs, whose comment period closed in June 2026, follows the same pattern: still R4-based IGs, not R5 (CMS-0057-F rule text, cms.gov). TEFCA’s QHIN Technical Framework v2.0 specifies FHIR R4 as its exchange standard, too.

Newer HL7 ballot activity does show R5-capability patterns emerging in draft implementation guides. That’s worth watching. But as of this writing, no finalized US regulation has adopted an R5-based IG, and payers or providers who want to move ahead of the regulatory timeline can voluntarily adopt newer IG versions, provided the change doesn’t disrupt existing API consumers who are still expecting the mandated behavior.

I’ll say the quiet part plainly: “build for R5 now” advice, when it’s aimed at a team trying to hit a 2026 or 2027 compliance date, runs directly against what the regulator is actually asking for. It’s not wrong that R5 is better in places. It’s wrong to treat that as a compliance argument.

For the compliance mechanics behind these rules, see our guide on the HTI-1 final rule.

When to Build on R5 (The Decision Framework)

My framework, after watching a few teams get this decision wrong in both directions: build on R4 if you need something live for compliance or interoperability in the next 18 months. Build on R5 if you’re starting a greenfield platform you expect to run for five-plus years and you can absorb the extra testing overhead an emerging spec carries.

Build on R4 when your timeline touches the January 2027 compliance deadline, when you’re integrating with production EHRs (Epic, Cerner, Athena all support R4 today; R5 support across that group is partial at best), or when your team’s existing FHIR expertise is R4-deep.

Build on R5 when you’re starting a genuinely new digital health platform with no legacy constraints, when your use case is subscription-heavy (R5’s SubscriptionTopic model is a real, material improvement there, not a marginal one), or when you’re building supply chain, NEMT, or scheduling workflows where the new R5 resources directly replace application-layer workarounds you’d otherwise have to write yourself.

There’s a third option worth naming: build R4-compatible and R5-aware. Design your resource profiles so they can migrate forward without a rewrite, and think in SubscriptionTopic-shaped patterns even while you’re physically running R4 Subscription today. It’s more design discipline up front. Actually, “discipline” undersells it, it’s extra work with no immediate payoff, which is exactly why most teams skip it. It pays off later, when the regulatory floor eventually moves.

We saw the value of staying on stable R4 firsthand on a maternal health platform’s SMART on FHIR build inside Epic: 15% improvement in delivery-rate accuracy, running on production R4 infrastructure the whole way through. R4 production stability mattered more to that outcome than being on the newest spec would have.

The teams happiest with R5 in 2026, in my experience, aren’t the ones who migrated off R4. They’re the ones who started fresh on R5 with no legacy weight to carry forward. Migration and greenfield are different problems, even when the spec question looks the same on paper.

If you’re weighing this against your own architecture, our FHIR-ready architecture guide covers the pattern in more depth.

R5 Server and Client Support Status (Who’s Actually Ready)

R5 support across the major FHIR servers and EHR vendors is uneven. Worth knowing before you commit to a greenfield R5 build, because the spec being finished doesn’t mean your dependencies are.

On the server side, Smile CDR added R5 support in 2024 and has kept it on an active roadmap. Aidbox shipped R5 support in beta the same year, per Health Samurai’s published release notes. Firely Server reached general availability for R5 in 2024. Medplum has R5 support in active development, per its published roadmap, but it’s not there yet.

On the EHR side, it’s a different picture. Epic treats R4 as its primary API and R5 as exploratory, with no public production timeline as of this writing. Cerner, now Oracle Health, is on R4 post-DSTU2, with no publicly committed R5 timeline either.

If your integration depends on a specific EHR’s FHIR API and that EHR doesn’t support R5 yet, the R5 decision is already made for you. No amount of your own team’s readiness changes what the other side of the connection can speak.

If you’re evaluating a FHIR server migration as part of this decision, our FHIR expert services team can walk through the tradeoffs with you directly.

How ConnectHealth Handles R4, and What R5 Means for Enterprise Interoperability

If you’re a single-app developer building one integration, pick your version and build. You don’t need an accelerator for that; the decision framework above is enough.

Where this compounds is platform-scale: managing ten-plus EHR connections across a mix of R4 production systems and R5 pilots, each with its own quirks. Every new connection means re-solving the same normalization problem across versions, not just across vendors.

That’s the layer ConnectHealth operates at today, on FHIR R4, with PHISecure handling the HIPAA-compliant OAuth flow underneath it. For enterprise customers on a five-year platform roadmap, the version-translation layer is exactly where the R4-versus-R5 question stops being theoretical and starts being an infrastructure decision.

For the wider interoperability picture, see our healthcare interoperability solutions overview.