Stream: cds hooks
Topic: Ordering related hooks (deprecate medication-prescribe)
Matt Varghese (Sep 13 2018 at 00:20):
Hey folks, for those who don't know me, I'm Matt Varghese from Epic, the developer who built Epic's CDA based decision support web service capabilities, and is in charge of implementation of CDS Hooks at Epic.
We have a released beta implementation that supports the patient-view hook currently. And I have been investigating adding support for the order-review hook and the medication-prescribe hook, which led me to ask this question.
To me, from the EHR perspective medication-prescribe hook is a perfect subset of the order-review hook. Additionally, in most EHRs (at least according to my understanding) medication orders and procedure orders are entered and signed in the same place / same way. So order-review hook seems to be the right way to go, and medication-prescribe seems a wrong hook, one that we are disinclined to implement.
Yes, one can argue that medication-prescribe should only send medications. However, this also led me into thinking more on the context of these hooks. Right now, all meds are in the context of the medication-prescribe hook, and all orders including meds are in the context of the order-review hook. I think this is the wrong approach. For example, a radiology decision support system may not necessarily care about all orders. It may only care about the radiology/imaging orders being signed. Or lab prior-authorization may not care about non lab orders, or lab orders that are not going to that particular lab. That means, putting all orders into the context feels like a wrong direction. I would advocate rather that orders go in the prefetch of these hooks, so there is configurability on what orders to send for these hooks.
And if we have configurability on what orders to send for these hooks, suddenly, these two hooks actually become completely redundant.
So I propose that we deprecate the medication-prescribe hook and move the orders from the context to the prefetch of the order-review hook (or provide configurability some other way in the context).
I would also recommend renaming the order-review hook to order-sign hook or order-prescribe hook. "Order review" means something else, at least in Epic, and afaik also clinically. It is the act of reviewing the patient's order history. Not the act of prescribing orders.
I also hear talk of an order-entry hook (sorry, not super active on zulip, so not sure where this is exactly at), which happens at the point when the order is pulled in as opposed to order sign/prescribe which happens at the point of actually signing/finalizing the order. Welcome this hook - can't wait to have it :)
Welcome discussion around this both on this thread, and at the connectathon.
Lloyd McKenzie (Sep 13 2018 at 02:49):
I think there's a valuable use for the MedicationPrescribe hook, but ideally it would shift a bit from the Order-review hook. I think the ideal for Medication-Prescribe would be at the time of selection of Patient + medication - before the full order is entered. Because at that point, there are a whole lot of decisions and guidance that can be invoked: information about drug cost, information about what drugs are on formulary, recommended doses, duplicate therapy, drug-drug interactions, etc. If you can expose that information sooner in the process, it saves the clinician the time of filling out the full order. The order-review hook is useful when you need to evaluate the entire therapy and also evaluate a whole set of orders - to make sure the combination doesn't conflict or violate guidelines, to make sure nothing important's been missed, etc.
If we were to make the shift, medication-prescribe (or even a renamed patient-medication) would just need a Patient and either a CodeableConcept or a Medication instance.
Lloyd McKenzie (Sep 13 2018 at 02:49):
I do agree that if you're firing the medication-prescribe at the same point in the workflow as the order-review, there's no need for the hook.
Matt Varghese (Sep 13 2018 at 02:49):
Why would that be different from order-entry / order-selection though?
Lloyd McKenzie (Sep 13 2018 at 02:53):
I'd expect order-entry to occur after all orders have been fully entered - as decribed "when ready to sign". That can be several minutes - or rarely even hours - from the time the system knows "patient + medication"
Matt Varghese (Sep 13 2018 at 02:55):
But then, the same considerations of wanting to pull up cost of the order etc before the full order is written up also applies for procedures, not just medications. So we need a generic "order-prescribe" rather than a "medication-prescribe" (which is what I meant by "order-entry" / "order-selection")
Lloyd McKenzie (Sep 13 2018 at 03:03):
It's possible that some degree of decision support could be provided with just a test code. But it's not as significant as found with a medication. If we wanted to generify it to "pre-order" which was just a service/product code or a Medication, that could work too.
Matt Varghese (Sep 13 2018 at 03:04):
I'm not particular about the name :D But I would prefer that the pre-order hook supports all kinds of orders, and not just meds.
Lloyd McKenzie (Sep 13 2018 at 03:06):
My gut says that the value will be higher on the pharmacy side than for lots of other areas, but agree that more generic = better in principle.
Matt Varghese (Sep 13 2018 at 03:07):
Cool. Thoughts on configurability over orders being included?
Lloyd McKenzie (Sep 13 2018 at 03:11):
The CRD spec is trialing some configurability stuff through the CDS-Hook extension mechanism. Feedback on it is welcome. I think the plan is to see how it gets used in practice and then, if appropriate, propose adding it into the core spec once we have some implementation experience.
Isaac Vetter (Sep 13 2018 at 03:12):
and it's important to note that the configurability piece is completely new; whereas, additional hooks is an anticipated, planned for and natural extension of the spec.
Matt Varghese (Sep 13 2018 at 04:08):
@Isaac Vetter How would the spec deprecate an existing hook when a new hook supersedes it?
Isaac Vetter (Sep 13 2018 at 04:15):
Matt - want to talk about this more at work this week? Here's the proposed methodology for the creation of new hooks. We really haven't tackled deprecation. Ultimately, it'd be better to not have to do this.
While one CDS client (EHR or other clinical workflow system) might not find value in a mature hook; other CDS clients might. The important questions to ask, regarding medication-prescribe, are:
1) is this hook valuable to implementors? Both CDS client and servers and
2) is is important/possible for a CDS server to check a CDS client's capabilities for a specific hook?
Matt Varghese (Sep 13 2018 at 04:30):
I will rephrase your question #1 as, if there is an order-prescribe hook, is the medication-prescribe hook valuable to implementers.
I agree, we should avoid deprecation of a mature hook, which is the whole reason I am asking this question.
So far our EMR Web Service decision support capabilities have been centered around procedures, with little use for meds. Yet we have had the request for calling the web service at the time of entering the order rather than signing many times.
Josh Mandel (Sep 13 2018 at 17:31):
From the initial design perspective FWIW (though I think this is pretty well covered in the discussion above): "prescribe" was about prescriptions as they're being written, for updates to dosage, drug, etc; and "review" was about looking at a set of orders together before signing off. It was my rough guess about how to break up the world, and we got a fair bit of mileage out of it!
Now, the in-the-middle-of-entry hook be generalized from prescriptions to many kinds of orders, though it's worth saying that EHRs tend to have medication-specific entry screens and workflows (no?).
Matt Varghese (Sep 13 2018 at 17:33):
@Josh Mandel At least in our EHR, ordering places allow both med and procedure orders.
They can be pulled into a "cart" as a mix of meds and procedures; and the cart containing that mix can be signed in one go.
Josh Mandel (Sep 13 2018 at 17:38):
So the screen that adjusts medication doses also has the ability to enter procedures? The kind of thing in depicted in https://www.google.com/search?q=hyperspace++order+medication&tbm=isch? This is good to know.
(edit: replaced screenshot per Matt's request)
Josh Mandel (Sep 13 2018 at 17:39):
Do other system also make this kind of generalization? (@Kevin Shekleton for instance)
Matt Varghese (Sep 13 2018 at 17:45):
@Josh Mandel Correct - we have flexible controls which adapt the UI based on the type of order being placed. I too am curious what other EMRs takes are. At the same time, if there is an order-prescribe hook, the medication-prescribe hook is a perfect subset. You can still use the order prescribe hook even if there are only medications, but the vice versa is not true.
Josh Mandel (Sep 13 2018 at 17:46):
It'd be good experience to try re-writing examples in the sandbox to use this generalized hook. I think there are two questions here:
1. Should we subsume medication-* under order-*?
2. Should we have distinct hooks for "I'm writing orders, guide me!" vs. "I'm reviewing orders, guide me!"
Josh Mandel (Sep 13 2018 at 17:47):
On #1, I'm inclined to think that combining these is a good idea, as long as we don't hit any unexpected issues.
Josh Mandel (Sep 13 2018 at 17:47):
On #2 my perspective is that these really feel different to me -- but if that's not born out in the actual UX from most systems, I'd revise this perspective :-)
Matt Varghese (Sep 13 2018 at 17:50):
@Josh Mandel Just to clarify - what do you mean by review? Currently, the order-review hook is called that, but the hook definition makes it the act of signing orders. I too agree that pulling an order into the cart with the intention to order it must be a different hook from finalizing and signing the order.
Josh Mandel (Sep 13 2018 at 17:51):
The intention for review hooks (like, my intention in 2015 -- unsure if this was well communicated) was: here's a set of orders in my cart that I'm planning to sign. Anything I should change? Any redundancies or missing dependencies, etc?
Matt Varghese (Sep 13 2018 at 17:52):
@Josh Mandel - ok, then we both agree. (Just that review means something else in clinical workflows as I understand, but I am fine with calling it order-review as nobody but tech people see it)
Josh Mandel (Sep 13 2018 at 17:53):
Can you clarify the clinical workflow distinction you're referring to, for the meaning of "review"? I'm not sure it's black and white, so we want to document any possible misinterpretation so we can proactively set people straight.
Matt Varghese (Sep 13 2018 at 17:56):
Once an order is signed/finalized - it becomes an active order on the patient. Then there are other lifecycle stages for the order, such as discontinue - if the physician feels the order (for example a med or recurring procedure) has outlived its usefulness. There are cancelled orders; there are resulted orders etc.
Order review is the act of reviewing the orders already signed on the patient - what is active, what results have come back, etc.
I would definitely say though, that if we can get clinicians to look this over, it would be better than my viewpoint.
Josh Mandel (Sep 13 2018 at 17:57):
Thanks -- that helps give me a quick sense of what you mean. If we were deprecating and generalizing stuff, then order-prepare and order-sign or something might be better names.
Matt Varghese (Sep 13 2018 at 17:59):
Sure - I am open to suggestions/ideas. I am already happy that we crossed the first item - the biggest concern on my list (procedure orders not being in medication-prescribe). Name would be nice to be clear :)
John Moehrke (Sep 13 2018 at 17:59):
Are these not just a variation on Subscription for Pre-Create, Post-Create, Pre-Update, and Post-Update on a resource targeted by Subscription? In theory Pre- and Post- could be on any CRUD operation?
John Moehrke (Sep 13 2018 at 17:59):
Thus it is just REST orchestration?
Matt Varghese (Sep 13 2018 at 18:02):
In the ordering flow - there is more than just a pre/vs post consideration. In fact both order-prepare and order-review are pre-hooks in that sense.
In the order-prepare case, the order is not filled out yet. So only basic information like code etc will be available. Advanced things, like exact dose, or laterality of a procedure etc will not yet be filled out. It is an early point where we can intervene so that the clinician is not upset "I just filled out this order, and now you tell me this is not the right order? Why didn't you say earlier?"
order-sign is when physician has filled out everything. Ideally there should only be serious stuff on this hook, since the clinician will be upset if you didn't do what you could on order-prepare.
John Moehrke (Sep 13 2018 at 18:05):
yup. sorry I need more REST
Lloyd McKenzie (Sep 13 2018 at 18:10):
The problem with sending full resources in a "pre-order" hook (i.e. one fired early in the authoring process) is that instances are expected to comply with the DAF profiles. If the DAF profiles make any discrete elements mandatory (e.g. specimen, dose, etc.), then suddenly you can't send the resource instances until at least that much has been entered.
Matt Varghese (Sep 13 2018 at 18:12):
@Lloyd McKenzie how is that consideration any different if the hook is called pre-order or medication-prescribe?
If you want details of the order, then order-sign would be the hook to use.
Lloyd McKenzie (Sep 13 2018 at 18:19):
Right. Which is why I'm suggesting that pre-order or medication-prescribe might be better just specifying code or Medication rather than full MedicationPrescription or ServiceRequest resources
Matt Varghese (Sep 13 2018 at 18:22):
Ah ok I see what you are saying. Immediately, that feels perfectly reasonable; will think more over just hardcoding that.
That also segues into the configurability aspect I mentioned. Even on an order-prepare or order-sign hook, not all CDS services may need all the orders being signed etc, and as you point out, not in full either.. Should we / can we / must we, make this configurable?
(PS: @Lloyd McKenzie - I hadn't seen your update to the earlier post. Now I get fully what you are saying)
Lloyd McKenzie (Sep 13 2018 at 18:32):
Can we? Sure. Must we? No. Should we? TBD. Services are free to ignore orders they don't care about. And we're looking at putting guard statements on hook service declarations that allow the client to not bother calling services if the data isn't relevant to them. EHRs can also choose to disable calls to certain services for certain users or in certain contexts. The real need for service configurability is if you want back certain types of cards from a service but not others.
Matt Varghese (Sep 13 2018 at 18:38):
@Lloyd McKenzie You mention guard statements. What would this be like? "Don't call me if it is not an imaging order?" Then if the user is signing a Chest X-Ray order, and a medication for headache, should the order-sign hook send both to you, or just the Chest X-Ray?
Or am I understanding you wrong?
John Moehrke (Sep 13 2018 at 18:39):
Just a reference to Postel's law
Lloyd McKenzie (Sep 13 2018 at 18:41):
In terms of guard statements, no clue. I just remember a presentation where @Kevin Shekleton mentioned they were something to be evaluated in "future versions" :) The specific example given was for a hook that would fire off the bilirubin SMART app if relevant wouldn't be triggered if the patient wasn't a newborn.
Kevin Shekleton (Sep 21 2018 at 18:10):
Our system has a generic ordering screen/module as well. It can handle any type of order (medication, radiology, lab, etc).
Kevin Shekleton (Sep 21 2018 at 18:17):
I think this is great discussion and will benefit most from broader implementation feedback. Right now, there has just been a couple of people experimenting with the (current) medication-prescribe hook. I'm not aware of anyone who has implemented the order-review hook.
One of the things that will be interesting is if it is easier on implementers (CDS clients + CDS services) to lump all ordering under a generic hook.
Thanks for logging docs/issues/411 Matt! I'll continue my thoughts there
Lloyd McKenzie (Sep 21 2018 at 19:43):
If the intention is that medication-prescribe is just a specialized version of order-review, that should be made clear. I think it's useful for us to have hooks at two separate points in the workflow - one for initial ordered item selection and one for completed set of orders for review.
Matt Varghese (Sep 23 2018 at 03:01):
@Lloyd McKenzie I am not proposing that one is a specialized case of the other. The hook that happens at initial order selection, and the one that happens when the order is filled out and about to be made active, must be two separate hooks - as they are two points in the workflow.
I am just saying that both should be generic to account for all orders; right now one accounts only for meds while the other accounts for both meds and all other types of orders, which is a deficiency.
Josh Mandel (Sep 24 2018 at 18:34):
I think a key issue right now is the mismatch between what EHRs have (generic ordering screens) and the quick demo our sandbox offers (med order entry only). I think it's important for the sophistication of our sandbox UX to at least parallel the sophistication of a real EHR -- i.e., it needs to cover the same use cases before we can expect to see anyone experimenting.
Alex Tatiyants (Sep 29 2018 at 14:26):
Sorry for the late entry here, but I agree with @Matt Varghese. medication-prescribe is a special case of an ordering hook based on my experience with major EMRs. As far as order events, order-sign and order-add make sense too because they're unambiguous. order-review, even though it was meant to represent a signing event is definitely not consistently implemented that way. In at least one case, it is implemented as continuous ping during the entire ordering process.
Kensaku Kawamoto (Sep 30 2018 at 16:20):
I think we should discuss this also during the CDS Hooks focused sessions at the CDS WG this week. In the context of -- we have patient-view, what are the next hooks to prioritize and define in more detail? For scope of orders, I think all vs. med vs. procedures are all reasonable. For data to put in context, I think either pulling all (or almost all, e.g., all minus referenced secondary resources like Provider) or prefetching are both reasonable. One issue to consider here is how often the non-med orders use standard codes to enable prefetching based on code. For workflow step, I agree with order-select (when the user just selected the order, and code is available), and order-sign (when the user is about to sign the orders). For order-review, I think we should discuss this further. Is it reviewing unsigned orders only? In which case should we call this unsigned-order-review? Or does it include signed orders, like when you review all the orders that are active for a patient?
Last updated: Apr 12 2022 at 19:14 UTC
