Fall detection & ambient assisted living

Falls are a leading cause of injury and loss of independence among older people, and a long lie on the floor after a fall worsens outcomes. Classic push-button alarms fail when the person is unconscious or does not wear the device. AI-based fall detection and ambient assisted living (AAL) combine wearables, privacy-preserving radar and home sensors to detect falls automatically, notice slow changes in routine and alert carers, so people can stay at home or in care homes with less intrusive supervision.

Problem & value

• Today: pendant alarms need a button press; many people forget or cannot wear them. Care homes rely on night rounds and call bells. Cameras raise strong privacy objections.
• AI value: automatic detection of falls and prolonged floor occupancy, fewer unnecessary night rounds, early warning of decline (changed gait, nocturia, reduced activity) and relief for scarce care staff.
• Evidence: a 2025 systematic review of AAL fall-detection technology found that non-wearable and hybrid (wearable plus ambient) solutions reached the highest detection performance and that deep learning gave the best results [1]. Recent radar research stresses that most detectors are trained on staged falls by young volunteers, which may not reflect real falls of frail older adults, so real-world performance must be validated locally [2][3].
• Constraint: value depends on the response process. An alert nobody answers within minutes has no benefit, and false alarms cause alarm fatigue.

Variants

• Home care / telecare: wearable or radar unit linked to an emergency call centre (Hausnotruf style).
• Care homes and hospitals: room-level radar or bed sensors, integrated with nurse-call systems and care documentation (see HLTH-025).
• Bathroom and night-time monitoring: the highest-risk location, where cameras are inappropriate; multimodal low-power sensing is being researched [4].
• Routine analytics ("activity of daily living"): passive smart-home sensors build a baseline and flag deviations (links to HLTH-007).

How it works

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: accelerometer and gyroscope with threshold logic or small neural networks; smartwatches add heart rate and impact detection.
• Radar: mmWave sensors track body height and motion and can detect a person lying still on the floor, working in the dark without images, which is the main privacy argument [2][3].
• Vision: pose estimation on depth or thermal frames, processed on the device so no images leave the room.
• Human-in-the-loop: every alert is verified (call, voice channel or visit) and the escalation rules are defined by the care provider; no automated emergency dispatch without human check unless the resident consented.

Data preparation

This use case runs mostly on sensor streams (wearable IMU, mmWave radar, depth or thermal frames, door and motion sensors) rather than on business documents. Relevant data live in the sensor vendor's platform, the nurse-call system and the care documentation software; incident reports are often paper or free text.

Typical gaps: no labelled falls (real falls are rare), alarm logs without outcomes, sensors without room or resident profile, inconsistent clocks, unclear consent and access rights for residents and relatives, and scattered escalation rules.

Preparation steps: - Document per room the sensor placement, resident profile and escalation ladder in one table (PREP-011). - Link alarm logs with the outcome (real fall, false alarm, test) by asking carers to confirm or dismiss every alert (PREP-021, PREP-020). - Collect a small evaluation set of staged falls and daily activities under supervision (PREP-018). - Keep raw sensor data local; store only events and pseudonymised baselines (PREP-022).

For a bought system, preparation is mainly room mapping, consent management and process definition, roughly a fifth of the effort; own model development shifts most of the effort into data collection and labelling.

Implementation paths

Which path for whom

• smb (small care providers, assisted-living operators): Path A, because mature sensor systems with emergency-call integration and certified processes exist; own models would add liability without benefit.
• enterprise (large care operators, housing companies): Path A, because commodity systems fit and the fall-alert process is standardised; negotiate central platforms and on-premise or EU hosting.
• developer: Path C, because open radar and IMU datasets and edge-capable open models allow building and testing detection on-device without sending data off-site.
• public (municipal care, social housing): Path A with certified products and EU or municipal hosting; open source only where the authority can operate and take responsibility for it.
• private (families): Path A, because ready-made wearables and radar sensors with an emergency-call service are simple to install and need no technical knowledge.

Path A — Buy (recommended)

• Telecare and AAL platforms: Tunstall, Doro, Vayyar (radar-based room sensors, Israel), Kepler Vision Technologies (Netherlands, EU; camera-based fall detection for care homes), Sensara, Safelyyou (US), and consumer options such as Apple Watch and Samsung Galaxy Watch fall detection. Verify current product lines and EU availability with the vendor.
• Check: CE marking and MDR status if medical claims are made, on-device processing, EU hosting, DPIA support, integration with nurse-call and care software, measured false-alarm rate in comparable settings.
• Choose A when: you are a care provider or housing company without ML staff; the process (response) matters more than the algorithm.

Path B — Build on cloud APIs

• Use device SDKs and IoT backends (Azure IoT, AWS IoT Core in EU regions, or EU providers) for ingestion, with rule engines, cloud time-series storage and workflow automation (n8n, Node-RED) for escalation.
• LLM APIs (EU-hosted) for plain-language daily summaries only, never for the detection decision.
• Choose B when: you integrate sensors from several vendors into one dashboard.

Path C — Self-host (open source)

• Edge: Raspberry Pi 5 or Jetson Orin Nano with radar modules (for example Texas Instruments mmWave or Infineon sensors), models exported to ONNX or TensorFlow Lite; MediaPipe/MoveNet or YOLO-pose for depth/thermal pose.
• Platform: Home Assistant, MQTT, Node-RED, InfluxDB/TimescaleDB, Grafana.
• Datasets: public fall datasets exist (for example radar and wearable sets in the cited reviews) but are largely staged; treat results as upper bounds [1][2].
• Hardware: HW1 (edge device per room), a small CPU server for the platform. Ops effort is high because of device fleet management and safety obligations.

Path D — Custom training

Worth it for vendors building a product or research projects. Needs labelled sensor data from real homes or care facilities, ideally with hard negatives (sitting down abruptly, dropping objects, pets, bed transfers). Collecting real falls is rare and ethically sensitive, so synthetic data, digital-twin simulation of radar returns [3] and few-shot adaptation per room are active areas. A product with a medical purpose needs a quality management system and clinical evaluation.

State of the art (2026)

• Radar is the leading privacy-preserving ambient modality; research now focuses on environment-independent models, post-fall floor-occupancy detection and digital-twin training data [2][3][5].
• Multimodal fusion (radar plus audio or wearable) lowers false alarms compared with single sensors [1][4].
• Edge inference on microcontrollers and small NPUs keeps raw data in the home.
• Limits: domain shift between staged and real falls, different room layouts, multiple people, pets and slow "sliding" falls; false alarms from bed-side sitting; missed falls reduce trust. Reported accuracies in papers are rarely comparable with field performance.

Shared resources & combinations

• Same stack: HLTH-007 (remote patient monitoring and wearable analytics) shares the time-series and device pipeline; VIS-024 shares pose estimation; ROBO-011 shares TinyML and edge deployment.
• Combinations: HLTH-012 (deterioration early warning) in care homes, CONV-016 (companion and voice assistants for elderly people) for two-way voice check-ins, HLTH-025 (nursing documentation) for logging incidents.

Effort, cost & KPIs

• Path A: weeks for rollout; cost per room or per user per month plus installation. Training staff and defining the response chain is the main effort.
• Path B: 3-6 months for integration of sensors, dashboard and escalation.
• Path C: 6-12 months with embedded and ML skills; plus long-term device maintenance.
• Path D: 12+ months, clinical study and QMS.
• KPIs: sensitivity on verified falls, false alarms per resident per week, time to response, time on floor, hospital admissions after falls, night-round reduction, carer satisfaction, resident acceptance.

People & change

Start with management and the care-service lead (duty of care, liability, budget), then the carers who respond to alerts, IT (network, sensor installation), the data protection officer, and the residents or their legal representatives and relatives, whose consent and understanding decide acceptance. A DPIA is likely, because continuous monitoring of vulnerable persons in their living space is systematic; health inferences touch special-category data, and an AVV is needed with the platform vendor.

Works council: depends. Sensors observe residents, but staff response times, location and alarm acknowledgements are logged; the BAG treats objective suitability for monitoring as sufficient under §87(1) no. 6 BetrVG, so involve the works council if one exists. §90(1) no. 3 requires early information on new AI-supported work processes. Municipal operators involve the Personalrat.

Support AI literacy (Art. 4 AI Act) for carers: what the system detects, typical false alarms, what to do when it fails (GUIDE-006). Pilot on one ward or in a few flats; collect feedback on alarm fatigue (GUIDE-009). Typical concerns: surveillance and loss of privacy for residents, extra workload for staff. Prefer radar over cameras, allow opt-out, tell residents clearly what is recorded, and keep a human verification step in every alert (GUIDE-008, GUIDE-005).

Risks, regulation & compliance

• EU AI Act: depends on purpose. A product with a medical purpose (fall detection or monitoring used for diagnosis or clinical decisions) is a medical device under the MDR (typically class IIa or higher under rule 11 for monitoring software, per manufacturer's classification) and, if a notified body is required, becomes a high-risk AI system under Art. 6(1) and Annex I. A pure wellness or safety alarm may be minimal risk. AI literacy (Art. 4) applies. Art. 5: emotion recognition in workplace or education settings is prohibited, and biometric categorisation inferring sensitive traits is prohibited; keep fall systems free from such features and avoid staff performance monitoring through the same sensors [6].
• GDPR: health and behavioural data are special-category data (Art. 9); a DPIA is normally required (Art. 35). Residents with dementia may lack capacity to consent, so involve legal representatives and apply data minimisation; prefer on-device processing and radar or thermal over cameras [7].
• MDR: claims such as "detects falls to prevent injury" can bring the product under Regulation (EU) 2017/745 [8].
• Safety: define fail-safe behaviour (connection loss, battery low, sensor offline) and test alarm delivery regularly.

Getting started

1. Map the response process first: who answers an alert, within what time, and what happens at night.
2. Choose the modality by setting (wearable for home, radar for bedroom and bathroom, no cameras where avoidable) and complete a DPIA with residents' representatives.
3. Pilot two vendors in 5-10 rooms for 3 months and log every alert as true, false or missed.
4. Tune thresholds per room and review alarm fatigue weekly with carers.
5. Add routine analytics only after the fall alerts are stable and accepted.

Sources

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