Safety review checklist

What this means

This page is the operational form of the arguments made across the rest of this section: a list of binary questions run against one screen before it ships. Each line takes a yes or a no, and the record carries the name of the person who answered. Ten lettered sections cover values, ranges, status colour, trends, provenance, escalation, motion and privacy, consent and language, accessibility and governance. Twenty-two of the forty-seven items carry a → link to the page that states the rule they enforce.

The form is a binary per line rather than a score, because a score reports an aggregate and the identity of the failing item is what a reviewer needs. A "no" is either fixed before the screen ships or recorded as an accepted exception with a name and a reason against it, which is what section J requires at the close of the run.

The page is formatted to survive printing, so a review can be run on paper away from the build. Print and export states what a printed health surface still has to carry.

The rule

No screen that displays, interprets or collects health information ships without this checklist completed, dated and attributable to a person.

A. Values and numbers

• Every displayed value has its unit, visible, adjacent, and in the accessible name. → Numbers, units and precision
• Precision matches the source; no value is rendered from an unformatted float.
• The unit system is the reader's stored preference, and any conversion is labelled. → Unit systems
• Zero, absent and failed states are distinguishable from each other and none renders as a number. → Uncertainty, staleness and missing data
• Out-of-scale values are shown at magnitude, not clamped to the end of a gauge.
• Numbers that appear in a list or update in place use tabular figures.

B. Ranges and interpretation

• Any comparison against a range shows the range and names whose range it is. → Reference ranges
• The words normal, abnormal, healthy, good, bad, poor and optimal appear nowhere in a string about the reader's own result.
• Age, sex and other qualifiers are checked, and the range applies to this reader or no range is shown.
• No surface asserts a cause, a diagnosis or a prognosis.
• Any risk figure is absolute, with a population, a time window and a baseline. → Risk and statistics

C. Status and colour

• Status is one of the four levels, and its meaning matches the definition. → Clinical status semantics
• Status is carried by colour and icon and word, and this is verified in greyscale.
• No element resolves a colour from both the category and the status namespace. → The two colour axes
• Category colour does not change with the value.
• At most one urgent and at most two attention surfaces on the screen. → Alarm fatigue
• Non-clinical messages do not use the clinical status palette.

D. Trends and time

• Every value shows when it was measured, and staleness is visible without reading a caption.
• No trend is drawn below the metric's minimum window, and gaps are drawn as gaps. → Trends and change
• Direction and valence are distinguished; no coloured arrow asserts a judgement the product cannot support.
• Nothing is extrapolated or projected.

E. Provenance

• Every value's provenance class is recorded and visible in plain words. → Data provenance and device accuracy
• No estimated or self-reported value drives a clinical status on its own.
• No manufacturer accuracy claim is restated as the product's own.

F. Escalation, emergency and crisis

• The escalation ladder is respected: no rung skipped, no parallel escalation of the same fact.
• De-escalation is communicated when a value returns to steady.
• If this screen can produce an emergency finding, the emergency path is implemented in full and has been tested this release. → Emergency and escalation
• If any question here can disclose risk of self-harm, the response pathway exists, is clinically reviewed, and always leads somewhere. → Crisis and self-harm
• Any result that may distress is announced before it is shown, and ends in a route to a person. → Delivering difficult results

G. Motion, notifications and privacy

• No urgency is carried by motion, sound or haptics; nothing flashes; no clinical value animates on reveal. → Motion in health UI
• Every animation has a defined reduced-motion behaviour that preserves information.
• Any notification for this screen carries no value or diagnosis and resolves to this screen. → Notifications and off-screen alerts
• Sensitive values mask without reflow, and the app obscures its content on backgrounding. → On-screen privacy

H. Consent and language

• Anything collected here has a stated purpose, a plain-language explanation and a revocation route where the data appears. → Consent and disclosure
• Declining is possible, unpunished, and no harder than accepting.
• Every clinical term has a plain-English expansion in place.
• Copy has been read aloud, and read by someone who did not write it.

I. Accessibility

• Contrast meets the published floor in both themes, measured not assumed. → Contrast conformance
• Fully operable by keyboard, with visible focus and a sensible order.
• Screen-reader pass completed; status changes announced at the right politeness level. → Screen readers
• Legible and complete at 200% text with no clipped clinical sentence. → Text resizing and zoom
• Touch targets meet the floor with adequate separation.
• Screen is comprehensible in greyscale and under a colour-vision simulation. → Colour independence

J. Governance

• Every threshold on this screen traces to a written clinical rule with a named owner and a date.
• Any hazard identified during this review is in the hazard log. → Regulatory context
• Every "no" above is either fixed or recorded as an accepted exception with a name and a reason.
• Reviewer name and date recorded.

Why (evidence)

Applying it

Components that implement this

Some of these items will eventually be machine-checkable: the banned-word list, the two-axis rule, the presence of a unit, and the alert budget are all lint rules waiting to be written. Until those rules exist, every item here is a human question, answered by the reviewer whose name section J requires on the record.

What this does not cover

• Clinical review. This list checks the interface, and it does not assess whether your organisation's thresholds, ranges or clinical content are correct. Passing it is not clinical sign-off.
• Clinical risk management process. Hazard logs, safety cases and the clinical safety officer role belong to your organisation and are covered by Regulatory context.
• Security review, privacy impact assessment and data protection assessment. Each of the three is a separate exercise with its own record, and a completed copy of this list stands in for none of them.
• Usability testing with real users. This list checks whether a screen meets the rules, and testing checks whether a reader understood what the screen said, so neither result substitutes for the other.
• Independent component-level accessibility review. Every component in the catalogue has been audited against WCAG 2.2 AA by its own authors, in a static source pass and a rendered pass, and the findings were fixed in the same change. That work was run by the authors, so it is not an independent review, and no component has had a clinical review yet. Passing this screen checklist stands in for neither. See The audit is author-run.

Updates to this page

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