This page describes the UTG Task Force's recommendations to the TSC, and includes updates after the policy was approved. 

The oversight groups, proposal types, and voting configuration functionality is already in place in the UP Jira project, and these suggestions intend to adjust the current configuration to better support proposal submitters and reviewers while ensuring the correct level of oversight from the HL7 community.

UTG Oversight Groups (OSGs)

Individuals meeting the requirements noted below should be proposed as OSG members based on input from the set of management, work groups or other entities noted below. TSC would ratify the proposed members. 

The diagram below shows all UTG voters such as OSGs (including the Work Groups whose members will be included in these groups) and regular voters from the HL7 community.

Need to update Vocab to TI, replace MnM with the TSC for the V3 group, and remove MnM from FHIR. 

  • V2
    • Minimum of three voters who are members selected by V2 Management Group (could include participants from OO, InM, and other interested WGs)
  • V3 and CDA
    • Minimum of three members selected by CDA MG and MnM, SD TSC (could include participants from SD and other interested WGs)
  • FHIR
    • Minimum of three members selected by FMG (could include participants from FHIR-I and other interested WGs)
  • Realm-based
    • Minimum of three members selected by IC and USRSC
  • Terminology Vocab
    • Minimum of three members selected by Terminology Services Management Group (could include participants from Terminology Infrastructure and other interested WGs)

Membership of oversight groups:

  • Minimum of 3 OSG members from the combination of required sources
  • Ask applicable Management Group or the TSC (for V3) to provide all Work Groups to review and propose additional members to the any OSG from their MG and/or WG constituency to enable tighter engagement with UTG proposal process
  • All proposed members will be ratified by the TSCwould be sent to TSC for ratification
  • Each OSG member has to understand their vote represents the thinking of the domain group
    • An individual can only be in one OSG
    • This could change in the future if voting as an individual or as an OSG member can be supported by JIRA

Qualifications and Responsibilities for OSG membership:

  • Minimum Qualifications
    • Familiarity with the product family terminology requirements and methodology
    • Understanding of basic concepts of Vocabulary/Terminology (what are concepts, codes, code systems, value sets, and the identifiers for such; and how they differ and are used)
    • Active participant in HL7 and the WG calls and activities and projects
    • HL7 member (either individual, or named as one of their organizational HL7 persons) or voting member of an HL7 affiliate
      • TSC should weigh in on whether non-voting members of organizational members of HL7 International can vote in the Consensus Review process
      • TSMG suggests that anyone who is an individual member or an organizational member (whether marked as voting or not) be allowed to participate in Consensus Review process

-COMBINE the two categories below-

  • "Nice-to-Have" characteristics:
    • The Minimum above, plus:
    • Expert in the product family terminology requirements and methodology
    • Familiarity with the FHIR CodeSystem, ValueSet, and NamingSystem resources to address UTG-specific issues
  • Ideal additional qualifications:
    • The 'nice to have' above plus:
    • Comfortable and familiar with FHIR IG development and publishing (using the IG publisher) processes
    • Experience and some level of expertise with software development using GitHub
    • Detailed knowledge of terminology design and use
  • Responsibilities:
    • Commit to putting in the time to review and vote on proposals that have entered consensus review
    • Go through the UTG tutorials
    • Have a Jira login
    • Setup notifications so they can be aware when their attention is needed

UTG Proposal Types

There should be four UTG proposal types that require consensus review that cover the HL7 product families, including one proposal to cover multi-product family or general proposals (such as content created for an IG to be published in THO). Note that other proposal types will exist that do not require voting, those are explained below.

UTG Voting Proposal Types:

  • V2 proposal type
    • OSG quorum: TerminologyVocab OSG, Realm-based OSG, V2 OSG
  • V3 and CDA proposal type
    • OSG quorum: Vocab OSG, V3 and CDA OSG, Realm-based OSG
  • FHIR proposal type
    • OSG quorum: Vocab OSG, FHIR OSG, Realm-based OSG
  • Multi-product family or General proposal type
    • OSG quorum: Vocab OSG, FHIR OSG, Realm-based OSG, V3 and CDA OSG, V2 OSG

Additional UTG Proposal Types needed for workflow but not for voting:

  • External
    • Used for HTA review of requested addition and changes to code system and naming system THO entries
    • Also used for uri changes because only external entities can have a old uri changed for use in FHIR
    • This includes external identifier systems
  • Identifier Systems
    • Requests for new identifier systems. Additional analysis for this needs to occur. If consensus review is needed for this type, then OSG groups would need to be assigned.
  • Note that in the past International focused request could be a separate type but the group decided that these should be handled within the family-based type approach

UTG Voting

The UTG voting workflow is in place and most of the recommendations require adjustment of existing values and functionality.

A summary of the UTG voting process is below.

Need to update diagram above

Basic Voting Configurations and Workflow

  • Currently a JIRA user can request to be a UTG voter and must be approved to be allowed to vote. Proposal to change so that determination that the voter is an Active HL7 member is accomplished automatically.
  • All voters count as one vote. No OSG weighting or super-voting. (Presumed to be a configuration change only)
  • No Super-voter needed - remove this vote type 
  • A vote by an OSG member satisfies a quorum requirement for that OSG type and also counts a vote on the proposal (this is not a change).
  • All proposal types require a minimum of nine votes to progress
  • All proposal types must meet quorum (i.e. obtain votes from applicable OSGs)
  • Institute (already programmed but not implemented) a “must be completed” time limit ("expiry timer") so that after a set number of time (Proposal: 6045 days) if the proposal has not passed out of consensus review state, it is automatically pushed back to DRAFT.
    • When pushed back, the original submitter/watchers are notified with a specific note that they must do a better job of socializing the proposal to move it forward.
      • Consider also adding notification to the sponsoring WG list serve. 
    • An advantage to using this approach to "stalled" proposals is that when re-submitting the proposer must do a current pull which means the re-submitted proposal will be updated for currency and hopefully will not have merge conflicts if passed. Need to see if we can still pull from web alone.
    • There is an "Urgency" element that is not turned on but was added in part to support allowing things like a time limit to be set differently for different urgencies. Current proposal would be to not use this yet.

Voting Requirements

The following requirements must be met prior to calculation of the voting outcome to progress the proposal.

  1. Minimum of 9 votes (OSG and regular voters combined)
  2. Quorum requirements
    1. Vote from the TerminologyVocabulary OSG
    2. Vote from the Realm-based OSG
    3. Vote(s) from the applicable product family OSG
      1. V2 proposal type - V2 OSG
      2. V3 and CDA proposal type - V3 and CDA OSG
      3. FHIR proposal type - FHIR OSG
      4. Multi-product family or general - V2, V3 and CDA, and FHIR OSGs

Voting Calculations and Outcomes

  • Vote assessment/completion. Once proposal is under review (in consensus review state)
    1. With each vote, logic assess if the quorum has been met and if total number required votes is met. If both requirements are met, the proposal is marked as "Progressable."
    2. FUTURE ITEM IF NEED BECOMES APPARENT: To allow the last needed vote to be changed (if the vote was in error):
      1. There is a configuration for a timer delay that sets the duration that a progressable proposal will be delayed until moving to the next state during which a vote can be changed or some other intervention.  
      2. The committee believes this delay should be set to 48 hours to support cross the globe assessment of the proposal.
  • When a proposal meets all voting requirements, and following the timer delay, it progresses and the vote count is assessed for consensus.
    • Affirmative percentage requirement for "consensus agreement" on proposal is configurable.  
      • Current setting is 70% have voted either affirmative or negative to be considered "in consensus agreement." With 9 required voters, this would mean 7 affirmative.
    • A proposal that is "in affirmative consensus agreement" and moves to the "Sent for Implementation" state.
    • A proposal that is "in negative consensus agreement" and moves to the "Change Rejected" state.
    • If consensus has not been reached (i.e., the consensus requirement, currently configured at 70%), then the proposal transitions to "Meeting Needed" state. (i.e., failure to meet consensus.)
      • The author of the proposal will need to arrange the meeting and should include Work Groups associated with the Proposal type and must be attended by any negative voters and at least one OSG member in the required quorum set. It is open to anyone else but voting should be restricted to HL7 members (as is the UTG voting).
      • If the result of a proposal review meeting is not consensus, then TSC for now, eventually the Terminology Services Management Group (TSMG) would vote to resolve. All OSG members would have to recuse from the vote unless all attendees approve them to vote.
    • "Consensus Assessment Hold" in UTG is a parameter for a 48 hour time delay after the last vote that would achieve tally before the proposal progresses to allow confirmation among voters and acknowledges multi-timezone voting.
  • If an OSG member in the quorum group has recorded a negative vote when tallied, then the UTG curator SHOULD request the proposal author and the NEG voter discuss the issues raised to determine if any modification of the proposal is still warranted prior to implementing. Given that the proposal has passed for implementation, this is not a required action and is up to the curator. If a change is warranted, the proposal must go back to DRAFT.

UTG and Work Group Health

To ensure Work Group participation, proposals should be tied to WG health.

  • WG receives a point against their WG Health score if they are a sponsor of UTG proposals that have stayed in Meeting Needed status for longer than 3 months 
  • WG receives a point against their WG Health score if they are a sponsor of UTG proposals that has a Sponsor Approval Date of over 6 months that hasve stayed in Waiting  any "in process" status (other than "sent for implementation" or "tabled") for longer than 6 months. These are blue labels in the diagram below.

Note: Implementation of WG health requires us to have a standard way to select a sponsoring WG and also a way to notify WGs of the tickets they are responsible for. FUTURE ITEM IF NEED BECOMES APPARENT.

Screen Shot 2021-05-26 at 12.32.37 PM.png

  • No labels