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

Last checked: 15 October 2026.

As of 15 October 2026, HL7 has published R6 ballot versions up to 6.0.0-ballot5 (the 2nd full ballot, dated 17 July 2026) and a 6.0.0-snapshot1, which the HL7 FHIR directory lists as "FHIR R6 Stable (Sept 2026)". The first full ballot, 6.0.0-ballot4, was dated 18 December 2025. The final R6 release date is a forecast; check the HL7 directory. 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.

If you are planning this for production, our FHIR integration team can build it with you.

Watch: FHIR DSTU2 vs STU3 vs R4 vs R5 vs R6: What Changed, Which to Use, and 5 Myths (Live Test) (5:11).

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.

Status (checked 15 October 2026): DeviceAlert is in the core 6.0.0-snapshot1 resource list, marked Normative in that snapshot. The snapshot is not the final R6 release.

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.

Status (checked 15 October 2026): ClinicalAssessment appeared in 6.0.0-ballot3 but is not in the core 6.0.0-snapshot1 resource list. It may be published as an additional resource outside core; check the HL7 directory before you plan on it.

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.

Status (checked 15 October 2026): InsuranceProduct appeared in 6.0.0-ballot5 but is not in the core 6.0.0-snapshot1 resource list. It may be published as an additional resource outside core; check the HL7 directory before you plan on it.

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.

Status (checked 15 October 2026): PersonalRelationship appeared in 6.0.0-ballot3 but is not in the core 6.0.0-snapshot1 resource list. It may be published as an additional resource outside core; check the HL7 directory before you plan on it.

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.

Status (checked 15 October 2026): MolecularDefinition appeared in 6.0.0-ballot3 but is not in the core 6.0.0-snapshot1 resource list. It may be published as an additional resource outside core; check the HL7 directory before you plan on it.

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.

Status (checked 15 October 2026): Group is in the core 6.0.0-snapshot1 resource list, marked Normative in that snapshot. The snapshot is not the final R6 release.

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 is planned to make more resources normative. Normative content follows HL7's backward-compatibility rules for future versions, so once you build against R6 normative resources, later versions such as R7 and R8 should not break those APIs except as those rules allow. This is a strong argument for investing in an R6 migration, because it is the version where much of the API surface is planned to stabilize. Until R6 is final, treat any status as subject to change.

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.

If you want help to plan a FHIR version upgrade, our team can review your resource usage and partners first.

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.