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, here,  here, 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 ‘http://hl7.org/fhir/StructureDefinition/birthPlace’ to http://hl7.org/fhir/StructureDefinition/patient-birthPlace. (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 fhir-director@hl7.org, 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)