R4 Ballot #2 (Mixed Normative/Trial use)

This page is part of the FHIR Specification (v3.5.0: R4 Ballot #2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

1.10 R4 Ballot Roadmap

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

Welcome to the second round of the FHIR Release 4 (R4) ballot, which is working toward our first release planned to include normative content. The R4 release of FHIR will have content with different ballot statuses:

  • Normative: Content that is subject to normative ballot rules. Once passed, strict rules are imposed on future change to help ensure inter-version compatibility
  • 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.

Three 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 as candidate-normative
Full FHIR Ballot Apr 2018 - May 2018 The full R4 ballot. It included:
  • 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 were required in response to ballot and implementer feedback
  • Additional signficant new (added post the full FHIR ballot) or significantly revised content balloted for "Trial Use"
This is the current 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. (Note that 'substantiative changes' means any change that is likely to change implementations - 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 general 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 Standard for Trial Use specification HL7 published in May, 2017. These changes resulted 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. (500MB zip, ~2.2GB unzipped). The scope of this FHIR Ballot is any page where the URL starts with http://hl7.org/fhir/2018Sep, 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. Also look at the road maps on the module pages.

1.10.3 Balloting Guidelines

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: We encourage 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 eliminates 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.

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 Rules for Round 2 Ballot (Follow up ballot)

This is the round 2 ballot for FHIR R4. As such, the scope of this second ballot for the R4 cycle is limited to the changes made from the 2018-May ballot cycle. Feedback not related to changes made will most likely be found "not related" and/or deferred to consideration as part of R5.

To assist balloters, for the Normative ballot, each substantitive change made is listed, along with links to the page and the task that prompted the change. Also, diff links are provided to assist with reviewing the non-substantitive changes.

For the Trial-Use ballot, the significant new content areas or changes are indicated.

The specification has been updated to include R3/R4 maps and difference analysis, but these have not been updated. This will be done proper to publication of the final specification In the mean time, balloters are welcome to comment on suggested improvements to the mappings and difference statements, but these cannot be the basis for negative votes. Contributions may also be made directly (join the conversation at chat.fhir.org ).

The lists below provide 2 "diff" links - these are links that ask a W3C differencing engine to compare the 2 pages of the specification. There are two different types of link:

  • ΔR: Difference analysis from R3 (last full release)
  • ΔB: Difference analysis from the first normative ballot

The W3C differencing engine is the best free html diff engine that we know of, but does have issues. In particular, when reviewing differences for resources and types, the special presentation forms (tables, svg) which are rich in rendering metadata makes the difference analysis a little confusing or even unreliable in places. Reviewers will find it easier to looks the differences for the definitions rather that the tables structures - e.g. when reviewing based on the diffs, review the definitions page changes first.

1.10.5 Normative Ballot Packages

1.10.5.1 Infrastructure

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

Please consult the Round 2 ballot guide above before commenting on this ballot.

Pages

Resources

Operation

Valuesets

Codesystems

Substantive Changes since the first Normative ballot

Description Committee + Tasks Pages
Scope Changes
Mark Managing Resource Identity as trial-use, not normative (move normative parts to Resource)FHIR-I: GF#16466 Managing Resource Identity ΔB
Base Documentation
Make it explicit about canonical URLs with fragments FHIR-I: GF#17357 References ΔB
Added reference.typeFHIR-I: GF#13543 References between Resources ΔB
Clarify definition of is-modifier + impacts on modifier extensions
Note: this lead to breaking changes on a few extensions (changed from modifierExtension to normal extension)		FHIR-I: GF#16188 Conformance Rules ΔB, Extensibility ΔB
Multiple language support on narrativesFHIR-I: GF#15759 Narrative ΔB
Rules around extensible bindings (intended to be clarifications, but may be substantiative for some)Vocab: GF#17402 Using Codes ΔB
Enhance/extend rules around changes between versionsFHIR-I: GF#13089 Version Management Policy ΔB
Add note about namespaces in types in FHIRPath consequence to FHIRPath changesFHIR-I: GF#15876 FHIRPath ΔB
Add draft Terminology Service API to FHIRPath FHIR-I: GF#15777 FHIRPath ΔB
Fix missing code for 1.0.2 FHIR versions Code System FHIR-I: GF#16318 FHIR versions Code System ΔB
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 Breaking change! FHIR-I: GF#16096 Search ΔB
Clarify about 406 and 415 status codes Breaking change! 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 canonicals FHIR-I: GF#14195 RESTful API ΔB
Change rules around optionality of Bundle.entry.request and .response Breaking change!FHIR-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
Search Page
Rename the "recurse" modifier on _include to "iterate" Breaking change! FHIR-I: GF#13602 Search ΔB
Add rule that search parameter names cannot differ only by case FHIR-I: GF#14961 Search ΔB
Describe use of exponential form when searching numbers (+ clarifications for precision) FHIR-I: GF#16369 Search ΔB
Describe use of :below on token for searching mime types FHIR-I: GF#16970 Search ΔB
Introduce special search parameter typeFHIR-I: GF#17488 Search ΔB
Note about timezones (not substantive?)FHIR-I: GF#16550 Search ΔB
Details about searching on versionsFHIR-I: GF#16361 Search ΔB
Operations
Remove support for operations on historical resources Breaking change! FHIR-I: GF#17258 Operations ΔB
Add the $versions operationFHIR-I: GF#17009 Capability Statement Operations ΔB
Data Types
Fix OID regexFHIR-I: GF#16023 OID Data type ΔB
Allow exponential form for decimals (with corresponding consequences for precision) FHIR-I: GF#16874 Data Types ΔB, XML ΔB
Change Money Type to make it simpler Breaking change! FHIR-I: GF#16297 Data Types ΔB
Change Identifier.type codes to use v2 codes now that they are defined Breaking change! FHIR-I: GF#9239 , GF#16898 Identifier Type ValueSet ΔB
Change Annotation.text to support markdownFHIR-I: GF#16965 Annotation Data type ΔB
Add minutes to Duration value setFHIR-I: GF#15868 Duration Value Set ΔB
Addition of expression in metadatatypes (not normative, but appears in multiple places)FHIR-I: GF#17227 Metadata Types ΔB
ElementDefinition
Make it clear and consistent that ElementDefinition specializes BackboneElement FHIR-I: GF#17404 ElementDefinition ΔB
Clarify use of slicing entryFHIR-I: GF#16309 ElementDefinition Δ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
Change ElementDefinition.binding.valueSet to only be of type Canonical Breaking change! FHIR-I: GF#16055 Element Definition ΔB
Add a note restricting use of ElementDefinition.contentReference FHIR-I: GF#14958 ElementDefinition ΔB
Make additional constraint on valid Element names FHIR-I: GF#15678 ElementDefinition ΔB
Resources
Make it clear that contained resources can't contain security labels FHIR-I: GF#16622 Resource ΔB
Contained resources MAY contain narrativeFHIR-I: GF#13870 Domain Resource ΔB
Remove restriction on Bundle containing multiple versions of the same resource Breaking change! FHIR-I: GF#17085 Bundle ΔB
Add deleted as an issue type FHIR-I: GF#17327 Issue Type ValueSet ΔB
New codes, adjustments, and fixed definitions to codes for OperationOutcome.issue.code FHIR-I: GF#16922 , GF#17329 Issue Type Code System ΔB
Deprecate OperationOutcome.locationFHIR-I: GF#17589 OperationOutcome ΔB
Rename Binary.content to Binary.data and exclude it from summary (which makes it optional) Breaking change! FHIR-I: GF#16998 , GF#16898 Binary Resource ΔB

1.10.5.2 Terminology and Conformance

The terminology infrastructure, and the base resources that specify content

Please consult the Round 2 ballot guide above before commenting on this ballot.

Resources

Operations

Valuesets

Codesystems

Substantive Changes since the first Normative ballot

Description Committee + Tasks Pages
Scope Changes / General
Remove ConceptMap from Normative package Vocab: GF#16363 ConceptMap ΔB
Change the canonical url for all v2 and v3 CodeSystems and ValueSets to http://terminology.hl7.org (from the Unified Terminology Process) Breaking change! (no task: Vocab committee decision) todo
CodeSystem
Remove codesystem-deprecated extension Vocab: GF#12312 CodeSystem ΔB
Rationalise ordinal value extensions (not normative) Breaking change! FHIR-I: GF#17350 extension-iso21090-CO-value.html Ordinal Value Extension ΔB
Mark section "Code systems with detailed metadata" informative Vocab: GF#16335 CodeSystem ΔB
ValueSet
Remove ValueSet.$expand profile parameter, and add parameters from ExpansionProfile Breaking change! Vocab: GF#16337 & GF#16490 ValueSet.$expand ΔB
Remove ValueSet.$expand.limitedExpansion parameter, and document how to use count instead Breaking change! Vocab: GF#16449 ValueSet $expand operation ΔB
Document Valueset.expansion.parameters better, along with new requirements Vocab: GF#16841 , GF#16484 , GF#16445 ValueSet ΔB
Move Valueset.extensible to an extension Vocab: GF#16427 ValueSet ΔB
Add note about Supplements and future rules around expansions Vocab: GF#16832 ValueSet ΔB, CodeSystem ΔB
Add datetime as a allowed type for ValueSet.expansion.parameter.value Vocab: GF#17616 ValueSet ΔB
Add "Any Version" special value for ValueSet.compose.include.version Vocab: GF#15998 ValueSet ΔB
Allow a value set to contain neither compose or expansion (metadata only) Breaking change? Vocab: GF#17475 ValueSet ΔB
Add contextDirection as a parameter for $expand Vocab: GF#17321 ValueSet.#expand ΔB
StructureDefinition
Update StructureDefinition invariants FHIR-I: GF#17185 StructureDefinition.kind ΔB
CapabilityStatement
Mark many attributes in CapabilityStatement as trial-use FHIR-I: GF#14444 CapabilityStatement ΔB
Fix minor errors in CapabilityStatement invariants FHIR-I: GF#13551 CapabilityStatement ΔB
Make CapabilityStatement.rest.resource.searchParam.definition mandatory for search parameters defined in the FHIR Specification Breaking change! FHIR-I: GF#16359 CapabilityStatement ΔB
Add CapabilityStatement.implementation.custodian FHIR-I: GF#16342 CapabilityStatement ΔB
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
Revoke constraint cpb-8 on CapabilityStatement.rest cardinality FHIR-I: GF#10205 CapabilityStatement ΔB
OperationDefinition
Add OperationDefinition.title FHIR-I: GF#15982 OperationDefinition ΔB
Add OperationDefinition.parameter.referencedFrom FHIR-I: GF#17508 OperationDefinition ΔB

1.10.5.3 Patient

The Patient resource, and related content

Please consult the Round 2 ballot guide above before commenting on this ballot. Patient is being reballoted solely because of changes driven by terminology standardization, which means that the Coding.system values for Patient.maritalStatus and Patient.contact.relationship. There is no other change.

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) (no task: Vocab committee decision) todo

1.10.5.4 Observation

The Observation resource, and related content

Please consult the Round 2 ballot guide above before commenting on this ballot.

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) (no task: Vocab committee decision) todo
Updated the definition of subject and added a note to the FHIR safety page about not being surprised by the focus element. OO: GF#16136 Observation ΔB
Created a standard extension event-relatedArtifact to reference other knowledge resources used for citations and documentation of the Observation instance. OO: GF#15824 Observation ΔB
Created a standard extension event-supportingInfo to reference other resources from the patient record that were used in creating the Observation instance. OO: GF#16172 Observation ΔB
Created a standard extension observation-precondition to reference other observations that must be known to correctly interpret the observation. OO: GF#17228 Observation ΔB
The code system for value set observation-interpretation is changed from HL7 Version 2 Table 0078 to v3-ObservationInterpretation as part of the HL7 Unified Terminology Governance Project . Added clarifying text to indicate that all use cases where interpretations are relevant might not be covered by the observation-interpretation value set. Breaking change! OO: GF#16186 , UTG Process Observation ΔB
Changed cardinality of Observation.interpretation and Observation.component.interpretation from 0..1 to 0..* OO: GF#16231 Observation ΔB
Added guidance on how other observations or code translations provide additional context that may alter the semantics of the observation. OO: GF#17578 Observation ΔB
Changed Observation.context to Observation.encounter and changed type from Reference(EncounterIEpisodeOfCare) to Reference(Encounter). Update search parameter definition and add a standard extension event-episodeOfCare. Breaking change! OO: GF#17661 Observation ΔB

1.10.5.5 Trial-Use R4

This ballot includes everything else not listed above, including draft, informative and externally derived content. Balloters are welcome to comment about these, though there is no difference between ballot comments on these content and normal content.

There have been many changes to the content; balloters should use the "Ballot Comparison" link at the bottom of page to compare the differences. For implementer convenience, some of the more signficant (not all) changes are listed here: