Stream: Da Vinci CRD
Topic: CDS-Hooks card with alternate flow
Viet Nguyen (Feb 13 2020 at 19:15):
@Isaac Vetter would it be possible for a CDS-Hook card or maybe the DTR smart app to return an option delegate the completion of the information gathering and PAS process to another person, like a office staff member or medical assistant? Office staff is often involved in prior auth. I'm going to cross post this on Da Vinci DTR.
Lloyd McKenzie (Feb 13 2020 at 20:33):
In theory, that's what Task would do. Once a Task is created, you can assign it to others, create a time-frame for completion, etc. However, support for external manipulation of task lists isn't yet something widely supported in most EHR software.
Isaac Vetter (Feb 18 2020 at 23:09):
Hey @Viet Nguyen , Lloyd -- apologies for the super delayed response. I think Lloyd sums up the current state of it well. I, personally, think that delegation of administrative tasks away from the clinician is so important that we oughn't be limited by current state. I've even said exactly this in negative ballot comments (I think a few times, but I can only find one).
Isaac Vetter (Feb 18 2020 at 23:09):
Overall, the potential for increasing provider burden is pretty significant in CRD/DTR.
Viet Nguyen (Feb 19 2020 at 00:41):
We certainly don’t want to increase burden. What’s the best (or available) paths forward? Does Epic have the ability to assign tasks to others in a practice? I can check with the other vendors too. I’m thinking the DTR Smart app would have to save the session and and maybe know to whom the completion was delegated. The host EHR would assign the delegation (via Task resource or inherently). The person delegated the task would have to resume the session in smart app and complete the DTR process. I think this would happen when Clincial notes or lab data may not be available when the DTR app was launched.
Isaac Vetter (Feb 19 2020 at 01:48):
The general concept of a back office work queue is very widely implemented in epic. I'd think that any prior auth workflow that resulted in something other than a yes, should be moved to a work queue. Relaunching the Smart app with a different user and the same appContext could reasonably enable this now.
Lloyd McKenzie (Feb 19 2020 at 02:19):
@Isaac Vetter How could you tie into that back office work queue with the FHIR resources and card types available?
Viet Nguyen (Feb 19 2020 at 17:28):
@Dennis Patterson @Jeffrey Danford - Would you please take a look at this discussion and weigh in from the perspectives of Cerner and Allscripts? The ability for the EHR to support delegation and alternate workflows that are initiated by CRD/DTR would help address concerns raised about workflow. I'm just not sure where the SMART/CDS-Hooks/FHIR parts of CRD/DTR fits in with native EHR functionality.
Jeffrey Danford (Feb 22 2020 at 17:13):
@Viet Nguyen Allscripts has the ability to assign tasks (not yet FHIR Tasks) to individuals and groups. Agreed this should be functionality supported in CRD/DTR. In Allscripts the CRD task is typically delegated to a nurse or a nurse group. They do their thing then the assign the task to the provider to sign it. The workflow may also be iterative, i.e. the task moves back and forth between the recipients depending on what's required at a given point.
Patrick Haren (Feb 22 2020 at 17:29):
Yes, I think if there's a way to queue or assign the smart app link (along with appcontext), from the cds card, that would provide options for alternative flows (like front-office staff actually performing the PA flow)... Having the feedback on 'is it covered' and the estimated patient cost would still be possible (when keeping the cds info), while we also streamline the flow into PA process, if required... I think that would be a good balance.
Patrick Haren (Feb 22 2020 at 17:30):
It could be a function of the EHR (in terms of functionality to support a smart link) without needing any additional interoperability specification
Isaac Vetter (Feb 27 2020 at 04:52):
(Lloyd, Viet -- apologies for the delayed response).
I, independently, came to the same conclusion as Patrick. A returned card could easily be re-displayed to a different user (preserving appContext, but perhaps not suggestions).
Isaac Vetter (Feb 27 2020 at 04:52):
A CDS Hooks card is simply a task. The ability to defer it by the user seeing it to another user is merely a capability of the CDS client -- which doesn't require an interop spec.
Isaac Vetter (Feb 27 2020 at 04:52):
The CDS Service could provide additional value by indicating when a card would be most appropriately deferred. This would require an interop spec. We could achieve this in a few different ways, including:
- return no card to the current user and POST a Task resource to the CDS Client
- markup the card to indicate to the CDS Client that it's deferrable, either through an extension or a standard element
Isaac Vetter (Feb 27 2020 at 04:52):
It's unclear to me how a CDS Service would know when a card is appropriately deferred to another user.
Lloyd McKenzie (Feb 27 2020 at 06:04):
It should be possible to know whether the task is appropriate to defer to another time. Anything that can be done 'later' could also potentially be done by someone else. And any mechanism that allows persisting something as a "remind me later" wouldn't need much tuning to swap the "me" for "some other person". Actions like "look at this guideline" or "switch to this med" when prescribing don't make much sense to defer. "Fill out this form before submitting a prior auth" would be fine to defer.
Lloyd McKenzie (Feb 27 2020 at 06:05):
However, the way we say "please fill out a Questionnaire" is still by creating a Task, so not sure how the card would get around that
Isaac Vetter (Feb 27 2020 at 06:05):
please launch this SMART app, is the same as please fill out this Questionnaire, right?
Lloyd McKenzie (Feb 27 2020 at 06:10):
There's a specific card for "launch this SMART app"
Lloyd McKenzie (Feb 27 2020 at 06:10):
"fill out this questionnaire" doesn't necessarily mean there will be a SMART app in play.
Dennis Patterson (Feb 27 2020 at 15:30):
This is a great topic that I'm finding to be more and more prevalent in connectathon discussions. In Sydney there was a use-case of having a CDS Service create a task / todo / inbox message for a practitioner to deal with once they logged back in. For non-critical decision support, this could be appropriate. Or, these services may be asynchronously listening for FHIR subscriptions notifications (rather than hooks) and want to then create work or an inbox message for a practitioner in a similar manner.
There's overlap in this thread with deferred work concept, with the added element of delegation. Both hinge on what API is called to create the deferred work. Cerner has a task model which isn't exposed currently in our FHIR implementation. Beyond the Task resource, I'm curious if the Communication resource would be applicable in some of these situations. Either could be consumed by the CDS Service or the launched SMART App, depending on workflow.
As for message contents, deferring a card itself could work, but other situations may call for another practitioner to open's a patient's chart and re-trigger patient-view to allow the CDS Service to re-assess current state.
Lloyd McKenzie (Feb 27 2020 at 16:40):
One of the challenges with persisting 'cards' rather than FHIR resources is that there'd be no ability for subsequent CDS calls to query to check whether there's already a "to-do" on file (and thus avoid creating yet another one). Using Task for this would make the to-do list queriable and potentially manipulatable (changing priority, timeline, etc. as a card action).
Last updated: Apr 12 2022 at 19:14 UTC
