Axon Labs
All insights

From the engineering desk

Insight10 min read23 July 2026

Why Fall-Detection Wearables Cry Wolf (and How to Fix It)

In one real-world study, 83 of 84 fall alarms were false. The engineering playbook for specificity: alarm budgets, sensor fusion, escalation and field validation.

By Axon Labs Engineering

Fall detection looks like a solved problem. A 2025 wearable system published in Sensors reported 97.9% sensitivity and 99.9% specificity in validation — numbers that read like victory. Then there’s the field: in a real-world deployment with older adults, a commercial fall-detection device produced 84 alarms, and 83 of them were false. That gap — between the lab table and the kitchen floor — is the actual engineering problem in fall detection, and it’s the one this article is about.

Key takeaways

  • Lab performance is not field performance: published systems hit 97.9% sensitivity / 99.9% specificity in validation, yet in one real-world study 83 of 84 alarms were false — and only 7.1% of fall-detection projects test in real-world settings at all.
  • The arithmetic is unforgiving: a device evaluating thousands of movement windows daily produces regular false alarms even at 99.9% specificity. The false-alarm budget — alarms per user-month — must be a top-level spec with a number.
  • The fixes are architectural: fuse modalities impostor motions can’t fake, escalate instead of alarming, and gate the program on free-living pilot data, not lab datasets.

The lab says solved. The field says otherwise.

The clinical need is enormous and well-documented: over 14 million US adults 65 and older — 1 in 4 — report falling each year, driving nearly 3 million emergency visits and more than 38,000 deaths annually (CDC), at a cost estimated above $60 billion in 2026. Automatic fall detection is the market’s answer, and on paper it works: a 2025 system in Sensors (MDPI) reported 97.9% sensitivity, 99.9% specificity, 99.7% accuracy.
Then researchers put a commercial device on older adults and watched. Over months of real-world use, the device raised 84 fall alarms. Eighty-three were false (PMC, real-world accuracy study). The umbrella evidence explains the disconnect: a systematic review found only 7.1% of wearable fall-detection projects report testing in real-world settings at all (PMC systematic review). The field is optimizing for the wrong exam.

The arithmetic labs don’t run

Why does 99.9% specificity feel like 83-out-of-84 in practice? Base rates. Falls are rare events; movement is continuous. A worn device evaluates thousands of motion windows every day, nearly all of them non-falls — so even a tiny false-positive rate multiplies into a steady drip of alarms, while the true falls it exists to catch arrive perhaps once a year.
The published field numbers agree with the arithmetic: an umbrella review of systematic reviews found individual false-positive rates of up to 0.3 alarms per hour in older adults (BMC Public Health, 2021) — several per waking day for the unluckiest users. Specificity written to three nines in a paper becomes a weekly nuisance on a wrist. That’s not a tuning problem. It’s a spec problem.

What actually triggers the false alarms

The real-world study catalogued its 83 false alarms, and the breakdown should reshape any detection roadmap: the biggest single cause wasn’t vigorous motion at all — it was normal device use.
Impostor eventWhy the IMU is fooledThe discriminating signal
Sitting down hardImpact spike resembles a fall’s decelerationPre-event gait context; posture recovery within seconds
Dropping / putting down the deviceFreefall plus impact — textbook fall signatureOn-body detection: skin contact, pressure, temperature
Car braking, elevatorsSustained acceleration transientsVibration signature; GPS/speed context
Bed transfers, lying down fastOrientation change plus impactLocation and time context; controlled-descent profile
Notice the pattern in the third column: almost every discriminator is context — what was happening before, and whether the device was even on a body. Single-sensor impact detection can’t see context. That’s the design insight, and it points directly at fusion.

False positives are an adoption event, not an annoyance

In the same real-world study, 9 of the 10 participants who didn’t complete the protocol left voluntarily. Every false alarm costs the user an embarrassing check-in call, or costs a caregiver a spike of fear — and users respond rationally: they take the device off. A fall detector in a drawer has a sensitivity of exactly zero.
This is the argument we made in our wearable health development guide: field performance, not lab accuracy, is the product, and comfort — physical and psychological — is a clinical feature. The false-positive problem is really an adherence problem, which makes specificity the commercial spec, not just the technical one.

Give the false-alarm budget a number

The teams that ship credible fall detection treat the false-alarm budget like a power budget: a named, top-level requirement — alarms per user-month — owned from architecture through validation. One per month is tolerable for most users and caregivers; one per week is churn; one per day is a returned unit.
  • Write it into the spec sheet beside sensitivity, and refuse the single-number accuracy conversation — a claimed “99% accurate” means nothing at these base rates.
  • Trade deliberately. Sensitivity and specificity move against each other; the budget decides where on the curve you ship. A missed-fall backstop (an unanswered “are you OK?” check-in) buys specificity headroom safely.
  • Segment the users. False-alarm rates vary person to person — frailty, gait, activity level all shift the impostor distribution (Scientific Reports, user-characteristics study). Per-user baselines beat one global threshold.

Fuse modalities the impostors can’t fake

Every impostor in the table above defeats an accelerometer. Almost none of them defeat an accelerometer plus context. That’s the fusion argument from our edge AI development guide applied clinically: better models over more modalities beat a harder-tuned threshold on one.
Fusion also solves the on-body problem directly: a device that knows it isn’t being worn shouldn’t be able to raise a fall alarm at all. Skin contact, pressure and temperature checks are cheap gates that would have eliminated the “dropped device” class entirely.

Escalate, don’t alarm

The architecture that reconciles fast response with a tight alarm budget is a staged escalation, not a tripwire. On-device inference flags a candidate event in milliseconds. Context checks — was the device worn, what preceded the impact, did the user recover posture — run in the next seconds. An unanswered check-in (“Are you OK?”) escalates to a caregiver or monitoring service. Only silence escalates to emergency contact.
Each stage filters impostors while true falls — where the user is down and not responding — pass through untouched. It’s the hybrid split from our wearables work: reflexes on the device, judgment above it. And it changes the reporting math for caregivers, who receive one meaningful escalation instead of a feed of maybes.

Free-living data is the phase gate

If only 7.1% of projects test in the real world, the differentiator is going there early. Lab datasets — scripted falls onto mats by healthy volunteers — are the hypothesis. The evidence is an instrumented pilot in real homes: devices worn wrong, half-charged, on real gaits, through real weeks. That’s where the impostor distribution actually lives.
  • Instrument the pilots. Log candidate windows, not just alarms, so specificity can be measured against the full denominator.
  • Gate on field metrics. Alarms per user-month and missed-fall backstop latency become EVT/DVT exit criteria, exactly like any other subsystem in the phase-gate process.
  • Keep learning after ship. Field telemetry feeding model updates — through a signed, revertible OTA path — is both the performance flywheel and, since September 2026, part of the CRA’s update-capable architecture anyway.
Users don’t abandon devices that miss falls. They abandon devices that cry wolf.

The bottom line

  • The lab exam is the wrong exam: 99.9% specificity coexists with 83-of-84 false alarms in the field, because base rates multiply tiny error rates into daily noise.
  • Specificity is the commercial spec — false alarms drive abandonment, and an unworn detector detects nothing. Give the alarm budget a number and own it like a power budget.
  • The fixes are architectural: fuse context the impostors can’t fake, escalate in stages instead of alarming, and validate on free-living data as a phase gate.
We’ve engineered exactly this problem — pressure-plus-inertial fusion, hybrid escalation, sub-$50 BOM — in a shipped clinical wearable. If your product lives or dies on detection credibility, start with a discovery & feasibility phase and we’ll size the alarm budget before the silicon.

Frequently asked questions

How accurate is wearable fall detection?

In the lab, excellent: a 2025 system in Sensors reported 97.9% sensitivity and 99.9% specificity. In the field, far worse: one real-world deployment with older adults logged 84 fall alarms of which 83 were false, and an umbrella review found up to 0.3 false alarms per hour. Lab accuracy and field performance are different questions.

Why do fall-detection devices produce so many false alarms?

Base rates. A worn device evaluates thousands of movement windows daily, nearly all non-falls, so even 99.9% specificity yields regular false alarms. In field data the biggest triggers weren't falls-like events at all: 42.2% of false alarms came from normal device use, and another 27.7% from dropping, misusing or putting down the device.

What false-alarm rate is acceptable for a fall detector?

Treat it as a named spec: alarms per user-month. Roughly one per month is tolerable; one per week drives abandonment; one per day is a returned unit. In one real-world study, 9 of 10 participants who didn't complete the protocol left voluntarily — false alarms are an adoption event, not an annoyance.

How do you reduce false positives in fall detection?

Architecturally: fuse modalities that impostor motions can't fake (pressure plus inertial data separates a fallen body from a dropped device), gate alarms on on-body detection, use per-user baselines, and escalate in stages — candidate, context check, unanswered check-in — instead of alarming on first impact.

Why do lab results not transfer to real-world fall detection?

Because almost nobody tests there: a systematic review found only 7.1% of wearable fall-detection projects report real-world evaluation. Lab datasets use scripted falls by volunteers; real homes contribute the actual impostor distribution — device handling, sitting hard, car rides — plus devices worn wrong and half-charged.

Sources

If the product has to ship, talk to the team that builds for that outcome.

Senior engineer on the first call. NDA before technical detail. References available under NDA after qualification. Or start with a fixed-fee feasibility study.

Request a conversationFeasibility study