Reference applications
Every worked example in this system belongs to a named, fictional medical device. This page is the register of them: what each one is, who uses it, and — the reason there is more than one — which design problem it exists to surface that the others cannot.
None of the applications below exists. None is modelled on, named after, or derived from any commercial product. All patient data, values, waveforms, reference ranges and screens throughout this system are fabricated. They are illustrations of design problems, not descriptions of devices, and nothing here should be read as a claim about any real product's behaviour.
Why more than one
For most of its life this system had a single reference application, and it worked well: one coherent clinical arc, from a queue of patients to a recorded decision. The problem is what a single example quietly teaches. Four assumptions ran through every page, and none of them was ever written down as an assumption:
- The person reading the output can independently verify it. A clinician who can read the ECG.
- The software waits. A human always acts before anything happens.
- The finding concerns a single episode, not a continuous stream or a year.
- Harm is fast and visible. Everybody finds out whether the decision was right.
Assumption 1 is load-bearing in a way that is easy to miss. This system's central strategy — evidence precedes conclusion, model annotation off by default, the clinician forming their own impression first — only works because the reader can read the evidence. Hand the same output to a screening operator, a patient, or a carer at 3 a.m. and the entire anti-anchoring apparatus stops being available. It has to be replaced with something else, and that something else is a different set of patterns.
Each application below breaks at least two of them. That is the entry requirement: an example that changes only the clinical content — a different organ, a different specialty — is not a reference application, it is a change of vocabulary. It would make this system look broader without making it broader.
Necessary, not sufficient. An application is admitted when it differs on two axes and when the patterns its position makes necessary can be written as rules somebody is willing to defend — Contributing puts it as: if you cannot write the "don't", the rule is not yet clear enough to enforce. One that clears the axes but not the argument is recorded as held, with the condition that would admit it.
The axes
These are the dimensions along which the shape of the screen changes. Clinical specialty, imaging modality, risk class and rules-versus-machine-learning are all absent from this list deliberately: each changes what the software is about, and none changes what the interface has to do.
| Axis | Range | What changes when it moves |
|---|---|---|
| Verification Can the recipient check the output? |
clinician → competent but not present → non-specialist operator → lay patient → carer | Removes verification as the backstop for interface error. Invalidates more of this system than any other axis — anti-anchoring, override, and the whole clinical register of Voice & tone assume it. "Competent but not present" is a distinct position: a clinician who can read the evidence but was not there for the events being described, and so cannot tell from the text what it left out. |
| Autonomy Does it act, or wait? |
in-loop → on-the-loop → autonomous → serially autonomous | Inverts the interface's job. It stops presenting evidence for a decision and starts accounting for one already taken — which needs a vocabulary of what was withheld, what happened unattended, and how to switch it off. The far position was added for agentic work: several dependent actions where each step's output is the next step's input, so errors compound instead of being caught. Reversibility — rejected as an axis of its own — is what makes that position dangerous. |
| Time base | episode → continuous stream → longitudinal months | Introduces absence as a state — dropout, staleness, "not monitoring" as distinct from "nothing wrong" — and work that outlives the person who started it. |
| Output tractability Is the output checkable in one piece, or must it be taken apart first? |
a scalar or verdict → a bounded set of localised assertions → an unbounded composed artefact | Verification asks whether the recipient could check; this asks what it would cost them. They cross, which is what makes them separate axes — SteadyLine's recipient cannot verify a dose but the dose is a scalar against a bound, while a composed brief for a competent colleague is the opposite. At the far end, checking stops being something the reader does to the output and becomes work the interface must do before showing it: every anti-anchoring device here assumes the output is enumerable and each assertion has a locatable referent, and none of that has a subject when the output is nine paragraphs. Deliberately technology-neutral — a rules-based template stitching sentences has the same problem, and an axis named "is it a language model" would be the rules-versus-machine-learning mistake wearing a new hat. |
| Harm latency | fast and visible → silent and delayed | When nobody who used the software ever learns the outcome, there is no feedback loop. The interface has to manufacture one: recall intervals, safety-netting, a list of findings whose loop has not closed. |
The register
Seven applications in use, and one held. Each anchors the patterns its position on the axes makes necessary.
| Application | Verification | Autonomy | Time base | Harm | Tractability | Status |
|---|---|---|---|---|---|---|
| AcuteLine | Clinician | In-loop | Episode | Fast, visible | Bounded — a flag and a score | In use |
| FieldGrade | None | Autonomous | Episode + recall | Silent, delayed | Bounded — one verdict per eye | In use |
| QuietWard | Aggregate, after the fact | On-the-loop | Continuous | Silent, by omission | Mid — an aggregate review object | In use |
| ForeCall | Clinician | On-the-loop | Episode | Fast | Bounded — a queue position | In use |
| CarryForward | A different clinician each time | In-loop, over months | Longitudinal | Silent, delayed | Bounded — a measurement and a due date | In use |
| SteadyLine | None — the user is the patient | In-loop, but the loop is the patient | Continuous, unattended | Immediate, physiological | Bounded — a scalar against a limit | In use |
| NightBrief | None in practice — fluency defeats it | Serially autonomous | Episode → continuous | Silent, delayed | Unbounded composed prose | In use |
The far end of the autonomy axis — software taking a sequence of dependent acts on one authorisation, where an error at step two becomes an input at step three — has no application here and no patterns. That is a decision, not an omission.
A candidate clears the axis bar comfortably. It fails the second gate: the rules are not settled, there is no deployed practice to reason from, and writing them now would produce confident prose with nothing behind it. That is worse than a blank page, because it is a blank page that looks authoritative — and it is the same objection that kept conversational tools out until Article 14 answered it.
Status: held. The condition that would admit it is a defensible rule for how a person approves a sequence of acts that do not yet exist. No date. The candidate is left unnamed on purpose — naming it would require registering it, and registration licenses a name for use everywhere.
AcuteLine
Ingests 12-lead and continuous ECG plus high-sensitivity troponin results and flags patients with suspected acute coronary syndrome for clinician review in a hospital emergency department. Decision support: it never diagnoses, never triggers therapy, and every output is confirmed by a qualified clinician.
| Component | AcuteLine |
|---|---|
| Users | ED registrar and consultant (primary), ED nurse (acquisition), cardiology on-call (escalation), cath lab team (receives the output), systems administrator, biomedical engineer, audit reviewer. Enumerated in full on Usability & context of use. |
| Environment | Bright resuscitation bay to darkened reading room; shared workstations; gloves; 10 in carts to 4 K monitors; frequent interruption. |
| Surfaces | The in-loop clinician baseline — every other application is defined by what it does differently from this one. |
AcuteLine remains the system's primary worked example, and the full context-of-use analysis lives on Usability & context of use rather than being duplicated here.
FieldGrade
A retinal screening station in community optometry and pharmacy premises. A trained but non-clinical operator captures fundus images; the software issues "no referable disease detected" with no specialist read, and refers anything else to a human grader.
| Component | FieldGrade |
|---|---|
| Users | Screening operator (cannot grade the image); the person being screened, who receives the result; a remote grader who sees only referrals; a programme coordinator responsible for coverage and recall. |
| Environment | High-street premises, no clinical support, no IT support, appointment slots measured in minutes. |
| Surfaces | The operator's only safety judgement is about the input. They cannot assess the finding, so the design problem moves upstream to capture adequacy. Also: a result with no reader, follow-up as a UI object, wrong-site rather than wrong-patient, and delivering a result to a lay person in the room. |
| Anchors | Capture & quality gate · Autonomous result & the safety net |
QuietWard
A supervisory layer over inpatient monitoring that defers, groups or withholds non-actionable alarms. Clinicians supervise in aggregate rather than case by case; an administrator authors the rules that decide what is shown.
| Component | QuietWard |
|---|---|
| Users | Ward nurse (sees the consequences, not the decisions), charge nurse reviewing in aggregate, clinical systems administrator authoring rules, and the patient whose alarm was deferred. |
| Environment | Continuous inpatient monitoring, 24-hour operation, plus a configuration console nobody design-reviewed. |
| Surfaces | The interface for what you were not shown. Nothing in this system currently designs an unraised alarm. Also: supervision by sampling rather than case-by-case, the configuration screen whose blast radius is every patient in the deployment, and what the ward looks like when the algorithm is switched off mid-shift. |
| Anchors | Suppression & the unraised alarm · Safety configuration |
ForeCall
Detects suspected intracranial haemorrhage on non-contrast head CT and promotes the study in a radiologist's worklist. It produces no report and makes no diagnosis; its entire output is a change to somebody else's order of work.
| Component | ForeCall |
|---|---|
| Users | Reporting radiologist whose worklist is reordered, referring ED clinician who may receive the notification, radiographer at acquisition. |
| Environment | Reading room and ED, across two software systems neither of which ForeCall owns. |
| Surfaces | Software that acts on someone else's attention without asking. Saying that it reordered, naming what it is not, failing loudly when a notification never arrives, and enforcing the reading paradigm the device was validated under. |
| Anchors | Reprioritisation & notification · Reader paradigm |
ForeCall is not an image-viewing application. A CT review page beside ECG review would be substantially the same page — zoom, calibration, annotation off by default, quality flags — because imaging modality changes the viewport widget. ForeCall exists only for the part that genuinely differs: the notification.
The prohibition stands, and it needed one carve-out. What is not a viewport concern is what a spatial model output claims: an attribution overlay is not an explanation, and a model-drawn boundary is not a measurement. Those are pattern concerns — and they are written without a viewer, which is the point. The test is simply whether a rule changes when you swap the viewport widget. Window level, pan, zoom, series navigation and measurement tools all do, and a manufacturer's existing system already ships them. "This overlay is not a reason" does not; it holds identically for a highlighted ECG lead, an attention weight over text, or a genomic track.
So there is no imaging reference application either. One would sit at clinician / in-loop / episode / fast — AcuteLine's coordinates — and be rejected by the same row above that rejects a stroke-triage reviewer. The imaging work anchors to ForeCall, which already reasons about spatial marks in Reader paradigm, and to CarryForward, which is already a nodule measured over months. Anchoring rather than inventing is the honest signal that the modality was never the point.
CarryForward
Tracks incidental findings — a pulmonary nodule noted on a scan ordered for something else — whose next action is due in months, across multiple clinicians, departments and pieces of imaging equipment.
| Component | CarryForward |
|---|---|
| Users | The clinician who noticed the finding and will have rotated out before it is due; the one who inherits it; a coordinator who owns the outstanding list; the patient, who may not know a finding exists. |
| Environment | Outpatient and cross-institution, over months to years, across equipment and software versions that change underneath the record. |
| Surfaces | Work that outlives its owner. Ownership and handover of a pending item; "seen" not being the same as "actioned"; whether two measurements from different scanners belong on the same line at all; and what happens to nine thousand issued results the day the model version changes. |
| Anchors | Trend & change over time · Pending work & closing the loop · Model version change |
SteadyLine
Continuous glucose interpretation and insulin dose support for a person with type 1 diabetes, running on their own phone, unattended, around the clock, with optional following by a carer.
| Component | SteadyLine |
|---|---|
| Users | The patient — who is also the subject, the operator and sometimes cognitively impaired at the moment of use. A carer or parent following remotely on delayed data. A clinician who sees the summary weeks later. |
| Environment | Home, in bed, asleep, in a supermarket, one-handed, on a phone with a dying battery and no connectivity. No IT support. No colleague to ask. |
| Surfaces | The user is impaired at exactly the moment they need the interface most — hypoglycaemia is a cognitive impairment, and every readability and action-count rule in this system was written for a tired clinician instead. Also: an output that is an instruction to change the body rather than information to think with; designing for sensor dropout and a backgrounded app; a second person acting at a distance on stale data; and no institutional identity at all — no MRN, no badge, no shared workstation. |
| Anchors | Unattended operation · Therapy recommendation · Proxy & carer access |
NightBrief
Composes a structured handover brief for an incoming night team from a patient's fragmented record across a shift, in a hospital that owns none of the source systems. Single-turn and non-conversational, over a defined corpus; a named clinician commits every brief, and nothing reaches the record until they do.
| Component | NightBrief |
|---|---|
| Users | The outgoing clinician who commits the brief. The incoming night team, who are competent but were not present for anything it describes and cannot tell from the text what it left out. A clinician days later who reads it as though a person wrote it. |
| Environment | End of a shift, under time pressure, with twelve briefs to commit — the conditions under which "review" quietly becomes "scroll past". |
| Surfaces | An error whose signature is absence. Every other failure in this system is a wrong thing shown; here it is a right thing missing, and the surface looks identical either way. Also: fluency, which makes not-checking the path of least resistance — "evidence precedes conclusion" is unimplementable when the conclusion is a fluent text that ships its own evidence-looking layer. And authorship: the first output here that a downstream reader will attribute to a person for the rest of the patient's life. And partial acceptance, for which override's agree/disagree/cannot-assess has no form — you cannot disagree with four-fifths of a paragraph. |
| Anchors | Composed output · Authorship & the record · Editing the draft |
Candidates that were rejected
Recorded because the reasoning is reusable — these are the shapes of example that look valuable and are not.
| Candidate | Why not |
|---|---|
| A radiology stroke-triage review application | Occupies AcuteLine's coordinates exactly — clinician, hospital, episode, in-loop, fast visible harm. It changes the pixels and nothing else. |
| A dermatology lesion triage application | Changes modality only. Its real design problems — capture quality, autonomous result, lay recipient — are all carried by FieldGrade. Still rejected. |
| An ambient documentation or scribe tool | Genuinely interesting design problems, but arguably not software as a medical device. Admitting it would drag this system into a different product class. |
| A conversational triage assistant | Withdrawn — see below. The objection was that the design rules were not settled, so the pages would be inventing rules they could not defend. |
Contributing says a prohibition here is "permanent until someone brings evidence, not a preference". Two were withdrawn on evidence rather than deleted, so the reasoning stays checkable.
The conversational assistant. The objection was epistemic — the rules were not settled, so any page would assert rather than cite. The EU AI Act changed that. Article 14 specifies human oversight as a design requirement: a system must be built so a person can understand its capacity and limits, stay aware of automation bias, interpret the output correctly, decide not to use it, and intervene or stop. Article 13 requires output interpretable enough to be used appropriately, and Article 50 requires disclosure that content is AI-generated. Those are specifications, not principles — enough to write against. NightBrief carries the work, and AI transparency & human oversight holds the citations so the pattern pages can reference rather than argue.
The image viewer. Narrowed rather than reversed — see ForeCall above. A generic viewer is still not worth a page; the machine-learning layer on top of one is.
What has not changed: an ambient scribe is still out of scope, because a tool that documents an encounter without informing a clinical decision is arguably not a medical device at all, and admitting it would pull this system into a different product class. NightBrief is in scope precisely because its summaries are relied on for decisions — which is what makes software a device under MDCG 2019-11, and what makes its failures clinical rather than administrative.
Substituting your own
None of these is your device. The point of the register is not the applications — it is the method, which you are expected to repeat for the thing you are actually building.
- Place your device on the four axes above. Not on the clinical ones. If it sits where AcuteLine sits, the existing patterns transfer nearly intact.
- Write the context of use. Users, goals, resources, technical, physical and organisational environment — the structure at Usability & context of use.
- Find the assumption that breaks. Wherever your device differs on an axis, the pages written for that axis position are the ones to re-derive rather than adopt.
- Record the divergence. Where a rule here does not fit your device, that is an input to your usability engineering file, not an error to work around silently.
These names were chosen to read as fiction and to avoid resembling any product the authors are aware of. That is not the same as clearance. If you fork this system and publish it, check every application name against a trademark register first — the "not traceable to any real product" property is a claim about diligence, and diligence is not inherited.
Do's and don'ts
Place your own device on the four axes and re-derive the patterns wherever it differs from the application an example was written for.
The axes are the transferable part. A rule written for an in-loop clinician may be actively wrong for an autonomous result, and the axis is what tells you which rules to re-examine.
Adopt AcuteLine's context of use because it is the most fully worked example in the system.
Its users are ED clinicians on shared hospital workstations. If your user is a patient at home, inheriting that context imports assumptions that will not survive your first formative evaluation.
Name the application an example belongs to, on the page where the example appears.
A rule illustrated with a screen from an autonomous screening device means something different from the same rule illustrated with a clinician's worklist. The reader needs to know which.
Mix two applications' conventions inside one worked example.
A patient header on a personal device, or a shared-workstation sign-in on a home phone, teaches a combination that cannot exist and quietly invalidates the example.
Add an application to this register before using it anywhere else in the system.
Enforced in CI. check-docs.mjs reads the
data-app attributes on this page and fails the build if any page names an
application the register does not list.
Invent a plausible-sounding product name inside a demo to make a screenshot feel real.
That is exactly how a "not traceable to any real product" guarantee stops being true — one unregistered name in one example that nobody reviewed.
Related
- Usability & context of use — the method these profiles follow, worked through in full for AcuteLine.
- Status & limitations — the Fiction evidence class, and what else in this system is invented.
- Using the system — what transfers to your device and what stays your responsibility.
- Contributing — how a new application or pattern is proposed and reviewed.
- Validation roadmap — the claims each application's patterns would put up for testing.