Education and Rollout Approach 

The educational and rollout approach for going live will be specialized for each group of individuals that need to be aware of UTG. The general public, the HL7 community, and HL7 vocabulary submitters all require varying levels of information about UTG. The sections below outline what notifications/information will be provided to each group. 

General Public

The general public will be provided high-level information about the UTG process. Requirements include:


Title: The HL7 Terminology (~15 min)

Description: This webinar introduces the HL7 terminology publication website and shows how to view and access this published terminology content that is referenced in HL7 standards.

Topics:

Internal Notes:

Completed webinar:

The HL7 Terminology

HL7 Community


The HL7 Community will provided the same high-level information about the UTG process, but will also include more information. Requirements include:

Title: Terminology Governance and Publishing at HL7 (~1 hour)

Description: This webinar introduces the HL7 terminology publication website and shows how to view and access this published terminology content that is referenced in HL7 standards. In addition, it will cover the publishing process for new releases and the update process for the current content.

Topics:

Internal Notes:

Completed webinar:

Terminology Governance and Publishing at HL7

HL7 Terminology Reviewers

The HL7 terminology reviewer group will be provided the same information information as the general public/HL7 community, but will also require more in-depth information for utilizing UTG review and vote on proposed terminology changes. Requirements include:

Completed Webinar:

Reviewing and Voting on HL7 Vocabulary Change Proposals

HL7 Terminology Submitters

The HL7 vocabulary submitter group will be provided the same information information as the general public/HL7 community, but will also require more in-depth information for utilizing UTG to request new vocabulary objects or vocabulary changes. Requirements include:

It is likely that this will be broken into three separate sessions due to the large amount of info that must be covered for this group. The sessions will include:

  1. Process (need to mention BitBucket)
    1. UTG Overview
    2. Change Proposal Overall Process 
      1. Mention the UP project on Jira and that everything is managed there
    3. UTG Workflow
    4. Becoming a Submitter
      1. Anyone can become a submitter, non-HL7 members need TSC approval (upon submitting form)
      2. Qualifications: former vocabulary facilitator role + additional skills
        1. Some familiarity with technical change management
        2. Some terminology expertise
        3. Ability to work on HL7 material on your local machine
    5. UTG Jira Project
    6. Creating a proposal
      1. Get Jira account 
      2. Becomes a submitter
      3. Create a change request
      4. Download current copy of content
      5. Make changes to the content and commit
      6. Submit changes for consensus review
        1. Certain items are required: Need sponsor approval date, links to change objects, included edited content changes
    7. Monitoring Consensus Review as a Submitter
      1. Receiving notifications
      2. Commenting on a proposal
      3. Expediting proposals
      4. Pulling proposal back to Draft, making suggested or required changes, and resubmitting
    8. Proposal Outcomes (refer to voting session for information on voting requirements)
      1. Approved - notification, goes into Curator workflow, and within some days depending on queue it will be implemented (current build)
      2. Rejected - notification, ticket is archived
      3. Meeting Needed - on submitter to set up a consensus group to decide how to triage proposal
      4. Withdrawn - submitter decides it is not necessary or what is being suggested doesn't make sense after clarifying comments (submitter rejects their own proposal)
      5. Tabled - the current solution is unclear and more time is needed to fully discuss and understand the material (pauses Consensus Review - like pulling to draft and resubmitting with no changes), may be to wait on people to come back from vacation, halts voting, many use cases, may be removed in the future if never used
  2. Content 
    1. Overview of the content
      1. Git archive, terminology source of truth, and Bitbucket change archive
      2. Terminology content (CS, VS, NS, concept domains, v2 tables, folder layout)
      3. Documentation content (IG control file (utg.xml), pagecontent folder and lists/manifests)
      4. Infrastructure content (templates and framework) - only certain people/circumstances allowed
      5. What folders contain the different bits of content
    2. Getting a local copy of the content
      1. From Bitbucket
        1. This is a Git archive database and it contains all of the changes from all submitters to the content
        2. It is accessible by the community
        3. When approved proposals are implemented and a new current build is validated, the Bitbucket change archive master is manually updated
    3. Making changes to the terminology content
      1. All the terminology content are XML files
      2. Any tool can be used to edit the XML files
        1. Can use text editor, XML aware editors, branch aware editors, etc. 
        2. Scripts and transforms
      3. Best way to describe overall process without looking at each element?
        1. All requirements for the four types of FHIR terminology resources that UTG employs (CS, VS, NS, list) must be adhered to
        2. Additional to support UTG
          1. Vocabulary WG versioning policy for types of resources
          2. Naming conventions
          3. UTG-specific extensions for CS/VS/NS (primarily for V3)
          4. UTG-specific properties for concepts
            1. Extended properties for V2 Tables
            2. Extended properties for Concept Domains (including bindings)
          5. Relationship between CS, VS, and V2 Tables for V2 content
    4. Reviewing and validating your changes
      1. XML syntax must be legal and valid
      2. Content changes may be viewed in their XML form
      3. Content changes may be built locally (generally for experienced FHIR IG developers)
    5. Saving/uploading changes and submitting for Consensus Review
      1. Local saves are only on your local machine
      2. Your change set in Bitbucket must be saved to the Bitbucket server before submitting
        1. There are fully documented specific tools that we have in the UTG project but some want to use tools that they are more familiar with. 3rd tutorial will discuss that. 
  3. Custom tools (developed as part of FHIR dev work)
    1. Setting up the environment and tooling
    2. Sourcetree
    3. Vocabulary Server
    4. Vocabulary Editor
      1. Expanding a VS
      2. Detailed walk-through of creating/editing artifacts and editing lists (manifest entries)

Questions:

  1. Best way to flow from creating a proposal, to content, and back to submitting a proposal?

Other Rollout Requirements