This page is part of the FHIR Specification v6.0.0-ballot3: Release 6 Ballot (3rd Draft) (see Ballot Notes ). The current version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

1.13 R6 Ballot Roadmap

Maturity Level : N/A

Responsible Owner: FHIR Infrastructure Work Group

Standards Status : Informative

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

This ballot is the third a Normative ballot - all of R6, and the last of specification is being balloted as a full Normative ANSI Standard. As such, balloters should note the draft ballots; following about the next ballot (expected in process:

• As a normative standard, any substantive changes - that is, changes that impact on implementations - must be approved by the January 2026 cycle) ballot - in other words, reballot is required
• You must sign up for the full mixed normative/trial use ballot. While comment is welcome on all first ballot to participate in later ballots; if you do not have time to participate for a round of the content, balloting, please abstain so that quorum levels are met
• There is certain to be another ballot after this, but we are particularly interested hoping that we won't require additional full ballots. Please raise significant issues in comments addressing: the first ballot

Balloters should keep the following in mind about ballot scope:

• Structural changes needed prior Some of the content in this ballot is earmarked to finalization 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 also only a substantive changes if (a) the readiness CodeSystem is bound to a Coding, CodeableConcept, or CodeableReference, and (b) the URL changes
• Implicit in that is that forcing minor changes in URLs etc on Implementation Guides is not itself substantive
• The standards status and status of all the content for in this ballot to set to Normative or Informative, and active, but the upcoming full ballot, 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 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:

• comments 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 relate existing implementations will not have to maturity levels and readiness change for Normative 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

In addition, Balloters Balloter's attention is drawn to three useful links at the following areas bottom of interest: every page:

These are very useful when preparing ballot comments.

Additional Resources : Allowing for development

1.13.1 Details of FHIR Resources 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.

• Immature resources have been moved out of this specification into other specifications IGs, often labelled as 'incubator IGs'. Here's the list:
  • BiologicallyDerivedProductDispense
  • Group : Allowing for groups to act collectively, or receive care collectively - change made based on feedback from LMICs countries, and also for social care ChargeItem
  • New data types: RelativeTime ChargeItemDefinition
  • New Resources: DeviceAlert , InsuranceProduct , MolecularDefinition , PersonalRelationship Citation Resource
  • Removed Resources: EvidenceReport ClinicalAssessment
  • Significant changes have been made to the Vital Signs Profiles , and the profile Medical Product of Human Origin ConditionDefinition profile has been added
  • The following resources have been updated and contain both structural and narrative revisions DeviceDispense
  • ResearchStudy DeviceUsage
  • ResearchSubject EncounterHistory
  • Measure FormularyItem
  • MeasureReport GenomicStudy
  • ServiceRequest , Task GraphDefinition
  • Specimen ImmunizationEvaluation
  • Observation , DiagnosticReport ImmunizationRecommendation
  • Device , DeviceAssociation , DeviceDefinition , DeviceMetric , DeviceAlert InventoryItem
  • NutritionProduct , NutritionIntake , NutritionOrder InventoryReport
  • BiologicallyDerivedProduct , BiologicallyDerivedProductDispense Linkage
  • MolecularDefinition
  • PersonalRelationship
  • SupplyDelivery ,
  • SupplyRequest
  • DocumentReference TestPlan
  • TestReport
  • TestScript
  • Transport
  • VerificationResult
  4
• Committees Other artifacts have asked for feedback on these resources: been moved out of this specification as well:
  • ResearchStudy CapabilityStatement.$subset
  • ResearchSubject DocumentReCapabilityStatementference.$conforms
  • Measure CapabilityStatement.$implements - In particular ballot questions on the Measure page
  • MeasureReport DocumentReference.$generate - In particular ballot questions on the MeasureReport page
  • And also these resources, though there have been no significant updates: SpecimenDefinition , ObservationDefinition , DeviceDispense , DeviceUsage , DeviceRequest , BodyStructure , VisionPrescription , and Transport SpecimenDefinition.$apply
  • ChargeDefinition.$apply
  • The following Module Pages have been added or updated: Resource.$graph
  • Diagnostics Resource.$meta
  • Device Resource.$meta-add
  • Nutrition Resource.$meta-delete
  • BDP Asynchronous Bulk Data Request
  • Asynchronous Bundle Request

Beyond this, almost all An addition, balloter's attention is drawn to the less mature following requests for balloters attention:

• The resources have , and 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 changes, but 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 many thousands of individual changes. At 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 time, 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 version comparison functionality FHIR specification, but is not working; we are endeavouring expected to have be moved to HL7 Terminology (THO).
• A new organizer element is added to the normative Observation resource in this functional by 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 time 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 and have comments seeking input about the ballot opens. strength of useability assertions
• There is a request for comments about implicit code systems

1.13.1 1.13.2 The FHIR R6 Ballot Process

This is the third of a series of draft ballots on R6, where different candidate resources for normative status in the final R6 version undergo focused review in order to try and reduce the overall ballot load of the final R6 ballot. Balloter's attention is drawn to two useful links at the bottom of every page: . These are very useful when preparing ballot comments. 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 .

Because this is only a draft ballot, committees are not required to response to comment, but will endeavour to do so. 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: Lloyd McKenzie Bryn Rhodes or David Hay Sarah Gaunt .

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

The difference analysis in this ballot for resources is still between Release 5 and Release 4. This will be updated when Release 6 is prior to publication of the final specification. In the meantime, 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 ).