Soliciting Feedback concerning the roadmap for FHIR R5

HL7 is working hard on publishing the next major version of FHIR, which is R5. R4 is the current approved version, and it was published in Oct 2019. Since then, we’ve been working on R5, an incremental release that addresses known issues and adds additional functionality to the standard. We’ve also been working on R4B, a patch on R4 that allows for implementing new functionality while being identical to R4 in the areas that are widely implemented. R4B is expected to be published soon, but we’re not sure what to do about R5. This post relates to our plan for R5.

The (recent) original plan for balloting R5 was that we would perform the normative ballot in the May ballot 2022 (which is actually open in March / April). This would lead to ballot reconciliation at the May WGM, and then further reconciliation processes etc would lead to a full R5 publication, with updates to both normative and trial use content at the end of 2022 (roughly). 

However the work required to actually prepare R5 has been bigger than estimated. This includes both applying previously agreed committee changes, and the underlying tooling work to fix identified issues in the publishing tools, and it’s clear that this work will not be completed in time for the forthcoming ballot March – May ballot. Note that the capacity of HL7 to manage the FHIR publication tooling workload is a known issue that HL7 is working to address.

Because the content will not be ready, FMG has decided that R5 will not be balloted in the May cycle. 

However, we’re close to being ready to ballot, and also, one of the problems of getting R5 ready for ballot is that the resources required for R5 compete with the resources required for IG and other ballot preparation. For this reason, FMG is planning to hold a special ballot cycle through June(ish) to ballot R5. 

During discussion about the challenges of balloting R5, FMG also discussed the benefits of publishing R5 at all. The FHIR community is quite disparate; some users and ecosystems are well into the implementation phase, based on R4, and see no benefit at all from R5, and will be ignoring it – they will reconsider when R6 is published. Other users are very keen for specific changes in R5, and consequently very keen to see it published as soon as possible. Yet more users are spread between those points. But one thing we noted is that few of the users that are keen on adopting R5 are focused on the normative parts of the specification, but it’s the normative parts of the specification that present the most procedural work and risk with the R5 ballot. 

FMG discussed several options around the R5 ballot, and we are seeking feedback from the standards and implementation communities as to which to choose. 

Option #1: Go ahead and publish R5 with normative content

This option means that we go ahead and publish R5 as close to the current schedule as possible – early in 2023 (the original schedule slid due to covid – both the direct and indirect impacts. The current schedule had us publishing R5 in late 2022). We will work to get R5 as solid as possible knowing that some implementations will migrate to R5 with plans to hold the normative portions of the implementation forward compatible from R4 forwards.

Option #2: Hold R5 off completely

For this option, we decide that we’re just going to publish R4B (which will be in March/April) and that will have to be enough for the implementers keen on something after R4, and we’ll wait longer for R5, letting the debates around the normative content pieces mature further before releasing an R5, expecting that the R5 release will be bigger and more authoritative. This option might imply that there’ll be an R4C after R4B, for instance, though the limitations on R4B mean further follow ups in that chain are marginally useful.

Option #3: Publish R5 as “trial-use”

In this option, we go ahead and publish R5 as soon as we can – hopefully towards the end of this year, but call all of the R5 changes ‘trial-use’, even the changes made to the content presently labelled normative. This allows us to test out changes to normative content but then make further changes before calling the changes ‘normative’ in R6. This reduces the procedural load associated with R5, and it appears reasonable to expect that we would get it published this year 

FMG is seeking feedback on this question prior to 4pm Eastern Wed 9th March. Feedback may be made by email to,, or by joining discussion at R4A/B/R5 Discussion

FHIR R4 Ballot & Community Consultation

The first of the R4 ballots is about to open. This is an important release cycle for the FHIR Communtity: it’s the first normative ballot cycle, and some of the FHIR content will be balloted as normative. Notes of interest:

  • This particular ballot is the first of three ballots to lead to the normative parts of R4
  • Once the parts finally become normative, there can be no breaking changes in those parts (well, it’s kind-of possible, but it takes multiple cycles and years)
  • Any substantive change during ballot reconciliation requires reballot – therefore committees balloting normative content will be highly motivated to refuse proposals for change
  • After this draft for ballot, there is no way to change what is selected to be balloted as normative or not for the rest of this cycle, nor to make substantiative changes to it

So we are looking for good review on this draft for comment ballot on the following things:

  • What content has been selected for normative
  • How the normative status is presented (clearly, hopefully)
  • The technical content of the normative material
  • Any suggestions for content that needs further implementation experience in the next few months

If you want to join in, and you haven’t already signed up, well, the ballot sign-up closes today. If you missed out, you can still comment through gForge.

Here’s some of the significant changes that have come with the introduction of normative content:

  • Every page has a clearly marked status now
  • There’s colors and markers for status (see here, herehere, and here for examples)
  • The ballot introduction explains the division of the FHIR specification into different packages, and the concept of ‘mixed status resources’

Along with the publication of the First R4 ballot, it’s time to do another round of consultation about proposed breaking changes to FMM4/5 content – almost all of which is slated to go normative in R4. Here’s a list of the change proposals:

  1. Include the PractitionerRole as an alternative target type for the Patient.generalPractitioner reference (GF#14224)
  2. Change the URL of the brithplace extension from ‘’ to (GF#12974)
  3. Change ElementDefinition.type.targetProfile from 0..1 to 0..* (GF#12465)
  4. For the conformance resources, change all elements of type uri where they will always point to a Conformance resource to type Reference(XX).  This will include changes to StructureDefinition (GF#12902)
  5. Add ElementDefinition.isModifierReason (0..1 string)  and possible replace .isModifier (GF#13065)
  6. Rename OperationDefinition.parameter.profile to OperationDefinition.parameter.targetProfile (to be consistent with ElementDefinition) (GF#13561)

If you’re an implementer who is affected by one of more of these changes, and you want to express an opinion, then send an email about the change to, describing your implementation, how the change impacts on you, and your opinion on it. Notes that some of these are pretty arcane things only of interests to a few toolsmith type people, so if you don’t know what they, that’s not a problem. Also, strictly, #2 is not a FMM=4+ change, but the PA work group wanted to seek opinions anyway. Given where we are in the ballot cycle, and holidays etc, this comment period is open until Friday Jan 26 (noon Eastern) – close in time for the HL7 Workgroup meeting.

Btw, outcomes from the last round of consultations:

  • Renaming ValueSet.compose: Community input was negative, and the committee didn’t make the change (we’re going to rename $compose instead)
  • Use of Observation.related and types: Community input was muted but leaned positive, and the change is included in this ballot publication
  • Adopting GitHub Flavored Markdown: community input was positive, and this change will be adopted (but hasn’t been applied to the specification and tools yet)