A 7.2-Second System Inside a 15-Minute Budget
A 7.2-Second System Inside a 15-Minute Budget
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
A 7.2-Second System Inside a 15-Minute Budget
A fall detector is designed backward from a 15-minute clinical response window: subtract 8 minutes for the ambulance, and the entire IoT contribution — fall confirmation plus the notification chain — is just 7.2 seconds, leaving a 6.9-minute caregiver window. Yet across 500 patients the same system fires about 502 alerts a day, of which only 2 are real falls. If the IoT link is that small a slice of the budget while false alarms swamp the real ones, where does the engineering leverage actually lie?
Companion to the chapter Elderly Care and Fall Detection — every number here comes from that chapter.
See the relationship before changing it
The figure reads from left to right. The blue card is false alerts. The middle card applies the page rule. The green card is real-alert share. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 500 alerts/day.
- 2
Name the relationship. share = 1.9 real falls / (1.9 + false alerts) x 100
- 3
Substitute with units. 1.9 / (1.9 + 500) x 100 = 0.38%
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change false alerts
Try Predict the direction of share = 1.9 real falls / (1.9 + false alerts) x 100. Test another false alerts, then compare real-alert share.
Observe False alarms can bury the real falls even when sensitivity looks strong. Reset false alerts to 500 and compare real-alert share.
Explain False alarms can bury the real falls even when sensitivity looks strong.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
Ready: use the stated baseline inputs, then compare each displayed result.
Ada: Two of this chapter’s numbers drive design decisions: the caregiver window carved out of the 15-minute clinical budget, and the daily alert volume behind the alert-fatigue warning. Let me rebuild both from the stated inputs.
- Clinical budget:
15 x 60 = 900s; after an 8-minute EMS commitment,900 - 480 = 420s remain. - System latency:
5.1 + 2.1 = 7.2s of detection plus notification. - Caregiver window:
420 - 7.2 = 412.8s, i.e.412.8 / 60 = 6.88min, the stated 6.9 minutes. - Alert volume for 500 patients at 95% sensitivity and 95% specificity: true positives
0.95 x 2 = 1.9, false positives0.05 x 10,000 = 500, total501.9, about 502 alerts/day. - Alert reliability:
1.9 / 501.9 = 0.38%of alerts are real falls. - (One caution: the worked example’s “43% safety margin” does not follow from these inputs – the caregiver-window basis gives
412.8 / 900 = 45.9%, and the designed 5-minute cascade leaves15 - (5 + 8 + 0.12) = 1.9minutes of slack, so the honest figures are ~46% or ~1.9 min, not 43%.)
The core figures reconcile. The design meaning is a study in scale: the entire IoT contribution – 7.2 seconds – is trivial against the roughly 13 minutes owned by humans and EMS, while 500 daily false alarms swamp fewer than 2 real falls, so the engineering leverage lives in the escalation ladder and in pushing specificity past 99% with sensor fusion, not in shaving milliseconds off inference.
Every number above is taken from the chapter’s own material and re-derived step by step.