Skip to end of metadata
Go to start of metadata

This page outlines the project objectives and architecture in the following sections:

Project Objectives

Process Description and Flow

Major Components of UTG

Terminology Components of UTG

Additional Architecture Details

UTG Voting Overview

Project Objectives

  • Minimize the number of ongoing support resources (and HL7 financial commitment) that are needed to support vocabulary maintenance as the volume of work increases
  • The Terminology governance process must effectively and efficiently fit into the HL7 balloting and publication processes so as to improve the production of the HL7 products, and not adversely impact them.
  • The tooling developed must be useful by a broad enough community to provide sustainability for ongoing maintenance and development
  • It must be an open process - proposals for change can come from anyone
    • Member or non-member
    • Familiar with committee & HL7 structure or not
    • Anywhere in the world
  • It must be a consensus-based process: Viewpoints are sought from all impacted stakeholders and the objective is to satisfy all those stakeholder needs as much as feasible
  • It must be a broad process: Stakeholders represent the full range of perspectives that are currently impacted by or are likely to be impacted by proposed changes - countries, product lines, implementer vs. academic, etc.
  • Tooling for authoring/viewing needs to be accessible independent of platform (Windows/Mac/Unix).  Could be cloud-based, but offline editing is required.  Can’t depend on “restricted” technologies (e.g. Google in China)
  • Tooling for reviewing proposals and submitted endorsements should be accessible independent of platform, and probably should support mobile platforms as well.
  • Process works across all terminology content
    • Different product families (v2/v3/CDA/FHIR/etc.)
    • Both HL7 content and content published by outside organizations in multiple
    • Different artifacts (code systems/value sets/concept domains/indirect bindings/concept maps/code system supplements)
    • May scale to other types of artifacts (for later implementation)
  • Process produces “awareness” in the community that’s impacted
    • Those who already use the vocabulary artifact
    • Those who are considering the vocabulary artifact
    • Those who have used it in the past and must access/process historical records
    • Those who have indicated a specific interest
  • Mechanically produces technically valid content with minimal manual overhead on those who apply changes
  • Encourages quality/good practice as part of creation/maintenance while not ignoring practical needs
  • Process allows for (and ensures) due diligence review
    • Participation from international community for artifacts with potentially international scope
    • Participation from those who know (and care about) good vocabulary processes
    • Participation from those who implement - actually use the vocabulary or might
    • Review by both those who are members/part of HL7 inner circle and those who are not
  • Content is protected from undue influence by participants outside of intended scope and by any particular stakeholder group within the intended scope
    • Internationally-scoped content is protected from undue influence by any particular realm/country
    • Particular realm/country-scoped content is protected from undue influence by the international community, and is identified so as to prevent inadvertent use in other realm/countries
    • Interested individuals and organizations are clearly identified, including individual-organization affiliations and care is ensured to balance inputs
  • Knowledge/experience/capability of participants is weighted by the process
    • Those who know more, have more experience, and have best skill have greatest influence
    • Influence accrues to those who do the work
  • Process ensures that content being reviewed is understandable by those who might perform the review
    • Clear what’s being changed - what the old version is, what the new version will be
    • Clear what the reason is for the change
    • Clear what (if any) the impacts will be on existing/planned artifacts
  • Process pushes the work to where the greatest bandwidth is
    • First choice: proposer (proposer could have an agent - agent should generally not be volunteer)
    • Second choice: HL7-funded resources
    • Last choice: volunteers
  • Process is responsive
    • Changes can migrate from “proposed” to “applied” in ~month
    • Changes are ideally continuous, not driven by specific HL7 events
    • Process does not depend on synchronous/multi-person meetings
  • Process reflects governance obligations
    • Adheres to expectations of ANSI & HL7 voting process
    • HL7 has ultimate authority over HL7 content
    • Process adheres to IP rules (not misusing copyrighted material, adhering to rules of terminology sources
  • Process is transparent - proposers and community are aware of where proposals are at in the process, what decisions have been made and why, and what steps still need to occur
  • Tooling should be multi-purpose and minimally specific to just this one terminology maintenance process. Ideally tooling should be generally available commercial products that can be configured straightforwardly to implement this process and its workflow
  • The ‘Terminology Objects” referenced here are HL7 curated Code Systems (and Code System Supplements?), Value Sets, Persistent Context Bindings, and Concept Domains.  In the future it may be extended for use with the RIM ontology (should the RIM shift from a structural model to an ontology), and for secondary objects such as Concept Maps.
  • Process will permit evolution over time in order to accommodate changes in priorities, funding exigencies, and changes in organizational priorities, and potentially new standards families that will emerge in HL7 in the future.
  • Process will be sustainable with existing and anticipated resources
  • Relationship With Balloted Artifacts
    • HL7 terminology will be treated as a separate activity from the product family balloting processes, although there will be synchronization and coordination points and requirements in order to work effectively for implementers and balloters.  Ballot feedback on the content of HL7 terminology artifacts will be considered as input to the terminology maintenance process, so that output from that process may be used in reconciliation and final publication of normative standards.  Note that there is some HL7 terminology content which has limited or no impact on the structure of balloted model artifacts, and so can be treated in a similar manner as feedback on the content of LOINC or SNOMED.  If the use of a particular code has a material impact on the use of a standard, the responsible work group may need to request a high priority terminology change in order to resolve a negative ballot.  If there is no material impact, the comment may be found “not related”.  If the external terminology custodian does not agree to make the change as desired by the balloter, the work group may need to re-design the artifact to use a different terminology or may need to move forward with the negative vote outstanding as per usual processes.
    • The process outlined in this document is proposed to be the process for treating the HL7 stewarded terminology objects as if they are an ‘external’ terminology, ie separate from the development and approval processes for balloted HL7 standards.  There are already a handful of HL7 terminology objects that are treated in this way (e.g. Table0396)
    • Some terminology artifacts (e.g. structural codes) may be managed directly as part of a product family’s artifacts and not be subject to this process.   Each family would need clear rules for what terminology artifacts would and would not be subject to this process.  These objects must be clearly identified so that it is clear to anyone in the community that wishes to make changes to these where the source of truth resides and what the exact process must be for each.

Process Description and Flow

At a very high level, the process consists of two parallel processes:

  • Creating and editing proposed submissions for changes to terminology and reviewing and asserting opinions (which are here called 'endorsements') on the proposed changes;
  • Monitoring the endorsement process, and applying changes for those proposals that have achieved the level of consensus required for implementation in the HL7 Terminology, and monitoring/facilitating the terminology publication processes

These run in parallel and asynchronously, and are coordinated and facilitated by tooling which makes use of a centralized (or federated) HL7 Terminology Store and a broadly accessible centralized (or federated) Proposal and Endorsement Store.  The process of proposals and endorsements is broad across the HL7 community, and the process of monitoring and applying changes is performed by a part-time Terminology Curator.

Diagram 1: General Architecture of new process

Overall Process Flow

The diagram below illustrates the detail of the top level overall process flow.   It incorporates a number of well-contained sub-processes which are detailed throughout the requirements section.  These are:

  • External Terminologies Process with HTA
  • Endorsement Acquisition Process
  • Create Delta Process
  • Endorsement Triage Process
  • Consensus:Controversial Resolution Process
  • Apply Approved Proposal Using Tooling Process

Diagrams outlining the processes above can be most clearly viewed in the project document from the Document Repository: UTGPdocument_v10.docx

The proposed process for HL7 Unified Terminology Governance is divided up into four separate processes.  Each of these can be developed separately, have their own sets of tooling (although they share some tools), and interact with different Stakeholders in the process.   This is illustrated by the diagram below:

The UTG group is concerned primarily with the blue (submit), green (voting), and applying (purple) process boxes above.   It is anticipated that the key HL7 Stakeholders (WorkGroups, FHIR implementation communities, etc.) may use their own tools and processes in order to determine and specify the changes that they feel are needed to the HL7 Terminology.  These proposed changes enter the HL7 Unified Terminology Governance Process with the creation and submission of a formal HL7 Terminology Change Proposal (abbreviated "Proposal" in all other diagrams below).  A single identified point of contact for the Stakeholder group is associated with the Proposal (labeled "Submitter" in all diagrams).    There is only a single entity which operates the tooling and is responsible for changes and updates to the HL7 Terminology Store; that is the Terminology Curator.

Proposal Lifecycle and States

A proposal can be thought of as having a lifecycle which is modeled by the State Diagram shown below.  A proposal is begun and is edited, then is submitted and goes out for endorsement, then moves either back to the edit state, or is processed as per the result of the endorsement period (approve, reject, process-as-controversial).  As this is a complex lifecycle, the diagram helps to illustrate how each proposal flows through this system.

The proposal goes through the workflow in JIRA is as follows:

Once a proposal is approved it goes through the implementation process workflow below and is published to the Source of Truth. 

Major Components of UTG 

There are several major components of the new process.  These can be listed as:

  • Terminology Persistence and Maintenance Data Store
  • Terminology subset extraction for viewing and publishing
  • Proposal Persistence and Endorsement tracking Data Store
  • Proposal Viewing/Creating/Editing
  • Proposal State Workflow Management
  • Terminology Curator Role
  • Endorsed Proposal Change Application

Terminology Components of UTG

The HL7 Terminology across all the product families may be classified into three broad categories:

  • Structural Terminology
  • Domain Content Terminology
  • External Terminology

The so-called 'Structural Terminology' consists of HL7-defined technical coded content which is very tightly bound to the model structures and internal HL7 components within the various balloted and published standards.  This includes for example the tables in V2 of the Message Structures, the code systems in V3/CDA for HL7 Realms and Datatypes, and code systems in FHIR for specific status codes.  There are many of these across the product families; because this content is tightly bound to the technical artifacts under ballot, and usually also bound to specific versions, it is felt that maintaining this content through a shared harmonized governance process would be wasteful of resources and counter-productive.  The same process and tooling and persistence mechanisms can be used to maintain it, but content of this type should bypass time-consuming editing and consensus-building processes in the workflow, and should instead go direct to application of the proposals in preparation for a ballot.

The main part of HL7 Terminology can be referred to as 'Domain Content Terminology'.  This includes, for example, V2 Telecommunication Use Codes, V3/CDA ActCode and Privacy content, and FHIR ReferralCategory and VisionEyes.   This content would all be subject to the suggested governance process.

Finally, there are many value sets in HL7 Standards which are built on content from external terminologies such as LOINC, NUBC terminologies, ISO terminologies, SNOMED, etc.  There are special processes for changes in content for these; changes to value set definitions are handled through the suggested governance processes, but requested changes or additions to these external terminologies are subject to a separate process mediated through the HTA as dictated by our negotiated relationships with these external organizations.

Additional Architecture and Design Details

UTG Architecture and Foundational Project Documentation

Design Information (UTG)

UTG Handling of non-HL7 Content

UTG Release Process Design and Implementation

  • No labels