Designing Clinical Decision Support

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