Stream: implementers
Topic: Search syntax
Anand Jahagirdar (Nov 12 2020 at 11:30):
Hi All,
I am trying to get syntax for Search API which does following:
- Select a patient and include additional resources ProcedureRequest and Encounter.
- Procedure request with specific code
- encounters linked to above selected procedure request
is it possible to do it in one single request?
I was thinking of following;
https://<fhirserver/Patient?
rev_include=ProcedureRequest:code=123 &
rev_include=Encounter[ How to select encounter linked to above procedure request ?]
thanks.
Marc Sandberg (Nov 12 2020 at 12:26):
Probably best to go in from the ProcedureRequest, I don't have an example set up, so I'm doing this blind:
[base]/ProcedureRequest?code=123&subject.identifier=923842&include=ProcedureRequest:subject&include=ProcedureRequest:context
I don't know if the Patient could really be you're in, if you want the parameter for code to be included.
Josh Mandel (Nov 12 2020 at 14:38):
Depending on what server you're connecting to, you may find it's better to stick with a couple of simpler calls rather than trying to do everything in a single query. Keep in mind that not all fhir servers support the full breadth of the search syntax. "generic" (aka "native").
Josh Mandel (Nov 12 2020 at 14:40):
That said, more technically: FHIR reverse inclusion can't be combined with chaining to only include a limited set of incoming references.
Josh Mandel (Nov 12 2020 at 14:42):
But in your particular example you can actually do something simpler: you can formulate three independent queries that fetch the data you need -- and on servers that support batch operations, you can submit a single batch query including all three requests, so you will get back a batch response including all three results. (You can do this because you already know the patient id up front, so you can write one query for that patient, one query for a limited set of encounters pointing that patient, and a third query for a limited set of procedure requests pointing to that patient.)
Marc Sandberg (Nov 12 2020 at 15:09):
Josh Mandel said:
and on servers that support batch operations, you can submit a single batch query including all three requests, so you will get back a batch response including all three results.
Funny you should say this, I was talking to someone about this just a few weeks ago, and he was adamant this was not the way to use the batch.
Gino Canessa (Nov 12 2020 at 16:29):
re: batch, I believe the documentation on the http page is pretty good about the rules - as long as you don't need to use the results of any of the queries to process the others, this would work well. If you needed to search for the patient id first, you could not use a batch because the later steps would depend on the results of the first query.
Josh Mandel (Nov 13 2020 at 22:09):
For folks interested in the details: I used this question as a jumping off point for this week's "Guided Walk Through FHIR" episode (see https://youtu.be/W8F4cGmseo0).
FYI @Anand Jahagirdar
Anand Jahagirdar (Nov 14 2020 at 12:57):
Thanks @Josh Mandel
René Spronk (Nov 16 2020 at 11:19):
Hmm - _revinclude=Procedure:patient:code=456 would have worked as well, one can specify a condition on a _revinclude
Josh Mandel (Nov 16 2020 at 14:34):
I've missed this -- your example of has two clauses separated by equals signs and no ampersands in between? Can you point me to the specs so I can review?
René Spronk (Nov 16 2020 at 15:09):
My error - I was confusing _revinclude with _has, which does allow additional conditional expressions expressed as modifiers. _revinclude doesn't.
René Spronk (Nov 16 2020 at 15:12):
For this kind of exercise (the one you're tackling in your video) we force the attendees of our training courses to think about what they should use a 'focal' resource, which has a large impact on the remainder of the search URL. There are many ways to arrive at the same result, even more so if one accepts that a result bundle may include resource types other than the ones one is interested in.
Last updated: Apr 12 2022 at 19:14 UTC
