Sturzrisiko-Prognose: KI schützt sturzgefährdete Stationspatienten

Das echte Ausmaß des Problems

Sturzereignisse im Krankenhaus sind kein seltenes Randthema. Laut einer Analyse aus einer deutschen geriatrischen Klinik (Zeitschrift für Gerontologie und Geriatrie, Springer) fallen 9,1 Patienten pro 1.000 Krankenhaustage — bezogen auf alle Patienten der Station. Bei den Patienten, die tatsächlich stürzen, liegt die Rate bei 41,0 Sturzereignissen pro 1.000 Tage. In allgemeinen Akutkrankenhäusern liegt der Wert bei 3,05 Stürzen pro 1.000 Pflegetage — was auf den ersten Blick weniger dramatisch klingt, bis man die absoluten Zahlen hochrechnet.

Das Alter verstärkt das Risiko drastisch: Patienten über 85 Jahre stürzen fünfmal häufiger als die Altersgruppe 46 bis 55 Jahre (5,61 vs. 1,29 Stürze pro 1.000 Patiententage). Da Krankenhäuser in Deutschland immer ältere Patientinnen und Patienten behandeln, wächst das Problem systematisch.

Was bei einem Sturz konkret passiert:

• 8,8 % der gestürzten Krankenhauspatientinnen und -patienten erleiden schwere Verletzungen wie Frakturen (laut Aktionsbündnis Patientensicherheit, APS)
• Ein Sturzereignis verlängert den Krankenhausaufenthalt im Schnitt um 6,19 Tage — bei Sturz mit Verletzung auf 7,55 Tage (Sawetzki et al., Thieme 2014)
• Diese Mehrtage werden über das DRG-System oft nicht vollständig refinanziert: Wenn ein Patient länger als die DRG-kalkulierte Grenzverweildauer bleibt, entstehen dem Haus Verluste

Diese Darstellung ist eine fachliche Orientierung, kein Medizin- oder Rechtsersatz. Sturzdokumentation, Haftungsfragen und DRG-Auswirkungen sind mit Klinikleitung, Rechtsabteilung, MDK-Beauftragten und ggf. MDR-Beauftragten abzustimmen.

Die verbreitete Antwort — die Morse-Fall-Skala bei Aufnahme ausfüllen und hoffen, dass sie irgendwie gepflegt wird — hat ein strukturelles Problem: Sie ist ein Einmal-Snapshot in einem dynamischen Prozess. Medikamentenänderungen, neue Schmerzmedikation, veränderte Mobilität, nächtliche Verwirrtheitszustände — all das verändert das Sturzrisiko innerhalb von Stunden. Ein Score, der montags erhoben wurde und am Donnerstagabend als Entscheidungsgrundlage gilt, ist faktisch eine gefährliche Illusion.

Mit vs. ohne KI — ein ehrlicher Vergleich

Pilotdaten sind ermutigend, aber keine Garantie: Reduktionsraten variieren stark je nach Patientenpopulation, Sensortyp, Kalibrierungsqualität und Integration in Pflegeprozesse. Klinische Verantwortung für die Sturzprävention verbleibt beim Pflegepersonal und der ärztlichen Leitung.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Das System spart täglich etwa 20–30 Minuten pro Schicht, die bisher für manuelle Morse-Skala-Updates und Risikoeinschätzungsrunden aufgewendet wurden. Der entscheidende Vorteil ist aber keine Zeitersparnis, sondern eine Qualitätsverbesserung: Das System ersetzt nicht die Pflegekraft am Bett — Pflegekräfte müssen weiterhin auf jeden Alert reagieren, dokumentieren und klinisch beurteilen. Wer ein solches System mit dem Ziel einführt, Personalstunden zu sparen, denkt es falsch.

Kosteneinsparung — hoch (4/5) Jedes vermiedene Sturzereignis bedeutet im Schnitt sechs bis acht weniger Liegetage, vermiedene Röntgen- und OP-Kosten sowie reduzierte Haftungsrisiken. Bei einer Station mit einer Sturzrate von einem Sturz pro Woche und einer Reduktion um 50 % entstehen pro Jahr 25–30 vermiedene Ereignisse — bei 6 Mehrtagen à ca. 500 Euro Kostenträger-Tagesrate sind das potenzielle Ersparnisse von 75.000–90.000 Euro jährlich, noch ohne Haftungsschutz und DRG-Optimierung. Einrichtungskosten für Sensor-Hardware und Integration liegen typischerweise bei 80.000–200.000 Euro für eine Station — das Verhältnis ist wirtschaftlich interessant.

Kostenschätzungen basieren auf durchschnittlichen Tagespflegekosten und veröffentlichten Sturzraten. Die tatsächliche Wirtschaftlichkeit hängt stark von Patientenpopulation, Sturzkomplikationsrate, Verhandlung mit Kostenträgern und DRG-Fallpauschalen ab. Vor jeder Investitionsentscheidung: Abklärung mit Controlling und Abrechnung.

Schnelle Umsetzung — niedrig (2/5) Dieser Use Case ist einer der aufwendigsten im Gesundheitsbereich. MDR-Prüfung als Medizinprodukt, HL7-FHIR-Integration in ein bestehendes Krankenhausinformationssystem, klinische Validierung, Schulung aller Schichten, Kalibrierungsphase für Sensoren — realistisch sind 12 bis 18 Monate vom Pilotbeschluss bis zum stabilen Produktivbetrieb auf einer Station. Wer das in drei Monaten erwartet, wird frustriert. Ähnlich aufwendig wie ein Sepsis-Frühwarnsystem, aber mit einer stärker standardisierten Sensor-Hardware-Ebene.

ROI-Sicherheit — hoch (4/5) Sturzraten sind messbar, Verweildauerverlängerungen sind buchbar, DRG-Deckungslücken sind dokumentiert. Das macht den ROI-Nachweis hier konkreter als bei vielen anderen KI-Projekten im Gesundheitswesen. Die Unsicherheit liegt nicht in der KPI-Definition, sondern in der Variabilität der Wirksamkeit je nach Patientenmix, Sensorqualität und Akzeptanz im Pflegeteam.

Skalierbarkeit — hoch (4/5) Einmal implementiert und validiert, lässt sich das System auf weitere Stationen und im Krankenhausverbund auf weitere Häuser übertragen — ohne die MDR-Compliance-Arbeit von Grund auf neu zu beginnen. Die Skalierung ist nicht trivial, aber machbar: Sensor-Hardware ist weitgehend standardisiert, die Datenintegration über HL7 FHIR ermöglicht Wiederverwendbarkeit der Schnittstellenarbeit.

Richtwerte — stark abhängig von Klinikgröße, KIS-System, Patientenpopulation und verfügbaren Ressourcen für MDR-Compliance.

Was das System konkret macht

Das Prinzip ist dasselbe wie beim Sepsis-Frühwarnsystem: kontinuierliche Mustererkennung statt punktuelle Einschätzung. Konkret arbeitet ein KI-gestütztes Sturzrisiko-Monitoring auf drei Ebenen.

Ebene 1: Sensordaten Verschiedene Sensortypen liefern unterschiedlich nützliche Signale. Radarsensoren an der Zimmerdecke (wie Qumea) erkennen kontaktlos Bewegungssequenzen — die charakteristische Abfolge von “aufsetzen, Beine absenken, Gleichgewichtsproblem” ist in den Daten sichtbar, bevor der Patient steht. Druckmatten im Bett oder auf dem Boden erfassen Gewichtsverlagerungen. Wearables am Handgelenk messen Bewegungsintensität und -qualität über Nacht. Unter-Matratzen-Sensoren wie EarlySense kombinieren Vitalzeichen mit Bewegungsdaten und erkennen, wenn jemand unruhig wird.

Ebene 2: EHR-Integration Reine Sensordaten ohne Kontext sind begrenzt aussagekräftig. Das Modell wird signifikant besser, wenn es aktuelle Medikamentenlisten (Sedativa, Diuretika, Antihypertensiva, Opioide — alle bekannten Sturzfaktoren), aktuelle Laborwerte (Elektrolyte, Hämoglobin), Mobilisierungsdokumentation aus der letzten Schicht und eventuell Verwirrtheitsepisoden (CAM-Score) einschließt. Dafür ist eine HL7-FHIR-fähige Schnittstelle zum Krankenhausinformationssystem notwendig.

Ebene 3: Risikomodell und Alertlogik Ein Machine Learning-Modell — in der Praxis meist ein Random Forest oder XGBoost — kombiniert Sensor- und EHR-Signale zu einem Risikoscore je Patient. Das Modell wird auf klinikinternen historischen Falldaten trainiert und erkennt Muster, die menschlichen Beobachtern nicht auffallen: zum Beispiel, dass Herr Meindl mit seiner Kombination aus Diuretikagabe abends, erhöhter Nachtaktivität und niedrigem Hemoglobin-Wert in 68 % der ähnlichen Fälle in den ersten vier Nachtschichtstunden einen Bettausstiegsversuch unternimmt.

Der Score löst gestaffelte Aktionen aus: grün (Routineüberwachung), gelb (erhöhte Aufmerksamkeit bei der nächsten Runde), rot (sofortiger Alert an Schwesternruf oder Pflegekraft-Smartphone). Die Entscheidung, was mit dem Alert passiert, liegt beim Pflegepersonal — das System gibt eine Einschätzung, keine Anweisung.

Die KI-gestützte Risikoeinschätzung ist ein klinisches Unterstützungswerkzeug. Sturzprävention, Sturzdokumentation und alle abgeleiteten klinischen Entscheidungen unterliegen der pflegerischen und ärztlichen Verantwortung. Das System ersetzt keine Pflegekraft und keine ärztliche Beurteilung — es ergänzt beides.

MDR-Pflicht: Was das für die Beschaffung bedeutet

Sobald ein KI-System Teil der Patientenüberwachungskette ist — also Sensordaten aufnimmt, verarbeitet und Empfehlungen für klinische Handlungen gibt — fällt es in den Anwendungsbereich der EU-Medizinprodukteverordnung (MDR 2017/745). Das ist keine Randnotiz, sondern ein zentrales Beschaffungshindernis.

Was das in der Praxis bedeutet:

Ein Radarsensor, der lediglich einen Alarm auslöst (“Patient steht auf”), kann unter Umständen als Klasse-I-Medizinprodukt eingestuft werden — mit einer vergleichsweise überschaubaren Zertifizierungslast. Sobald aber eine KI-Softwarekomponente Risikoempfehlungen gibt, die in klinische Entscheidungen einfließen (z. B. “erhöhe die Beobachtungsfrequenz für diesen Patienten”), ist die Klassifizierung als Klasse IIa oder höher wahrscheinlich — und dann ist eine unabhängige Benannte Stelle (Notified Body) für die Zertifizierung erforderlich.

Was du vor der Beschaffung klären musst:

1. Welche MDR-Klasse weist der Hersteller für seine Lösung aus? Liegt das CE-Zertifikat vor?
2. Wer ist in eurer Klinik MDR-Beauftragter — hat diese Person die Lösung bewertet?
3. Wie ist die Post-Market-Surveillance geregelt? MDR verlangt laufendes Monitoring durch den Hersteller.
4. Welcher Teil der Lösung gilt als Medizinprodukt — nur die Hardware, nur die Software, oder beides zusammen?
5. Wenn ihr das ML-Modell intern entwickelt oder anpasst: Gilt dann euer Haus als Hersteller?

Der letzte Punkt ist entscheidend: Wer ein eigenes KI-Modell auf Basis von Patientendaten trainiert und es in der klinischen Praxis zur Risikoeinschätzung einsetzt, kann unter MDR selbst zum Hersteller werden — mit allen Dokumentations-, Vigilanz- und Meldepflichten. Das ist kein theoretisches Risiko, sondern eine rechtliche Realität, die viele Krankenhäuser unterschätzen.

Diese Darstellung gibt einen Orientierungsrahmen. Die konkrete MDR-Klassifizierung, Konformitätsbewertung und regulatorische Strategie müssen mit dem MDR-Beauftragten der Klinik, einem zugelassenen Beratungsunternehmen für Medizinprodukte und ggf. einer Benannten Stelle abgestimmt werden. Fehleinschätzungen in der Klassifizierung können teuer werden.

Konkrete Werkzeuge — was wann passt

Die Werkzeugwahl hängt davon ab, wie viel Infrastruktur die Klinik bereits hat und wie tief die technische Integration gehen soll.

Qumea — kontaktlose Radarsensorik, erste Wahl für geriatrische Stationen Das Schweizer Unternehmen hat im März 2024 als erstes System am Caritas-Krankenhaus St. Josef Regensburg in Deutschland produktiv Betrieb aufgenommen. Der deckenmontierte 3D-Radarsensor erfasst Bewegungssequenzen kontaktlos und ohne Kamera. Kein Wearable, kein Körperkontakt, keine Bilddaten — das schafft Akzeptanz sowohl bei Patienten als auch beim Pflegepersonal. Alert-Integration in bestehende Schwesternrufsysteme (z. B. Ascom) möglich. Preise auf Anfrage; MDR-Beauftragter vor Beschaffung einbinden.

EarlySense — Unter-Matratzen-Sensor für Vitalzeichen + Bewegungsmonitoring EarlySense (jetzt Teil von Baxter International) kombiniert in einem kontaktlosen Sensor-System unter der Matratze: Herzfrequenz, Atemfrequenz und Bewegungsqualität, rund um die Uhr. Veröffentlichte Studien aus Pflegeeinrichtungen zeigen Sturzreduktionen von 38–47 %. Der Sensor braucht kein Wearable und keine Kamera. Einschränkung: kein deutsches Support-Angebot direkt, Implementierung über Partnernetzwerk. Global gehostet — DSGVO-Implikationen vorab klären.

Azure Machine Learning — für custom ML-Risikomodelle auf Klinik-Patientendaten Für Kliniken, die ein eigenes Risikomodell trainieren wollen — auf Basis ihrer eigenen historischen EHR-Daten, angepasst an ihre Patientenpopulation. Azure ML ist in der EU-Region (Deutschland) verfügbar und damit DSGVO-konform nutzbar. Achtung: Bei Training und Betrieb eines klinischen Entscheidungsunterstützungssystems auf eigenem Rechner-/Azure-Infrastruktur greift ggf. die MDR-Herstellereigenschaft (s. Abschnitt MDR-Pflicht). Developer-Level, erfordert klinischen Informatik-Support.

scikit-learn — Open-Source-ML für Forschungs- und Pilotprojekte Wenn eine Forschungsabteilung oder ein klinisches Informatik-Team ein Risikomodell in Python prototypen will, ist scikit-learn der Standard. Random Forest, XGBoost (über XGBoost-Bibliothek), logistische Regression — alles vorhanden, kostenlos, gut dokumentiert. Für Piloten geeignet; für den produktiven klinischen Einsatz braucht man jedoch eine validierte Deployment-Umgebung und MDR-Konformitätsbewertung.

Zusammenfassung: Wann welcher Ansatz

• Geriatrische Station, kein eigenentwickeltes Modell nötig → Qumea oder EarlySense
• Unter-Matratzen-Lösung ohne Wearable → EarlySense
• Eigenes Risikomodell auf Klinik-Daten → Azure ML + scikit-learn (mit MDR-Prüfung für Eigenentwicklung)
• Hoch reguliertes Umfeld, Haftungsklarheit wichtig → Kommerzielle Lösung mit CE-Zertifikat bevorzugen

Die Auswahl eines Medizinprodukts für die Patientenüberwachung muss in Abstimmung mit dem MDR-Beauftragten, dem klinischen Risikomanagement und der IT-Sicherheitsabteilung der Einrichtung erfolgen.

Datenschutz und Datenhaltung

Patientenbewegungen und -positionen in Echtzeit sind Gesundheitsdaten im Sinne von Art. 4 Nr. 15 und Art. 9 DSGVO — und damit der sensibelsten Datenkategorie zugeordnet. Das gilt auch dann, wenn kein Name im Datenstrom steht: Bewegungsmuster + Zimmernummer + Aufnahmezeitraum ermöglichen die Identifikation. Jede Verarbeitung dieser Daten erfordert eine rechtliche Grundlage (in der Regel: Einwilligung oder Behandlungsvertrag), ein Verarbeitungsverzeichnis und — wenn externe Dienstleister eingebunden sind — einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO.

Was das für die einzelnen Systemebenen bedeutet:

Sensorhardware: Radarsensoren (wie Qumea) und Unter-Matratzen-Sensoren (wie EarlySense) können so konfiguriert werden, dass keine Rohdaten außerhalb des Gebäudes übertragen werden — “geschlossene, verschlüsselte Systeme” (Qumea-Eigenbezeichnung). Das reduziert das Datenschutzrisiko erheblich: Die Verarbeitungen bleiben im Netzwerk der Klinik. Trotzdem: Systemkonfiguration mit Datenschutzbeauftragtem prüfen, Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO erstellen.

ML-Modell und Datenintegration: Wenn EHR-Daten (Medikamentenlisten, Laborwerte, Mobilisierungsdokumentation) mit Sensordaten zusammengeführt werden, entsteht ein hochsensibler Datenstrom. Die Verarbeitung sollte ausschließlich im Kliniknetzwerk oder in einem deutschen/EU-Rechenzentrum mit DSGVO-AVV stattfinden. Azure ML in der EU-Region (Germany West Central) erfüllt diese Anforderung — US-gehostete ML-Dienste tun es nicht, ohne explizite Standardvertragsklauseln und DSFA.

Cloud-Dienste für KI-Training: Wenn Patientendaten für das Modell-Training genutzt werden, auch in anonymisierter Form, gilt: Sorgfältige Pseudonymisierung vorab, Daten nie mit Re-Identifizierungsrisiko in externe Systeme übertragen.

Für jede externe Systemkomponente, die Patientendaten verarbeitet:

1. Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO — verpflichtend bei Hochrisikoverarbeitung
2. Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO mit jedem Anbieter
3. Eintrag ins Verarbeitungsverzeichnis nach Art. 30 DSGVO
4. Information der Patienten über die Datenverarbeitung (Transparenzpflicht)

Diese Auflistung ersetzt keine Rechtsberatung. DSGVO-Compliance für klinische KI-Systeme ist komplex und muss mit dem klinikeigenen Datenschutzbeauftragten und ggf. einem auf Gesundheitsrecht spezialisierten Anwalt abgestimmt werden.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Die Hardwarekosten hängen stark von der Sensorwahl ab:

• Radarsensor (Qumea-Typ): ca. 3.000–6.000 Euro pro Zimmer, abhängig von Zimmerausstattung und Integrationstiefe (Schwesternruf, Pflegedokumentation) — keine offiziellen Listenpreise
• Unter-Matratzen-Sensor (EarlySense-Typ): ca. 3.500–4.500 Euro je Einheit (UK-Referenzpreise; DE-Preise auf Anfrage)
• Für eine Station mit 24 Hochrisiko-Betten: Schätzungsweise 80.000–120.000 Euro Hardware plus Installation
• KIS-Integrationskosten (HL7-FHIR-Schnittstelle zum Krankenhausinformationssystem): 20.000–80.000 Euro, stark abhängig vom KIS-Anbieter und Integrationstiefe
• MDR-Compliance-Beratung (sofern Eigenentwicklung): 15.000–40.000 Euro einmalig

Laufende Kosten

• Software-Lizenzgebühren: typischerweise 20–40 % der Hardware-Erstkosten p. a. (Herstellerangaben variieren stark)
• Modellpflege und Rekalibrierung: 0,5–1 FTE IT/klinische Informatik intern oder externes Service-Paket
• Medizinprodukt-Post-Market-Surveillance: laufender Aufwand, den der Hersteller trägt (nicht die Klinik, sofern Eigenentwicklung ausgeschlossen)

Was du dagegen rechnen kannst

Eine geriatrische Station mit durchschnittlich einem Sturz pro Woche:

• 52 Sturzereignisse/Jahr × 6,19 Mehrtage × ca. 500 Euro/Tag (Kostentragersperspektive) = ~160.000 Euro potenzielle Mehrkostenbelastung pro Jahr
• Bei 50 % Reduktion durch das System: ~80.000 Euro vermiedene Kosten jährlich
• Amortisation der Hardware bei dieser Annahme: ca. 2 Jahre

Das ist ein konservatives Szenario. Haftungsrisiken, MDK-Prüfungen, Pflegeaufwand bei Sturzkomplikationen und Reputationseffekte sind dabei noch nicht eingerechnet.

Kostenschätzungen basieren auf veröffentlichten Studiendaten (Sawetzki et al. 2014, Thieme) und Herstellerangaben. Tatsächliche Kosten und Einsparungen hängen von Patientenvolumen, Komplikationsrate, DRG-Fallgruppen und Verhandlungsergebnissen mit Kostenträgern ab. Vor der Investitionsentscheidung: Vollkostenrechnung mit Controlling, Abrechnung und Pflegedienstleitung erstellen.

Typische Einstiegsfehler

1. Alert-Kalibrierung unterschätzen — und Alarm-Fatigue riskieren. Das ist der häufigste und gefährlichste Fehler. In den ersten Wochen nach Installation interpretiert das System alltägliche Bewegungen als Risiko — ein Patient, der sich im Bett umdreht, eine Krankenschwester, die das Bett neu bezieht, ein Besuchender am Bett. Das Ergebnis: ein Alarm-Regen, den das Pflegeteam nach zwei Wochen systematisch ignoriert. Studien zu klinischen Alarmsystemen zeigen, dass 72–99 % der Alarme in Intensivstationen False Positives sind — ein Verhältnis, das auch Bettsensoren betrifft, bevor das Modell kalibriert ist.

Lösung: Eine Einlernphase von vier bis acht Wochen einplanen, in der Pflegekräfte aktiv Feedback geben (“dieser Alarm war unnötig” / “dieser war berechtigt”). Das Modell muss auf die spezifische Patientenpopulation und die Zimmercharakteristik der Station trainiert werden — keine Off-the-Shelf-Kalibrierung reicht aus.

2. Die Morse-Fall-Skala als “ausreichend” betrachten — und das KI-System parallel nicht aktualisieren. Ein KI-System ersetzt die Morse-Fall-Skala nicht — es ergänzt sie. Das Problem: Wenn das Pflegeteam den Morse-Score nicht pflegt (und das tun sie in der Praxis oft nicht nach der Aufnahme), fehlt dem ML-Modell ein wichtiges Eingangssignal. Dann berechnet das Modell auf Basis von unvollständigen Daten — und gibt eine falsche Sicherheit. Das System muss in den Pflegeprozess eingebettet sein, nicht danebenstehen.

3. MDR-Compliance als “werden wir schon irgendwie regeln” behandeln. Die MDR-Konformität ist keine nachträgliche Formalität — sie ist eine Voraussetzung für den legalen Betrieb eines medizinischen Monitoring-Systems. Mehrere Kliniken haben KI-Projekte stoppen müssen, weil im Projektverlauf unklar wurde, ob sie als Hersteller eines Medizinprodukts gelten. Die Folge: Nachholende MDR-Dokumentation, teures Consulting, Projektverzögerung von 6–12 Monaten.

Lösung: MDR-Beauftragten von Tag eins ins Projektteam einbinden. Hersteller-MDR-Status klären, bevor ein Vertrag unterschrieben wird.

4. Das System auf der Nachtstrecke einführen — und alle Schichten vergessen. Sturzereignisse passieren auch tagsüber — und die Frühschicht, die das System noch nicht kennt, reagiert anders auf Alerts als die Nachtschicht, die es drei Monate begleitet hat. Wenn nur eine Schicht trainiert ist, entstehen gefährliche Lücken in der Reaktionskette.

5. Nach Implementierung kein Modell-Retraining einplanen. Das initiale Modell wurde auf historischen Daten trainiert — vor dem System-Rollout. Nach Einführung verändert sich das Patientenverhalten, weil Pflegekräfte früher eingreifen. Das Modell sieht dadurch weniger “echte” Stürze und braucht regelmäßiges Retraining, um seine Vorhersagegüte zu erhalten. Dieser Punkt fehlt in fast jedem Projektplan.

Einstiegsfehler im Betrieb klinischer KI-Systeme können sich direkt auf die Patientensicherheit auswirken. Pilotphase, Kalibrierung und Schulung sind keine optionalen Phasen — sie sind klinisch notwendig.

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

Die Hardware zu installieren ist der einfache Teil. Das Schwierige ist, dass das Pflegepersonal auf einer ohnehin stark belasteten Station mit einem weiteren Alarm-System konfrontiert wird, das es noch nicht kennt und dem es noch nicht traut.

Drei Widerstands-Muster, die regelmäßig auftreten:

“Noch ein Alarm, den ich sowieso ignoriere.” Pflegekräfte auf geriatrischen Stationen arbeiten in Umgebungen mit mehreren parallelen Alarmsystemen — Infusionsgeräte, Herzmonitore, Bettalarme, Schwesternruf. Ein neues System wird zuerst als additiver Lärm wahrgenommen, nicht als Qualitätsgewinn. Die erste Reaktion ist skeptisch, manchmal ablehnend. Das ist rational, kein Widerstand gegen Innovation.

“Die Technik versteht nicht, was ich sehe.” Erfahrene Pflegekräfte haben ein intuitives Gespür für Patientenrisiken — ganzheitlich, aus Jahrzehnten Praxis. Ein Sensor-System, das einen Score ausgibt, kann sich anfühlen wie eine Entmündigung dieses Wissens. Wichtig: Das System explizit als Unterstützungswerkzeug einführen, nicht als Überprüfungswerkzeug für das Pflegepersonal. Pflegekräfte, die regelmäßig Alerts kalibrieren dürfen, identifizieren sich schnell mit dem System — sie bauen es mit.

“Wenn das System Recht hatte und ich nicht gehandelt habe — was dann?” Die Haftungsfrage ist real. Wenn ein Alert ausgelöst wurde und die Pflegekraft nicht sofort reagieren konnte (weil sie gleichzeitig bei einem anderen Patienten war), und der Patient trotzdem stürzt — ist das dann ihre Schuld? Diese Frage muss vor der Einführung mit der Rechtsabteilung und der Pflegedienstleitung geklärt werden. Das System dokumentiert den Alert mit Zeitstempel — was eine neue Dokumentationsrealität schafft, mit der das Team vertraut sein muss.

Was konkret hilft:

• Pflegekräfte von Anfang an in die Kalibrierungsphase einbinden — ihre Rückmeldung zu False Positives und Missed Alerts ist Goldwert
• Eine Schlüsselpflegekraft pro Station als “System-Champion” benennen, die erste Anlaufstelle ist und Frust aufnimmt
• Klare Kommunikation: Das System löst keine Personalspar-Maßnahmen aus — es soll Stürze verhindern, nicht Personalstunden zählen
• Haftungsfragen schriftlich klären, bevor das System live geht
• Erste Erfolgsdaten nach sechs Wochen teilen — nichts überzeugt eine skeptische Schicht schneller als eine Sturzreduktion, die sie selbst erlebt hat

Haftungsfragen rund um Alert-Routing, Reaktionszeiten und Dokumentationspflichten sind klinik- und vertragsspezifisch. Die hier skizzierten Lösungswege ersetzen keine Beratung durch Rechtsabteilung, Pflegedienstleitung und Datenschutzbeauftragte/n.

Realistischer Zeitplan mit Risikohinweisen

Zeitrahmen für geriatrische Station mittelgroßer Klinik mit bestehender HL7-FHIR-Grundlage. Kliniken ohne FHIR-fähiges KIS oder ohne MDR-Beauftragten sollten 6–12 Monate für Vorlaufzeit einkalkulieren.

Häufige Einwände — und was dahintersteckt

“Wir haben doch die Morse-Fall-Skala — das reicht.” Die Morse-Skala ist ein gutes Screening-Instrument bei Aufnahme. Ihr Problem: Sie ist statisch in einem dynamischen klinischen Kontext. Klinische Praxisberichte und internationale Pflegestudien zeigen konsistent, dass Sturzrisiken durch Medikamentenwechsel, postoperative Verwirrtheitszustände und Nachtphase-spezifische Faktoren entstehen, die kein punktuelles Assessment abbilden kann. Das Argument “wir haben die Morse-Skala” ist richtig und trotzdem unzureichend.

“Wir wollen keine Kameras auf den Zimmern.” Das ist ein berechtigter Einwand — und ein veraltetes Bild von Sensor-Systemen. Radar-basierte Systeme (wie Qumea) und Unter-Matratzen-Sensoren (wie EarlySense) arbeiten vollständig ohne Kamera und ohne Bilddaten. Das System “sieht” keine Patienten — es erkennt Bewegungsmuster in anonymisierten Radar-Reflexionen. Dieser Unterschied ist klinisch und datenschutzrechtlich relevant, wird aber in der öffentlichen Wahrnehmung oft vermischt.

“Das können wir uns als mittelgroße Klinik nicht leisten.” Das ist ein ehrlicher Einwand, der eine ehrliche Antwort verdient: Stimmt, für viele Häuser sind die Investitionskosten in der Größenordnung 100.000–200.000 Euro für eine Station nicht ohne weiteres zu rechtfertigen. Die Gegenrechnung: Eine Station mit wöchentlichen Stürzen und resultierenden DRG-Deckungslücken von 50.000–80.000 Euro pro Jahr hat eine Amortisationszeit von zwei bis vier Jahren. Das ist kein triviales Argument, aber es braucht eine vollständige Kostenrechnung — nicht nur die Hardwarepreise.

“Die Pflegekräfte werden das System nicht annehmen.” Das ist ein valides Risiko, das durch die Art der Einführung entschieden wird — nicht durch die Technologie selbst. Systeme, die von Pflegekräften als zusätzliche Kontrolle empfunden werden, haben schlechte Akzeptanz. Systeme, die von Pflegekräften als Entlastung und Sicherheitsnetz erlebt werden, werden angenommen. Der Unterschied liegt in der Kalibrierungsbeteiligung, der Kommunikation und in den ersten sichtbaren Ergebnissen.

Amortisationsrechnungen und DRG-bezogene Aussagen sind Orientierungswerte. Vor der Investitionsentscheidung mit Controlling, Abrechnung und Pflegedienstleitung eine Vollkostenrechnung auf Basis eurer eigenen Sturzraten und DRG-Fallgruppen erstellen.

Woran du merkst, dass das zu dir passt

Das passt, wenn:

• Eure geriatrische oder unfallchirurgische Station hat eine dokumentierte Sturzrate von mehr als einem Sturz pro Monat auf 20–30 Betten
• Ihr betreibt bereits ein HL7-FHIR-fähiges Krankenhausinformationssystem (oder seid dabei, eines einzuführen)
• Es gibt einen MDR-Beauftragten im Haus oder die Möglichkeit, einen einzubeziehen
• Pflegedienstleitung und Klinikleitung stehen gemeinsam hinter dem Projekt — kein Top-Down-Diktat ohne Pflegebeteiligung
• Die aktuelle Dokumentationslage erlaubt, eine Baseline-Sturzrate zu messen (ohne Baseline kein ROI-Nachweis)
• Ihr betreibt einen Krankenhausverbund und plant die Ausweitung nach erfolgreichem Pilot

Das passt (noch) nicht, wenn:

1. Klinik mit weniger als 50–80 Betten auf der Zielsation, kein MDR-Beauftragter vorhanden. Der Compliance-Aufwand übersteigt den realistischen Nutzen. Mit einem Sturz alle vier bis sechs Wochen rechnet sich die Investition für eine kleine Station kaum — und ohne MDR-Beauftragten ist das Projekt ein regulatorisches Minenfeld.

2. Die Morse-Fall-Skala wird auf eurer Station nicht konsistent gepflegt. Wenn das Baseline-Assessment nicht funktioniert, kann das KI-System keine validen Daten nutzen. Digitalisierung auf Chaos aufsetzen gibt digitalen Chaos zurück. Zuerst den Prozess stabilisieren, dann automatisieren.

3. Kein HL7-FHIR-fähiges KIS und kein klinischer IT-Spezialist im Haus. Ohne Schnittstellenintegration ist das System eine Insellösung ohne EHR-Kontext — also nur ein Bewegungs-Alarm, kein Risikoscore. Das ist nicht wertlos, aber weit hinter den Möglichkeiten und rechtfertigt selten den MDR-Aufwand.

Wenn ihr einen dieser Punkte erkennt: Das bedeutet nicht, dass das Thema nicht relevant ist — es bedeutet, dass ihr zuerst andere Grundlagen legen müsst. Ein Gespräch mit einer Pflegeberatungsagentur oder einem klinischen IT-Berater kann klären, in welcher Reihenfolge das sinnvoll ist.

Das kannst du heute noch tun

Bevor Sensoren installiert werden, bevor ein Hersteller beauftragt wird, ist der wichtigste erste Schritt: die eigene Baseline kennen.

Wie viele Stürze passieren auf eurer Station — pro Monat, pro Schicht, zu welcher Tageszeit? Was steht im Pflegebericht danach? Welche Medikamentenwechsel gab es in den 24 Stunden vorher? Dieses Audit, konsequent für die letzten sechs Monate ausgeführt, ergibt mehr Erkenntnisse über euer tatsächliches Risikoprofil als jedes Herstellergespräch.

Dafür brauchst du heute noch nichts kaufen. Du brauchst eine strukturierte Analysevorlage — und einen anonymisierten Datensatz aus eurem Pflegedokumentationssystem.

Wichtiger Hinweis vor der Nutzung dieser Vorlage:

Für eine klinische Analyse müssen Patientendaten vollständig anonymisiert oder pseudonymisiert werden, bevor sie in ein externes KI-System eingegeben werden. Name, Geburtsdatum, Zimmernummer, Aufnahmedatum — alles muss entfernt oder verändert sein, sodass keine Re-Identifikation möglich ist. Verwende für diese Analyse ausschließlich anonymisierte Fallbeschreibungen ohne identifizierende Merkmale. Kläre mit dem Datenschutzbeauftragten, ob und welche Daten für eine externe Analyse freigegeben werden dürfen.

Diese Vorlage ist ein analytisches Unterstützungswerkzeug. Sie ersetzt keine klinische Risikoeinschätzung, keine ärztliche Beurteilung und keine Sturzdokumentation nach internen Pflegestandards. Alle Schlussfolgerungen sind mit der Pflegedienstleitung und dem klinischen Qualitätsmanagement abzustimmen.

Quellen & Methodik

• Sturzrate in geriatrischer Klinik (9,1 / 1.000 Krankenhaustage): Runge M, Rehfeld G, Schacht E: „Sturzereignisse stationärer geriatrischer Patienten”, Zeitschrift für Gerontologie und Geriatrie, Springer, 2004. Wert für Patienten, die tatsächlich stürzten: 41,0 pro 1.000 Tage. Altersdifferenz: 85+-Gruppe 5,61 vs. 46–55-Gruppe 1,29 pro 1.000 Patiententage.
• Schwere Verletzungsrate 8,8 %: Aktionsbündnis Patientensicherheit e. V. (APS), „Vermeidung von Stürzen älterer Patienten im Krankenhaus”, Fakten und Erläuterungen, 2024, aps-ev.de.
• Direkte Sturzkosten (€103/Ereignis, 6,19 Mehrtage): Sawetzki S, Pokorny A, Klewer J: „Ökonomische Beurteilung von Sturzereignissen in einem Krankenhaus der kardiologischen und herzchirurgischen Maximalversorgung”, Gesundheitsökonomie & Qualitätsmanagement, Thieme, 2014. Direkte Kosten pro Sturzereignis: ca. 103 Euro (Personalkosten 55 %, Diagnosekosten ~40 %). Verlängerung bei verletzungsfreiem Sturz: 6,19 Tage; mit Verletzung: 7,55 Tage.
• Qumea in Regensburg: Bistum Regensburg, Pressemitteilung, März 2024: „Caritas-Krankenhaus St. Josef etabliert digitales Sturz-Frühwarnsystem.” Erste Klinik in Deutschland mit Qumea-Radarsensor im Produktivbetrieb. Ergebnis Testphase: kein Sturz während der Testphase.
• Alert Fatigue (72–99 % False Positives): PMC-Scoping Review, „Alarm fatigue in healthcare: a scoping review of definitions, influencing factors, and mitigation strategies” (2025). Querbestätigt durch: Assessment of alarm fatigue among intensive care unit nurses: a cross-sectional study, PMC 2024, erhoben an deutschem Universitätsklinikum (Jan–März 2024).
• EarlySense-Sturzreduktion (38–47 %): EarlySense-Herstellerangaben, bestätigt durch Studien aus Hebrew Home at Riverdale und Dorot Medical Center. Gerätebeschreibung aus verifizierter Tool-Seite (April 2026).
• Pilotstudie Nobi Smart Lamps (84 % Reduktion): CareTRIALOG, Dezember 2023. Pilottest Hartland House (Pflegeheim UK, Frühjahr 2023). Einschränkung: UK-Pflegeheim, nicht direkt auf deutsche Krankenhaus-Geriatrie übertragbar.
• MDR 2017/745: Verordnung (EU) 2017/745 des Europäischen Parlaments und des Rates über Medizinprodukte, in der aktuell gültigen Fassung. Klassifizierungsregeln: Anhang VIII.
• DSGVO Art. 9 (Gesundheitsdaten): Datenschutz-Grundverordnung in der aktuell gültigen Fassung. Art. 28 (AVV), Art. 30 (Verarbeitungsverzeichnis), Art. 35 (DSFA).

Du überlegst, ob ein Sturzprävention-Pilotprojekt für eure Station sinnvoll ist und willst die wirtschaftliche und klinische Machbarkeit einschätzen? Sprich uns an — gemeinsam schauen wir, welche nächsten Schritte für euren konkreten Kontext sinnvoll sind.