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 the four. 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.
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 → 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. |
| Autonomy Does it act, or wait? |
in-loop → on-the-loop → 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. |
| 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. |
| 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
Six applications, all now worked through. Each anchors the patterns that its position on the axes makes necessary, and every one of those patterns is written.
| Application | Verification | Autonomy | Time base | Harm | Status |
|---|---|---|---|---|---|
| AcuteLine | Clinician | In-loop | Episode | Fast, visible | In use |
| FieldGrade | None | Autonomous | Episode + recall | Silent, delayed | In use |
| QuietWard | Aggregate, after the fact | On-the-loop | Continuous | Silent, by omission | In use |
| Forecall | Clinician | On-the-loop | Episode | Fast | In use |
| CarryForward | A different clinician each time | In-loop, over months | Longitudinal | Silent, delayed | In use |
| SteadyLine | None — the user is the patient | In-loop, but the loop is the patient | Continuous, unattended | Immediate, physiological | In use |
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, and this system will not grow one. 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, which is a component concern, not a pattern. Forecall exists only for the part that genuinely differs: the notification.
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 |
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 without a second image viewer. |
| 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 | The design rules are not settled. This system holds itself to arguing every Reasoned claim; it would be inventing rules it cannot defend. See How to read a claim. |
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.