FHIR Ballot Prep
This page lists the tasks to be completed by work groups in preparation for the R4 release of the FHIR core specification. The timelines for implementation guide publication and balloting may differ. Implementation Guides may choose to either publish in sync with the core specification (and actively manage dependencies as underlying resources and profiles are updated) or may choose to ballot later, once the FHIR specification is finalized. (The disadvantage of the latter approach is that changes to the core specification identified as part of implementation guide revision won't be able to be applied until a subsequent release.)
Here is a link for Implementation Guide proposals
- R4 is the first FHIR publication that is hoped to contain Normative content. For those who aren't familiar with HL7 processes, Normative means that, once the specification passes, we will no longer make breaking changes to the specification from that point forward - ever. The rules for change in FHIR for normative content are described [here].
- R4 is also the first time we're expecting to have multiple "ballots" for FHIR core content. This means that there will be one FHIR specification hosted on the web. However, each page in the specification will identify both what level it's being balloted at (not balloted, draft, STU or normative) as well as which ballot it's part of. Multiple ballots are necessary to allow content to proceeed by different paths - balloting at different levels requires separate ballots and if there's a need to allow some content to be demoted to a lower level while other content remains on the normative path, that content needs to be packaged separately.
For this WGM:
- Discuss the candidate normative artifacts and evaluate whether your WG/organization would like to see the list changed. The current candidate list is:
- Framework, XML, JSON, RESTful API, Search, Data types
- CodeSystem, ValueSet, ConceptMap. (But not all operations on those resources)
- Bundle, OperationOutcome, Parameters, StructureDefinition, SearchParameter, CapabilityStatement, OperationDefinition
- Patient, Observation
- Look at the revised workflow patterns ([Definition], [Request], [Event]) and consider how to apply them to your artifacts
- Look at the new quality criteria - for resources and other artifacts - and plan for how you'll work at meeting them
- Identify what your target FMM levels are for the artifacts you control
- Identify any new resources or IGs you want in R4
- Look at your tracker items and plan to manage them
For the R4 publication - STU candidates:
- Align with updated workflow patterns where it makes sense to do so and agree on deviations with the Workflow project
- Clear (and then keep on top of) tracker items
- Move towards your target FMM levels
- Candidate normative artifacts: In addition to the above, get this content "rock solid" - substantive changes applied, QA complete, artifact to the point where the WG and community is happy for it to be "locked down"
For the R4 publication - Normative candidates:
- all of the above plus:
- Get all content "rock solid" with both WG and community in agreement that content is ready to be set in stone
January 2018 Cycle
Sept 2018 Cycle
possible Normative re-ballots, possible limited STU FHIR Core ballot, possible IG R4-based STU ballots:
The primary purpose of this cycle is to allow reballoting of packages that are eligible to pass with only minor substantive changes or where one or more resources have been dropped from the package down to STU. *If* there is a second ballot for normative issues, then work groups balloting STU core content may petition for an additional STU ballot if they've made major revisions they feel justifies an additional ballot review. However, STU publications do not require reballot for substantive change and there will be little time for reconciliation and change application prior to the publication of R4, so this option needs to be considered carefully.
- 2018-06-06: Deadline for connectathon proposals to FMG
- 2018-07-01: Work groups notify the FMG whether they need to reballot normative packages (due to substantive change), STU resources (due to significant refactoring) or IGs during the Sept. cycle
- Implementation Guide proposals due to FMG for new FHIR IGs
- Scope changes to what artifacts are present in the normative candidate releases is due to FMG
- 2018-07-15: Notice of Intent for ballot due
- 2018-08-05: Reconciliation packages must be posted by this date at the absolute latest
- 2018-08-10: All substantive reconciliation applied. FHIR Core is frozen, limited QA process for content subject to ballot only
- 2018-08-17: Pre-ballot (and connectathon) content freeze. Publication process begins, including ensuring that content is appropriately flagged for ballot status and there are no last minute QA issues
- 2018-08-24: Ballot opens
- 2018-09-24: Ballot closes and initial triage occurs. Note: No substantive changes allowed for normative candidates unless they drop to STU.
This will be the publication of the FHIR R4 core specification plus any implementation guides that are ready
- 2018-09-29 - 2018-10-05: October WGM (Baltimore).
- 2018-10-14: Final reconciliation packages posted for 2nd and 3rd ballots
- 2018-11-01: Substantive content freeze for core R4 publication including all substantive QA changes. Decision based on vote results and withdrawals about which normative packages to drop to STU. Implementation guides publishing as part of R4 may continue to make substantive changes.
- 2018-11-11: Final content freeze for R4 publication and start of QA period. No changes permitted for FHIR Core without product director permissions. Implementation Guides may update based on their QA processes
- 2018-11-25: QA period closes, QA change application begins
- 2018-12-02: FHIR core and FHIR IGs are all locked. No further changes without product director permission
- Finalization of FMM levels, final internal publication clean-up, publication process, TSC publication approval
- ~2018-12-15: Publication of R4
The world rejoices, Grahame sleeps