Stream: cds hooks
Topic: Proposal for order-search hook
JP (Jul 23 2020 at 22:22):
I've opened a PR on the cds-hooks repo for a proposed order-search. This would be the first hook to fire when a clinician browses an order catalogue, allowing a decision service to make recommendations. This would happen before order-select and order-sign.
https://github.com/cds-hooks/docs/pull/532
There's a challenge in that an EHR needs to convey enough context to the decision service to avoid having services that are not relevant to the current clinical context fire. The order-select hook is able to avoid this because the selected order that is passed has a specific type, meaning decision services that apply to MedicationRequest selections need not fire if a bundle contains ServiceRequests. The proposal suggests adding an orderType parameter to provide that same functionality.
Lloyd McKenzie (Jul 24 2020 at 00:59):
Can you give some examples of what sort of decision support you'd expect to be provided when the only knowledge is that a clinician is ordering a MedicationRequest? Or worse a ServiceRequest (which encompasses referrals, labs, imaging orders and more)?
JP (Jul 24 2020 at 05:20):
The intent isn't that you'd be able to give appropriate guidance with only that parameter and nothing else. For a specific decision support service implementation I'd expect it to query (or prefetch) whatever additional data it might need. It could definitely be argued that the ability to do that makes the orderType parameter redundant. I think it remains relevant because it allows a first-pass filter on the types of services that run. The type of data included in the order-select hook allows similar functionality.
I did consider using something like useContext to provide this functionality. That would allow much more granularity in the filter. However, the initial feedback I had was that that would be very difficult to implement on the EHR side.
I also considered creating hooks specifically for device-search, medication-search, etc. but that seemed to run counter to current efforts to represent orders generally.
Trying to cover the breadth of possibilities for orders and clinical contexts when browsing a catalog is pretty challenging. I'd welcome other suggestions. The "all-in" approach of extensively using useContext (or similar) to scope the services seems onerous for EHR implementors, while the "run all the services" approach seems extremely inefficient when many "order" hooks have no chance of being relevant.
Lloyd McKenzie (Jul 24 2020 at 05:43):
My question stands. Can you give a concrete example of what a CDS system could provide (with whatever querying you might imagine it would do) when triggered with just a patient id and a code saying 'MedicationRequest' or 'ServiceRequest'?
Bryn Rhodes (Jul 24 2020 at 05:49):
A clinician wants to prescribe a medication for diabetes management. Choosing the appropriate medication involves gathering information, both from the patient’s record, as well as the clinician providing input to the process. The order select hook is too late, the clinician has already chosen a medication. This hook enables a service to provide guidance about whst medication to choose.
JP (Jul 24 2020 at 06:20):
To use Bryn's example, the "MedicationRequest" orderType covers the clinician needing to prescribe a medication while the "for diabetes management" and "clinician providing input" components could be handled by a SMART app designed for medication recommendations. The CDS service itself would just provide a link to the SMART app.
Given the complexity of orders, the ability to launch a secondary SMART app focused on recommendations to gather additional input, and the explanation that it's not the intent that the CDS service itself necessarily do anything I'm not quite sure how to answer your question. Does "launch a SMART app" fit the bill?
I'm definitely open to other suggestions on how to approach this. I think there's value in a hook that fires when browsing an order catalog specifically for things like recommendation applications. My real question is how to best align this with current thinking in the cds-hooks space.
Lloyd McKenzie (Jul 24 2020 at 11:36):
But nothing in the proposed hook tells you that they're about to prescribe for "diabetes management" - and there's no query that would tell you that. All you know is that they're about to prescribe 'something'.
Lloyd McKenzie (Jul 24 2020 at 11:37):
With ServiceRequest, it's even worse - all you know is "they're about to order 'something'". I don't understand how you can provide context-meaningful CDS with such limited information.
Lloyd McKenzie (Jul 24 2020 at 11:39):
I guess if the intention is to replace the EHR's medication order mechanism with a SMART app, it could work, but with ServiceRequest, it wouldn't even be clear whether to launch the imaging, lab or referral app. And it's hard to imagine EHRs jumping up and down to support a hook whose sole purpose is to bypass a key functionality...
John Silva (Jul 24 2020 at 12:45):
An indirectly related aspect of this ---- with the order-select hook as the first time a CDS Hook and SMART app can interact with the user (clinician) it could cause many back-and-forth cycles of canceling the order as the SMART app recommends alternatives to the chosen order by the clinician and the clinician might need to incrementally refine (or cancel) their order to match the recommendation of the CDS Hook/SMART app. This is the kind of workflow that can cause clinician dissatisfaction and distrust and eventual non-use of the CDS recommendations. Having more of the pre-conditions known and conveyed up front for the order (medication and specific serviceRequest) can help (maybe) reduce these iterations?
JP (Jul 24 2020 at 20:05):
Lloyd McKenzie said:
But nothing in the proposed hook tells you that they're about to prescribe for "diabetes management" - and there's no query that would tell you that. All you know is that they're about to prescribe 'something'.
Lloyd, I completely agree with this. I'm not sure where I'm miscommunicating but this proposal as-is intentionally only provides a minimal amount of filtering of decision services
My initial proposal, prior to raising the hook on this chat, was to include a useContext in the hook context for exactly the reasons you list. The initial feedback I had was that it would prove to be difficult from an EHR implementation perspective since they'd have to provide appropriate context when invoking the hook. That may not actually be the case, but that's the feedback I'm working from. If there's a better way to specify and track that context from an EHR's perspective I'd like to know and incorporate that into the hook definition.
Let's consider an alternate proposal for a "medication-search" hook that has a useContext parameter. That would provide sufficient granularity to only invoke the hook specifically for the "medication prescription for diabetes" scenario. The "medication-search" aspect runs counter to the consolidation of the order-* hooks (medication-prescribe is being retired), and the additional useContext has the same supposed difficulties for EHR implementation.
JP (Jul 24 2020 at 20:09):
More generally, given the need for order recommendations and given the wide variety of orders and clinical contexts involved, what approach would be most aligned with the current direction of cds-hooks and easiest to implement from an EHR's perspective?
Lloyd McKenzie (Jul 24 2020 at 21:39):
I understand the challenge of having a useContext. I would expect that in many (most?) EHRs, the EHR would have no clue what the clinician was trying to prescribe until they'd started typing the name of the drug and gotten far enough to select one from the drop-down. And at that point, you're good to go with your first firing of the "order-select" hook. If dealing with ServiceRequest, the EHR might be able to tell whether the clinician is about to order a lab vs. imaging vs. make a referral, but I doubt they'd know more than that until, again, the user had started to fill out the form (and order-select would be viable). My question was for a concrete example of a couple of useful cards you would expect a service to provide back with the current design for the hook. It may be there would be useful things you could say that would need to be said before you'd started filling out the order form/selecting from a care plan/bunch of order sets. I just can't visualize what they would be.
Matt Varghese (Sep 09 2020 at 17:18):
I agree with @Lloyd McKenzie The EHR generally has no clue what or even what type of order a clinician is trying to place until it is selected.
A medication-search is likely not feasible, because afaik it's not feasible to distinguish between searching for a med and searching for a procedure.
And the EHR generally doesn't know the type of service request even if somehow it could be told that it is a service request and not a med request.
So the OrderType parameter does not seem very practicable for an EHR to furnish (except maybe in extremely limited contexts?).
Matt Varghese (Sep 09 2020 at 17:19):
Additionally the likelihood of noise on this hook, and the response delay introduced in the clinician's workflow make me wary of this hook proposal.
Josh Mandel (Sep 09 2020 at 18:15):
These assessments are context dependent. Some systems provide an electronic prescribing interface that is specific to medications.
Matt Varghese (Sep 09 2020 at 18:18):
Josh Mandel said:
These assessments are context dependent. Some systems provide an electronic prescribing interface that is specific to medications.
@Josh Mandel: Agreed. Added qualifiers to my previous response..
Lloyd McKenzie (Sep 09 2020 at 18:24):
I'd still love examples from @Jonathan Percival of what sorts of card content he envisions a service being able to provide back for this hook.
JP (Sep 09 2020 at 21:24):
@Lloyd McKenzie - There's some internal discussion going on with the client I'm working with on how to proceed.
John Silva (Sep 10 2020 at 19:18):
I've been on a 'departmental CIS system" where it had a taxonomy of order types the clinician could order so it 'knew' the order type and provided the clinician with a nice list of orders based on the top-level order type chosen.
Last updated: Apr 12 2022 at 19:14 UTC
