FHIR Balloting Considerations

This page discusses the rules and guidelines around the balloting of FHIR-related content

Objectives

• Minimize ballot fatigue for voters, ballot coordinators and work groups
• Ensure that adequate feedback is received on FHIR content
• Ensure that FHIR artifacts are internally consistent

Rules

1. The FHIR core specification (ITS, Security, REST, etc.) and all resources are always balloted as a single package

Rationale: All of FHIR is interdependent. Implementers need to be able to reference a single version number when communicating a release. Implementation guides (and the profiles, value sets, etc. they contain) can be balloted separately from the FHIR specification.

2. Not all FHIR content must move to a given ballot status simultaneously.

Rationale: Not all content will meet the same degree of review/stability at the same time

3. Profiles and implementation guides balloted outside the FHIR specification may never have a ballot status that implies greater stability than the least stable of the artifacts they depend on. E.g. If a profile makes use of resources that are DSTU, that profile cannot be normative. Similarly, if profiled resources are "Draft", a profile cannot be DSTU

Rationale: Don't build a house on sand . . .

4. FHIR will use the following criteria to determine ballot statuses

Normative: The content has been at DSTU status for at least two years and the most recent DSTU version of the content has been successfully implemented in pilot or production in at least 5 independent settings covering all or most of the intended scope of the resource. Implementations should span at least 3 countries (international realm). Ideally, the resource will have been exercised in at least one connectathon. All outstanding change requests have been addressed and the work group responsible for the artifact is confident (90%+ agreement) that the content is ready to lock down under backward compatibility rules.

Note: This means that Patient can't go normative until we have at least a few implementations that use it for animals . . .

DSTU: The content does not yet meet criteria for normative. However, it satisfies all FHIR quality criteria and is considered to be "complete and ready for production use" by the creating work group.

Draft: The content does not meet the criteria for DSTU and it is necessary to seek feedback from community that cannot be appropriately gathered in other ways (questions to list server or implementer's Skype chat, peer review) before the work group can have confidence in bringing the content to DSTU level. It may also be published as draft if the resource is needed to make the publication package complete (due to internal references). In rare cases, the FMG may approve a "draft" publication if required for regulatory purposes.

Rationale: FHIR has strict inter-version compatibility rules for normative content - once a resource is normative, very little can be changed without deprecating the entire resource. Thus, confidence in the resource content is essential. The purpose of DSTU is to support early adoption in real settings, so the quality bar must be high. Even when publishing draft content, we need to respect the time of voters and ensure the content is there for good reason.

5. FHIR will not publish content at the DSTU or Normative cycle without going through a formal QA process first

Rationale: Ballots take a lot of time and energy. We want to ensure the content is as right as possible and also avoid distracting voters with publication, typo and other errors

Guidelines

1. FHIR avoid balloting on back-to-back cycles

Rationale: Back to back is too tight to reasonably reconcile and QA

2. FHIR will avoid using "out of cycle" ballots

Rationale: Out of cycle is harder for HQ to manage and reduces predictability for the community

3. Stand-alone profiles and profiles defining extensions should be published as part of the FHIR specification

Rationale: These don't have enough content or context to reasonably be published independently. If they're published as part of FHIR, they must be approved with FHIR

4. Implementation guides may be published independently of the FHIR specification if there's a desire to list them as an independent HL7 standard (these would ballot and publish on their own schedule, though in consultation with FMG)

Rationale: It's not appropriate to have everything FHIR-related published as a single specification. External groups will be publishing implementation guides as independent artifacts and HL7 will need to be able to do the same.

Discussion

Should there be guidelines about what can be balloted? For example, should profiles that only define "common" extensions ever become normative?