Choosing a Fall Detection System

Start from the problem, not the hardware

Fall detection is not one technology. It is a response-time problem with several possible answers, and the right answer depends on where incidents actually happen in your building, who is on shift when they happen, and what your staff will realistically wear or carry.

Buyers often start with a device. Start instead with three questions: where do falls happen, how long does a response currently take, and what would a good response look like at 3am with two staff on the floor. Everything else follows from those.

The four families of fall detection

Almost every product on the market is a variation on one of four approaches. They differ in what they detect, what they require from the resident, and what they record.

• Wearable alarms: a pendant or watch that detects a sudden drop and asks the wearer to confirm. Reliable when worn, and useless when it is in a drawer. We look at that trade-off in wearable versus camera fall detection.
• Radar and mmWave sensors: no camera, no wearable, but a smaller field of view and often no visual confirmation for staff.
• Camera-based vision: uses existing CCTV coverage, detects fall-like events in a monitored zone, and can send a short event clip or an alert. This is the approach most homes evaluate first because the infrastructure already exists.
• Floor and pressure sensors: useful for bed exits and a defined area, poor for a resident who falls while walking a corridor.

Edge versus cloud: ask where the video goes

The single most important technical question is where the video is processed. In an edge-first design, an SI (artificial intelligence AI)-assisted model runs on a device inside the building and sends only an alert or a derived signal. In a cloud design, video or frames leave the site for processing.

Both can work. But the choice changes your network requirement, your cost model, your latency and your privacy story, and the privacy story is the one families ask about first. If a vendor cannot answer 'where does the video go' in one sentence, that is your answer.

Alerting is the product

Detection without a fast, unambiguous alert is a dashboard nobody watches. Ask what exactly happens when an event fires: who is notified, on what device, how the alert is acknowledged, what happens if nobody acknowledges, and how a false alert is dismissed and recorded.

A system that produces a hundred unactionable alerts a week will be ignored within a month. Ask for the expected alert volume per zone per week, and treat that number as a core feature rather than a footnote.

Coverage: zones, rooms and the route between them

Most incidents do not happen in the bed. They happen on the way to the toilet, in a corridor, or in a bathroom. Map your own incident history onto your camera coverage and you will usually find a gap exactly where the incidents are.

If the gap is in a washroom or a bedroom, the privacy question becomes the deciding one. Our note on privacy-preserving vision in aged care covers what those systems can and cannot store.

Questions to put to any vendor

The last question matters most. A vendor who answers it honestly is worth more than one who claims to replace your staff.

• Where is the video processed, and what leaves the building?
• What is the expected false-alert rate per zone per week, and how is it measured?
• What happens when the network, the device or the internet is down?
• How are alerts acknowledged, escalated and logged?
• Can we export the incident record, and in what format?
• What does the system do that a careful night round does not?

Run a trial you can actually judge

A pilot should produce a number you can compare, not a feeling. Agree in advance what you will measure, over what period, and on which zones. Response time to a real event, alert volume, and staff-reported usefulness are usually the three that decide it.

Our FAQ answers the deployment and privacy questions we are asked most often, and the About page explains who we are and what we build. If you want the wider product family, the sensing and risk-prediction platform is Steadicore and the cognitive and physical training side is Sanospark.

False alerts decide the project

False alerts are not a technical footnote. They are the usual reason a system gets quietly switched off. A detector that fires whenever two residents help each other up from a chair, or whenever someone lowers themselves carefully to the floor, will exhaust the patience of the night shift within a few weeks, and a switched-off system protects nobody.

Ask any vendor two questions about this. How is sensitivity tuned, and who owns that tuning after installation. The second matters more, because a system tuned to the vendor's demo room will behave differently in your corridors, in your lighting, with your residents' walking aids.

The honest target is not zero false alerts, which usually means missed events. It is a rate your staff consider tolerable, measured on your own data after the first month and adjusted with them rather than for them.