--- 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