This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Ballot Expectations

From HL7Wiki
Revision as of 21:24, 30 April 2019 by Annewiz (talk | contribs)
Jump to navigation Jump to search

This is preliminary policy subjected to review and refinement by the FMG.

Balloting is one of the key functions delivered by HL7. The purpose of balloting is to ensure that the community targeted by a specification has reviewed the specification and agrees with it and that the specification has appropriately high quality and is appropriate for use.

For this objective to be achieved, it's essential that the community who reviews ballots is used efficiently. The content submitted for ballot must actually be ready for review and reviews must only be sought when necessary.

If work groups need to have a frozen snapshot of their publication hosted for reference for some purpose (connectathon, preliminary regulation, formal review, etc.) this can be arranged without balloting.

The FMG is instituting the following guidelines for ballot:

1. "For Comment" ballots should only be used when appropriate:

  • In general, content that is not deemed "ready for implementation" should be reviewed by soliciting WG review through listserv and chat.fhir.org, testing at connectathons and, if need be, holding formal peer reviews.
  • If there's a need to reach a broader community to ask specific questions to allow content to move forward, consult the product director for appropriate communication channels.
  • Ballots scheduled for "STU" ballot will not be dropped to "comment only" ballot automatically if it is not deemed ready for STU. If content is not ready for ballot review, the ballot should be deferred to a later cycle.
  • "For Comment" ballots will be approved in situations where a work group cannot progress their content to STU ballot level without getting specific questions answered and the the community and the alternative feedback mechanisms are not sufficient to reach the community from which answers are required. The work group should indicate what specific questions require an answer and why alternative mechanisms are insufficient to meet their needs when requesting "For Comment" ballot.

2. Multiple STU ballots prior to publication should be an unusual exception and will require justification to the FMG. Substantive changes are permitted between STU ballot and publication. However, if the substantive changes are significant and the work group feels that a ballot review is essential prior to allowing production testing by implementers, a second STU ballot is possible.

3. Content submitted to STU ballot should be considered "ready for implementation" by the balloting work group with prior experience at connectathon. The FMG may solicit evidence of adequate connectathon review and community participation and/or perform a cursory review of ballot material during the pre-ballot QA period to verify that the submitted content is sufficiently complete and of high-quality. (I.e. there should not be "to do" areas that are relevant for the implementation scope subject to ballot, there should be adequate example instances, etc.)

4. The FMG may request that the TSC adjust ballot schedules to balance balloter load. If a large number of ballots targeting the same community are scheduled for ballot in a single cycle, some ballots may be deferred to subsequent cycles. Work groups will be consulted should this occur and consideration will be given to regulation and project funding timelines.

5. Work groups are encouraged to solicit participation during the ballot. Ballots that fail to receive line-item feedback from a sufficient number of commenters may be held back by the FMG from receiving STU status

All FMG decisions with respect to authorization to ballot and authorization to publish are subject to appeal to the TSC.