FHIR Chat · Using OverrideReason / Feedback outside suggestion

Current spec https://cds-hooks.org/specification/current/#overridereason and PR https://github.com/cds-hooks/docs/pull/519 are geared towards using OverrideReason with suggestions. Our patient-view hooks service responds with applicable pathways (as app link cards) for users to interact with based on the patient context. The use case we wanted to try out is as a CDS service provider, present bunch of app link cards (with out suggestions - example below) and let user override the same if they think that the app link card is not applicable

{
  "cards": [
    {
      "indicator": "info",
      "summary": "UpToDate® suggests Osteoporosis and osteopenia: Initial management in postmenopausal women",
      "detail": "This UpToDate Pathway will help guide clinicians in the initial management of low bone mass (bone mineral density T-score &lt; -1.0) in postmenopausal women. This includes identifying patients who are at high risk for fracture and thus likely to benefit from pharmacologic therapy. The approach should be individualized and include shared decision making between the patient and clinician.",
      "source": {
        "label": "UpToDate",
        "url": "https://www.uptodate.com",
        "icon": "https://www.uptodate.com/app/assets/utd-menu/utd-icon.png",
        "topic": [
          {
            "display": "Endocrinology and Diabetes",
            "code": "828901000000109",
            "system": "http://snomed.info/sct"
          }
        ]
      },
      "links": [
        {
          "label": "UpToDate® suggests Osteoporosis and osteopenia: Initial management in postmenopausal women",
          "url": "https://healthtech.utdlab.com/acds/services/smartauth/oauth-init/recommendationsApp",
          "type": "smart",
          "appContext": "120455"
        }
      ],
      "overrideReasons": [
        {
          "display": "Screening not wanted",
          "code": 171103002,
          "system": "http://snomed.info/sct"
        },
        {
          "display": "Referral to different healthcare provider",
          "code": 449221000124102,
          "system": "http://snomed.info/sct"
        },
        {
          "display": "Care plan reviewed",
          "code": 335031000000106,
          "system": "http://snomed.info/sct"
        },
        {
          "display": "Personal health plan not appropriate",
          "code": 755201000000108,
          "system": "http://snomed.info/sct"
        }
      ],
      "uuid": "4d48b322-0930-4141-9cec-17c503cd4dd1"
    },

Is this a valid use case to use overridereason / feedback?

@Chuck Feltner @Barbara Atkins

Dennis Patterson (May 04 2020 at 18:43):

Override reasons are at the card level and feedback is per card.uuid, so I think this is a valid use

Dennis Patterson (May 04 2020 at 18:55):

If the CDS Client called your service to say that a card was accepted by virtue of launching the SMART App link, is that your expected behavior?

Raj M (May 04 2020 at 20:59):

Good Point. We were more focused on the flow when provider did not agree with the CDS Service's recommendation to launch the app link (Card Overridden action). But Provider/EHR user can possibly take three different actions when an app link card is presented

Card Ignored - Nothing sent to /feedback end point
Card Overriden - User pick one of the override reason. Overriden feedback sent to /feedback endpoint (based on the override reason picked by the user)
Card Accepted by virtue of launching the SMART app link - We weren't expecting anything sent back to /feedback endpoint. Technically a CDS Service provider can tie up an particular SMART launch to a card using appContext if needed or potentially CDS client can also send Card Accepted feedback to /feedback end point

Chuck Feltner (May 04 2020 at 21:16):

@Raj M Thanks for outlining the use case. Sounds like a valid use. I suppose based on receiving the feedback with the override reasons the CDS Service would not resend those corresponding cards on subsequent patient-view CDS Service Requests for that patient?

Raj M (May 05 2020 at 15:16):

Yes @Chuck Feltner that is the intent in longer run. Shorter term goal is learning the effectiveness of our Hooks service

Isaac Vetter (May 05 2020 at 20:53):

Hey @Raj M , any suggestions for clarifying that it is okay to supply overrideReasons on a card without suggestions, in the spec?

Raj M (May 06 2020 at 20:31):

Sure @Isaac Vetter. I am thinking it will be good to clarify 'card' vs 'suggestion in a card'.

In the current.md (master)

overrideReasons | OPTIONAL | array of OverrideReason | Override reasons can be selected by the end user when overriding a card ~~without taking the suggested recommendations~~ or suggestion in a card. The CDS service MAY return a list of override reasons to the CDS client. The CDS client SHOULD present these reasons to the clinician when they dismiss a card. A CDS client MAY augment the override reasons presented to the user with its own reasons.

In the pr#519

Once a CDS Hooks service responds to a hook by returning an info or suggestion card, the service has no further interaction with the CDS client. The acceptance or rejection of a ~~suggestion~~ card or suggestion in a card is valuable information to enable a service to improve its behavior towards the goal of the end-user having a positive and meaningful experience with the CDS. A feedback endpoint enables suggestion tracking & analytics.
Typically, an end user may only accept a suggestion in a card, or override a card once; however, a card once ignored could later be acted upon.
The CDS client can inform the service when one or more suggestions in a card were accepted by POSTing a simple json object. The CDS client authenticates to the CDS service as described in Trusting CDS Clients.
A CDS client may enable the end user to override guidance without providing an explicit reason for doing so. The CDS client can inform the service when a ~~suggestion~~ card was dismissed by specifying an outcome of overridden without providing an overrideReason. This may occur, for example, when the end user viewed the card and dismissed it without providing a reason why.

Isaac Vetter (May 13 2020 at 15:49):

Raj, Also:

A CDS client can inform the service when a ~~suggestion~~ card was rejected by POSTing an outcome of overridden along with an overrideReason to the service's feedback endpoint. The CDS Client may enable the clinician to supplement the overrideReason with a free text comment, supplied to the CDS Service in overrideReason.userComment.

Isaac Vetter (May 13 2020 at 15:53):

Also, I changed your above, like so:

Once a CDS Hooks service responds to a hook by returning an info or suggestion card, the service has no further interaction with the CDS client. The acceptance of a suggestion or rejection of a card ~~or suggestion~~ is valuable information to enable a service to improve its behavior towards the goal of the end-user having a positive and meaningful experience with the CDS. A feedback endpoint enables suggestion tracking & analytics.

Effectively, a suggestion isn't overridden -- only a card can be overidden. A card isn't accepted, only one or more suggestions can be accepted. Does that make sense?

This is pretty much what the PR already said, e.g.:

Upon receiving a card, a user may accept its sugestions, ignore it entirely, or dismiss it with or without an override reason. Note that while one or more suggestions can be accepted, an entire card is either ignored or overridden.

Dennis Patterson (May 13 2020 at 15:57):

did you mean to say "only one or more suggestions can be accepted"

Isaac Vetter (May 13 2020 at 15:57):

@Raj M - want to re-review? Dennis - can you prioritize your re-review as well? (Tables are added as you requested). Dennis - if you approve today, I'll merge in since Josh's already approved as well.

Dennis Patterson (May 13 2020 at 15:59):

yep i'll be looking today

Raj M (May 13 2020 at 19:41):

Yes

Isaac Vetter said:

Effectively, a suggestion isn't overridden -- only a card can be overidden. A card isn't accepted, only one or more suggestions can be accepted. Does that make sense?

Raj M (May 13 2020 at 19:45):

Looks good @Isaac Vetter . Thx :+1:

Isaac Vetter said:

Raj M - want to re-review?

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Using OverrideReason / Feedback outside suggestion · cds hooks

Stream: cds hooks

Topic: Using OverrideReason / Feedback outside suggestion

Raj M (May 04 2020 at 15:55):