FHIR Chat · Deferring cards

One of the use-cases we're looking at for the next release of the Da Vinci CRD specification is allowing the creation of 'deferring' a SMART app launch. Specifically, if a provider is ordering something that requires a prior authorization, CRD will currently pass back a card allowing launching of a SMART app allowing the simplified capturing of information needed for that prior authorization. However, the reality is that in many practices, the process of gathering that information might not be done immediately when the patient's in the room - and might not even always be done by the ordering practitioner.

The initial thought was to pass back a card with two options - launch the SMART app or create a Task allowing the launch (complete with appropriate context) to be scheduled for later. And that's what we'll still do if we can't find a better way. However, the approach suffers from a few limitations

there's no mechanism to allow the provider to choose whether they want the Task assigned to themselves, someone else or possibly leave it unassigned
there's no ability to indicate priority or desired timing for completion
there's no ability for the provider to adjust any other aspects of the Task at the time it's created.

It seems to me that 'deferring' a card is a pretty general set of functionality that would be useful on a wide variety of cards. "Would you like to review ABC's opioid prescribing guidelines?" - "Yes, but not now". "Consider putting this patient on a diuretic as well" - "Good idea, but I want to think about it more/talk with their GP first".

This wouldn't even necessarily involve technical changes to the CDS Hooks spec, as it would really just be EHR functionality with no particular interoperability considerations. Really, it would just involve some guidance around the types of cards that might be deferred and a recommendation to provide support for that. I suppose it might be possible to add a flag on a card about whether a given card should be deferrable, but I'm not sure that should be decided by the service. It might also have some impact on capturing Feedback - so you would know if something was deferred and also be able to track whether it was acted on eventually.

Thoughts?

Josh Mandel (Aug 27 2021 at 15:47):

Agreed this is an important UX consideration -- and I agree that it needn't involve much if any change to the spec. It'd be worth writing out what we think the UX guidance might be, in conjunction with CDS Clients to understand what's possible/likely (and in what kind of step-wise fashion, and over what time-course).

Frank Pandolfe (Aug 27 2021 at 17:04):

I'm not sure that routing SMART apps to other users is really within the scope of a synchronous alert covered by CDS Hooks.
One possibility is to create a suggestion that could read something like "push to PA queue" or "push to my 'to do' list" which would write something to a monitored database which could then create a task for someone else to fill out or for the clinician to fill out later or potentially do routing. There seem to be a lot of subtleties that could get quite complicated.

The spec doesn't specify what the client should do if a client ignores or overrides a card.
override forever? until the next time I log in? show again in five minutes?
Some of this will also do with how the client chooses to display the card. Is it an interruptive alert or does it just show up in a side panel?

Deferring a card could be a special override case where the user sees something like "snooze for 5 minutes"
Feedback is sent that the card was overridden. The client could choose to recall the service in 5 minutes.

Thinking about this again maybe it makes more sense to think of it as a special case of "ignore" - no feedback is sent until the user decides to "meaningfully" interact with a card.

Lloyd McKenzie (Aug 27 2021 at 18:15):

My primary concern here isn't the feedback given, it's that the action that needs to be taken at some point is one that doesn't necessarily need to happen right away. In that case, the user should have the ability to 'track' the item as a to-do and, if appropriate, assign it to someone else. The alert definitely needs to be synchronous. The recommended action doesn't always need to be.

Frank Pandolfe (Aug 27 2021 at 18:44):

The action of the suggestion could be to create a task on a task management system. Once there, it is up to that system to manage all the tracking.

Josh Mandel (Aug 27 2021 at 18:55):

I'm not sure that routing SMART apps to other users is really within the scope of a synchronous alert covered by CDS Hooks.

I wouldn't describe this as routing a card; I'd describe it as the user receiving a suggestion from the card, and the CDS Client helping the user act on that suggestion in a useful/convenient fashion.

Josh Mandel (Aug 27 2021 at 18:56):

There are some important technical implications though, especially if the SMART App Launch takes advantage of an appContext param -- how long does the CDS Service need to honor appContext for, and is it bound to any particular security context?

Lloyd McKenzie (Aug 27 2021 at 18:58):

How would the CDS service be involved in honoring the appContext when the SMART app is launched? I wasn't aware that the SMART app talked to the CDS Service. The app context is just a chunk of data that gets passed into the launch.

Josh Mandel (Aug 27 2021 at 19:11):

The appContext may not be stateless; it may be something like... a large random number that acts as a database key to a record that the CDS Service can write, and the SMART App can read.

Josh Mandel (Aug 27 2021 at 19:12):

If the database is keeping that state alive for 2h and then clearing it (more than enough time for a provider to click an app link in any normal scenario) this is an assumption that will fall flat in a world where "suddenly we're going to stick Tasks on someone's queue for next Monday".

Frank Pandolfe (Aug 27 2021 at 21:32):

Clinician is working in a patient chart, is writing a medication and receives a CDS Hooks Card indicating that pre-auth is needed. The card contains a link to a SMART app (among several other possible pieces of information including the appContext) where a clinician fills out a FHIR Questionnaire. The clinician:

Scenario 1: Completes the questionnaire in real-time

this is the "expected" workflow and does not seem to pose any issues

Scenario 2: Defers the completion for several minutes while still in the patient chart

Sill seems fine. The appContext is probably still valid. How to defer the card in this case is up for discussion.

Scenario 3: Leaves the patient's chart and defers the completion until "some later time" be it several hours or several days.

Do I want to create a "reminder" to myself to go back and do this?
3.1 No reminder; clinician will remember.

         -  Clinician navigates back to the chart, the CDS Hooks service is recalled and the appContext is refreshed
   3.2 Yes, reminder;

        - Create a task to remind me to go back into that patient's chart and prescribe that medication.

Scenario 4: Determines that someone else should fill out the pre-auth

Create a task to tell that someone else to fill out the pre-auth

Scenario 5: Partially fill out a questionnaire via a SMART app and come back later to complete it or ask someone else to complete the rest.

i don't want to think about that one yet.

I wasn't trying to describe Scenario 3.2 and 4 as the routing of cards. I was trying to convey the idea that a synchronous notification protocol should not be responsible for task management or result routing.
I suggest one way to potentially get around that is to use the suggestion field. The action associated with that suggestion could create a FHIR Task resource and write it to some server that has a task management system on it. The task management system would be responsible for urgency, contacting people, sending messages, etc. Whoever picks up the task would have to have access permissions and launch the app from whatever system they are in. That system would be responsible for providing any further appContext.

Of note, I'm not as familiar with the SMART app launch sequence and if launching a SMART app in a new window is allowed, but there would be a clinical risk if we allowed a clinician to launch a SMART app in a new window with the appContext of Patient A, then allow the clinician to navigate to Patient B, while keeping the app launched with the context of Patient A. The clinician could get confused who's SMART app is up on the screen.

Josh Mandel (Aug 27 2021 at 22:34):

Re: confusion, EHRs manage smart app launch in patient context; the app learns whether it needs to display a patient banner. If the EHR supports having more than one patient chart open at a time, the usual UX should disambiguate.

Josh Mandel (Aug 27 2021 at 22:35):

3.2 is clearly an EHR experience outside the protocol, IMHO. any management or creation of "tasks" would be an internal detail.

Lloyd McKenzie (Aug 27 2021 at 23:17):

For #3.1/3.2, you can't re-trigger the "order sign" hook once the order is already signed and printed. More is needed than a reminder Task. You actually need to store the card information because you won't be able to re-generate it later.

I can write a FHIR Task, but don't really want to because that doesn't allow the user to indicate who the Task owner should be (if they're deferring, it's quite probable it won't be the clinician), nor is it possible to fill in other information like urgency or timeframe. Finally, it places whether a card is "deferrable" in the hands of the CDS service, which isn't ideal. Having it as part of the spec means that it's now a UI function of the EHR where filling out other task-cue stuff can be handled, it can be available everywhere, and considerations about things like "how long does the context need to be valid" can be addressed.

Josh Mandel (Aug 27 2021 at 23:23):

Understood. I'd start with implementation inside the EHR UX and feed changes into the spec based on that experience. It's too easy for the spec to get far ahead of implementations otherwise.

Lloyd McKenzie (Aug 28 2021 at 02:55):

The question from a CDS Hooks perspective is: should we be building in an expectation for CDS Services to include a "create Task" alternate action with some custom parameters to store the information needed to launch the SMART app later; or would the EHRs rather build this as a generic piece of functionality?

Frank Pandolfe (Aug 28 2021 at 03:30):

I would argue that a CDS service should not provide this functionality. I believe it is outside the scope of a CDS service to do so. Additionally. offering the option of tasks for later time or a different user is admitting that we have failed at least a couple tenets of the five rights of clinical decision support .

Lloyd McKenzie (Aug 28 2021 at 15:12):

Saying "this thing you're ordering requires prior authorization, would you like to launch a SMART app to optimally apply for it" is best done at the time the order is being written, even if the clinician doesn't want to be the one to use the app. There's no other point in the workflow it can easily be triggered. "X needs to be done now" sometimes translates to "The decision on who is going to do X and when needs to be made now".

Vassil Peytchev (Aug 29 2021 at 16:26):

I don't think it can be universally assumed that "at time of order" is the only, or even the best suited trigger point. There are systems that allow pending, multi-step order signing, and probably other mechanisms, where the trigger point can be executed.

Lloyd McKenzie (Aug 29 2021 at 18:59):

The hook points we have defined are "order-select" and "order-sign". My point is that it's common for prior authorization to happen after the order is signed - and once signed, there isn't going to be a workflow point in a standard defined hook that would allow the relevant decision support to be triggered.

Vassil Peytchev (Aug 29 2021 at 19:24):

What I was thinking about was:

Order sign - DS trigger
As result of DS, order is pended/moved to a work queue, or something else
Order sign - DS trigger again
Etc. - repeat as needed.

Lloyd McKenzie (Aug 29 2021 at 19:35):

But the order can't necessarily be 'pended'. Simple case of a prescription, the order needs to be signed, printed and handed to the patient before they leave, even if the prior authorization work will be done by someone an hour later.

Josh Mandel (Aug 29 2021 at 20:36):

So in these cases the EHR would not offer to defer. I have a feeling EHR developers could discover the heuristics pretty quickly to optimize this experience. It's what they do!

Lloyd McKenzie (Aug 29 2021 at 21:37):

Right. But the EHR still needs to hold onto the SMART app link so the prior auth can be done later. The question is whether that should be handled by the EHR (my preference) or be one of the options on the card (which results in a less-satisfactory user experience because the user then has to go in to manipulate that Task queue to establish ownership, priority, etc.)

Josh Mandel (Aug 29 2021 at 21:42):

Perfect. Is anyone arguing for "options on the card"? Reviewing the thread: Lloyd, Vassil, Frank, and I aren't, as far as I can tell.

Lloyd McKenzie (Aug 29 2021 at 22:01):

If we don't have "options on the card", then we need "functionality in the EHR" - and I haven't heard arguing for that either...

Josh Mandel (Aug 30 2021 at 02:13):

No matter how it is integrated, this feature requires buy-in from EHRs.

Bas van den Heuvel (Aug 30 2021 at 07:18):

Just a thought, this is something the CDS service initiates and tracks, if the CDS service knows the data is still pending, can't it just present a new card when patient-view is called again?

Lloyd McKenzie (Aug 30 2021 at 16:07):

Looking up a patient and having it flag that there are 20 potentially active orders for which prior authorization might be required doesn't seem super-friendly to me. There wouldn't be a good way to track which ones the patient's decided to pay out of pocket or has gone through the steps already and determined that prior authorization wasn't required, etc.

Frank Pandolfe (Aug 30 2021 at 17:24):

I think this is a really interesting use case to think about. It seems to involve a task (filling out a SMART on FHIR questionnaire) that is triggered in a synchronous workflow. However, if the filling out of the form does not happen in the expected workflow, it crosses over into an asynchronous workflow. How do we hand off the responsibility from CDS Hooks to something else?

Lloyd McKenzie (Aug 30 2021 at 17:53):

That's exactly the question.

Josh Mandel (Aug 30 2021 at 18:49):

What is preventing EHRs from implementing or experimenting with UX options here, without CDS Services having to do anything special?

Frank Pandolfe (Aug 30 2021 at 18:54):

Then we're back to the beginning.

Lloyd, it seems as though you initially suggested that a card should return an option to create a task. A task meaning an asynchronous process for a user to go back and fill out a SMART on FHIR app.

Where do propose that the infrastructure needed to create a task lives? Is it part of CDS Hooks? Part of the client responsibility?

I also think the solution to this likely lives on the client side. I'm not sure what additional functionality you would like CDS Hooks to supply in order to make the workflow happen.

Lloyd McKenzie (Aug 30 2021 at 21:22):

The Da Vinci requirement is that when a card is returned, the provider needs to be able to assign it to be dealt with later (by themselves or someone else). One approach to do that is to have a card return an action that creates a Task. However, it's cleaner if the CDS Hooks implementations just generically allowed that functionality because they could then do things with the UI (assigning owner, timeline, priority) that couldn't easily be managed with a CDS Service initiated Task. While EHRs could just choose to implement deferral and assignment of cards for subsequent handling independent of the CDS Hooks spec, it seems like something the CDS Hooks specification should speak to at least a little bit:

to say that it's possible (or even recommended)
to provide guidance about the types of cards that make sense to allow deferral of vs. not - if such guidance can be provided generically
to talk about implications for card feedback
to talk about implications for launch context duration (as mentioned by Josh earlier in the thread)
to consider whether cards should be explicitly be marked as 'appropriate to defer'
maybe other things

If the EHR community says they're happy to start addressing deferral of cards as a generic process, then CRD will likely do nothing and allow that guidance to develop. If they don't want a generic process, then we'll proceed with defining the Task-based approach even though it's not as ideal.

Frank Pandolfe (Aug 31 2021 at 15:36):

I think there are two types Deferring.

short term defer. (i.e. still working in patient chart and want to dealt with CDS, just not now.
You mentioned: "Would you like to review ABC's opioid prescribing guidelines?" - "Yes, but not now".
I would view this as potentially a "snooze".
In terms of feedback, i think that snoozing is an ignore until the clinician "meaningfully" interacts with a card

i don't think this use case really is what you're asking about though.

longer term defer. - create a task and deal with it later.
To accomplish, I think this can be implemented with a suggestion that has an associated action that would kick off this workflow, as opposed to launching the app, then deciding what to do.
Launching the app with the correct context would be done in the secondary workflow
For feedback, it would show that a particular suggestion was taken.

I don't think the spec has to say anything additional in regards to say that deferring is possible or recommended or what type of cards make sense to defer. I think those are implementation details.

If you have other specific recommendations, I'd be interested to hear what they are.

Lloyd McKenzie (Aug 31 2021 at 15:47):

I'm not sure about how 'snoozing' would work when a provider is context switching between different workflows. A card can't very well "wake up" when the provider is now in a different workflow. And once a workflow is 'complete' (appointment booked, referral sent, order printed), the provider won't ever be "coming back"

I'm also not sure what the 'secondary workflow' would be in my case. Once the order is printed or the appointment is booked, if prior authorization is needed, what 'hook' would fire later on that would be appropriate to display the "fill out your prior authorization" SMART app launch? Patient-view would get super noisy and I can't think of another trigger point that'd be more specific.

Frank Pandolfe (Aug 31 2021 at 16:00):

I think case one is for the EHR client implementation to figure out

I think case two is for the secondary workflow to figure out (something like a task manager that we've discussed). Once the CDS hooks service has displayed the card and the clinician has taken action, from the CDS Hooks workflow perspective, the service has done its job. end of story. that means there is no longer a "hook" to call. CDS Hooks service has completed and and now it is up to that other process to figure out.

Lloyd McKenzie (Aug 31 2021 at 16:02):

I agree the hook service has done its job. However, the 'card' may still need to be dealt with. If a card is acted upon 2 days later, you presumably still want to know that in 'feedback'. We can't presume there's going to be another workflow that's going to trigger the same card.

Frank Pandolfe (Aug 31 2021 at 16:37):

the card has been dealt with. and the "same card" doesn't need to be triggered. The function of the "card" you want dealt with as a follow up is the clicking of a SMART on FHIR app to fill out the pre-auth. not anything else to do with the card. It is this secondary workflow outside of CDS Hooks that somehow indicates a pre-auth still needs attention. If it is launching a SMART on FHIR app, that can be done outside the context of CDS Hooks.

Lloyd McKenzie (Aug 31 2021 at 16:55):

A card has been provided. The user doesn't want to act on it yet, but does want to act on it in the future. The "closed loop" of the feedback mechanism should indicate that it's been acted on when it eventually is. The card might be to launch a smart app, but it could also be to create some other order, to read a PDF or to do various other things. Any one of those might be something the user wants to "do later" or "get someone else to do later". And we can't count on the workflow that led to the original card being repeated to retrigger the card.

Lloyd McKenzie (Aug 31 2021 at 16:59):

That seems to me to be something that CDS Hooks can/should speak to

Frank Pandolfe (Aug 31 2021 at 17:09):

"The user doesn't want to act on it yet" - This is the definition of "ignore"
"The "closed loop" of the feedback mechanism should indicate that it's been acted on when it eventually is" - it will, if the card is re-triggered

"We can't count on the workflow that led to the original card being repeated to retrigger the card" - i disagree

Lloyd McKenzie (Aug 31 2021 at 17:13):

Ignore can be three substates - I don't care now and I never will; I care, but I'll deal with it later; I care and I'll get someone else to deal with it later. What, specifically, does the user need to do to ensure that when later comes, they can still act on the information, or put the action in someone else's queue to address? How is the workflow that led to the original card being triggered (e.g. creating an appointment) going to get re-triggered once the appointment is made? I've heard assertions that it's possible. No one has yet explained to me what the user would do in the EHR interface to make it happen.

Frank Pandolfe (Aug 31 2021 at 17:24):

for cases two and three... you are trying to shove an asynchronous workflow into a synchronous protocol.

see what i said above:
longer term defer. - create a task and deal with it later.
To accomplish, I think this can be implemented with a suggestion that has an associated action.

that action creates a task that guides the user to do something

Matt Varghese (Aug 31 2021 at 17:30):

In the real world, a prior authorization questionnaire won't be filled out in a single pass. Provider staff would want to open the app, fill some details, save that. Review the chart / call the patient, gather additional information, open the app again, fill more details, repeat.. Even passing the baton among multiple staff. Likewise, even after the questionnaire is filled out, there may be a desire to review the data before PAS submission.

So CDS Hooks having the ability to defer will only address the first iteration of this. And therefore, I can't see CDS Hooks being the right place for this.

Whereas, what is really needed is a repeatable ability to open the SMART App. I personally don't know how this is going to be covered in "standards" for interchange of data. This is workflow, and the EHR will have to store off the SMART App URL understanding it is a prior authorization app, and allow the app to be launched multiple times ?

Lloyd McKenzie (Aug 31 2021 at 17:55):

The foundation of CDS Hooks is indeed synchronous. But the foundation is also solving real-world issues. And if it turns out that some of the real-world problems involve the synchronous response needing to be handled asynchronously, that seems like something the standard could address. (And in my opinion, should address.)

I'm happy for the outcome to be a Task. The question is how do we set an expectation that the user can right-click (or perform some other EHR-specific gesture) on a card to create the Task, including being able to fill in details like owner and timeframe? Also, what's the best way for a Task to represent what's in the card? Both of those questions seem to me like things that CDS Hooks could address. If those questions are asked, then the process of launching (and re-launching if necessary) the SMART app could absolutely be managed outside the boundaries of CDS Hooks. (As could later instantiation of a suggested order or launching a browser to read a PDF during a slower period of the shift.)

Bas van den Heuvel (Sep 01 2021 at 07:22):

I'm getting a bit worried about the statement "I'll deal with it later". I do see value in asking the EHR to something at the practitioners convenience, but whether this is possible (and safe) highly depends on the advice that has been given. The advice is given based on the data available when the original call has been made. Any change in the clinical data may invalidate the advice and could result in an unsafe/dangerous advice. In the case a advice has not been acted on or completed. A re-run of the CDS service would allow the CDS service to decide what the appropriate advice is at that point in time.

Frank Pandolfe (Sep 01 2021 at 14:07):

the card will have an indicator field which will indicate the "severity" of the returned card. and the available suggestion presented to the user could be based on the indicator. It would be up to the person writing the card to help prevent unsafe actions.

This is another reason why the ability to "deal with it later" should be an action
https://cds-hooks.org/specification/current/#action
attached to a suggestion.
The card author write a create action with a resource object to create a new task.
This keeps ability to "deal with it later" within the control of the card author.

Maybe we can come up with some best practice guidelines around how to do this.

Lloyd McKenzie (Sep 01 2021 at 15:05):

The problem with using an 'action' is that there's no way to capture who should action, when it should be done by or priority. It also means that the provider is dependent on the CDS service providing the 'defer' option. However, if that's the preference, we can go that way. It would still be good to have guidance on how best to represent different types of cards in Task.

Gino Canessa (Sep 01 2021 at 15:41):

Frank, I think Bas was concerned about race conditions, e.g.:

a practitioner defers a card that had "ok to prescribe medication X"
in the time between issue and when the practitioner actually views the card, new medication Y has been added which makes X unsafe

Unless the practitioner is guarding against noticing that the card is out of date (and practitioners have enough to be worrying about), they will think it is safe when it isn't.

My quick read of what Bas is suggesting is that when the practitioner comes back to the card that was deferred it should be refreshed so that contents are current.

Josh Mandel (Sep 01 2021 at 15:50):

Today, each CDS invocation is associated with a hookInstance UUID. If an EHR wants to support some kind of "do this later" workflow, it can keep track of the CDS invocation associated with a deferred card and re-run them later, with updated inputs as needed. I agree with Frank there are probably some "best practice guidelines" we can develop here, but those will come from trying things out in prototypes. We've got a lot of good building blocks.

Frank Pandolfe (Sep 01 2021 at 16:54):

Gino,
I would agree that we want to prevent those types of conditions from occurring. That's also why it's a good idea to be able to control what actions are able to be taken within a card by the card author. If deferring a medication prescribe is a bad idea, which it probably is, then it shouldn't appear as a potential suggestion.
As Josh suggesting the UUID can help keep track and re-run the service.... and prototypes will certainly help clarify the limitations and best practices.

Lloyd McKenzie (Sep 01 2021 at 17:07):

I think it's hard to determine that 'deferring' is a bad idea. If decision support recommends prescribing a companion drug, but the patient has a vague recollection that they may have tried it in the past and had a reaction but isn't sure, then deferring the companion until you can contact the other provider or have time to do more digging or whatever may be reasonable. CDS services will typically feel that their actions are important and should be dealt with right away. I think that in general, the choice should always be up to the users. If they want to defer something, they should defer it. (I do like the notion that the deferred 'task' contains the information to re-trigger the decision support rather than re-launch the action, such that if the context has changed, the recommendation might be different.)

Josh Mandel (Sep 01 2021 at 17:11):

EHRs can today try things like letting administrators manage a table of

Card `source.url`	Card `source.topic`	Okay to defer?	Need to re-execute?
https://service1.example.org	`prior-auth`	true	false

... and use this to drive downstream workflow. Over time, we might realize we need some extensions in cards to make the logic more robust; those an feed into the spec.

Matt Varghese (Sep 02 2021 at 03:32):

I want to cite this other zulip thread here: https://chat.fhir.org/#narrow/stream/180803-Da-Vinci.20CRD for context.

As I see it, this desire to defer is coming in response to to underlying workflow problems in the CRD spec. I don't think making a bunch of hasty modifications to CDS Hooks to make up for workflow insufficiencies in the CRD spec is the right thing to do. We should really think through the CRD spec better to make sure it matches real world workflows, and does not burden providers with what was previously back end staff responsibilities.

Especially given that the NPRM to regulate CRD has been repealed, I would personally prefer that the CRD spec be given more careful thought with good insights from how workflows actually exist in the real world, rather than trying to bend the CDS Hooks spec to make the CRD spec work.

Lloyd McKenzie (Sep 02 2021 at 04:44):

I don't see how that thread is relevant to the current question. Yes, having an additional hook point might be useful in some workflows, but the need to be able to defer cards (all sorts of cards) is generic. I provided a couple of examples of non-CRD-related situations (reviewing a PDF, submitting a companion order) where deferral would also be useful. Even if there was a hook point for "fulfill order" (no one ever submitted a change request), that wouldn't eliminate the utility of the hook on "order select" or "order sign" nor would it mean that deferring the card wouldn't sometimes still be relevant in any of those three hook points.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Deferring cards · cds hooks

Stream: cds hooks

Topic: Deferring cards

Lloyd McKenzie (Aug 26 2021 at 14:47):