Sturzerkennung & Ambient Assisted Living

Stürze sind eine der häufigsten Ursachen für Verletzungen und den Verlust der Selbstständigkeit älterer Menschen, und langes Liegen am Boden nach einem Sturz verschlechtert die Folgen. Klassische Notrufknöpfe versagen, wenn die Person bewusstlos ist oder das Gerät nicht trägt. KI-gestützte Sturzerkennung und Ambient Assisted Living (AAL) kombinieren Wearables, datenschutzfreundliche Radarsensorik und Haussensoren, um Stürze automatisch zu erkennen, schleichende Veränderungen im Tagesablauf zu bemerken und Pflegekräfte zu alarmieren, damit Menschen mit weniger aufdringlicher Überwachung zu Hause oder im Pflegeheim bleiben können.

Problem & Nutzen

• Heute: Notrufanhänger erfordern einen Tastendruck; viele Menschen vergessen ihn oder können ihn nicht tragen. Pflegeheime verlassen sich auf nächtliche Rundgänge und Rufanlagen. Kameras stoßen auf starke Datenschutzbedenken.
• KI-Nutzen: automatische Erkennung von Stürzen und längerem Liegen am Boden, weniger unnötige nächtliche Rundgänge, Frühwarnung bei Abbau (veränderter Gang, nächtliches Wasserlassen, geringere Aktivität) und Entlastung knapper Pflegekräfte.
• Belege: Ein systematischer Review von 2025 zur AAL-Sturzerkennung kam zu dem Ergebnis, dass nicht am Körper getragene und hybride Lösungen (Wearable plus Umgebungssensorik) die höchste Erkennungsleistung erreichten und dass Deep Learning die besten Ergebnisse lieferte [1]. Aktuelle Radarforschung betont, dass die meisten Detektoren mit gestellten Stürzen junger Freiwilliger trainiert werden, die echte Stürze gebrechlicher älterer Menschen möglicherweise nicht abbilden; die Leistung im Realbetrieb muss daher lokal validiert werden [2][3].
• Einschränkung: Der Nutzen hängt vom Reaktionsprozess ab. Ein Alarm, den innerhalb von Minuten niemand beantwortet, bringt nichts, und Fehlalarme führen zu Alarmmüdigkeit.

Varianten

• Häusliche Pflege / Telecare: Wearable oder Radareinheit, verbunden mit einer Notrufzentrale (Art Hausnotruf).
• Pflegeheime und Krankenhäuser: Radar auf Raumebene oder Bettsensoren, integriert in Schwesternrufanlagen und Pflegedokumentation (siehe HLTH-025).
• Bad und nächtliche Überwachung: der Ort mit dem höchsten Risiko, an dem Kameras ungeeignet sind; multimodale stromsparende Sensorik wird erforscht [4].
• Routineanalyse ("Aktivitäten des täglichen Lebens"): Passive Smart-Home-Sensoren bilden eine Basislinie und markieren Abweichungen (Verbindung zu HLTH-007).

So funktioniert es

sensing (wearable IMU | mmWave radar | depth/thermal | smart-home sensors | audio events)
  -> edge preprocessing (filtering, point-cloud/range-Doppler, on-device inference)
  -> event model (fall, post-fall lying, bed exit, wandering) + routine model (baseline, anomaly)
  -> fusion and confidence scoring (multi-sensor, context: room, time, resident profile)
  -> alert logic (verification call, two-way voice, escalation ladder)
  -> carer / call centre / emergency response
  -> feedback (confirm or dismiss) -> logging, retraining, quality reporting

• Wearables: Beschleunigungssensor und Gyroskop mit Schwellenwertlogik oder kleinen neuronalen Netzen; Smartwatches ergänzen Herzfrequenz und Aufprallerkennung.
• Radar: mmWave-Sensoren verfolgen Körperhöhe und Bewegung und können eine still am Boden liegende Person erkennen; sie arbeiten im Dunkeln ohne Bilder, was das wichtigste Datenschutzargument ist [2][3].
• Bildsensorik: Posenschätzung auf Tiefen- oder Thermalbildern, verarbeitet auf dem Gerät, sodass keine Bilder den Raum verlassen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Jeder Alarm wird überprüft (Anruf, Sprechverbindung oder Besuch), und die Eskalationsregeln legt der Pflegeanbieter fest; keine automatische Alarmierung des Rettungsdienstes ohne menschliche Prüfung, es sei denn, die Bewohnerin bzw. der Bewohner hat eingewilligt.

Datenaufbereitung

Dieser Anwendungsfall läuft überwiegend auf Sensordatenströmen (Wearable-IMU, mmWave-Radar, Tiefen- oder Thermalbilder, Tür- und Bewegungssensoren) und weniger auf Geschäftsdokumenten. Die relevanten Daten liegen in der Plattform des Sensoranbieters, in der Schwesternrufanlage und in der Pflegedokumentationssoftware; Vorfallberichte sind oft Papier oder Freitext.

Typische Lücken: keine beschrifteten Stürze (echte Stürze sind selten), Alarmprotokolle ohne Ergebnis, Sensoren ohne Raum- oder Bewohnerprofil, uneinheitliche Uhrzeiten, unklare Einwilligung und Zugriffsrechte von Bewohnern und Angehörigen sowie verstreute Eskalationsregeln.

Schritte der Aufbereitung: - Sensorplatzierung, Bewohnerprofil und Eskalationsstufen je Raum in einer Tabelle dokumentieren (PREP-011). - Alarmprotokolle mit dem Ergebnis (echter Sturz, Fehlalarm, Test) verknüpfen, indem Pflegekräfte jeden Alarm bestätigen oder verwerfen (PREP-021, PREP-020). - Einen kleinen Evaluationsdatensatz aus gestellten Stürzen und Alltagsaktivitäten unter Aufsicht erheben (PREP-018). - Rohe Sensordaten lokal halten; nur Ereignisse und pseudonymisierte Basislinien speichern (PREP-022).

Bei einem gekauften System besteht die Aufbereitung vor allem aus Raumerfassung, Einwilligungsmanagement und Prozessdefinition, grob einem Fünftel des Aufwands; bei eigener Modellentwicklung verlagert sich der größte Teil des Aufwands auf Datenerhebung und Labeling.

Umsetzungswege

Welcher Weg für wen

• smb (kleine Pflegeanbieter, Betreiber von betreutem Wohnen): Weg A, denn es gibt ausgereifte Sensorsysteme mit Notrufanbindung und zertifizierten Prozessen; eigene Modelle brächten Haftung ohne Nutzen.
• enterprise (große Pflegebetreiber, Wohnungsunternehmen): Weg A, denn Standardsysteme passen und der Ablauf der Sturzalarmierung ist standardisiert; verhandeln Sie zentrale Plattformen und On-Premises- oder EU-Hosting.
• developer: Weg C, denn offene Radar- und IMU-Datensätze und edgefähige offene Modelle erlauben es, die Erkennung auf dem Gerät zu bauen und zu testen, ohne Daten außer Haus zu senden.
• public (kommunale Pflege, sozialer Wohnungsbau): Weg A mit zertifizierten Produkten und Hosting in der EU oder bei der Kommune; Open Source nur dort, wo die Behörde den Betrieb leisten und die Verantwortung übernehmen kann.
• private (Familien): Weg A, denn fertige Wearables und Radarsensoren mit Notrufdienst sind einfach zu installieren und erfordern keine technischen Kenntnisse.

Weg A — Kaufen (Standardsoftware) (empfohlen)

• Telecare- und AAL-Plattformen: Tunstall, Doro, Vayyar (radarbasierte Raumsensoren, Israel), Kepler Vision Technologies (Niederlande, EU; kamerabasierte Sturzerkennung für Pflegeheime), Sensara, Safelyyou (USA) sowie Verbraucheroptionen wie die Sturzerkennung von Apple Watch und Samsung Galaxy Watch. Prüfen Sie aktuelle Produktlinien und die Verfügbarkeit in der EU beim Anbieter.
• Prüfen: CE-Kennzeichnung und MDR-Status, falls medizinische Aussagen gemacht werden, Verarbeitung auf dem Gerät, Hosting in der EU, Unterstützung bei der DSFA, Integration in Schwesternruf- und Pflegesoftware, gemessene Fehlalarmrate in vergleichbaren Umgebungen.
• Wählen Sie A, wenn: Sie ein Pflegeanbieter oder Wohnungsunternehmen ohne ML-Personal sind; der Ablauf (Reaktion) wichtiger ist als der Algorithmus.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Nutzen Sie Geräte-SDKs und IoT-Backends (Azure IoT, AWS IoT Core in EU-Regionen oder EU-Anbieter) für die Datenerfassung, mit Regel-Engines, Cloud-Zeitreihenspeicher und Workflow-Automatisierung (n8n, Node-RED) für die Eskalation.
• LLM-APIs (in der EU gehostet) nur für verständliche Tageszusammenfassungen, nie für die Erkennungsentscheidung.
• Wählen Sie B, wenn: Sie Sensoren mehrerer Anbieter in einem Dashboard zusammenführen.

Weg C — Selbst betreiben (Open Source)

• Edge: Raspberry Pi 5 oder Jetson Orin Nano mit Radarmodulen (zum Beispiel mmWave-Sensoren von Texas Instruments oder Infineon), Modelle exportiert nach ONNX oder TensorFlow Lite; MediaPipe/MoveNet oder YOLO-pose für die Pose auf Tiefen-/Thermalbildern.
• Plattform: Home Assistant, MQTT, Node-RED, InfluxDB/TimescaleDB, Grafana.
• Datensätze: Öffentliche Sturzdatensätze existieren (zum Beispiel Radar- und Wearable-Datensätze in den zitierten Reviews), sind aber überwiegend gestellt; betrachten Sie die Ergebnisse als Obergrenzen [1][2].
• Hardware: HW1 (Edge-Gerät je Raum), ein kleiner CPU-Server für die Plattform. Der Betriebsaufwand ist hoch wegen der Verwaltung der Geräteflotte und der Sicherheitspflichten.

Weg D — Eigenes Training

Lohnt sich für Hersteller, die ein Produkt bauen, oder für Forschungsprojekte. Erfordert beschriftete Sensordaten aus echten Wohnungen oder Pflegeeinrichtungen, idealerweise mit schwierigen Negativbeispielen (abruptes Hinsetzen, herabfallende Gegenstände, Haustiere, Bettwechsel). Echte Stürze zu erfassen ist selten und ethisch heikel, daher sind synthetische Daten, Digital-Twin-Simulation von Radarechos [3] und Few-Shot-Anpassung je Raum aktive Forschungsfelder. Ein Produkt mit medizinischer Zweckbestimmung braucht ein Qualitätsmanagementsystem und eine klinische Bewertung.

Stand der Technik (2026)

• Radar ist die führende datenschutzfreundliche Umgebungsmodalität; die Forschung konzentriert sich nun auf umgebungsunabhängige Modelle, die Erkennung der Bodenbelegung nach einem Sturz und Digital-Twin-Trainingsdaten [2][3][5].
• Multimodale Fusion (Radar plus Audio oder Wearable) senkt die Fehlalarme im Vergleich zu einzelnen Sensoren [1][4].
• Inferenz am Edge auf Mikrocontrollern und kleinen NPUs hält die Rohdaten in der Wohnung.
• Grenzen: Domänenverschiebung zwischen gestellten und echten Stürzen, unterschiedliche Raumaufteilungen, mehrere Personen, Haustiere und langsame "gleitende" Stürze; Fehlalarme durch Sitzen an der Bettkante; verpasste Stürze untergraben das Vertrauen. Die in Veröffentlichungen berichteten Genauigkeiten sind selten mit der Leistung im Feld vergleichbar.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: HLTH-007 (Fernüberwachung von Patienten und Wearable-Analytik) teilt die Zeitreihen- und Geräte-Pipeline; VIS-024 teilt die Posenschätzung; ROBO-011 teilt TinyML und Edge-Deployment.
• Kombinationen: HLTH-012 (Frühwarnung bei Verschlechterung) in Pflegeheimen, CONV-016 (Begleit- und Sprachassistenten für ältere Menschen) für Sprach-Check-ins in beide Richtungen, HLTH-025 (Pflegedokumentation) zur Protokollierung von Vorfällen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für die Einführung; Kosten je Raum oder je Nutzer und Monat plus Installation. Schulung des Personals und Festlegung der Reaktionskette sind der Hauptaufwand.
• Weg B: 3-6 Monate für die Integration von Sensoren, Dashboard und Eskalation.
• Weg C: 6-12 Monate mit Embedded- und ML-Kompetenz; dazu langfristige Gerätewartung.
• Weg D: 12+ Monate, klinische Studie und QMS.
• Kennzahlen: Sensitivität bei verifizierten Stürzen, Fehlalarme je Bewohner und Woche, Reaktionszeit, Zeit am Boden, Krankenhauseinweisungen nach Stürzen, Rückgang nächtlicher Rundgänge, Zufriedenheit der Pflegekräfte, Akzeptanz bei den Bewohnern.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsleitung und der Leitung des Pflegedienstes (Fürsorgepflicht, Haftung, Budget), dann den Pflegekräften, die auf Alarme reagieren, der IT (Netzwerk, Sensorinstallation), der bzw. dem Datenschutzbeauftragten sowie den Bewohnerinnen und Bewohnern oder ihren gesetzlichen Vertretern und Angehörigen, deren Einwilligung und Verständnis über die Akzeptanz entscheiden. Eine DSFA ist wahrscheinlich, weil die kontinuierliche Überwachung schutzbedürftiger Personen in ihrem Wohnraum systematisch ist; Rückschlüsse auf die Gesundheit berühren besondere Kategorien personenbezogener Daten, und mit dem Plattformanbieter ist ein AVV erforderlich.

Betriebsrat: abhängig vom Einzelfall. Die Sensoren beobachten Bewohner, aber Reaktionszeiten, Standort und Alarmquittierungen des Personals werden protokolliert; das BAG sieht die objektive Eignung zur Überwachung nach § 87 Abs. 1 Nr. 6 BetrVG als ausreichend an, binden Sie daher den Betriebsrat ein, falls es einen gibt. § 90 Abs. 1 Nr. 3 verlangt die frühzeitige Information über neue KI-gestützte Arbeitsabläufe. Kommunale Betreiber beziehen den Personalrat ein.

Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) der Pflegekräfte: was das System erkennt, typische Fehlalarme, was bei einem Ausfall zu tun ist (GUIDE-006). Führen Sie einen Piloten auf einer Station oder in einigen Wohnungen durch; sammeln Sie Rückmeldungen zur Alarmmüdigkeit (GUIDE-009). Typische Sorgen: Überwachung und Verlust der Privatsphäre für Bewohner, Mehrarbeit für das Personal. Bevorzugen Sie Radar gegenüber Kameras, ermöglichen Sie ein Opt-out, sagen Sie den Bewohnern klar, was aufgezeichnet wird, und behalten Sie bei jedem Alarm einen menschlichen Prüfschritt bei (GUIDE-008, GUIDE-005).

Risiken, Regulierung & Compliance

• KI-Verordnung (EU AI Act): hängt von der Zweckbestimmung ab. Ein Produkt mit medizinischer Zweckbestimmung (Sturzerkennung oder Überwachung zur Diagnose oder für klinische Entscheidungen) ist ein Medizinprodukt nach der MDR (typischerweise Klasse IIa oder höher nach Regel 11 für Überwachungssoftware, gemäß der Einstufung des Herstellers) und wird, falls eine Benannte Stelle erforderlich ist, zu einem Hochrisiko-KI-System nach Art. 6 Abs. 1 und Anhang I. Ein reiner Wellness- oder Sicherheitsalarm kann ein minimales Risiko darstellen. Die KI-Kompetenz (Art. 4) gilt. Art. 5: Emotionserkennung am Arbeitsplatz oder in Bildungseinrichtungen ist verboten, ebenso die biometrische Kategorisierung zum Rückschluss auf sensible Merkmale; halten Sie Sturzsysteme frei von solchen Funktionen und vermeiden Sie eine Leistungsüberwachung des Personals mit denselben Sensoren [6].
• DSGVO: Gesundheits- und Verhaltensdaten sind besondere Kategorien personenbezogener Daten (Art. 9); eine DSFA ist in der Regel erforderlich (Art. 35). Bewohner mit Demenz können einwilligungsunfähig sein, daher sind gesetzliche Vertreter einzubeziehen und Datenminimierung anzuwenden; bevorzugen Sie die Verarbeitung auf dem Gerät und Radar oder Thermalsensorik gegenüber Kameras [7].
• MDR: Aussagen wie "erkennt Stürze zur Verletzungsvermeidung" können das Produkt unter die Verordnung (EU) 2017/745 bringen [8].
• Sicherheit: Legen Sie ein ausfallsicheres Verhalten fest (Verbindungsverlust, schwacher Akku, Sensor offline) und testen Sie die Alarmzustellung regelmäßig.

Erste Schritte

1. Klären Sie zuerst den Reaktionsprozess: wer einen Alarm beantwortet, innerhalb welcher Zeit und was nachts geschieht.
2. Wählen Sie die Modalität nach Umgebung (Wearable für zu Hause, Radar für Schlafzimmer und Bad, keine Kameras, wo vermeidbar) und führen Sie mit den Vertretern der Bewohner eine DSFA durch.
3. Testen Sie zwei Anbieter in 5-10 Räumen über 3 Monate und erfassen Sie jeden Alarm als richtig, falsch oder verpasst.
4. Passen Sie die Schwellenwerte je Raum an und besprechen Sie die Alarmmüdigkeit wöchentlich mit den Pflegekräften.
5. Ergänzen Sie die Routineanalyse erst, wenn die Sturzalarme stabil laufen und akzeptiert sind.

Quellen

1. Fall Detection in Elderly People: A Systematic Review of Ambient Assisted Living and Smart Home-Related Technology Performance (PMC) - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12609574/
2. Reliable Quasi-Static Post-Fall Floor-Occupancy Detection Using Low-Cost Millimetre-Wave Radar (arXiv) - https://arxiv.org/pdf/2601.17710
3. Radar-Based Fall Detection for Assisted Living: A Digital-Twin Representation Case Study (arXiv) - https://arxiv.org/html/2601.11938v1
4. Edge-Efficient Two-Stream Multimodal Architecture for Non-Intrusive Bathroom Fall Detection (arXiv) - https://arxiv.org/pdf/2603.17069
5. Environment-independent mmWave Fall Detection with Interacting Multiple Model (arXiv) - https://arxiv.org/pdf/2311.08755
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
8. Regulation (EU) 2017/745 (MDR) - https://eur-lex.europa.eu/eli/reg/2017/745/oj