Stream: implementers
Topic: Search parameter combination logic
Cooper Thompson (Apr 02 2021 at 14:18):
I've been making the assumption that there was some guidance in the FHIR Spec (or a referenced RFC), that multiple search parameters should be applied using AND logic. I know we have some intentional leeway for servers to return relevant resources, but I expected the default behavior would be to apply multiple criteria using AND. However, reviewing the REST API and Search Handling, the only guidance is:
The server determines which of the set of resources it serves meet the specific criteria... from the Search Introduction
I expect most clients are assuming AND logic, and maybe that is just a broad assumption we didn't feel needed to be specified, but is there actually anything in any spec (FHIR or referenced RFC) that actually names that behavior? I couldn't find any.
Michele Mottini (Apr 02 2021 at 14:57):
', the result of the search operation is the intersection of the resources that match the criteria specified by each individual search parameter. If a parameter repeats, such as /Patient?language=FR&language=NL, then this matches a patient who speaks both languages. This is known as an AND search parameter, since the server is expected to respond only with results which match both value'
Michele Mottini (Apr 02 2021 at 14:57):
https://build.fhir.org/branches/R4B/search.html#combining
Cooper Thompson (Apr 02 2021 at 15:02):
Meh. Sorry for asking you to read the spec for me. I was skimming that section but saw the "$" reference right away and was like "that's not what I was looking for". It is a little weird that we introduce the "$", then spend a few paragraphs on & and , and then get back to $, but ultimately I should have just read it in detail.
Michele Mottini (Apr 02 2021 at 16:23):
No problem. I had that same issue before myself
Lloyd McKenzie (Apr 05 2021 at 16:01):
If you think the current language is confusing, feel free to submit a change request for us to improve it :)
Last updated: Apr 12 2022 at 19:14 UTC
