FHIR Ballot Process

This page is a draft as we refine the FHIR ballot process. This is a working page; the final version may be published in some other form.

This process aligns with requirements of the HL7 Governance and Operations Manual as well as ANSI requirements while reflecting differences in how the FHIR specification is managed. Where processes diverge from traditional HL7 balloting processes, these divergences should be viewed as temporary and experimental as the organization goes through a process of re-examining ballot processes for the entire organization.

For review of this process, see FHIR Ballot Process Review

Submission of Ballot Comments

• ballot comments are submitted through the standard ballot procedure (e.g. excel spreadsheets) submitted using the HL7 Ballot Desktop. (Free text comments are accepted as well, though not preferred.)
• as befits the FHIR publishing differences, the ballot submission spreadsheets have a few differences from the standard ballot submission template:
  • The number of heading rows have been reduced to one to maximize screen real estate
  • The following columns have been removed: Ballot WG, Artifact ID, Chapter, Pubs, Disposition External Organization, Referred To, Received From and Notes
  • Additional columns have been added to capture ballot URL, Tracker Item #, Summary, Disposition Date, Mover/Seconder
  • Column order has been adjusted to group related content together
  • Formatting has been altered to make clear which elements are considered to be "required" for a complete ballot submission.
  • A few columns have undergone minor name changes to improve their clarity.
  • Where appropriate, drop-down values have been adjusted to improve submission consistency
• Balloters are free to submit line items directly to the tracker if they feel comfortable doing so, but must still submit a ballot spreadsheet with row for each tracker item they consider to "support" their negative. (These items may have been submitted to the tracker by themselves or simply be existing tracker item submissions they agree with and wish to include as part of their ballot.)
  • The first page on the ballot submission form will include an invitation to follow this process and a link to a wiki page providing instructions for doing so

Notes:

• The standard ballot amalgamation macro will be adjusted to process both the "standard" and modified FHIR formats. Due to the architecture of the macro, these changes are small and will have minimal maintenance impact
• The documentation tabs have been adjusted to reflect modified columns and headings.

Reconciliation Process

• Reconciliation occurs following the HL7 GOM, bylaws, and processes, and also subject to the various committee DMPs
• The only difference between the FHIR ballot reconciliation process and other ballots is that FHIR uses gForge as the authoritative mechanism to track the status of the ballot line items instead of using the ballot spreadsheets

The FHIR gForge process

• once the ballot closes, the spreadsheets are consolidated (including text comments from the ballots), and one of the FHIR editors checks each entry for integrity (is the line item understandable, is the vote valid, are the references correct.) Non-valid line items are marked
• initial triage is performed in the spreadsheet - assigning responsible committees, cross-linking related ballot line items, correcting/populating missing URLs, assigning priorities, adding descriptive summaries
• all valid line items are uploaded to gForge, one task for each line item
  • The tooling uses JavaScript to parse the consolidated spreadsheet saved as CSV and populates the appropriate fields within the tracker based on the spreadsheet.
  • This tooling is considered a "temporary" solution as a more robust solution would involve a tracker with a programmable API.
  • A list of ballot line items referencing existing tracker items is processed and used to find and update existing tracker items to mark them as associated with the ballot, as well as supplementing the existing tracker item with referencing balloter information, in-person review requests and additional comments
  • The tooling clearly marks which items are ballot-submitted (including which ballot) in a manner that cannot be duplicated by a direct tracker submission.
• committees work on ballot line items like any other gForge comment - they are prioritised / resolved / etc
• for ballot line items, when the items are approved by committee, the disposition details are recorded in the appropriate fields for subsequent extraction
  • gForge fields for this use are named the same as in the ballot spreadsheet (mover, seconder, work group, meeting date/quarter, vote)
  • Meeting minutes must identify the tracker items resolved and the individuals present for each vote.
• The consolidated ballot spreadsheet is also distributed to work groups for use as a backup in the event of issues with gForge and/or network availability, with the expectation that resolutions would then be propagated into the tracker once the tracker is available.

Why FHIR uses gForge

• scale the ballot reconciliation process to involve multiple committees in a more efficient manner than multiple spreadsheets
• provide far greater visibility and transparency to the process - balloters can see the current state of all of their own items as well as everyone else's. Balloters and community members can comment on proposed dispositions and make suggestions
• this process provides a single point of engagement (no need to sign up for multiple list servers or attempt to attend conference calls at potentially inhospitable times just to provide feedback on a line item)
• integrate the ballot issues with other standing issues.
  • Feedback to FHIR is continuous. While ballot feedback must be given special status (at least for DSTU and normative ballots), all comments must be dealt with and managing this through a single integrated interface simplifies processes for both work groups and commenters
• provide open public traceability for all changes to the specification
  • All changes made to tracker items are logged, as are all comments. Comments can be searched and feedback provided within and outside ballot processes can be easily analyzed for metrics on stability of various parts of the specification
  • Individuals can sign up to "monitor" ballot line items of interest (and automatically monitor any they have submitted themselves).

Finalization of Ballot Reconciliation

• Once all line item tasks for a given ballot are resolved (easily checked by setting the appropriate filter in gForge search), the ballot can be closed
• An extract is taken from gForge and converted to a ballot spreadsheet
  • An Excel extract is generated from the filtered ballot items. A macro is then used to copy the appropriate columns across to the ballot spreadsheet.
• the ballot is closed using the normal procedure on the ballot desktop (upload ballot reconciliation spreadsheet etc), seek formal withdrawals, etc.

Ballot process requirements

• ANSI requirements must be met
• For the near term, existing GOM requirements must be met. (Changes to the GOM could be contemplated in the future if benefit was seen.)
• It must be possible for the FMG and other ballot process managers to have continuous up-to-date views of the status of all ballot comments
• It must be possible for balloters and other interested parties to see the current status of their own comments and other comments of interest, regardless of disposition WG and without needing to sign up for individual work group list servers or monitor general list server traffic
• It must be possible to seamlessly move ballot items between work groups in an efficient manner with no risk of items becoming unassigned or not properly tracked
• All changes proposed to FHIR must be entered into the tracker and any risks of divergence between decisions recorded in the tracker and content reflected in the ballot reconciliation spreadsheet should be minimized
• It should be possible to track exactly who made what comments on a particular ballot line item
• New process expectations for work groups should be minimized. (Note: All work groups doing FHIR development work must manage tracker items regardless of how ballot reconciliation is handled)
• The process must support parallel item resolution with active management to allow swift completion of the reconciliation process (Target is 2-3 months for 500-1000 comments spread across at least 15 work groups).
• The process should be available to and intuitive to use for all balloters as well as all work group members

Additional discussion

Weight of vote comments vs. non-vote comments

• Comments from non-voters *must* be considered as part of the evolution of the specification to ensure that there is no barrier to implementers providing feedback and to ensure that FHIR is perceived as a truly "open" specification. (This is not a significant departure from HL7 general practice as feedback on HL7 specifications could always be raised by non-voters on conference calls, at WGM meetings and via list server.)
• Comments submitted as part of (or referenced by) formal votes MUST be reconciled prior to publication.
• Non-vote comments (submitted in a sufficiently timely fashion) MUST be reviewed and prioritized but might not be reconciled prior to publication, depending on impact/priority
• Voters have the right to not withdraw their negatives and influence whether the specification passes or not and goes to publication. Non-vote comments have no formal influence one whether the specification is published