NOTE: This content is draft and has not yet undergone review by the FMG or vocabulary work groups!

Proposed rules for IG terminologies in HL7-published IGs:

  1. Use 'standard' codes: If it is possible to use existing terminologies (because they have appropriate licensing and the semantics and granularity meet the use-case), then IGs are expected to use those terminologies
    1. ‘Existing terminologies’ include both external terminologies, such as SNOMED, LOINC, ICD, etc. as well as terminologies maintained in (THO).  It also includes terminologies defined in FHIR core or in other IGs that are dependencies of the IG being developed.
    2. If codes are needed from an external code system that does not yet have a URL registered for the CodeSystem in THO, HTA processes to determine a canonical URL, including the policy around using a temporary URL must be followed.
    3. Appropriate management group approval (currently FMG) is required if the licensing for the selected terminology does not make it freely available to all implementers within the scope of implementation unless the use of the terminology is already mandated for use by those same implementers by legislation and their paid license for use would cover the proposed new use as well.
  2. Example codes: If the IG has no intention of defining any required or preferred terminology, it SHOULD provide example codes that can be used and validated within example instances and that demonstrate the breadth of concepts expected to be covered as well as the range of granularity that might be expected.  NOTE: This means you're using example bindings. If no standard codes (as per #1) are available, the IG has three options:
    1. If the codes to be used are ones that might appropriately be used in production instances and it is the intention of the IG authors that this occur, follow the process outlined in #4 & #5
    2. If the codes will not be used in production (example and illustrative codes) but might be used by other IGs and there is value in having a shared set of codes across IGs, then the users shall submit the codes for inclusion in THO using the UTG tool to add codes to a special code system with the canonical URL Ideally, the UTG tool should allow such registrations with minimal overhead.  Such codes SHOULD NOT declare relationships with other codes, though grouping abstract codes may be used to allow simple intentional value set declaration.  These codes SHALL only be used in value sets bound exclusively with example bindings.
    3. If there is no value to re-use, the IG SHALL define the codes within an IG-specific CodeSystem with the canonical URL [ig-base-canonical]/CodeSystem/example-do-not-use. Note that this means that all IG-specific example codes will be defined within a single code system. These codes SHALL only be used in value sets bound exclusively with example bindings.
  3. Codes for 'code' elements: If the codes being defined are used within an Extension.value or Parameters.parameter.value of type ‘code’, the element must follow MnM guidance for when IG elements should use ‘code’ rather than ‘Coding’ or CodeableConcept (to be developed). In this case, the IG SHOULD generally define a code system with a canonical URL based in the IG and a URL tail (i.e. of their choice in the namespace of their implementation guide.  (External code systems can be leveraged instead if there is no concern about external revision of the code system negatively impacting its intended use within the extension.)  There are no constraints on the canonical URL of the code system and different code systems can be used for different extensions, if appropriate.
  4. Low maturity codes: If the IG artifacts referencing the codes are maturity level 2 or lower, the implementation guide MAY define codes in a code system with the canonical URL [ig-base-canonical]/CodeSystem/temporary-codes or temporary-codes-x (where 'x' is an IG-determined suffix) for all situations where none of the previous options apply. If there is an expectation that the eventual code system will live in THO, the IG can alternatively register a NamingSystem for the proposed code system using UTG.  However, the code system content will be defined (for now) in the specific IG.  (TODO: describe how to use a THO URL for a code system appearing in an IG,)  All codes, regardless of their purpose that can’t be found in external systems must be defined in this one code system.  Abstract codes may be introduced to allow for easy construction of intensional value sets.  The expectation is that all of these codes will eventually be proposed to and incorporated into appropriate external code systems (e.g. SNOMED, LOINC, THO).  The temporary IG-specific code system allows for experimentation and confirmation of requirements through early implementation and connectathon.  Official registration of ‘real’ codes would come once requirements are more solid.
  5. IG-specific codes: If (generally after implementation experience with the temporary codes defined in step #4) there is a strong belief that the codes being used will only be relevant to their IG, they can petition the Terminology work group (or other appropriate management group) to allow the code system to be remain defined locally to the IG only (in which case the rules in #3 apply.)  Such code systems would have an IG-defined URL which would NOT contain the "temporary-codes" string.
  6. Define new codes: In order for any of the IG artifacts referencing temporary codes to reach maturity level 3 or higher, all terminology used in value sets with a binding strength other than ‘example’,  not used in extension values or parameter values with a data type of ‘code’, and not approved as an exception in step #5 must exist in an ‘external’ terminology and cannot be published as part of an HL7-maintained IG. Typically this will mean submitting requests for codes through the HTA, through the UTG process or engaging with other external terminology providers.
  • No labels