Nurse Call and Code Blue: Life-Critical Alert Design

Nurse Call and Code Blue: Life-Critical Alert Design

A life-critical alert runs on a stricter contract than telemetry. Telemetry may drop a sample, arrive late, and stay silent when nothing is wrong. An alert may do none of those. It needs bounded latency, at-least-once delivery with deduplication, an acknowledgement traced back to a human, a second path that survives the first one dying, and supervision that proves every endpoint is alive before anyone needs it.

Most IoT platforms are built on the telemetry contract and then pointed at a button. That works in the demo and fails on the one press that mattered.

What actually separates an alert from telemetry?

Six properties. Every one of them changes the code you write.

The last two rows carry the design. In telemetry, silence and health look identical, and that is acceptable. In an alert system, silence is the exact signal you cannot distinguish from disaster — a quiet ward and a dead network produce the same dashboard. Removing that ambiguity is most of the engineering work.

How fast does the system need to be?

Fast enough that it disappears inside the clinical window rather than eating it. Indonesia's Ministry of Health puts the code blue response target at 5 to 10 minutes to reach the scene (Kemenkes, 8 August 2022), and hospital accreditation is assessed on documented response times, not on estimates.

The clinical evidence sets a much tighter inner bound. In a study of 7,479 in-hospital cardiac arrests across 200 US hospitals, 18.3% of patients waited more than 2 minutes for defibrillation (Chan et al., Archives of Internal Medicine, 2009). Hospital-level rates of that delay ranged from 2.4% to 50.9%, and hospitals in the best-performing quartile had 41% higher odds of survival to discharge (OR 1.41, 95% CI 1.11–1.77). The gap was explained by process, not by hospital size or teaching status.

That is the budget you are spending. A sensible split:

Everything above the first escalation timer is engineering. Everything below it is clinical procedure, and it is not yours to invent.

Why is a button press not a phone call?

Because a call can be busy and a press cannot. Model the press as a ticket whose lifecycle is independent of any voice session. A voice session is one possible response to a ticket, not the ticket itself.

Three consequences fall out of that split, and each of them is a bug you would otherwise ship.

Nobody ever gets a busy tone. Two rooms pressing at once produce two tickets in one ordered queue. A telephony-shaped design would return "line busy" to the second patient, which in this context is a system that refuses a call for help.

The confirmation light must not lie. Two stages: a fast blink means sent, a normal blink means registered. The device is only allowed to show "registered" after the backend acknowledges the ticket. A light that turns solid on local button-press logic tells a frightened patient that help is coming when nothing left the room.

Abnormal termination reopens the ticket. If the voice session ends any way other than the backend commanding it, the ticket returns to NEW with a "dropped" flag rather than silently closing. Do not infer normality from a hangup cause code — Asterisk 20 through 22 have known cases of empty cause values, and an empty cause read as "normal" closes a live emergency.

What does at-least-once delivery really cost?

Three things people skip: an idempotent event id, an application-level acknowledgement, and a local queue that predates the network attempt.

MQTT QoS 1 means at least once, so duplicates are guaranteed, not hypothetical. Give every press a stable event id and make ingest idempotent. The part usually missed is the reply: a duplicate must be acknowledged again, with the same ticket id. Not an empty ack, not silence. The device cannot tell "you already have this" apart from "you never got this", so it will keep retrying and the patient keeps watching an unconfirmed light.

A broker PUBACK is not an acknowledgement either. It says the broker took the bytes. It says nothing about whether a ticket exists, and the backend can be dead while the broker is perfectly healthy. Only an application-level ticket-created reply is allowed to delete the local queue entry.

That local queue has to be written before the first publish attempt, in every mode — normal and degraded. The tempting design writes to a queue only after the network fails, which leaves an 8 to 10 second window between the press and the degraded-mode trigger where a brownout erases a call that was never recorded anywhere. One owner for the event lifecycle, no bypass path.

Two rules keep the queue honest:

• Full or write-failed means fail loud, never drop-oldest. The oldest entry is the longest-unanswered call — the worst possible thing to discard. Reject the new event, raise a persistent fault, show an error pattern on the device, and still fire the beep and the hardwired lamp.
• Replayed events carry their age, or admit they cannot. Store a monotonic timestamp plus a boot counter per entry. On replay, send the age so the backend can compute when the press happened. If the boot counter changed, the device rebooted, the monotonic clock reset, and the age is a lie — drop it and annotate the ticket "time unknown" instead of guessing. This is the same class of problem covered in clock drift in field systems, and in a code blue log the timestamp is the evidence.

Why does a second path matter more than a better first path?

Because the failure that hurts is the one that takes out your whole stack at once. ECRI ranked "unpreparedness for a digital darkness event" as the #2 health technology hazard for 2026 (published 21 January 2026), defining it as a sudden loss of access to electronic systems and patient information. A nurse call system with one path is a system that goes dark with everything else.

The second path should not be a cleverer version of the first. It should be dumber and physically separate.

The hardwired call line is a GPIO pulling a lamp driver. It needs no broker, no backend, no DNS, no certificate. Server down, network down, backend crash-looping: the patient presses, the unit beeps, the corridor lamp lights, and a nurse walking the ward sees which room. That is a worse experience than the full system and an enormously better one than nothing.

This is also why an in-device "emergency dial-out mode" is usually the wrong answer. If the voice server, broker, and backend share a host — and in a single-server LAN deployment they do — then the host dying takes the fallback with it. A fallback that fails with the thing it protects is not a fallback. It is complexity aimed at a narrow window that a container restart policy already closes in seconds. Same reasoning as single points of failure in business systems: the cheap dumb redundancy usually beats the clever smart one.

Who is allowed to close an alert?

Not the system, and often not the patient.

DIN VDE 0834, the German standard for nurse call systems in hospitals and care homes, is unusually explicit here: calls without speech capability can only be cancelled at the call location, and where speech is available, remote cancellation is permitted only if a speech connection was actually established (ZVEI, Call Systems according to DIN VDE 0834). Rooms that cannot be seen from the presence-detection point — bathrooms — require their own separate call cancellation.

Read that as a design rule rather than a European formality. It encodes a failure mode: a nurse opens the channel, hears nothing, and hangs up. In a bathroom, "hears nothing" is exactly what a patient collapsed on tile sounds like. So a bathroom or pull-cord call becomes its own class from day one:

• No auto-resolve when the voice session ends. The ticket moves to AWAITING_CONFIRM and the room lamp stays lit.
• Resolution only through an explicit nurse action — "room checked" — recorded with the nurse's identity and a timestamp.
• The patient cannot cancel a bathroom call at all. Only staff can.

For ordinary bedside calls, patient cancellation is fine, but design the gesture against panic. A long press of two seconds or more cancels; repeated short presses are ignored. Someone frightened will hit a button several times, and that must never cancel their own call for help.

How do you know every endpoint still works?

You supervise every leg and treat silence as a fault. UL 1069, the North American standard for hospital signaling and nurse call equipment (Edition 8, 2024), puts a hard number on it: the maximum time from a fault occurring in any communication path to the trouble signal is 90 seconds, and the trouble signal must be distinguishable from every nurse call signal.

Ninety seconds is a useful yardstick even outside a certified installation, because it rules out the common lazy design: a 60-second MQTT keepalive means the last will and testament publishes at around 90 seconds, and only then does your alarm logic start. Set the keepalive at 15 seconds and detection lands inside the window with room to spare.

A supervision matrix worth copying:

The bolded row is the one teams forget. In this architecture the nurse app never dials out — the backend originates every session — so the app's voice registration is only exercised when a call arrives. Its data socket can be perfectly healthy while its voice registration is dead, and mobile SIP stacks do lose registration in background states. Without that row, the station dashboard shows green and the app is discovered deaf at the exact moment a patient presses.

Two more supervision details that pay for themselves:

A backend liveness topic the units subscribe to. Units watching only their own broker connection cannot tell "broker alive, backend dead" from healthy. A retained heartbeat from the backend, refreshed every ten seconds, closes that gap and lets the unit switch to degraded feedback on its own.

Test mode. Drills are mandatory in most hospital SOPs, and a system with no test mode either gets drilled with real events — polluting the response time data the accreditation review depends on — or does not get drilled at all. Rarely-used emergency hardware that is never exercised is discovered broken during the emergency.

What does the nurse's shift owe this design?

More than the architecture diagrams usually admit. In a survey of 3,986 nurses across 213 hospitals, 76% reported delaying their response to alarms and 55% had encountered a situation where a patient needed urgent attention and nobody responded (Ruppel et al., BMJ Open Quality, 2023). ECRI's 2026 list names the same theme from the other direction, ranking "health technology implementations that prompt unsafe clinical workflows" as hazard #9.

An alert system that adds noise makes the ward less safe, not more. Four rules that follow:

1. Distinct sounds for distinct classes. A bathroom call and a low-battery warning must not share a tone. If everything beeps the same, everything gets treated the same, which means treated late.
2. Escalate rather than repeat. Repeating the same alarm to the same person trains them to ignore it. After the policy timeout, send it to a different person — the same escalation chain pattern used in panic button fleets, with the timers set by the hospital's code blue SOP.
3. Order the queue by priority, not only arrival. Bathroom calls above bedside calls, always visible, never hidden behind a modal.
4. Every alert has an owner. A claimed ticket shows who claimed it, so two nurses do not both walk to room 3 while room 7 waits. Make the claim atomic in the backend; two taps at the same instant must produce one winner.

The pre-signoff checklist

Before a life-critical alert system goes live, these are the things worth proving with a test rather than a diagram:

• Press the button with the network cable unplugged. Beep, local light, corridor lamp — all three still fire.
• Kill the backend but leave the broker running. Units must enter degraded mode within the supervision window, not sit there looking healthy.
• Restore the network. Every queued press replays with a correct age, and a press made across a device reboot arrives marked "time unknown" rather than with an invented timestamp.
• Send the same event id twice. One ticket, two acknowledgements, same ticket id in both.
• Cancel a bathroom call as a patient. It must be refused.
• End a bathroom voice session normally. The ticket must stay open and the lamp must stay lit.
• Force-quit the nurse station app. The answer button must go disabled and an alarm must sound within the supervision window.
• Run a drill in test mode. Nothing from that drill appears in the incident report.

None of this is exotic engineering. It is the ordinary monitoring and alerting discipline applied with the assumption that silence is never good news. The difference between a nurse call system and a sensor network is not the hardware — the board, the broker, and the protocol are the same. The difference is what you are willing to assume when nothing arrives.