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

FHIR Ballot Process

From HL7Wiki
Jump to navigation Jump to search

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

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 discouraged.)
  • 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.)

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
  • 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 identifying 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
  • 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 done 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

  • 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