Sepsis-Frühwarnsystem: ML erkennt kritische Vitalzeichenmuster auf der ITS

Das echte Ausmaß des Problems

In Deutschland stirbt alle sieben Minuten ein Mensch an Sepsis. Das ist keine Metapher und keine Hochrechnung, das sind die Zahlen der SEPSIS-Hilfe e. V. und der deutschen epidemiologischen Forschung auf Basis von Routinedaten des Statistischen Bundesamts.

Pro Jahr erkranken in Deutschland rund 75.000 Patientinnen und Patienten an einer schweren Sepsis. Auf deutschen Intensivstationen sind im Schnitt 17,9 Prozent der Betten mit Sepsispatientinnen belegt. Die Krankenhaussterblichkeit bei beatmungspflichtiger Sepsis lag in einer prospektiven deutschen Multicenterstudie bei über 55 Prozent.

Was diese Zahlen bedeuten, zeigt sich, wenn man sie in Behandlungskosten übersetzt: Ein Intensivstationstag ohne Beatmung kostet in Deutschland im Schnitt 1.265 Euro, mit maschineller Beatmung rund 1.426 Euro (Weiss et al., Deutsches Krankenhaus, Stand 2022, mit Preissteigerungen 2024 dürften die Werte eher höher liegen). Schwere Sepsis mit Organversagen verursacht Gesamtbehandlungskosten von 20.000 bis 80.000 Euro je Fall, bei mehrwöchiger ITS-Verweildauer auch deutlich mehr.

Das Besondere an Sepsis: Es ist keine Erkrankung, die man entweder hat oder nicht hat. Sie entwickelt sich in Stunden. Jede Stunde frühere, leitliniengerechte Antibiotikatherapie senkt die Mortalität um rund 7 Prozent, das ist keine theoretische Verbesserung, das ist die sogenannte „one-hour bundle”-Evidenz aus der Überarbeiteten Surviving Sepsis Campaign (SSC 2018) und nachfolgenden Metaanalysen.

Das Problem: Die frühen Signale sind unspezifisch und verteilt über viele Parameter gleichzeitig. Ein einzelner Pflegender, der sieben bis zwölf Patienten gleichzeitig betreut, kann keine laufende Multiparameter-Trendanalyse durchführen. Das ist keine Frage von Sorgfalt oder Kompetenz, es ist eine strukturelle Unmöglichkeit.

Die bestehenden Scoring-Systeme und warum sie an ihre Grenzen stoßen

Bevor man über ML spricht, muss man verstehen, was auf Intensivstationen heute eingesetzt wird, und warum es Lücken lässt.

SOFA-Score (Sequential Organ Failure Assessment): Der SOFA-Score ist der klinische Goldstandard für die Diagnose von Sepsis und Organdysfunktion auf der ITS. Er bewertet sechs Organsysteme (Atmung, Gerinnung, Leber, Herz-Kreislauf, ZNS, Niere) mit je 0–4 Punkten. Ein Anstieg um ≥ 2 Punkte definiert Sepsis nach den Sepsis-3-Kriterien (Singer et al., JAMA 2016). Das Problem: Der SOFA erfordert Laborwerte und ist für eine Berechnung alle paar Stunden ausgelegt, er ist kein Echtzeit-Werkzeug.

qSOFA (quick SOFA): Drei Parameter am Bett: veränderte Bewusstseinslage, erhöhte Atemfrequenz (≥22/min), systolischer Blutdruck ≤100 mmHg. Schnell, ohne Labor, aber in einer deutschen Studie (Serafin et al., Notfall + Rettungsmedizin 2022) fehlte qSOFA bei 43 Prozent aller Sepsispatientinnen mit hohem Mortalitätsrisiko. Für das Screening außerhalb der ITS ist qSOFA damit unzureichend.

NEWS2 (National Early Warning Score) und MEWS (Modified Early Warning Score): Aggregierte Scores, die Vitalparameter punktbasiert zusammenfassen und bei Überschreiten eines Schwellwerts einen Alarm auslösen. Klinisch etabliert, aber konzeptionell regel- und schwellwertbasiert, sie erkennen keine subtilen Trendmuster über Zeit und zwischen Parametern hinweg.

Was all diese Systeme nicht können: Sie analysieren keine kontinuierlichen Zeitreihen mehrerer Parameter in ihrer Wechselwirkung. Ein Herzfrequenzanstieg von 85 auf 98 ist allein nicht auffällig. Kombiniert mit leicht steigendem Laktat, marginal sinkender Sauerstoffsättigung und einer Temperaturerhöhung über die letzten sechs Stunden, das ist das Muster, das ein gut trainiertes Modell erkennen kann, lange bevor die Einzelparameter Grenzwerte überschreiten.

Mit vs. ohne KI, ein ehrlicher Vergleich

Alle Werte: Orientierungsgrößen. Ergebnisse sind klinik- und modellspezifisch, der UCSD-Effekt ist in einem spezifischen US-Universitätsklinikumskontext entstanden, keine direkten Rückschlüsse auf jede deutsche ITS.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5) Ein validiertes Frühwarnsystem entlastet das Pflegepersonal vom kognitiv aufwändigen Multiparameter-Trendmonitoring, geschätzt 30–60 Minuten pro Schicht auf einer vollbelegten ITS. Das ist real, aber nicht der dominante Nutzenvektor. Die größere Wirkung entsteht nicht durch weniger Arbeit, sondern durch richtiger platzierte Aufmerksamkeit. Im Vergleich zu anderen gesundheitlichen KI-Anwendungen wie Abrechnungsoptimierung oder Befundkommunikation ist der direkte Zeitgewinn für die klinische Routine hier eher im Mittelfeld.

Kosteneinsparung, niedrig (2/5) Die wirtschaftliche Logik ist klar: Weniger Beatmungstage, kürzere ITS-Verweildauer, vermiedene Organversagen, das rechnet sich pro Fall erheblich. Aber der Weg von klinischem Nutzen zu buchhalterisch erfasster Kostenreduktion ist in deutschen Krankenhäusern lang. DRG-Erlöse sind für sepsis-assoziierte Diagnosen gedeckelt; gespartes Geld durch kürzere Verweildauer führt nicht zwingend zu mehr Erlös. Das investierte Budget für Zulassung, Integration und Betrieb ist real, der Rückfluss über Abrechnungsoptimierung ist es weniger.

Schnelle Umsetzung, sehr niedrig (1/5) Das ist die entscheidende Einschränkung dieses Use Case. Wer glaubt, ein Sepsis-Frühwarnsystem sei ein SaaS-Tool, das man in vier Wochen einführt, unterschätzt die regulatorische Realität fundamental: MDR-Klasse IIb bedeutet Notified Body, klinische Validierungsstudie, ISO 13485, technische Dokumentation. Eigenentwicklungen ohne CE-Kennzeichnung dürfen im klinischen Betrieb nicht verwendet werden. Das Minimum für eine valide Lösung, von Beschaffung bis Vollbetrieb, liegt bei 18 bis 36 Monaten. Kein anderer Anwendungsfall in dieser Gesundheits-Kategorie hat einen vergleichbar hohen regulatorischen Einstiegshürden.

ROI-Sicherheit, hoch (4/5) Der klinische Nutzen ist durch mehrere unabhängige Studien belegt. Die COMPOSER-Studie an der UC San Diego (2024) ist die bisher methodisch stärkste prospektive Implementierungsstudie. Auch in Deutschland gibt es auf Basis von MIMIC-Daten validierte Modelle. Wer ein regulatorisch konformes, an seiner Klinik-Population nachvalidierteres Modell betreibt, hat einen belastbaren medizinischen ROI, auch wenn der wirtschaftliche ROI wie oben beschrieben schwerer zu quantifizieren ist.

Skalierbarkeit, mittel (3/5) Ein einmal zertifiziertes Modell kann auf weitere ITS-Einheiten desselben Krankenhauses oder Trägers ausgerollt werden, sofern die Monitoring-Infrastruktur und EHR-Anbindung vergleichbar sind. Das ist ein echter Skalierungshebel. Klinikträger mit fünf ITS und gemeinsamem KIS profitieren überproportional. Aber: Modelle, die auf einer Patientenpopulation trainiert wurden, müssen auf neuen Populationen re-validiert werden. Der Transfer von Uniklinikum zu Kreiskrankenhaus ist nicht trivial.

Richtwerte, stark abhängig von Klinikinformationssystem, vorhandener Monitoring-Infrastruktur und Größe der ITS.

Das Alarmflut-Problem: Warum ein weiterer Alert scheitern kann

Auf einer typischen Intensivstation gehen pro Patient und Tag zwischen 40 und 400 Alarmierungen ein, von Monitoring-Geräten, Beatmungsmaschinen, Perfusoren und Meldesystemen. Laut einer in Critical Care Medicine publizierten Untersuchung sind bis zu 99 Prozent dieser Alarme klinisch nicht handlungsrelevant, sei es weil sie Artefakte sind, technisch bedingte Fehlauslösungen oder klinisch bekannte Befunde.

Intensivpflege im Jahr 2026 ist, unter anderem, Alarmmanagement. Das Gehirn passt sich an: Wiederholte Alarme ohne Konsequenz werden zuverlässig ignoriert, das ist keine Fahrlässigkeit, das ist eine adaptive kognitive Reaktion auf Reizüberflutung. Der Fachbegriff ist Alarm Fatigue.

Ein schlecht kalibriertes ML-Frühwarnsystem fügt diesem System einen weiteren Alarmgeber hinzu, und riskiert, genauso ignoriert zu werden wie der vierte Perfusor-Alarm in zwanzig Minuten.

Das Paradebeispiel für dieses Risiko ist der Epic Sepsis Model (ESM). In einer externen Validierungsstudie an der University of Michigan Medicine (Wong et al., JAMA Internal Medicine 2021) zeigte sich: Das Modell erkannte nur 33 Prozent der tatsächlichen Sepsisfälle, generierte dabei Alerts für 18 Prozent aller hospitalisierten Patientinnen und Patienten. Die AUROC lag bei 0,63, deutlich unter den vom Hersteller angegebenen 0,77–0,83. Ergebnis: massive Alarm-Fatigue ohne klinischen Mehrwert.

Das bedeutet nicht, dass Sepsis-KI nicht funktioniert. Es bedeutet, dass die Spezifität mindestens genauso wichtig ist wie die Sensitivität. Ein System, das auf 100 Patienten zehnmal alarmiert und dabei 9 tatsächliche Sepsisfälle früh erkennt und 1 mal falsch liegt, ist klinisch wertvoll. Ein System, das 30-mal alarmiert und dabei 12 echte Fälle findet und 18 falsch positive Alerts produziert, kann unter dem Strich Schaden anrichten, weil sich Ärzte und Pflegende darauf konditionieren, den Alarm zu ignorieren.

Was daraus folgt für die Implementierung: Jedes Sepsis-Frühwarnsystem braucht eine klinikspezifische Kalibrierung der Alarmschwellen und eine prospektive Evaluationsphase, in der das Team Feedback gibt, was war richtig, was war Rauschen? Kein Modell von der Stange passt ohne Anpassung auf jede ITS.

MDR-Zulassung: Was das für Krankenhäuser bedeutet

Das ist der Punkt, den viele unterschätzen, und der den gesamten Einführungsprozess dominiert.

Ein KI-basiertes Sepsis-Frühwarnsystem, das auf Vitaldaten zugreift und klinische Entscheidungshinweise gibt, fällt nach der EU-Medizinprodukteverordnung (MDR 2017/745) regelhaft unter Klasse IIb. Die Begründung: Anhang VIII, Regel 11, Software, die zur Überwachung lebenswichtiger Physiologieparameter bestimmt ist, bei denen die Art der Veränderungen unmittelbar lebensbedrohlich sein kann.

Was Klasse IIb konkret verlangt:

Der EU AI Act (Verordnung 2024/1689) klassifiziert KI-Systeme, die Diagnose- oder Behandlungsentscheidungen in der Medizin beeinflussen, als Hochrisikosysteme (Anhang III, Punkt 5a). Ab August 2026 greifen zusätzliche Pflichten: Protokollierung, menschliche Aufsicht, Genauigkeitsdokumentation. Für Hersteller bedeutet das weiteren Aufwand, und für Krankenhäuser, dass sie nur Systeme einsetzen dürfen, die diesen Anforderungen genügen.

Was das für Krankenhäuser heißt: Wer ein kommerzielles, bereits CE-zertifiziertes System beschafft, kauft diese Compliance mit. Wer auf eine Eigenentwicklung setzt oder ein Forschungsmodell in den Betrieb überführt, trägt die Zulassungslast selbst, und das ist ein Projekt mit einem Budget von 200.000 bis 500.000 Euro für die Konformitätsbewertung allein, plus 12–24 Monate Zeitaufwand.

Was das System konkret macht

Technisch basieren die performantesten Sepsis-Frühwarnsysteme auf zwei Ansätzen, die sich zunehmend ergänzen:

LSTM-Netzwerke (Long Short-Term Memory): Rekurrente neuronale Netze, die Zeitreihen analysieren und Muster in langen Sequenzen erkennen können. Auf ITS-Vitaldaten trainiert, lernt ein LSTM, welche Kombinationen von Parameterveränderungen über Zeit typischerweise einer Sepsis vorausgehen, auch wenn kein Einzelparameter einen Grenzwert verletzt.

Transformer-Modelle auf EHR-Daten: Neuere Ansätze wie das COMPOSER-LLM-System der UC San Diego integrieren nicht nur kontinuierliche Vitaldaten, sondern auch strukturierte EHR-Informationen (Medikamentengabe, Laborbefunde, Diagnosen) in ein gemeinsames Modell. Die prospektive Implementierung zeigte eine Sensitivität von 72,1 Prozent bei einer False-Alarm-Rate von 0,0087 pro Patienten pro Stunde, deutlich besser als frühere Versionen.

Der Datenfluss in der Praxis:

1. Patientenmonitor (Philips IntelliVue, Dräger Infinity, Mindray) sendet Vitaldaten kontinuierlich an eine Device-Gateway-Schnittstelle
2. Gateway exportiert via HL7 v2.x (dominant in deutschen Krankenhäusern) oder HL7 FHIR R4 in den Analytics-Layer
3. ML-Modell berechnet alle 5–15 Minuten einen Risikoscore und hält einen Zeitverlauf vor
4. Bei Überschreitung des Schwellwerts: Alert im KIS (Klinikinformationssystem) oder direkt am Patientenmonitor mit Trendanzeige, kein blinder Alarm, sondern visualisierter Parametertrend
5. Arzt oder Pflegefachperson quittiert, dokumentiert Entscheidung, Feedback fließt in Modell-Monitoring

Was das System nicht macht: Es stellt keine Diagnose. Es schlägt kein Antibiotikum vor. Es ordnet keine Maßnahmen an. Es erzeugt einen Hinweis, dass ein Patient ein erhöhtes Risiko haben könnte, mit der Verantwortung bleibt das klinische Personal.

EHR-Integration: Die unterschätzte technische Hürde

Die größte nicht-regulatorische Herausforderung bei der Einführung eines Sepsis-Frühwarnsystems ist nicht das ML-Modell, es ist die Datenpipeline.

Deutsche Intensivstationen arbeiten mit heterogener Monitoring-Hardware: Philips IntelliVue, Dräger Infinity, GE Carescape, Mindray. Jeder Hersteller implementiert seine Gerätekommunikation auf Basis proprietärer Protokolle und Datenformate, die dann über Hardware-Gateways in das Klinikinformationssystem übertragen werden.

Die relevanten Standards sind:

• HL7 v2.x: Dominant in deutschen Krankenhäusern, sendet Observation-Messages (ORU/OBR), aber Implementierungen zwischen verschiedenen Systemen weichen oft voneinander ab
• HL7 FHIR R4: Modernerer REST-basierter Standard, noch nicht flächendeckend in deutschen KIS implementiert, viele Häuser haben keinen produktionsfähigen FHIR-Server
• IEEE 11073 / IHE PCD: Profile für Point-of-Care Device Communication, technisch korrekt, in der Praxis selten vollständig implementiert

Was das in der Realität bedeutet: Ein Implementierungsprojekt beginnt oft nicht mit der ML-Pipeline, sondern mit einer monatelangen Bestandsaufnahme: Welche Monitoring-Geräte welcher Generation laufen auf welcher ITS? Welche Schnittstellen unterstützt das KIS (Orbis/Dedalus, iMedOne, medico, SAP IS-H)? Wo fehlt die Echtzeit-Datenfähigkeit überhaupt?

Laut einer Analyse von Healthcare IT News können allein die Interface-Engine-Lizenzen und Integrationsarbeiten für heterogene EHR-Umgebungen 500.000 bis 2 Millionen Euro jährlich kosten. Für ein einzelnes Krankenhaus ist der Aufwand überschaubar, aber nicht trivial: Sechs bis zwölf Monate für die Datenintegration allein sind keine Seltenheit.

Der Silberstreif: Neue Krankenhäuser oder solche, die gerade ihr KIS-System konsolidieren (z. B. im Rahmen des Krankenhaus-Zukunftsfonds / KHZG-Förderung), haben die Chance, FHIR-fähige Infrastruktur von Anfang an einzuplanen. Diese Häuser sind für Sepsis-KI strukturell besser gerüstet als Häuser mit gewachsener IT-Heterogenität.

Konkrete Werkzeuge, was wann passt

Dieser Use Case ist kein SaaS-Marktplatz. Es gibt keine Plattform, auf der man sich ein Sepsis-Frühwarnsystem einmalig registriert und in vier Wochen betreibt. Die Landschaft teilt sich in drei Kategorien:

Kommerziell, CE-zertifiziert (klinikreif in der EU):

• Philips eCareManager / IntelliVue Guardian Solution: Philips bietet für Kliniken mit Philips-Monitoring-Infrastruktur eine integrierte Clinical Decision Support-Lösung an, die Sepsis-Screening nach Surviving-Sepsis-Protokollen unterstützt. Die Guardian Solution basiert auf regelbasiertem Scoring (kein ML im engen Sinne), ist aber CE-zertifiziert und integriert in die Philips IntelliVue-Monitoring-Kette. Für Häuser mit Philips-Monitoren der erste valide Ausgangspunkt. Preisgestaltung: auf Anfrage, typisch im niedrigen sechsstelligen Euro-Bereich für eine ITS-Installation.
• Dräger Analytics / Critical Care Suite: Dräger bietet für Häuser mit Dräger-Beatmungsgeräten Analytics-Lösungen an. Sepsis-spezifische ML-Komponenten sind im Aufbau (Stand Mai 2026 noch nicht als eigenständiges CE-markiertes Produkt verfügbar).
• B. Braun OnlineSuite / Fresenius Kabi IT-ClinicalDecision: Weitere Medizintechnik-Hersteller mit proprietären ITS-Analytics-Angeboten, meist monitoring-hardware-gebunden.

Forschung / Eigenentwicklung:

• Open-Source-Modelle auf PhysioNet/MIMIC-IV-Daten: Mehrere öffentlich zugängliche Modelle (z. B. auf GitHub der COMPOSER-Gruppe, Sepsis-3-basierte LSTM-Implementierungen) können als Entwicklungsgrundlage dienen. Cave: Diese Modelle haben keine CE-Zulassung. Sie dürfen nicht ohne Konformitätsbewertung klinisch eingesetzt werden.
• Amazon SageMaker / Azure ML Health: Cloud-ML-Infrastruktur für Häuser, die in Healthcare-Cloud-Plattformen investieren und eigene Datenwissenschaftler haben.

Klinische Entscheidungsunterstützung als Begleitinfrastruktur:

• AMBOSS: Nicht für das Echtzeit-Alerting, aber als Rückendeckung für das klinische Personal, AMBOSS enthält peer-reviewte, aktualisierte Sepsis-Leitfäden (Sepsis-3, SSC-Bundle, S3-Leitlinie 2025) für schnellen Point-of-Care-Zugriff. Wenn ein Alert auslöst, sollte das Team wissen, was es mit dem Hinweis macht.

Zusammenfassung:

Datenschutz und Datenhaltung

Vitaldaten auf der Intensivstation sind Gesundheitsdaten im Sinne von Art. 9 DSGVO, die sensibelste Datenkategorie überhaupt. Hinzu kommen Anforderungen aus dem SGB V, der Datenschutzkonferenz (DSK) und den länderspezifischen Krankenhausgesetzen.

Für ein Sepsis-Frühwarnsystem bedeutet das:

• Verarbeitungsgrundlage: Behandlungsvertrag (Art. 6 Abs. 1 lit. b, Art. 9 Abs. 2 lit. h DSGVO), Verarbeitung personenbezogener Gesundheitsdaten zur Behandlung ist grundsätzlich möglich, aber dokumentationspflichtig
• Auftragsverarbeitung (AVV): Wenn ein externer Anbieter die Datenverarbeitung übernimmt, ist ein AVV nach Art. 28 DSGVO verpflichtend. Bei Cloud-Lösungen: EU-Hosting zwingend, keine Drittlandübermittlung ohne Standardvertragsklauseln
• Datensparsamkeit: Das Modell sollte nur die Parameter verarbeiten, die für die Vorhersage notwendig sind, keine unnötige Aggregation oder Speicherung vollständiger Patientenakten in Analytics-Systemen
• Anonymisierung für Modelltraining: Training auf Echtdaten erfordert Einwilligung oder Pseudonymisierung, für reguläre Modell-Updates ist ein datenschutzrechtlich geprüfter Prozess nötig
• Datenspeicherung on-premise vs. Cloud: Für die meisten deutschen Krankenhäuser ist On-Premise oder ein zertifiziertes deutsches Rechenzentrum (z. B. BWH, Telekom Healthcare) die sicherere Wahl, besonders für ITS-Echtzeitdaten

Technische und organisatorische Maßnahmen (TOMs): Verschlüsselung aller Datenströme (TLS 1.3 minimum), Zugriffsprotokollierung, Rollenkonzept (nur behandelnde Ärzte und Pflegefachpersonen mit aktivem Patientenkontakt), regelmäßige Penetrationstests für die Datenpipeline.

Haftung und Verantwortung im deutschen Krankenhausrecht

Wenn ein ML-System einen Alarm auslöst und die behandelnde Ärztin handelt, wer haftet bei einem Fehler?

Diese Frage ist im deutschen Recht noch nicht vollständig ausdiskutiert, aber die Leitlinien sind klar:

Die ärztliche Sorgfaltspflicht bleibt unberührt. Ein KI-Hinweis ersetzt keine ärztliche Entscheidung. Wenn eine Ärztin einen Alarm erhält, diesen ignoriert und der Patient stirbt, wird die Frage der Haftung daran gemessen, ob das Ignorieren des Alarms gegen den medizinischen Standard verstoßen hat, nicht daran, ob die KI “Schuld” hatte.

Produkt- und Medizinproduktehaftung: Wenn ein CE-zertifiziertes System einen Fehler produziert (falscher Alarm führt zur Unterlassung einer Behandlung; ausgebliebener Alarm führt zu versäumter Frühbehandlung), haftet der Hersteller nach § 1 Produkthaftungsgesetz bzw. nach Medizinprodukterecht. Die Klinik haftet, wenn sie das System falsch eingesetzt oder nicht korrekt validiert hat.

Pflicht zur menschlichen Aufsicht: Der EU AI Act (für High-Risk-KI verpflichtend ab August 2026) schreibt vor, dass KI-Systeme in der klinischen Entscheidungsunterstützung so gestaltet sein müssen, dass eine qualifizierte Person die Entscheidung überprüfen und übersteuern kann. Das ist medizinisch sowieso selbstverständlich, rechtlich wird es Pflicht.

Praktische Empfehlung: Jede Klinik, die ein Sepsis-Frühwarnsystem einführt, sollte vorab eine Haftungsklärung mit dem Rechtsträger (Träger des Krankenhauses), dem Hersteller und ggf. der Haftpflichtversicherung durchführen. Die meisten Kliniken haben diese Fragen noch nicht systematisch geklärt.

Was es kostet, realistisch gerechnet

Vorbemerkung: Die Kostenschätzungen für diesen Use Case unterscheiden sich grundlegend von typischen SaaS-Anwendungen. Es gibt keine “Freemium-Option” für ein MDR-konformes Sepsis-Frühwarnsystem.

Einmalige Einrichtungskosten (Vollbetrieb, ohne Eigenentwicklung):

• MDR-Konformitätsbewertung (bei Eigenentwicklung): 200.000–500.000 € (Notified Body, externe Beratung, technische Dokumentation)
• EHR-Integration / Datenpipeline: 50.000–200.000 €, abhängig von KIS-Komplexität
• Klinische Validierungsstudie (prospektiv, lokal): 100.000–300.000 €
• Schulung und Change Management: 20.000–50.000 €
• Gesamteinrichtung bei Eigenentwicklung: 400.000–1.000.000 €

Bei Kauf einer kommerziell validierten Lösung (Philips, Dräger, internationale Anbieter):

• Lizenz- und Einrichtungskosten: 100.000–400.000 € je nach Installationsgröße
• Jährliche Lizenz/Service: 30.000–80.000 €
• Lokale Anpassung und Validierung: 30.000–100.000 €

Laufende Kosten:

• Systemwartung, Modell-Monitoring, Datenpflege: 1–2 VZÄ klinische Informatik/IT
• Jährliche Relizenzierung / Softwarewartung: 30.000–80.000 €

Was du dagegen rechnen kannst: In Deutschland lag der durchschnittliche ICU-LOS bei Sepsispatientinnen bei 12–20 Tagen. Wenn das System in 30 Prozent der Fälle eine um drei Tage kürzere Verweildauer ermöglicht, spart das auf einer 20-Betten-ITS mit 200 Sepsispatientinnen im Jahr: 200 Fälle × 30 % × 3 Tage × 1.265 € = 227.700 € jährlich.

Das ist ein plausibles, konservatives Szenario. Es kompensiert die laufenden Kosten, aber amortisiert den Einrichtungsaufwand nur über mehrere Jahre. Der entscheidende ROI bei diesem Use Case ist primär klinisch und ethisch: vermiedene Sterbefälle und vermiedene Organversagen. Der wirtschaftliche Nutzen ist real, aber sekundär.

Typische Einstiegsfehler

1. Modell ohne lokale Validierung in den Betrieb nehmen. Ein Modell, das auf US-amerikanischen oder UK-Patientenpopulationen trainiert wurde, kann auf einer deutschen ITS-Population schlechter performen, andere Altersstruktur, andere Komorbiditäten, andere Antibiotika-Protokolle. Die externe Validierung des COMPOSER-Systems auf anderen Kliniken war Bestandteil der Originalpublikation. Kliniken, die proprietäre Modelle kaufen und direkt einschalten, ohne eine Validierungsphase auf ihrer eigenen Population einzuplanen, riskieren genau das Epic-Problem: hohe Falsch-Positivrate, Alarm-Fatigue, Vertrauensverlust.

2. Alarmschwellen nicht kalibrieren. Ein Modell hat intern einen Risikoscore von 0–1. Ab welchem Wert wird alarmiert? Das ist keine technische Entscheidung, das ist eine klinische. Zu niedrig: Alarm-Flut. Zu hoch: relevante Fälle werden verpasst. Dieser Punkt wird oft als Software-Konfiguration behandelt, gehört aber in ein Gespräch zwischen Intensivmedizinern, Pflegeleitung und dem Datenwissenschaftsteam, mit regelmäßigen Nachjustierungen in den ersten sechs Betriebsmonaten.

3. Den Regelbetrieb nicht für kontinuierliches Monitoring einplanen. Ein Sepsis-Modell, das sechs Monate nach dem Start keine Nachschau erhält, degradiert still. Warum? Patientenpopulation ändert sich (neue Antibiotika-Protokolle, andere Erkrankungsmuster), Monitoring-Infrastruktur ändert sich (Gerätewechsel, neue Sensorkalibrierung), Dokumentationsverhalten ändert sich. Wenn niemand die falsch-positive Rate und die Sensitivität monatlich überprüft, merkt man Degradation erst, wenn Pflegende berichten: “Den Alarm ignorieren wir schon seit Monaten.” Post-Market Surveillance ist nicht nur eine MDR-Pflicht, sie ist klinisch notwendig.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Hürde, Integration, Modell, Alerting, ist lösbar und gut dokumentiert. Die menschliche Hürde ist schwieriger.

Widerstand aus der klinischen Praxis: Erfahrene Intensivmedizinerinnen haben das Argument sehr schnell parat: “Ich erkenne Sepsis selbst.” Das stimmt, bei den klar manifesten Fällen. Das ML-System soll die Fälle finden, die auch für erfahrene Klinik-Teams schwierig sind. Wer das Gespräch so rahmt, bekommt weniger Widerstand als mit dem Argument “die KI macht es besser”.

Das Team muss den Alert respektieren wollen. Ein Alert hat nur klinischen Wert, wenn er wahrgenommen und ernst genommen wird. In der Einführungsphase ist eine kurze retrospektive Auswertung hilfreich: “Der Alarm hat in sieben von acht Fällen der letzten drei Wochen stattgefunden, hier sind die Patientenverläufe.” Konkrete Fälle bauen mehr Vertrauen als Präsentationen über Modell-Performance.

Pflegefachpersonen sind die Hauptnutzenden, nicht Ärzte. Systeme werden meist als ärztliche Entscheidungsunterstützung kommuniziert, aber Pflegefachpersonen verbringen die meiste Zeit am Patientenbett. Wenn das Alert-Interface im Pflegeinformationssystem nicht nutzbar oder in drei Klicks vergraben ist, wird es nicht genutzt. Das UX-Design des Alert-Systems ist nicht verhandelbar.

Was konkret hilft:

• Vor dem Go-live eine dreimonatige “Silent Mode”-Phase: Das System läuft, alarmiert aber nicht, stattdessen bekommt das Team retrospektiv Auswertungen: “Der Algorithmus hätte hier alarmiert, was war tatsächlich der Verlauf?” Das baut Vertrauen in das Modell, bevor es Konsequenzen hat.
• Einen klinischen Champion benennen, eine Intensivmedizinerin oder einen Intensivmediziner mit Interesse an Digital Health, der das System intern verteidigt und Feedback kanalisiert.
• Klares Protokoll: Was passiert, wenn ein Alarm auslöst? Wer schaut nach, in welchem Zeitfenster, mit welcher Dokumentationsanforderung?

Realistischer Zeitplan mit Risikohinweisen

Anmerkung: Kauf eines kommerziell CE-zertifizierten Systems verkürzt die Phase MDR-Konformitätsbewertung. Dafür beginnt die Integration mit fremder Infrastruktur, die Datenpipeline-Phase bleibt.

Häufige Einwände, und was dahintersteckt

“Wir haben qSOFA und SOFA, das reicht.” SOFA ist der Standard für die Diagnose, nicht für die Früherkennung. qSOFA hat eine Sensitivität von unter 60 Prozent für frühe Sepsisfälle. Diese Scores messen Organ-Dysfunktion, die sich oft erst zeigt, wenn die Sepsis bereits manifest ist. ML-Modelle können dem klinischen Team drei bis sechs Stunden Vorsprung geben, in einem Kontext, in dem jede Stunde Mortalität senkt. Das ist kein Entweder-oder: ML ergänzt bestehende Scores, ersetzt sie nicht.

“Ein weiterer Alarm, das brauchen wir nicht.” Das ist das stärkste Argument, und es stimmt, wenn schlecht kalibriert. Alarm-Fatigue ist ein reales, dokumentiertes Problem. Die Antwort ist nicht, auf das System zu verzichten, sondern es so zu kalibrieren, dass es nur alarmiert, wenn es etwas Relevantes zu sagen hat. Das COMPOSER-LLM-System erreichte 0,0087 false alarms pro Patient pro Stunde, das ist weniger als ein zusätzlicher Alarm pro Patienten pro fünf Tage. Das ist handhabbar.

“Zu teuer, zu aufwändig, das ist nichts für uns.” Für ein Kreiskrankenhaus mit 8-Betten-ITS und ohne klinisches Informatikteam stimmt das. Für ein Maximalversorger mit 30+ ITS-Betten, eigenem IT-Dept und KHZG-Förderung ist die Kosten-Nutzen-Rechnung deutlich anders. Der Fehler ist, alle Häuser mit demselben Maßstab zu messen.

Woran du merkst, dass das zu dir passt

Du solltest mit diesem Projekt beginnen, wenn:

• Dein Haus hat eine ITS mit ≥ 15 Betten und einem jährlichen Sepsisaufkommen von mindestens 100 behandelten Fällen
• Ihr habt ein Klinikinformationssystem (Orbis, iMedOne, medico, SAP IS-H) mit dokumentierter FHIR-Exportfähigkeit oder habt gerade KHZG-Mittel für digitale Infrastruktur beantragt
• Eure Monitoring-Infrastruktur ist weitgehend homogen (z. B. überwiegend Philips IntelliVue oder überwiegend Dräger Infinity), heterogene Monitoring-Landschaften erhöhen den Integrations-Aufwand massiv
• Ihr habt eine klinische Informatik-Einheit oder Zugang zu Datenwissenschaftlerinnen mit Medizin-Hintergrund
• Die Intensivmedizinische Leitung ist aktiv involviert und bereit, die Modell-Validierungsphase klinisch zu begleiten, nicht nur formal zu unterschreiben

Drei harte Ausschlusskriterien, wer das noch nicht tun sollte:

1. Kein funktionierendes KIS mit Echtzeit-Datenfähigkeit. Wenn ihr noch auf papierbasierten Pflegedokumentationen oder einem Legacy-KIS ohne API-Schnittstellen arbeitet, ist das Fundament nicht da. Der erste sinnvolle Schritt ist die KIS-Modernisierung, nicht die KI-Aufsatz. Ein Sepsis-Modell ohne Echtzeit-Datenstrom ist technisch unmöglich.

2. ITS mit weniger als 10 Betten oder weniger als 50 Sepsisfällen im Jahr. Die statistische Grundlage für klinische Validierung ist zu schmal. Der Einrichtungsaufwand ist für kleine ITS wirtschaftlich nicht darstellbar. Und: Auf einer kleinen Einheit mit erfahrenem Team überwiegt oft die persönliche Kenntnis jedes Patienten die Vorteile eines automatisierten Systems.

3. Kein klinisches Informatik- oder Datenwissenschaftsteam und kein Budget für Zulassung. Ein MDR-konformes System kaufen erfordert trotzdem interne Kompetenz für lokale Validierung, Datenpflege, Systemintegration und Performance-Monitoring. Wer das Projekt als reine IT-Beschaffung behandelt und kein klinisch-informatikrelevantes Personal einplant, wird nach dem Launch keinen nachhaltigen Betrieb hinbekommen.

Das kannst du heute noch tun

Wenn du Intensivmedizin, klinische Informatik oder ITS-Infrastruktur verantwortest, ist der sinnvolle erste Schritt kein Tool-Kauf, sondern eine ehrliche Bestandsaufnahme.

Hier ist ein strukturierter Prompt für eine erste Bewertung, entweder zur Selbstevaluation im Team oder als Vorbereitung auf ein Gespräch mit eurem KIS-Anbieter:

Quellen & Methodik

• COMPOSER AI / UC San Diego: Bulgarelli et al., „Impact of a deep learning sepsis prediction model on quality of care and survival”, npj Digital Medicine, Januar 2024. DOI: 10.1038/s41746-023-00986-6. Studie an 6.217 Patienten, 17 % relative Mortalitätsreduktion, Frühwarnung 4–6 Stunden vor klinischer Diagnose.
• Epic Sepsis Model Validierung: Wong et al., „External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients”, JAMA Internal Medicine, 2021. DOI: 10.1001/jamainternalmedicine.2021.2626. Michigan Medicine: ESM erfasste nur 33 % der Sepsisfälle, alertete auf 18 % aller Patienten.
• Kosten ITS in Deutschland: Weiss et al., „Kosten der intensivmedizinischen Versorgung in einem deutschen Krankenhaus”, Anaesthesiologie & Intensivmedizin / Springermedizin. ICU-Tag durchschnittlich 1.265 EUR (ohne Beatmung) bis 1.426 EUR (mit Beatmung).
• Sepsis-Sterblichkeit Deutschland: Sepsis-Hilfe e. V. / AWMF S3-Leitlinie Sepsis 2025 (Update, Springer Nature Link 2025). Alle sieben Minuten stirbt in Deutschland ein Mensch an Sepsis; ~75.000 schwere Sepsisfälle pro Jahr.
• qSOFA-Sensitivität: Serafin et al., „Screening auf Sepsis in der Notfallmedizin – qSOFA ist uns nicht genug”, Notfall + Rettungsmedizin, Springer, 2022. qSOFA verpasste 43 % der Hochrisiko-Sepsisfälle.
• COMPOSER-LLM prospektive Implementierung: Lauritsen et al., „Development and prospective implementation of a large language model based system for early sepsis prediction”, npj Digital Medicine, 2025. Sensitivität 72,1 %, 0,0087 false alarms/Patienten/Stunde.
• MDR-Klassifizierung: EU-Medizinprodukteverordnung 2017/745, Anhang VIII, Regel 11; Decomplix.com: „Classification of Medical Devices Under EU MDR (2025)”.
• Alarm-Fatigue auf ITS: Cvach, „Monitor alarm fatigue: an integrative review”, Biomedical Instrumentation & Technology, 2012; AAMI, „Clinical alarms in intensive care units”.
• EU AI Act, Hochrisiko-KI Medizin: Verordnung (EU) 2024/1689 über Künstliche Intelligenz, Anhang III Nr. 5a. Gültig ab August 2026 für neue Marktzulassungen.
• Kosten ITS-EHR-Integration: Healthcare IT News, „Interface engine licensing in heterogeneous EHR environments”, 2023–2024.

Willst du einschätzen, ob die ITS-Infrastruktur deines Hauses für diesen Schritt bereit ist, oder einen konkreten Beschaffungsprozess strukturieren? Meld dich, das klären wir gemeinsam.