UTG Task Force Recommendations to TSC

This page describes the UTG Task Force's recommendations to the TSC.

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.

• V2
  • Minimum of three members selected by: V2 Management Group, OO, InM
• V3 and CDA
  • Minimum of three members selected by: CDA MG, MnM, SD
• FHIR
  • Minimum of three members selected by: FMG, FHIR-I, MnM
• Realm-based
  • Minimum of three members selected by: IC, USRSC
• Vocab
  • Minimum of three members selected by: Vocab, HTA

Membership of oversight groups:

• Minimum of 3 OSG members from the combination of required sources
• Ask all Work Groups to review and propose additional members to any OSG from their WG constituency to enable tighter engagement with UTG proposal process
• All proposed members would 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)

• "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:
  • Go through the UTG tutorials
  • Have a Jira login
  • Commit to putting in the time to review and vote on proposals that have entered consensus review
  • 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: Vocab 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
• 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.

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: 45 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 is 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.
• 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 Vocabulary 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. 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 have stayed in any "in process" status (other than "sent for implementation" or "tabled") for longer than 6 months. These are blue labels in the diagram below.