FHIR R6 Is Coming: What's New, What Breaks, and Should You Skip R5?

The FHIR R6 ballot opened in January 2026, with the final release expected in late 2026 or early 2027. For the thousands of healthcare development teams currently building on FHIR R4 -- and the smaller number on R5 -- this raises urgent questions: What actually changes? Will my existing integrations break? And the question on every CTO's mind: should we skip R5 entirely and go straight from R4 to R6?

This guide cuts through the specification language to give you a practical developer-focused assessment of FHIR R6: the new resources, the breaking changes, the migration path, and a decision framework for when (and whether) to adopt it.

What Is New in FHIR R6

R6 introduces several new resources that address gaps the community has been working around for years. Here are the most significant additions.

DeviceAlert

Previously, device alerts were shoehorned into Flag or DetectedIssue resources, neither of which properly represented device-generated alerts. DeviceAlert is a purpose-built resource for medical device alerts with fields for alert type, priority, status, and the triggering device reference. This is significant for organizations building hospital equipment monitoring systems.

ClinicalAssessment

ClinicalAssessment replaces the former ClinicalImpression resource with a cleaner model for capturing a clinician's assessment of a patient's condition. The restructuring separates the assessment finding from the investigation process, making it more useful for clinical decision support systems.

InsuranceProduct

US healthcare has needed a standard way to represent insurance products, plan types, and coverage details. InsuranceProduct fills this gap, enabling structured representation of plan networks, formularies, and benefit structures. Combined with the existing Coverage resource, this creates a complete insurance data model.

PersonalRelationship

The RelatedPerson resource has always been awkward for representing complex family and social relationships. PersonalRelationship provides a dedicated resource for modeling relationships between persons with proper role coding, time periods, and bidirectional references.

MolecularDefinition

MolecularDefinition supports genomic and molecular data representation, reflecting the growing importance of precision medicine. It provides structured fields for molecular sequences, variants, and annotations that were previously captured in extensions or non-FHIR formats.

The Redesigned Group Resource

The Group resource has been completely redesigned in R6. The R4/R5 Group served dual duty as both a definitional grouping ("all patients with diabetes") and an actual enumeration ("these specific 50 patients"). R6 separates these concerns, with distinct structures for characteristic-based groups and member-enumerated groups. This is the most impactful breaking change for teams using Group -- every Group-based query and workflow will need review.

The "Additional Resources" Concept

R6 introduces a new publishing model: "additional resources." These are resources that go through the full HL7 balloting process but are published outside the core specification release cycle. This means the FHIR community can add new resources without waiting for a major version release.

For developers, this changes the planning calculus. Previously, you would evaluate a FHIR version holistically. Now, you need to track both the core specification AND additional resources that may be relevant to your use case. The HL7 FHIR registry will become the definitive source for discovering available resources.

Most Resources Becoming Normative

This is arguably the most important change in R6 for long-term planning. FHIR has two maturity levels for resources:

• STU (Standard for Trial Use): The resource may have breaking changes between versions. Most R4 resources are STU.
• Normative: The resource is guaranteed to be backward compatible. In R4, only Patient, Observation, Bundle, and a handful of others are normative.

R6 moves the majority of commonly-used resources to normative status. This means that once you build against R6 normative resources, those APIs will not have breaking changes in R7, R8, or beyond. This is a powerful argument for investing in an R6 migration -- it's the version where the API surface stabilizes permanently.

Migration Impact by Resource

Not all resources change equally between versions. Here is the migration impact assessment for the most commonly used FHIR resources:

Key insight: most of the heavy breaking changes happened in R5. If you are on R4 today, R5 was the painful migration. R6 adds fewer breaking changes on top of R5, meaning the marginal effort of going R4 to R6 vs R4 to R5 is relatively small.

Should You Skip R5?

This is the pragmatic question. R5 was released in 2023, but adoption has been limited. Most US healthcare systems remain on R4, primarily because US Core profiles, CMS regulations, and the USCDI all reference R4. Here is the decision framework:

Skip R5, Go Directly to R6 If:

• You are currently on R4 and have no regulatory requirement to adopt R5
• You are not using R5-specific features (Subscriptions, new search parameters)
• You can wait until late 2026 or 2027 for R6 ecosystem readiness
• You want the stability guarantee of normative resources (R6 has far more normative resources than R5)
• You are building a new system that won't go live until 2027+

Adopt R5 Now If:

• You need R5 Subscriptions (topic-based, fundamentally better than R4 subscriptions)
• Your trading partners already use R5
• You are building against an Implementation Guide that requires R5
• You need the R5 Encounter restructuring for your use case

Stay on R4 If:

• You are building for US regulatory compliance (USCDI v3 and ONC certification still reference R4 profiles)
• Your EHR vendor only supports R4 (Epic, Oracle Health, athenahealth all primarily expose R4)
• You have stable, working R4 integrations with no driver to change

When to Adopt R6: A Practical Timeline

The specification release and ecosystem readiness are different milestones. Here is what the R6 adoption timeline looks like:

The practical implication: no one should be running R6 in production before mid-2027, unless you are building a FHIR server (not a client) and want to be ahead of the ecosystem. For EHR development teams, the right time to start R6 planning is now, but the right time to deploy is 2027.

R6 Ecosystem Readiness Checklist

Before committing to an R6 migration, verify these ecosystem dependencies:

1. FHIR Server Library Support: Does your FHIR server (HAPI FHIR, Microsoft FHIR Server, IBM FHIR, etc.) have R6 support? Check for beta/preview releases.
2. Validation Tooling: The HL7 FHIR Validator must support R6. Without validation, you cannot verify conformance.
3. Implementation Guide Publisher: If you publish IGs, the IG Publisher must support R6 resource types and profiles.
4. Testing Tools: Inferno and Touchstone need R6 test suites for conformance testing.
5. Terminology Services: Verify that your terminology server supports R6 CodeSystem and ValueSet changes.
6. Client Libraries: SMART on FHIR client libraries, FHIR SDKs, and any third-party libraries must support R6 data models.

Preparing Your Codebase for R6

Even if you are not migrating today, there are steps you can take now to reduce future R6 migration effort:

• Abstract your FHIR version: If your application directly constructs FHIR resources using version-specific classes, introduce an abstraction layer. Map your domain objects to a version-neutral internal model, then serialize to the target FHIR version. This is the same pattern we recommend for avoiding common healthtech integration mistakes.
• Use profiles, not raw resources: Building against US Core profiles rather than raw FHIR resources insulates you from base resource changes, since profiles add constraints on top of the base.
• Avoid deprecated elements: R5 deprecated several R4 elements. If you are on R4, avoid using elements marked as "trial use" or known to be restructured in R5/R6.
• Invest in integration tests: Build a comprehensive FHIR conformance test suite. When you switch versions, these tests immediately surface breaking changes.

Frequently Asked Questions

Will R4 still be supported after R6 is released?

Yes. FHIR versions are not deprecated when new versions release. R4 will remain a valid, supported specification. The US regulatory ecosystem (ONC, CMS) still references R4, and vendors will continue supporting R4 APIs for years. However, new features and resources will only appear in R6+.

Can I run R4 and R6 simultaneously?

Yes, and many organizations will need to. You can run a FHIR server that supports multiple versions, or run separate server instances. HAPI FHIR supports multi-version operation. The key challenge is maintaining data consistency across versions -- changes made via R6 must be visible via R4 queries and vice versa.

What about R5 Subscriptions? Do they change in R6?

R5 introduced topic-based Subscriptions, replacing the R4 polling model. R6 refines but does not fundamentally change the R5 Subscription model. If you adopt R5 Subscriptions now, the migration to R6 Subscriptions will be straightforward.

How does R6 affect US Core profiles?

US Core profiles will need to be republished against R6 base resources. The US Core team typically releases new profile versions 6-12 months after a FHIR release. Until US Core R6 profiles are published, US-regulated systems should remain on R4 + US Core 6.x or 7.x.

Is R6 the last major FHIR version?

No, but R6 significantly reduces the scope of future changes by making most resources normative. Future versions (R7, R8) will add new resources and features but will not break normative resource APIs. Think of R6 as the version where FHIR's core API surface "freezes."

What is the biggest risk of early R6 adoption?

Ecosystem immaturity. The specification may be final, but if your FHIR server, client libraries, terminology services, and testing tools do not support R6, you will be building on unstable foundations. Wait for at least two major FHIR server libraries to release stable R6 support before committing.