In a recent post I realized that I had never explained how to add events to the Pharmacy system for use with the Rules Engine. Time to remedy that. In fact, I’m going to take it to another level and show you:
– Setting up rules to fire off patient monitor alerts in Siemens Pharmacy, both from pharmacy driven rules, and Soarian side workflows calls.
– Creating pop up alerts that interrupt medication validation in pharmacy.
– Pulling pharmacy data into Soarian side workflow processes.
– Pulling Soarian data into pharmacy side rule processes.
– Setting up Pharmacy medication triggers in Character Cell.
So get ready, if you were wondering how the Rules Engine works pharmacy side, this is the update you’ve been waiting for.
First the Scenario
Imagine you had a request to check to see if a patient with a spinal catheter had an anticoagulant ordered, or a patient on an anticoagulant had a spinal catheter ordered. Big tubes coming out of your back plus drugs that keep you from clotting equals a bad time. In such a situation an alert should appear in pharmacy. This is especially important because spinal catheters are non-medication orders, so without the alert the pharmacists won’t know that one has been placed on the patient.
Before going further, it’s worth noting that there are two different types of Pharmacy alerts: those that appear on the patient monitor or on a patient when a pharmacist first loads their patient profile, and another that appears as an action (in this case a medication being placed) occurs. The first is persistent, but doesn’t interrupt processing. The other pops up right away, but is gone as soon as it’s dismissed.
This is important because in this situation we don’t know how the conflict is going to arise. The anticoagulant could be placed first, and then a spinal catheter order is placed in Soarian, or the spinal catheter order is placed and then the anticoagulant medication is ordered (or the order is validated) in Siemens Pharmacy. Only if the conflict is discovered as the anticoagulant is being validated will a pop-up alert be of any use, or will the event we create Pharmacy side even fire. So then how to you get the persistent alert on the patient if the conflict is triggered by spinal catheter event? Well, then you’ve got to fire the Pharmacy alert using a Soarian side event subscription (aka a workflow). Don’t worry. We’re goign to cover all of this, but let’s start with:
The Patient Monitor Alert – When Driven by Spinal Catheter Order
Not seen above is the non-medication order subscription. Then we only continue if the order type is one of the spinal drain types we care about. Then we need a rule that can access medication orders in order to see if the patient is on any of these listed anti-coagulants. Here’s a look at the qualifier for such a rule.
Note that this is a Pharmacy side qualifier, not a Soarian side one. This is because medications placed within pharmacy, but not yet administered, will not show up in the Soarian side database, so this will give us more complete information. And here’s the rule code:
Additionally, we a rule to fire off the Patient Monitor alert. I recommend using a sub rule that can be called directly from Pharmacy side rules, or from Soarian side using a wrapper rule that will put the patient data in the correct format for Siemens Pharmacy. Here’s the wrapper rule code:
If you don’t want to write your own custom rule for writing out the alert, you can always call the model rule SUB_WRITE_TO_RX_ALERT instead. The alert will end up looking like this in the Pharmacy system:
I’ll go over the way to add Pharmacy side events to trigger rules (and tie them to medications) and how to fire the pop-up alerts in Siemens Pharmacy in the part 2.