The Sepsis Alert That Won't Stop Firing
A 600-bed hospital system licensed a vendor's sepsis early-warning model. The vendor reports AUC 0.89 on its validation set and a 6-hour median lead time. After eight months, internal audit finds the model flags 31% of admitted patients; nurses dismiss 70% of alerts within 10 seconds. Sepsis mortality in flagged patients has not improved, and the model's alert rate is 2.3x higher for patients over 75 and for those admitted on weekends. The vendor says the model is 'locked' and retraining is not permitted under the contract. Clinical leadership wants to keep it because 'it can't hurt to have more alerts.'
1. Was this an appropriate use case to deploy? Identify the impacts that should have been assessed before go-live and explain why alert volume is itself a patient-safety impact.
Read the worked answer
Assessment: The use case - clinical decision support for a time-critical condition - is plausible, but the deployment as configured is not defensible. Appropriateness is not established by vendor AUC alone; it depends on fit between the model's intended use, the local population, workflow, and decision consequences.
Impacts that should have been assessed before go-live:
- Clinical benefit and harm: expected true/false positives per 1,000 admissions, not just discrimination. A 31% flag rate implies many false positives.
- Alert fatigue: the cognitive and workflow burden on nurses, including time-to-dismiss and override behavior.
- Equity: subgroup performance by age, sex, race/ethnicity, language, and admission time.
- Workflow fit: who receives the alert, what action is expected, and whether the recommended action is feasible at 2 a.m. on a weekend.
- Automation bias and complacency: whether clinicians over-rely on the score or ignore it.
Why alert volume is a safety impact: 'More alerts' is not free. High false-positive rates train staff to dismiss alerts, which can cause misses when a true positive appears. Dismissal in under 10 seconds is a symptom of a system that has taught users the signal is noise. False positives also consume lab draws, antibiotics, isolation beds, and clinician attention. The leadership claim that it 'can't hurt' is therefore false: the harm is mediated by human behavior and resource diversion, not only by the model's direct output.
2. Diagnose likely causes of the 31% alert rate and the weekend/age disparity. Separate model limitations from deployment and sociotechnical factors, and state what evidence you would gather.
Read the worked answer
Model-side hypotheses:
- Prevalence shift: the local sepsis prevalence or case mix differs from the vendor's validation population, so a threshold tuned elsewhere produces a different alert rate.
- Label and feature drift: sepsis case definitions, lab ordering patterns, and EHR documentation changed over eight months.
- Calibration failure: the score may rank well but be miscalibrated, especially at the high-sensitivity threshold used.
- Subgroup performance: older patients may have different baseline labs and comorbidities; weekend admissions may have missing or delayed labs that the model imputes in ways that inflate risk.
Deployment/sociotechnical hypotheses:
- Threshold choice: operations set the alert threshold for sensitivity without calculating the false-positive burden.
- Weekend data pipeline: reduced staffing means fewer labs and vitals, producing missingness that the model handles poorly.
- Workflow: alerts may fire to the wrong role or at the wrong time, so true positives are dismissed along with false ones.
- Documentation differences: weekend admissions may be documented differently, affecting features derived from notes.
Evidence to gather: calibration curves overall and by subgroup; alert-level chart review (sample true/false positives); missingness rates by day of week; threshold sensitivity analysis; time-stamped workflow observation; comparison of local prevalence to vendor validation; and a shadow-mode run of a recalibrated threshold. This distinguishes a model that needs local calibration from one that is unsafe for the population.
3. Recommend a decision to clinical leadership. State conditions and a fallback if the vendor refuses retraining or subgroup reporting.
Read the worked answer
Recommendation: Do not continue full, unrestricted deployment. Move to a limited, monitored mode - shadow or silent mode, or a much higher threshold with mandatory human review - while the system is recalibrated and subgroup performance is established.
Conditions for any continuation:
- Local calibration and threshold analysis showing an acceptable false-positive burden per 1,000 admissions.
- Subgroup performance reporting by age, sex, race/ethnicity, language, and weekend/weekday, with a pre-agreed minimum performance floor.
- Workflow redesign so alerts reach the right role with a feasible action and a clear escalation path.
- Monitoring of alert volume, dismissal time, override reasons, and sepsis outcomes, with a kill switch.
- Contract amendment allowing local validation, access to model documentation, and performance reporting.
If the vendor refuses: treat the product as not procurable for this use. Decommission or replace it. A 'locked' model that cannot be locally validated or subgroup-reported is incompatible with clinical governance, regardless of its validation AUC. Document the decision, notify risk/legal, and preserve the audit trail. The fallback is not 'keep firing alerts'; it is 'stop using the tool until the evidence exists.'