Acknowledge & escalate
The full lifecycle of an alarm, from the moment it fires to the moment it is permanently resolved — including every way it can be silenced, and the ways it must not be.
Overview
The Alert Banner specifies what an alarm looks like. This pattern specifies what it does over time: how it is acknowledged, when it comes back, when it escalates to someone else, and how it ends.
That lifecycle is where alarm safety is actually won or lost. Two failure modes sit at opposite ends and both are lethal: an alarm that nags until clinicians ignore the whole class, and an alarm that goes quiet while the patient is still deteriorating.
Answerable
Every alarm can be acknowledged in one action, from wherever it is seen. An alarm a clinician cannot answer is an alarm they learn to tune out.
Never silently ending
An alarm leaves the screen for exactly two reasons: a clinician answered it, or the condition resolved and that resolution was shown. Nothing else.
Escalating on evidence
Time alone escalates to a person. New clinical evidence escalates the alarm itself. The two are different mechanisms and are never conflated.
The lifecycle
| State | Visual | Audio | Exits to |
|---|---|---|---|
| Active | Full priority chroma | Priority tone | Acknowledged, Resolved, Escalated |
| Acknowledged (timed) | Chroma drops to rail; countdown visible | Silent | Re-asserted, Resolved |
| Acknowledged (indefinite) | Chroma drops to rail | Silent | Resolved, Escalated on new evidence |
| Re-asserted | Full chroma returns | Priority tone returns | Acknowledged, Resolved, Escalated |
| Latched | Full chroma retained | Silent after first cycle | Resolved once acknowledged |
| Escalated | Full chroma; recipient named | Priority tone | Acknowledged by the escalation recipient |
| Resolved | Removed or replaced by confirmation | Silent | Terminal — persists in the event log |
Acknowledging
Acknowledgement means "a qualified person has seen this." It does not mean the problem is solved, and the interface must never let those two blur.
Pause the audio and read the state line. The alarm is quieter and it is still unanswered — the two are different facts and the interface refuses to conflate them. Acknowledging does not end the alarm either: it latches until the condition resolves, which is why acknowledging and escalating both leave it active.
| Mode | Window | Use | Available at |
|---|---|---|---|
| Timed | Documented per alarm class; 10 min default for Critical | Default for Critical — the clinician is acting, not dismissing | Critical, Urgent |
| Indefinite | Until the condition resolves | The clinician has assessed and a plan is in place | Urgent, Advisory |
| Audio pause | Fixed, documented, non-extendable | Managing noise during a procedure or conversation | All — visual signal unaffected |
Pausing audio silences the tone and changes nothing else. The banner keeps full chroma, the alarm keeps its state, and a separate indicator shows audio is paused with the time remaining. Pause is time-boxed, cannot be extended indefinitely, and never applies to a class of alarms — only the one in front of the clinician.
Audio off, visual signal at full strength, remaining pause stated.
A global, open-ended mute that also drains the visual signal. The patient is still having a STEMI and the screen no longer says so.
Escalating
Two mechanisms, deliberately separate:
Time-based — escalates to a person
The alarm has not been answered within its window. The finding has not changed; the audience has. The alarm names who it has gone to, so the original recipient knows help is coming and the new recipient knows why they were called.
Evidence-based — escalates the alarm
New data has changed the clinical picture. This is the only mechanism permitted to re-raise an alarm a clinician has already assessed, and it must state what changed. See Clinician override.
- Escalation windows are configured per deployment, not per user. A clinician cannot lengthen their own window.
- Escalation is announced to the original recipient, not done silently behind them.
- A Critical alarm never escalates into nothing. If no recipient is reachable, that failure is itself an alarm.
- Escalation never restarts the clock on the original alarm. Elapsed time is measured from first fire, always.
What must never happen
| Never | Why |
|---|---|
| Auto-dismiss on a timer | An alarm that disappears unseen is indistinguishable from one that never fired. |
| Dismiss on navigation or page change | Moving to another screen is not an assessment. |
| Bulk "acknowledge all" | Guarantees at least one alarm is answered without being read. |
| Acknowledge from a notification the alarm text is not fully visible in | Answering something you have not read is not acknowledgement. |
| Silence a whole alarm class or an entire session | Removes the signal for patients nobody has assessed. |
| Escalate on the same evidence, repeatedly | Nagging. Trains clinicians to dismiss the class without reading. |
| Let a clinician disable an alarm class from within a clinical screen | Alarm configuration is an administrative act with its own authority and audit. |
Every request for a bulk-acknowledge control is really a report that the system is over-alerting. The correct response is to fix the alarm burden — tune thresholds, coalesce duplicates, demote inflated priorities — never to add a control whose purpose is to answer alarms without reading them. Coalescing identical findings on the same patient is permitted and is a different mechanism entirely.
Alarm burden
Alarm fatigue is a system property, not a user failing. A product built on this system is expected to measure and publish its own burden.
Everything here concerns an alarm that fired. Software that reduces burden by deciding some alarms should never fire at all is making a different decision, with a different failure mode — one that announces itself to nobody. That is designed in Suppression & the unraised alarm, which starts from the position argued here and asks how the silence is held to account.
- Alarms per clinician per hour, by priority. A rising Critical rate with a flat true-positive rate is the definition of the problem.
- Time to acknowledge, by priority. Rising time usually precedes disengagement.
- Acknowledge-without-open rate — alarms answered without the evidence ever being viewed. This is the single most sensitive early indicator of fatigue.
- Escalation rate, split into time-based and evidence-based.
- Override rate — see Clinician override.
Who holds each rule
Most of what makes acknowledgement safe is timing, and timing lives in the alarm system, not in anything that renders. The component holds the shape of an acknowledgement; the implementer holds its consequences.
| Rule | Held by | Where |
|---|---|---|
| No auto-dismiss, ever | Alert banner | An alarm condition renders with no dismiss control at all. Acknowledging is the only action, and it is not the same thing. Asserted: AlertBanner: there is no dismiss control at any priority |
| Acknowledgement records who and when | Alert banner | acknowledgedBy takes a name and a time and renders both, and the control disappears once used.Asserted: AlertBanner: acknowledged state names the person, and the control goes |
| State change is announced | Alert banner | A critical or urgent condition is an assertive live region; an advisory is polite. Asserted: AlertBanner: an alarm condition is an assertive live region |
| Audio is never the sole channel | Alert banner | The visual signal always carries the priority in words. Audio is not emitted by this package at all, so it cannot be the sole channel here — see the rows below for what that leaves you. Asserted: AlertBanner: priority is in text, not only in colour |
| Acknowledgement is terminal and persists | Event log | The record has no edit, delete or clear. An acknowledgement made in error is corrected by a later entry that says so, and both stand. Asserted: EventLog: no entry can be edited, removed or cleared |
| Timed acknowledgement by default at Critical | The implementer | A timer. The banner has none; onAcknowledge tells you it happened and nothing here re-asserts. |
| Latching | The implementer | Whether a condition that has cleared still needs acknowledging is alarm-system state the renderer does not hold. |
| No bulk acknowledge, no class-wide silencing | The implementer | Prohibited system-wide and expressible as an ordinary button. Nothing in the package can stop you writing one; the prohibition is in what is not accepted. |
| Time escalation to a person; evidence escalation to the alarm | The implementer | Routing logic. Which of those a given change of state triggers is a decision your alarm system makes. |
| Unreachable escalation recipient is itself an alarm | The implementer | Detecting that a page went unanswered, and raising a new condition because of it, is the alarm system's. |
| A Critical alarm never escalates into nothing | The implementer | The terminal recipient of an escalation chain is a deployment fact; the renderer cannot know whether one exists. |
| Escalation never restarts the clock on the original alarm | The implementer | Two timers, and the discipline of not resetting one when the other starts. |
| Re-assertion does not steal focus | The implementer | A re-asserted alarm is a new render of the banner. Whether your application moves focus to it is your routing; the banner does not. |
| Countdowns are text | The implementer | There is no countdown component here. If you build one, the rule is that it is announced as text at intervals, not as a spinning ring. |
| Escalation windows are configured per deployment, not per user | Deployment configuration | Set once for the site, under the controls in Safety configuration. |
| Burden is measured and published | The implementer | Alarms per clinician per hour, time to acknowledge, acknowledge-without-open rate: none of these can be measured from inside a component. They are your telemetry. |
A pattern page has no component underneath it, so a rule stated here is held by whoever builds against it unless a component already holds it. Of these 16 rules, 5 are held by a component this package ships, 1 are deployment configuration, and 10 are the implementer’s. The three rules IEC 60601-1-8 actually turns on — re-assertion, escalation and rate — are all on the implementer’s side. This page renders acknowledgement correctly; it does not make an alarm system safe.
Do's and don'ts
Audio off, visual signal at full strength, remaining pause stated.
A global, open-ended mute that also drains the visual signal. The patient is still having a STEMI.
Re-alerts on new evidence, and says what changed.
The same finding on the same recording, fired eleven times. This is how a clinician learns to dismiss red.
Accessibility
- Acknowledgement is a single, keyboard-reachable action with a documented shortcut that jumps to the highest-priority unacknowledged alarm.
- State change is announced. Moving to acknowledged, re-asserted or escalated updates a live region — the chroma change alone is invisible to a screen-reader user.
- Countdowns are text and readable at any moment, not an animated ring with no accessible value.
- Audio is never the sole channel. Every audible alarm has an equivalent visual state, for hearing-impaired clinicians and for noisy environments.
- Re-assertion does not steal focus, but does move to the top of the reading order and announce.
Outcomes of use
What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.
- Effectiveness — Every alarm reaches a qualified person who assesses it, and none ends unseen. Latching and escalation exist for the tail of this distribution.
- Efficiency — Alarms per clinician-hour and time to acknowledge by priority. Acknowledge-without-open rate is the earliest measurable sign that efficiency has been bought with disengagement.
- Satisfaction — Alarm fatigue is a satisfaction failure before it becomes a safety one. This pattern is where a product's credibility with its users is spent or preserved.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1). Each bullet says what checks it: a component that holds the rule, a test in your verification file, deployment configuration, post-market surveillance, or a design review where no test can see it. A control checked by nothing is a sentence.
- No auto-dismiss, ever. (held by Alert banner) Mitigates: an unseen alarm on an unattended display.
- Timed acknowledgement by default at Critical. (a test in your verification file) Mitigates: a one-tap dismissal ending an alarm for a patient who is still deteriorating.
- Audio pause never alters the visual signal. (a test in your verification file) Mitigates: noise management silently removing the clinical signal.
- Latching. (a test in your verification file) Mitigates: a transient but significant event clearing before anyone saw it.
- No bulk acknowledge, no class-wide silencing. (a test in your verification file) Mitigates: alarms answered unread; whole populations losing coverage.
- Time escalation to a person; evidence escalation to the alarm. (a test in your verification file) Mitigates: an unanswered alarm dying quietly, and nagging on unchanged evidence.
- Unreachable escalation recipient is itself an alarm. (a test in your verification file) Mitigates: silent failure of the escalation chain.
- Burden is measured and published. (post-market surveillance) Mitigates: alarm fatigue developing undetected between releases.
Related
- Event log — where an acknowledgement persists, which is what makes it terminal.
- Alert Banner — the component this lifecycle drives.
- Clinician override — evidence-based re-alerting.
- Triage worklist — where unacknowledged alarms accumulate.
- Sign in / sign out — who an alarm is attributed to.
- Touch & gestures — why no gesture may acknowledge, and what a deliberate operator action has to be.