FHIR R5 went normative in 2023, but most US health IT deployments still run R4 (or the R4B refinement) in 2026. The reason is straightforward: US Core, most Da Vinci IGs, and CMS-0057-F still reference R4. But R5 has real changes worth understanding for teams making long-term platform decisions.
Subscription: topic-based model. R4's Subscription resource is a per-endpoint criteria-and-hook subscription. R5 introduces SubscriptionTopic — a shared definition of what events to subscribe to, with per-subscriber subscriptions referencing the topic. This scales much better in multi-subscriber deployments. Some R4B implementations backport this model; check server capabilities.
Encounter changes. R5 splits the R4 Encounter resource into Encounter (the identification of the encounter) and EncounterHistory (state changes). More resources, but cleaner state modeling for admission/discharge flows.
Type changes: primitive extensions. R5 fixes several places where R4 primitives couldn't carry extensions. Practical impact is small unless your team was hitting the R4 limitation.
Cascading $expand and version-independent $translate. Terminology operations get more consistent semantics in R5. Production teams using Ontoserver or HAPI's terminology module will notice cleaner error handling for edge cases.
What doesn't change (much)
Core patterns — Bundle transaction semantics, SearchParameter, ETag/If-Match versioning — are essentially the same between R4 and R5. FHIR REST clients can be written to speak either version with modest branching.
Decision matrix
| Situation | Recommend |
|---|---|
| CMS-0057 conformance target | R4 or R4B (regulation reference) |
| Greenfield deployment, US Core Only | R4 |
| Multi-subscriber notification-heavy | R5 (SubscriptionTopic) |
| Multi-region international | R5 (better version alignment) |
| Long-term platform investment | Design to support both |
Migration path
R4 to R5 is not a big-bang migration. Most servers support both versions concurrently — HAPI FHIR 7.x, Aidbox, and Medplum all do this. New endpoints can start on R5 while legacy endpoints stay on R4. The main integration cost is client-side: SDKs need to handle both.
For most US health IT teams in 2026, staying on R4 is the right call. R5 becomes essential only when the specific R5 features (SubscriptionTopic, cleaner Encounter modeling) solve a concrete pain point. Design for eventual R5 support, but don't migrate speculatively.
