Safety configuration
One person, on a screen nobody design-reviewed, changing the behaviour of every alarm for every patient in a deployment — while the clinicians affected are never told it happened. This is the highest-consequence interface in a clinical product and it is almost always the least designed one.
Overview
This system already names the clinical systems administrator as a specified user whose "errors here affect every clinician silently" — see Usability & context of use — and has admitted in writing that administration screens receive a fraction of the attention the clinical ones do. This page is that debt being paid.
The reasoning is uncomfortable and simple. A clinician making a mistake harms one patient. An administrator making a mistake in a threshold, an escalation chain or a suppression rule harms every patient the rule touches, for as long as nobody notices — and because the consequence is a change in what does not happen, nobody notices for a long time.
It does not look like one. It has forms, tables and a save button, and it is usually built by whoever had capacity. But a screen that decides which alarms reach which clinicians is making the same class of decision as the screen that displays them, at a thousand times the scale. It gets the same design rigour, the same risk controls, and the same review as any bedside screen — or the controls on the bedside screens are decorative.
Blast radius first
Before anything else, the screen states how many patients, which wards, and for how long this change would apply.
Simulated before saved
No clinical rule takes effect until it has been run against real recent data and the author has seen exactly what it would have done.
Visible at the bedside
A change is announced where its effects land, with its author and time. Configuration that only exists in a console is configuration nobody can question.
Blast radius
The single most useful thing this screen can do is refuse to let someone edit a rule without knowing its reach. Scope is stated before the fields, not discovered at the confirmation step.
Medium and low priority only. High-priority and technical alarms are never held — see Suppression.
Changed from 90%. This widens the rule.
| Part | Rule |
|---|---|
| Reach | Required, above the fields. Patient count, ward list, and the care settings explicitly excluded. A number the author has to read before they can type. |
| Draft state | Editing never touches the live rule. A console that writes to production as you type has no safe way to be interrupted. |
| Direction of change | Each edited field says whether it widens or narrows the rule. "Changed from 90%" is a fact; "this widens the rule" is the meaning. |
| Standing prohibitions | Restated inline, at the field. The administrator should not have to remember that high-priority alarms are unsuppressable — the form should say so where they are typing. |
| Save | Disabled until previewed, with the reason in the label rather than in a tooltip — see Button. |
| Provenance | Current version, author and date in force, so the person editing knows whose decision they are changing. |
Simulated before saved
A change to a clinical rule is run against a stated period of real recent data before it can be saved, and the author is shown exactly which signals it would have removed, delayed or newly raised — including any that were later acknowledged as clinically significant. Configuration reviewed only as parameters is configuration nobody has understood. "Hold for 60 seconds instead of 30" is unreadable as a risk; "this would have delayed 412 alarms, 3 of which preceded a rapid response call" is not.
- Real data, stated period. Synthetic previews test the arithmetic, not the rule. The window and the patient count are named so the author knows the strength of what they are looking at.
- Outcome-linked wherever possible. "Delayed alarms that preceded a deterioration" is the number that changes minds. It requires joining suppression data to clinical outcomes, and it is worth the engineering.
- Both directions. A narrowing change raises more alarms, which is also a safety consequence — alarm burden is a hazard, not just an annoyance.
- Never a summary alone. The affected cases are reachable individually. A count with no way to inspect it is a reassurance, not evidence.
- Preview expires. A simulation run against data from three weeks ago, saved today, is not a preview of anything. Re-run or re-approve.
Who may change what
Not every configuration change carries the same consequence, and treating them uniformly means either obstructing trivial edits or waving through catastrophic ones.
| Class | Examples | Required |
|---|---|---|
| Presentational | Ward display names, sort order of a list, density. | One authorised user. Logged. |
| Operational | Escalation chains, who is on call, contact routing. | One authorised user, preview of the resulting chain, logged and announced. |
| Clinical rule | Thresholds, hold periods, grouping windows, which priorities a rule may touch. | Preview against real data, plus a second approver. Announced at the bedside. Never effective the instant it is saved. |
| Prohibited | Suppressing high-priority or technical alarms; disabling an announced risk control; retrospective application to a firing alarm. | Not offered. These are not permissions — the capability does not exist. See Contributing. |
Two-person authorisation is expensive and it is routinely applied to the wrong things — the irreversible-looking action rather than the wide-reaching one. Deleting a ward is dramatic and recoverable from backup. Widening a suppression rule by two percentage points is undramatic and affects two hundred people continuously until someone notices. The second approver belongs where the blast radius is, not where the drama is.
Visible at the bedside
The people who experience a configuration change are not the people who made it, and in most products they are never told it happened. A ward that suddenly gets quieter is indistinguishable from a ward where the monitoring broke.
Advisory priority, in clinical language, naming both people. It is dismissible — this is information, not an alarm — but it persists in the ward's change record.
- In clinical language, not rule syntax. "Held for 60 seconds instead of 30",
never
hold_ms: 60000. - Named humans, not a service account. "Changed by system" is the signature of a change nobody will be able to explain later.
- Advisory, never an alarm hue. A configuration change is not a patient condition — see Colour.
- Persistent in the ward's record even after dismissal, so the incoming shift can find out what changed before they arrived.
- Effective at a stated time, never retroactively, and never mid-alarm. A scheduled change is visible before it takes effect.
Getting back
| Situation | Behaviour |
|---|---|
| Revert a change | One action to the previous version, from the rule's own history. Rollback is itself announced at the bedside — an unannounced reversal is a second unexplained change. |
| Emergency stop | A single control that disables all suppression and raises everything, available without the two-person process. Making the safe direction hard is how people end up leaving a bad rule running. |
| Version history | Every version readable with its author, approver, preview result and period in force. The record must answer "what were the rules at 03:40 last Tuesday" — the question an incident review actually asks. |
| Unsaved draft | Preserved and clearly marked as not in force. An administrator interrupted mid-edit must not return to ambiguity about what is live. |
| Conflicting edit | Refused, with the other author named. Two people editing alarm rules from different assumptions is a hazard, not a merge problem. |
Do's and don'ts
Reach stated before the fields. The author reads the consequence before they touch a control.
A field name, a unit nobody thinks in, and no indication that this number governs two hundred people's monitoring.
Preview: would have delayed 412 alarms, 26 of which did not self-resolve, and 3 preceded a rapid response call.
The change expressed as what it would have done to real patients. This is the sentence that stops a bad rule.
Hold period: 30 s → 60 s. Save?
A diff of parameters. Correct, complete, and impossible to assess — the reviewer has no way to know whether doubling it is safe.
Announced where the effects land, with named people. The ward can ask someone about it.
(configuration updated silently)
The ward gets quieter and nobody knows why. The most likely response is a fault report, and the second most likely is nothing at all.
Save is disabled with the reason in the label. The gate is visible rather than discovered on submit.
An optional safety step, positioned as the lesser action. It will be skipped, most often by the person most confident they do not need it.
Accessibility
- Blast radius is in the accessible name of the form region, so it is announced on entry rather than sitting as a visual banner a screen-reader user reaches last.
- Disabled Save carries its reason in the label — "Save, preview required" — not in a tooltip or a title attribute. See Button.
- Direction of change is text: "this widens the rule". Strikethrough on an old value is decorative and is not announced.
- Every field has a real
<label for>and anaria-describedbyhint carrying the standing prohibitions — see Text field. - Units are spelled out and never only in a field name.
hold_msis unreadable; "hold before raising, in seconds" is not — see International design. - Preview results are a table with scoped headers, not a chart alone. The numbers must be readable non-visually because they are the evidence.
- The bedside announcement is advisory-priority and dismissible, announced politely rather than assertively — it is not a patient condition.
- The emergency stop is reachable in one tab stop from anywhere in the console, and is never behind an overflow menu.
- Targets ≥ 24 px, readable at 320 px (SC 2.5.8, SC 1.4.10). Administration consoles are assumed to be desktop-only and are routinely used from a phone during an incident.
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 — the rule that ends up in force is the rule the author intended, and its clinical effect is one they saw before it applied to anyone. Misconfiguration rate is the measure, and it is almost never instrumented.
- Efficiency — the second approver and the mandatory preview cost real time. That cost is the point, and it is bounded to the class of change where the blast radius justifies it; applying it uniformly would train people to route around it.
- Satisfaction — an administrator who is confident they have not broken anything, and a ward that can find out what changed. Both are trust in the same object: the record of who decided what.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1).
- Blast radius stated before the fields. Mitigates: a rule edited without awareness of how many patients it governs.
- Preview against real data mandatory before save. Mitigates: a change whose clinical effect was never assessed, only its parameters.
- Outcome-linked preview. Mitigates: a statistically small harm hidden inside a large intended saving.
- Second approver for clinical rules. Mitigates: single-person error at deployment scale.
- Changes announced at the bedside with named author and approver. Mitigates: a behavioural change indistinguishable from a fault, and an unanswerable question at incident review.
- Draft state separate from live. Mitigates: partial configuration reaching production through an interrupted edit.
- Never effective retroactively or mid-alarm. Mitigates: an in-progress alarm changing behaviour under a clinician responding to it.
- One-action rollback, itself announced. Mitigates: a bad rule left running because reverting was harder than tolerating it.
- Emergency stop outside the approval process. Mitigates: the safe direction being obstructed by a control designed for the unsafe one.
- Version history answers "what were the rules at a given time". Mitigates: an incident that cannot be reconstructed.
- Prohibited changes are absent, not permissioned. Mitigates: a stated risk control being switched off by someone with sufficient rights.
- Concurrent edits refused with the other author named. Mitigates: two people composing a rule neither of them intended.
Related
- Suppression & the unraised alarm — what these rules do, and the prohibitions this screen must enforce.
- Acknowledge & escalate — escalation chains are configuration too, and carry the same blast radius.
- Clinician override — the other place this system records who decided what, and why attribution is not surveillance.
- Text field · Numeric input — the controls this console is built from, and their labelling rules.
- Tokens & governance — the same idea applied to visual decisions: a controlled characteristic needs a recorded rationale.
- QuietWard — the reference application, including the administrator as a specified user.