Blog › Assisted Living

Nurse call, escalation and who actually responds

Most alerting failures in care settings are not sensor failures. They are escalation failures — and the fixes are organisational rather than technical.

Nurse call, escalation and who actually responds

Every alerting system in a care setting eventually faces the same test: something happens at 03:40 on a Sunday, and the question is whether a competent human arrives in time. Everything else — the sensors, the dashboards, the integrations — exists only to make that more likely.

Most failures are not sensor failures. They are failures of escalation design: alerts that went to a screen nobody was watching, to a phone that was on silent, to a staff member who had left, or to everybody at once so that nobody owned it.

Separate the three kinds of alert

Bundling everything into one notification stream is the root cause of alert fatigue, and alert fatigue is the reason genuine alerts get missed. Three tiers, handled differently.

Emergency

Fire, carbon monoxide, a resident call button, a confirmed fall. These need an immediate, guaranteed, acknowledged response. In most cases they should travel over the regulated call system rather than a smart home platform, because that system is designed, certified and maintained for exactly this.

Urgent, needs a person soon

A resident out of bed for far longer than usual overnight. An apartment below a safe temperature. A water leak. A door to outside open in the small hours. These need someone tonight, but not a running response.

Informational

A sensor stopped reporting. A pattern drifting over days. Energy consumption up in a communal area. These belong in a shift handover or a weekly review, and should never interrupt anybody.

The discipline is to keep tier three out of tiers one and two. Once staff learn that a notification is probably nothing, the system has stopped working regardless of how well the sensors perform.

Alerts need an owner, not an audience

An alert sent to a group is an alert nobody has accepted. Bystander effect is not a theoretical concern in a busy building at four in the morning.

The pattern that works is assign, acknowledge, escalate. An alert goes to one named person on shift. If it is not acknowledged within a defined time, it escalates to a second person. If that is not acknowledged, it escalates again — to a duty manager, an on-call number, or an external monitoring service. Every step is logged.

Three details make this work in practice. The acknowledgement must be trivially easy, or it will not happen. The escalation timers must be short enough to matter and long enough to be achievable — two minutes is unrealistic when someone is assisting a resident. And the final step must terminate somewhere staffed twenty-four hours a day, which for a small provider usually means a monitoring service rather than a manager's mobile.

Test escalation deliberately, on a schedule, and record it. Trigger each tier on purpose at least quarterly, including overnight, and confirm the alert arrived, was acknowledged, and escalated correctly when ignored. This is the single most valuable thing in this article. Systems decay silently — staff leave, phone numbers change, an app update resets notification permissions — and an untested escalation path is an assumption, not a safeguard. Keep the test records; a regulator will ask.

The failure modes worth designing against

Do-not-disturb

Modern phones silence notifications overnight by default. A night alerting system built on ordinary push notifications may be disabled every night at exactly the hours it exists for. Use whatever critical-alert mechanism the platform offers, verify it on each device, and re-verify after operating system updates.

Staff turnover

Care has high turnover, and alert routing tied to individuals rots quickly. Route to roles — whoever holds the night duty phone — rather than to named people, and make removing a leaver's access part of the standard offboarding checklist alongside returning keys.

The device the alert depends on

If alerts arrive on a shared handset, that handset must be charged, present and audible at the start of every shift. Make it a documented handover check. It is mundane and it is the most common single point of failure.

Silence read as safety

No alerts might mean nothing happened, or might mean the hub has been offline since Thursday. Monitor the monitoring: alert if a sensor has not reported for twenty-four hours, and if the hub itself goes quiet. Send those to a maintenance stream, not to night staff.

Network and power

Put hubs, network equipment and any gateway on an uninterruptible supply, and prefer local processing so a broadband fault does not disable the building's sensing. Then confirm what actually still works with the internet unplugged — and test that too, because the answer is often less than the supplier implied.

Who is on the other end at 4am?

This question decides more than any technical choice, and small providers often discover the answer only when it is tested. Three models exist, and each has a real cost.

Waking night staff on site. The most responsive and the most expensive. If you have it, escalation is straightforward: the alert reaches the person already in the building.

Sleeping-in staff. Cheaper, and it puts an absolute requirement on the alert being loud enough to wake someone through a closed door. This is where critical-alert configuration stops being a detail and becomes the whole safeguard.

On-call at home, or an external monitoring centre. Viable, but the response time is now a journey rather than a corridor, and the escalation design has to account for it. A monitoring centre also brings trained operators and a documented log, which for a small provider is frequently better than a manager’s mobile phone.

Whichever applies, write down the realistic response time and check the alert thresholds are compatible with it. A rule that assumes someone arrives in three minutes is meaningless if the honest answer is twenty-five.

Reducing false alerts without reducing sensitivity

The temptation when alerts become annoying is to raise thresholds until they stop. That reduces genuine detection too. Better approaches:

Require corroboration. Two independent signals agreeing — a bed sensor plus a bathroom door contact, presence plus a rise in carbon dioxide — removes most false positives without dulling real ones.

Use time context. The same event means different things at eleven in the morning and four in the morning. Out of bed for thirty minutes is unremarkable in daytime.

Tune per resident. Building-wide thresholds guarantee false alerts for whoever sleeps late, and missed alerts for whoever rises at five. Individual baselines take a month to establish and are the single biggest improvement available.

Review the log monthly. Count alerts, and how many led to any action. A rule that has fired forty times and prompted nothing is training staff to ignore the system, and should be changed or removed.

What to record, and why it matters

Keep, for each alert: what triggered it, when, who was notified, when it was acknowledged, what was done, and when it closed. This serves three purposes — it demonstrates a duty of care was discharged, it lets you find rules that generate noise, and after any serious incident it is the only reliable account of what happened.

Be equally deliberate about retention. This is sensitive personal data about identifiable residents, so set a retention period, justify it, restrict access, and delete on schedule. An indefinite archive of who got up when is a liability, not an asset.

Getting from nothing to something dependable

  1. Map the response first. For each alert type: who, within how long, escalating to whom, terminating where. On paper, before configuration.
  2. Route to roles, never to individuals.
  3. Build tier two only to begin with, in one wing. Leave emergencies on the regulated system.
  4. Run a month of alerts with no changes and count how many led to action.
  5. Tune per resident, then extend to the rest of the building.
  6. Put quarterly escalation testing in the compliance calendar, overnight included, with records kept.

None of that is technically difficult. It is organisational work, which is precisely why it is usually the part that gets skipped — and precisely why it is the part that determines whether the system helps anybody.

Further reading