Enhance suggestion to support grouped recommendations

[isaacvetter]

In discussion with @brynrhodes and @kpshek regarding aligning Clinical Reasoning and CDS Hooks, one of the topics of discussion was around the functionality of the FHIR Clinical Reasoning RequestGroup resource. Overall, FHIR's RequestGroup is very powerful, but it also introduces a lot of complexity as well as a dependence upon STU3.

How to pragmatically and simply incorporate the best parts of RequestGroup into CDS Hooks, while also allowing for compatibility with this FHIR resource? Here's the direction that @brynrhodes, @kpshek, and myself landed on:

An array of actions should be added to the CDS Hooks suggestion, such that a card can return multiple suggestions, of which the user can select one. Each suggestion contains a list of actions. When a user selects a suggestion that contains multiple actions, the user is selecting all of the actions within that suggestion. Here's what this looks like in json:

“suggestions”: [
  // EHRs should render suggestions to the user as
  // ANY suggestion can be selected
  {
    “uuid”: “abc1238hdf87sh”,
    “label”: “Add & remove”,
    “actions”: [
     // Actions are ANDed together
     {
      “type”: “create”,
      “description”: “Add this new order for X”,
      “resource”: { resource X }
     },
     {
      “type”: “delete”,
      “description”: “Cancel the existing order”,
      “resource”: “MedicationRequest/123”
     }
    ]
  },
  {
    “uuid”: “n9d89hsdg8h”,    
    “label”: “Modify warfarin”,
    “actions”: [
     {
      “type”: “modify”,
      “description”: “Change warfarin dosage to 10mg/day”,
    “resource”: "MedicationRequest/abc"
     }
    ]
  }
]

Note that each suggestion is implicitly OR’d and that the actions within a suggestion are AND’d. This intentionally does not support the additional feature and complexity of Clinical Reasoning’s RequestGroup selectionBehavior. Additionally each suggestion is implicitly a “visual-group” in the same way as Clinical Reasoning's RequestGroup’s groupingBehavior.

[bdoolittle]

Hi Isaac,

I think that this would be a great modification to the cds-hooks spec. In the implementation I'm working on at athenaHealth, we are using a combination of create and delete to describe a modification to the order (e.g delete a specified order and create an identical order with modifications to it). I like how the RequestGroup resource allows for the updates to be explicitly described.

In the FHIR action-type documentation, it mentions RequestGroup action types of create, remove, update, and fire-event.

• Do we want the naming scheme to match FHIR?
• Would the cds-hooks spec support the fire-event action type?
• What might some fire-event use cases be?

[jmandel]

I'm just catching up on this one... and I think we already have support for this (if I'm understanding correctly).

Our current structure provides an array of suggestions (the things that are "OR'd together") in a single suggestion card. Each suggestion includes list of changes (the things that are "AND'd together", in the form of create + delete arrays), which correspond to the actions array you're describing. On a quick read, it seems like the only difference is whether these arrays are merged into a single "actions" array (with the create-vs-delete distinction bubbling down into a property on the actions).

In terms of the use cases you'd want to make sure we support, @isaacvetter, can you highlight the gap?

(Also, I should say: we could of course just add a modify array next to our current create + delete — but I originally figured that it was clearer to let the EHR manage the question of whether to preserve or reassign ids, and just let the service express a modify as create-and-delete. Are there more kinds of actions besides create/delete/modify that you'd want to make sure we can handle, which would steer us toward the more generic model?)

[travisstenerson]

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.

[bdoolittle]

@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 @isaacvetter interpretation where resources specified within each suggestion (create and delete arrays 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.

[kpshek]

I agree with @bdoolittle 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. 😄

@jmandel - You're correct that the proposal @isaacvetter, @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 @isaacvetter, @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.

[brynrhodes]

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

[isaacvetter]

Does anyone (@kpshek, @jmandel ) 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

[bdagnall]

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!

[kpshek]

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?

[kpshek]

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

[isaacvetter]

Swapped in above image, per suggestion, on pull #60

[isaacvetter]

Fixed in #60