Pending work & closing the loop
A finding whose next action is due in eight months will outlive the clinician who noticed it, the rotation they were on, and often the system it was recorded in. Almost all of the harm here comes from nobody doing anything — which is the one failure mode no alarm fires for.
Overview
Triage worklist is a queue of now: work that exists, is visible, and will be done this shift. This is a queue of later, and almost everything about it is different. Its items are invisible for months at a time. Its owner will have moved department before it comes due. And its failure is silent — nothing appears, nothing is dismissed, and the first sign is a patient presenting with something that was written down three years ago.
"Seen" is not a resting state. A clinician reading a finding and moving on is the most common way a loop fails to close, and most software records it as success — the result was viewed, the notification was acknowledged, the item left the inbox. Every one of those is a record that somebody's eyes passed over something, and none is a record that anybody did anything.
In this system an item is closed with a recorded reason, or open with a named owner and a due date. There is no third state.
Every finding has an owner
A named person, not a department, a rota or a queue. Ownership can be transferred; it cannot be vacant.
Due is a state
Items age. The interface shows how overdue something is as a first-class property, not as a date the reader must subtract from today.
Closure is evidenced
A loop closes because something happened and was recorded — not because the item was opened, dismissed, or reached the bottom of a list.
Anatomy
-
Pulmonary nodule · interval CT 62 days overdueA. Whitcombe · MRN 55-2287 · due 13 Jun 2026 · owner transferred from Dr S. Iyer, 2 Feb 2026
-
Incidental adrenal lesion · biochemistry 9 days overdueK. Oyelaran · MRN 55-1904 · due 5 Aug 2026
-
Thyroid nodule · repeat ultrasound due in 34 daysM. Castellanos · MRN 55-3310 · due 17 Sep 2026
Ordered by how overdue, not by when it was created. The oldest unclosed loop is the most dangerous thing on the screen, and it is at the top.
| Part | Rule |
|---|---|
| The finding | What was found and what needs to happen about it, in one line. Not the report it came from — an item nobody can act on without opening a document is an item that waits. |
| Owner | A named person. "Respiratory team" owns nothing; the ambiguity is the failure mode this pattern exists to remove. |
| Due date | Absolute date, plus how overdue it is in days. Both — a reader should never have to subtract from today, and a relative age alone goes stale on an open screen. |
| Overdue state | Escalating with time. This is one of the few places a queue may legitimately use alarm priorities, because lateness here is the clinical risk. |
| Transfer history | Who owned it before and when it moved. Ownership that changes silently is ownership nobody feels. |
| Subject | Patient name and identifier on every row — this list is inherently cross-patient. See Patient header. |
Ownership that survives a rotation
The person who notices an incidental finding is, statistically, not the person who will act on it. Junior staff rotate every few months; the finding is due in eighteen. Any design that assumes continuity of the individual has already failed.
| Event | What the system does |
|---|---|
| Finding recorded | An owner is assigned at creation — never "unassigned pending triage", which is the state items die in. |
| Owner rotates out | Transfer is required before the account is deprovisioned, and the open list is presented to them as part of leaving. Items are never orphaned onto a disabled account. |
| Owner unavailable | Escalates to a named deputy after a stated period. Not to a shared inbox — a group mailbox is where accountability goes to be diluted. |
| Transfer accepted | The new owner acknowledges receipt. An assignment nobody accepted is not a transfer. |
| Nobody available | The item escalates to the clinical lead and appears on a department-level open-loop list. It never simply stops having an owner. |
| Patient moves institution | The loop stays open until closure is evidenced somewhere, or is explicitly closed as transferred with the receiving service recorded. |
What closure means
The whole pattern rests on refusing to accept weak evidence of completion. Each of these is routinely treated as closure in real systems, and none of them is.
| Not closure | Why not |
|---|---|
| The result was viewed | Somebody's eyes passed over it. Nothing follows about what they did. |
| The notification was dismissed | Dismissal is how a busy person clears a screen. |
| A letter was generated | Generated is not sent, and sent is not received. |
| The patient did not attend | Non-attendance is the strongest possible signal that the loop is still open. |
| Time passed | Items do not expire. An overdue finding is more dangerous, not less. |
-
14 Aug 2026 · 11:02Closed — surveillance complete. Interval CT performed 9 Aug; nodule stable at 8.4 mm across 3 measurements; discharged from surveillance per local protocol.Dr R. Mensah · evidence: CT 88-5510, clinic letter 12 Aug
-
2 Feb 2026 · 09:40Ownership transferred and acceptedDr S. Iyer → Dr R. Mensah · rotation
-
12 Jul 2023 · 16:20Finding recorded · interval CT due 12 Jan 2024Dr S. Iyer · incidental on CT 88-1120, ordered for abdominal pain
Three years, two owners, one closure with a stated reason and the evidence behind it. This record is what makes the loop auditable rather than merely finished.
- Closure requires a reason from a fixed set, plus optional free text. Free text alone is unanalysable, and this list has to be countable.
- "Not clinically indicated" is a legitimate closure and must be as easy as any other. A pattern that makes closing hard produces a list nobody maintains.
- Closure is attributable and reversible. Reopening is available and recorded.
- Bulk closure does not exist. Same reasoning as bulk acknowledgement — see Acknowledge & escalate.
- The patient's non-attendance closes nothing; it opens a different action with its own owner and due date.
States
| State | Rendering |
|---|---|
| Open, not yet due | Neutral. Present in the owner's list, ordered by due date, not hidden until it matures — an item you cannot see until it is late is an item you cannot plan around. |
| Due | Advisory. Appears at the top of the owner's list on the due date. |
| Overdue | Escalating with elapsed time, with the count of days stated. Priority reflects lateness because lateness is the risk. |
| Action in progress | Scan ordered, appointment booked — visible as a distinct state so the item is not chased twice, and still open. |
| Blocked | Named blocker and owner of the blocker. "Awaiting patient response" is a state with its own due date, not a resting place. |
| Closed | Reason, evidence, author and date. Removed from the open list, retained permanently. |
Do's and don'ts
Open · owner Dr R. Mensah · due 13 Jun 2026 · 62 days overdue
A named owner, a date, and lateness as a state. Somebody can be asked about this today.
Seen · 13 Jun 2026 · respiratory team
A resting state that records only that someone looked, owned by a team rather than a person. This item will not move again.
Closed — surveillance complete.
Stable across 3 measurements; discharged per protocol.
Dr R. Mensah · evidence: CT 88-5510, clinic letter 12 Aug
A reason from a fixed set, the evidence, and an author. Countable and auditable.
Completed — letter generated 9 Aug 2026
Generated is not sent, sent is not received, and received is not acted on. Three assumptions in one word.
Dr S. Iyer is leaving on 2 Feb. 4 open findings require a new owner before the account is closed.
Transfer is part of leaving. The items cannot be stranded on a deprovisioned account.
Owner: S. Iyer (account disabled)
Four patients' findings now belong to nobody, and the list still shows an owner, so nothing looks wrong.
Did not attend 9 Aug · loop remains open · new action: contact patient, due 16 Aug, owner Dr R. Mensah
Non-attendance generates work rather than closing it. This is the population screening misses.
Closed — did not attend
The patient at highest risk of a missed finding has just been removed from the list of people being followed.
Accessibility
- Overdue is stated in days, in text, not conveyed by a colour stripe or position alone. "62 days overdue" is the fact; the stripe is reinforcement.
- Owner and due date are in the row's accessible name, so an item can be assessed without opening it.
- Patient identity on every row is announced, because this is a cross-patient list and the wrong-patient hazard is live in a way it is not on a single record.
- Alarm priorities here are legitimate — lateness is the clinical risk — but they still never travel alone; the day count carries the meaning. See Colour.
- The list states its denominator and is never filtered by default; an open-loop list that hides items defeats itself. See Filter.
- Never paginated. This is a set worked to zero — see Badge & pagination.
- Closure requires a keyboard-reachable reason control, and the reason set is a real listbox rather than free text alone — see Select.
- Targets ≥ 24 px, readable at 320 px (SC 2.5.8, SC 1.4.10). This list is reviewed on phones between clinics more than it is at a desk.
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 — findings requiring later action get it, and the ones that do not are closed with a reason someone can defend. The measure is the count and age of open loops, which is computable and almost never computed.
- Efficiency — an owner can see their whole liability in one list, ordered by how late it is. The expendable resource is administrative attention, and it should be spent on the overdue items rather than on finding them.
- Satisfaction — clinicians stop privately keeping their own lists. A personal spreadsheet of things to chase is the clearest possible evidence that the system is not trusted to hold them.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1).
- No "seen" state. Mitigates: a viewed finding recorded as a handled one.
- Named individual owner, never a team or a shared inbox. Mitigates: diffuse accountability, where everyone assumes someone else has it.
- Owner assigned at creation. Mitigates: items dying in an unassigned triage state.
- Transfer required before deprovisioning; acceptance required. Mitigates: findings orphaned on a disabled account while still appearing owned.
- Overdue rendered as an escalating state with a day count. Mitigates: lateness invisible until a patient presents.
- Closure requires a reason and evidence. Mitigates: loops closed by dismissal, by letter generation, or by the passage of time.
- Non-attendance opens work rather than closing it. Mitigates: the highest-risk patients being removed from follow-up precisely because they disengaged.
- No bulk closure. Mitigates: a backlog cleared without individual consideration.
- Blocked items carry their own owner and due date. Mitigates: "awaiting response" as a permanent resting state.
- List never filtered by default and never paginated. Mitigates: open loops existing outside the view of the person responsible for them.
- Closed items retained permanently and reopenable. Mitigates: a wrong closure becoming unrecoverable.
Related
- Triage worklist — the queue of now, and why this one needs different ordering.
- Trend & change over time — the surveillance this list keeps on schedule.
- Autonomous result — recall created at the moment of issue, the same instinct in a screening programme.
- Acknowledge & escalate — the same refusal to accept weak evidence of a human having engaged.
- Sign in / sign out — attribution, which ownership depends on.
- CarryForward — the reference application.