FHIR Chat · docs: issue 18: Clarify Decisions · cds hooks

Stream: cds hooks

Topic: docs: issue 18: Clarify Decisions

Github Notifications (Jan 25 2017 at 17:59):

robs16 opened issue 18

It is my understanding that decisions are not meant to direct the EMR to perform the decision action (create/delete). Instead they're meant to be a notification to the EMR after the action has already been executed (out of band) by the CDS vendor.

The documentation needs to reflect this understanding, as it is easy to misunderstand and assume that decision should cause the EMR to perform the requested updates.

Github Notifications (Feb 21 2017 at 20:32):

jmandel commented on issue 18

@robs16 your description here isn't quite right. The idea of a "decision" is to communicate a user's intent to the EHR — the user had a conversation with an external app and *decided* something (e.g. decided to change drugs while writing a prescription), but the thing *isn't done yet* (e.g. the changes hasn't been made).

The EHR's job upon learning about a "decisoin" is to update the UI to reflect this decision, allowing the user to continue in the workflow from where they left off.

This is super-helpful in cases where EHR's don't support API driven writes. For example, the EHR probably doesn't support an API for creating a new prescription —so the CDS Hooks framework allows an alternative, where the service returns a "decision" that the EHR can then render within its native UX. Think of it as a bridge to writing

For data types where the external service *can* write (e.g. adding a new problem to the problem list), the service could just go ahead and issue the POST call. Then after returning to the EHR, the service might just include an "information card" saying (for example) "hypertension added to the problem list" (for example).

Github Notifications (Feb 22 2017 at 21:50):

robs16 commented on issue 18

@Josh Mandel Thanks for the clarification. From what you said there appears to be (at least) two distinct ways for the CDS service to provide the decision output and it is dependent on the consumer of the CDS service. This implies a tight coupling between the consumer and provider (custom integration), which IMHO is not ideal for an interface standard. I would prefer the the decisions are communicated in the same manner in both of the scenarios, potentially with an indicator to show if a decision has already been performed.

Github Notifications (Feb 22 2017 at 21:59):

jmandel commented on issue 18

Thanks for the comments @robs16! Can you clarify which "two distinct ways" you're referring to?

If you're talking about REST API calls vs CDS Hooks Decision responses... my apologies if I was unclear. These would be serving different use cases. One (REST API calls) is for changes that could be made directly to a system (by anyone authorized client, EHR it's a CDS service, SMART app, or otherwise); the second (decisions) is for changes that can't be made directly to an EHR's system, and so instructions they're merely proposed via the UI of the electronic health record, for a user to confirm/complete.

If this explanation still seems wrong, I wonder if you might give an example of the alternative approach that you're expecting. I really appreciate your attention here!

Github Notifications (Feb 22 2017 at 22:31):

robs16 commented on issue 18

Scenario 1: CDS Service changes the patient's chart directly to reflect the decision
Scenario 2: CDS Service can only indicate the decision which the user has agreed to

In both cases, the user has somehow indicated that a change should be made. I am suggesting in both cases there should be a decision record in the cds hooks response (honestly before this conversation it never occurred to me that this might not be the case). An info card can be ignored or not even presented and it would certainly be a bit of hard-coded wizardry to interpret an info card from a programatic standpoint as an indicator that the decision was made and applied. There could be many reasons why the EHR needs the decision in the CDS hooks response. For example, just because it is possible to remove an order programmatically does not mean the EHR has the logic in such a call to understand that this is part of a CDS session and perform associated logic. At the same time it brings a consistency and clarity to the response where a decision has been made.

Github Notifications (Feb 23 2017 at 22:22):

jmandel commented on issue 18

Hmm — I definitely wasn't suggesting that the EHR would be responsible for parsing/understanding the contents of an Information card :-) I was trying to say that, optionally, the service could create a user-facing notification using this kind of card.

This is good stuff.

We should probably step back here and talk about flows for:

1. *effecting* change, like adding a new problem to a patient's problem list, vs.
2. *notifying of a change already applied*, like "hey, EHR: you should be aware that I just added this problem to the list in the context of an app/user interaction", vs.
3. *communicating a desired* change, like saying "I interacted with the clinician and determined that she wants to change the dose to 200mg", vs.
4. *notifying about the evaluations that were performed*, like for the EHR's audit logging, so it knows what to record about the CDS that occurred

The question becomes: which of these things happen through the FHIR REST API (I'd think (1) at least) vs a synchroous CDS Hooks response (and within that response, which things are decisions vs some new concept like "change notifications" or "loggable events".

Github Notifications (Apr 20 2017 at 19:53):

bkaney commented on issue 18

@Josh Mandel just calling your attention to #26 here as a way to handle your (3) from above.

Last updated: Apr 12 2022 at 19:14 UTC