Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-40504

Resolve problem with ConceptMap properties (and task 39151)

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R5
    • Terminology Infrastructure
    • ConceptMap
    • Hide
      1. add code to the type list for ConceptMap.property.type  
      2. add ConceptMap.property.system (0..1) canonical
      3. add constraint:  If ConceptMap.property.type is code, ConceptMap.property.system must be present
      4. Make the following name changes to mapAttribute elements:
        1. Change the name of ConceptMap.mapAttribute  to ConceptMap.additionalAttribute
        2. Change the name of ConceptMap.group.element.target.dependsOn.mapAttribute  to ConceptMap.group.element.target.dependsOn.attribute
        3.  Change the name of ConceptMap.group.element.target.product.mapAttribute  to ConceptMap.group.element.target.product.attribute 
      5. Update the definitions of ConceptMap.additionalAttribute to:
        1. Short definition
          1. Definition of an additional map attribute to act as a data source or target
        2. Longer definition
          1. An additionalAttribute defines a data element found in the source or target data model where the data will come from or be mapped to. Some mappings are based on data in addition to the source data element, where codes in multiple fields are combined to a single field (or vice versa). 
        3. Comment
          1. Concept Map attributes are not used to define additional data elements where mapping data can be found. For an example, see [Specimen Type v2 -> SNOMED CT Mapping(conceptmap-example-specimen-type.html)
      6. Update the definitions of ConceptMap.property to the following: 
        1. Short definition = Additional properties of the mapping
        2. Longer definition = A property (new element name) defines a slot through which additional information can be provided about a map from source -> target.
        3. Comment = Multiple occurrences of ConceptMap.group.element.target.property may occur for a ConceptMap.property where ConceptMap.group.element.target.property.code is the same and ConceptMap.group.element.target.property.value differs. This may be used to supply for example, mapping priority, provenance, presentation hints, flag as experimental, and additional documentation. 
      7. There are other changes that must be made in the ConceptMap text - scope and usage. We will address these at another time. GG to enter a ticket. 
      8. $translate changes 
        1. Input parameter:
          1. Change the name of dependency.element to dependency.attribute
            1. Change the description from: The element for this dependency to: The attribute for this dependency 
        2. Output parameters:
          1. Change the name of match.product.property to match.product.attribute
            1. Change the description from: The element for this product to The attribute for this product
            2. Change description from:  The element for this product to The attribute for this attribute
                1.  Change the name of match.dependsOn.property to match.dependsOn.attribute
          2. Add an output parameter
            1. match.property with description = The property of the mapping
              1. Sub-parts:
                1. uri
                2. values from ConceptMap.group.element.target.property.value 
      Show
      add code to the type list for ConceptMap.property.type   add ConceptMap.property.system (0..1) canonical add constraint:  If ConceptMap.property.type is code, ConceptMap.property.system must be present Make the following name changes to mapAttribute elements: Change the name of ConceptMap.mapAttribute  to ConceptMap.additionalAttribute Change the name of ConceptMap.group.element.target.dependsOn.mapAttribute  to ConceptMap.group.element.target.dependsOn.attribute  Change the name of ConceptMap.group.element.target.product.mapAttribute  to ConceptMap.group.element.target.product.attribute  Update the definitions of ConceptMap.additionalAttribute to: Short definition Definition of an additional map attribute to act as a data source or target Longer definition An additionalAttribute defines a data element found in the source or target data model where the data will come from or be mapped to. Some mappings are based on data in addition to the source data element, where codes in multiple fields are combined to a single field (or vice versa).  Comment Concept Map attributes are not used to define additional data elements where mapping data can be found. For an example, see [Specimen Type v2 -> SNOMED CT Mapping(conceptmap-example-specimen-type.html) Update the definitions of ConceptMap.property to the following:  Short definition = Additional properties of the mapping Longer definition = A property (new element name) defines a slot through which additional information can be provided about a map from source -> target. Comment = Multiple occurrences of ConceptMap.group.element.target.property may occur for a ConceptMap.property where ConceptMap.group.element.target.property.code is the same and ConceptMap.group.element.target.property.value differs. This may be used to supply for example, mapping priority, provenance, presentation hints, flag as experimental, and additional documentation.  There are other changes that must be made in the ConceptMap text - scope and usage. We will address these at another time. GG to enter a ticket.  $translate changes  Input parameter: Change the name of dependency.element to dependency.attribute Change the description from: The element for this dependency to: The attribute for this dependency  Output parameters: Change the name of match.product.property to match.product.attribute Change the description from: The element for this product to The attribute for this product Change description from:  The element for this product to The attribute for this attribute  Change the name of match.dependsOn.property to match.dependsOn.attribute Add an output parameter match.property with description = The property of the mapping Sub-parts: uri values from ConceptMap.group.element.target.property.value  
    • Grahame Grieve/Michael Lawley: 6-0-0
    • Enhancement
    • Non-compatible
    • R5

    Description

      Task FHIR-39151 proposed to normalise ConceptMap property definitions to be like the way that the CodeSystem properties are defined. That was approved by TI, but I reopened it because they are not the same thing: the existing 'properties' elements which the task proposed to change are specifically defined to be devoted to wrangling between data elements of different scope:

      "this is a product of the mapping that goes in the output data set somewhere"

      But Michael Lawley has a different use case:

      "something that helps advise which mapping to choose"

      E.g. a property of the mapping itself, which is what task 39151 was trying to provide
      This is a legitimate use case, but not one we'd considered outside task 39151 - at least, not formally to my knowledge. Michael's just been using the existing product property since that's what's was there, though it's not a proper use.

      There's even got an example in the spec: https://github.com/HL7/fhir/blob/master/source/conceptmap/conceptmap-example-priority.xml. But that example has the same problem: it's using output products but actually they contain properties of the mapping.

      So after talking about it, Michael and I propose that we:

      1. rename the existing 'property' to 'mapAttribute' in both the root and on ConceptMap.group.element.target.dependsOn and ConceptMap.group.element.target.product

      2. clone the CodeSystem property framework (as originally proposed in the task) and add ConceptMap.group.element.target.property for the things Michael has a need for. (and make it clear that these are properties of the mapping, not the underlying concepts)

      3. Add new parameters to $translate for properties in and out and clarify the other parameters

      4. while we're at it, adopt the disposition to FHIR-38171 for some $translate parameters too (38171 proposed the adoption of FHIR search semantics for value set operations and code system operations that deal with properties, so it's natural to apply the same considerations in ConceptMap)

      Since this very definitely has to be committed to the spec by the end of this week, it appears that this is procedurally only possible if the cochairs approve it directly, though it would be good to get wider endorsement here

      The obvious concern that this is a pretty big change to be making right now at this point in time. I think it's justified because:

      • We have in effect adopted the requirements through the task and the example
      • I did convince the committee to walk that adoption back but that was on internal consistency grounds, not an issue with the actual use case
      • The properties framework in CodeSystem is well understood and normative, so adding it to ConceptMap isn't a big leap
      • We're making other breaking changes to ConceptMap now anyway, so this is the time to do it
      • it's evident that calling what we have now 'property' is confusing for people, and has caused confusion in the resolution of the task, and we really don't want to fix it later

      Attachments

        1. screenshot-1.png
          screenshot-1.png
          416 kB
        2. screenshot-2.png
          screenshot-2.png
          603 kB

        Activity

          People

            GrahameGrieve Grahame Grieve
            GrahameGrieve Grahame Grieve
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: