Stream: cds hooks
Topic: Prefetch Data and subsequent invocations
Wolfgang Wiessler (Dec 07 2017 at 15:41):
Hello,
are we required to send the prefetch data with every invocation of the hook instance? So far I have interpreted it that prefetch data needs to be sent with the first invocation of a hook instance. When we invoke it again (e.g. after the CDS service/app redirects back to the EHR), are we expected to provide the prefetch data again?
Kevin Shekleton (Dec 07 2017 at 18:35):
Hi Wolfgang! Prefetch is an optional aspect of the CDS Service request and the EHR is not obligated to honor any prefetch requests. From our specification:
"An EHR may choose to honor some or all of the desired prefetch templates from an appropriate source."
"It is the CDS Service's responsibility to check to see what prefetched data was satisfied (if any) and manually retrieve any necessary data. If the CDS Service is unable to obtain required data because it cannot access the FHIR server and the request did not contain the necessary pre-fetch keys; the service shall respond with an HTTP 412 Precondition Failed status code."
Wolfgang Wiessler (Dec 08 2017 at 09:20):
Hi Kevin! That is what I thought. I am currently building our CDS framework implementation and I am testing it against the CDS Sandbox services. Those services are rejecting requests that do not have the matching prefetch. My assumption was that they are not 100% up to spec and I wanted to make sure that this is indeed the case or if services should reject requests if the expected prefetch data is not there.
Grahame Grieve (Dec 08 2017 at 11:57):
I was not aware that not caching this data was not up to spec?
Kevin Shekleton (Dec 08 2017 at 19:21):
@Wolfgang Wiessler - That is correct that those CDS Services that are bundled with our Sandbox assume the prefetched data is always present. @Zach Plata is actually re-writing those CDS Services now and as part of that work, he is changing them to gracefully handle the scenario in which case the prefetched data is not present :)
Kevin Shekleton (Dec 08 2017 at 19:22):
@Grahame Grieve - Where are you getting the caching questions from?
Grahame Grieve (Dec 08 2017 at 20:19):
just from what is above
Kevin Shekleton (Dec 09 2017 at 13:06):
I’m sorry, I’m not following. I don’t see any references to caching in this thread
Grahame Grieve (Dec 09 2017 at 21:35):
the notion above is that you should only need to send the pre-fetch data with the first invocation of a hookInstance. And any casual reader would conclude, from the thread, that if a cds service does not do this, it's not up to spec.
But the spec never says that this is an expectation, and it's a hard expectation, since there's no 'done with a hook' call for a CDS service to stop remembering the context. I think there should be more clarity around this
Wolfgang Wiessler (Dec 12 2017 at 11:24):
To summarize:
- The prefetch queries are not mandatory. A CDS Service can ask for that data upon invocation, but it is not guaranteed that the data will be there
- The EHR decides whether to fulfill the prefetch requests (in full or partially)
- The CDS Service is expected to gracefully deal with missing data: 1. Try querying the data via the FHIR API (if available); 2. If the CDS Service cannot get the data, return a proper response (e.g. empty cards array or an info card)
In our case the CDS Service would just return an App Link Card and the app will not have any data pre-filled.
I suppose the "caching" aspect could come in when we only send the prefetch on the first invocation. Then the CDS Service needs to cache that data if it needs it in subsequent requests or it needs to query it again.
To me, sending prefetch (only) makes sense on the first invocation, since this is where you are setting the context of the interaction and kick-start the service. Most subsequent calls are for getting the status/results from the CDS Service after user interaction.
David Hay (Jan 17 2018 at 23:42):
Is there any way that a client can find out in advance what FHIR queries a service is likely to make of it? the 'definition' returned by the discovery has a prefetch, but that is not necessarily all the data that a service might want from the client (is it?). It would be nice to look at the definition to understand what data it is expecting to get from the client...
Kevin Shekleton (Jan 18 2018 at 17:39):
We don't have this in CDS Hooks today, no.
Kevin Shekleton (Jan 18 2018 at 17:39):
This question has come up before and you could take this same question and ask it regarding SMART apps, too.
Brett Esler (Jan 18 2018 at 22:55):
perhaps a statement of SMART on FHIR scopes that may be needed and list of profile URIs the CDS relies on?
Last updated: Apr 12 2022 at 19:14 UTC
