Skip to end of metadata
Go to start of metadata

Attendance can be found Here

Co-Chair and Key Participant information can be found on the Agenda found Here

Discussion items


We did not review this content from the Tuesday Q5 meeting - in the scribe's opinion, this text needs to be reviewed.

RM suggests we have an adhoc joint call - outside of the WGM since we are running out of quarters. 

From Tuesday Q5: The rules for extensible binding strength are:

' FHIR-29968 - Getting issue details... STATUS

  1. there must be an expectation that a consumer of an instance is doing something computable that is largely dependent on having the data encoded at the granularity of the specified value set
  2. the value set is not comprehensive of all of the use cases that are present in the space. you are dependent on computation, but you know you won't always be able to
  3. the value set cannot contain a concept equivalent to other, because that wouldn't make sense
  4. the value set cannot have an abstract concept or a collection of abstract concepts that collectively cover the space 

Key discussion items

  1. extensible bindings should not have an expansion where there are concepts in the list that subsume other concepts in the list. ADD to list!! 
  2. maybe not, this might be useful in some cases
  3. you shouldn't have a set of concept codes that cover the entire space (e.g. Procedure), but at some levels it might make sense (e.g. skin disorders)
  4. It should be documented that:
    1. if a code is sent that is not from the value set expansion that decision logic can infer that the concept is not in the conceptual space covered by the value set (e.g. if the value set includes the concept diabetes, and a code outside the value set is sent, decision logic can infer that diabetes is not the condition conveyed)
  5. Guidance should include a clear statement that if you send a local code you are stating that it is NOT semantically equivalent OR subsumed by any of the included codes
    1. How does this statement align with the juvenile diabetes/diabetes example?

Question from scribe:

If the receiver is expected to evaluate all codes sent as mentioned yesterday, do we have a sense that implementers understand this nuance? Is there a patient safety risk if the receiving system does not, and in the example of diabetes/juvenile diabetes, evaluating only diabetes could be a patient safety risk. (concern based on the message that sequence doesn't matter, etc.)

Draft statement  for IG authors on using terminologyLloyd drafted some guidance that the attendees reviewed.

Policy for terminology in FHIR IGs


  1. if you can use existing terminologies, do so.
    1. External
    2. THO
    3. FHIR Core? 
      1. some discussion; not originally included, has been added
    4. Other IG specific terminologies
  2. Content has to be free for use within the space or be confident that all relevant implementers will have license already
    1. FMG approval currently listed as the approver of an exception
    2. Some discussion. The statement should be genericized - appropriate approval. 
      1. FMG may not be comfortable with being out of the loop with being in the approval workflow
      2. If another group is the approver, FMG wants to make sure that group would follow their guidelines
      3. DaVinci? probably didn't happen for those IGs
    3. Joan H: she has a request to get a Canadian SNOMED CT edition url
      1. There is only one url for SNOMED CT
      2. Carol: there is an open question about whether the various editions should be represented separately in THO. There is only one SNOMED CT code system URL. 
      3. Rob M suggests that this should be brought up during another session - Carol will contact Joan. 
  3. EXAMPLE binding strength: If no intention of defining any required or preferred terminology, SHOULD define example codes. 
    1. Used in production? go to another step. You can declare examples that reference real codes from for example SNOMED CT or LOINC. 
    2. Not used in production, but desire to share across IGs - use THO, KISS
      1. Shared dumping ground, in THO
    3. Not used in production, no value to reuse, IG specific, all examples in a single code system? (don't understand this one)
      1. Fixed pattern for an IG specific dumping ground
      2. [ig-base-canonical]/CodeSystem/example-do-not-use
  4. Net new content, with a data type of code, (Extension.value or Parameter.parameter.value), IG SHOULD define a Code System specific to the IG. The canonical url can be whatever the IG author wants. M&M will be creating some guidance for use of code data type.
    1. Discussion:
      1. RM: how do people move terminology out of their IG into THO?
      2. LM: when talking about code data type, it doesn't matter
      3. JD: he has IG specific codes, used in a CodeableConcept. He doesn't think they will ever be shared, they are IG specific. They are codes, but the data type isn't code.
        1. RM: discussed the Vocab thought process that IG authors lean towards using THO and not keeping terminology specific to an IG, or at least use the THO url.
        2. JD: too difficult to create content in THO
  5. Not data type code, low maturity (2 or lower) (profiles do not have maturity levels). An IG might profile a normative resource, and the IG is low maturity
    1. IG MAY define codes in [ig-base-canonical]/CodeSystem/temporary-codes, OR
      1. define a NamingSystem resource in UTG and use THO as the base url
    2. Discussion
      1. This is very close to what Vocab is proposing
      2. Any artifact that references the codes must be FMM 2 or under. Some nuances to work out here with the reference to maturity level. There is no maturity level for an IG artifact. Some day there will be maturity levels for profiles. Publishing doesn't support. 
      3. JD: why do we need to define codes into a temporary code system other than to point out to an implementer that they shouldn't be considered real 
        1. Why do they need to be lumped together in one code system? (Concept Domain). Make it super obvious to implementers that these things will change.
        2. Having separate CodeSystems provides some information
        3. Frank M. echoes JD's concern. 
        4. LM: you could create a hierarchy in the one CodeSystem to get the visual cue
        5. JD: still not seeing the value
        6. Peter Jordan: is JD's concern about affiliate/realm specific artifacts, or is the policy applicable to HL7 International specifications only? 
          1. International only, affiliates do not have to comply
          2. This is guidance 
        7. TK: putting the IG specific codes in one CodeSystem (temporary) might make it easier for governance, but it might be more difficult for implementers
        8. Compromise:
          1. [ig-base-canonical]/CodeSystem/temporary-codes or
          2. [ig-base-canonical]/CodeSystem/temporary-codes-x if the implementer prefers to create more than one code system
          3. Note: it was questioned whether we should do the same for the examples dumping ground.
        9. RM: This aligns closely to the Vocab workflow, here:  Workflow process for use of code system identifiers in FHIR - Draft
          1. Can this be tested in a connectathon - the terminology server part
  6. If at the end you decide you don't want terminology in THO, and it should only be in your IG, petition to remove from THO. 
    1. Note: the url might have to change
  7. Maturity level 3, not example, not code data type, not approved as an exception, the concepts should be in an external terminology. 
    1. IG specific CodeSystem resources are not allowed without an approval step
      1. they belong in THO, or
      2. an external code system
    2. Discussion:
      1. Implementing this will depend on being able to monitor maturity levels. Tooling dependency. 

Next steps:

  1. More review required of this very comprehensive material, along with a comparison and merging with the Vocab material
    1. Consider use of SHALL/SHOULD/MAY
  2. This joint meeting is with FHIR-I and not FMG, although the material is created in the FMG space and will eventually presented to Vocab, and then FMG. 
  3. Vocab will propose the policy and forward to FMG. 
  4. Note: LM doesn't see the tooling required to govern as being essential to the policy
  5. Once something is policy, then it can be enforced even if there isn't tooling support
  6. LM would like to attend the URL Task Force calls. 

Next steps

Meet to resolve unfinished business with regards to extensible bindings.

Action items

  • Rob McClure Schedule meeting with FHIR-I to discuss extensible binding strength definition and usage note updates
  • No labels