Asynchronous vs synchronous intent of the specification

[Manoj Sharma]

 

So I wanted to pose a question to the CDS Hooks group, which revolves around the intent of this specification.  You can find the verbiage "this specification describes a 'hook'-based pattern for invoking decision support from within a clinician's EHR workflow. The API supports: Synchronous, workflow-triggered CDS calls".

But as an EHR vendor, I may see value in triggering a hook within my clinical workflow, which may not need immediate action.   For example, in the sandbox.cds-hooks.org, we are triggering a “medication-prescribe”.  In the EMR workflow, this hook would be triggered once required information for that Medication Order is keyed in (i.e. medication, strength, dose, sig).  The CDS Hooks Service being triggered for “medication-prescribe” may have to query multiple vendors (CVS, Walgreens, Walmart) for prices to compare to the medication.  This may take longer than expected.  In this example, would it not be possible to leverage bi-directional communication to push the prices as they are received from the CDS Hooks service? If the CDS Hooks Service is not able to provide all prices, does the “synchronous” aspect of the CDS Hooks specification make it unreasonable to use for these type of scenarios?  Is asynchronous not supported by the specification or was the intent to keep it “as synchronous” as possible?

In a similar fashion, if the EHR vendor allows the provider to continue in the clinical workflow, as the CDS Hooks Service is still gathering the prices before responding with the entire set of cards to the provider, even to the point of the provider being at a different part of the EHR.  Does the specification dictate that the provider's action has to take place within a specific amount of time or location, relative to the workflow trigger?  How does this group see this type of scenario fitting in to the CDS Hooks specification?

I know I have posed many questions, so we may need to break down the CDS Hooks specification intent versus real world expectations of the EHR vendors and the CDS Service providers in the two scenarios above.

[Isaac Vetter]

Hey Manoj,

Great questions!

1) Is there value in asynchronous, user-facing, external CDS? 

Heck yes, there is! The scenario that you lay out is a great example. The current limitation of the spec to synchronous exchanges is an intentional limitation in scope. An option to receive an asynchronous CDS response could be a great enhancement. Other potentially valuable features that are intentionally placed out of scope by the verbiage you quote, are: patient-facing cds and non-user facing cds.

Essentially - we've got to start somewhere and remote, synchronous, provider-facing cds has a lot of value and is accomplishable.

2) Does the specification dictate that the provider's action has to take place within a specific amount of time or location, relative to the workflow trigger?

The specification does not dictate specific UI or EHR workflow. In my EHR, especially in ordering scenarios, we think it's important to restrict the clinician from moving to a different part of the EHR. 

Does that help?

Isaac

--
You received this message because you are subscribed to the Google Groups "CDS Hooks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cds-hooks+...@googlegroups.com.
To post to this group, send email to cds-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cds-hooks/ebd0e382-f769-41f0-8f9f-e9fa694f07c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.