Stream: Da Vinci CRD
Topic: Adequacy of CDShooks in achieng CRD goals
Sreekanth Puram (Sep 16 2021 at 03:59):
Based on a long discussion in the burden reduction track today got me thinking about the purpose of CRD. If we roll back to 2018 when we started on this, the primary purpose of having CRD is to solve the following problems from a provider point of view( I am purposefully not using specific terms to keep the discussion more at the problem level and not pondering into the existing specification and the solutions provided there.)
- Is prior authorization necessary for the treatment option that I am committing to?
- Even if prior authorization is not needed, is there any payer mandated documentation requirement that I need to comply with so that when there is a pre-payment or a post-payment review from the payer, I can use this documentation.
- If I am an ordering provider, how do I know what documentation may be needed by the payer which only I can answer even in the case when a rendering provider is making a prior auth request.
- How does the payer transmit the documentation requirements in such a way that the burden is reduced on the provider side.
- Different providers and payers have different ways of solving these problems currently and there is a need to come up with a single standard to maintain consistency.
We came up with CDShooks as a means to achieve the above. While it solves the problem of reducing the provider burden by integrating the prior auth process in the provider's workflow, the current IG based on CDSHooks adds additional restrictions and defeats the purpose of interoperability across payers and providers.
- CDShooks is a EHR-specific thing and is currently not a part of any practice management system and not a part of the EHR certification requirements. Some of the specialty-specific EHRs also do not support this.
- The CDShooks mandates the use of the smart app link if there are prior auth requirements thereby preventing the possibility of the EHRs implementing their own methodology to collect documentation based on the payer specified document templates and rules.
- Payer or their designated entity is now mandated to supply a smart app to interpret their rules increasing the possibility of non-compliance when running DTR.
So what is the way forward? I have the following ideas that we need to ponder upon.
- Abandon CDShooks and come up with a different strategy. But with so many implementations going on, this may be a weak suggestion.
- Modify the IG in such a way that we are not associating too much with CDShooks. We can still use the CDSHooks format for exchanging data so that we can integrate CRD into the EHR workflows. However, we modify the response format by mandating the use of either suggestions or system actions to pass on the payer-specific template and rule information and leave it to the caller to determine how they want to process the templates and rules.
Since It is already on the agenda for the next versions of CRD and DTR specs to plan for the standardization of app context, I would recommend thinking beyond app context and smart app link to figure out the methodology to pass on payer-specific documentation requirements to down stream processes like DTR. @Lloyd McKenzie @Larry Decelles @Robert Dieterle
Lloyd McKenzie (Sep 17 2021 at 00:01):
I don't understand the assertion that the current design defeats the purpose of interoperability.
CDShooks is in no way EHR-specific. It's implementable by any system that has a user interface with workflow points that could be used for hook invocation and where CDS would be supported. The fact that some EHRs don't support it isn't a reason not to use it as a foundational technology. The reality, is that the EHRs that don't support CDS Hooks also don't support anything else we could piggyback off, so they're faced with needing to implement something. If they implement CDS Hooks, at least it's not a one-off solution, but instead something they can use for lots of other purposes too.
It's not true that CRD mandates the use of a SMART app if there are auth requirements. Use of DTR is always optional. However, it is true that CDSHooks doesn't yet offer a mechanism for a card to allow invocation of an internal EHR function. The ability to even describe, reference and launch internal EHR functions is only now being defined as part of SMART-web-messaging. As well, the desire by EHRs to be able to do that is a new requirement - it wasn't expressed during the original design of CRD. We can potentially accommodate that using the CDS Hooks extension mechanism, or perhaps it is something that should be rolled into the base CDS Hooks specification. In either case, it's not a fatal flaw in the architectural decision to use CDS Hooks.
Each payer doesn't need to define their own SMART app. In fact, that's not even desirable. In theory, there only needs to be a single SMART app that could generically support the needs of all payers. The standard isn't about having custom SMART apps, it's about providing a consistent way of launching the SMART app (if both payer & provider support DTR), and providing a consistent way of passing the rules to a generic SMART app.
Obviously we need to explore further with those EHRs that want to be able to manage the rules process internally about what the best way to extend CRD to enable that. (When we embarked on this process, the objective was to minimize the amount of work EHRs would need to undertake, as most were already over capacity with other requests.) However, there's no reason why we can't find a way to do that.
It's not true that CDS
Sreekanth Puram (Sep 20 2021 at 14:19):
@Lloyd McKenzie It may not directly defeat the purpose of interoperability. However, the payers can make their DTR templates work only with their smart app. This may not be intentional but eventually may end up that way as they don't find a reason why it should work else where. I am not talking about the EHRs which don't support CDSHooks but am more talking about practice management systems and other applications which may not really follow any of the CDSHook work flows. The CRD server even though it is a CDSHooks endpoint, should support simple API request and response. The response that the current spec sends back is a link to the smart app and some cryptic data in the app context which can be read by the smart app only. Instead if the response is made in such a way that it can be processed by any downstream systems, it would serve the purpose of everyone. The EHR/Practice management system should take the responsibility of how they want to process the repose of the CRD instead of the payer dictating what to do.
The idea of having a single app for all payers makes it anti competitive. It would be difficult to maintain this single app and less "popular" payers, EHRs and providers don't get their specific requirements taken care of, I would prefer the payer send the information in the standardized format Questionnaire, CQL etc and leave it to the EHR/Provider to work in the way they want. CDSHooks should be a means to achieve what we are trying for, it should not be the limiting factor for what we can't do.
It is okay for the payer to send a smart app in addition to providing details about the templates and rules but the smart app should not be the only way for payers to communicate this information.
Lloyd McKenzie (Sep 20 2021 at 14:33):
The original interoperability objective was to easily connect provider and payer. There was no expectation that templates would be shareable across SMART apps, as both would be payer sourced. If a group of payers wanted to share a single app, they could. There was also no intention (or expressed desire) to have the DTR functionality performed internally within the EHR. In the next release of DTR, we've agreed to standardize the 'context' passed to the DTR smart app, such that the information shared by the CRD app will be the same regardless of the DTR app being launched. However, the card will still indicate which DTR app to launch, as CDS Hooks does not have an ability to provide a list of possible apps, nor would the CDS Server have access to a list of candidate apps. The ability to launch functionality within an EHR will require an enhancement of or an extension to the existing CDS Hooks platform to allow the CDS Service to
a) be aware that the EHR has the necessary functionality to invoke
b) pass back a card that allows invocation of that functionality
We'll need to work with the EHRs who want this capability to figure out how best to enable it.
Josh Mandel (Sep 21 2021 at 13:16):
CDS Hooks does not have an ability to provide a list of possible apps,
A service can return a set of cards to accomplish this today.
Sreekanth Puram (Sep 21 2021 at 15:39):
As I said earlier, we should not be limited by the capability of CDSHooks. If we are okay with the providers opening different apps for prior authorization, I think the current model is ok. However, I don't see it much different from the portal world except for the prefilling of the data. Also, the EHR vendors like Cerner and Eclinicalworks etc have a very long process in approving a smart app that can work in their system. They don't allow the launch of a smart app based on a link provided as a response CDS Hook call. Instead, if we leave it to the app vendors to work out the logistics with the EHR vendors the payers can focus more on the creation of standardized CQLs and questionnaires. If the norm for DTR is that it is opened through a payer-specific app, the payer does not have any motivation to maintain standardized CQL.
Matt Varghese (Sep 21 2021 at 18:57):
@Josh Mandel , CRD needs to be able to tag a particular App in the CDS Hooks response as the DTR App (vs. other apps being not relevant in that sense). This is so the EHR can save this App onto the referral, and launch it multiple times.
So the App is not a step in the interaction like CDS Hooks envisions, but really is DATA returned by the CRD Service that the EHR needs to record. See the second bullet point in this JIRA issue: https://jira.hl7.org/browse/FHIR-33961
Matt Varghese (Sep 21 2021 at 18:58):
Also @Josh Mandel , I am curious about your thoughts on this thread as well: https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/Can.20AppContext.20of.20one.20App.20be.20used.20to.20launch.20a.20different.20App.3F
Lloyd McKenzie (Sep 21 2021 at 23:01):
The requirement to launch an app multiple times is not CRD-specific. And - as already pointed out - EHRs require manual configuration of each supported app. It makes much more sense for the determination that "This is a CRD app and persistence would be a good thing" to be made at this configuration time than every time a link to the app is provided.
Matt Varghese (Sep 22 2021 at 13:41):
The CRD proposal cannot actually be reused by another use-case. In fact, if another use-case does the same thing, then both of them fall apart, since now we don't know if it's a CRD App or the other use-case app.
Matt Varghese (Sep 22 2021 at 13:43):
Not to mention, even now one of my concerns is that if there is a CRD App Link and a regular CDS Hooks app link in the same CDS Hook (even on different cards), the EHR cannot know without resorting to inspecting AppContext, which should actually be a black box to the EHR.
Josh Mandel (Sep 22 2021 at 13:44):
Just define a .extension.contextForCrdv1.2.2 structure?
Josh Mandel (Sep 22 2021 at 13:44):
(Or, whatever strategy of being explicit with the modeling.)
Matt Varghese (Sep 22 2021 at 13:45):
Almost everything in CRD really needs extensions. At that point, I ask this question: https://jira.hl7.org/browse/FHIR-33963
Josh Mandel (Sep 22 2021 at 13:46):
(I'm not up to speed on the CRD use case, so I don't have an opinion one way or the other on that -- I've just chimed in here on CDS Hooks design.)
Matt Varghese (Sep 22 2021 at 13:48):
Can I request that the CDS Hooks group take a closer look at the CRD IG?
Lloyd McKenzie (Sep 22 2021 at 16:43):
The EHR does not need to know that an app is a CRD app. It's just an app, like any other. There is a generic requirement that when a user is presented with an app during their workflow, they might want to be able to launch that app later - or have someone else do so. IF EHRs choose to support that and/or CDS Hooks is updated to support that, then CDS Hooks would take advantage of that capability. But it's not required for CDS Hooks to work.
It's absolutely not true that everything in CRD needs extensions. CRD developed a number of extensions, but none are CRD-specific and some have already been incorporated into the base spec:
- added support for R4 resources
- added support for some request resources that weren't covered by some of the defined Hooks. I believe these have now been added in the base hook definitions
- defined an optional configuration mechanism to give EHRs the ability to tune what kinds of advice they want from a service that can provide multiple kinds. I'm not sure if anyone has implemented this. If it turns out no one wants it in practice, we'll yank it
- added support for if-none-exist and rules for linkage between multiple created resources in cards. The first avoids race conditions and the second plugs a hole in the CDS Hook specification. Neither are specific to CRD and both have been proposed as enhancements/clarifications to the CDS Hook specification
The core of how CRD works - clinician starts ordering something and a card comes back either telling them information (service covered, service nor covered, prior authorization required, prior authorization required if filled out of network, etc.), giving them an option of changing what they're ordering, or giving them the option of launching a SMART app are all things that are standard CDS Hooks functionality. There is zero requirement to indicate that a launched SMART app happens to be a CRD SMART app. We have not proposed any such thing and are not in favor of that being the solution to "some users might want to deal with a card later rather than immediately".
Lloyd McKenzie (Sep 22 2021 at 16:44):
I know @Isaac Vetter went through CRD with a fine-tooth comb when it was first balloted and was generally quite happy with it.
Matt Varghese (Sep 22 2021 at 21:47):
@Lloyd McKenzie, it is reasonable to expect that the EHR may be able to retrieve the CDS Hooks card again either to the same user or to an administrator. However, with DTR, the card needs to be moved from the provider's workflow to a different non-admin staff person's workflow, not at provider behest, but by system knowing who to forward to - usually a pool. And the card needs to be kept along with the order that it is relevant to. These two are not generic CDS Hooks requirements. CDS Hooks (1) doesn't expect to go to a different user other than the user who saw it transferring explicitly and (2) CDS Hooks doesn't deal at the order level, but at the ordering session level.
Matt Varghese (Sep 22 2021 at 21:48):
It may be true @Isaac Vetter tried to find all issues back then. However, back then we were not trying to implement this yet, and so our perspectives were not as informed as now?. These are issues we actually ran into now that we are trying to implement this.
Lloyd McKenzie (Sep 23 2021 at 02:14):
First, there will be some information that generally should be captured in DTR by the clinician. Auto-routing the card to an admin person without giving the clinician the option of launching DTR defeats the purpose of CRD and DTR. We want the clinician to be aware of the additional clinical information and actions that need to happen at the time they're ordering when the patient is in the room. Auto-punting it to a staff person defeats this purpose.
If you want to know what apps are DTR apps, you can know that - Epic or any other EHR can capture metadata about any app they register, so if you want to implement special workflows for certain apps, you certainly can. The card deferral mechanism we're currently proposing (if it's initiated by the CDS service instead of the EHR) would leverage Task - and it's certainly possible for the Task to be owned by a Group or a 'type' of performer rather than an individual. That's also something that's potentially relevant for other types of delegation. E.g. Delegating to whoever the next attending happens to be rather than a specific individual.
It's true that CRD doesn't allow distinguishing which request a particular card is associated with. The text of the card can convey that to a human being, but it's not designed or intended to support this being done by an automated process. If there's a need to do this, then I guess we could look at putting an extension on the card. Again, it's essential that the card be presented to the clinician ordering and that they have the opportunity to act on it, not have it auto-routed elsewhere.
Last updated: Apr 12 2022 at 19:14 UTC
