Stream: implementers
Topic: search: on-the-fly composites?
Josh Mandel (Aug 02 2017 at 20:35):
Monday in the FHIR Infrastructure WG we discussed GF#13324, where @Chris Grenz asked about a more expressive way to find resources based on inbound connections. (Specifically he wanted a way to say: find me all Patients pointed to by a Provenance that meets conditions A and B. Today's API lets you say: find me all Patients pointed to by a Provenance that meets condition A and a Provenance that meets condition B — but there's no way to restrict the search to cases where a single Provenance meets both conditions.)
Josh Mandel (Aug 02 2017 at 20:37):
It seems to me like this issue isn't restricted to inbound references (with _has search parameters). Rather, the same issue arises for outbound connections. Like I can say Patient?generalPractitioner.given=John&generalPractitioner.family=Smith — but this query also finds patients with two provides, named "John Adams" and "Alice Smith".
Josh Mandel (Aug 02 2017 at 20:39):
In fact, it can even apply to queries within a given resource, on repeated fields. Like the following erroneous way to find patients with diastolic hypertension (diastolic BP > 100): Observation?component-name=diastolic&component-value=gt100
the problem is that this query will match observations with a normal BP (of 120/80), because it contains some diastolic value, and some value over 100 mmHg.
Josh Mandel (Aug 02 2017 at 20:40):
For the final case (within-resource queries) FHIR has "composite" search parameters — a way to ask for component-value-quantity=diastolic$gt100.
Josh Mandel (Aug 02 2017 at 20:41):
The question is: should we try to introduce some on-the-fly way to perform similar constraints-on-subtrees for queries that cross resource boundaries?
Josh Mandel (Aug 02 2017 at 20:41):
I'm inclined to say "No", on the principle that FHIR's search interface was never designed to handle full-on graph search. But we've historically had difficulty explaining exactly how to draw this line.
Chris Grenz (Aug 02 2017 at 20:42):
Agree it's a generalizable problem.
Grahame Grieve (Aug 02 2017 at 20:59):
the _filter parameter can do all this stuff.
Grahame Grieve (Aug 02 2017 at 21:00):
it intrigues me that there's such resistance to it....
Josh Mandel (Aug 02 2017 at 23:56):
It's likely lack of understanding. Can you share some examples of how to solve this with filter?
Grahame Grieve (Aug 03 2017 at 00:04):
_filter=related[type eq has-component and target.code eq 2345-6].target re url
Josh Mandel (Aug 03 2017 at 21:13):
Can you maybe write out the "Patient with a provider with first name John and last name Smith" example @Grahame Grieve? I'm still having trouble following.
Grahame Grieve (Aug 03 2017 at 21:42):
GET [base]/Patient?_filter=general-practitioner[given eq John and family eq Smith].id pr true
Grahame Grieve (Aug 03 2017 at 21:42):
i think.
Last updated: Apr 12 2022 at 19:14 UTC
