ballot-intro.md — FHIR Core Extract

type: docsource: source/ballot-intro.html

[%settitle FHIR STU6 Ballot Welcome%] [%file newheader%] [%file newnavbar%]

R6 Ballot Roadmap

Responsible Owner: [[%wgt fhir%]]([%wg fhir%]) Work Group	Standards Status:Informative

Welcome to the first full ballot of FHIR Release 6 (R6).

This ballot is a Normative ballot - ALL of the specification is being balloted as a full Normative ANSI Standard. As such, balloters should note the following about the ballot process:

As a normative standard, any substantive changes - that is, changes that impact on implementations - must be approved by the ballot - in other words, reballot is required.
You must sign up for the first ballot to participate in later ballots; if you do not have time to participate for a round of balloting, please abstain so that quorum levels are met.
Note that submitting a comment in Jira is not the same as voting. After comments have been submitted, you must actually vote affirmative or negative on the comment for it to count as a voted comment. Non-voted comments might still be considered as part of reconciliation, but it is not guaranteed and such consideration will become less likely in additional ballots on this same specification.
There is certain to be another ballot after this, but we are hoping that we won't require additional full ballots. Please raise significant issues in the first ballot.

Balloters should keep the following in mind about ballot scope:

Some of the content in this ballot is earmarked to move to terminology.hl7.org (THO). FMG's position is that moving valuesets from the specification to THO is not itself a substantive change.
Moving CodeSystems from core to THO is only a substantive changes if (a) the CodeSystem is bound to a Coding, CodeableConcept, or CodeableReference, and (b) the URL changes.
Implicit in that is that changes to this specification that force minor changes in URLs etc in Implementation Guides are not considered substantive changes.
The standards status and status of all the content in this ballot has been set to Normative or Informative, and active, but the FMM status of the underlying artifacts has not been consistently updated, pending revisions to the overall FMM framework
The cross version comparisons, difference analysis, structure maps and transforms have not been consistently updated for this ballot. This will be done for the next ballot. These weill also not count as substantative changes

And these notes about breaking changes:

This specification is fully normative, so once this ballot is complete, no breaking changes are allowed in future publications
Technically, this is 'forwards' compatibility: that existing implementations will not have to change for future versions. However, in practice, whether this is true depends on implementation choices. As such, the Rules for Inter-version Compatibility are of particular importance for balloters to consider
If content was normative in R4, then this specification is not allowed to contain breaking changes to that content under the rules published in this version, so balloters should pay particular attention to the parts that were normative in R4
As R5 was not normative, breaking changes from R5 are allowed (even in the R4 normative areas)
Other parts of the specification may contain breaking changes from previous versions

Balloter's attention is drawn to three useful links at the bottom of every page:

These are very useful when preparing ballot comments.

Details of Changes in this version

This section lists the important changes between this version and the last version (draft ballot 3). Note that there thousands of changes between this version and the last version, so there's no list of all changes (though see all the R6 tasks in Jira)

Immature resources have been moved out of this specification into other IGs, often labelled as 'incubator IGs'. Here's the list:
Other artifacts have been moved out of this specification as well:

An addition, balloter's attention is drawn to the following requests for balloters attention:

The resources Invoice, InsuranceProduct and InsurancePlan are likely to be removed from the specification and moved to being an Additional Resource after this ballot due to concerns around their readiness, and the thin implementation experience. Ballot comments on this subject are welcome, and on their content.
The way Medication dosage regimes are represented has undergone extensive reorganization. There have been changes to the Boundaries for MedicationRequest, and dosages in MedicationRequest, MedicationDispense, and MedicationStatement. Balloters should pay careful attention to the Dosage and the Dosage Examples pages. In addition, there are related changes in Timing
The MedicationStatement.medication element now explicitly supports representing statements such as 'no medications are known / taken. Balloters are invited to comment on this approach, impact and possible limitations
The code system used in medication statement category is presented here but is expected to move to terminology.hl7.org
The nutritionintake-status-reason code system used in NutritionIntake.statusReason is currently defined in the FHIR specification, but is expected to be moved to HL7 Terminology (THO).
A new organizer element is added to the normative Observation resource in this ballot. The OO Work Group is seeking reviewers and implementer feedback on this new element, which is intended to help clarify and make explicit when an instance of the Observation resource is used for organizing/grouping sets of sub-observations (e.g., for laboratory panel/battery result reporting). This capability is particularly applicable for use in laboratory result reporting, but it can also be used as appropriate with other types of observations.
Both SearchParameter and OperationDefinition have comments seeking input about the strength of useability assertions
There is a request for comments about implicit code systems

The FHIR R6 Ballot Process

This ballot is using HL7's Jira balloting process. As such, ballot comments will need to be submitted in Jira and, in general, balloting spreadsheets will not be used. Some organizational and affiliate balloters may continue to use spreadsheets but will be responsible for importing them into Jira themselves and may have slightly different processes for consolidating ballots to take that into account. The ballot desktop will be used for voter registration but will not be available for vote submission. Voters are encouraged to view the recorded tutorial on Jira balloting in addition to reading through the instructions on submitting Jira feedback and using Jira balloting. A webinar will be held part-way through the ballot cycle to provide an opportunity to ask questions about the process. Questions can also be raised on the Jira/Confluence stream on http://chat.fhir.org.

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 tracker item; 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: Bryn Rhodes or Sarah Gaunt.

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

[%file newfooter%]