Problem with automatic code generation from search params - 2016-09 core #169

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU2
    • FHIR Infrastructure
    • Observation
    • 10.1.5
    • Hide

      Change the way SearchParameter is defined so component.expression overrides the path defined in the component search parameters thus allowing you to specify exactly how data is extracted from pairs of elements in the instance.

      See for example searchparameters.xml -> "fullUrl": "http://hl7.org/fhir/SearchParameter/Observation-code-value-quantity"

      PROPOSED RESOLUTION (needs input – assigned issue to Grahame Grieve for review)

      We agree that search parameters should be computable – even Composite paramters. Two fixes are needed to address this issue:

      1. The "code-value-[x]" search parameter on Observation should be broken up into four separate paramaters (just like the "value-[x]" search parameter was broken up; they appear to have gotten out of sync).

      2. Doing #1 still leaves a problem for search parameters like "code" that reference >1 path within a resource (Observation.code, Observation.component.code). Specifically, an implementaiton doesn't know which paths are "fair game" to combine for composite indexing. To address this issue, we propose changing http://hl7-fhir.github.io/searchparameter-definitions.html#SearchParameter.component to reflect how the grouping should occur. This would look like:

      "component": [

      {"expresssion" :[\\ "Observation.code"\\ "Observation.valueQuantity"\\ ]}

      ,

      {"expression": [\\ "Observation.code"\\ "Observation.valueQuantity"\\ ]}

      ]

      instead of the current data, which shows only:

      "component": [

      { "reference": "[http://hl7.org/fhir/SearchParameter/Observation-code]" }

      ,

      { "reference": "[http://hl7.org/fhir/SearchParameter/Observation-value[x]|http://hl7.org/fhir/SearchParameter/Observation-value%5Bx%5D]" }

      ]

      3. For UI purposes, it would be good to populate the "paths" column for all search parameters, including composites.

      Show
      Change the way SearchParameter is defined so component.expression overrides the path defined in the component search parameters thus allowing you to specify exactly how data is extracted from pairs of elements in the instance. See for example searchparameters.xml -> "fullUrl": " http://hl7.org/fhir/SearchParameter/Observation-code-value-quantity " PROPOSED RESOLUTION (needs input – assigned issue to Grahame Grieve for review) We agree that search parameters should be computable – even Composite paramters. Two fixes are needed to address this issue: 1. The "code-value- [x] " search parameter on Observation should be broken up into four separate paramaters (just like the "value- [x] " search parameter was broken up; they appear to have gotten out of sync). 2. Doing #1 still leaves a problem for search parameters like "code" that reference >1 path within a resource (Observation.code, Observation.component.code). Specifically, an implementaiton doesn't know which paths are "fair game" to combine for composite indexing. To address this issue, we propose changing http://hl7-fhir.github.io/searchparameter-definitions.html#SearchParameter.component to reflect how the grouping should occur. This would look like: "component": [ {"expresssion" :[\\ "Observation.code"\\ "Observation.valueQuantity"\\ ]} , {"expression": [\\ "Observation.code"\\ "Observation.valueQuantity"\\ ]} ] instead of the current data, which shows only: "component": [ { "reference": "[http://hl7.org/fhir/SearchParameter/Observation-code]" } , { "reference": "[http://hl7.org/fhir/SearchParameter/Observation-value[x]|http://hl7.org/fhir/SearchParameter/Observation-value%5Bx%5D]" } ] 3. For UI purposes, it would be good to populate the "paths" column for all search parameters, including composites.
    • Grahame Grieve/Kevin Shekleton: 27-0-0
    • Enhancement
    • Non-compatible
    • Yes
    • DSTU2

      Comment:

      The code-value-[x] composite search parameter references other parameters that each have multiple paths. Although common sense would indicate that the "Observation.code" should only be paired with "Observation.value-[x]" (and not "Observation.component.value-[x]"), the specification itself does not indicate this in a deterministic way that could be understood by a spec parser.

      Given this ambiguity (that requires a human in the loop and impedes automatic code generation), either the spec should further define this, or there should be separate composite search parameters – one for Observation and one for its components (e.g., "component-code-value-[x]").

      Summary:

      Problem with automatic code generation from search params

            Assignee:
            Unassigned
            Reporter:
            cmoesel
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: