Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


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. Where the folders are located in the Source of TruthProcess (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
    Detailed walkthrough
    1. Vocabulary Server
    2. Vocabulary Editor
      1. Expanding a VS
      2. Detailed walk-through of creating/editing artifacts and editing lists (manifest entries)


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

Other Rollout Requirements