Stream: cds hooks
Topic: Defining request triggers
Thomas Reese (Oct 29 2018 at 21:17):
Problem: There is a need to further define CDS Hooks triggering events within a workflow to better align with clinicians’ information needs.
Rationale: Relevant to medication order entry, common steps in the process include select product, dose, frequency, route, administration instructions, and accept. The proposed CDS Hooks spec 1.0 includes medication-prescribe and order-review, which are ambiguous on which event triggers the request. This may confuse CDS implementers and EHR vendors on what data is available within the context of a request. Currently order-review workflow is defined as, “The user is in the process of reviewing a set of orders to sign.” And the medication-prescribe workflow is defined as, “The user is in the process of prescribing one or more new medications.” Medication orders are typically entered individually, and “reviewing” is not necessarily the term used for the task. Moreover, “in the process of prescribing” does not delineate the discrete step in the task. The provided medication-prescribe example (https://cds-hooks.org/hooks/medication-prescribe/) is of a context MedicationRequest (STU3) and MedicationOrder (DSTU2) with most fields populated (e.g., dose, frequency, route, administration instructions), so this does not clarify the time when a request is triggered.
Proposal: The medication-prescribe hook could be characterized as the final action (e.g., Accept) for a unique medication order task. This seems to align with the term medication-prescribe. Whereas, a medication-select hook could be characterized as selecting the medication or medication product. EHR implementers typically map Medi-Span or First DataBank lists to medications available at the institution, which allows for a medication product dropdown list.
Use case: Below is a workflow figure of each triggering event. Further information on Potential Drug-Drug Interaction CDS Hooks triggers and implementation is available at: http://hl7.org/fhir/uv/pddi/2018Sep/start.html.
PDDI-implementation-guide-CPOE-workflow-1.png
Lloyd McKenzie (Oct 29 2018 at 21:18):
I don't think it's safe to assume that those decisions will always happen in a particular order
Doug Martin (Oct 30 2018 at 11:34):
I don't think that is the point here. Certainly the initial (select) and final (commit) events are pretty much set. The intervening events could occur in pretty much any order and some not at all, but the point, I believe, is the need for more fine-grained triggers so that CDS can be more fine grained as well.
Lloyd McKenzie (Oct 30 2018 at 14:12):
Most CDS is going to need to trigger once particular combinations of these things are known. And whenever they're changed. If the intention is that you'd subscribe to all of the events that involve changing any of the fields that might impact your decision, I guess that works, but I'm not sure the end result is going to be terribly different than "receive an event any time the draft prescription is changed"
Thomas Reese (Nov 01 2018 at 21:51):
Thank you @Doug Martin for the clarification and @Lloyd McKenzie for the comment. With the medication order use case, CDS can be performed and is needed at the first step of a specific order (e.g., select medication product) and at the final step (e.g., Accept). Currently, most medication CDS is only performed at the final step. The steps between will likely vary by implementation and medication, but it is fairly safe to assume the frequency, route, and administration instructions wouldn't be entered before the medication. Certain elements of the context resource (e.g., MedicationRequest) may be empty at the medication-select trigger. This is acceptable since the majority of CDS can be performed with only the medication product available. The motivation/win for this approach is to align CDS knowledge with clinician needs earlier in the task workflow.
Josh Mandel (Nov 02 2018 at 02:00):
The medication prescribe hook is intended to support calling repeatedly over the course of a prescribing action, each time being passed the full details of the prescription as far as they're known up to that point. So even if we do not model the sequence as having a particular start and end with specific steps in between, an external decision support service can still provide fine-grained advice. At least that's the theory; are you struggling to make this work successfully?
Guilherme Del Fiol (Nov 02 2018 at 15:23):
There was a lot of confusion about medication-prescribe and order-review at the last FHIR connectathon and subsequent WGM. The problem I see with "medication-prescribe" is that the definition is ambiguous. "The user is in the process of prescribing one or more new medications." Different people were interpreting this as the user selecting a medication or submitting/accepting//signing a final prescription. "order-review" is also ambiguous. First, the name and definition imply that order-review can be used with any order, not only meds. Second, "review" implies that this hook should be trigger when the clinicians is reviewing a list of orders prior to signing as opposed to when they click the "sign" button. I like @Thomas Reese proposal because it is anchored on an explicit definition of the workflow.
Another point of confusion at the connectathon is how to handle this workflow in CPOE systems, where medication orders are entered at the same time as other orders.
Last updated: Apr 12 2022 at 19:14 UTC
