Frühwarnsystem für Sepsis und klinische Verschlechterung

Sepsis und unerkannte Verschlechterung töten Patienten vor allem deshalb, weil die Behandlung zu spät beginnt. Frühwarnsysteme lesen die Daten, die Krankenhäuser ohnehin erheben, schätzen das Risiko jedes Patienten alle paar Minuten und alarmieren das Personal früher als eine manuelle Score-Führung. Die Evidenz ist real, aber uneinheitlich: Gut integrierte, prospektiv evaluierte Systeme haben eine geringere Sterblichkeit gezeigt, während schlecht validierte die meisten Fälle verpasst und Alarmmüdigkeit verursacht haben. Die Qualität der Umsetzung zählt mehr als die Wahl des Modells.

Problem & Nutzen

• Heute: Stationen nutzen manuelle Summenscores wie NEWS2 (Royal College of Physicians) oder MEWS, die in Abständen erfasst werden; das Sepsis-Screening nutzt die Kriterien SIRS/qSOFA/SOFA. Eine Verschlechterung wird oft spät bemerkt, besonders nachts, auf Normalstationen und bei Personalmangel.
• KI-Nutzen: deutlich mehr Variablen und ihre Verläufe nutzen (nicht einzelne Schwellenwerte), fortlaufend bewerten, die Gründe für den Alarm anzeigen und das Sepsis-Bündel früher auslösen (Kulturen, Laktat, Antibiotika, Flüssigkeit).
• Evidenz (gemischt): Das Epic Sepsis Model zeigte in einer externen Validierung an Michigan Medicine eine schlechte Trennschärfe (AUC 0,63) und verpasste etwa zwei Drittel der Sepsis-Patienten, während es bei vielen anderen Alarm schlug [1]. Dagegen brachte das System TREWS, prospektiv an fünf Krankenhäusern evaluiert, frühere Behandlung und geringere Sterblichkeit in Verbindung, wenn Kliniker Alarme zügig bestätigten [2]. Das in zwei Notaufnahmen eingesetzte Deep-Learning-Modell COMPOSER wurde in einer quasi-experimentellen Studie mit einer Verringerung der Sepsis-Sterblichkeit in Verbindung gebracht [3]. Dies sind Beobachtungs- oder quasi-experimentelle Designs, daher sollten Effektgrößen nicht auf ein anderes Krankenhaus übertragen werden.
• Leitlinien: Die Surviving Sepsis Campaign 2021 empfiehlt Sepsis-Screening-Programme in Krankenhäusern und rät von qSOFA als alleinigem Screening-Instrument ab [4].

Varianten

• Sepsis-Vorhersage (Notaufnahme und Station): Infektion plus Organdysfunktion (Sepsis-3).
• Allgemeine Verschlechterung: ungeplante Verlegung auf die Intensivstation, Herzstillstand, Tod innerhalb von 24-48 h (Auslöser für Rapid Response).
• Intensivspezifisch: hochfrequente Wellenformen, akutes Nierenversagen, respiratorisches Versagen, Schockvorhersage.
• Nach der Entlassung und zu Hause: Wearables und Fernüberwachung, siehe HLTH-007.

So funktioniert es

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

• Modelle: Die meisten im Einsatz befindlichen Systeme sind Gradient-Boosted Trees oder logistische/Cox-artige Modelle auf strukturierten Daten; tiefe Sequenzmodelle (LSTM/Transformer) und aus Notizen abgeleitete Merkmale liefern etwas zusätzliches Signal, erfordern aber mehr Validierungsaufwand. LLMs werden hauptsächlich zum Lesen von Notizen (Infektionsverdacht) und zur Erklärung von Alarmen eingesetzt, nicht als Kern der Bewertung.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Alarm ist Entscheidungsunterstützung. Kliniker bestätigen oder verwerfen ihn; alle Behandlungsentscheidungen bleiben bei ihnen. Verwerfungen mit Begründung werden protokolliert und für die Feinabstimmung genutzt.
• Zentrale Designentscheidungen: Vorhersagehorizont, Definition des Labels (Sepsis-3 vs. Abrechnungscodes), Alarmschwelle nach Kapazität gewählt (Alarme je Pflegekraft und Schicht) und wer den Alarm erhält.

Datenaufbereitung

Ein Warnscore benötigt kontinuierliche Vitalwerte, Laborwerte, Medikation, Anordnungen und teils Notizen. Sie liegen im Krankenhausinformationssystem, im Patientendatenmanagementsystem der Intensivstationen, im Laborsystem und in Bettplatzmonitoren, oft mit unterschiedlichen Zeitstempeln und Patienten-IDs. Typische Lücken: auf Papier dokumentierte und verspätet eingetippte Vitalwerte, fehlende Werte, uneinheitliche Einheiten, Freitext-Pflegenotizen, nicht gespeicherte Gerätedaten, keine verlässlichen Sepsis-Labels und wechselnde Kodierpraxis.

Schritte der Aufbereitung: (1) Datenquellen und Verantwortliche erfassen (PREP-001, PREP-004); (2) Systeme über HL7-/FHIR-Schnittstellen verbinden (PREP-005); (3) Papierkurven durch digitale Erfassung am Bett ersetzen (PREP-008); (4) Einheiten, Zeitstempel und Patienten-IDs bereinigen und Tabellen aufräumen (PREP-011); (5) das Sepsis-Label mit Klinikern definieren und Labels aus kodierten Fällen und Blutkulturen gewinnen (PREP-019, PREP-020); (6) einen retrospektiven Testdatensatz für die lokale Validierung aufbauen (PREP-018); (7) Extrakte pseudonymisieren (PREP-022). Werkzeuge: FHIR-Server, OMOP, Python-Datenpipelines.

Die Datenarbeit macht meist deutlich mehr als die Hälfte des Aufwands aus, weil Live-Datenströme und lokale Validierung der schwierige Teil sind. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• Enterprise (Klinikverbünde): Weg A, weil Sepsis-Alarme eine hochriskante Funktion vom Typ Medizinprodukt sind und zertifizierte Produkte mit klinischer Validierung existieren.
• Öffentlicher Sektor (kommunale Krankenhäuser und Universitätskliniken): Weg A mit zertifizierten Produkten, weil Haftung, Konformität und Vergaberegeln validierte Produkte gegenüber Eigenentwicklungen begünstigen.
• Entwickler: Weg C, weil Modelle auf offenen Vitalwert-Datensätzen (MIMIC, eICU) auf bescheidener Hardware laufen und Forschung und Validierung ohne Cloud-Abhängigkeit erlauben.

Weg A — Kaufen (empfohlen)

• In die EHR eingebettet: Epic Sepsis Model (aktuelle Version 2) und ähnliche Module anderer EHRs; prüfen Sie vor dem Einsatz die lokale Validierung [1].
• Spezialanbieter: Bayesian Health (TREWS, USA), Prenosis Sepsis ImmunoScore (USA, FDA De Novo 2024 zugelassen [5]), Dascena (USA), Frühwarnlösungen für die Patientenüberwachung von Philips (EU: Niederlande), Dräger (EU: Deutschland) und EU-Anbieter von Krankenhaus-IT wie Dedalus (EU: Italien/Frankreich/Deutschland). Prüfen Sie CE-Status und MDR-Klasse jedes Produkts.
• A wählen, wenn: dem Krankenhaus ein ML-Team fehlt und es ein zertifiziertes Produkt mit Herstellerhaftung und klarer Zweckbestimmung wünscht.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Gesundheitsdatenplattformen mit EU-Regionen: Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake (FHIR-Speicher) plus verwaltetes ML (Azure ML, Vertex AI, SageMaker) für tabellarische und Zeitreihenmodelle.
• LLM-APIs (EU-Regionen oder EU-Anbieter, z. B. Mistral) nur für Notizzusammenfassungen oder Alarmerklärungen; die Bewertung sollte ein validiertes deterministisches Modell bleiben. Erfordert einen Auftragsverarbeitungsvertrag und die Zustimmung des Krankenhauses zur Cloud-Übertragung von Patientendaten.
• Wer einen Bewertungsdienst für den eigenen klinischen Einsatz baut, wird zum Hersteller von Software als Medizinprodukt (siehe Risiken).

Weg C — Selbst betreiben (Open Source)

• Daten: FHIR-Server (HAPI FHIR), Streaming (Apache Kafka, Flink), OMOP CDM mit OHDSI-Werkzeugen.
• Modelle: XGBoost/LightGBM, scikit-learn, PyTorch; Zeitreihen mit sktime; Benchmark und Baselines mit dem offenen YAIB-Framework (Yet Another ICU Benchmark) [6]. Bei Bedarf Open-Weight-LLMs (z. B. Familien Llama, Qwen, Mistral) für Notizmerkmale auf HW2-HW3.
• Hardware: Die tabellarische Kernbewertung läuft auf der CPU (HW1); GPUs nur für Notiz-NLP oder tiefe Modelle.
• Der Betriebsaufwand im Krankenhaus dominiert: Schnittstellen, Monitoring, MLOps, klinische Governance.

Weg D — Eigenes Training

Die meisten Forschungskrankenhäuser landen hier: Training und Validierung auf lokalen Daten, passend zum Patientenmix. Öffentliche Datensätze für Entwicklung und Benchmarking: MIMIC-IV und eICU (PhysioNet), HiRID (Zürich), AmsterdamUMCdb sowie die PhysioNet/Computing in Cardiology Challenge 2019 zur Sepsis-Vorhersage [7]. Planen Sie zehntausende Aufnahmen, eine retrospektive, dann stille (Schatten-) prospektive Validierung und einen regulatorischen Weg, falls das Modell vermarktet oder über den Forschungsrahmen hinaus genutzt werden soll.

Stand der Technik (2026)

• Die beste Praxis hat sich verschoben von der retrospektiven AUC hin zur prospektiven, in den Arbeitsablauf integrierten Evaluation; Zeit vom Alarm bis zur Maßnahme und das Vertrauen der Kliniker bestimmen den Nutzen [2][3].
• Label-Probleme: Modelle, die auf Abrechnungscodes oder dem Zeitpunkt der Antibiotikagabe trainiert wurden, können das Verhalten der Kliniker lernen und „vorhersagen“, was das Personal ohnehin vermutet, was die Leistung aufbläht. Nutzen Sie klinische Definitionen (Sepsis-3) und bewerten Sie die Vorlaufzeit vor der klinischen Erkennung.
• Datenverschiebung (Dataset Shift): Die Leistung sinkt bei neuen Patientenpopulationen, Laborverfahren oder Praxisänderungen; Rekalibrierung und Drift-Überwachung sind erforderlich, und externe Validierung über Krankenhäuser hinweg ist weiterhin selten.
• Grenzen: niedriger positiver Vorhersagewert bei seltenen Ereignissen, Alarmmüdigkeit, fehlende oder verspätete Daten, Verzerrung zwischen Untergruppen und Automatisierungsverzerrung, wenn das Personal Alarmen zu sehr vertraut oder sie ignoriert.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (tabular-ml + time-series + streaming): HLTH-007 Fernüberwachung, HLTH-020 Risikostratifizierung in der Bevölkerung, HLTH-013 EKG-Signale; die FHIR-/OMOP-Datenschicht wird mit HLTH-028 Terminologie-Mapping geteilt.
• LLM-Schicht: HLTH-018 Aktenzusammenfassung und HLTH-003 klinische Dokumentation liefern Notizmerkmale und Kontext.
• Naheliegende Kombination: HLTH-004 klinische Entscheidungsunterstützung (Bündel-Leitfaden, Antibiotic Stewardship) und HLTH-008 Kapazitätsplanung (Intensivverlegungen).

Aufwand, Kosten & Kennzahlen

• Weg A: 3-9 Monate inkl. Schnittstellenarbeit, lokaler Validierung und klinischer Governance; Lizenz je Bett oder je Krankenhaus.
• Weg B/C: 9-18 Monate mit einem Team aus Data Science, klinischer Informatik und Qualitätsmanagement; die Kosten entstehen vor allem durch Personal, Daten- technik und regulatorische Arbeit, nicht durch Rechenleistung.
• Kennzahlen: Sepsis-Sterblichkeit, Zeit bis zur Antibiotikagabe und bis zum Abschluss des Bündels, ungeplante Verlegungen auf die Intensivstation und Herzstillstände auf Normalstationen, Sensitivität und positiver Vorhersagewert beim gewählten Schwellenwert, Alarme je 100 Patiententage, Zeit bis zur Alarmquittierung, Kalibrierungsdrift, Leistung in Untergruppen.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung und die Ärztliche Direktion ein, dann die Leitungen von Intensivmedizin, Notaufnahme und Stationen (Prozessverantwortliche), die Pflegedirektion, IT und IT-Sicherheit, die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten, Recht und Compliance sowie von Anfang an den Betriebsrat. Pflegekräfte und Ärzte sind die Endnutzer und müssen Alarmschwellen und Eskalationsschritte mitgestalten.

Betriebsrat: ja. Ein System, das jeden stationären Patienten bewertet und die Quittierung von Alarmen protokolliert, ist objektiv geeignet, Reaktionen des Personals zu überwachen, daher gilt § 87 Abs. 1 Nr. 6 BetrVG; § 90 Abs. 1 Nr. 3 und § 80 Abs. 3 stützen frühe Information und einen Sachverständigen. Öffentliche Krankenhäuser beteiligen den Personalrat. Vereinbaren Sie, dass Alarmdaten nicht für individuelle Leistungsbeurteilung verwendet werden (GUIDE-004).

Datenschutz: Gesundheitsdaten und systematische Auswertung erfordern eine Datenschutz-Folgenabschätzung (DSFA), einen AVV und die Einbindung der bzw. des Datenschutzbeauftragten (GUIDE-005). Bei einem Hochrisiko-System sind die Pflichten von Anbieter und Betreiber einzuplanen (GUIDE-014).

KI-Kompetenz: Unterstützen Sie das Personal mit Schulungen zur Bedeutung von Alarmen, Fehlalarmen und Automatisierungsverzerrung (GUIDE-006). Pilotieren Sie zuerst still auf einer Station, dann mit sichtbaren Alarmen, benennen Sie Champions aus Pflege und Ärzteschaft und begegnen Sie Sorgen vor Alarmmüdigkeit, indem Sie die Alarmbelastung verfolgen. Kliniker entscheiden stets über die Behandlung (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): hochriskant. Software mit medizinischer Zweckbestimmung (Diagnose, Vorhersage, Überwachung) ist ein Medizinprodukt nach MDR (Regel 11, meist Klasse IIa oder höher); ist eine Benannte Stelle erforderlich, ist sie nach Art. 6 Abs. 1 mit Anhang I hochriskant, mit Pflichten zu Risikomanagement, Daten-Governance, Protokollierung, Transparenz, menschlicher Aufsicht und Genauigkeit (Art. 9-15) [8]. Die Anwendungstermine für diese produktbezogenen Regeln liegen später als für Systeme nach Anhang III und waren Gegenstand von Verschiebungsvorschlägen; prüfen Sie den aktuellen Zeitplan. Das hauseigene Modell eines Krankenhauses unterliegt zudem den Bedingungen der MDR-Ausnahme für Eigenherstellung (Art. 5 Abs. 5) und nationalem Recht.
• Betreiber (Krankenhäuser): menschliche Aufsicht, Überwachung, Protokollierung und KI-Kompetenz (Art. 4); betroffenes Personal informieren.
• DSGVO: Gesundheitsdaten sind eine besondere Kategorie (Art. 9); Rechtsgrundlage aus der Gesundheitsversorgung und nationalem Gesundheitsrecht; DSFA (Art. 35) voraussichtlich erforderlich; die Sekundärnutzung für Trainingszwecke braucht eine eigene Grundlage, Pseudonymisierung und Ethikvotum; die Verordnung zum Europäischen Gesundheitsdatenraum wird die Sekundärnutzung von Gesundheitsdaten prägen [9]. Alarme unterstützen die Kliniker, ersetzen sie aber nicht, was Bedenken nach Art. 22 begrenzt.
• Sicherheitsrisiken: verpasste Fälle (falsche Sicherheit), Alarmmüdigkeit, Verzerrung, Drift, Ausfall von Datenströmen. Gegenmaßnahmen: Validierung im stillen Modus, lokale Kalibrierung, ausfallsicherer Rückfall auf NEWS2, Alarmbudget, Audits der Untergruppen, Meldung von Vorkommnissen, Überwachung nach dem Inverkehrbringen.

Erste Schritte

1. Legen Sie mit Klinikern die klinische Fragestellung (Sepsis vs. allgemeine Verschlechterung), das Umfeld, das Label und die Verantwortlichen für Alarme fest; messen Sie Ausgangswerte für Sterblichkeit, Zeit bis zur Antibiotikagabe und Alarmbelastung.
2. Führen Sie in der EHR einen automatisch berechneten NEWS2 als transparente Ausgangsbasis ein.
3. Prüfen Sie Verfügbarkeit und Aktualität der Daten (Häufigkeit der Vitalwerte, Latenz der Laborwerte, FHIR-/HL7-Schnittstellen); bauen Sie die Datenschicht auf OMOP/FHIR auf.
4. Betreiben Sie das Kandidatenprodukt oder -modell 3-6 Monate im stillen Modus; bewerten Sie Vorlaufzeit, PPV und Leistung in Untergruppen lokal.
5. Gehen Sie auf einer Station mit einem Rapid-Response-Protokoll live, überwachen Sie Kennzahlen und Drift und skalieren Sie dann.

Quellen

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/