Stream: cds hooks
Topic: Client side pre-conditions
Rong Chen (Feb 19 2020 at 20:13):
Has anyone encountered the need for some kind of pre-conditions of a cds-service? Say for a given hook, there is a specific cds service to check if the anti-coagulation treatment is given to an atrial fibrillation (AF) patient according to AF management clinical guidelines. The actual treatment compliance checking is quite involved, but the pre-condition (or inclusion criteria) for that is the patient has AF condition and can be easily determined at client side (EHR). Without some kind of pre-conditions checking/filtering at client side, about 96% of the cds-service calls are meaningless since AF is only about 4% prevalence in general population.
Other pre-conditions could be patient age group, gender or relevant medications. The point is to avoid unnecessary calls of remote cds-service unless some pre-defined conditions are met.
Carl Anderson (Feb 19 2020 at 21:48):
I'm not sure there's been discussion about a mechanism to suppress calls, but I imagine that by pre-fetching the right resources in the hook definition you could make the calls lightweight enough.
Carl Anderson (Feb 19 2020 at 21:54):
Let me know if this is helpful: https://cds-hooks.org/specification/current/#prefetch-template
Rong Chen (Feb 20 2020 at 07:27):
Pre-fetching does help (that's actually what we use) a bit, but it doesn't avoid unnecessary calls (involving round-trip) of remote cds-services.
Rong Chen (Feb 20 2020 at 07:43):
For inspiration, an optional predictions attribute could be added to the service definition:
{
"hook": "patient-view",
"title": "Static CDS Service Example",
"description": "An example of a CDS Service that returns a static set of cards",
"id": "static-patient-greeter",
"prefetch": {
"patientToGreet": "Patient/{{context.patientId}}"
}
"preconditions": {
"patient.gender": "male"
}
}
To indicate that if the patient.gender isn't male, the client should not proceed to call at all. This does add a bit of complexity to the client-side to process the conditions. Since it's optional, similar to pre-fetch as an optimization, the client can still go ahead to call if it doesn't have the capability to process the pre-condictions.
Dennis Patterson (Feb 20 2020 at 15:15):
@Rong Chen this had come up previously and was ultimately scoped out for 1.0, relying on the CDS Client underlying rules engine to handle when to invoke the CDS Service. You can have a look at the discussion here - https://github.com/cds-hooks/docs/issues/6
Rong Chen (Feb 20 2020 at 16:18):
Thanks @Dennis Patterson . It's pity since this could bring significant potential for optimization. Any chance to bring it up for v1.1 considerations? If it's optional attribute (thus optional for client to process), it would fit in v1.1. Even with simple criteria like age, gender and single condition would be very useful.
Josh Mandel (Feb 21 2020 at 17:18):
Are you suboptimal behavior in a production scenario today? Would be good to understand impact.
Rong Chen (Feb 22 2020 at 09:51):
@Josh Mandel Yes, it is based on the observation of production use of our patient-view hook based cds alert for stroke prevention. The relevant clinical guideline is only applicable for atrial fibrillation patient, which is about 2-4 % in general population. In other words, 96-98% of cds-service calls aren't necessary at all if the patient has no documented AF condition. You can find more information about the design of the cds from this publication on the scientific evaluation of the CDS, https://www.ncbi.nlm.nih.gov/pubmed/29534063
For a regional EHR that covers half million population (include GPs & specialists care which is perhaps unique in Sweden), this means 10k calls per day (again 96-98% is unnecessary if the client can process some kind of pre-condition or inclusion/exclusion criteria). This is just one service, if we continue to add 20-100 more cds-services one could easily see why the current design isn't optimal.
Josh Mandel (Feb 22 2020 at 15:23):
Thanks! The design is assuredly not optimal -- I'm just trying to understand the real-world consequences today, and anticipated consequences down the line. The things we could talk abou are 1) is this slowing down EHR usage for folks? Can this be quantified? 2) is this costing extra $$ in bandwidth or compute? Can this be quantified? 3) Is this preventing adoption of a broader set of services, vs. say steering your organization toward adopting closer-to-the-edge or more-highly-aggregated CDS service deployments? 4) is this causing compliance challenges? Of what nature?
Other categories?
Isaac Vetter (Feb 27 2020 at 04:23):
Apologies for joining the conversation late, Rong.
Has anyone encountered the need for some kind of pre-conditions of a cds-service?
Yes, very much so.
Isaac Vetter (Feb 27 2020 at 04:23):
The widely deployed current state is that a CDS Hooks service can co-exist with local CDS rules exactly as you describe. (e.g. only call zika cds service if patient is female). It's not only appropriate, but also often desirable to intermix local CDS rules with remote CDS Hooks services to minimize traffic/compute/cost/UI time. Currently, these "pre-conditions" are also locally configured. Some systems/organizations use FHIR Clinical Reasoning to also provide interoperable rules to define pre-conditions. I expect to see more of these "CQL Hooks" going forward.
Isaac Vetter (Feb 27 2020 at 04:23):
You should determine the cost/benefit analysis of simply documenting the requisite pre-conditions to healthsystems using your service versus building an interoperable description of those rules.
Grahame Grieve (Feb 27 2020 at 05:52):
I think that means that there isn't interoperability in the pre-conditions at this time.
Grahame Grieve (Feb 27 2020 at 05:52):
but it seems like a reasonable thing to desire to me
Rong Chen (Mar 02 2020 at 12:48):
Thanks for the confirmation, @Isaac Vetter @Grahame Grieve
Last updated: Apr 12 2022 at 19:14 UTC
