Stream: implementers
Topic: Bundle search request
Madeline Hoskins (Aug 19 2019 at 18:51):
Hi All,
I am working on some queries from an EMR. Can you please advise if the below syntax would be valid for the following scenario: Return the identifier and specialty of a PractitionerRole and include the practitioner and location resource.
"request": {
"method": "GET",
"url": "/PractitionerRole/_include:practitioner,location&_elements:identifier,specialty"
}
Michele Mottini (Aug 19 2019 at 19:48):
something like: .../PractitionerRole?_include=PractitionerRole:practitioner&_include=PractitionerRole:location - I would not bother with _elements, it is not widely implemented and it is just an optimization, you are going to get all elements (including those) if you do not specify it
Madeline Hoskins (Aug 19 2019 at 19:52):
Thanks Michele.
Also, for a Bundle with multiple entries or requests, how can I make sure the requests are made in the right order? Is this possible?
Michele Mottini (Aug 19 2019 at 20:15):
Not sure - what is the right order?
I'd suggest not to use a request bundle - it is another feature that is not widely implemented. Issue separate requests
Madeline Hoskins (Aug 20 2019 at 17:23):
For example: I want to make sure that the first query is run before the last two.
The first query finds the ServiceRequest for when the patientId = 123 and the response should include the Patient that represents the subject, PractitionerRole that represents the requester, PractitionerRole that represents the performer.
The second query wants to include the resource referenced from the PractitionerRole.location field for the "requester" resource- so i need to be sure that the first query is run before jumping into the respective PractitionerRole resource that represents the requester.
{
"resourceType": "Bundle",
"id": "bundle-request",
"type": "batch",
"entry": [{
"request": {
"method": "GET",
"url": "/ServiceRequest?Patient=123&_include:ServiceRequest:subject,&_include:ServiceRequest:requester,&_include:ServiceRequest:performer"
}
},
{
"request": {
"method": "GET",
"url": "/PractitionerRole?_include:PractitionerRole:location"
}
},
{
"request": {
"method": "GET",
"url": "/PractitionerRole?_include:PractitionerRole:practitioner,&_include:PractitionerRole:location"
}
}
]
}
Michele Mottini (Aug 20 2019 at 17:27):
A query like /PractitionerRole?_include=PractitionerRole:location returns ALL PractitionerRole resources. If you want to limit that to the PratictionerRoles returned by the first search you cannot use a bundle - you have to issue the first search request, extract the PractitionerRole ids and use those to do another search (or - better - directly extracts the Location ids and get those)
Madeline Hoskins (Aug 20 2019 at 17:33):
Okay that makes sense. So i need multiple Bundles of requests? How would i a send a single request?
Lloyd McKenzie (Aug 20 2019 at 21:37):
You could say SeviceRequest?patient=123&_include=ServiceRequest:subject&_include=ServiceRequest:requester&_include=ServiceRequest:performer&_include:iterate=Practitioner:location
However, that would give you the location of both requester and performer. The only mechanism to get only the requester locations is to execute two independent requests. There's no way to send a batch or transaction in which the parameters of one query are dependent on the results of a preceding query
Jay Lyle (Mar 02 2020 at 14:58):
Michele Mottini said:
something like:
.../PractitionerRole?_include=PractitionerRole:practitioner&_include=PractitionerRole:location- I would not bother with_elements, it is not widely implemented and it is just an optimization, you are going to get all elements (including those) if you do not specify it
We have one context in which medication orders link to patients, so the order screen and patient screen can be easily aligned with their resources using References. We have another context in which the order view contains a small number of identifying patient attributes (e.g., date of birth, ID).
I was thinking of mixing _include & _elements:
GET [base]/MedicationOrder?status="Active"&_include=MedicationOrder:patient?_elements=birthDate,identifier?type="SSN"
Your comment suggests this may not be worthwhile, but if we're getting all the pharmacy orders for a location, all those patient records are going to be heavy. Is this still your impression?
Michele Mottini (Mar 02 2020 at 20:23):
That request gets all MedicationOrder with all their associated patient - yes, it is going to be heavy - and most actual server will reject it as too broad. Adding _elements would help reducing the amount of data to be returned, not much in term of the amount of data to find / extract, and again: most server do not implement _elements
Michele Mottini (Mar 02 2020 at 20:24):
Also: . . . .identifier?type=ssn means search MedicationOrder by type, not return only the SSN identifiers, is that what you meant?
Jay Lyle (Mar 03 2020 at 00:15):
Yes. This is for a pharmacy application, so the pharmacist can review the workload and select tasks. It should be restricted to specific clinics, which we might do with an operation, a compartment extension, or maybe just with custom code.
Last updated: Apr 12 2022 at 19:14 UTC
