FHIR R6 is coming. What changes, what moves, and what to do now

FHIR R4 has been the interoperability baseline for the better part of a decade. Most national programs, most payer mandates, most implementation guides in active use today were built on R4. That is not going to change overnight.

But the 2026 State of FHIR report tells a clear story: R5 adoption is already climbing, and R6 is on the horizon. If you are building anything today that is meant to last, it is worth understanding what R6 actually changes, and why it is more significant than a typical point release.

FHIR R6 is targeting its first fully normative release in the first half of 2027. The ambition is significant: where R4 brought many core resources to normative status for the first time, R6 aims to bring the entire core there.

For teams designing data models, building FHIR profiles, or running conformance programs, that matters. Stability at the core means less churn, more predictable upgrade paths, and a foundation you can build on without worrying about it shifting under you.

Here is what you need to know.

The core gets smaller, and more stable

One of the most consequential structural changes in R6 is what is not in the core anymore. Since R5, parts of the FHIR specification have been progressively split off into separate packages with their own release cycles: terminology into hl7.terminology, extensions into hl7.fhir.uv.extensions. R6 takes this further.

Resources that have not yet matured enough for normative status are being moved out of the core entirely into a new category: Additional Resources. These live in separate Incubator Implementation Guides, each owned by a specific HL7 workgroup. They are real FHIR resources, they can be used in implementations, they follow the same specification rules, but they evolve on their own timeline. They can graduate back into the core when they are ready.

This is a meaningful design choice. A smaller, fully normative core is easier to implement reliably, easier to certify against, and easier to build tooling for. The incubator model gives newer or more specialized resources room to mature without holding the whole spec back.

Currently there are 13 active incubators, spanning areas from Patient Administration and Orders & Observations to Clinical Genomics, Pharmacy, Financial Management, and Security. If your implementation touches any of these domains, you will want to know which resources moved.

What moved

The resource changes in R6 are worth spelling out directly, because some of them will affect implementations that are live today.

Several resources present in R4 and R5 have been removed from the R6 core entirely. ClinicalImpression, MedicationKnowledge, and EvidenceReport did not make the cut. A range of molecular resources (MolecularSequence, SubstanceNucleicAcid, SubstancePolymer, SubstanceProtein, SubstanceReferenceInformation, SubstanceSourceMaterial) have been replaced by the MolecularDefinition resource in the Clinical Genomics Incubator IG.

One new resource enters the core in R6: DeviceAlert.

On the operations side, three new operations arrive in R6 core – Group-purge, Measure-evaluate, and Patient-purge – while several that existed in R5 have been removed or relocated, including DocumentReference-generate, the Resource-add/filter/remove family, and StructureDefinition-questionnaire.

Across both core and incubators, R6 totals 163 resources* and 60 operations. The core alone accounts for 131 resources. For comparison, R4 and R5 each carried around 140-150 resources in their respective cores, so the headline number is broadly similar but the composition has changed.

*Our research revealed that at the time of FHIR R6.0.0-ballot4 five resources lived both still in the core specification and also in their new incubator home, so most likely the total number of total resources will be closer to 158 in the final version.

What else is new

Beyond the structural reorganization, R6 brings a set of substantive improvements that have been building since R4B and R5.

Medication resources have been reworked. This is an area that has historically caused friction in implementations, especially around dosing, and the R6 changes are designed to make the model more coherent and easier to profile.

CodeableReference is now a first-class datatype. If you have been working with R5 already, you will recognize this: it is the pattern that allows an element to carry either a coded concept (‘this medicine’) or a reference to another resource (‘this one-off medication that I’ve made’), depending on what is available. It closes a real gap in how clinical data gets modeled.

Family and household handling has been improved. A quiet but important change for anyone working on social determinants of health, family-based care models, or household-level analytics largely influenced by FHIR implementation experiences in the developing world. And subscriptions have been further refined, building on the significant work done in R5.

For teams currently running on R4, much of this is already accessible through cross-version extensions — with equivalent packages for R6 currently in development. For example, the package hl7.fhir.uv.xver-r5.r4 lets you pre-adopt R5 elements in an R4 environment. Equivalent packages for R6 are in the works.

This is not a workaround, it is a supported mechanism of regular extensions, and it is now properly specified and packaged for the first time. If your implementation would benefit from a specific R6 construct but you are not ready to migrate, pre-adoption is worth exploring.

What this means in practice

For teams deciding where to invest modeling effort right now, a few things follow from all of this.

If you are building new profiles or Implementation Guides and have any flexibility on version, designing with R6 in mind, even before it is finalized, is a reasonable choice. The normative ambition of R6 means that what you build against it is less likely to need reworking when the next version comes around. R6 is targeting the same role R4 plays today: the stable, widely-adopted baseline that national programs and large implementations will anchor to.

If you are running on R4 or R5 and staying there for now, the incubator structure tells you something useful. The resources that moved out of core are the ones to watch. If your implementation depends on them, you will want to track their incubator development and plan for eventual migration.

R6 will be the next R4. That is not a prediction, it is the explicit intent of everyone who has been building it. The groundwork is being laid now.

---

Ready to explore how your data models look in R6?
Start with Simplifier.net, free to try, built for FHIR profile authoring across versions.