Sepsis & clinical deterioration early warning

Sepsis and unrecognised deterioration kill patients mainly because treatment starts late. Early warning systems read the data hospitals already collect, estimate each patient's risk every few minutes and alert staff earlier than manual score-keeping. Evidence is real but uneven: well-integrated, prospectively evaluated systems have shown lower mortality, while poorly validated ones have missed most cases and caused alert fatigue. Implementation quality matters more than model choice.

Problem & value

• Today: wards use manual aggregate scores such as NEWS2 (Royal College of Physicians) or MEWS, recorded at intervals; sepsis screening uses SIRS/qSOFA/SOFA criteria. Deterioration is often noticed late, especially at night, on general wards and during staff shortages.
• AI value: use many more variables and their trends (not single thresholds), score continuously, surface the reasons for the alert, and trigger the sepsis bundle earlier (cultures, lactate, antibiotics, fluids).
• Evidence (mixed): the Epic Sepsis Model in an external validation at Michigan Medicine had poor discrimination (AUC 0.63) and missed about two thirds of sepsis patients while alerting many others [1]. In contrast, the TREWS system, evaluated prospectively across five hospitals, associated earlier treatment and lower mortality when clinicians confirmed alerts quickly [2]. The COMPOSER deep-learning model deployed in two emergency departments was associated with a reduction in sepsis mortality in a quasi-experimental study [3]. These are observational or quasi-experimental designs, so effect sizes should not be transferred to another hospital.
• Guidelines: the Surviving Sepsis Campaign 2021 recommends hospital sepsis screening programmes and advises against qSOFA as a single screening tool [4].

Variants

• Sepsis prediction (ED and ward): infection plus organ dysfunction (Sepsis-3).
• General deterioration: unplanned ICU transfer, cardiac arrest, death within 24-48 h (rapid-response triggers).
• ICU-specific: high-frequency waveforms, AKI, respiratory failure, shock prediction.
• Post-discharge and home: wearables and remote monitoring, see HLTH-007.

How it works

1. monitors / EHR / lab system (HL7 v2, FHIR, device gateways)
2. streaming ingest + normalisation (units, timestamps, missing-value handling)
3. feature engineering (last values, trends, time since last measurement, drugs, comorbidities)
4. risk model (gradient boosting / sequence model) + optional note-NLP features
5. calibrated risk + explanation (top contributing factors)
6. alert logic (thresholds, suppression, escalation rules)
7. nurse / physician review
8. bedside assessment
9. bundle or no action
10. feedback capture + monitoring of drift, alert burden, outcomes

• Models: most deployed systems are gradient-boosted trees or logistic/Cox-type models on structured data; deep sequence models (LSTM/Transformer) and note-derived features add some signal but need more validation effort. LLMs are used mainly for reading notes (infection suspicion) and for explaining alerts, not as the scoring core.
• Human-in-the-loop: the alert is decision support. Clinicians confirm or dismiss it; all treatment decisions stay with them. Dismissals with reasons are logged and used for tuning.
• Key design choices: prediction horizon, label definition (Sepsis-3 vs. billing codes), alert threshold chosen from capacity (alerts per nurse per shift), and who receives the alert.

Data preparation

A warning score needs continuous vitals, labs, medication, orders and sometimes notes. They live in the hospital information system, the patient data management system on ICUs, the lab system and bedside monitors, often with different time stamps and patient IDs. Typical gaps: vitals charted on paper and typed in late, missing values, inconsistent units, free-text nursing notes, device data not stored, no reliable sepsis labels and changing coding practices.

Preparation steps: (1) inventory data sources and owners (PREP-001, PREP-004); (2) connect systems through HL7/FHIR interfaces (PREP-005); (3) replace paper charts by digital capture at the bedside (PREP-008); (4) clean units, time stamps and patient IDs and tidy tables (PREP-011); (5) define the sepsis label with clinicians and harvest labels from coded cases and blood cultures (PREP-019, PREP-020); (6) build a retrospective test set for local validation (PREP-018); (7) pseudonymise extracts (PREP-022). Tools: FHIR servers, OMOP, Python data pipelines.

Data work usually takes well over half of the effort, because live data feeds and local validation are the hard part. See GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (hospital groups): Path A, because sepsis alerts are a high-risk, medical-device-type function and certified products with clinical validation exist.
• Public (municipal and university hospitals): Path A with certified products, because liability, conformity and procurement rules favour validated devices over in-house builds.
• Developer: Path C, because models on open vital-sign data sets (MIMIC, eICU) run on modest hardware and allow research and validation without cloud dependence.

Path A — Buy (recommended)

• EHR-embedded: Epic Sepsis Model (current version 2) and similar modules in other EHRs; check local validation before use [1].
• Specialised vendors: Bayesian Health (TREWS, US), Prenosis Sepsis ImmunoScore (US, FDA De Novo authorised 2024 [5]), Dascena (US), Philips patient-monitoring early-warning solutions (EU: Netherlands), Dräger (EU: Germany), and EU hospital IT vendors such as Dedalus (EU: Italy/France/Germany). Verify the CE status and MDR class of each product.
• Choose A when: the hospital lacks an ML team, and wants a certified product with vendor liability and a clear intended purpose.

Path B — Build on cloud APIs

• Healthcare data platforms with EU regions: Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake (FHIR stores) plus managed ML (Azure ML, Vertex AI, SageMaker) for tabular and time-series models.
• LLM APIs (EU regions or EU providers, e.g. Mistral) only for note summarisation or alert explanations; the scoring should stay a validated deterministic model. Needs a data processing agreement and hospital approval for cloud transfer of patient data.
• Building a scoring service for own clinical use means becoming a manufacturer of software as a medical device (see risks).

Path C — Self-host (open source)

• Data: FHIR server (HAPI FHIR), streaming (Apache Kafka, Flink), OMOP CDM with OHDSI tools.
• Models: XGBoost/LightGBM, scikit-learn, PyTorch; time-series with sktime; benchmark and baselines with the open YAIB framework (Yet Another ICU Benchmark) [6]. Open-weight LLMs (e.g. Llama, Qwen, Mistral families) for note features on HW2-HW3 if needed.
• Hardware: the core tabular scoring runs on CPU (HW1); GPUs only for note NLP or deep models.
• Hospital operations effort dominates: interfaces, monitoring, MLOps, clinical governance.

Path D — Custom training

Most research hospitals end up here: train and validate on local data to fit the case mix. Public datasets for development and benchmarking: MIMIC-IV and eICU (PhysioNet), HiRID (Zurich), AmsterdamUMCdb, and the PhysioNet/Computing in Cardiology Challenge 2019 on sepsis prediction [7]. Plan for tens of thousands of admissions, retrospective then silent (shadow) prospective validation, and a regulatory path if the model will be marketed or used beyond the research setting.

State of the art (2026)

• Best practice shifted from retrospective AUC to prospective, workflow-integrated evaluation; alert-to-action time and clinician trust determine the benefit [2][3].
• Label problems: models trained on billing codes or timing of antibiotics can learn clinician behaviour and "predict" what staff already suspect, which inflates performance. Use clinical definitions (Sepsis-3) and evaluate lead time before clinical recognition.
• Dataset shift: performance degrades with new patient populations, lab assays or practice changes; recalibration and drift monitoring are required, and external validation across hospitals is still rare.
• Limits: low positive predictive value for rare outcomes, alert fatigue, missing or delayed data, bias across subgroups, and automation bias if staff over-trust or ignore alerts.

Shared resources & combinations

• Same stack (tabular-ml + time-series + streaming): HLTH-007 remote monitoring, HLTH-020 population risk stratification, HLTH-013 ECG signals; the FHIR/OMOP data layer is shared with HLTH-028 terminology mapping.
• LLM layer: HLTH-018 chart summarisation and HLTH-003 clinical documentation supply note features and context.
• Natural combination: HLTH-004 clinical decision support (bundle guidance, antimicrobial stewardship) and HLTH-008 capacity planning (ICU transfers).

Effort, cost & KPIs

• Path A: 3-9 months incl. interface work, local validation and clinical governance; licence per bed or per hospital.
• Path B/C: 9-18 months with a data science, clinical informatics and quality-management team; cost is mostly people, data engineering and regulatory work, not compute.
• KPIs: sepsis mortality, time to antibiotics and to bundle completion, unplanned ICU transfers and cardiac arrests on wards, sensitivity and positive predictive value at the chosen threshold, alerts per 100 patient-days, alert acknowledgement time, calibration drift, subgroup performance.

People & change

Involve management and the medical director, then the heads of intensive care, emergency and wards (process owners), nursing leadership, IT and IT security, the data protection officer, legal and compliance, and the works council from the start. Nurses and physicians are the end users and must shape alert thresholds and escalation steps.

Works council: yes. A system scoring every inpatient and logging acknowledgement of alerts is objectively suited to monitor staff reactions, so §87(1) no. 6 BetrVG applies; §90(1) no. 3 and §80(3) support early information and an expert. Public hospitals involve the Personalrat. Agree that alert data are not used for individual performance review (GUIDE-004).

Data protection: health data and systematic evaluation call for a DPIA, AVV and DPO involvement (GUIDE-005). As a high-risk system, plan provider and deployer duties (GUIDE-014).

AI literacy: support staff with training on alert meaning, false alarms and automation bias (GUIDE-006). Pilot silently first on one ward, then with visible alerts, name nurse and physician champions, and address alarm-fatigue fears by tracking alert burden. Clinicians always decide on treatment (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: high-risk. Software with a medical purpose (diagnosis, prediction, monitoring) is a medical device under MDR (rule 11, usually class IIa or higher); when a notified body is required it is high-risk under Art. 6(1) with Annex I, with obligations on risk management, data governance, logging, transparency, human oversight and accuracy (Arts. 9-15) [8]. Application dates for these product-linked rules are later than for Annex III systems and have been subject to postponement proposals; confirm the current timetable. A hospital's in-house model is also subject to MDR in-house exemption conditions (Art. 5(5)) and national law.
• Deployers (hospitals): human oversight, monitoring, logging and AI literacy (Art. 4); inform affected staff.
• GDPR: health data is special-category (Art. 9); legal basis from care provision and national health law; DPIA (Art. 35) likely required; secondary use for training needs a separate basis, pseudonymisation and ethics approval; the European Health Data Space Regulation will shape secondary use of health data [9]. Alerts support but do not replace the clinician, which limits Art. 22 concerns.
• Safety risks: missed cases (false reassurance), alert fatigue, bias, drift, failure of data feeds. Mitigations: silent-mode validation, local calibration, fail-safe fallback to NEWS2, alert budget, subgroup audits, incident reporting, post-market surveillance.

Getting started

1. Define the clinical question (sepsis vs. general deterioration), setting, label and alert owner with clinicians; measure baseline mortality, time to antibiotics and alert burden.
2. Deploy auto-calculated NEWS2 in the EHR as a transparent baseline.
3. Check data availability and timeliness (vitals frequency, lab latency, FHIR/HL7 interfaces); build the data layer on OMOP/FHIR.
4. Run the candidate product or model in silent mode for 3-6 months; assess lead time, PPV and subgroup performance locally.
5. Go live on one ward with a rapid-response protocol, monitor KPIs and drift, then scale.

Sources

1. Wong A et al., External validation of a widely implemented proprietary sepsis prediction model in hospitalized patients, JAMA Internal Medicine 2021 — https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/2781307
2. Adams R et al., Prospective, multi-site study of patient outcomes after implementation of the TREWS machine learning-based early warning system for sepsis, Nature Medicine 2022 — https://www.nature.com/articles/s41591-022-01894-0
3. Boussina A et al., Impact of a deep learning sepsis prediction model on quality of care and survival, npj Digital Medicine 2024 — https://www.nature.com/articles/s41746-023-00986-6
4. Evans L et al., Surviving Sepsis Campaign: International Guidelines 2021 — https://www.sccm.org/survivingsepsiscampaign/guidelines-and-resources/surviving-sepsis-campaign-adult-guidelines
5. FDA, De Novo authorisation of Prenosis Sepsis ImmunoScore (2024), press announcement — https://www.accessdata.fda.gov/cdrh_docs/reviews/DEN230036.pdf
6. van de Water R et al., Yet Another ICU Benchmark (YAIB) — https://github.com/rvandewater/YAIB
7. Reyna M et al., Early prediction of sepsis from clinical data: PhysioNet/Computing in Cardiology Challenge 2019 — https://physionet.org/content/challenge-2019/
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. Regulation (EU) 2025/327 (European Health Data Space) — https://eur-lex.europa.eu/eli/reg/2025/327/oj
10. Royal College of Physicians, National Early Warning Score (NEWS) 2 — https://www.rcp.ac.uk/improving-care/resources/national-early-warning-score-news-2/