Skip to content

FHIR R6 plans and current issues #176

Description

@tmprd

Summary: All changes to FHIR RDF for the R6 release should be finished by November 1st, 2025. After R6, all changes to FHIR RDF (anything that isn't "Informative") should be backwards and forwards compatible.

Background: FHIR Maturity levels

Many parts of the FHIR spec are assigned FMM (FHIR Maturity Model) levels based on their maturity, levels 1-5 representing “Trial Use” and level 6 representing “Normative” status. https://build.fhir.org/versions.html

Once an artifact achieves Normative status, specific rules come into play around inter-version compatibility. These rules have implication for both forward and backward compatibility and are intended to allow implementations to exercise FHIR interfaces and process the content of FHIR resources safely while exchanging data between systems using different versions of FHIR. These rules do not apply to non-normative content, including STU content within normative artifacts.

The rules for Normative parts of the spec include:

Forward compatibility means that content that is conformant in an old release will remain conformant with future versions. Once normative, FHIR's rules try to enforce forward compatibility. However, that doesn't guarantee that all old systems will interoperate with future systems.

Backward compatibility means that instances created against future versions of the specification will interoperate with older versions of the specification. This is not guaranteed by FHIR, though there are strategies systems can adhere to that will increase their chances of such interoperability. 

Some parts of the spec, such as example resources, are "Informative" and aren't assigned maturity levels

[An Informative] portion of the specification is provided for implementer assistance and does not make rules that implementers are required to follow. Typical examples of this content in the FHIR specification are tables of contents, registries, examples, and implementer advice

FHIR R6 will be Normative

According to the FHIR Management Group, all content subject to the maturity levels in version R6 of the FHIR spec should be Normative: https://confluence.hl7.org/spaces/FMG/pages/358257608/2025-09+Key+Messages

  • There should be no trial use elements in the normative FHIR R6 release and trial use elements will need to be moved to extensions.
  • See: Assessment for Moving Trial Use Elements to Extension for more details.
  • There should be no Trial-Use tagged content in notes, pages, etc.
  • All non-resource pages must be either Normative or Informative.

There should be no trial use elements in the normative FHIR R6 release.
FMG recommendation is that trial use resource/data type elements should either have the STU tag removed (i.e. they become normative) or they be converted to extensions 
Convert to extension unless:

  • there is evidence that the trial use element is in use
  • it's been there for a long time - i.e. since R4
  • other compelling evidence brought forward by work group

This means that most existing content in the latest version R5 will either be advanced to Normative status or removed. For example, the proposed changes to maturity for specific resources can be found here: https://fhir.org/maturity/evaluation.html

All R6 changes required by November 1st 2025

Although there may be more changes to R6 next year, changes for the first release are due soon:

  • First Normative R6 Ballot is planned for January 2026
    • All FHIR R6 changes need to be made by November 1st 2025
    • Any Jira issues that require a breaking/substantive change will force another Normative Ballot

These are defined as:

  • Non-substantive changes should not cause changes in any conformant resource instances. For example, section renumbering, correcting broken links, changing styles, fixing typos, and providing clarifications that do not change the meaning of the specification. In addition, this covers corrections that are judged not to create any expectation of change to a conformant resource instance.
  • Substantive changes are changes that introduce new functionality - changes to the specification that create new capabilities - but would not render unchanged existing applications non-conformant
  • Breaking changes are changes that mean that previously conformant resource instances are no longer conformant to the updated specification

FHIR R6 RDF and beyond

The FHIR RDF page will change from FMM 3 to Normative, however it also contains a lot of Informative content.

We should review and prioritize current FHIR RDF issues:

  • Which parts of FHIR RDF will be made Normative vs Informative?
    • Turtle serialization, OWL ontology, and ShEx?
  • Which changes do we want in R6?
  • Which changes would be forwards & backwards compatible after R6?
  • Which changes would be “breaking” after R6?

Everything from here to the end of this comment was moved here from the next comment, to make the checklist easier to edit. -- DBooth 21-Oct-2025

Which parts of FHIR RDF will be made Normative vs Informative?

My view is that the Turtle syntax and semantics of FHIR RDF, OWL classes and also ShEx are not Informative parts of the spec, and therefore they will be made Normative in R6. Changes to any of these could make previous versions non-conformant, which happened between R4 and R5, for example.

Changes to FHIR Turtle examples that aren't syntactic or semantic changes to the language itself I think will remain Informative, and permitted beyond R6. (For example, adding a name to an example patient.)

Which changes do we want in R6?

I would prioritize changes to Turtle serialization first, to ensure syntactic conformance. These kinds of changes will also likely not be possible after R6, due to making previous data non-conformant. Examples:

Where to make the changes?

Each spec change below may impact any or all of the following FHIR components:

Component github location
rdf.html page FHIR source repo
Yellow content model schemas (turtle) Kindling
Examples (turtle) Core lib: turtle generation
ShEx Core lib: ShEx generation
OWL Kindling (but should move to core lib)
HAPI HAPI repo -- Add link please

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions