Current Build

1.10 R4 Ballot Roadmap

FHIR Infrastructure Work GroupMaturity Level: N/ABallot Status: Informative

Welcome to the first round of the FHIR Release 4 (R4) ballot, which is the first FHIR Ballot that includes content on a normative track. Note that the R4 version of FHIR will have content with different ballot status:

  • Normative: Content that is subject to normative ballot rules. Once passed, breaking changes are no longer possible
  • Trial Use: Content that is undergoing FHIR maturity Model based testing. In a future ballot cycle, once sufficiently mature, it will be balloted as normative
  • Informative: Content that is advisory (e.g. implementers are not required to conform to the content), or navigational content - tables of contents, generated lists, etc.
  • Draft: Content added late in the balloting process that has no formal standing, but is published for visibility. It might not be suitable for use in production systems.
  • Deprecated: Content that is in the process of being removed (see deprecation).
  • External: Content that is replicated from external standards (e.g. HL7 v2, DICOM) and is not subject to ballot comment

1.10.1 The FHIR R4 Ballot Process

The FHIR R4 ballot process is significantly more complex than previous ballots because of the introduction of content on the normative track. 3 ballot periods are anticipated:

Draft Ballot Dec 2017 - Jan 2018 This first ballot was mainly a development ballot for the FHIR team. It allowed for:
  • The community to review the packaging and publication of the normative content
  • The FHIR Management Group to hone ballot procedures
  • Ongoing review of the FHIR content - particularly that marked normative
Full FHIR Ballot Apr 2018 - May 2018 The full R4 ballot. It includes:
  • Multiple packages of normative content (see below)
  • The rest of the content balloted for "Trial Use"
Follow up Ballot Aug 2018 - Sep 2018 A follow up ballot
  • Reballoting of normative content where substantitive changes are required
  • Additional signficant new (added post the full FHIR ballot) or significantly revised content balloted for "Trial Use"

The key driver of this complexity is the introduction of normative content. HL7's ballot rules for normative content require that if any substantiative changes are made as a result of ballot reconciliation, the content must be reballoted by the same ballot pool. (Note that 'substantiative changes' means any change that will affect implementers - a very low bar).

In the past, normative ballots have undergone many cycles of balloting, a process that can take years. The FHIR ballot will be different, in that there are 2 ballot cycles allowed; any normative content that cannot pass ballot with 2 cycles will fall back to Trial Use for R4, and HL7 will try again for FHIR R5. Note that the content on the normative track has already undergone extensive testing, production implementation, and previous ballots.

To facilitate this process, the ballot is broken up into multiple normative packages:

Infrastructure Abstract base types, data types, formats, the RESTful API, and content and typing rules
Terminology and Conformance The terminology infrastructure and the base resources that define FHIR implementations
Patient The Patient resource and related content
Observation The Observation resource and related content

A full list of the pages that are in each normative package can be found below. Any content that is not in these packages is considered to be part of the Trial Use Ballot.

In addition to these ballots of the core FHIR specification, several implementation guides are undergoing ballot as well.

1.10.2 R4 Ballot Background

Release 4 of the FHIR specification provides thousands of significant changes and enhancements from the third FHIR Draft Standard for Trial Use specification HL7 published in May, 2017. These changes result from committee meetings, connectathons, over a thousand change proposals, and collaborations with other standards organizations. A summary of changes and a complete list of changes to resources and data types are available, along with transforms between R3 and R4 for many resources.

The FHIR specification is presented as a series of interlinked HTML pages. They can either be reviewed online or can be downloaded for exploration on your own device. (175MB zip, ~1GB unzipped). The scope of this FHIR Ballot is any page where the URL starts with http://hl7.org/fhir/2018May, though balloters must pay careful attention to which ballot package content is in (see below, or the Table of Contents).

A few notes to consider when balloting:

  • Pay close attention to the ballot status and FMM level of the artifacts. More scrutiny is appropriate for higher-maturity artifacts. While feedback is welcome for all content, expect draft and low maturity content to be a bit rough around the edges.
  • Not all of the existing outstanding issues will be resolved prior to the ballot passing. Some may be left open to allow feedback from the early adopter community.
  • While many applications have used the FHIR specification in production, the functionality it covers is not yet complete. Resources may evolve and new ones will be introduced over time. Refer to FHIR Timelines for additional guidance on expectations around the evolution of the FHIR specification, or the road maps on the module pages.

1.10.3 Balloting Rules

HL7 ballot rules require that participants sign up prior to opening of the ballot. If you did not sign up in advance, you can still submit comments using the Propose a Change link at the bottom of each page of the specification. Feedback from balloters will be given priority but all suggestions will be considered as much as time allows. (And be sure to sign up to the FHIR list-server and/or follow the #FHIR hash-tag so you don't miss the chance to vote in the next ballot cycle.)

If you are signed up to ballot, you can download the balloting spreadsheet from the Ballot Desktop . All ballot feedback must be provided using the spreadsheet template provided. (There's a help tab that explains the meaning of each of the columns.) For FHIR, you have the option of making your comments directly in the spreadsheet or submitting your comment using the FHIR Change Tracker tool. If you take the latter approach, you must include a reference to each tracker item in your ballot spreadsheet along with a vote (negative, affirmative typo, etc.). The other columns can (and should) be left blank. All spreadsheets must be submitted along with an overall vote by end of day Eastern time on the designated ballot closure date for the comments to be considered as part of ballot disposition.

IMPORTANT: Because of the volume of feedback we expect this ballot cycle, we strongly ask (beg?) balloters to capture their comments using the gForge tool and to use the spreadsheet only to list their tracker item numbers and votes. (If you include additional information beyond tracker item and vote, we need to cross-check to ensure the content is aligned, which eleminates any savings. So if you keep additional columns for internal review, please wipe them before submission.) Tracker-based comment submission dramatically reduces administrative overhead in managing the ballot. It also means that you can receive automatic notifications when your comment is scheduled for discussion, commented on or resolved. This will be the last ballot cycle where FHIR will permit spreadsheet-based ballot submissions, so you may as well get used to tracker-based balloting sooner rather than later...

When submitting your ballot feedback, if you have a general comment on something that you see occurring multiple times, please include at least a couple of specific locations where you see the issue. As much as possible, capture each separate concern as a distinct row in the ballot sheet or separate tracker item . (If using tracker items for your submissions, you MUST still submit a ballot spreadsheet referencing the relevant tracker items.) It makes our job of reconciling much easier. Also, don't forget to fill in the section numbers (gray numbers to the left of each heading) and URLs. Only one URL should be placed in the "url" element or column. If you want to reference additional URLs, include them in the text of your ballot comment.

If you have questions that are interfering with the ability to review the specification or submit ballot comments, please contact one of the co-chairs of the FHIR Management Group: Lloyd McKenzie or David Hay.

Thanks for taking the time to review the FHIR specification. We appreciate any feedback you can provide.

1.10.4 Normative Ballot Packages

1.10.4.1 Infrastructure

Abstract base types, data types, formats, the RESTful API, and content and typing rules

Pages

Resources

Operation

Valuesets

Codesystems

Substantive Changes since the first ballot

Description Committee + Tasks Pages
RESTful API
Add fhirVersion parameter to application/fhir mime type FHIR-I: GF#16165 RESTful API ΔB
Fix HTTP response status codes for If-Match header FHIR-I: GF#16096 Search ΔB
Clarify about 406 and 415 status codes FHIR-I: GF#16329 Restful API ΔB, Formats ΔB
Rewrite intermediaries section, and refocus on custom headers FHIR-I:GF#14162 RESTful API ΔB
Clarify version requirements in Location header FHIR-I:GF#13915 RESTful API ΔB
Decribe use of :below on reference for searching canonicsls FHIR-I:GF#14195 RESTful API ΔB
Change rules around optionality of Bundle.entry.request and .responseFHIR-I: GF#14551 RESTful API ΔB
Add _list parameter to history interactionFHIR-I: GF#16022 RESTful API ΔB
Add conformance language about errors and operation outcomeFHIR-I: GF#14495 RESTful API ΔB
Mark Conditional Create, Update, Patch, and Delete as Trail-useFHIR-I: GF#16448 RESTful API ΔB
Add mode parameter to /metadata FHIR-I:GF#14444 RESTful API ΔB
Allow exponential form for decimals (with corresponding consequences for precision) FHIR-I: GF#16874 Data Types ΔB, XML ΔB
Describe use of exponential form when searching numbers (+ clarifications for precision) FHIR-I: GF#16369 Search ΔB
Change Money Type to make it simpler FHIR-I: GF#16297 Data Types ΔB
Rename the "recurse" modifier on _include to "iterate" FHIR-I: GF#13602 Search ΔB
Add rule that search parameter names cannot differ only by case FHIR-I: GF#14961 Search ΔB
Make it clear that contained resources can't contain security labels FHIR-I: GF#16622 Resource ΔB
Remove support for operations on historical resources FHIR-I: GF#17258 Operations ΔB
Remove restriction on Bundle containing multiple versions of the same resource FHIR-I: GF#17085 Bundle ΔB
Add draft Terminology Service API to FHIRPath FHIR-I: GF#15777 FHIRPath ΔB
Make it explicit about canonical URLs with fragments FHIR-I: GF#17357 References ΔB
Add deleted as an issue type FHIR-I: GF#17327 Issue Type ValueSet ΔB
Fix missing code for 1.0.2 FHIR versions Code System FHIR-I: GF#16318 FHIR versions Code System ΔB
New codes, adjustments, and fixed definitions to codes for OperationOutcome.issue.code FHIR-I: GF#16922 , GF#17329 Issue Type Code System ΔB
Rename Binary.content to Binary.data and exclude it from summary (which makes it optional) FHIR-I:GF#16998 , GF#16898 Binary Resource ΔB
Change Identifier.type codes to use v2 codes now that they are defined FHIR-I:GF#9239 , GF#16898 Identifier Type ValueSet ΔB
Make it clear and consistent that ElementDefinition specializes BackboneElement FHIR-I:GF#17404 ElementDefinition ΔB
Contained resources can contain Narrative FHIR-I:GF#13870 References ΔB
Decribe use of :below on token for searching mime types FHIR-I:GF#16970 Search ΔB
Add the $versions operationFHIR-I: GF#17009 Capability Statement Operations ΔB
Add note about namespaces in types in FHIRPath consequence to FHIRPath changesFHIR-I: GF#15876 FHIRPath ΔB
Clarify use of slicing entryFHIR-I: GF#16309 ElementDefinition ΔB
Change Annotation.text to support markdownFHIR-I: GF#16965 Annotation Data type ΔB
Fix OID regexFHIR-I: GF#16023 OID Data type ΔB
Add minutes to Duration value setFHIR-I: GF#15868 Duration Value Set ΔB
Make ElementDefinition.constraint.expression optional, and ElementDefinition.constraint.xpath trial-useFHIR-I: GF#16862 ElementDefinition ΔB
Add ElementDefinition.sliceIsConstraining (trial-use)FHIR-I: GF#13545 ElementDefinition ΔB
Mark Managing Resource Identity as trial-use, not normativeFHIR-I: GF#16466 Managing Resource Identity ΔB

1.10.4.2 Terminology and Conformance

The terminology infrastructure, and the base resources that specify content

Resources

Operations

Valuesets

Codesystems

Substantive Changes since the first ballot

Description Committee + Tasks Pages
Change ElementDefinition.binding.valueSet to only be of type Canonical FHIR-I: GF#16055 Element Definition ΔB
Remove "logical" from list of StructureDefinition.kind codes, and update invariants FHIR-I: GF#17185 StructureDefinition.kind ΔB
Fix minor errors in CapabilityStatement invariants FHIR-I: GF#13551 CapabilityStatement ΔB
Add a note restricting use of ElementDefinition.contentReference FHIR-I: GF#14958 ElementDefinition ΔB
Make CapabilityStatement.rest.resource.searchParam.definition mandatory for search parameters defined in the FHIR Specification FHIR-I: GF#16359 CapabilityStatement ΔB
Add CapabilityStatement.implementation.custodian FHIR-I: GF#16342 CapabilityStatement ΔB
Make additional constraint on valid Element names FHIR-I: GF#15678 ElementDefinition ΔB
Remove codesystem-deprecated extension FHIR-I: GF#12312 CodeSystem ΔB
Remove ValueSet.$expand profile parameter, and add parameters from ExpansionProfile FHIR-I: GF#16337 & GF#16490 ValueSet.$expand ΔB
Change the canonical url for all v2 and v3 CodeSystems and ValueSets to http://terminology.hl7.org (from the Unified Terminology Process) Vocab: GF#??? todo
Change all documentation elements in CapabilityStatement to use markdown FHIR-I: GF#14170 CapabilityStatement ΔB
Add CapabilityStatement.imports FHIR-I: GF#14299 CapabilityStatement ΔB
Fix search parameter generation so that context related search parameters are defined FHIR-I:GF#17215 CapabilityStatement ΔB
Remove ValueSet.$expand.limitedExpansion parameter, and document how to use count instead FHIR-I:GF#16449 ValueSet $expand operation ΔB
Rationalise ordinal value extensions FHIR-I:GF#17350 extension-iso21090-CO-value.html Ordinal Value Extension ΔB
Document Valueset.expansion.parameters better FHIR-I:GF#16841 , GF#16484 , GF#16445 ValueSet ΔB
Move Valueset.extensible to an extension FHIR-I:GF#16427 ValueSet ΔB
Add note about Supplements and future rules around expansions FHIR-I:GF#16832 ValueSet ΔB, CodeSystem ΔB
Add OperationDefinition.title FHIR-I:GF#15982 OperationDefinition ΔB
Revoke constraint cpb-8 on CapabilityStatement.rest cardinality FHIR-I:GF#10205 CapabilityStatement ΔB
Remove ConceptMap from Normative package FHIR-I:GF#16363 ConceptMap ΔB
Mark many attributes in CapabilityStatement as trial-use FHIR-I:GF#14444 CapabilityStatement ΔB

1.10.4.3 Patient

The Patient resource, and related content

Substantive Changes since the first ballot

Description Committee + Tasks Pages
Change the canonical url for all v2 and v3 CodeSystems and ValueSets to http://terminology.hl7.org (from the Unified Terminology Process) Vocab: GF#??? todo

1.10.4.4 Observation

The Observation resource, and related content

Substantive Changes since the first ballot

Description Committee + Tasks Pages
Change the canonical url for all v2 and v3 CodeSystems and ValueSets to http://terminology.hl7.org (from the Unified Terminology Process) Vocab: GF#??? todo