New order-dispatch hook proposal

[lmckenzi]

As discussed on the CDS calls and as referenced in https://jira.hl7.org/browse/FHIR-34104

[isaacvetter]

Hey Lloyd,

Would you consider using ServiceRequest as the example instead of MedRequest?

Implementers working towards the specific use-case driving the creation of this hook, US-based prior auth, will not use this hook for pharmacy ePA, because the US already has mature, in-prod interop in NCPDP.

Isaac

p.s. I tried to create a branch of your branch to make this easier for you, if you agree, but github won't let me create a PR / I'm not spending the time to figure it out, here's the full doc: https://gist.github.com/isaacvetter/72c6073ddb3dc45829c1f2d2ba0ed3a6

[lmckenzi]

Hi Isaac,

Part of me wants to push back and say "But CDS-Hooks is an international spec, so the U.S. regulatory requirement doesn't matter..." Also, there are some medications that aren't handled under NCPDP that actually will manifest through this CRD process. However, in the interest of making you happy, change applied.

As I was doing so, I cleaned up/clarified a few other things.

I've been thinking a bit more about "order-assign" vs. "order-dispatch" and I really prefer the latter. The reality is that the order doesn't change at all during the dispatch process, and it might be dispatched to multiple parties over time. Assignment sounds much more like a one-time thing and also like something where it's a fait-accomplis when the action is done, rather than merely being a request that says "Hey, would you mind taking this on?" I think "dispatch" is a term that reflects that better.

[isaacvetter]

@lmckenzi ,

1) Any concerns with changing order to a bundle of orders to enable workflows in which multiple orders are being dispatched? 2) Isn't listing the performer duplicating info in the request (ServiceRequest/MedRequest, etc?)

[lmckenzi]

1. I hadn't considered multiples as a workflow, but guess it's at least possible. However, we don't necessarily want to pass in the full orders because, in this case, the orders will already exist. So it makes more sense to send an array of local references I think?
2. No, it's not duplicating info. Dispatching means that either the order didn't specify a performer and now you're assigning it; or it specified a high-level performer and now you're choosing someone specific.

[mattvarghese]

I don't fully understand what workflow within the EHR "order-dispatch" corresponds to. Selecting an order, signing an order etc. are specific identifiable, commonly agreeable things across EHRs. What exactly is "dispatching an order"? Without being able to clearly articulate that, we're just asking for nebulous hooks that may not correspond to actual clinical workflow points.

The existing description mentions selecting a place of service or performer. However, this selection doesn't always need to be done? It could be that the patient just shows up / calls their preferred performer, at which point the order gets synced (pull sync) by that location, and scheduled. So I don't know if this "order-dispatch" process is a thing / is well understood. I feel like CRD is rushing through a spec without understanding workflows.

Tomorrow, another vendor with a different use-case in mind comes around and assumes, there is some place in the EHR where, for example a lab is selected to be sent to for a particular order by a human end user after the order is signed. Is that true? No - lab order routing is automated without human intervention. And even if there was a point of human intervention, that would be a completely different workflow point than the CRD use-case.

Also, in the context of CRD, what I at least agree with / requested is a "background" hook. I don't know that this order-dispatch hook will meet the background processing requirements of CRD. Prior authorization requirements need to often be evaluated in the background.. If we leave the background processing aside, the workflow we are trying to hit is when a referral entry user tries to check for coverage requirements. This is actually a more defined workflow point. So if we go with a hook of "coverage-requirements-check" I think that is at least more realistic. Another vendor is not going to come around tomorrow and mistakenly assume it does something which it doesn't.

Likewise, saying that the order detail is already available is also very CRD specific thinking, and even may not hold in CRD either. If the hook is implemented for the case of changing performing location or provider, is that data filed to the EHR before the hook fires? Is that data available on the FHIR server yet? Some EHR may cancel the record and create a new record for the change - so the FHIR ID even may change etc. So I would say the resource should be included in the bundle? We should follow the precedent of order-select and order-sign..

[lmckenzi]

'dispatch' happens when an order that was not assigned to a specific performer becomes assigned to a performer -either as a 'candidate' or as 'performed'. If dispatching occurs without human intervention then, ideally, it should happen prior to order signature so that if the assigned performer will influence cost or other decision criteria, the human in the loop can adjust. If that's simply not possible, then I guess there wouldn't be an opportunity for decision support in that case.

As has been mentioned many times, "coverage requirements" is only one type of decision support CRD might provide. If you have someone who is receiving a referral and is keying in the order for local performance, that too could FHIR the order-select and order-sign hooks, so that scenario should be caught.

The order detail being available isn't CRD-specific thinking. If the order isn't yet 'official', then the order-sign hook covers what's needed. If the order was signed and persisted without a performer and a performer is later assigned, then by definition, the order is pre-existing.

I'm not dead-set against including the orders as a Bundle. I'm just pointing out that the use-case is different. With order-select and order-sign, there was a high likelihood that the orders wouldn't be available for query. With order-dispatch, by definition the order already exists and is available.

[mattvarghese]

@lmckenzi, "dispatch" is not a workflow in EHRs. You're giving a technical explanation of what you mean by dispatch. However, there isn't a meaningful workflow point corresponding to this - or at least, not one that I am aware of.

For me, when I am designing a CDS Hooks implementation, where, and in which user's workflow, am I wiring this hook into?

Also, if there is a point at which assignment of a location does happen, it is in a referral where a back-office staff works with the patient to assign location. At that point, clinical decision support isn't realistic because it is not a clinician.

So I'll merely say that "coverage-requirement-check" is something I can (and likely other EHRs can) meaningfully translate into a specific point in some end user's workflow, whereas "order-dispatch" isn't something that can be meaningfully translated into a workflow point.. There is a user whose responsibility it is to validate coverage requirements, and there is a workflow in which said user does that.

[lmckenzi]

If an EHR has no point in their workflow where they select a particular recipient for a non-directed referral or choose an imaging center for a DI order, then they won't implement the hook. If they do have locations in their workflow where a human makes such choices, then they will. Are you asserting that no EHRs have locations where humans take undirected orders and pick particular providers to perform them?