Stream: implementers
Topic: CDS Hooks, 'asynchr.' reply
Bart van der Worp (Aug 24 2017 at 12:38):
We would like to implement this use-case with CDS Hooks.
- CDS request for starting of a calculation.
- Returning the result of this calculation.
Quite basic, but the calculation takes a long time, typical several minutes.
I don't think that sending the response after finishing the calculation is good practice.
So the idea is to send a CDS response after basic intake of pre-fetched data with intake status.
After the calculation is completed, it is then needed to push the result.
The only way within CDS Hook context I see is mis-use a pre-fetch cycle to push the result.
Not good practice either as seen from standpoint of consistent standard use, but already somewhat better from general perspective ...
Polling using a second CDS request is something I would not like at all.
Please advice. Am I missing or misinterpreting something?
Thanks in advance, Bart.
Grahame Grieve (Aug 24 2017 at 12:39):
is this actually a cds-hooks thing? as in, integrated with the UI? What does the flow look like from the user's perspective?
Bart van der Worp (Aug 24 2017 at 12:44):
Yes, the result is a link to the result. As such a normal CDS use as far as I understand. The point is the very long elapsed time of the calculation.
More detailed consideration would be to send the link already in the first reply, it is known then, but we would also like to synchronize the end of the calculation. This could also result in error status that the caller system needs to know, so that's beyond only presenting it.
Josh Mandel (Aug 24 2017 at 12:46):
It's a good use case, and not one the current CDS Hooks spec supports very well. You've identified one workaround, which is a forward pointer to a result that can be generated right away, even before the result is available. Users can click the link and see a page that you host to indicate status and, when available, the final result.
Josh Mandel (Aug 24 2017 at 12:48):
Thinking about how the spec would need to change to accommodate this use case better: we could say something like 1) response cards can contain a "pollAgainAfter" interval and perhaps a "pollAgainUrl" that would return a replacement card when content was available, or 2) the EHR could host an endpoint specifically for asynchronous results, and the external service could push to that endpoint when ready.
Bart van der Worp (Aug 24 2017 at 12:56):
I would prefer 2) in our current case, but both seem feasible I guess.
We need to proceed, so for the time being we could mis-use the pre-fetch for pushing the result as a work around?
We could arrange a special FHIR 'resource' to create an endpoint to push the result to.
And ofcoarse, this needs to discussed clearly in detail with the builders of the requesting system.
Josh Mandel (Aug 24 2017 at 12:59):
I'm not sure I follow what you mean about prefetch... prefetch is a way to send data from the EHR to a CDS Service, but you're talking about returning data from the CDS Service to the EHR.
Bart van der Worp (Aug 24 2017 at 13:01):
Yes, but pre-fetch is initiated by the CDS service as I understand and as such could be mis-used as a push by posting our result in stead of or added to the standard content of the pre-fetch request?
Bart van der Worp (Aug 24 2017 at 13:02):
(deleted)
Josh Mandel (Aug 24 2017 at 13:03):
(You can edit a previous post by hitting the left arrow, or clickinging the post and choosing "Edit".)
Bart van der Worp (Aug 24 2017 at 13:04):
Thanks!
Josh Mandel (Aug 24 2017 at 13:04):
(sure!)
Josh Mandel (Aug 24 2017 at 13:04):
I don't follow what you're saying — pre-fetch is initiated by the EHR (based on a client's static, configuration-time settings).
Josh Mandel (Aug 24 2017 at 13:05):
BTW this may be a better topic for https://chat.fhir.org/#narrow/stream/cds-hooks
Bart van der Worp (Aug 24 2017 at 13:05):
(deleted)
Bart van der Worp (Aug 24 2017 at 13:16):
I mixed terminology ...
The CDS request contains pre-fetched data. This is not what I mean.
The CDS request also contains a EHR FHIR server URL that can be used to ad-hoc request additional data from the EHR. This is what I erroneously called 'prefetch' ...
We could use this URL to push the result from the CDS service to the EHR as a temporary workaround.
Bart van der Worp (Aug 24 2017 at 14:38):
Can an admin move this topic to cds-hooks please?
Josh Mandel (Aug 24 2017 at 14:44):
Topics don't move, but we can pick up the convo there :-)
Last updated: Apr 12 2022 at 19:14 UTC
