FHIR Chat · search: multiple _has params · implementers

Stream: implementers

Topic: search: multiple _has params


view this post on Zulip Michael Calderero (Apr 06 2018 at 21:05):

http://build.fhir.org/search.html#has says that when there are multiple _has parameters, they are processed independently of other _has parameters. So if I have a model like below:

pat1 <- obs1 (category: abc, code=xyz)
pat2 <- obs2 (category: hhh, code=yyy)

and I do a search like Patient?_has:Observation:subject:category=abc&_has:Observation:subject:code=yyy I should get both pat1 and pat2?

view this post on Zulip Michael Calderero (Apr 06 2018 at 21:09):

If that's the case, then the reference servers I tested do not behave that way. tx.fhir.org/r4 gives me an error right now but HAPI and Vonk both give me zero results instead of 2.

Attached is a transaction bundle for a test case that I ran against Vonk. The last entry in the bundle contains the multiple _has parameters.multiple_has_testcase_tx_bundle.xml

view this post on Zulip Michael Calderero (Apr 06 2018 at 21:15):

Sorry ignore the previous attachment because it had an error. Use this instead: multiple_has_testcase_tx_bundle.xml

view this post on Zulip Lilian Minne (Apr 09 2018 at 12:34):

Hi Michael,

The expected result of your query is that it returns patients that have both an observation with category=abc AND an observation with category=yyy. Which is indeed the case for zero patients in your example. However, if you would add a third observation to patient 2:

pat2 <- obs3 (category:abc, code=xyz)

then your query would return pat2.

The meaning of processing the _has parameters independently is that they do not refer to the same Observation. So if you change the query to: Patient?_has:Observation:subject:category=abc&_has:Observation:subject:code=xyz this would still not return pat1.

I hope this explanation helps!

Lilian

view this post on Zulip Michael Calderero (Apr 09 2018 at 13:58):

Hello Lilian - thanks for the explanation.

My confusion stems from the fact that http://build.fhir.org/search.html#has mentions that "each _has parameter is processed independently of other _has parameters" but doesn't give an example. So I looked through the rest of the spec and found http://build.fhir.org/search.html#chaining, which gives this example:

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. For use cases where the joins must be evaluated in groups, there are either Composite search parameters, or the _filter parameter.

So I inferred that the behavior of 'multiple _has parameter' is the same as the excerpt above, except that it is in reverse. And, my original understanding of the excerpt's example above is:

Example data:
pat1 -> prac1 (name: Joe, address-state: CA)
pat2 -> prac2 (name: Jane, address-state: MN)
pat3 -> prac1 and prac2

My original understanding was the search 'Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN' would return all three (i.e. because of 'may return Patients' phrase). But from your explanation it sounds like it should only return pat3. Is that right?

view this post on Zulip Lilian Minne (Apr 09 2018 at 14:27):

Hi Michael, that's correct. I understand the confusion though :)
@Ewout Kramer is this something to add in the explanation in the specs?

view this post on Zulip Ewout Kramer (Apr 13 2018 at 14:53):

Hi Michael, that's correct. I understand the confusion though :)
@Ewout Kramer is this something to add in the explanation in the specs?

Yes, so the "independently" does not mean OR, indeed. It's worth creating a gForge ticket item for, so we can discuss it more widely.

view this post on Zulip Michael Calderero (Apr 13 2018 at 15:49):

Ok thanks. I will get around to creating the ticket sometime today (if no one else has done it).


Last updated: Apr 12 2022 at 19:14 UTC