Stream: Da Vinci
Topic: CRD Hooks
Lloyd McKenzie (Jul 29 2018 at 22:56):
Obviously we're going to need a hook to cover patient-independent hook, as the existing CDS Hooks have patientId as a mandatory element. However, I'm wondering whether we should leverage the existing medication-prescribe and order-review hooks for patient-identified action. Those are the natural business locations to invoke checks from and they already have some of the key information built in. All we'd need to add is an expectation for support for retrieving the patient's Coverage resources, presumably as part of pre-fetch. @Danielle Friend @Jeff Danford @Kevin Shekleton - thoughts?
Lloyd McKenzie (Jul 30 2018 at 15:15):
@Isaac Vetter
Isaac Vetter (Jul 30 2018 at 16:02):
Hey Lloyd, from my limited understand of the CRD workflow, it seems like we should definitely be using the existing hooks and/or defining new hooks that describe workflow events that aren't specific to just this integration. Careful identification of the "natural business locations"/ workflow events is the key.
And exactly as you say, Coverage should simply be a pre-fetch element. Overall, we don't want or need to create integration-specific hooks.
Mind saying more about the patient-independent use-case? What's the workflow event? If a specific user action is required (user click's button/link), it's probably more appropriate as a simple SMART app.
Lloyd McKenzie (Jul 30 2018 at 16:06):
I'm not sure that Coverage is a pre-fetch. Or at least it's not the same sort of thing. When you invoke one of the standard hooks on a payor application, you're only going to do so if the patient in question has a relationship with that payor and there's reason to believe the payor might be involved in paying for the service that's happening/being ordered. The insurance information shared would be the Coverage that's specific to that particular payor/patient/proposed service combination. Typically there would just be 1, though in some cases there would be more than one. The key thing is that it would be hard to define a query that would bring back only the relevant Coverage. It's really intended to be determined by the EHR. So what I was envisioning was defining an additional (optional) parameter for the existing hooks similar to 'patient' and 'encounter' that provide context for the hook invocation - and which could then be referenced in pre-fetch queries.
Lloyd McKenzie (Jul 30 2018 at 16:08):
The patient-independent hook would fire at the same time as the current medication/order/encounter hooks, but it has a limitation of not allowing the exchange of patient-identifiable information. So rather than saying "I'm drafting this order for patient X, what payor-specific information should I know?" you'd instead say "I'm ordering this type of service (code) to be delivered by this location (Location) and expect to bill under this type of plan (code) - what payor specific information should I know?"
Lloyd McKenzie (Jul 30 2018 at 16:09):
In the patient-independent one we can't really use the MedicationRequest/ServiceRequest/[other]Request resources because those are all tied to the Patient. Instead we'd need to convey the nature of the service in a single code.
Isaac Vetter (Jul 30 2018 at 16:10):
Lloyd, your patient-independent idea feels really similar to the Anonymized CDS idea
Lloyd McKenzie (Jul 30 2018 at 16:14):
Perhaps. It's not clear that there's actually an intention to support querying for additional data in the non-patient-identified situation. The real reason for using the hook mechanism in that case isn't to allow the service to query data, it's just to ensure that the user gets relevant data (cards) at the appropriate times in the workflow.
Lloyd McKenzie (Jul 30 2018 at 16:16):
Back to your question of whether there are additional workflow points required, the only other possible one would be an "I'm thinking about ordering X" - sort of a "what if" scenario. I'm not sure if/how that's supported in the current EHRs. And my guess is that what you'd actually do in that case would be to fire off the "I'm ordering" hooks at that workflow location too - because you'd want exactly the same information back and whether it was a draft order or a proposal wouldn't/shouldn't matter to the decision support being invoked.
Robert Dieterle (Jul 30 2018 at 18:17):
I see this is confusing -- many of the tabs are there to start the conversation regarding profiles -- the only ones that are "complete" are the tabs for eligibilityrequest, eligibilityresponse and coverage. Sorry for the delay in responding -- will review the work book this evening and post a new copy clarified information
Lloyd McKenzie (Jul 30 2018 at 18:19):
Ok. The use of EligibilityRequest/Response is actually in question as we move to CDS Hooks. We may not need them. (And if we do use them, we'll probably use more core elements and less extensions.) I'm writing up a complete list of issues for us to discuss which should be out this evening.
Last updated: Apr 12 2022 at 19:14 UTC
