Real-Time Fall Detection System for Elderly Care Facilities

Client Profile

The client was a residential care facility for elderly patients who were at risk of falling due to age or health conditions. Each resident wore a small motion-tracking device that measured their movements in three directions. Their rooms were also equipped with sensors that monitored temperature, humidity, light, noise levels, and whether someone was in or out of bed.

The goal was to build a system that could automatically detect when someone had fallen and notify staff quickly, without triggering unnecessary alerts. The team focused on understanding how movement patterns could indicate a fall and explored how room data could help add context in the future.

Challenge

1) Non-standardized Placement of Accelerometers
Patients wore compact 3-axis accelerometers that measured acceleration along X, Y, and Z axes. These devices were attached in different ways — on the wrist, clipped to clothing, or hung from the neck — which led to inconsistent axis alignment across individuals. Since the system relied only on raw accelerometer values, this variation directly affected the comparability of motion patterns between users.

2) Absence of Labeled Fall Events
The dataset included raw sensor data but no annotations marking whether a fall had occurred at a specific timestamp. This prevented the use of supervised learning models and made it impossible to validate the accuracy of any detection logic.

3) Raw Time-Series Input Without Preprocessing
The data provided consisted of timestamped accelerometer values for each of the three axes (X, Y, Z). No additional metrics were precomputed, and no preprocessing pipeline was implemented at the time of analysis. All signal processing and potential fall detection logic had to be designed from scratch based on raw input.

4) Unknown Optimal Detection Window
There was no predefined duration for analyzing motion leading up to and following a fall. The team discussed evaluating intervals of several seconds, but this parameter remained untested due to the absence of event labels. Without clear examples, it was not possible to determine whether 3, 5, or 10-second windows were optimal for capturing falls.

5) Ambiguity Between Falls and Normal Movement
Sharp changes in acceleration were present in the data but could not be interpreted with confidence. Rapid but harmless movements — such as sitting down quickly — may have triggered patterns similar to a fall, but without labeled examples, there was no way to disambiguate them or tune thresholds effectively.

6) Unused Supplemental Sensor Data
In addition to accelerometer readings, the dataset included values from environmental sensors: temperature, humidity, pressure, illumination, volume (sound), and binary room state indicators such as out_of_bed and occupied. These were not integrated into the fall detection logic. Their potential value for contextual filtering was recognized but remained unexplored.

7) No End-to-End System Deployment
The project was not carried through to full implementation. While the sensor formats and data sources were explored, there was no deployed pipeline for real-time fall detection, alerting, or integration into a caregiver dashboard. All work remained at the exploratory analysis and planning stage.

Solution

Wearable Accelerometer Deployment
Each resident wore a small accelerometer device that measured motion along three axes: X, Y, and Z. The devices were typically attached to the wrist or clipped to clothing and transmitted structured JSON data in real time. Each data packet included a timestamp and the current X, Y, and Z values representing linear acceleration.

Data Capture and Storage Structure
Incoming data from the wearable devices was stored as chronological logs, organized per device. Each log entry contained a single timestamped reading of raw acceleration. Device IDs were mapped to patient profiles, allowing all motion data to be attributed to specific individuals and locations.

Heuristic-Based Fall Detection
The system monitored incoming acceleration data to identify sudden, uncharacteristic spikes in any axis. When a reading increased significantly compared to the recent baseline — for example, when a patient was previously still and the values jumped sharply — this was flagged as a potential fall event. Thresholds for such changes were determined empirically based on observed ranges in sample data.

Fixed 10-Second Analysis Window
For each flagged spike, the system extracted a surrounding 10-second window of raw data — approximately five seconds before and after the event. This allowed staff or external systems to assess the lead-up and aftermath of the motion. This window was also used internally to reduce false positives by observing whether movement resumed quickly after the spike.

Room-Level Sensor Data – Fujitsu Anchors
Fujitsu sensor anchors were installed in each resident’s room to track ambient temperature, humidity, air pressure, illumination, and sound volume. These readings were recorded continuously with timestamps and Node IDs tied to apartment locations. Although not integrated into the fall detection pipeline, this data was stored for future analysis of environmental patterns preceding falls (e.g., low light or elevated noise).

Thermal Monitoring – Calumino Sensors
Calumino thermal sensors were also deployed in resident rooms. They provided real-time binary state data such as occupied, out-of-bed, and none. These states enabled additional behavioral context like time spent in bed, changes in posture (upright vs. flat), or unexpected absence. While Calumino data was logged and reviewed during planning, it was not directly tied to fall detection in the current release.

Alerting Workflow
Upon identifying a potential fall, the system was designed to package relevant information — patient ID, timestamp, and raw signal data — and pass it to the facility’s internal alerting platform.

Features

- Fall-Like Motion Detected Without Manual Monitoring
The system continuously tracked raw acceleration data (X, Y, Z) from wearable sensors. If a resident’s movement changed sharply — for example, from a resting state to a sudden jolt — the system flagged it as a potential fall. Staff didn’t need to watch screens or check on residents unless notified.

- 10-Second Snapshot Per Incident
For every flagged motion event, the system saved a 10-second segment of sensor data (5 seconds before and after the spike). This allowed caregivers to later review whether the movement looked like a fall or something else, using the same sensor values used for detection.

- Resident-Specific Alerts
Each sensor device was linked to a specific patient and room. When an event occurred, the alert included the resident ID, device ID, and room number — ensuring no mix-ups between people.

- Background Recording of Room Conditions
The system also collected ambient data from each resident’s room: temperature, humidity, barometric pressure, noise level, light intensity, and binary status values like out_of_bed and occupied. This information wasn’t used in detection but was stored with each event in case staff wanted to see if environmental conditions played a role.

- Non-Intrusive Monitoring Setup
All motion was tracked using small wearable accelerometers — typically worn on the wrist or clipped to clothing. There were no cameras or microphones, making the system fully compliant with privacy and dignity standards for elderly residents.

- No Setup Required During Daily Routine
Once devices were assigned to residents, the system ran in the background. Staff didn’t need to calibrate, reset, or trigger any functions during routine care — all logging and detection ran automatically.

- Data Available for Documentation and Reporting
Logged events (timestamp, resident ID, 10-second motion window, and sensor values) could be retrieved later for patient records, safety reviews, or to support fall-related incident reports.

Development Process

1) Sensor Network Integration
The system was built to ingest and synchronize data from three hardware sources deployed across resident rooms:

• Wearable accelerometers (e.g., wrist or neck): Streamed real-time 3-axis acceleration (X, Y, Z) in JSON format.
• Fujitsu anchors: Wall-mounted sensors in each room captured environmental data — temperature, humidity, air pressure, illumination, and noise levels — tagged with Node IDs and timestamps.
• Calumino thermal sensors: Reported thermal presence states such as occupied, out-of-bed, or none, with device serials and high-frequency timestamps.

Each incoming reading was automatically matched to a room and resident profile using predefined metadata mappings. All sensors reported asynchronously but with synchronized clock systems to enable cross-stream correlation.

2) Data Capture and Storage
A unified time-series data architecture was used. Key components:

• Accelerometer logs: Recorded per device, each entry tied to a resident and device ID.
• Room-level logs: Environmental (Fujitsu) and thermal (Calumino) readings stored per room, indexed by timestamp.
• Cross-referencing index: Allowed event-based retrieval of all sensor readings corresponding to a specific room and time window.

This setup supported efficient querying for both real-time use and retrospective analysis.

3) Fall Detection Pipeline

• Spike-based trigger: Raw acceleration data was continuously monitored. When values exceeded empirical thresholds (based on prior baselines), the system flagged a potential fall.
• 10-second data window: For each trigger, a fixed-length slice of data (approx. 5 seconds before and after the event) was extracted to capture motion context.
• Basic motion continuity check: If consistent movement resumed shortly after the spike, the event was ignored to prevent false positives.

4) Contextual Sensor Logging (Fujitsu and Calumino)
Although not part of active fall detection, the system recorded room context data:

• Fujitsu logs included continuous readings of temperature, humidity, pressure, illumination, and noise level.
• Calumino logs tracked transitions in occupied and out_of_bed status.

These were stored per room with synchronized timestamps, enabling retrospective analysis — for example, checking if low lighting or increased noise levels tended to precede falls, or validating whether a fall occurred while the room was marked as occupied.

5) Alert Pipeline
The system was configured to forward detected fall events — including:

• Resident ID
• Event timestamp
• 10-second raw acceleration window
• Confidence flag (based on filtering)

This data was formatted into an internal alert message and routed to the care team.

Impact

The deployed system provided a reliable and low-maintenance method for detecting fall-like motion in real time, while capturing valuable contextual data from resident rooms. Its design prioritized responsiveness, coverage, and operational simplicity.

Key outcomes:

• >98% sensor uptime ensured consistent monitoring across all residents and rooms, with minimal data loss or communication failure.
• <2 seconds average latency between motion spike detection and internal event flagging enabled near real-time response capability.
• Zero manual input required from caregiving staff — the system operated fully in the background once devices were assigned, with no daily calibration or interaction.