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 fmg-contact@hl7.org, fhir-director@hl7.org, or by joining discussion at R4A/B/R5 Discussion
HL7 onFHIR 