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

FHIR Ballot Expectations

From HL7Wiki
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, with the concurrence of the TSC, is instituting the following policy for ballot:

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

  • In general, content that is not deemed "ready for implementation" should be reviewed by soliciting WG review, testing at connectathons or, 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 assistance in identifying appropriate communication channels.
  • Ballots scheduled for "STU" ballot SHALL 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 SHALL be deferred to a later cycle.
  • "For Comment" ballots are appropriate in situations where a work group cannot progress their content to STU ballot level without getting specific questions answered and the alternative feedback mechanisms are not sufficient to reach the community from which answers are required. The work group SHALL 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 exception and SHALL require approval by the FMG. Substantive changes are permitted between STU ballot and publication. However, if the substantive changes are significant and the work group determines that a ballot review is essential prior to production testing by implementers, a subsequent STU ballot may be warranted.

3. Content submitted to STU ballot SHALL be considered "ready for implementation" by the balloting work group, including prior experience at connectathons. 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 meets the established quality criteria. (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.

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