HL7 Balloting

Overview

Balloting is the formal process that HL7 uses to get feedback and comments on specifications prior to publication.  Rules governing balloting are defined in both HL7's Governance and Operations Manual and in the HL7 Essential Requirements.  These, in turn, are governed by the expectations of the American National Standards Institute (ANSI) which accredits HL7 as a standards development organization and enforces rules around the openness and fairness of approval processes.  The objective of balloting is to actively seek feedback on a proposed standard and to ensure that the community that will be governed by that standard is in agreement with the expectations set by the standard. 

In the balloting process, a "frozen" version of a specification is subjected to review during a scheduled time window.  Reviewers who have registered for the ballot can submit comments about the specification that raise issues and propose changes.  They also cast an overall vote indicating whether they believe the specification should be published in its current form.  The sponsoring Work Group(s) then review the comments provided and address them through a process called reconciliation.  Based on the response of the Work Group(s), the balloter may choose to adjust their vote by "withdrawing" negative votes.  The final determination of whether the specification can proceed to publication as a 'standard' is driven by the balance of affirmative votes received and varies depending on the type of ballot.

Ballot Levels

HL7 specifications can be balloted at one of four levels:

• For Comment ballots are used early in the development cycle to solicit feedback from the community.  Such ballots never result in the authorization to publish a specification.  They are intended to give guidance and direction to the Work Group developing the specification by soliciting review from the community outside the participants performing the development work.  These ballots have the least onerous requirements in terms of response to feedback.  There isn't really a notion of "pass" or "fail" for informative ballots.
• Informative ballots are used to vet content that is not intended to be binding on implementers.  It is often used for specifications that guide internal HL7 processes or that give non-binding recommendations/guidance to the implementer community.  Because the specification resulting from such a process is non-binding, requirements for consensus and limitations on substantive change between review and final publication are lower than other ballot types.
• Standard for Trial Use (STU) ballots are used to vet content that is eventually intended to be binding on implementers.  It is used to vet content that is deemed "ready to implement" by the sponsoring work group, but where there has not yet been significant implementation experience.  STU specifications are time-limited and give an opportunity for the community to exercise the specification in real-world implementation before the specification is "locked down" and forward and backward compatibility rules come into play.  STU specifications are also non-binding and therefore requirements for consensus and limitations on substantive change between review and final publication are also lower.
• Normative ballots are used for final review of specifications that are intended to be binding on the implementer community and where there are strict rules around future changes to preserve a degree of forward and/or backward compatibility.  The specifications that result from this process are considered authoritative.  As such, the rules for consensus are highest and any issues raised during the review process receive the greatest degree of scrutiny by the community.  There are strict limits on the types of changes that can be made between the ballot review process and eventual publication.  It is common for specifications to undergo multiple cycles (where content is submitted for ballot, feedback is received and applied and the content is returned to ballot) before the community is satisfied and the specification can be published as an official standard.  If consensus cannot be reached (i.e. agreement between some balloters and the authoring Work Group(s) cannot be achieved), a recirculation ballot is held. 

Under ANSI rules, most Normative-balloted content is subject to periodic review to confirm that the specification is still relevant.  This review takes the form of a Reaffirmation ballot.  Such ballots are subject to the same rules as a Normative ballot.

In addition,

Recirculation ballots are a special process invoked at the conclusion of some Normative ballots.  They are limited to the pool of voters who submitted votes as part of the original Normative ballot process.  They highlight any issues where consensus could not be reached between the authoring Work Group(s) and some members of the ballot pool.  They provide the balloters within the pool the chance to adjust their vote based on the outstanding negative comments.  Essentially this means that those who voted affirmative have the opportunity to change their vote to negative if they agree with the negative balloters that the specification should not be published "as is".  It also provides those who did not vote or abstained an opportunity to change their vote to either affirmative or negative after reviewing the outstanding negative comments  At the conclusion of the recirculation period, all votes are "locked in" and a final determination is made about whether the ballot passes or not.

In some cases, when dealing with specifications that do not represent a standard or early in the development lifecycle, HL7 may opt to forgo the balloting process and instead use a process of formal Peer Review.  As well, feedback can be provided on HL7 published specifications using HL7's Specification Feedback process even if a ballot is not currently open.

Ballot Process

For a participant, the ballot process works as follows:

1. User signs up to participate in a specific ballot on a specific specification.  There may be a cost associated with this if the user is not an HL7 member.

2. During the ballot period, the balloter reviews the specification and provides feedback as ballot comments and mark their comments as either "negative" (the publication should not proceed without change) or "affirmative" (the publication can proceed even if the change isn't made).  These comments get aggregated and determine the balloters overall vote:

   Vote	Description
   No vote	No vote has been recorded. This is the initial state for the ballot submission. If no action is taken by the voter, this will be the voter's final submission status. A "no vote" means that the ballot submission won't count towards quorum.
   Abstain	The balloter has reviewed at least some of the ballot material but has not formed an opinion on whether the specification should be approved or not. Abstentions count towards quorum, but not towards whether the ballot passes or not.
   Affirmative	The balloter may have some feedback about minor changes they would like to see (typos, small suggestions, etc.) but are overall comfortable with the specification and are happy to see the specification published even if none of their comments result in changes to the specification. This vote cannot occur if the balloter has submitted any "negative" comments.
   Negative	At least one of the balloter's comments was marked as "negative", meaning the balloter feels the specification must not be published until all issues they marked as negative have been appropriately addressed.
   Removed	After initially signing up as a voter, the user has been removed from the voting pool. This may be based on user request or due to a lapse of membership.

3. The HL7 work group(s) responsible for the specification review the comments provided and decide (and document) what changes, if any, will be made to the specification as a result of the comment.  This process is called Disposition.  In it, the work group makes one of the following determinations:
   1. Persuasive: Whatever changes were proposed by the balloter will be made as requested
   2. Not Persuasive: The work group will not make any change based on the raised issue (and will provide a rationale for why)
   3. Persuasive with Mod: The work group agrees with the issue identified and will make changes, but the changes will differ in a noticable way from the balloter's suggestion/intention
   4. Not Persuasive with Mod: The work group disagrees with the issue, but will make a change to the specification as a result of the comment anyhow - e.g. to better document why things are the way they are
   5. Not Related: The comment does not fall within the scope of the ballot.  (The comment itself may eventually be dealt with as part of other review, but the comment is not deemed to be relevant to the current ballot.)
   6. Considered - No action required: This is used for comments that do not propose a change
   7. Considered for future use: No change will be made based on this comment for the current release, but the comment will remain "outstanding" and will be considered as a possible change in a future release
   8. Duplicate: The proposal is substantially the same as another comment and the decision will be documented on the other comment.
4. Balloters have the opportunity to decide to adjust their votes:
   1. A balloter can Retract their vote prior to the work group making a decision on what changes will be made.  Essentially this means that the balloter has changed their mind (possibly after discussion, re-reading the content, new understanding, etc.) and no longer believes the comment should have been submitted
   2. A balloter can Withdraw their vote after the work group has disposed of the comment.  This means that the balloter accepts the resolution to the issue raised and, once the resolution is applied, the issue should no longer create a barrier to publication.
   3. If a balloter no longer has any negative comments remaining after retracting or withdrawing comments, the balloter's overall vote changes to "affirmative"
5. Agreed changes are applied to the specification
6. A final determination is made whether the specification has "passed" ballot and is ready for publication or whether additional changes is needed and, potentially another ballot cycle of review is required
7. In some cases a Recirculation ballot will be necessary

The outcome of the ballot process is determined by the answer to two questions: Does the ballot meet quorum requirements? and Did the ballot pass?

• Quorum is determined by whether a sufficient percentage of the individuals who signed up to vote actually did so.  I.e. It's the percentage of voters who cast an Affirmative, Negative or Abstention vote out of all voters who registered to participate in that ballot.  Removed voters are not considered to be "signed up" for the purposes of quorum calculation.
• Passing is determined after balloters have had a chance to withdraw or retract.  A calculation is made of the percentage of Affirmative votes out of the combined total of Affirmative + Negative votes.  This calculated value is compared to the minimum percentage required to pass based on the type of ballot.  Abstensions and No-votes are relevant as part of determining quorum, but have no impact on whether a ballot "passes".

Different types of ballots have different expectations around quorum and passing requirements:

Ballot Tooling

Balloting in HL7 is managed through the use of two tools that work in concert:

• The HL7 Ballot Desktop manages ballot announcement and registration process and captures the formal record of ballot submissions and reconciliation for ANSI audit purposes.  It also manages any recirculation ballots.
• The Jira Ballot Process manages the submission of comments, the assignment of ballot weights to comments and the management of the overall vote of each registered balloter.

Specific details on how to use the tools to perform balloting can be found by following the links:

<insert links>