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

Allow the fhirQueryPattern extension to be a superset of the data requirement

    XMLWordPrintableJSON

Details

    • Change Request
    • Resolution: Persuasive
    • Medium
    • US Quality Measures (FHIR)
    • current
    • Clinical Quality Information
    • CQFM FHIR Query Pattern
    • Hide

      Change the description of the extension to:

      A FHIR Query URL pattern that corresponds to at least the data specified by the data requirement. If multiple FHIR Query URLs are present, they each contribute to the data specified by the data requirement (i.e. the union of the results of the FHIR Queries represents at least the complete data for the data requirement). In other words, the FHIR Query (or queries, taken together) MAY omit filters that are specified in the data requirement, such that the query would be expected to return more data than required, but it (or they, taken together) SHALL NOT return less data.

      This is not a resolveable URL, in that it will contain 1) No base canonical (i.e. it’s a relative query), and 2) Parameters using tokens that are delimited using double-braces and the context parameters are dependent solely on the subjectType, according to the following: Patient: context.patientId, Practitioner: context.practitionerId, Organization: context.organizationId, Location: context.locationId, Device: context.deviceId.

       

       

      Show
      Change the description of the extension to: A FHIR Query URL pattern that corresponds to at least the data specified by the data requirement. If multiple FHIR Query URLs are present, they each contribute to the data specified by the data requirement (i.e. the union of the results of the FHIR Queries represents at least the complete data for the data requirement). In other words, the FHIR Query (or queries, taken together) MAY omit filters that are specified in the data requirement, such that the query would be expected to return more data than required, but it (or they, taken together) SHALL NOT return less data. This is not a resolveable URL, in that it will contain 1) No base canonical (i.e. it’s a relative query), and 2) Parameters using tokens that are delimited using double-braces and the context parameters are dependent solely on the subjectType, according to the following: Patient: context.patientId, Practitioner: context.practitionerId, Organization: context.organizationId, Location: context.locationId, Device: context.deviceId.    
    • Linda Michaelsen/ Bryn Rhodes: 16-0-0
    • Enhancement
    • Compatible, substantive

    Description

      When generating fhirQueryPatterns for DataRequirements that include valueset-based terminology restrictions, the current processing uses an `:in` modifier to reference the value set. However, many FHIR servers do not support this modifier, and so the value sets must be expanded in-line in the query to be evaluated. Obviously this does not scale and so an option is to add a configuration to the implementation to specify a maximum "chunk" size (i.e. the number of fhirQueryPattern extensions to generate for a given terminology expansion), and to say that when the threshold is exceeded, the terminology requirement is excluded from the resulting queryPatterns. In this case, however, the fhirQueryPatterns taken together would represent a superset of the data requirement, which is inconsistent with the current language, which indicates that the fhirQueryPatterns "correspond" with the data requirement. Relax this language to allow the fhirQueryPatterns to represent a "superset" of the data requirement, but still cannot be a "subset".

      Attachments

        Issue Links

          Activity

            People

              bryn.rhodes Bryn Rhodes
              bryn.rhodes Bryn Rhodes
              Bryn Rhodes
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: