FHIR Chat · docs / PR #91 Specify that users may choose at most one s... · cds hooks/committers

Stream: cds hooks/committers

Topic: docs / PR #91 Specify that users may choose at most one s...

Github Notifications (Sep 10 2017 at 01:37):

kpshek opened PR #91
from at-most-one-suggestion to master

In discussion with @brian doolittle, @kendrapugh, @Isaac Vetter, @brynrhodes, and @Josh Mandel we discussed that allowing users to choose at most one suggestion was preferable over our current approach of allowing a user to select as many suggestions as they want. Our reasoning is that choosing at most one suggestion prevents the user from choosing multiple suggestions that conflict or can cause patient harm.

Github Notifications (Sep 10 2017 at 15:36):

isaacvetter review_requested PR #91

Github Notifications (Sep 10 2017 at 16:43):

brynrhodes review_requested PR #91

Github Notifications (Sep 10 2017 at 16:54):

kpshek closed PR #91

Github Notifications (Sep 10 2017 at 18:42):

kensaku-kawamoto commented on PR #91

Could we get some examples for this? E.g., if a patient has a hemoglobin A1c in the pre-diabetes range, the suggestion may be to choose one or more of:
[ ] Re-test A1c
[ ] Diagnose with prediabetes
[ ] Refer to Diabetes Prevention Program

In this context, what does "can only choose one suggestion" mean? Since a given Suggestion card's actions are AND'd, it seems like these would need to be different cards. But it seems what is being suggested is that the user can only choose one of them?

Github Notifications (Sep 10 2017 at 19:23):

bdoolittle commented on PR #91

You are correct, if you wanted the user to be able to select any number of your provided suggestions, you would need multiple cards. The alternative would be to make suggestions that offer some of the combinations that a user might select. For example:

[] Re-test A1c
[] Diagnose with prediabetes
[] Diagnose with prediabetes & Refer to a Diabetes Prevention Program
[] Refer to a Diabetes Prevention Program

While only being able to select a single suggestion in a card may be a bit cumbersome for your use case, it does represent the more conservative interpretation of suggestions. What I mean is that there may be patient safety risks if multiple suggestions could be selected. Imagine a case where medication A and medication B are both suggested for treating a specific illness. However, selecting both medication A and B would result in a harmful drug-drug interaction. In this case, you would not want to give the provider the option of selecting both of these medications.

One could make the argument that a subsequent order-review hook would occur after the suggestion is accepted and orders are created and that this hook would catch any hazardous interactions between the created orders. However, we can't rely on subsequent hooks as a fail safe as there is no guarantee that a new hook would be made or that any guidance will make it to the provider before the orders are signed off on and the encounter has closed.

Github Notifications (Sep 10 2017 at 19:31):

kensaku-kawamoto commented on PR #91

I think we should mimic existing EHR functionality for now. Currently, in our production rules, it is very common to have this "check any of the above, with some pre-checked" approach. I think it will be extremely limiting to allow basically only radio buttons and not check boxes. In the future, we should work towards having more complex order set like functionality -- where, e..g, you can say things like "choose one or more from set A OR one or more fro set B" (i.e., nested radio buttons and check boxes).

Github Notifications (Sep 10 2017 at 19:43):

kendrapugh commented on PR #91

I was thinking of contraindicated synergistic effects, although you may also want to explicitly bundle for therapeutic selectivity! e.g.
[] choose A, less toxic than B or C on their own
[] choose B and C, when combined they are safe
I would lean toward XOR operations so that suggestions do not imply combinations of decision branches are safe (in the event they may not be) for 1.0, but I agree we should be able to get more complex representation in the future.

Github Notifications (Sep 12 2017 at 14:23):

travisstenerson commented on PR #91

Our current Hooks response is currently embedded in a RequestGroup specifically because we could not represent the complex selection logic required with the actions in just CDS Hooks. The (large) clinical practice guideline I am currently working with makes use of all of the selectionBehavior cases covered in FHIR clinical reasoning:

any | all | all-or-none | exactly-one | at-most-one | one-or-more

Without them we need to make use of RequestGroup and not just a set of CDS-Hooks actions. It would be nice if CDS-Hooks also covered the above cases. But if not, I agree that XOR is much preferable to OR within an action.

Last updated: Apr 12 2022 at 19:14 UTC