Designing Clinical Decision Support

---
name: designing-clinical-decision-support
language: en
description: Creates CDS rule specifications with trigger conditions, evidence base, and alert fatigue mitigation. Use when designing CDS alerts, specifying clinical rules, or optimizing alert systems.
tags:
  - design
  - health-informatics
  - clinical
metadata:
  author: casemark
  practice_areas:
    - Health Informatics
    - Health IT
    - Clinical Informatics
  document_types:
    - Design Document
  skill_modes:
    - Design
---

# Designing Clinical Decision Support

Creates CDS rule specifications with trigger conditions, evidence base, and alert fatigue mitigation strategies. This skill covers the design lifecycle from clinical need identification through post-deployment monitoring for rules implemented in certified EHR systems.

## Why This Skill Exists

Poorly designed CDS is worse than no CDS at all. Alert fatigue from excessive, low-value interruptions causes clinicians to override 49-96% of drug interaction alerts, including clinically significant ones. Meanwhile, the absence of evidence-based CDS at critical decision points contributes to preventable adverse events. This skill structures CDS design to maximize clinical value while minimizing cognitive burden, following the CDS Five Rights framework: right information, right person, right format, right channel, right time in workflow.

---

## Checkpoint A --- Intake & Scoping

Answer every question before proceeding. Mark unknowns with [VERIFY].

1. **Clinical problem statement** --- What patient safety risk, quality gap, or regulatory requirement does this CDS address?
2. **Evidence base** --- What clinical guidelines, systematic reviews, or regulatory mandates support this rule? (Cite specific sources: USPSTF grade, ACC/AHA class, FDA safety communication)
3. **Target users** --- Which clinician roles should receive this alert? (Attending physician, resident, nurse, pharmacist, all prescribers)
4. **EHR platform and CDS engine** --- Which system will execute the rule? (Epic BPA, Cerner MPages, vendor-neutral CDS Hooks implementation)
5. **Workflow insertion point** --- At what point in the clinical workflow should the CDS fire? (Order entry, note signing, medication reconciliation, scheduling)
6. **Current override rate** --- If replacing or modifying an existing alert, what is the current override rate and documented reasons?
7. **CDS governance committee approval** --- Has the clinical informatics committee approved the concept?

### Required Documents

- Clinical guideline or evidence source document
- Current alert inventory for the target clinical domain (to assess overlap and fatigue burden)
- EHR CDS capability matrix (available trigger types, data elements accessible at runtime)
- Override reason code taxonomy currently in use
- Baseline quality measure data if the CDS targets an eCQM or HEDIS measure

---

## Step 1 --- Define Trigger Logic

Specify the computable conditions that activate the CDS rule:

- **Patient inclusion criteria** --- Demographics (age, sex), problem list entries (SNOMED CT concepts), active medication list (RxNorm CUIs), lab results (LOINC codes with value thresholds), encounter type
- **Action trigger** --- What user action initiates evaluation? (New order for drug class X, opening a patient chart, completing a flowsheet row)
- **Temporal conditions** --- Time-based logic (e.g., "no HbA1c result in past 90 days" requires date arithmetic against LOINC 4548-4)
- **Exclusion criteria** --- Conditions that suppress the alert: documented allergy contraindication, active hospice status, patient refusal on file
- **Boolean logic structure** --- Write the full trigger as a structured boolean expression:
  ```
  IF (active_medication IN [RxNorm class]) 
  AND (lab_result[LOINC] < threshold OR lab_result_age > 90d) 
  AND NOT (problem_list CONTAINS [SNOMED exclusion concept])
  THEN fire_alert
  ```

---

## Step 2 --- Design the Intervention

Structure the CDS output following the CDS Five Rights:

- **Alert type classification** --- Interruptive (hard stop, soft stop) vs. non-interruptive (info button, dashboard indicator, inbox message). Default to non-interruptive unless evidence supports interruption
- **Content specification** --- Write the exact alert text. Include: (a) what was detected, (b) why it matters with severity, (c) recommended action, (d) link to evidence. Keep below 3 sentences for interruptive alerts
- **Action options** --- Define the response buttons: Accept recommendation (with pre-populated order), Override with reason (from coded reason list), Defer/snooze (with time limit), Cancel triggering action
- **CDS Hooks integration** --- For SMART on FHIR CDS Hooks implementations, specify the hook type (patient-view, order-select, order-sign, medication-prescribe), the prefetch query, and the card response structure
- **Suggested actions** --- For order-based CDS, pre-populate the recommended order with appropriate defaults (dose, route, frequency) to minimize clinician effort

---

## Step 3 --- Assess and Mitigate Alert Fatigue

Before deployment, evaluate the fatigue impact:

1. **Estimated firing frequency** --- Query historical data to estimate how often the trigger criteria are met. Express as alerts per provider per shift
2. **Positive predictive value projection** --- Of estimated firings, what percentage represent truly actionable clinical situations?
3. **Tiering strategy** --- Classify severity: Tier 1 (hard stop, life-threatening), Tier 2 (soft stop, clinically significant), Tier 3 (informational, non-interruptive). Only Tier 1 and 2 justify interruption
4. **Duplicate/overlap check** --- Compare trigger logic against all existing active CDS rules. Identify rules that would fire on the same patient population and order type
5. **Suppression rules** --- Define auto-suppression for repeat firings (e.g., "do not re-fire this alert for the same patient within 24 hours if overridden")
6. **Override reason analysis plan** --- Design structured override reasons that produce analyzable data for post-deployment refinement

---

## Step 4 --- Specify Knowledge Maintenance

CDS rules are clinical content that requires lifecycle management:

- **Evidence review schedule** --- Define review frequency based on evidence velocity: annual for stable guidelines, quarterly for rapidly evolving domains (e.g., oncology protocols)
- **Trigger for urgent update** --- FDA safety communication, guideline withdrawal, formulary change, new contraindication
- **Version control** --- Each rule version gets a unique identifier with effective date, author, approving committee, and clinical evidence citation
- **Retirement criteria** --- Override rate > 90% for 3 consecutive months triggers mandatory review. Measure-based CDS retires when the quality measure is retired or topped out

---

## Step 5 --- Build and Test

Execute the CDS rule implementation:

- **Unit testing** --- Create test patients covering: positive trigger (alert fires correctly), negative trigger (alert correctly suppressed), boundary conditions (values at exact thresholds), exclusion criteria (alert suppressed for excluded populations)
- **Integration testing** --- Test within the full clinical workflow: place the triggering order, verify the alert appears at the correct workflow point, confirm the recommended action executes correctly
- **Performance testing** --- Measure alert rendering latency. CDS that takes > 2 seconds to display at order entry will be perceived as system slowness, not decision support
- **User acceptance testing** --- Have 3-5 representative clinicians walk through the alert in simulated encounters. Document feedback on clarity, actionability, and workflow disruption

---

## Step 6 --- Deploy and Monitor

Post-deployment surveillance is mandatory:

- **Phased rollout** --- Deploy to a pilot unit or provider group first. Monitor for 2 weeks before enterprise deployment
- **Monitoring metrics** --- Track daily: firing rate, override rate by reason code, acceptance rate, time-to-action after alert display, adverse events in the target population
- **Feedback channel** --- Establish a mechanism for clinicians to report CDS issues directly to the clinical informatics team (not just the IT help desk)
- **30-day review** --- Formal post-deployment review with the CDS governance committee. Present metrics, clinician feedback, and recommendations for tuning

---

## Checkpoint B --- Design Completeness Review

Before submitting for governance committee approval:

- [ ] Trigger logic is fully specified with coded data elements (SNOMED, LOINC, RxNorm)
- [ ] Evidence base is cited with guideline strength and quality rating
- [ ] Alert type (interruptive vs. non-interruptive) is justified with fatigue analysis
- [ ] Alert text is reviewed for clinical accuracy and health literacy
- [ ] Override reason codes are defined and mapped to the organization's taxonomy
- [ ] Suppression and de-duplication rules are specified
- [ ] Test cases cover positive, negative, boundary, and exclusion scenarios
- [ ] Knowledge maintenance schedule is defined with responsible owner
- [ ] Estimated firing frequency and PPV are documented

---

## Quality Audit

- [ ] CDS rule addresses a documented clinical need with evidence support (not vendor suggestion alone)
- [ ] Interruptive alerts are limited to Tier 1 and Tier 2 severity
- [ ] Estimated alert frequency does not exceed organizational threshold per provider per shift
- [ ] All coded elements use current terminology versions (SNOMED CT, ICD-10-CM, LOINC, RxNorm)
- [ ] CDS Hooks specification follows HL7 standards if applicable
- [ ] Override data capture is structured for post-deployment analysis
- [ ] Clinical informaticist and subject matter expert sign-off documented
- [ ] Post-deployment monitoring plan has defined metrics and review milestones
- [ ] Rule version is catalogued in the organizational CDS knowledge base

---

## Guidelines

- Default to non-interruptive CDS formats unless clinical evidence demonstrates that interruption prevents significant harm. The burden of proof is on the case for interruption, not against it
- Never deploy CDS rules without a defined retirement or review process. Orphaned rules are the primary driver of alert fatigue accumulation
- Use coded clinical data (SNOMED CT, LOINC, RxNorm) for all trigger criteria. Free-text triggers are fragile and unauditable
- Include the evidence citation in the alert display. Clinicians are more likely to accept recommendations they can verify
- Design CDS as a system, not individual rules. Every new rule must be evaluated against the existing rule inventory for interaction effects
- Track the override rate as a signal, not a problem. High override rates indicate poor rule design, not poor clinician behavior
- For CDS Hooks implementations, minimize prefetch data to what the rule actually needs. Over-fetching degrades FHIR server performance
- Maintain alignment with ONC certification criterion 170.315(a)(9) for CDS configuration requirements