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

Stream: cds hooks

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

view this post on Zulip Github Notifications (May 06 2017 at 06:49):

isaacvetter opened Issue #43

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.

view this post on Zulip Github Notifications (May 06 2017 at 11:42):

bdoolittle commented on Issue #43

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?

view this post on Zulip Github Notifications (May 08 2017 at 08:00):

jmandel commented on Issue #43

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, @Isaac Vetter, 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?)

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -