R4 Ballot #1 (Mixed Normative/Trial use)

This page is part of the FHIR Specification (v3.3.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

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.
  • External: Content that is replicated from external standards (e.g. HL7 v2, DICOM) and is not subject to ballot comment

Some Normative resources contain a few elements labeled as 'Trial Use' even though the resource itself is labeled 'Normative'. While HL7 prefers to avoid this outcome, there are a number of resources where the overall functionality of the resource is clearly ready to be labeled as 'normative' while some very specific elements are known not to have the requisite level of implementation experience as the rest of the resource. E.g. Bundle.signature.

Where a Normative resource contains elements marked as trial-use, these elements are clearly marked in the resource definitions. Implementers should be aware that future versions of the FHIR specification may change these parts of the resources (in addition to the other changes allowed under the inter-version compatibility rules. While HL7 will carefully consider the consequences of breaking change to these elements, implementers should be aware that reading/using these elements has the potential to cause breaking change to their applications later.

Note that this same status will arise as a matter of process when new elements are introduced into normative resources in future versions - they will undergo a period of trial use as appropriate.

Note: it is also possible that some resources in the future will be labeled as 'trial use', but contain some elements labeled as 'normative'. There is no resource like this in this ballot, though all Trial Use resources contain normative content from Resource and DomainResource, and the Data types.

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.

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.

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

The terminology infrastructure, and the base resources that specify content

The Patient resource, and related content

The Observation resource, and related content