FHIR Chat · docs / Issue #43 Enhance suggestion to support grouped re...

Stream: cds hooks/github

Topic: docs / Issue #43 Enhance suggestion to support grouped re...

Github Notifications (Jun 12 2017 at 20:54):

kpshek milestoned Issue #43

Github Notifications (Jun 14 2017 at 16:50):

Few questions about this issue:

"This intentionally does not support the additional feature and complexity of Clinical Reasoning’s RequestGroup selectionBehavior".

As far as I can tell from the spec, the function of selectionBehavior would only be enforceable within the SMART app. So a service hoping to use a Suggestion card to provide alternatives could only provide alternatives that were not mutually exclusive. Like this situation:

Doctor prescribing Amoxicillin, medication-prescribe fires, CDS service realizes patient has confirmed MRSA.

Service wants to suggest doctor prescribe Bactrim or Clindamycin, but not both. Through suggestion cards, you can't enforce the mutual exclusivity there. Or am I misinterpreting, and certain suggestions can cancel other suggestions?

Which means the service would need to return a RequestGroup to show that you can choose one of these medications, but not both. From what I can see, a suggestion card is just saying "create this resource if the user clicks this card", and not "select from these options and then create".

Has there been discussion on allowing for selection behaviour in Suggestion cards. Can a Suggestion card return a RequestGroup? The problem I see with that is the recursive nature of a request group.action, problems displaying it, problems parsing it. I get the feeling the attractive nature of CDS-Hooks is it's simplicity and a RequestGroup is kind of a complicated Resource, and that it seems implied that a single suggestion should be a single resource.

Github Notifications (Jul 03 2017 at 15:51):

bdoolittle commented on Issue #43

@travisstenerson, the CDS-Hooks specification does not clarify how suggestions should be interpreted. This is an area that should be described in greater detail as misaligned interpretations between CDS service and EHR could result in a degraded user experience and potential patient safety issues.

At athenaHealth, our implementation aligns with @Isaac Vetter interpretation where resources specified within each suggestion create and delete array or the actions array are AND'ed together and all suggestions within the suggestions array are OR'ed together and are all mutually exclusive. In this implementation, suggestions that are not mutually exclusive must be tied to separate cards.

If we were to connect with a service that did not assume mutual exclusivity between suggestions within a card, our providers would not be able to accept more than one of the services suggestions.

An even worse case can happen if an EHR does not assume mutual exclusivity but a CDS service does. Here a provider may accept multiple suggestions when in reality this should have only been one. In benign cases, this might result in a more expensive visit for a patient, but in more extreme cases harmful drug-drug interactions may be selected.

The important thing here is not how the EHR executes suggestions, but that both EHRs and CDS services agree on how suggestions should be handled.

Github Notifications (Jul 10 2017 at 20:50):

kpshek assigned Issue #43

Github Notifications (Jul 13 2017 at 03:20):

kpshek commented on Issue #43

I agree with @brian doolittle wholeheartedly that we need to be very clear in our intentions/definition of suggestions. Today we are sorely lacking here so we should all aim to ensure that we address this in this issue.

@Josh Mandel - You're correct that the proposal @Isaac Vetter, @brynrhodes, and myself have here is functionally equivalent to what we have today but just semantically different. Though you touched on the differences, I thought I'd lay them out very plainly with additional reasoning.

#### Consolidated actions array vs arrays-per-action-type
Rather than grouping action types in distinct arrays (create, delete), all actions have been combined into a single actions array. We felt that this was a cleaner structure than what we have today.

#### Addition of an explicit modify action type
Not having a modify action seems confusing as we don't see all developers understanding that EHRs may convert a delete and create action into a single modify action -- especially if the CDS Service simply wants to perform a simple action like modifying the dosage of an existing medication.

The addition of a modify action also aligns with Clinical Reasoning.

@brynrhodes - RequestGroup calls this update. It seems like we should use that term too rather than modify. Thoughts?

@travisstenerson - You are correct that both our current suggestions API and the proposal here do not support mutually exclusivity; RequestGroup in Clinical Reasoning does. When @Isaac Vetter, @brynrhodes, and I were discussing this, it was a conscious decision on our part to omit this. We were trying to balance simplicity of the API and allowing for interesting scenarios and use cases. These are often opposing concerns and favoring one is often at the expense of the other. I would like to see what use cases we can support today with our current API/functionality and over time enhance the API if we find there to be enough interest from both CDS Services providers and EHRs. For those who want to push beyond what the specification supports today, I think there are several options at their disposal: SMART apps, custom vendor/service collaboration, etc.

Github Notifications (Jul 16 2017 at 19:33):

brynrhodes commented on Issue #43

@kpshek - I agree we should use consistent terms and call it update.

Github Notifications (Jul 20 2017 at 17:41):

isaacvetter commented on Issue #43

Does anyone (@kpshek, @Josh Mandel ) have the ability to regenerate this image? We need to change the text on the suggestion from _[{delete: ..., create: ...,}]_ to
_actions: [{
type”: create, ...,
type: delete, ...,
}]_

http://cds-hooks.org/images/overview-with-decisions.png

Github Notifications (Jul 25 2017 at 22:25):

bdagnall commented on Issue #43

Hi there. I am trying to catch up on this thread so forgive me if the answer to my question has already been provided. I am working with Bryn Rhodes on a health platform that engages with a CDS service using CDS Hooks. I don't have a specific use cases necessarily. I am wondering if there is a pre-defined taxonomy of suggestion card types that could be used for downstream processing to determine how a suggestion should be handled? I can imagine that some suggestions are urgent and should be routed to a provider or patient through a real-time messaging system. Other suggestion cards might be stored and only shown when someone actively logs into the system. Who receives the suggestion card, when they receive it and through which communication channel they receive it could all be based on the suggestion card type. Thanks!

Github Notifications (Jul 26 2017 at 06:27):

kpshek commented on Issue #43

Hi @bdagnall! Your questions are great and best discussed either in their own issue (feel free to open a new Github issue here) or raise this discussion in a new topic in our #cds-hooks stream in our Zulip chat.

Would you mind raising your questions in either of those two venues?

Github Notifications (Jul 26 2017 at 06:30):

kpshek commented on Issue #43

@Isaac Vetter - What if we replace that image with this one?

<img width="892" alt="cds hooks workflow" src="https://user-images.githubusercontent.com/157327/28607547-015335ce-71a2-11e7-83c2-259b8a6f0742.png">