Stream: implementers
Topic: transitive composite search ?
Georg Fette (Aug 10 2018 at 10:34):
Hello, I have a question concerning the search capabilities of the FHIR-REST-query: I would like to find patients having encounters containing observations with contrained values (e.g. systolic blood pressure < 60). After reading the search documentation I think that I have to use the Composite Search (http://build.fhir.org/search.html#composite) to enforce each observation to contain both constraints, the contraint on the code values as well as the contraint on the quantity. But I have the additional request that some of the observations have to belong to the same encounter and some are allowed to belong to arbitrary encounters of the patient. For that the composite search somehow would have to be transitively nestable. How would a query like that look like ?
Btw.: Is the implementers stream the correct one to discuss search issues or is there one that better matches that topic ?
Grahame Grieve (Aug 10 2018 at 11:41):
this is the right place.
Grahame Grieve (Aug 10 2018 at 11:46):
the only way I can think that you'll get something like that to work is with the _filter parameter
Georg Fette (Aug 10 2018 at 12:30):
Ah, interesting, I had not yet taken a look at the "_Filter Parameter" page. But after reading about filters I still have problems constructing my query.
I came up with something like
GET [base]/Patient?_has:Encounter:_has:Observation.component-code-value=1234-5$lt50&_has:Encounter:_has:Observation.component-code-value=1234-5$lt50
&_filter=encounter1.identifier = encounter2.identifier
My first problem is the double reverse chaining of the patient (as I am interested in the patients and not in the observations by which they are contrained by). Is double reverse chaining possible ?
My second problem is the combination with the filter. As neither in the filter specification nor in the normal query specification there exists the possibility for aliases for the objects. It is difficult to express that the encounter has to be the container of one observation and the same encounter also has to be the container of the other observation without having the binding that those two observations are the same as in the other constraints.
Is it necessary to compare the identifier of the ecnounters in a filter or can the encounter be compared itself (i.e. _filter=encounter1 = encounter2) ?
Grahame Grieve (Aug 10 2018 at 12:32):
so we've always known that the simple search, and even the _filter parameter are hardly the beginning of a real query language. And you're crossed the boundaries, I'm afraid. The only other options you have is:
- do as much of the query as you can and then plough through the return resources, or
- use CQL
Michele Mottini (Aug 10 2018 at 14:08):
Keep also in consideration that advanced search features like _filter or composite search are not widely implemented
Last updated: Apr 12 2022 at 19:14 UTC