Stream: cds hooks
Topic: prefetch list of resources
Vadim Peretokin (Jun 02 2017 at 09:45):
Spec for prefetch says: each value is a FHIR Bundle.entry indicating a response status and returned resource
A Bundle.entry is 0..*, so it's an array in FHIR, but in the spec text and example, it seems to be using Bundle.entry[1] directly
Vadim Peretokin (Jun 02 2017 at 09:47):
There's just one example where the EHR would need to send a list, "medications": "MedicationOrder?patient={{Patient.id}}", but the spec doesn't have an example for that.
I'll go with treating the prefetch objects value as an array of objects as using Bundle.entry would prescribe - but it would mean that it doesn't align with the text following it indicating a response status and a returned resource nor the provided examples
Vadim Peretokin (Jun 02 2017 at 09:48):
Can anyone confirm/deny the problem?
Dave Carlson (Jun 02 2017 at 15:10):
@Vadim Peretokin I just opened Zulip to ask exactly the same question. Looking at @Brett Esler redbook service definition that includes a prefetch -- "conditions": "Condition?patient={{Patient.id}}&_count=1000". This would return a bundle with multiple entries, each containing one resource. Seems like the spec should require any array for prefetch objects (entries).
Brett Esler (Jun 02 2017 at 15:54):
I read this more 'like a FHIR Bundle.entry' and I expected the prefetch items that return multiple items to have 'resource' set to a Bundle (which is the resource returned by the prefetch statement)
Dave Carlson (Jun 02 2017 at 16:09):
Brett, with that interpretation, it would be most consistent for any prefetch based on a query to expect a Bundle resource. So, in your Redbook services, all prefetch other than "patient". Many of your prefetch queries include &_count=1. When invoking, how would I know whether your service is expecting a single resource or a Bundle, unless I parsed the query looking for _count=1 ?
Brett Esler (Jun 02 2017 at 16:39):
The prefetch would return a resource or a bundle as per FHIR API call so {emrbase}/Patient/{{Patient.id}} returns a single Patient resource with the id provided (FHIR read); something like "{emrbase}/Condition?patient={{Patient.id}}&_count=1000" or "{emrbase}/Observation?patient={{Patient.id}}&code=55284-4&_count=1&_sort:desc=date” are FHIR searches so return a Bundle (even though there is only ever one result in the 2nd one; still a Bundle)
Brett Esler (Jun 02 2017 at 16:47):
so just making the call on the EMR as stated in the pre-fetch; it might be good to say something about paging as expect the prefetch should provide all the pages available from the EMR - although can't see how to supply this for a CDS call as there would be multiple Bundles (pages); this kind of goes back to your original point...
Dave Carlson (Jun 02 2017 at 17:05):
Thanks Brett. So, as I continue to build a test using your hooks service, you expect all prefetch values other than "patient" to send a Bundle in the request?
Brett Esler (Jun 03 2017 at 00:54):
I am just reading it as supply the response from the stated prefetch statement with the base url of the EMR - so the response will be a bundle for FHIR API search or a specific resource when a FHIR API read (based on the prefetch statement) - the only way I can see there being a single resource (other than Bundle) is if one of the context variables is supplied like {{Patient.id}} - i.e. retrieve a specific resource like {emrBase}/{resourceType}/{{contextId}}
Brett Esler (Jun 03 2017 at 00:54):
so for redbook service you are right - Patient resource (read) and the rest are Bundles (search)
Last updated: Apr 12 2022 at 19:14 UTC
