Closed michaelwschroeder closed 2 years ago
When we do this one, we should deprecate the fhirServer/search/useStoredCompartmentParam
variable and simply always use the internal search param
Investigation: what is the current behavior?
Now that we have useStoredCompartmentParam
, does compartment search work or not when the inclusion criteria parameters are filtered out?
I confirmed that we do not extract the ibm-internal-Patient-compartment parameter if the corresponding patient
search parameter is not enabled.
Verified issue with 2 different compartments. closing issue
Is your feature request related to a problem? Please describe. If compartment inclusion criteria search parameters are not specified in the
fhirServer/resources/<resourceType>/searchParameters
list for a given resource type, then the new generated compartment search token (if thefhirServer/search/useStoredCompartmentParam
value is set to true - see issue #1708) or the tokens for the inclusion criteria search parameters, are not created/stored at resource create/update time, and thus that resource will not get returned on a compartment search as it should.Example:
fhir-server-config.json only specifies _id and _lastUpdated as valid search parameters for the Procedure resource type, not the patient and performer inclusion criteria search parameters:
A Procedure resource is created which contains the following Patient reference, meaning it should be associated with that Patient compartment:
However, the Patient compartment inclusion criteria search parameters for the Procedure resource type,
patient
andperformer
, are not in thefhirServer/resources/<resourceType>/searchParameters
list, so are not considered valid search parameters. This means the generated compartment search token (if enabled) or the inclusion criteria search tokens will not be created and indexed when the Procedure resource is stored.The following compartment search is performed:
The Procedure created in step 2 will not be returned in the search results because the necessary compartment search token(s), which are what's used in the compartment search SQL, were not created and indexed.
Describe the solution you'd like When extracting compartment inclusion criteria search parameters for a resource when persisting the resource, we should assume the search parameters are valid rather than checking them against the configured search parameters for the tenant, which might not have included the compartment inclusion criteria search parameters. Then when validating search parameters on a compartment search request, again, we should not validate the compartment inclusion criteria search parameters against the configured search parameters for the tenant, but instead assume they are valid.
Describe alternatives you've considered See issue #1707 for alternatives considered.
Acceptance Criteria At least one acceptance criteria is included.
GIVEN the compartment inclusion criteria search parameters for a resource type are not configured as valid search parameters WHEN a compartment search against the resource type is executed THEN all valid resources are returned
GIVEN the compartment inclusion criteria search parameters for a resource type are not configured as valid search parameters WHEN a standard search against the resource type is executed which contains one of the inclusion criteria search parameters THEN an error will be returned indicating the search parameter is not valid for the given resource type
Additional context Add any other context or screenshots about the feature request here.