make medication-prescribe a generic order hook, update order-* hook names

[mattvarghese]

Creating this issue based on this zulip conversation:
https://chat.fhir.org/#narrow/stream/17-cds-hooks/topic/Ordering.20related.20hooks.20(deprecate.20medication-prescribe)

Gist of it:
There is value in being able to apply the medication-prescribe hook to non-med orders and not just med orders. So make it generic.
Proposed names include, but not limited to:

• order-prepare
• pre-order
• order-select

Similarly, rename order-review to have a more meaningful name
Proposed names include, but not limited to:

• order-sign
• order-finalize

(Update: after writing this up, I was also told that "prescribe" is an outpatient only term, and doesn't makes sense in inpatient settings. So removed the suggestion of "order-prescribe" from above.)

[kpshek]

Thanks for logging this @mattvarghese. I think it would be good to get implementer feedback (both from CDS clients and services) as to if this approach is better.

In Cerner's case, our ordering module is generic and allows for any order type (eg: medication, lab, radiology, etc) to be ordered. So, a generic hook seems like it would fit well with our implementation. I am not aware of other EHR vendors but I imagine some only support certain order types so they may not feel the same way.

In my experience over the past few years working with CDS Service Providers, they seem to all deal with very specific order types. That's not to say they won't expand beyond this, but it will be interesting to see how they view this more generic hook.

One of the benefits of a more specific hook is that it is clear what is supported by the CDS client (eg, EHR vendor). For instance, if I say I support medication-prescribe (or say, medication-select), it is very clear what I support. However, the same cannot be said about a more generic hook like order-select. For instance, I just may support order-select for medication but not anything else.

The good thing is that our existing medication-prescribe and order-review have really not been put through the paces with implementer feedback. So, now is a great time to be discussing changes like this.

[kpshek]

Also, FWIW, my initial gut reaction to this was that goes against what we have described hooks thus far - very specific actions occurring in the workflow. The more generic we make a hook, the more complexity it may accrue in order to handle the various scenarios. I wonder if our worldview here is being colored by the generic ordering hooks fits the UX paradigms of Cerner & Epic's EHRs.

Another thought - the fact that FHIR has distinct resources for these order types makes a possible generic ordering hook cumbersome. Specifically, the context will be potentially complex with varied resource types.

I mention this not intending to squash this proposal; but I just wanted to capture my initial reaction. Ultimately, I think the broader community who wants to use these hooks need to get involved and we can go with the consensus decision.

One final thought - a generic order review/sign hook likely needs to exist for CDS services that want have a holistic look at everything being ordered in order to provide good guidance/CDS. Given that, going broad for all of the other order hooks may be the right thing to do.

[mattvarghese]

@kpshek -
(1) You are saying Cerner also has a generic workflow rather than a med specific workflow. It is what I would expect because that is what I understand clinicians to expect.
(2) Agree that medication-prescribe and order-review have not really been put through a lot of implementation - and so now is the time to change it. Naturally, trying to implement them was when the issue came up for me.
(3) Your statement of complexity with regard to generic hooks is not accurate. Order-review is a generic hook right now, so changing from medication-prescribe to order-selection will make them both better aligned, reducing implementer complexity due to one less difference. Likewise, regardless of context, if the CDSS asks for a resource, the EHR has to be able to include that in the prefetch, so that the EHR has to have the capability anyway (aside from the cutting corners of saying, we don't support prefetch - go fetch it yourself).

So let's first make the generic hooks. And if more specific hooks are needed, we have a path to make them.

I also am still not super sure that defining all the orders / meds in the context of these hooks is appropriate. The CDSS on the other side likely may not care about all these orders. It will only care about certain types of orders, at least in most of the use-cases we have - radiology decision support, high cost lab prior auth, certain medication dosing / appropriateness etc. So within what we know, I don't see the value of the generic context. My personal take is that the orders the CDSS cares about should go in the prefetch because that will allow a more specific subset. That said, this should not be included in the scope of this github issue.

[lmckenzi]

The value for the generic context is cross-checking orders. E.g. If you're ordering med X, ensure that you've also scheduled regular blood tests to monitor liver/kidney function; or if you're ordering procedure Y, ensure that you've also given an order for clear-fluids only starting 8 hours prior and have ordered prophylactic antibiotics starting 4 hours prior.

Granted, these are slightly more essoteric than doing drug-drug checking across drug orders

[mattvarghese]

@lmckenzi So in your example, if the clinician orders Med X, blood tests, and a Chest X ray together, would a CDSS which cares about Med X want to get the chest Xray, or would it be better off just specifying in the prefetch that it wants med x and blood tests?

[mattvarghese]

Also, what if there was a standing order for a blood test which covers the need for blood tests for med X, so that the physician will not be ordering a blood test. The CDSS has to anyway ask for all blood tests in the prefetch..

[mattvarghese]

And finally, note that the blood test is a lab order. So the current medication-prescribe hook will NOT include it.

[lmckenzi]

There isn't necessarily anything to prefetch - the orders are "ready for signoff", but that doesn't mean they're yet exposed via the REST interface. (Most EHR systems don't (yet?) expose "draft" content.) The CDSS would look at both what orders are already in place as well as what draft orders are part of the bundle in deciding what action to recommend. In most cases the queries for orders already in place would be by direct query rather than prefetch as "what orders are relevant" would be highly contextual and it's unlikely the CDSS would ask for all active orders (or that the EHR would choose to deliver that).

Understood that medication prescribe wouldn't cover it. As mentioned earlier, I think medication prescribe should be defined as occurring earlier in the workflow - at the time of drug selection, long before the order is fully entered. And in that case, you really don't need more than a single order at a time unless you're looking to do drug-drug-interaction checking between the selected drug and other (likely more complete) draft orders.

[kensaku-kawamoto]

In agreeing with many of the points made, here are my 2 cents:

• If unsigned orders aren't available yet in the regular FHIR interface, we'd want it provided in the CDS Hooks context, because there's no other way to get it. Ideally, this WOULD be supported in the FHIR interface, because we care about this info whether you are in a CDS Hooks context or not. E.g., in a SMART on FHIR app that is recommending whether a patient with diabetes needs an A1c test, you don't only care about A1c that have been resulted or ordered; you also care about the A1c that is in unsigned orders, because you would look silly recommending that an A1c be ordered when they've already done so and put it in the unsigned orders.
• I think it would be good to also support only partially completed unsigned orders, i.e., in the order-select hook (e.g., where you've only said you are going to prescribe atenolol PO, but not how frequently or for how long). For non-medications, it would be good for these to also use a standard orderable catalog, with standard codes. But even having EHR vendor or implementation-specific codes would be much better than having nothing.
• I can see both sides of the argument of whether to make it fully generic vs. type specific (e.g., medication orders vs. procedure orders). I don't think we should get any more specific than meds vs. non-meds (i.e., procedures), though, as distinguishing between different types of procedures is difficult. We should also potentially make clear how immunizations cross this bound. Possibly another reason to combine the two.
• I agree that whatever is chosen, it should be clear what will be sent with regard to medication orders vs. procedure orders.
• For orders that haven't been yet signed, the quantity of orders we are talking should be limited, and in memory -- so I see little performance benefit in NOT retrieving and sending the available information. If there is one. Perhaps I'm missing something here though.
• I'll contribute another use case to the desire of knowing orders across the main types (medications vs. procedures): recommending an invasive procedure like a lumbar puncture, need to make sure the patient is not about to be co-prescribed anti-coagulant (blood thinning) medications. And vice versa.
• P.S. Lloyd's example is common -- med ordering to check for monitoring labs ordered (e.g., vanconymcin levels)

[mattvarghese]

@lmckenzi - the "order-select" hook can actually send more than just the med / procedure being ordered. The clinician workflow is that they are selecting a few orders (or even opening an order set), so that the first order may not have any others already in the shopping cart, but subsequent ones will have 'already-selected' orders in the shopping cart while the current order is being selected. I would favor implementing the "order-select" hook to include all orders in the cart, while marking the particular order which was selected in this instance of the hook. Especially @kensaku-kawamoto 's comments also seem to line up with including other orders simultaneously present in the cart.

[mattvarghese]

@kensaku-kawamoto - agree that the set of orders in the cart is not big, and so it would not be particularly onerous to send them. However, if we include all in the context, the CDSS does not have any option to choose not to receive all; whereas if we say the orders go in prefetch, the CDSS can exactly specify the orders it wants. If it wants all orders, it can say so, but if it only cares about a particular med and associated blood monitoring, it can say it only wants that subset to be sent.

Personally, I am fine with either option. Just that, putting myself in the shoes of a CDSS system while designing this, I wondered if the CDSS would want all of it - especially if it is a large orderset that triggered the "order-selection" hook. I thought about the use-cases of radiology, order prior auth, med appropriateness etc, and in each of these, it seemed to me that there is a subset of orders, and not everything in the cart, which the CDSS would care about? Drug-drug interaction is an interesting case; if every drug-drug interaction needs a web service call, that would be particularly taxing. And most EHRs already support all basic drug-drug interaction checks. So a drug-drug interaction check which needs CDS Hooks to me is a complex one, and in these cases again, I would think there is a subset of what is in the cart (based on pharm class/subclass, or a value-set of meds) which the CDSS would want.

[isaacvetter]

I believe this issue has been addressed by PRs: #469 , #428, #429.

Closing.