Stream: implementers
Topic: advanced search for all resources related to XX
Sean McIlvenna (Jan 04 2020 at 03:17):
Is it possible (or is something in the works) to do a search for anything that references a specific resource? I've taken a look at a global _search, but that would require me listing out all search parameters of type Reference in the query. I've also looked at GraphDefinition... not even sure how a server would search based on a GraphDefinition. Just wondering what direction I should start heading down, if any is even possible.
Lloyd McKenzie (Jan 04 2020 at 03:21):
It would mean the server would need to be able to index any arbitrary reference in any extension wherever it appeared. And even that would only get references on that specific server. I don't believe there are any current plans to define something like this...
Eric Haas (Jan 04 2020 at 04:12):
Revinclude * ?
Lloyd McKenzie (Jan 04 2020 at 15:26):
We can come up with a syntax. The question is whether it's reasonable for implementers to index that way.
Eric Haas (Jan 04 2020 at 23:48):
Whether reasonable or not the logical search syntax would be:
GET [base]/Observation?_id=xyz&_revinclude=*:*
Eric Haas (Jan 04 2020 at 23:49):
which is not currently defined
Paul Church (Jan 04 2020 at 23:58):
I'm inclined towards an extended operation on Resource, perhaps $references-to. It would be like a search in that it would return a searchset and support pagination.
The major reason why I don't like revinclude for this is that a * in revinclude conceptually means "all search parameters" -- but not all references are necessarily the subject of a search parameter. As an implementer I don't expect to be using the search index internally for this operation.
John Moehrke (Jan 05 2020 at 20:08):
How is $everything not sufficient? https://www.hl7.org/fhir/operation-patient-everything.html
Lloyd McKenzie (Jan 05 2020 at 20:12):
That gives you all data for a patient, not all references to a single resource. Everything would provide orders of magnitude of unwanted data. As well, it's possible that some referencing resources might not be part of the patient component. In fact, the base resource might not be in the patient compartment either.
John Moehrke (Jan 05 2020 at 22:04):
so the desire is all resources that have a pointer to XYZ resource? That is _revinclude. Or is there a desire for both pointing TO and FROM?
Lloyd McKenzie (Jan 05 2020 at 22:27):
_revinclude requires enumerating the specific relationship. It doesn't (currently) allow returning resources regardless of the nature of the relationship.
John Moehrke (Jan 05 2020 at 22:36):
yeah, that sounds like better handled by an operation specifically designed for that high resource need.
Lloyd McKenzie (Jan 05 2020 at 23:13):
No reason for it to be resource-specific. Key thing is it means indexing arbitrary extensions
xiao dingding (Jan 06 2020 at 08:41):
I am sorry. Can someone teach me how to use _revinclude? I mean I want to search observations from a diagnosticReport resource which id is 62714. And I use "http://xxx/hapi-fhir-sample/baseDstu3/Observation?_revinclude=DiagnosticReport:result:specialty=62714&_pretty=true". But it doesn't work.
René Spronk (Jan 06 2020 at 09:59):
'specialty' is not a search paremeter for DiagnosticReport. You probably want category, see bottom of the page http://build.fhir.org/diagnosticreport.html
René Spronk (Jan 06 2020 at 11:45):
(remember to always check the 'self' link in the response bundle to see which parameters the server has actually used/applied - if different from the ones supplied by you as the client this is a clear indication you used some non-existing/non-supported query parameter)
Last updated: Apr 12 2022 at 19:14 UTC
