Clinical Decision Support and CPOE

September 2008 - Vol. 5 No. 9

While the functionality and limitations differ between systems, the challenge with any CDS tool is developing a solution that provides the most value to the CPOE user while simultaneously improving patient safety. In choosing a CDS tool, you need to have a thorough understanding of the features that you will utilize.

CDS Features to Consider

The expert rule engine you use (either as an add-on or a pre-built module for your existing system) should have sufficient flexibility to allow an analyst a wide variety of options and potential areas where an expert rule could be utilized. Following are some of the functions an expert rule should be able to perform:

■ Evaluate lab results for a specific lab and value

■ Check for updated/added allergies

■ Review patient orders for specific type(s) of orders

Programming Complexity

It is important to determine the difficulty level for programming an expert rule in your system. Ideally, the required programming skill sets would not exceed your current staffs’ capabilities. If you do not have sufficient expertise in-house, consider sending at least two staff members to a training course.

Establish the level of interactivity you want from your expert rules. Can a rule make available a combination of functions to provide the best features and value? For example, in a multi-facility organization, you may want to perform PCA max dose checking in Facility A and B, but not in Facility C or D. Table 1 lists some types of expert rules based on their level of complexity and feature set (see page 16).

Impact on System Response Time

When developing an expert rule, the programmer should consider the impact of the rule on system response time. Because CPOE can increase the time it takes for a provider to place an order, an expert rule that results in an even more dramatic time increase may negatively impact the provider’s perception of the rule’s value.

Alert Fatigue

Alert fatigue is a potential problem with CPOE. In a paper-based system, when an order is written for acetaminophen 650 mg PO every six hours as needed for mild pain and the patient has an allergy to acetaminophen, the prescriber will not be alerted at the time of writing the order. With CPOE, prescribers will receive multiple alerts including drug-allergy, drug-drug interaction, and drug duplicate alerts. At some point,the user will become desensitized or fatigued by these alerts and their effectiveness will be reduced. This fatigue could lead to a medication error.

Using expert rules, it is possible to evaluate alerts and develop rules that have a higher degree of clinical relevance.  This will help reduce alert fatigue and provide a system that will help ensure patient safety.  Users will recognize the need to pay extra attention to alerts, rather than automatically closing them out.

Consider a rule where users are projected to change the order 10% of the time, with minimal improvement on patient safety. This rule may not be desirable. On the other hand, if a user is expected to change an order 80% of the time for improved patient care, there is obvious value to the rule and the alert.

Criteria for Establishing Rules

One of the challenges with any expert rule engine is determining the types of rules to implement. For the most part, you want to rely on the users to suggest possible options for an expert rule. Keep in mind you may also need to consider a business need that drives the creation of an expert rule without the request of users. In either case, user involvement is imperative for a multitude of reasons to ensure a successful expert rule.

Any request for an expert rule should be evaluated to see if other options are available. For example, can screen tailoring achieve the desired result? User involvement is crucial in this step because they may have a specific workflow that will not support a screen tailoring solution.

Committee approval: An expert rule should go through a variety of approval processes as determined by policies or procedures. It may also be worthwhile to form an internal group of analysts to evaluate each new request.They may be able to offer alternate solutions that eliminate the need for a new rule.

Rule design and testing: Before the rule is coded, a functional specifications sheet should be requested from the user. This functional spec sheet should describe how the rule is to function, the rule triggers, and the expected outcome. After the programmer codes the rule based on this functional spec sheet, the user then tests it for functionality. Having a user involved throughout rule development and testing is key to success and helps ensure user acceptance. The user is also asked to determine if any communication to the other system users is necessary. If communication is needed, the user is asked to develop the notification message.

Roll out: Your facility should develop internal guidelines,which address where the rule should be built and when it should be moved to the production (or live) environment. We perform rule validation at every migration point to ensure that the migration process is correct and to flush out any components of the rule that were missed. This increases confidence that when the rule is moved to the production environment, there won’t be any issues.Prior to production migration, an e-mail and system bulletin are sent out to inform users of the new rule functionality, which contains the information submitted by the user.

Finally, user involvement can help decrease the time to market of an expert rule and reduce any re-coding of the rule. Table 2 lists some examples of expert rules and the reasons they were developed.

Examples of Expert Rules

The following is a short list of rules that we have developed to assist our CPOE users. While these examples may not apply to your organization, they provide an outline of what to consider.

Neonatal Intensive Care Unit (NICU) Dose Calculation

The NICU physicians requested the ability to enter a baby’s weight and drug dosage in mg/kg and then have the computer system calculate the dose. Through the combined use of screen tailoring and an expert rule, we were able to provide this capability. Without the use of this expert rule, the NICU physicians would have continued manually calculating these results prior to entering the order. This rule has improved workflow.

Patient Identification Check

We use an expert rule that displays the patient name, date of birth, and medical record number in a pop-up window at the time of order entry. This serves as a double check allowing the user to validate that they have selected the right patient.

Allergies Updated Prior to Order Placement

With this expert rule, for patients with no documented allergies or those for whom allergies have not been updated for the current admission, the user cannot place orders until the allergies have been addressed. This helps ensure that drug-allergy checks are accurate and up-to-date.

Epidural Order and Conflicting Drugs

This rule was developed to address the scenario of a patient being placed on an epidural followed by additional orders for a narcotic or sedative. In this case, the patient could receive an unintended amount of a sedating drug, possibly leading to respiratory depression. Additionally, if an epidural is placed and an order for an anticoagulant is entered, this rule informs the user that an active epidural and a concurrent anticoagulant are not recommended. This rule was designed to function in two different scenarios:

1. When an epidural order is placed, the rule will scan the patient’s medication profile for any narcotic, sedative, or anticoagulant medication order. If any of these medications have been ordered for the patient, a pop-up warning message will alert the prescriber.

2. When a narcotic, sedative, or anticoagulant order is placed, the rule will scan the patient’s medication profile for any epidural order. If the patient is on an epidural, the user will be required to contact a specific group (i.e., pain service) and obtain approval to enter the medication order. The user is also required to document this approval on the medication order.

Heparin Drip and aPTT/hPTT Lab Orders

Our facility has different cutoff values for the aPTT result, dependent upon whether the patient is on a heparin drip. This rule will display an alert message to the user if they attempt to place a standard aPTT lab order on a patient with an active heparin drip order. Conversely, if the patient is not on a heparin drip and the user attempts to place a heparin aPTT(hPTT), the rule informs them to order the aPTT instead.

Monitoring Rule Effectiveness

When considering a new rule, it is important to evaluate its effectiveness prior to implementation. For example, with our heparin hPTT rule,we are tracking every time the rule is fired. Our goal is to see an increase in the hPTT orders for patients on a heparin drip, with a concurrent decrease inthe aPTT orders for the same patients. Over time, as prescriber behavior is modified by the alert system, this rule should fire less and less as the users will know to order the hPTT for patients on a heparin drip.


CPOE offers the ability to provide real time, clinically relevant information to the prescriber. CPOE also introduces workflow concerns not seen with paper orders. Effective implementation of a clinical decision support system and utilizing an expert rule engine provides the user with meaningful alerts that ultimately help the user ‘do the right thing’when it comes to patient safety and improving quality of care. ■

Chad Lowry, PharmD, earned a Doctor of Pharmacy degree from Idaho State University College of Pharmacy and currently serves as a Computerized Physician Order Entry (CPOE) Pharmacy Consultant at The Health Alliance in Cincinnati, Ohio.


Like what you've read? Please log in or create a free account to enjoy more of what has to offer.

Current Issue

Enter our Sweepstakes now for your chance to win the following prizes:

Just answer the following quick question for your chance to win:

To continue, you must either login or register: