reverse=true semantics for ConceptMap/$translate

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • R5
    • Terminology Infrastructure
    • ConceptMap
    • Hide

      Existing text:
      if this is true, then the operation should return all the codes that might be mapped to this code. This parameter reverses the meaning of the source and target parameters

      Proposal: re-word the documentation as follows:

      If true, then the operation should return all the codes that are mapped to the 'code'/'coding'/'codeableConcept' input parameter.

      In this case:

      • The input code or coding(s) must belong to the target{{Scope}} ValueSet (rather than the source{{Scope}} ValueSet)
      • Any provided dependency parameters are matched against ConceptMap.group.element.target.product (rather than ConceptMap.group.element.target.dependsOn)
      Show
      Existing text: if this is true, then the operation should return all the codes that might be mapped to this code. This parameter reverses the meaning of the source and target parameters Proposal:  re-word the documentation as follows: If true, then the operation should return all the codes that are mapped to the 'code'/'coding'/'codeableConcept' input parameter. In this case: The input  code or coding (s) must belong to the target{{Scope}} ValueSet (rather than the source{{Scope}} ValueSet) Any provided  dependency  parameters are matched against  ConceptMap.group.element.target.product  (rather than  ConceptMap.group.element.target.dependsOn)
    • Carmela Couderc/Michael Lawley : 4-0-0
    • Clarification
    • Non-substantive

      The detailed specification for $translate needs work.

      With the changes to the ConceptMapRelationship code system, it is less problematic, but there's still the issue that the values of match.concept when reverse=true are source concepts, not target concepts.

      [It might make sense for {{match.concept}} to be renamed as {{match.target}} for the forward case and {{match.source}} for the reverse case, but {{match.source}} is already taken by the ConceptMap.]

       

      Secondly, the semantics around the use of reverse=true with non-trivial ConceptMaps – those that include unmapped provisions and/or product / dependsOn clauses is quite unclear.

       

      Thirdly, the semantics around a normal (reverse=false) $translate where there are dependsOn but no (or incomplete) dependency parameters is also unspecified.

      [Specifically, if there are two map entries (A -> X) and (A -> Y) where each has a dependsOn condition, what happens with a $translate with code=A but no dependency parameter?  Should it fail or return both X and Y.  If it returns both, then there's no indication to the client about the existence of those conditional elements.]

       

      Original thread https://chat.fhir.org/#narrow/stream/179202-terminology/topic/ConceptMap.2F.24translate.20and.20the.20reverse.20flag

       

            Assignee:
            Marc Duteau
            Reporter:
            Michael Lawley
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: