Hi,
I’m trying to understand this part of the spec Search - FHIR v4.0.1
From this:
Note that chained parameters are applied independently to the target resource. For example,
GET Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN
may return Patients cared for by Joe from CA and Jane from MN: no one practitioner need satisfy both conditions. E.g. the chains are evaluated separately.
My interpretation is the search parameters end up in an OR condition: name = Joe OR state = MN
Now on the Reverse Chaining (Search - FHIR v4.0.1) when there are multiple _has parameters, my interpretation is that also is considered an OR, based on:
“Or” searches are allowed (e.g. GET [base]/Patient?_has:Observation:patient:code=123,456), and multiple _has parameters are allowed (e.g. GET [base]/Patient?_has:Observation:patient:code=123&_has:Observation:patient:code=456).
Note that each _has parameter is processed independently of other _has parameters.
Consider this search URL:
[base]/Patient?_has:Encounter:patient:date=2020&_has:Condition:patient:code=C34.0,C34.1,C34.2,C34.3,C34.8,C34.9&_has:Observation:patient:code=2160-0,14682-9,3091-6,22664-7&_has:Observation:patient:code=1743-4,1742-6,30239-8,1920-8,88112-8
Should that be interpreted with an OR like: Condition.code=C43.0… OR Observation.code=2160-0… OR Observation.code=1743-4… ?
My interpretation from the specification is that the OR is the right way of processing these kinds of parameters, but a colleague did a test on the HAPI FHIR test server online and got that the logic was really an AND, because with the _summary=count he got less results when adding another condition to the search (first tested with one condition then added another one).
I can’t provide the example right now because the HAPI FHIR server is offline at the moment. I’ll try later.