66 Fall Detection: Motion Thresholds

66.1 Start With the Decision

Begin with one risk or task. Ask the person what help they want.

66.2 Route Overview

This is part 1 of 2. Continue with Fall Detection: Alert Reliability.

66.3 Part Objectives

• Calculate motion marley’s math bridge: fall motion, quantisation, and sampling from stated measurements and limits.
• Validate design for trust before scaling alerts with a concrete scenario and pass criteria.

66.4 Overview

This first route follows a fall from sensor evidence through latency, confirmation, caregiver contact, escalation, and alert-fatigue review.

This is part 1 of 2. Continue with Elderly Care IoT: Monitoring, Economics, and Autonomy for the second focused route.

66.5 Start With the Story

Help Without Taking Away Control

Picture an older adult who wants to live at home. A door sensor, fall button, or medicine reminder may help. The goal is not to watch every moment. The goal is to support a clear need while the person keeps choice, dignity, and control.

Begin with one risk or task. Ask the person what help they want. State what the device can notice and what it cannot know. Choose who receives an alert. Set a response time. Provide a simple way to cancel a false alarm and ask for help when the device fails.

Collect the least private detail that can do the job. A room-level change may be enough; a camera may not be needed. Test poor signal, low power, unusual routines, visitors, and long quiet periods. Record consent and review it when the service changes.

This simple model cannot remove all risk or replace human care. It makes one support path clear and testable.

Use Practitioner to build the service record. Use Under the Hood to examine inference, fairness, safety, and privacy limits.

Picture an older adult at home after a sudden fall. A sensor alert helps only if the right person can check it and act in time.

First, name the care goal and the person who owns each step. Then trace the path from a sign, to a check, to a call, and to help.

More sensors may catch more clues, but they can also raise false alarms and reduce privacy. Less sensing protects daily life, yet it may miss a weak sign.

That is the simple story, but it cannot set a care rule or prove a health claim. The cases and safety checks later in the chapter supply that detail.

Use the Practitioner sections to design and test the care path. Use the Under the Hood sections to study risk, delay, consent, and weak evidence in more depth.

Plain check

• Name the care goal. Ask the older adult. Record clear consent. Keep choice in view.
• Name the first sign. Mark its time. Mark its source. Mark what it cannot prove.
• Check the worn state. Check the charge state. Check the home link. Check the phone link.
• Ask for safe cancel. Give enough time. Make the prompt clear. Record the answer.
• Name the first carer. Name the next carer. Name the final help. Set each wait time.
• Test no reply. Test a dead phone. Test a lost link. Test a tired carer.
• Check a false alert. Check a missed alert. Count both harms. Change the rule with care.
• Keep private data small. Keep its life short. Limit who may view it. Log each use.
• Separate urgent signs. Separate slow change. Do not mix their rules. Keep each owner clear.
• Rehearse the call path. Rehearse the night path. Rehearse a travel case. Save each result.
• Give staff plain steps. Give family plain steps. Give the adult control. Keep support easy.
• Check each new device. Check each new home. Check each code change. Reopen the care plan.
• Save the event record. Save each response. Save each delay. Mark what stayed unknown.
• Use Practitioner to test. Use deeper risk checks. Read the care limits. Keep claims modest.
• Review with real people. Fix confusing steps. Remove unused data. Repeat the full test.

Picture an older adult living independently while family or care teams need confidence without constant surveillance. Fall detection and elderly-care IoT must balance signal interpretation, dignity, response time, and false alarms so the connected system supports care instead of replacing judgment.

Phoebe’s Field Notes: What “>3g” Actually Measures, And Whether 50 Hz Can Catch It

Motion Marley’s Math Bridge: Fall Motion, Quantisation, and Sampling

The mathematical gist. With a catalog-style 5.5 kHz MEMS resonance, a 3g threshold moves the proof mass only 24.6 nm. A 12-bit ±16g converter resolves 7.81 mg per code, so amplitude quantisation is not the obvious bottleneck. A 20 ms impact contains features near 50 Hz and therefore asks for at least 100 samples/s; the chapter’s 50 Hz rate supplies only one sample per pulse and can miss the true peak by phase.

Math Bridge · guided foundationsCan a 50 Hz clock catch a 20 ms fall impact?Let Motion Marley connect proof-mass motion, ADC codes, pulse duration, and Nyquist sampling. Learn the maths

66.6 Fall Detection with Sensor Fusion

66.7 Putting Numbers to It

Fall detection alert latency budgets work backward from clinical response requirements:

Use this latency budget: caregiver window equals the clinical response requirement minus expected EMS response and detection-to-notification latency.

Worked example: 15-minute clinical response requirement for fall detection system.

Subtract EMS response: 15 minutes - 8 minutes (average ambulance arrival) = 7 minutes available.

Subtract detection latency: 5.1 seconds (fall confirmation) + 2.1 seconds (notification chain) = 7.2 seconds system latency.

Caregiver response window: 420 seconds - 7.2 seconds = 412.8 seconds (6.9 minutes) for graduated alerts before auto-911 dispatch.

Alert cascade timing: T+0 patient cancel button (30 sec) → T+30s primary caregiver → T+3min secondary caregiver → T+5min auto-911. Total: 7.2-second detection + 5-minute cascade + 8-minute EMS = 13.1 minutes, meeting the 15-minute requirement with a 1.9-minute safety margin.

66.8 Learning Objectives

By the end of this section, you will be able to:

• Assess the elderly fall crisis and its economic impact on healthcare systems
• Design fall detection systems using multi-sensor fusion and edge ML
• Calculate alert latency budgets for healthcare IoT working backward from clinical requirements
• Implement comprehensive elderly monitoring with behavioral analytics and pattern detection
• Evaluate privacy, autonomy, and ethical trade-offs in elderly surveillance systems
• Analyze the business model including Medicare reimbursement and ROI calculations

66.9 Minimum Viable Understanding (MVU)

If you only have 5 minutes, focus on these three essentials:

1. Falls are the #1 cause of injury death for adults 65+ — IoT sensors (accelerometer + gyroscope + ambient) detect falls in under 10 seconds with 95%+ accuracy
2. Alert cascades work backward from clinical requirements — a 15-minute clinical response window minus 8-minute EMS response leaves ~7 minutes for the IoT detection-to-notification chain
3. Behavioral analytics detect gradual decline — subtle 2-week changes in activity, sleep, and medication adherence predict health crises before they become emergencies

Everything else in this chapter builds on these three ideas.

66.10 Fall Detection as Escalation

An elderly-care IoT system must detect possible falls, decide how confident it is, ask for human confirmation when possible, and escalate without stripping away autonomy or privacy. The wearable, phone, room sensor, or bed sensor is only the first step. The real system includes the older adult, caregivers, emergency contacts, monitoring staff, clinical teams, device support, and the policies that decide who sees which data and who is responsible for acting on it.

Read fall detection as a timed decision chain rather than a single classification result. A sensor event becomes a candidate fall, the edge model checks movement and posture context, the device asks the wearer to cancel if safe, the app alerts caregivers, and the service escalates when no one responds. Each delay, false alarm, missed event, dead battery, worn-wrong device, connectivity gap, or unclear responsibility changes the safety of the deployment. A technically accurate model can still fail if the alert chain is not owned and rehearsed.

Use the linked figure in Part 2 to inspect fall detection as an end-to-end escalation service. Trace the wearable and gateway path through cloud analysis, wearer or caregiver acknowledgement, monitoring escalation, and emergency response; the value lies in the owned chain, not in a sensor threshold alone.

Good designs also distinguish emergency fall detection from slower behavioral monitoring. A fall alert may need seconds-level confidence, location, and escalation. A decline-in-activity signal may need days or weeks of trend evidence before a caregiver checks in. Medication reminders, door sensors, bed sensors, bathroom motion, stove monitoring, and wearable vital signs can support care, but they also increase surveillance risk. The care goal should decide the sensor mix, not the other way around.

• Detection boundary: Separate impact, orientation, inactivity, gait change, heart-rate context, location, and ambient corroboration instead of treating one threshold as truth.
• Escalation boundary: Define who is contacted, when, by what channel, and what happens when the wearer, caregiver, phone, monitoring center, or network does not respond.
• Care boundary: Distinguish independent living, assisted living, memory-care support, post-discharge monitoring, and facility operations because each has different staffing and consent assumptions.
• Autonomy boundary: Collect only the data needed for the care goal and make cancellation, consent, review, retention, and data-sharing rules visible.

The key product question is therefore not “can the sensor detect a fall?” It is whether the whole service can notice a high-risk event, avoid alert fatigue, preserve dignity, reach the right person, and leave an auditable record of what happened.

Checkpoint: Escalation Boundaries

You know:

• Fall detection is useful only when sensing, confidence, cancellation, caregiver acknowledgement, monitoring escalation, and emergency response are treated as one chain.
• Detection, escalation, care, and autonomy boundaries prevent a high-accuracy model from becoming an unsafe or intrusive service.
• A deployment must record device, alert, care, and privacy state so support teams can distinguish real falls, false alarms, offline periods, and consent limits.

66.11 Design for Trust Before Scaling Alerts

False alarms are not just a model-quality issue; they are a workflow risk. If caregivers receive too many low-confidence alerts, they may stop treating notifications as urgent. If the wearer cannot cancel an obvious false alarm, the system can feel punitive. If alerts contain too little context, responders lose time deciding whether the event is real, whether the person is still moving, and where help is needed. Trust is built by showing the right evidence to the right actor at the right time.

A practical design uses sensor fusion and staged escalation. A wrist, watch, phone, or pendant IMU can combine accelerometer, gyroscope, barometer, and heart-rate context. A home deployment may add bed, motion, door, appliance, room-occupancy, floor-vibration, or voice-assistant signals. The app should distinguish self-cancelled events, caregiver-acknowledged events, unresolved alerts, monitoring-center escalations, device-offline intervals, and confirmed incidents so the team can improve thresholds without hiding risk.

Start pilots with a small number of explicit scenarios. Test normal sitting, lying down, stair use, exercise, shower entry, sleep, phone charging, device removal, and a staged fall drill if it can be done safely. Record how long the wearable takes to detect the event, whether the wearer can cancel it, which contact receives the alert, what context appears in the message, and whether the incident record is usable after the fact. Include caregivers in the test because they experience the operational load.

1. Name the care scenario. Distinguish independent living, assisted living, memory-care support, hospital discharge, or nursing-home monitoring before choosing hardware, connectivity, and staffing assumptions.
2. Set the escalation ladder. Define wearer prompt, primary caregiver, backup contact, monitoring center, and emergency service handoff with timeout rules, retry channels, and acknowledgement requirements.
3. Measure alert quality. Track confirmed falls, false alarms, missed events, cancellation rate, response time, battery failures, device-wearing adherence, and periods when the service was offline.
4. Plan device operations. Specify charging reminders, waterproofing expectations, replacement process, firmware updates, calibration checks, clock synchronization, and support for users with limited dexterity or cognition.
5. Protect dignity. Prefer the least intrusive sensor mix that satisfies the care goal, and expose consent, mute, review, data-retention, and family-sharing controls in language the household can understand.

66.12 Continue to the Next Part

Carry this evidence into Fall Detection: Alert Reliability, which begins with Reliability Needs Event Context.