FHIR STU3 (Standard for Trial Use) is open for Ballot. For those participating in the ballot (entrance to the ballot is already closed under ANSI rules), here’s a few notes about the ballot process to help focus your attention (note: If you didn’t enrol in the ballot pool, you can still make comments directly on gForge, though they won’t count as ballot formally).

Note, if you’re balloting on FHIR, the STU 3 Ballot Welcome is a useful place to start. In addition, see:

• Summary of Changes (including breaking changes to the infrastructure)
• Complete list of changes to resources and data types
• Balloting Roadmap

Beyond this, there’s some specific things for balloters to consider when balloting:

• A significant amount of work has occurred around Workflow in FHIR, with an objective of improving consistency around definition, request and event-related resources, as well as providing guidance around the different mechanisms FHIR supports for managing various styles of workflows. One of the outcomes of this change is that some resources have been revised to align with the workflow patterns and many more resources are expected to undergo this alignment post-ballot. Reviewers are encouraged to consider the potential impact of alignment as part of their ballot feedback.
• The proposed Vital Signs Profile is created to enable general interoperability between all all vital signs handling systems – particularly with an eye to consumer mediated exchange. If you think that’s a good idea (rather than every system doing vital signs differently) – or you think it’s a bad idea – ballot about it
• A note about the CQF (Clinical Quality Framework) ballot: during the editorial preparation of the FHIR ballot, the editors integrated the clinical quality framework part of FHIR more directly with the FHIR publication itself. As a result of this, it’s no longer clear what exactly is FHIR, and what is CQIF. However this happened after the FHIR and CQF ballots were announced as separate ballots). We will combine the ballots for FHIR and CQF, and then sort the line items based on the content they address, so that balloters don’t need to worry about the separation between the two. Balloters need only vote against one of the two. We expect that in the future CQF won’t be a separate ballot – it’s just a module in FHIR
• We’ve introduced a new navigational framework to the ballot, by breaking it up into “modules”. Each module has a page of it’s own that references key content, addresses common implementer use cases, and provides a roadmap for the planned future of the module. These are all a work in progress; comments are welcome

The next time we ballot a maj0r release of FHIR (release 4, perhaps in 12 months or so), we’re planning to bring some of the key foundations of FHIR forward with a Normative status. We don’t yet know exactly what parts (depends partly on how this ballot goes), nor have we worked through the process implications of taking some of the content normative. This may change how you ballot, particularly for artefacts with the higher level maturity levels. (btw, note that MnM is working on clarifying Maturity levels for more kinds of artefacts than just Resources).

Note: we have changed to “STU” from “DSTU” – we’ve dropped the “Draft” part, since FHIR is long past being a draft.