FHIR Infrastructure ![]() | Maturity Level: N/A | Ballot 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:
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:
|
Full FHIR Ballot | Apr 2018 - May 2018 | The full R4 ballot. It includes:
|
Follow up Ballot | Aug 2018 - Sep 2018 | A follow up ballot
|
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.
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:
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.
Abstract base types, data types, formats, the RESTful API, and content and typing rules
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 .response | FHIR-I: GF#14551 ![]() | RESTful API ΔB |
Add _list parameter to history interaction | FHIR-I: GF#16022 ![]() | RESTful API ΔB |
Add conformance language about errors and operation outcome | FHIR-I: GF#14495 ![]() | RESTful API ΔB |
Mark Conditional Create, Update, Patch, and Delete as Trail-use | FHIR-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 ![]() ![]() | Issue Type Code System ΔB |
Rename Binary.content to Binary.data and exclude it from summary (which makes it optional) | FHIR-I:GF#16998 ![]() ![]() | Binary Resource ΔB |
Change Identifier.type codes to use v2 codes now that they are defined | FHIR-I:GF#9239 ![]() ![]() | 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 operation | FHIR-I: GF#17009 ![]() | Capability Statement Operations ΔB |
Add note about namespaces in types in FHIRPath consequence to FHIRPath changes | FHIR-I: GF#15876 ![]() | FHIRPath ΔB |
Clarify use of slicing entry | FHIR-I: GF#16309 ![]() | ElementDefinition ΔB |
Change Annotation.text to support markdown | FHIR-I: GF#16965 ![]() | Annotation Data type ΔB |
Fix OID regex | FHIR-I: GF#16023 ![]() | OID Data type ΔB |
Add minutes to Duration value set | FHIR-I: GF#15868 ![]() | Duration Value Set ΔB |
Make ElementDefinition.constraint.expression optional, and ElementDefinition.constraint.xpath trial-use | FHIR-I: GF#16862 ![]() | ElementDefinition ΔB |
Add ElementDefinition.sliceIsConstraining (trial-use) | FHIR-I: GF#13545 ![]() | ElementDefinition ΔB |
Mark Managing Resource Identity as trial-use, not normative | FHIR-I: GF#16466 ![]() | Managing Resource Identity ΔB |
The terminology infrastructure, and the base resources that specify content
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 ![]() ![]() | 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 ![]() ![]() ![]() | 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 |
The Patient resource, and related content
Resource |
Operations |
Valuesets |
Codesystems |
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 |
The Observation resource, and related content
Resource |
Operations |
Valuesets |
Codesystems |
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 |