Emergency and escalation

What this means

An emergency path exists in a health product wherever the product's clinical rules can flag a value, a combination of values, or an answer to a question as meaning that a person should get help now rather than at the next convenient moment. The flagged input may be a blood pressure reading in a range that warrants same-day assessment, a symptom answer inside a questionnaire, or a device alert. Which inputs carry that meaning is clinical content owned by the adopting organisation, and what the interface does once one of them is flagged is what this page governs.

Every other page in this documentation is written for restraint, asking that the interface not alarm, not over-escalate and not spend attention it will need later. This path is the single exception to every budget set by Alarm fatigue, and the requirements of the exception are owned by this page. Engagement, brand, layout, the alert budget and the reader's stated notification preferences are all overridden here, and the interface is required to be unmistakable rather than calm.

Three properties of this path bear on whether it works when it fires. Its frequency is low, so it accrues almost no exercise in production. It is difficult to test, because reaching it requires a fixture that forces a clinical rule to fire rather than ordinary use of the product. Its build order is late, after the surfaces the product ships on. A defect on the ordinary status path is measured by a product metric, and a defect here is measured by what happened to the reader.

The rule

When the product's clinical rules say a value may require emergency or same-day care, the interface enters a distinct emergency path: unmissable, unambiguous, undismissable by accident, redundant across channels, and unaffected by every other budget in this system.

flowchart TD
  A[Value arrives] --> B{Does a clinical rule<br/>flag emergency?}
  B -- No --> C[Ordinary status path<br/>steady / watch / attention]
  B -- Yes --> D{Is the value fresh<br/>and its provenance sufficient?}
  D -- No --> E[Prompt a confirming measurement<br/>Do not alarm on an estimate]
  D -- Yes --> F[Suppress every other alert on the screen]
  F --> G[Emergency surface: action first, one action, plain words]
  G --> H[Offer the region-configured emergency route]
  G --> I[Persist until explicitly acknowledged]
  I --> J[Record the acknowledgement with a timestamp]
  G --> K[Redundant channel: in-app plus push plus next open]

The eight requirements

The order below is normative and the numbering is cited elsewhere on this page. The last two columns record who carries each requirement while the components remain unbuilt, and where a fuller specification exists. An empty cell means this page is the only statement of that requirement.

Accessibility on this surface is held to a stricter bar than the rest of the system. The emergency surface is announced assertively, is reachable and operable by keyboard and by switch control, holds focus without trapping the reader with no exit, meets the contrast floor with no material translucency, and works at 200% text with no clipped sentence. The bar sits above the rest of the system on this page's own reasoning, which is not a measurement opsinjs has made: a person having a medical emergency is more likely to be using assistive settings than a reader at any other moment.

What must never happen:

• An emergency conveyed by colour, motion or sound alone.
• An emergency surface behind a paywall, a login wall, or an onboarding step.
• An emergency raised from an estimated or stale value, a case the flow above routes to a confirming measurement instead.
• An emergency that can be swiped away by accident and never returns.
• An emergency competing with any other alert on the same screen.
• A hardcoded emergency number.

Why (evidence)

Applying it

Components that implement this

The emergency surface is specified as a distinct configuration of AlertBanner and CareCard rather than as a separate component, so that it inherits the same announcement and contrast contract as every other alert and does not drift into a bespoke screen that no audit covers. That specification includes its suppression behaviour, which hides every other alert on the screen. What ships today falls short of that in one specific respect. Neither component can see a sibling, let alone silence one, so rule 4 is the caller's to implement and the caller's to test on every screen that can reach this path. Rule 4 therefore belongs in product code with a named owner rather than in an assumption that a component is holding it.

What this does not cover

• Which values are emergencies. Every threshold on this path is clinical content owned by your organisation, and it should be reviewed by someone clinically accountable, written down, and version controlled.
• Emergency service integration, dispatch, or anything that contacts a service on the reader's behalf. That is a substantial regulatory undertaking and sits outside a presentation layer.
• Mental health crisis, which needs a different tone and different routes: Crisis and self-harm.
• Clinical escalation between professionals, which is not a consumer surface.
• Legal duties. Whether the adopting organisation has a duty to act on a flagged value is a question for its clinical safety and legal teams.

Updates to this page

Last read through against the system on 2026-09-02. Due for review every 3 months; expiry is reported by pnpm run check:freshness.