Skip to end of metadata
Go to start of metadata

There will inevitably be situations where we identify “breaking” changes that we would like to be effective in (and documented in) previous releases of the FHIR specification.  There are also situations where similar changes might be desired to ‘normative’ content when releasing new versions. The general rule is that such changes are always prohibited.  I.e. “Technical corrections cannot be substantive/breaking changes”.

However, there are two situations where we can contemplate making breaking changes to a prior release:

  1. If the existing release is fundamentally ‘broken’, such that it can’t be implemented as-is, changes can be made where the fix to reflect community intention and to allow implementation is obvious.
  2. If the implementation community determines that
    1. The change needs to be made urgently
    2. Making the change would have low/no cost (typically because uptake has thus far been either non-existent or very low)
    3. No-one in the community objects to making the change


This policy describes the process for evaluating whether these conditions have been met:

For #1, the responsible work group must document the current release content, describe how and why it is ‘non-implementable’ to the satisfaction of the FMG.  The FMG will then share this documentation and solicit feedback from the broader community (see ‘soliciting feedback’ below). The FMG will then consider the resulting feedback and, if none of the feedback indicates that the proposed fix would break existing implementations, the change can be approved as a ‘technical correction’

For #2, the responsible work group must document the current release content, the proposed change and the reason why the change is sufficiently urgent to apply to a prior release.  If the FMG is convinced of the urgency and that the impact on the community will be negligible, it will then share this documentation with the broader community (see ‘soliciting feedback’ below).  The FMG will review the resulting feedback and, if no member of the implementation community objects on the basis of impact to their implementations, the change can be approved as a ‘technical correction’.

In either case, if there is an objection from the community, then the default presumption is that the change will not be made.  However, if the FMG strongly feels that the change should still be made, based on the overall feedback received, they can escalate the decision to the TSC, forwarding the documentation of the issue, all community feedback received and a motion indicating the FMG recommendation.

“Community communication” will include the following processes:

  • Posting to the FHIR announcements stream on Zulip
  • Reaching out to the HL7 members list
  • Providing content to the HL7 affiliates for distribution to their affiliate members (including potentially translating the documentation)
  • Emailing out to all “registered implementers” on FHIR.org
  • Posting on the product director’s blog


All communication shall include an email address (or Confluence page) at which feedback can be provided.  The feedback period shall not be less than 30 days (to ensure there is time to investigate impacts, engage with contractors, allow for vacations/absences, etc.)

In any situation where this process is invoked, the FMG shall consider any process failures that resulted in the need for change and identify what mitigating steps might be useful in preventing a recurrence.

  • No labels

1 Comment

  1. Personal Comment: This begs for the SGB to define a single feedback process across all product lines/families/workgroups/steering divisions.