Stream: cds hooks
Topic: How is DetectedIssue different from a card?
Isaac Vetter (May 07 2019 at 15:23):
@Rich Boyce , @Thomas Reese - @Dennis Patterson and I were chatting at the WGM this week about #477. I'm struggling to mesh together the DetectedIssue resource with a CDS Hooks card. It seems like an instance of DetectedIssue is simply a formal auditing of the rationale for showing a card to a clinician. Within your PDDI flow can we keep the use of storage of the DetectedIssue resource within the "PDDI CDS Medication Select Service" perhaps with the use of the proposed CDS Hooks /analytics endpoint for the EHR to inform the service of the action taken by the clinician?
Thomas Reese (May 07 2019 at 15:52):
This is something I have not thought of and I think it might be a great option to resolve several barriers (thank you!). My one concern is that we use the clinician actions from the order-select response to populate the DetectedIssue. The goal is to provide the order-sign service with enough information, either through the DetectedIssue or another mechanism, to filter a subsequent alert (hopefully). So, the order-select and order-sign services need to communicate, if they are separate. Also, I think we can track the original MedicationRequest with the identifier/id to confirm clinician actions.
Isaac Vetter (May 07 2019 at 16:03):
Hey Thomas, it's really just the DetectedIssue's mitigation.action that the order-sign service that you need, right? (The override reason supplied by the clinician to the order-select service should be used to inform the order-sign service when to suppress alerts). Is this right?
Thomas Reese (May 07 2019 at 18:14):
Yes, that is the primary reason.
Isaac Vetter (May 07 2019 at 20:50):
I think that It would be cleaner and more "CDS Hooks-like" and broadly reuseable to enable override reasons natively within the cards.
Isaac Vetter (May 07 2019 at 20:53):
What do you think?
Bryn Rhodes (May 07 2019 at 21:37):
Override reason makes sense, we would use something like that (and have had to use EHR-specific functionality to configure that aspect because CDS Hooks doesn't have it). But I wonder how it would work in the case of passing the override from an order-select to an order-sign? Would the EHR keep that as some sort of context and make it available on the order-sign call?
Lloyd McKenzie (May 07 2019 at 22:59):
If it was actually a resource, it would point to the order and be available
Isaac Vetter (May 08 2019 at 03:19):
But I wonder how it would work in the case of passing the override from an order-select to an order-sign? Would the EHR keep that as some sort of context and make it available on the order-sign call?
Isaac Vetter (May 08 2019 at 03:20):
Admittedly, we created appContext to enable this type of relaying of information from the CDS Service to a SMART app, but a SMART app launches in the client directly from a card. A order-sign hook doesn't launch directly from an order-selectin the client. Further, this enables a pretty slippery slope.
Isaac Vetter (May 08 2019 at 03:20):
It's much more likely that the two services have a relationship and should communicate directly with one another.
Isaac Vetter (May 08 2019 at 03:20):
In fact, if there's the same Clinical Reasoning engine, it seems important that the engine be able to maintain state. @Bryn Rhodes - is this the case?
Isaac Vetter (May 08 2019 at 03:20):
Lloyd McKenzie: If it was actually a resource, it would point to the order and be available
Isaac Vetter (May 08 2019 at 03:20):
Hey Lloyd, the specific need here is to enable a clinician to identify why generated clinical guidance isn't relevant. Sure, FHIR resources all the way down has many benefits, but our approach may also allow CDS Hooks to be specific about what's needed -- overrideReason, instead of a full DetectedIssue resource to communicate this information.
Isaac Vetter (May 08 2019 at 03:20):
@Thomas Reese - what do you think about exploring an extension that communicated the list (or ValueSet?) of override reasons in the card. The /analytics endpoint to actually receive this info is trickier.
Bryn Rhodes (May 08 2019 at 03:28):
@Isaac Vetter , that's true, once the clinician overrode, the service would track it, and could apply the override to the order-sign hook if it was appropriate for that user.
Lloyd McKenzie (May 08 2019 at 13:41):
@Isaac Vetter My point is that if an override is determined once, that override presumably applies for all subsequent invocations of the hook for that patient/order/context - including those that may happen in other sessions and possibly even for other users. The only way to manage that is if the override is persisted, and that probably means a resource.
Thomas Reese (May 08 2019 at 15:23):
This is what I envisioned and think it may be in use with the Opioids IG. For example, an overriding reason could be that the "patient was instructed to discontinue the first conflicting medication." This would be one in a ValueSet.
Bryn Rhodes (May 08 2019 at 21:35):
For the Opioid IG, we actually leave that up to local configuration, since different EHRs will likely do that differently and CDS Hooks didn't have a mechanism to communicate the override generically. That's why we'd be interested in working through the use case, we would definitely use that feature.
Isaac Vetter (May 15 2019 at 16:25):
Hey Guys, I updated our CDS Hooks 1.1 ideas wiki page to include override reasons and analytics.
Isaac Vetter (May 15 2019 at 16:25):
If we strip it down to the bare minimum, what do we need from an override reason? It's really just an array of human readable terms and maybe machine-readable ids ? Maybe a freetext comment? Would the CDS service dictate when a reason is required?
Rich Boyce (May 15 2019 at 18:09):
In the PDDI use case, the CDS service needs to relate order-select and order-sign hooks to avoid alerting, in the response to order-sign, something that was overriden in order-select. I am note sure if that implies that the override object would need to provide an additional field useful for such tracking (e.g., the HookInstance ID of the orderselect or the MedicationRequest id containing the trigger medication from the order-select). The Also, its not clear to me how the job the CDS Analytics endpoint would interact with the CDS Service. Is there a document I can read on that?
Josh Mandel (May 15 2019 at 20:39):
Cool! I added "actions" to the list.
Isaac Vetter (May 20 2019 at 20:06):
Hey @Rich Boyce,
Isaac Vetter (May 20 2019 at 20:06):
the CDS service needs to relate order-select and order-sign hooks to avoid alerting, in the response to order-sign, something that was overridden in order-select
Isaac Vetter (May 20 2019 at 20:06):
Totally makes sense. Further, it seems likely that many use-cases, in addition to PDDI would also benefit from knowing when to not alert the clinician during order-sign.
Isaac Vetter (May 20 2019 at 20:06):
The balloted version of the CDS Hooks specification included this (small) section on Suggestion Tracking Analytics. During HL7 ballot comment resolution it was removed due to a lack of maturity/implementations.
Isaac Vetter (May 20 2019 at 20:06):
This simplistic "analytics" proposal uses the card.suggestion.uuid as the unique id, (which I think makes sense instead of the MedRequest FHIR id or something else) and only informs the CDS service when a suggestion is accepted. To enhance this part of the spec, we'd need to define the structure of an override and also specify how an instance of an override is communicated back to the service.
Last updated: Apr 12 2022 at 19:14 UTC
