Local Validation of a Sepsis Prediction Algorithm Before Go-Live
A 1,400-bed hospital group plans to deploy a vendor sepsis prediction model (EHR-based, 48-hour horizon) across six wards. The vendor reports an AUC of 0.82 and a positive predictive value of 0.31 at the recommended threshold, based on United States data. In a three-month silent run covering 4,100 admissions in Hong Kong, the model fires on 38% of admissions at the vendor threshold; positive predictive value is 0.09 and sensitivity for Sepsis-3 is 0.71. The model uses vital signs, white cell count, lactate and age, and was trained where documentation and blood-culture ordering patterns differ. Nurses report alert fatigue, and 62% of alerts are dismissed within 30 seconds. The vendor offers quarterly recalibration on hospital data under a 'continuous learning' clause. The clinical AI governance group must decide whether to go live.
1. Evaluate the local validation results. Why is the AUC an insufficient basis for a decision, and which metrics should drive it?
Read the worked answer
The AUC describes ranking ability across all thresholds; the wards experience one threshold and its consequences.
- What the local data show. At the vendor threshold, 38% of 4,100 admissions generate an alert - roughly 1,560 alerts in three months, or about 17 per day across six wards. With a PPV of 0.09, about nine of every ten alerts are false positives. Sensitivity of 0.71 means the model misses roughly three in ten Sepsis-3 cases, so it cannot be used as a rule-out.
- Why the AUC misleads here. AUC is prevalence-independent and threshold-independent. The US PPV of 0.31 and the local 0.09 can coexist with similar AUCs if prevalence, case mix, documentation timing or lactate ordering differ. The decision-maker needs calibration (predicted versus observed risk), PPV at the intended operating threshold, sensitivity, and the alert burden per bed-day.
- Use decision-curve or net-benefit analysis. Weigh the number of true alerts against the workload of false alerts and the harm of missed cases. Also examine the timing: a 48-hour horizon alert that arrives after the clinician has already acted adds nothing.
- Subgroup analysis. Check performance in the elderly, immunocompromised and post-operative patients, and on wards with different documentation intensity; an average can hide a ward where the model is harmful.
- Conclusion. On these results the model is not deployable at the vendor threshold. The question is not whether the AUC is good, but whether any threshold gives an acceptable balance of alert burden and missed cases in this hospital.
2. What conditions would you require before any go-live, and how would you structure the decision?
Read the worked answer
A conditional, staged deployment with a pre-agreed stop rule, not a binary yes/no.
- Threshold recalibration on local data. Choose an operating point that yields an alert burden the wards can absorb - for example, a target of a few alerts per ward per day - while keeping sensitivity acceptable. Present the trade-off curve to the clinical leads and let them choose.
- Workflow and human factors. Define exactly what the alert asks the clinician to do, who receives it, at what time of day, and how it is acknowledged. An alert with no actionable pathway is noise. Co-design with nurses and junior doctors; test in a simulated shift.
- Extended silent or shadow mode. Run for longer with an agreed evaluation plan, and include the alert in the display without triggering action until the threshold and workflow are settled.
- Governance and accountability. Name a clinical owner and an engineering owner, document the intended use, and record the model version and training data in a model card. Assess whether the software is a medical device (SaMD) and, if so, how it is listed under MDACS and what change-control obligations follow.
- Regulatory and quality artefacts. Apply IEC 62304 lifecycle processes for the software and ISO 14971 risk management for the clinical use, including failure modes such as missed data, interface downtime or silent model drift. Check the Personal Data (Privacy) Ordinance position for the data feeds and any vendor access.
- Contract. Require transparency on model changes, local performance reporting, data ownership and exit provisions.
- Stop rules. Pre-agree what performance or safety signal triggers suspension - for example, sustained PPV below an agreed floor, or an alert burden above an agreed ceiling.
3. How should the 'continuous learning' recalibration clause be governed after go-live?
Read the worked answer
Continuous learning is a change-control obligation, not a maintenance task.
- Lock the version. Every deployed model must have an identifiable version, with a record of what changed, when, and who approved it. No silent updates.
- Define what counts as substantial change. Recalibration on local data, new input variables or a new threshold are all changes that could alter performance or safety. Assess each against the risk management file and the regulatory position, and notify the regulator where required.
- Validate before and after. Validate any recalibrated model on a held-out local dataset before deployment, then monitor prospectively against the pre-agreed metrics: calibration, PPV, sensitivity, alert burden and time-to-antibiotics. Compare with the version being replaced.
- Monitor for drift. Track input data completeness, coding changes and seasonal effects. A rise in missing lactate values, or a new triage template, can degrade performance without any change to the model.
- Beware feedback loops. Once clinicians act on alerts, blood cultures are ordered differently, which changes the labels the model learns from. Document this and avoid retraining on data shaped by the model without adjustment.
- Independent review. Have a standing clinical AI review group examine quarterly performance reports, and record its decisions. The vendor's report should not be the only evidence.
- Exit and rollback. Keep the ability to revert to a previous version and to switch the system off entirely; test that ability before it is needed.