Stream: cds hooks
Topic: Returning decisions from an app
Josh Mandel (Oct 24 2018 at 01:33):
Hey all! Based on our discussion in Baltimore I've completed two tasks:
1. Updated @Alex Tatiyants's delightful "Decision Proposal" doc to flesh out details of app-to-ehr communications using SMART Web Messaging (change set here)
2. Wrote up a SMART Web Messaging proposal with significantly reduced scope, including rational, alternatives considered, and an explanation of how it works with CDS Hooks.
The SMART Web Messaging proposal in particular includes a section on alternatives considered that reflects the trade-offs we began to discuss in Baltimore. I'd love feedback on this approach; so far I've had the chance to discuss with @Isaac Vetter and @Matt Varghese.
Josh Mandel (Oct 24 2018 at 16:21):
@Dan Gottlieb and @Vladimir Ignatov FYI
Alex Tatiyants (Oct 25 2018 at 13:46):
@Josh Mandel this is great. I'm fine changing the response from CDS Hooks actions to FHIR operations since it'll accomplish the same thing. The only issue I can see is the need to have some guarantees about which FHIR operations will be supported. In other words, if an EMR has a CDS Hooks implementation which supports actions for add/create/update order, CDS service should be able to assume that the same implementation will support FHIR update/create/delete for unsigned orders as well.
Josh Mandel (Oct 25 2018 at 13:49):
Yeah, I think that's right, in terms of assumptions. Would you feel better if these assumptions were spelled out over the wire with scopes or something?:or is this more like a checklist item for people who are configuring services?
Josh Mandel (Oct 25 2018 at 13:54):
I should also note that for it CDS Services returning action cards today, it is also hard to be sure which kinds of actions to EHR will natively support applying. In the case of the web messaging API, at least there is a way for the EHR to return an error if the requested update cannot be performed.
Alex Tatiyants (Oct 25 2018 at 18:13):
A couple of comments:
- Yes, I do think that the assumptions should be somehow spelled out. No strong feelings on config vs. runtime, both could be useful depending on context.
- You're right in that we can't guarantee which actions are supported by an EMR. That said, if an EMR does support a specific action (like add order) then we should be able to depend on it also supporting the same operation via FHIR. So, it's really symmetry I'm after.
Josh Mandel (Oct 29 2018 at 20:29):
Let me see if I can get the symmetry aspect right: are you saying that any operation you can perform via SMART Web Messaging should also be available in the REST API? Or any action you can perform in a CDS Hooks suggestion card should be available in the REST API? (Neither of these seems guaranteed true today.)
Last updated: Apr 12 2022 at 19:14 UTC
