Stream: Da Vinci CRD
Topic: CDS Hooks for CRD
Joseph Sadlon (Jul 26 2021 at 20:51):
Hello, I'm with an EHR working through an integration using the CRD specs and one of the issues is what hook should we us to call the payer. One clear choice is to use the order-select hook and make that call several times during the ordering workflow while the data required to determine prior auth is entered. We could then also use order-sign when the order is to be signed. However, in our system it is very common that all the information required for Prior Auth is not entered on the order until after the order is signed (e.g. place of service, date of service, rendering provider). Ideally, we would need to make CDS requests several times pre order sign and post order sign until all the required information is entered on the order. Are there any suggestions as to what CDS Hook to use when we need to make several calls post order sign?
Lloyd McKenzie (Jul 26 2021 at 22:50):
If you were only going to support one hook, the best would be order-sign. The notion with order-select is that sometimes payers will have information that's useful earlier in the process (e.g. drug X isn't covered, but drug Y is; or there was an x-ray of that body part done 3 days ago, here's the id). Ideally, you'd support all of the hooks so that booking appointments, discharge plans, etc. would all provide payer information if there is any.
Joseph Sadlon (Jul 27 2021 at 15:23):
Thanks @Lloyd McKenzie. Based on our workflow ideally we need to support two CDS Hooks. One for pre order sign and one post order sign. The idea here is since order information required for prior auth is entered sometimes before the order is signed and sometimes after the order is signed. We will also need to make several pre order sign and several post order sign requests as the data is being entered. Our thought is that using the pre order sign and post order sign hooks would allow the service to know where is the ordering process the request is coming from.
That said, the problem we have is there is no post order sign CDS Hook that can be called multiple times similar to order-select. I would look to see if this scenario has come up before and there is guidance or if we are the first to come across this use case.
Lloyd McKenzie (Jul 27 2021 at 15:29):
I'm having a bit of trouble understanding what you're trying to do. The objective with CRD is that - as a clinician is going through the ordering process, payers can provide useful information - including potentially an indicator that prior authorization is required and/or a link to a SMART app to gather relevant information. Once the order is signed, it's signed. There shouldn't be any further need to call CRD at that point. By the time you get to signing order, you'll absolutely have enough information filled in to allow the payer system to determine whether prior authorization is needed or not. There's no expectation for you to keep calling CRD as you go through the prior authorization process - that's what DTR and PAS are for.
Joseph Sadlon (Jul 27 2021 at 15:43):
Let me try to explain in better detail. The service we are working with requires certain information to determine if prior auth is required or not. That data includes items such as the place of service, the provider/organization who the order is being sent to and will render the care, the date of service. In our system a provider is not required to populate all of this information prior to signing the order and back office staff can populate this information.
For example, a provider may select an order for an MRI but not know where the patient will ultimately have the MRI done. The provider is able to sign the order leaving this information null. If we were to make a CDS request to the service at this point in time the service will not be able to determine if prior auth is required or not since the provider/organization who the order is being sent to is unknown.
The order is then picked up by the practice's back off staff who will discuss with the patient where the MRI will be completed (e.g. MRI of New England). The back office staff will populate that information on the order and submit the order to that organization (e.g. MRI of New England). This is post order sign and at this point we have all the data the service requires and we should make the CDS request at this time and the service will respond if prior auth is required or not.
Does this clarify?
Lloyd McKenzie (Jul 27 2021 at 17:05):
If there isn't enough information in the order to determine whether prior authorization is required or not, then the best you can do is submit a card saying "prior auth may be needed, click here to launch a SMART app to figure it out" - with the knowledge that responsibility for launching the Smart app may be delegated to admin staff and it might not be launched until after the order is out.
The notion of having a hook at the "submit order for fulfillment" endpoint is certainly something that could be considered for a future version of CRD. It would presumably pass the 'Task' that was seeking fulfillment of the order. You could propose that as a change request to CRD - and also to CDS Hooks as it would be a new type of hook.
Matt Varghese (Aug 31 2021 at 17:55):
I can confirm that what @Joseph Sadlon mentions is the frequent case workflow in our EHR as well. CRD as written therefore risks moving back office staff tasks onto the provider, which is actually going to burden, and not unburden the provider. This was one we were also trying to work around when there was the risk of regulation requiring CRD, but now that the NPRM has been pulled, we should probably address these kinds of things in a more systematic way?
Joseph Sadlon (Sep 02 2021 at 17:19):
Hi @Matt Varghese happy we are not the only ones with this issue. While we have not formally submitted this proposal to CDS Hook or DaVinci we are thinking we would implement an 'order-signed' hook. This hook would operate in a similar way as the order-select hook in that it can be triggered multiple times during a workflow, most notably when additional data points are added to the order. This hook would trigger after the order is signed but would no long trigger once the order is submitted. Our thought is this would allow the CDS service know where in the workflow the use is in as well as inhibit the hard stop that using order-sign would put in place.
Therefore, with this implementation the CDS Service would continue to get CDS requests, for CRD, at multiple times while the order is being selected as well as multiple times after the order is signed. The use on the CDS Client side will be provided guidance throughout the ordering workflow and would be able to decide at what point during the ordering workflow they would like to engage with the SMART on FHIR app and continue the authorization process. Once the order is submitted, we would stop making requests to the CDS Service.
One consideration we have not worked though and would love feedback is if the CDS Client should continue to make CDS requests after the authorization process is complete. From the CDS Client point of view, we would want to continue to make CDS Hook requests and not have to care if authorization is complete. Building functionality to inhibit CDS calls once the authorization is complete would be a custom use case implementation, which is what we want to avoid. We would expect the CDS Vendor to dictate if they need to respond to a CDS Hook request and if the authorization is complete, they would not populate any additional guidance or cards in the response. Interested if the thought process here is just.
Matt Varghese (Sep 07 2021 at 18:44):
Hi @Joseph Sadlon , yes, we're most definitely not the only people affected by this - I'd imagine everyone who tries to implement the CRD spec from the role of an EHR will run into this.
I would worry that "order-signed" would become a difficult to define hook? I am not sure there is cross EHR commonality about what constitutes "additional data points are added to the order"? So, when would such a hook be triggered would be rather nebulous to determine? The concern you bring up about this hook firing after we have authorization is one example case of this nebulousness?
Some part of me is tempted to suggest a prior-authorization-check hook or something like that specific to CRD. Note that one purpose of the hook in CDS Hooks is to define the context. So such a CRD-specific hook would require coverage information, service performance information etc. That said, my own reservation about it is whether that would be too "use-case specific" a hook, and would overlap with other hooks / workflow points? Note however that from a practical point of view, such a prior-authorization-check hook would be doing exactly what you're trying to do with the 'order-signed' hook (?)
Personally, I think this is an example of something that should be discussed between both the CRD community and the CDS Hooks community, since it does bring up some questions about what a hook is?
Lloyd McKenzie (Sep 07 2021 at 19:47):
The CRD project introduced a number of new hooks to CDS Hooks to specify additional workflow 'steps' we wanted to tie into (e.g. appointment book, patient discharge, etc.) However, we didn't attempt to introduce new hooks into the 'order' workflow space as we assumed that the existing hooks would suffice. We can certainly look at adding more (e.g. Seek order fulfillment) if needed.
I wouldn't be a fan of a prior-authorization-specific hook as that's targeted to the type of decision support you're wanting, and my understanding is that hooks are supposed to be independent of the type of decision support that might be needed. That said, in the end it's sort of up to the EHR community to agree on common workflow points that can be described and triggered consistently across the different EHR platforms.
Bharat Nadimpalli (Sep 07 2021 at 21:53):
One of the challenges with using CDS cards for CRD documentation is that cards ultimately cannot and do not force user interaction. In case of CRD, documentation gathering process is a mandatory step (DTR) to completing the overall prior auth process.
A key goal for several EHR workflows is to reduce provider documentation burden when appropriate.
I wonder if there is a case to be made for vendors to send back “tasks”, similar to systemActions (Sep 2020 ballot) to indicate work to be completed either by the user/provider, or later in the workflow by a back office staff person.
Lloyd McKenzie (Sep 07 2021 at 22:43):
There's no expectation of forcing user interaction. They're free to not use the SMART app and ignore any message provided. If they want, they can phone or fax to see if prior auth is required and follow all the processes they have now. However, if the user wants a card acted on, but they want it done later, there should be a mechanism. And note that this isn't a prior-auth specific issue. If a CDS Hooks service says "here's guidelines for prescribing X", the clinician might well be interested in reading those, but perhaps not right now when they're with the patient. Sure, they could go in and 'pretend' to prescribe that same med in the future to bring up the link again (if they remember), but it seems better to be able to right-click or something on the original card and say "add to my to-do list".
Bharat Nadimpalli (Sep 07 2021 at 23:19):
I agree. However, there are two possible issues to be addressed with this approach. They aren’t insurmountable, but are worth thinking through -
-
The liveliness of the smart app links is uncertain. An auth token is almost certainly likely to expire by the time the app is opened the next time.
-
If the link could somehow be opened at a later point of time, it’s no longer in the original context and with some workflows, it’s not the same user.
Another option would be to support a GET against a hook ID to be able to retrieve a previously issued guidance, but that’s an undue burden on the vendors.
Lloyd McKenzie (Sep 08 2021 at 01:51):
Well, the auth token is determined by the launch of the SMART App - it's granted at launch, not by the hook. Granted, it's theoretically possible that the link passed is time dependent and might not work in the future, so it'd be useful to know if the app was 'deferable'. Some would, some wouldn't. The fact some wouldn't certainly doesn't mean it's not a desirable feature for those that are. For other cards where you're just hitting a link, presumably that wouldn't be an issue. Certainly if you're going to store a card for later launch, you'd also want to store at least some of the context for the card - presumably the context that was used to launch the hook originally. Agree that the user would be different. If assigning to a different user would break the app, then so be it. In general, if it makes sense for a user to delegate, the app should probably be designed to be delegateable.
Last updated: Apr 12 2022 at 19:14 UTC
