Zum Inhalt springen
Gesundheitswesen op-managementkrankenhausscheduling

OP-Saal-Auslastung: ML-Prognose reduziert Leerlaufzeiten

Unvorhersehbare OP-Dauern erzeugen massenhafte Leerläufe in teuren Operationssälen — ML-Dauerprognose auf Basis von Eingriff, Team und Patientendaten ermöglicht präzisere Belegungsplanung.

⚡ Auf einen Blick
Problem
OP-Säle kosten 15–40 € pro Minute Betriebskosten. Planungsmodelle basieren auf Durchschnittswerten je Eingriff — ignorieren aber Chirurgen-Erfahrung, ASA-Score, Komorbidität und historische Abweichungen. Ergebnis: 25–35% der OP-Kapazität verpufft durch Leerläufe, während gleichzeitig Eingriffe abgesagt werden, weil die letzte Stunde nicht belegt werden kann.
KI-Lösung
Ein ML-Modell (Gradient Boosting + Quantilregression) schätzt OP-Dauer als Verteilung — nicht als Punktwert. Planer sehen P50/P90-Prognosen je Eingriff und Team. Tagespläne werden auf Basis dieser Verteilungen dynamisch optimiert, um Kapazitätsauslastung zu maximieren.
Typischer Nutzen
10–20% mehr abrechenbare Eingriffe je OP-Tag durch präzisere Belegung. Bei 6 OP-Sälen bedeutet 45–60 Minuten weniger Leerlauf täglich 300.000–600.000 € mehr Erlös pro Jahr.
Setup-Zeit
KIS-Integration + Datenbereinigung + Modellvalidierung: 9–18 Monate
Kosteneinschätzung
Einrichtung: 150.000–400.000 € (KIS-Integration + Implementierung); laufend 80.000–200.000 €/Jahr Lizenz/SaaS
FHIR-Anbindung an SAP IS-H oder ORBISGradient Boosting + QuantilregressionConstraint-Optimierung für Tagesplanung
Worum geht's?

Es ist Montagmorgen, 7:41 Uhr.

OP-Managerin Miriam Schalk öffnet ihre E-Mails, während der Kaffee noch läuft. Drei Nachrichten aus dem Wochenende. Ein Gynäkologe meldet sich krank. Ein orthopädischer Patient wurde wegen einer Infektion nicht operationsbereit entlassen. Eine Familienangehörige hat kurzfristig abgesagt, was einen Begleittransport unmöglich macht. Drei Ausfälle — bei sechs OP-Sälen und einem Tagesprogramm, das in zwei Stunden beginnt.

Miriam zieht das Excel auf. Daneben das SAP IS-H, das die geplante Belegung zeigt. Sie hat 6 Listen mit insgesamt 34 Eingriffen. Drei davon fallen weg. Die verbleibenden 31 müssen auf 5 operationsfähige Säle verteilt werden — unter Berücksichtigung, welche Chirurgen gerade verfügbar sind, welche Anästhesistinnen eingeteilt sind, welche Geräte für welchen Eingriff gebucht sind, und welche Eingriffe nach OP-Hygieneabfolge zusammenpassen.

Sie schiebt, tauscht, kalkuliert. Um 9:14 Uhr schickt sie die neue Tagesliste raus. Die Anästhesieleitung ruft zurück: Zwei Zuordnungen funktionieren nicht, weil die Robotikeinheit nur in Saal 3 steht und Saal 3 schon voll ist. Zurück auf Anfang.

Das Programm startet mit 45 Minuten Verspätung. Saal 2 hat am Nachmittag eine Lücke von anderthalb Stunden, die niemand mehr füllen kann — zu kurzfristig, um einen Patienten aus dem Wartepool zu holen.

Das passiert nicht wegen Miriams Inkompetenz. Es passiert, weil die Kombinatorik von 31 Eingriffen, 5 Sälen, 12 Chirurgen und 8 Anästhesistinnen mit diversen Geräteverfügbarkeiten rechnerisch kaum noch manuell beherrschbar ist — und weil das System keine Prognose kennt, sondern nur Durchschnittswerte je Eingriff.

Das echte Ausmaß des Problems

Ein OP-Saal kostet im laufenden Betrieb 15–40 Euro pro Minute — je nach Personalbesetzung, Geräteeinsatz und Raumgröße. Das sind 7.200 bis 19.200 Euro pro Acht-Stunden-Tag. Wenn eine Stunde leer steht, ist das Geld weg — kein DRG-Erlös, keine Leistung, aber die vollen Fixkosten laufen weiter.

Studien und Praxisberichte aus deutschen Krankenhäusern zeigen: Zwischen 20 und 35 Prozent der geplanten OP-Kapazität geht in der Realität durch Leerläufe verloren. Der häufigste Auslöser sind nicht technische Pannen oder Notfälle, sondern schlicht falsch eingeschätzte OP-Dauern. Ein Eingriff, für den 90 Minuten eingeplant waren, dauert 55 Minuten — und die restlichen 35 Minuten sind für keinen weiteren Eingriff nutzbar, weil der Plan dafür keinen Spielraum vorsah.

Das Gegenteil ist genauso schmerzhaft: Eingriffe, die länger dauern als geplant, verschieben den gesamten Tagesplan. Das Team macht Überstunden, ambulante Patienten warten, Nachfolgeeingriffe werden verschoben oder abgesagt.

Der entscheidende Konstruktionsfehler im klassischen Planungsmodell: OP-Dauern werden als Durchschnittswert je Eingriffskategorie gespeichert. Das System kennt keine Unterschiede zwischen einer routinierten Chirurgin mit 800 Eingriffen und einem Assistenzarzt im dritten Jahr. Es berücksichtigt nicht, ob der Patient 78 Jahre alt ist und einen ASA-Score von 3 hat. Es ignoriert, ob es sich um einen Ersteingriff oder eine Revision handelt.

Zur wirtschaftlichen Dimension: Bei einem Haus mit 6 OP-Sälen und 250 Betriebstagen pro Jahr entspricht eine Stunde weniger Leerlauf pro Saal täglich 1.500 eingesparten oder zusätzlich abrechenbaren Stunden pro Jahr. Je nach Eingriffsmix sind das 300.000 bis über 600.000 Euro Mehrerlös — oder, realistischer formuliert: 300.000 Euro weniger subventionierter Leerlauf.

Klinikum Stuttgart hat das gemessen: Nach Einführung von Predictive Analytics-gestützter OP-Planung mit Getinge Torin stieg die Saalauslastung in der Kernbetriebszeit um 6%, das Haus führte jährlich rund 2.000 zusätzliche Eingriffe durch und steigerte den Gewinn um 4 Prozent.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete klinische, haftungsrechtliche und regulatorische Anforderungen (MDK, MPG, KRITIS) sind mit Klinikhygiene, Rechtsabteilung und IT-Sicherheitsbeauftragten abzustimmen.

Mit vs. ohne KI — ein ehrlicher Vergleich

KennzahlOhne KIMit ML-gestützter OP-Planung
Planungsabweichung (geplant vs. tatsächlich)30–45 Minuten je Eingriff15–25 Minuten je Eingriff ¹
OR-Auslastung in der Kernbetriebszeit65–75%71–82% ¹
Überstunden im OP-Personalhäufig, schwer planbarbis zu 25% reduzierbar ¹
Resequencing nach Ausfall1,5–3 Stunden manuell15–30 Minuten mit Systemunterstützung ¹
Erlös durch zusätzliche EingriffeBaseline+3,4% Kapazität (Klinikum Stuttgart) ²
Chirurgenspezifische Prognosekeinevorhanden (nach Trainingsphase)

¹ Eigene Schätzwerte basierend auf nextOR-Herstellerangaben (40% höhere Planungspräzision, 25% weniger Überstunden) und PMC-Studien zu ML-basierter OP-Dauerprognose. Ergebnisse sind stark abhängig von Datenqualität, Eingriffsverteilung und Umsetzungsdisziplin. ² Klinikum Stuttgart / Getinge Torin, gemessen nach erstem Implementierungsjahr (Getinge, 2022).

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5)
Das Planungsteam spart täglich 1–2 Stunden manueller Koordinationsarbeit — bei Notfall-Resequencing manchmal sogar 3 Stunden. Das ist real, aber nicht der Hauptgewinn. Der eigentliche Wert liegt in der zurückgewonnenen OR-Kapazität, nicht in eingesparter Arbeitszeit. Verglichen mit anderen Gesundheits-Anwendungsfällen wie der KI-gestützten Arztbriefschreibung, die täglich je Arzt Stunden einsparen, ist hier der Zeitvorteil konzentrierter aber weniger personenbreit.

Kosteneinsparung — sehr hoch (5/5)
Das ist der stärkste wirtschaftliche Hebel in dieser Kategorie. Eine Stunde weniger Leerlauf pro Saal und Tag entspricht 90–120 Minuten zusätzlicher abrechenbarer OR-Zeit pro Woche. Bei 6 Sälen und 250 Betriebstagen: potenziell 300.000–600.000 Euro Mehrerlös pro Jahr — nachweisbar über die DRG-Erlösstatistik. Kein anderer Anwendungsfall im Gesundheitsbereich hat vergleichbare direkte Auswirkungen auf den Krankenhauserlös.

Schnelle Umsetzung — schwierig (2/5)
Das ist die ehrlichste Einschätzung in diesem Artikel: KIS-Integration, historische Datenbereinigung, Modelltraining, Validierungsphase, Change Management mit Chirurgen — realistisch 9–18 Monate bis zum produktiven Betrieb. Wer etwas anderes verspricht, hat die Schnittstellen zu SAP IS-H oder Orbis noch nicht gesehen. Unter den Gesundheits-Anwendungsfällen ist dies einer der aufwändigsten Einstiege — zusammen mit dem Sepsis-Frühwarnsystem.

ROI-Sicherheit — hoch (4/5)
Der Nutzen ist messbar: OR-Auslastungsrate (Minuten genutzter vs. verfügbarer OP-Zeit), Anzahl abgerechneter Eingriffe, Überstundenvolumen. Klinikum Stuttgart hat das alles gemessen und veröffentlicht. Die Unsicherheit liegt in der Implementierungsqualität und im Chirurgen-Buy-in — deshalb keine 5. Wer schlechte Daten eingibt und das System an der Schnittstelle zum Alltag nicht angenommen wird, sieht keinen ROI.

Skalierbarkeit — mittel (3/5)
Ein Modell, das für Standort A trainiert wurde, lässt sich nicht 1:1 auf Standort B übertragen — verschiedene Chirurgenteams, unterschiedliche Eingriffsmixe, andere Gerätelandschaft. Für einen einzelnen Standort ist die Skalierung auf mehr Säle einfach. Konzernintern auf 5 Standorte hochzuziehen bedeutet 5 Implementierungsprojekte, nicht eines.

Richtwerte — stark abhängig von Eingriffsmix, Datenqualität und Implementierungstiefe.

Was das System konkret macht

Klassische OP-Planung arbeitet mit einem Punktwert: „Kniearthroskopie = 65 Minuten”. Das ist der historische Durchschnitt aller Kniearthroskopien in der Datenbank — unabhängig vom Chirurgen, vom Patienten, vom Zeitpunkt.

Machine Learning arbeitet anders. Statt eines Durchschnittswerts lernt das Modell aus tausenden historischer OP-Datensätze, welche Faktorkombinationen zu kürzeren oder längeren Operationen geführt haben:

  • Chirurgenspezifisch: Chirurgin A braucht bei Kniearthroskopien im Schnitt 58 Minuten, Assistenzarzt B 79 Minuten — und das Modell weiß, warum
  • Patientenspezifisch: ASA-Score 3, Body-Mass-Index > 35, Revisions-Eingriff — jeder Faktor verschiebt die Prognose
  • Kontext: Erster Eingriff des Tages dauert im Schnitt 7% länger als der zweite (Einrichtungszeit), Montage-Eingriffe weichen systematisch von Mittwoch-Eingriffen ab

Statt eines Punktwerts liefert das Modell eine Verteilung: P50 (50% der Fälle dauern kürzer) und P90 (90% der Fälle dauern kürzer). Damit können Planer bewusst entscheiden: Dieser kurze Eingriff am Ende des Tages bekommt den P50-Wert — bei 30 Minuten Restzeit ist das vertretbar. Dieser komplexe Revisionseingriff bekommt den P90-Puffer — 20 Minuten Sicherheitsabstand, damit der Saal pünktlich schließt.

Auf Basis dieser Verteilungen berechnet eine Constraint-Optimierungsschicht den Tagesplan: Welche Eingriffe in welcher Reihenfolge in welchen Saal? Unter Berücksichtigung von Geräte- und Raumverfügbarkeit, Chirurgenpräferenzen, Hygieneabfolgen und Personalverfügbarkeit.

Das Ergebnis ist kein autonom erstellter Plan — der OP-Manager entscheidet und freigibt. Aber statt mit einem leeren Excel zu beginnen, startet die Planung mit einem optimierten Vorschlag, der in Minuten angepasst werden kann.

Seoul National University Hospital validierte einen Random-Forest-Ansatz an 240.654 chirurgischen Datensätzen (2018–2022) und erreichte einen R²-Wert von 0,92 — die Modelle erklärt 92% der Varianz in der tatsächlichen OP-Dauer (Springer Journal of Medical Systems, 2025).

Wenn der Chirurg kurzfristig ausfällt — das Notfall-Resequencing-Problem

Ausfall-Szenarien wie Miriams Montag sind kein Ausnahmefall. Krankenhausplaner berichten von durchschnittlich 2–4 kurzfristigen Planänderungen pro OP-Tag — Krankmeldungen, Notfallaufnahmen, Geräteausfälle, Patientenabsagen.

Das Kernproblem beim Resequencing ist die Kombinatorik: Jede Verschiebung erzeugt Folgeanpassungen. Wenn Saal 3 wegen eines Ausfalls neu belegt werden muss, ist das nicht nur eine Frage, welcher Eingriff passt — sondern ob die Anästhesistin verfügbar ist, ob das Implantatlager den passenden Artikel hat, ob die Hygieneabfolge mit dem Voreingriff kompatibel ist, und ob der Patient schon prämedziert wurde.

Ein ML-gestütztes System kann diese Szenarien in Sekunden berechnen und priorisierte Alternativpläne vorschlagen — nicht als Automat, sondern als Entscheidungsunterstützung für den OP-Manager. Das Ergebnis: Resequencing in 15–30 Minuten statt 2–3 Stunden manuellem Umplanen.

Was das System dabei nicht lösen kann: die menschliche Kommunikation. Selbst wenn der optimale Plan in zwei Minuten berechnet ist — die Chirurginnen müssen informiert werden, das Pflegepersonal umgeplant, der nächste Patient aus dem Wartebereich geholt. Der administrative Ablauf um die technische Lösung herum bleibt Aufgabe des OP-Managements.

Praxistipp für Einführungsteams: Beginnt nicht mit dem Regelbetrieb, sondern mit einer dreimonatigen Parallel-Simulationsphase. Das Planungsteam führt weiterhin den manuellen Plan, sieht aber parallel den KI-Vorschlag — und kann nachvollziehen, wo die Systeme divergieren und warum. Das baut Vertrauen auf, bevor das System zur primären Planungsinstanz wird.

Diese Darstellung beschreibt das technische Resequencing-Prinzip. Die Verantwortung für patientensicherheitsrelevante Entscheidungen (Hygieneabfolge, medizinische Dringlichkeit, Anästhesiefreigabe) verbleibt bei den klinisch Verantwortlichen — ein System liefert Vorschläge, keine Anordnungen.

Was die KIS-Integration wirklich bedeutet

Wer in einem deutschen Krankenhaus über OP-Daten-basiertes Machine Learning spricht, muss über KIS-Integration sprechen. Und wer über KIS-Integration spricht, muss Klartext reden: Das ist das aufwändigste Element des Projekts, nicht das ML-Modell.

SAP IS-H — mit Ablaufdatum. SAP hat angekündigt, IS-H 2030 einzustellen. Viele deutsche Häuser befinden sich deshalb gerade in einer KIS-Übergangssituation: IS-H läuft noch, ein Nachfolger (häufig Dedalus ORBIS) ist in Evaluation oder Einführung. Ein ML-Modell, das auf IS-H-Daten trainiert wurde, muss nach einem KIS-Wechsel vollständig neu kalibriert werden — die Datenstruktur, Prozesscodes und Zeitstempel-Definitionen können sich fundamental unterscheiden.

Was das konkret bedeutet: Wer 2026 mit einem ML-Projekt auf IS-H-Basis startet und 2028 auf ORBIS migriert, startet das ML-Projekt danach faktisch von vorn. Das ist nicht ein Argument gegen den Start — aber ein Argument dafür, jetzt mit sauberer Datendokumentation zu beginnen, damit das Retraining nach der Migration schneller geht.

HL7 und FHIR — der Goldstandard, der in der Praxis holpert. Die ISiK-Standards schreiben seit 2023 FHIR-konforme Schnittstellen für deutsche Krankenhäuser vor. In der Theorie bedeutet das: Modernes KIS hat eine standardisierte FHIR-Schnittstelle, ML-System koppelt an, fertig. In der Praxis: Ältere HL7-v2-Installationen haben proprietäre Erweiterungen, Zeitstempel-Inkonsistenzen und fehlende Felder. Die Datenbereinigung dauert länger als das Modelltraining.

Checkliste vor Projektstart:

  • Sind chirurgische Eingriffe strukturiert kodiert (OPS-Code), oder nur als Freitext?
  • Werden Beginn und Ende (Schnitt und Naht) als separate Zeitstempel dokumentiert?
  • Existiert eine saubere Zuordnung Chirurg→Eingriff→tatsächliche Dauer, ohne manuelle Nachkorrekturen?
  • Ist der Anästhesiebeginn separat erfasst (für Einleitungszeit)?

Vier Ja-Antworten bedeuten: Das Projekt kann in 9–12 Monaten starten. Weniger als vier bedeuten: Zuerst Datenqualitätsprojekt, dann ML.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete klinische, haftungsrechtliche und regulatorische Anforderungen (MDK, MPG, KRITIS) sind mit Klinikhygiene, Rechtsabteilung und IT-Sicherheitsbeauftragten abzustimmen.

Konkrete Werkzeuge — was wann passt

Getinge Torin — der etablierte internationale Standard für KI-gestütztes OR-Management. Klinikum Stuttgart hat Torin seit 2017 im Einsatz und dokumentiert messbare Ergebnisse: 36% höhere Plangenauigkeit, 6% mehr Auslastung, 2.000 zusätzliche Eingriffe pro Jahr. Torin bietet tiefe Integration in bestehende KIS-Landschaften (HL7, FHIR), Performance-Analytics und Echtzeit-Tagesplanung. Subscription-Modell, Preis auf Anfrage. Geeignet für Häuser mit 5+ OP-Sälen und vorhandener digitaler OP-Dokumentation. Getinge ist ein Medizintechnik-Konzern mit globalem Support — das bedeutet Stabilität, aber auch längere Entscheidungsprozesse beim Anbieter.

nextOR — das deutsche SaaS-Pendant. nextOR GmbH und SAP haben eine Partnerschaft für die DACH-Region, was die SAP IS-H-Integration erleichtert. Bidirektionale FHIR-Schnittstelle, Cloud oder On-Premise, DSGVO-nativ. Herstellerangaben: 40% höhere Planungspräzision, 25% weniger Überstunden, über 60% weniger Prozesskosten im administrativen OP-Management. SaaS-Jahresgebühr basierend auf Eingriffszahl — kein fixer Lizenzblock. Für Häuser, die eine deutsche Lösung mit lokaler Unterstützung und SAP-Integration bevorzugen.

Custom-ML-Ansatz (intern oder mit KI-Dienstleister) — Für Häuser, die vollständige Datenkontrolle benötigen oder besondere Eingriffsmixe haben (z.B. Universitätskliniken mit hohem Anteil experimenteller Verfahren). Gradient-Boosting-Modelle (XGBoost, LightGBM) kombiniert mit Quantilregression sind Stand der Forschung. Entwicklungsaufwand: 6–18 Monate je nach Datenqualität. Laufende Kosten: Infrastruktur + Retraining. Empfehlenswert, wenn Sonderanforderungen an Integrationen oder Datenhaltung bestehen, die Standardlösungen nicht erfüllen.

Zusammenfassung: Wann welcher Ansatz

  • Etablierte internationale Lösung, 5+ Säle → Getinge Torin
  • Deutsche SaaS-Lösung mit SAP-Integration → nextOR
  • Vollständige Datenkontrolle, Uni-Klinik oder Sonderanforderungen → Custom ML mit KI-Dienstleister

Eine kostenlose Eigenentwicklung mit generischen Open-Source-Tools (z.B. scikit-learn auf rohen KIS-Exporten) ist technisch möglich, aber in der Praxis nicht empfehlenswert: Der Aufwand für saubere Datenextraktion, Modellvalidierung und klinischen Qualitätssicherungsprozess übersteigt bei den meisten Häusern den Preis einer Speziallösung.

Datenschutz und Datenhaltung

OP-Daten sind medizinische Daten und damit besonders schützenswerte personenbezogene Daten nach Art. 9 DSGVO. Das Krankenhaus ist Verantwortlicher im Sinne der DSGVO; jeder externe Anbieter, der OP-Daten verarbeitet, muss über einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO eingebunden werden.

Beide Hauptlösungen erfüllen die EU-Anforderungen, aber mit unterschiedlichem Profil:

  • Getinge Torin: Getinge ist ein schwedisches Unternehmen, Cloud-Hosting in der EU verfügbar. AVV erhältlich. Für Daten im Cloud-Betrieb: sicherstellen, dass EU-Rechenzentrum ausdrücklich im Vertrag vereinbart ist.
  • nextOR: Deutsches Unternehmen, DSGVO-native Architektur, On-Premise-Option verfügbar. Für Häuser mit strengen Datenlokalisierungsanforderungen die einfachere Wahl.

Für Krankenhäuser unter KRITIS-Regularien (Häuser mit mehr als 30.000 vollstationären Fällen/Jahr) gilt zusätzlich: Jedes neue IT-System, das kritische Prozesse wie die OP-Planung berührt, unterliegt dem Branchenspezifischen Sicherheitsstandard B3S für Krankenhäuser und muss in das IT-Sicherheitskonzept eingebunden werden. Die Meldepflichten gegenüber dem BSI bei Sicherheitsvorfällen gelten auch für KI-gestützte Planungssysteme.

Eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist empfehlenswert, wenn das ML-System individuelle Chirurgenprofile erstellt — das gilt als systematische Verarbeitung zu Bewertungszwecken.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete klinische, haftungsrechtliche und regulatorische Anforderungen (MDK, MPG, KRITIS) sind mit Klinikhygiene, Rechtsabteilung und IT-Sicherheitsbeauftragten abzustimmen.

Was es kostet — realistisch gerechnet

Einmalige Projektkosten

  • Datenaudit und KIS-Schnittstellenanalyse: 15.000–40.000 Euro (abhängig von KIS-Komplexität und externem Beratungsanteil)
  • Implementierung und Integration (Anbieter): variiert stark — in der Regel im sechsstelligen Bereich für ein Haus mit 6+ Sälen
  • Interne Projektkosten: OP-Manager-Zeit, IT-Zeit, klinische Projektleitung — oft unterschätzt

Laufende Kosten (jährlich)

  • Lizenz/SaaS: Abhängig von Eingriffsvolumen; für ein Haus mit 6.000–10.000 Eingriffen/Jahr sind 80.000–200.000 Euro realistisch (keine verifizierten Listenpreise — Orientierung aus Marktbeobachtung)
  • Systempflege, Retraining-Zyklen: 10–15% der Erstimplementierungskosten jährlich

Konservative ROI-Rechnung 6 OP-Säle, 250 Betriebstage, Ziel: 45 Minuten weniger Leerlauf pro Saal und Tag.

45 Minuten × 6 Säle × 250 Tage = 67.500 Minuten = 1.125 Stunden Mehrkapazität pro Jahr.

Bei einem durchschnittlichen DRG-Erlös von 1.500 Euro je Stunde genutzter OR-Zeit (grober Richtwert — je nach Eingriffsmix stark abweichend) entspricht das 1.687.500 Euro potenzieller Mehrerlös. Realistisch erreichbar in den ersten 18 Monaten: 30–50% davon, also 500.000–840.000 Euro.

Die Investition in Implementierung und Betrieb liegt in der Regel darunter — aber nur, wenn das Datenqualitäts- und Change-Management-Problem gelöst ist. Häuser, die das Projekt starten und dann an schlechter Datenqualität oder Chirurgen-Widerstand scheitern, realisieren keinen ROI.

Wie du den Nutzen tatsächlich misst
Basiskennzahl vor Start: OR-Auslastungsrate in der Kernbetriebszeit (dokumentierte Nutzungsminuten / verfügbare Betriebsminuten). Diese Zahl erhebst du aus dem bestehenden KIS — sie ist die Baseline. Nach Einführung messbar: Auslastungsrate, Eingriffszahl, Überstundenvolumen. Wenn diese drei Kennzahlen nach 12 Monaten nicht messbar besser sind, stimmt etwas mit der Implementierungsqualität oder dem Chirurgen-Buy-in nicht.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. DRG-Erlöse, Vollkosten-Kalkulation und konkrete Abrechnungsfragen sind mit der Krankenhausverwaltung, dem Medizincontrolling und ggf. dem MDK-Beauftragten abzustimmen.

Typische Einstiegsfehler

1. Das Projekt beginnt beim ML-Modell statt bei den Daten.
Ein Gradient-Boosting-Modell ist in vier Wochen entwickelt. Die Frage ist, womit es trainiert wird. Wenn die OP-Dokumentation im KIS Zeitstempel enthält, die manuell nachkorrigiert wurden, keine konsistente Chirurgenzuordnung hat, oder Eingriffe unterschiedlich kodiert wurden (Freitext vs. OPS), dann trainierst du das Modell auf Rauschen. Die Ergebnisse sehen statistisch akzeptabel aus und sind klinisch nutzlos. Lösung: Datenaudit zuerst, Modell danach.

2. Das System wird eingeführt, aber die Chirurgen werden nicht abgeholt.
Ein OP-Manager, der den KI-Vorschlag in die Tagesplanung übernimmt, ohne dass die Chirurgen wissen, wie er zustande kommt, schafft Misstrauen. „Das System schätzt, dass deine Leistenhernien 12 Minuten länger dauern als der Durchschnitt” klingt nach einer Kritik. Lösung: Transparenz über die Modelllogik. Zeig Chirurginnen, welche Faktoren ihre individuelle Prognose beeinflussen. Wer die Logik versteht, akzeptiert das System leichter.

3. Das Modell wird einmal trainiert und nie aktualisiert.
Das ist der gefährlichste Fehler — weil er still passiert. Ein Modell, das auf den Daten von 2022–2024 trainiert wurde, kennt nicht die neue Chirurgin, die seit März 2025 im Haus ist. Es kennt nicht den veränderten Robotik-Workflow nach dem neuen da-Vinci-System. Es kennt nicht die neue Prämedikationsroutine, die die Einleitungszeit um 8 Minuten verlängert. Sechs Monate nach Rollout prognostiziert das System schlechter als bei der Inbetriebnahme — und niemand hat es bemerkt, weil niemand die Baseline-Kennzahlen regelmäßig prüft. Lösung: Vierteljährliches Modell-Review einplanen, in dem Planungsabweichung und Modellgenauigkeit ausgewertet werden.

4. Zu viele Eingriffskategorien gleichzeitig optimieren.
Je komplexer ein Eingriff, desto höher die Varianz — und desto schlechter die ML-Prognose. Herzchirurgie, Polytrauma-OPs und Revisionseingriffe bei Komplikationen haben Dauervarianzspannen von 50–200%, die kein Modell zuverlässig vorhersagen kann. Lösung: Mit den Elektiv-Eingriffen starten, bei denen die Varianz beherrschbar ist: Knie-Arthroskopien, Katarakt-OPs, Hüft-Prothesen-Erstimplantationen. Die Gains in diesen Kategorien finanzieren den Aufwand — komplexe Eingriffe kommen später.

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

Der technische Teil des Projekts ist handhabbar. Das Schwierige ist die Organisation.

Die Chirurgen. Sie sind es gewohnt, OP-Dauern selbst einzuschätzen. Das System sagt ihnen jetzt, dass ihre Einschätzung im Schnitt 22 Minuten zu optimistisch ist. Das wird nicht alle begeistern. Die Einführung gelingt nicht durch Anordnung, sondern durch Transparenz: Zeige den Chirurgen ihre eigene Prognosegenauigkeit über die letzten 12 Monate — und erkläre, wie das Modell diese Information nutzt. Wer in den Daten sieht, dass er sich systematisch um 20 Minuten verschätzt, ist offener für externe Unterstützung.

Die OP-Koordinatorinnen. Für sie bedeutet das System zunächst Mehraufwand: Eingabedisziplin im KIS steigt (vollständige Zeitstempel, korrekte Chirurgenzuordnung), weil das Modell von dieser Qualität abhängt. Der Widerstand: „Jetzt soll ich noch mehr dokumentieren, damit ein System meinen Job macht.” Die Antwort: Das System macht weniger Arbeit, nicht mehr — aber erst nach einer 3-monatigen Qualitätsverbesserungsphase. Diese Ehrlichkeit muss vorab kommuniziert werden.

Die IT-Abteilung. Das Projekt hat eine KIS-Schnittstelle, eine Cloud-oder-On-Premise-Entscheidung, ein Datensicherheitskonzept und KRITIS-Compliance-Anforderungen. IT ist kein optionaler Beifahrer, sondern Kernteam-Mitglied ab Tag eins. Ein Projekt, das IT erst einbezieht, wenn das Modell schon entwickelt ist, verliert 6 Monate Umsetzungszeit.

Was in der Praxis funktioniert:

  • Pilotfachbereich wählen, der das Projekt aktiv unterstützt (nicht den Fachbereich mit den meisten Problemen)
  • Drei Monate paralleles Monitoring: System-Prognose vs. manueller Plan, ohne Eingriff in den Regelbetrieb
  • Monatliches Steuerungsmeeting mit OP-Manager, IT und mindestens einem leitenden Chirurgen
  • Kein „Big Bang”-Rollout auf alle Säle gleichzeitig — ein Saal pro Monat ist nachhaltiger

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete KRITIS-Pflichten, B3S-Umsetzung und BSI-Meldewege sind mit dem IT-Sicherheitsbeauftragten und der Rechtsabteilung abzustimmen.

Realistischer Zeitplan mit Risikohinweisen

PhaseDauerWas passiertTypisches Risiko
Datenaudit & KIS-AnalyseMonat 1–2Zeitstempel-Qualität prüfen, Schnittstellen inventarisieren, fehlende Felder identifizierenDaten schlechter als erwartet — zusätzliche Bereinigungsphase nötig
Datenbereinigung & AufbauMonat 2–4Historische Daten normalisieren, Chirurgenzuordnung vervollständigen, Eingriffskodierung vereinheitlichenKeine IT-Kapazität — Projekt wartet auf interne Ressource
Modelltraining & ValidierungMonat 4–7ML-Modell trainieren, P50/P90-Prognosen validieren, klinische PlausibilitätsprüfungModell gut im Test, schlechter im Realbetrieb — mehr Eingriffskategorien nötig
KIS-SchnittstellenintegrationMonat 5–9 (Überlappung)HL7/FHIR-Anbindung konfigurieren und testen, bidirektionalen Datenaustausch sicherstellenÄlteres KIS liefert nicht alle benötigten Felder — Workarounds nötig
Pilotbetrieb (1 Fachbereich)Monat 8–11Parallelbetrieb: System-Vorschlag neben manuellem Plan, Rückmeldungen einsammelnChirurgen nehmen Vorschläge nicht an — Kommunikationsarbeit nötig
Rollout & VollbetriebMonat 12–18Schrittweiser Übergang auf KI-gestützte Planung, Modell-Review-Zyklus etablierenPersonalwechsel im OP-Management — neues Team muss eingearbeitet werden

Häufige Einwände — und was dahintersteckt

„Unsere Eingriffe sind zu komplex, da kann kein Modell planen.”
Die komplexen Eingriffe sind tatsächlich schwer zu prognostizieren — und das ist auch gar nicht das Ziel. Ein Herzklappen-Eingriff mit unbekanntem intraoperativen Befund kann kein ML-System auf 10 Minuten genau schätzen. Aber 60–70% des elektiven OP-Programms eines typischen deutschen Hauses besteht aus Eingriffen mit beherrschbarer Varianz: Katarakts, Hüft- und Knieprothesen, Hernien, Cholezystektomien. Genau dort liegen die Gewinne. Die komplexen Fälle bekommen großzügige Zeitpuffer — das ist keine Schwäche des Systems, sondern sein Quantilregression-Mechanismus in der Praxis.

„Wir haben das mit Excel gut im Griff.”
Vielleicht stimmt das für den Regelbetrieb. Die Frage ist, was bei drei Montagausfällen passiert, wenn die Planung um 7:41 Uhr beginnt und um 9:00 Uhr fertig sein muss. Excel kann keine Constraint-Optimierung, kennt keine Prognoseverteilungen und zieht keine Geräteverfügbarkeiten in Echtzeit. Der Resequencing-Fall ist die schärfste Probe — und da zeigt sich der Unterschied am deutlichsten.

„Wir können uns das nicht leisten.”
Dann rechne zuerst, was der Status quo kostet. Wenn ein Saal täglich 45 Minuten leer steht, sind das bei 250 Betriebstagen 11.250 Minuten — etwa 187 Stunden ungenutzte OR-Zeit. Bei einem mittleren DRG-Erlös von 1.500 Euro/Stunde (grober Richtwert) entspricht das 280.500 Euro jährlich — pro Saal. Bei sechs Sälen: über 1,5 Millionen Euro struktureller Mindererlös pro Jahr. Die Software kostet einen Bruchteil davon. Wer sagt, das sei zu teuer, hat noch nicht die Vollkosten des Leerlaufs ausgerechnet.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. DRG-Erlöse, Vollkosten-Kalkulation und konkrete Abrechnungsfragen sind mit der Krankenhausverwaltung, dem Medizincontrolling und ggf. dem MDK-Beauftragten abzustimmen.

Woran du merkst, dass das zu dir passt

  • Du betreibst mindestens 4 OP-Säle mit einem überwiegend elektiven Programm und messbarer Leerzeit zwischen Eingriffen
  • Die OP-Planung läuft über SAP IS-H oder ORBIS mit dokumentierten Eingriffs-Zeitstempeln (Schnitt und Naht als separate Felder)
  • Dein Haus führt mehr als 5.000 elektive Eingriffe pro Jahr durch — das ist die Mindestdatenmenge für ein stabiles ML-Modell
  • Du hast 2+ Jahre historische OP-Daten mit Chirurgenzuordnung und tatsächlichen (nicht manuell korrigierten) Endzeiten
  • Die Leerzeit im OP ist quantifiziert: Du weißt, wie viele Minuten täglich je Saal ungenutzt bleiben — nicht geschätzt, sondern aus dem KIS ausgelesen
  • Leitende Chirurgen sind bereit, ihre Prognosegenauigkeit zu diskutieren — ohne diese Offenheit scheitert jedes Planungssystem

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

  1. Weniger als 4 OP-Säle oder unter 5.000 elektive Eingriffe pro Jahr. Unter dieser Schwelle fehlt die Datenbasis für ein stabiles ML-Modell — die Fallzahl je Eingriffskategorie pro Chirurg ist zu klein für verlässliche Prognosen. Eine Standardsoftware für OP-Scheduling (ohne ML) kostet weniger und liefert den größten Teil des Nutzens.

  2. Keine strukturierte digitale OP-Dokumentation im KIS. Wenn Eingriffe hauptsächlich als Freitext dokumentiert sind, Zeitstempel fehlen oder manuell nachkorrigiert werden, ist das Datenqualitäts-Projekt der erste Schritt — nicht das ML-System. Ein Modell, das auf Freitext-Chaos trainiert wird, ist schlechter als keine Prognose.

  3. KIS-Migration in den nächsten 18 Monaten geplant. Der Übergang von SAP IS-H auf ein neues KIS (z.B. Dedalus ORBIS) bedeutet Datenstrukturbruch. Ein ML-Modell, das mit IS-H-Daten trainiert wurde, muss danach vollständig neu entwickelt werden. Starte das ML-Projekt erst nach der Migration — oder nutze die Übergangszeit für die Datenqualitäts-Vorarbeit.

Das kannst du heute noch tun

Bevor du eine Software evaluierst, erstelle eine Baseline. Nimm die letzten 90 Tage OP-Daten aus dem KIS und berechne: Wie viel Prozent der geplanten Operationszeit war tatsächlich genutzte OR-Zeit? Wie groß ist die durchschnittliche Abweichung zwischen geplantem und tatsächlichem Ende je Eingriffskategorie?

Diese zwei Kennzahlen kosten keinen Cent und keine Software. Sie zeigen, ob ein ML-Projekt sich lohnt — und sie sind die Baseline, gegen die jede spätere Verbesserung gemessen wird.

Als zweiten Schritt kannst du das Resequencing-Problem direkt mit einem LLM testen: Exportiere einen Tagesplan und drei hypothetische Ausfälle und gib den folgenden Prompt ein:

Resequencing-Prompt für Notfall-Umplanung
Du unterstützt mich als OP-Manager bei der Notfall-Umplanung nach kurzfristigen Ausfällen. Heutiger Tagesplan: [TAGESPLAN EINFÜGEN: Saal, Eingriff, geplante Dauer, Chirurg, Anästhesist] Ausgefallene Eingriffe heute: [AUSGEFALLENE EINGRIFFE EINFÜGEN: Eingriff, Grund, Saal] Verfügbare Ressourcen: - Verfügbare Chirurgen: [LISTE] - Verfügbare Anästhesisten: [LISTE] - Spezialgeräte: [GERÄTE UND SAALZUORDNUNG] - Verbleibende Zeit je Saal: [MINUTEN JE SAAL] Erstelle drei Resequencing-Vorschläge. Für jeden Vorschlag: 1. Welche Eingriffe fallen heute komplett aus 2. Wie werden verbleibende Eingriffe neu verteilt 3. Welche Risiken entstehen (Hygieneabfolge, Gerätekonflikte, Chirurgendoppelbelegung) Priorisierungsregeln: - Medizinisch dringliche Fälle haben Vorrang - Kurze Eingriffe (< 45 min) werden bevorzugt in Restzeiten eingeplant - Keine Chirurgen-Doppelbelegung - Geräte bleiben in zugewiesenem Saal
Funktioniert mit ChatGPT, Claude, Gemini
Beispiel-Ausgabe

Mitarbeiter:in

Tagesplan: Saal 1 — Hüftprothese 120min (Dr. Stein), Cholezystektomie 60min (Dr. Stein), Hernie 45min (Dr. Meyer). Saal 2 — Kniearthroskopie 65min (Dr. Braun), Schulterprothese 90min (Dr. Braun), Leistenhernie 40min (Dr. Lang). Ausgefallen: Dr. Braun krank — beide Saal-2-Eingriffe (Kniearthroskopie + Schulterprothese) fallen aus. Verfügbar: Dr. Meyer (Saal 3 frei ab 13:00), Dr. Lang (bis 16:00). Saal 2 frei. Robotik nur in Saal 3.

KI-Assistent

Vorschlag A — Kapazitätsmaximierung: Saal 1: Plan unverändert (Dr. Stein). Saal 2: Kniearthroskopie (65 min) auf Dr. Lang legen → passt in seine Verfügbarkeit bis 16:00, kein Gerätebedarf. Saal 3 ab 13:00: Schulterprothese mit Dr. Meyer — Robotik nicht nötig für Standard-Schulterprothese. Kein Eingriff wird gestrichen. 2 Säle laufen durch. Risiken: Dr. Lang hat heute schon Leistenhernie in Saal 2 (40 min) — Check: Ist Kniearthroskopie danach in derselben Raumhygieneklasse? → Ja (beide Klasse sauber-kontaminiert). Vorschlag B — Konservativer Plan: Kniearthroskopie streichen (Warteliste: kurzfristig ersetzbar). Schulterprothese auf nächsten Verfügbarkeitstermin Dr. Braun. Saal 2 ab Mittag für ambulante Kurzeingriffe aus dem Wartepool öffnen — Koordinator kontaktieren. Empfehlung: Vorschlag A, sofern Dr. Lang und Dr. Meyer keine Einwände. Bitte Hygienecheck Saal 2 (Dr. Braun-Abfolge) mit Klinikhygiene bestätigen.

Das Prompt-Ergebnis ersetzt keine spezialisierte Software — aber es zeigt dir innerhalb von 5 Minuten, ob die Logik des Resequencings systematisierbar ist, und welche Rahmenbedingungen du dafür brauchst. Wenn du das Prompt dreimal ausfüllst und dreimal sinnvolle Vorschläge zurückbekommst, ist der nächste Schritt: eine Demo bei nextOR oder Getinge Torin anfragen und das KIS-Datenaudit beauftragen.

Das LLM-Prompt ist eine Ideen-Skizze für die OP-Koordination, keine klinische Entscheidungsunterstützung. Medizinische Dringlichkeit, Hygieneabfolge und Patientensicherheit verbleiben bei den klinisch Verantwortlichen (OP-Leitung, Anästhesie, Klinikhygiene). LLM-Vorschläge dürfen nur als Diskussionsgrundlage dienen, nicht als Anweisung an das OP-Team.

Quellen & Methodik

  • Klinikum Stuttgart / Getinge Torin: Getinge: „Optimierung des OP-Managements: Wie KI den Alltag in OP und Klinik verbessert” (2022). Dokumentierte Ergebnisse nach Torin-Einführung ab 2017 / KI-Modul November 2021: 36% höhere Plangenauigkeit, 6% Saalauslastungssteigerung in Kernbetriebszeit, ca. 2.000 zusätzliche Eingriffe/Jahr, 4% Gewinnsteigerung. getinge.com
  • Seoul National University Hospital: Lee et al., „Development of Predictive Model of Surgical Case Durations Using Machine Learning Approach”, Journal of Medical Systems, Springer 2025. N=240.654 chirurgische Datensätze 2018–2022; Random Forest R²=0,92. PubMed
  • Brigham and Women’s Hospital / Leap Rail: PubMed, „Machine Learning Can Improve Estimation of Surgical Case Duration: A Pilot Study” (2019). 70% Reduktion der Planungsungenauigkeit, 7-Minuten-Verbesserung gegenüber konventioneller EHR-Schätzung. PubMed
  • Model Drift in klinischen ML-Systemen: PMC, „Data drift in medical machine learning: implications and potential remedies” (2023). Kalibrierungsdrift durch Fallmix-Verschiebungen — Hauptrisiko bei langfristiger ML-Nutzung in Krankenhäusern. PMC
  • nextOR GmbH: Herstellerangaben zu Produktperformance (40% höhere Planungspräzision, 25% weniger Überstunden, >60% weniger Prozesskosten) von next-or.de (Stand Mai 2026). Herstellerangaben ohne unabhängige Drittvalidierung.
  • SAP IS-H Abkündigungsdatum 2030: seppmed.com, „SAP IS-H endet 2030” (Januar 2026). seppmed.com
  • KRITIS-Krankenhaus: BSI-Schwellenwert > 30.000 vollstationäre Fälle/Jahr; B3S-Standard für Gesundheitsversorgung im Krankenhaus (DKG, Version 1.1). dkgev.de
  • OP-Betriebskosten pro Minute: Eigene Schätzung auf Basis publizierter Vollkostenberechnungen für deutsche Krankenhäuser (Bereich 15–40 €/Minute je nach Personalbesetzung, Geräteausstattung und Raumgröße).

Du willst wissen, ob euer KIS die nötige Datenqualität für ein ML-Projekt mitbringt — und was der erste realistische Schritt wäre? Das klären wir in einem kurzen Gespräch.

Diesen Inhalt teilen:

🤝

Interesse an diesem Use Case?

Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.

Deine Daten werden ausschließlich zur Bearbeitung deiner Anfrage verwendet (Art. 6 Abs. 1 lit. b DSGVO). Mehr in unserer Datenschutzerklärung.

Kostenloser Newsletter

Bleib auf dem neuesten
Stand der KI

Wähle deine Themen und erhalte relevante KI-News, Praxistipps und exklusive Inhalte direkt in dein Postfach – kein Spam, jederzeit abmeldbar.

Was interessiert dich? Wähle 1–3 Themen — du bekommst nur Inhalte dazu.

Mit der Anmeldung stimmst du unserer Datenschutzerklärung zu. Jederzeit abmeldbar.

Kostenlos
Kein Spam
Jederzeit abmeldbar