Section 7.5: Optimization and Lifecycle Retirement

7.5.1 The “Why”: CDS is a Living Therapy, Not a Static Monument

There is a dangerous misconception that can take root in even the most well-intentioned informatics teams: the idea that a Clinical Decision Support (CDS) rule, once built and validated, is “done.” This is a profound error in thinking. A CDS rule is not a brick-and-mortar monument, built once and expected to stand unchanged for decades. A far more accurate and professionally responsible metaphor is that a CDS rule is a living therapy. Like any potent medication, it must be continuously monitored for efficacy and side effects, its dosage must be adjusted in response to new data, and, most importantly, it must be discontinued when it is no longer beneficial or has been supplanted by a superior alternative.

The clinical environment is in a constant state of flux. Medical evidence evolves, new guidelines are published, formularies change, and clinical workflows are redesigned. A CDS rule that was perfectly aligned with best practices on the day it went live will inevitably experience “clinical relevance decay.” Its logic will slowly drift out of sync with the ever-changing reality of patient care. If left untended, this once-helpful tool can become a source of outdated advice, a generator of clinical noise, or a barrier to the adoption of new, evidence-based practices. At best, it becomes an ignored annoyance; at worst, it actively promotes suboptimal care.

This final section of our module is dedicated to the most advanced and strategic aspect of CDS management: the governance of its complete lifecycle. You will learn that the work you performed in monitoring and analysis is not an end in itself, but the beginning of a continuous quality improvement cycle. We will provide a structured framework for using that data to methodically optimize and tune your rules—the “dose adjustments” of CDS. And, crucially, we will detail the formal process for retiring rules that have reached the end of their therapeutic life. Mastering this discipline elevates you from a rule builder to a true CDS portfolio manager, a digital steward responsible for the health, efficacy, and safety of the institution’s entire library of clinical logic.

7.5.2 The Optimization Engine: The Plan-Do-Study-Act (PDSA) Cycle

Effective CDS optimization is not a random, haphazard process. It is a rigorous, scientific methodology for continuous quality improvement. The most widely adopted and effective framework for this is the Plan-Do-Study-Act (PDSA) cycle. This simple but powerful model provides a structured approach to take the data from your audit logs, turn it into a hypothesis for improvement, test that hypothesis, and implement the change in a controlled manner.

As a pharmacy informaticist, you will live in this cycle. It will be the engine that drives the evolution and refinement of every rule in your portfolio.

Applying the PDSA Cycle: Our Levofloxacin Rule Example

Let’s walk our levofloxacin rule through a formal PDSA cycle based on the data we analyzed in the previous section.

• PLAN:
  • Problem Identification: The acceptance rate (73.3%) is below our target of 85%.
  • Data Analysis: The override reason analysis clearly shows that 45% of overrides are due to the alert firing in patients with AKI, where Cockcroft-Gault is invalid.
  • Hypothesis: We hypothesize that by adding a logic condition to suppress the alert for patients with evidence of AKI, we can reduce alert noise and increase the acceptance rate for the remaining, more relevant alerts.
  • The Plan: Propose a change to the rule’s pseudo-code: “ADD EXCLUSION: AND NOT (Patient’s Serum Creatinine has increased by > 0.3 mg/dL in the last 48 hours)”. Obtain P&T committee approval for this planned change.
• DO:
  • An informaticist goes into the EHR’s test environment. They open the rule `[PHA] Renal Dosing – Levofloxacin`. They add the new logic condition exactly as planned. They document the change in the rule’s metadata. The rule status remains “Test”.
• STUDY:
  • Phase 1 (Testing): The informaticist creates a new negative test case: “PHA-LRD-09 (Negative – AKI)”. This test patient has a baseline creatinine of 1.0 and a current creatinine of 1.5. They run the test and verify that the alert is correctly suppressed. They also re-run all previous positive and negative test cases to ensure the change did not break any existing logic (this is called regression testing).
  • Phase 2 (Deployment): After successful testing, the rule is activated in the production environment.
  • Phase 3 (Data Collection): We allow the updated rule to run for another 30 days, collecting a new set of audit log data.
  • Phase 4 (New Analysis): We re-calculate our KPIs with the new data. We find the acceptance rate has increased to 89%, and the total number of alerts has decreased by 40%. Our hypothesis is confirmed.
• ACT:
  • Adopt: The change was successful and is now the new standard for this rule. The optimization cycle is complete. We will continue our standard monthly monitoring.
  • Adapt: If the acceptance rate only improved to 78%, we might adapt our strategy. Perhaps the AKI definition needs to be more sensitive? We would start a new PDSA cycle with a refined plan.
  • Abandon: If the change had no effect or a negative effect, we would abandon it. We would deactivate the new logic (reverting to the previous version) and return to the “Plan” phase to form a new hypothesis based on a deeper analysis of the data.

7.5.3 Masterclass: The Science of Rule Retirement

In a mature CDS program, the decision to retire a rule is as important, and should be as data-driven, as the decision to build one. An unmanaged library of old, irrelevant, and low-value alerts is a primary driver of alert fatigue and physician burnout. Proactive “weeding” is a critical informatics function. However, it must be done through a formal, safe, and well-communicated process. Simply turning off alerts without due diligence can re-introduce risks the rule was designed to prevent.

Triggers for a Retirement Review

Retirement should be considered when a rule meets one or more of the following criteria. This is often reviewed on a scheduled basis (e.g., annually) by the CDS governance committee.

Retirement Trigger	Description	Example
Clinical Obsolescence	The underlying clinical guideline that the rule is based on has been significantly revised or withdrawn.	A rule enforcing the JNC-7 blood pressure guidelines is now obsolete. It must be retired and replaced with a new rule based on the current ACC/AHA guidelines.
Persistently Poor Performance	Despite multiple optimization attempts (PDSA cycles), a rule’s acceptance rate remains unacceptably low (< 30-40%).	A drug-interaction alert between warfarin and broccoli consistently has a 5% acceptance rate. After multiple attempts to make it more specific, it’s clear clinicians do not find it valuable. It should be retired to reduce noise.
Formulary or Workflow Change	The medication, lab test, or clinical workflow the rule is based on has been removed or fundamentally changed.	A dosing alert for a specific antibiotic is no longer needed after that antibiotic is removed from the hospital formulary.
Redundancy / Consolidation	A new, more sophisticated rule or EHR feature has been implemented that makes an older, simpler rule redundant.	Three separate, simple alerts for different statins can be retired and replaced by a single, more elegant rule that checks for the ‘HMG-CoA Reductase Inhibitors’ therapeutic class.

The Formal CDS Retirement Protocol

Once a rule has been flagged for potential retirement, it must go through a formal decommissioning process.