Stream: cds hooks
Topic: Configuring Hooks
Lloyd McKenzie (Jul 30 2018 at 05:05):
DaVinci plans to use CDS Hooks as part of the solution for its Coverage Requirements Discovery use-case. This means passing information from a payor to the clinician when they're about to undertake some sort of action that is potentially related to their coverage. Possibilities include requirements for pre-authorization/availability of pre-determination, templates/forms to fill out, rules to follow, required first-line therapies, etc. One of the requirements we'd identified before settling on the CDS Hooks approach was the need to give the EHR some sort of control over what sorts of information they wanted back from the payor - did they only want pre-determination info? Only rules info? Only reference info? (We have a total of 8 different types of information that a payor could potentially pass back.) The question is if/how it's appropriate to replicate this in the CDS Hooks space.
One possibility is to say that the payor needs to set up a separate hook for each type of information it might pass back (with the presumption that either the EHR, or possibly the user) would have the ability to configure which hooks are turned on or off. However, that's rather inefficient. You'd be hitting the payor server up to 8 times and much of the processing would be common to all of the types of responses. An alternative would be passing a 'configuration' object as part of the hook invcocation. The service declaration could indicate what configuration options are available. The EHR and/or user could determine what the configuration settings should be and the service would look at the passed configuration object in deciding what to do. Configuration options could include simple booleans to turn certain checks/response types on or off. However, they caould also do things like set a max number of responses of a particular type or possibly other things.
It's certainly possible for the EHR to do some filtering of responses by card type, but if a lot of the cards are different types of information messages or links, that wouldn't help much.
Isaac Vetter (Jul 30 2018 at 05:11):
Hey Lloyd, a hook is an EHR user's workflow event.
If the provider and the payer are pre-configuring the response, why not have the payer set up different services for the same hook that return different responses?
Lloyd McKenzie (Jul 30 2018 at 05:39):
The payor could set up different services - but it means that the EHR is then invoking 8 services rather than one, and the payor is performing a lot of the same logic on each invocation (figuring out who the patient is, what their coverage is, grabbing extra information from the EHR to decide which specific rules apply). So it's less efficient than a single configurable service. Obviously the price is adding the complexity of configuration.
Isaac Vetter (Jul 30 2018 at 16:07):
Hey Lloyd, a way to do this within CDS Hooks would be to specify the "configuration" in the pre-fetch, maybe as one of more Parameters?
But specifying configuration dynamically on the request is more power and complexity than appears to be needed.
The provider determines the "information types" they want returned during implementation, not dynamically at run-time, right? Why isn't the payer keeping a mapping table of provider to information type and only ever using the same service?
Lloyd McKenzie (Jul 30 2018 at 16:21):
I think the notion was to allow the user to have some control over what they wanted back. It's more useful in the "I'm thinking about doing X and wondering if pre-authorization is required" scenario than "I'm ordering X, what do I need to know?" scenario. In the former, you might have specific questions you're interested in the decision support engine's ideas about. In the latter, you'd typically want to have the same behavior all the time - though you could want that behavior to be user-specific. E.g. provider A doesn't want to see the "reference" links from service 1 because to them they're noise, while provider B using the same EHR might find them useful. It'd make a lot more sense (and be more responsive) to maintain that in the EHR than to have the payor maintain that linkage.
Kevin Shekleton (Aug 01 2018 at 11:59):
This to me sounds like it is organization specific build/configuration that is agreed upon between the payer and hospital as to what data they want to see and when. Right now, this has been handled outside of the CDS Hooks conversation.
Lloyd McKenzie (Aug 01 2018 at 14:23):
Handled how? If the hospital wants to be able to invoke the hook and receive certain information sometimes but not other times, how do they communicate that? They could theoretically filter out certain cards, but there's nothing on a pure information card that lets you know what 'kind' of information it's presenting that would allow you to suppress certain types of information but not others. (And you'd be incurring the overhead of doing the decision support to generate a card that's not wanted.)
Kevin Shekleton (Aug 01 2018 at 16:29):
I don't think I understand the ask well enough here and I don't have experience with such dynamic behavior for a single service (in the context of CDS Services).
Is there a specific ask from the payer service community to offer this type of flexibility or is this requirement being created to ensure the solution allows for this type of flexibility if needed?
Last updated: Apr 12 2022 at 19:14 UTC
