NOTE TO READERS: this page was discussed at Monday Q2, May 2022 WGM - changes in progress 

This page summarizes the policy documents and statements that have been developed over the years by the Vocabulary WG.

Listed below the current policies are the active discussions for policies that have been requested or appear needed, and are under discussion prior to finalization and adoption.

Vocabulary Work Group Approved Policy Statements

  1. Policy on case sensitivity of codes
  2. Policy on OIDs for SNOMED CT Extensions   (May 2022 WGM Monday Q2: archived - there isn't a current problem looking for a solution - guidance for Supplements will provide information)
  3. Policy for Intensional Value Set Definitions based on LOINC (May 2022 WGM Monday Q2: archived: content related to LOINC and intensional value sets may be added to THO)
  4. HL7 proposed guidance on use of displayName (V3 CD) and Text (V2.x CNE,CWE)  (Not a policy, but guidance for v2 and C-CDA - create new section and label "Guidance")
  5. Policy on use of translationCode in V3 (ISO 21090) coded datatypes   (this will be sent to the CDA Management Group and M&M- asking one of them to take ownership and update if necessary)
  6. Policy on use of Retired or Legacy HL7 Code Systems   (will be checked for consistency with deprecation task force recommendations - this is an implemented policy! - for now will stay on page)
  7. Policy on the expected content of "All Codes" value set (this will stay on this page...) (UTG/THO can enforce a url syntax)
  8. Policy on Deprecation of Vocabulary Objects in THO

Vocabulary Work Group Active Discussions Developing New Policies (in priority order)

  1. Policy on Maintenance of Code System Identifiers (URIs)
    1. Policy on creation of canonical URLs for UTG Code Systems   (migrate to THO documentation)
    2. Deprecated identifiers, preferred, authoritative, valid period   (this will probably be retired after review by Deprecation team)
  2. Code System Unification   (move to another section, this was tabled because it is dependent on the Deprecation Task force work)
    1. Not addressed in the Deprecation Task Force (as of May 2022)
    2. Synchronizing identifiers across product families
  3.  Versioning  (not active - move to not yet worked on section - and might not live here)
    1. More than one active during the same period
    2. Consequences
    3. ValueSets, CodeSystems, NamingSystems, ConceptMaps
      1. TSMG convened a Task Force that is proposing a versioning policy for the above resources, see THO Artifact Versioning Task Force Meetings
  4. Use of extensible value set bindings (preferred and required)   (this information will live somewhere, most likely not here, intent might have been to clean up info in the FHIR spec)
  5. Pre-Adopting Terminology Updates   (move to guidance - guidance to IG creators to eliminate warnings/errors - get access to something that hasn't yet been published in THO) (at some point someone might want to address the issue of referencing terminology from >1 source)
  6. CodeSystemFragments  (CC to look for recent ticket)
    1. When and where they can be used
    2. Who is responsible for a fragment?
  7. CDA Concept Domain / Value Set Support
    1. Lisa Nelson has brought up the question of how to best support a Concept Domain in FHIR
    2. Some have suggested that a Concept Domain may be represented as a Value Set that is bound to an element with Example binding strength
    3. Another option is for CDA to bind the element to a concept in the ConceptDomains code system.
    4. Vocab to provide guidance/policy statement and further capabilities with regards to IG processing and binding validation are MnM and FHIR-I topics.
    5. Ted to keep Jean Duteau in the loop. 
  8. Lower priority
    1. Policy on adding coded content to older HL7 code systems
    2. CodeSystem unification
      1. What updates are required for the losing CodeSystems to indicate they are  not to be used and have been replaced, and how will those be presented in THO
      2. Should the new/winning CodeSystem be related to the ones that are retired
      3. See ObservationInterpretation
    3. CodeSystem divorce
      1. What updates are required for a CodeSystem that is split into two or more CodeSystems?
        1. 2 (or more) new CodeSystems, and a retired CodeSystem?
        2. Should relationships be maintained between the CodeSystems?
    4. General approach to support combining concepts (from only same code system?) to form an expression. Obviously need to allow SCT CG but also support segmented meanings. See Combine CPT codes and hopefully also incorporate CPT Code Modifiers among many others.
      1. 2022-03-28: the "policy" now is that the Code System defines the grammar. 
      2. This may become a project when there is enough interest 
    5. FHIR binding requirements for use in sliced elements. Can an EXAMPLE binding support a specific code slice? See Can you use code system directly w/o valueset in slice?
      1. Said another way: Agreement or modification on existing FHIR approach to allowed content in slicing that is not in bound value set for element. See Can you use code system directly w/o valueset in slice?
      2. The binding of a model element is just one of many ways to express allowed values. It is not the only way. 
      3. 2022-03-28: this is complicated, an established approach has been implemented, and that approach might be considered loose
    6. There is currently no existing approved Vocabulary WG or TSC policy that OIDs for value sets in FHIR must be in the OID registry. Once a decision on this policy is made, we can decide that either:
      1. Must be in the registry, and then we must develop the process to get it there as different and additional metadata for the OID registry entry than is contained in the FHIR resource is required.
      2. Does not have to be, in which case we will need to approach the Pharmacy WG for them to decide if they need it in the OID Registry for ease of access and use by CDA and the V3 community.
      3. 2022-03-28: Discussed at TSMG? RM: we have not established that the HL7 OID registry is a registry of all HL7 OIDs - it is a registry of OIDs that were requested under the HL7 OID root. If we want to add a disclaimer, we have to send it into HQ. There might be OIDs referenced in IGs that are not in the HL7 OID registry (e.g. references to value sets in VSAC)
      4. Current OID Registry text:  HL7 has established this OID registry and assigns OIDs in its branch for HL7 users and vendors upon their request in its role as an ISO Registration Authority. 
        1. (note there are two FAQ links on this page, the top one is to an HL7 Confluence page, the bottom one is to a general OID page)
      5. If an OID is needed for an HL7 artifact, it will be made available for free.
      6. There is an OID generator in use - this tool could be made available, and as part of the process to create a new CodeSystem or ValueSet, we could assign an OID. 
        1. This would require some set up
        2. Some issues around making this tool secure
      7. Currently the request process leads people to something that implies, you MUST pay
      8. Lots of opportunity to improve the user experience

  • No labels