Clinician override
How a clinician disagrees with the software, what the system does about it, and why making disagreement easy is a safety requirement rather than a concession.
Overview
AcuteLine is decision support. The clinician is the decision-maker, which means their disagreement is not an error condition — it is the system working. A tool that makes agreement one tap and disagreement a five-field form has not made itself safer; it has made its own performance data useless and trained its users to click through.
This pattern covers the moment of disagreement and everything downstream of it: the record, the audit trail, and the feedback into post-market surveillance.
Symmetric
Agreeing and disagreeing cost the same number of actions and carry the same visual weight. Any asymmetry biases the data the system collects about itself.
Attributable
Every override records who, when, and on what evidence. Not to police the clinician — to make the record defensible and the surveillance data real.
Non-obstructive
Disagreement never blocks care. The clinician acts first; the system records. Nothing about overriding delays the patient.
Anatomy
| Element | Rule |
|---|---|
| Three options | Agree · Disagree · Cannot assess. Identical styling — no primary variant on any of them. |
| "Cannot assess" | A first-class answer. Forcing a binary produces false agreement from clinicians who lack the information to judge. |
| Reason | Optional, one tap from a differential list. Free text is available but never required. |
| Attribution | User, timestamp and originating screen, shown before submission so the clinician knows what is being recorded. |
A mandatory justification field is the most reliable way to stop clinicians disagreeing. Under time pressure the cheapest path becomes "Agree", and the system's measured agreement rate climbs while its real-world accuracy does not. The reason list exists because most disagreements have a common cause worth capturing — but the override is recorded with or without one.
The asymmetry trap
Equal weight, equal cost. The resulting agreement rate means something.
A prominent accept and a buried, apologetic dissent. This measures how hard you made disagreement, not how often the model is right.
The record
An override produces a durable, human-readable entry. It is written once, never edited, and never deleted — a correction is a new entry referring to the previous one.
-
2026-08-13 14:26:38ECG acquired and analysed — STEMI pattern, anterior V2–V4AcuteLine model v4.2 · confidence 0.94 · trained to 2025-11
-
2026-08-13 14:27:04Alert acknowledgedS. Whitfield · Registrar · from triage worklist
-
2026-08-13 14:31:12Clinician disagreed with finding — reason: early repolarisationS. Whitfield · Registrar · from ECG review · annotation was ON
-
2026-08-13 14:33:47Serial ECG requested · repeat in 30 minS. Whitfield · Registrar
-
2026-08-13 15:06:20Assessment revised — agrees with finding (supersedes 14:31:12)A. Bergström · Consultant · from ECG review · serial change confirmed
- Append-only. The 15:06 revision does not overwrite the 14:31 entry; it supersedes it and says so. Both are permanently visible.
- Records the model, not just the answer. Version and confidence at the time of the decision, because both change.
- Records the viewing conditions. Whether annotation was on, and which screen the assessment came from. A disagreement formed before seeing the model's marks is a different data point from one formed after.
- Human-readable without a decoder. The clinician, a colleague, and an auditor two years later all read the same sentences.
When the model and clinician disagree
What must not happen is as important as what does.
| The system does | The system never does |
|---|---|
| Record the override and continue | Ask "are you sure?" — a confirmation that only ever appears on disagreement is a thumb on the scale |
| Leave the original finding visible and unaltered in the record | Delete or hide the finding the clinician rejected |
| Stop re-alerting for the same finding on the same recording | Keep re-raising an alarm a clinician has explicitly assessed |
| Continue analysing subsequent recordings normally | Suppress future alerts for that patient — the next ECG is a new question |
| Escalate on new evidence, stating what changed | Escalate on the same evidence, hoping for a different answer |
An overridden finding must not re-fire on the same recording — that is nagging, and it trains clinicians to dismiss without reading. It must re-fire when new evidence arrives, and the new alert states what changed: "Serial ECG at 15:04 shows ST elevation increased 3.1 → 4.8 mm since the assessment at 14:31." Novel evidence, not repetition.
Feeding surveillance
Overrides are the primary real-world signal about how the device performs after release, and the interface is what determines whether that signal is trustworthy.
- Agreement rate is only meaningful if disagreement is frictionless. Any change to this pattern that makes disagreement costlier invalidates the trend across the change — so the pattern is version-stamped in the data.
- Reason codes are a fixed, versioned vocabulary. Free text is captured but never silently mapped into a code.
- "Cannot assess" is reported separately from disagreement. A rising cannot-assess rate usually means degraded inputs, not a degraded model.
- Clinicians are never ranked by agreement rate, and the interface never implies it. The moment disagreement feels observed, it stops being honest.
Who holds each rule
An override is a disagreement with a model, recorded. The record is now something this package ships; the disagreement is not.
| Rule | Held by | Where |
|---|---|---|
| Append-only | Event log | There is no edit, delete or clear. An override that turns out to be wrong is corrected by a later entry that says so, and the original stands. Asserted: EventLog: no entry can be edited, removed or cleared |
| Records who overrode, and that it was a person | Event log | The actor union distinguishes a person from software structurally, with the role that permitted the action. Asserted: EventLog: every entry names an actor, and says whether it was software |
| The model's finding is not removed by the override | Event log | The overridden entry is marked as superseded and remains readable. Both the finding and the disagreement are in the record. Asserted: EventLog: a superseded entry stays, and says it was superseded |
| Records the model, not just the answer | The implementer | The model name and version are strings you put in the entry. The log renders an actor version for software entries; whether you record which model was overridden is yours — see Model version & change. |
| Records the viewing conditions | The implementer | Display, window level, zoom, and what else was on screen: none of that reaches a component. |
| Disagreeing is one action and is never harder than agreeing | The implementer | Which button is primary, and whether disagreeing opens a form that agreeing does not, is your layout. |
| An override never silently retrains anything | The implementer | Data pipeline. Entirely outside the browser. |
| The reason is free text, not a dropdown | The implementer | Textarea is the right control; using it rather than a Select is a choice you make. |
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 8 rules, 3 are held by a component this package ships, and 5 are the implementer’s. Three of eight held, all by the event log — which is to say the record of an override is now trustworthy in shape. Everything about what the override contains is yours.
Do's and don'ts
Equal weight, equal cost, and “cannot assess” as a first-class answer.
Prominent accept, buried dissent. The agreement rate now measures friction, not accuracy.
Disagree recorded 14:41 · S. Whitfield · model 4.2
the model’s finding stays visible above
The override is an entry, attributed, and the finding it overrides is still there. Both are in the record.
Disagree finding removed
The model’s finding is gone. Whether it was right, and what it said, cannot be reconstructed — and neither can the pattern of disagreements that would show the model drifting.
Accessibility
- A real radio group. The three options are
role="radiogroup"with a visible legend, not three unrelated buttons. - Selection state is not colour alone — the pressed option carries a
thicker border and
aria-pressed. - Reason chips are toggle buttons with
aria-pressed, reachable and operable by keyboard in one tab stop plus arrow keys. - The audit trail is an ordered list, chronological in DOM order, with timestamps as readable text rather than relative phrasing like "4 minutes ago".
- Confirmation is announced politely after recording, and the recorded entry is reachable without navigating away.
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 assessment recorded matches what the clinician actually believes — which requires that disagreeing is as easy as agreeing.
- Efficiency — Actions required to disagree must equal actions required to agree. Any asymmetry is measured by the system as model accuracy when it is really interface friction.
- Satisfaction — A sense of agency over the tool rather than supervision by it. A clinician who feels their agreement rate is being watched stops producing honest data.
Clinical safety notes
Trace these in your risk file (ISO 14971), usability engineering file (IEC 62366-1) and post-market surveillance plan. 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.
- Symmetric agree/disagree, no primary styling. (design review; no test can see it) Mitigates: automation bias, and post-market data that measures interface friction rather than model accuracy.
- Reason optional. (a test in your verification file) Mitigates: suppressed disagreement under time pressure.
- "Cannot assess" available. (a test in your verification file) Mitigates: false agreement from clinicians without sufficient information.
- No confirmation prompt on disagreement only. (a test in your verification file) Mitigates: an asymmetric friction that biases the record.
- Append-only audit, corrections supersede. (held by Event log) Mitigates: an unreconstructable decision history at incident review.
- Viewing conditions recorded. (a test in your verification file) Mitigates: conflating impressions formed before and after seeing model annotation.
- No re-alert on the same evidence; mandatory re-alert on new evidence. (a test in your verification file) Mitigates: alarm fatigue in one direction, missed deterioration in the other.
- Override never delays care. (a test in your verification file) Mitigates: a documentation step sitting between a clinician and a time-critical action.
- No clinician-level agreement ranking. (design review; no test can see it) Mitigates: observation pressure corrupting the surveillance signal.
Related
- Confidence disclosure — the score being agreed or disputed.
- ECG review — where most overrides originate.
- Patient header — the identity every entry is bound to.
- Button — why none of these three is primary.