Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add capability to configure compartment search via searchParameterCombinations config property #1778

Open
michaelwschroeder opened this issue Dec 2, 2020 · 1 comment
Labels
P3 Priority 3 - Nice To Have search

Comments

@michaelwschroeder
Copy link
Contributor

Is your feature request related to a problem? Please describe.
If a compartment inclusion criteria search parameter is specified in the fhirServer/resources/<resourceType>/searchParameterCombinations list to limit search scope (i.e. patient or performer), then that parameter must be specified on a compartment search even though the compartment search already scopes the query to that search parameter. In addition, the search parameter will be specified twice in the generated SQL.

Example:

  1. fhir-server-config.json specifies the patient search parameter in its fhirServer/resources/<resourceType>/searchParameterCombinations list for the Procedure resource type:

        "resources": {
          "Procedure": {
            "searchParameterCombinations": ["patient","patient+date","patient+status","patient+code"]
          }
        },
    
  2. The following compartment search is performed:

        Patient/17575/Procedure
    

    It will fail because the patient search parameter was not specified, even though the compartment search already scopes the search to a single Patient.

  3. The following compartment search is performed:

        Patient/17575/Procedure?patient=Patient/17575
    

    It will correctly return the Patient's Procedure resources, but the patient search parameter has to be unnecessarily specified, and the generated SQL will contain functionally duplicate WHERE clauses to scope the results to a single Patient.

Describe the solution you'd like
Provide a way for the user to configure valid search parameter combinations for compartment searches in the fhirServer/resources/<resourceType>/searchParameterCombinations config property using a custom format. One suggested format is the following:

    <compartmentType>/<searchParameter1>+<searchParameter2>+...

For example, if a user wanted to allow Procedure searches on the Patient compartment where the code and status search parameters were valid for the Procedure search, they could specify the following in the fhir-server-config.json file:

        "resources": {
          "Procedure": {
            "searchParameterCombinations": ["Patient/code+status"]
          }
        },

This would allow the following search request:

    Patient/12345/Procedure?code=1028-5&status=completed

Describe alternatives you've considered
See issue #1707 for possible alternatives considered.

Acceptance Criteria
At least one acceptance criteria is included.

GIVEN a compartment search parameter combination is configured for a particular compartment
WHEN a compartment search is executed with that parameter combination
THEN all valid resources are returned
2.
GIVEN no compartment search parameter combination is configured for a particular compartment
WHEN a compartment search is executed for that compartment
THEN the search request fails
3.
GIVEN a compartment search parameter combination is configured for a particular compartment
WHEN a compartment search is executed for that compartment, but with the wrong parameter combination
THEN the search request fails

Additional context
Add any other context or screenshots about the feature request here.

@lmsurpre lmsurpre added the cms-interop This issue is associated with the CMS interoperability rule label Dec 8, 2020
@lmsurpre lmsurpre modified the milestones: Sprint 2021-1, Sprint 22 Dec 8, 2020
@lmsurpre
Copy link
Member

lmsurpre commented Dec 8, 2020

stretch goal for sprint 22

@lmsurpre lmsurpre removed this from the Sprint 22 milestone Jan 6, 2021
@lmsurpre lmsurpre removed the cms-interop This issue is associated with the CMS interoperability rule label Jan 6, 2021
@lmsurpre lmsurpre added the P3 Priority 3 - Nice To Have label Aug 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Priority 3 - Nice To Have search
Projects
None yet
Development

No branches or pull requests

2 participants