Difference between revisions of "FHIR Ballot Expectations"

From HL7Wiki
Jump to: navigation, search
Line 1: Line 1:
This is a draft (not yet approved) policy under consideration by the FMG.
+
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.
 
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.

Revision as of 18:01, 6 February 2019

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 will only be approved in exceptional situations. 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 is a need to reach a broader community to ask specific questions to allow content to move forward, this can be done through the product director's blog or similar means. Ballots scheduled for "STU" ballot will not be dropped to "comment only" ballot. If content is not ready for ballot review, the ballot should be deferred to a later cycle.

2. Multiple STU ballots prior to publication should be an unusual exception and will require justification to the FMG.

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 reserves the right to 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

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 from receiving STU status

Copyright © Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.