Stream: cds hooks
Topic: Question about CDS Hooks Scope
Eric Haas (Oct 19 2018 at 04:08):
Discussion about CDS Hooks today led to this general question. Is hooks used outside of a single "patient view". For example if a drug is recalled could a practitioner get a card alerting her and listing all of her patients currently taking the drug? Apologies ahead of time if this is old hat... I have not been keeping up.
Vadim Peretokin (Oct 19 2018 at 08:04):
From my understanding it is for a single patient view indeed using the patient-view hook. For this usecase - sounds like it could be a custom hook.
Lloyd McKenzie (Oct 19 2018 at 14:12):
Hooks are tied into EHR workflows. They fire when users do particular things that make it appropriate to prompt the user "in-context". In the event of a drug recall, I'm not sure what the user-initiated workflow would be that would make sense in which to display an alert that applied to multiple patients. It might be best to handle that usecase by just sending an alert to the provider's inbox or something like this. Though perhaps it could be tied to a "user-sign-on" hook. (One important thing with hook messages is that they're not persistent - once you move past that point in the workflow, the messages are gone.)
Kevin Olbrich (Oct 19 2018 at 14:59):
There are use cases for decision support hooks on worklists that contain many patients, but that is a pretty large dump truck full of worms.
Lloyd McKenzie (Oct 19 2018 at 15:05):
Even then, the hook would be tied to the context of the worklist. It's unlikely that you'd have a worklist that represented "all patients on drug X" - or in the unlikely event that you did, that a practitioner would interact with it very often. And if no one interacts with it, no hook would trigger.
Kevin Olbrich (Oct 19 2018 at 15:11):
It might be more along the lines of 'patients I am going to see this week', but there is clearly a need for out-of-band CDS / alerts for things that change asynchronously.
Lloyd McKenzie (Oct 19 2018 at 15:51):
I don't see that as CDS. There's no "decision" that's being supported. It's just an alert.
Guilherme Del Fiol (Oct 19 2018 at 16:51):
We are currently investigating the use of CDS hooks as the services layer for population-based CDS that is not triggered by a user interaction with the EHR. Here is the workflow:
1) a population analytics client starts a population analysis process by retrieving a population of interest. For the target population, it retrieves data needed to verify if patients meet certain risk criteria.
2) For each patient, the population analytics client "triggers" some kind of "software invoked" hook and sends a CDS request to a CDS service passing the data in step 1 as prefetch.
3) The CDS service returns cards for each patient indicating whether or not the patient meet the risk criteria.
4) The analytics client populates a population-based dashboard with patients who meet high risk criteria (in our use case, patients who meet criteria for genetic evaluation of cancer risk based on family history).
I think a similar approach could be followed in the use case that @Eric Haas described. I know CDS Hooks was originally intended for user-triggered hooks within the EHR workflow, but so far we have not found a reason not to use it for population-based CDS. One big advantage is that we can use the same API for both individual-based and population-based CDS services.
Lloyd McKenzie (Oct 19 2018 at 16:57):
That approach only works if you have tight knowledge of the kinds of cards that are going to be returned. The hooks specification allows cards to contain any text the service wants - aimed at displaying information to a human user. The EHR doesn't get to dictate the contents of the cards and they're not terribly computable beyond knowing if there's a request to create or change resources. It sounds to me that your sort of using CDS Hooks as a transport for a custom method invocation.
Guilherme Del Fiol (Oct 19 2018 at 19:31):
Hi @Lloyd McKenzie, you're comment is right on. This is one of the architectural question we're facing. In our case, we do have control of both the population analytics client and the CDS service, so we can agree among ourselves what the output will be. But hopefully this could be something generalizable that can be standardized through a hook specification or IG that constraints what we expect in the card for these kinds of use cases. Our current though is to include a Communication and/or RiskAssessment resource in the CDS response card (this would be a part of the hook/card spec).
Lloyd McKenzie (Oct 19 2018 at 20:13):
This seems like something that is orthogonal to the CDS Hook spec. Why wouldn't it be more straight-forward to just define a custom operation?
Guilherme Del Fiol (Oct 19 2018 at 22:38):
I am not sure I understand what you mean by custom operation in this context, but by "custom" I read "non-standard". Analyzing and making assessments/conclusions about each individual patient in a population is a generalizable use case for a CDS service and could be supported by a standard services approach. The only difference is that this use case is triggered by a software rather than a user action in the EHR. The idea of prefetch/data requirements, a CDS request that fulfills the prefetch, and a CDS response that conforms to a standard format are still common in both use cases.
Lloyd McKenzie (Oct 19 2018 at 22:44):
It means using OperationDefinition. It could be as "standard" as a hook. If lots of implementations expect to use it, it could be in the core spec. Otherwise, it would be defined in an ImplmentationGuide with appropriate scope.
Grahame Grieve (Oct 19 2018 at 23:06):
I don't understand why, if the desire is to get cards for display, you wouldn't use CDS hooks?
Lloyd McKenzie (Oct 19 2018 at 23:39):
That's not what I understood was happening. The cards are containing a boolean that the software uses to decide which records are included in an amalgamated view
Guilherme Del Fiol (Oct 20 2018 at 00:05):
In our use case, the output would contain the output of a risk assessment, including: 1) Risk category (initially binary, but possibly multiple categories at some point, like low, medium, high); 2) specific criterion that the patient meets (e.g., first or second degree relative with breast cancer and age of onset <40); and 3) data that meet this criterion (FHIR resource(s) with data that meet the criteria).
Lloyd McKenzie (Oct 20 2018 at 00:07):
Is the data returned in the cards intended for direct rendering to a human?
Guilherme Del Fiol (Oct 22 2018 at 14:33):
Yes, the cards that return with a "positive" risk assessment are displayed on a population health management dashboard.
Last updated: Apr 12 2022 at 19:14 UTC
