Trial coordination console
Clinical sites miss visit windows. The system tells them weeks later.
A concept for the person nobody designs for: the site study coordinator, whose whole job is keeping patients inside a date range that lives in a spreadsheet.
- 9 screensCoordinator console
- 1 rejectedDirection, kept and shown
- WindowsNot dates, throughout
The window is the job.And it lives in a spreadsheet.
Every visit has to happen inside a date range calculated per patient: protocol day, plus or minus the allowed days, counted from that patient's own randomisation date. Miss it and the visit becomes a protocol deviation that has to be explained to the sponsor. The sponsor's system records that a visit happened. It does not compute when the next one must.
- 01
Randomisation
Day zero. The patient's whole visit schedule is counted from this date.
- 02
Window calculated
In Excel, by hand, alongside three or four other trials: each with a different sponsor, portal and login.
- 03
Visit falls due
No alert fires. Nothing in the sponsor's system knows this date exists.
- 04
No slot available
Phone and email, back and forth, while the window keeps narrowing.
- 05
Window closes
Silently. Nobody is told. The visit is now a protocol deviation.
- 06
Monitoring visit
Weeks later, this is where it gets found, and explained.
One patient, one missed window, and six steps where nothing in the system was watching.
Our first version was a dashboard.We threw it away.
Same data, opposite job. The difference is legible in the bottom-left corner of each screen: one is built for the person who oversees twenty-four sites, the other for the person who has to get through today at one of them.
The fix was not a better dashboard. It was changing whose day the product is built around, and the interface follows whoever signs the contract, which is why this was a decision and not an obvious improvement. The rejected file is kept on purpose.
Every window is calculatedfrom one patient’s own day zero.
A protocol does not schedule visits on dates. It schedules them on days counted from the moment that patient was randomised: day 84, plus or minus seven. Two patients enrolled a fortnight apart have windows a fortnight apart for the rest of the trial, and no calendar the site keeps will tell them that.
So the patient screen shows the derivation rather than the result. Randomisation date, protocol day, allowed tolerance, window opens, window closes: five lines, in the order the arithmetic actually runs. A coordinator who disagrees with a date can see exactly which input to argue with.
It is also the answer to the obvious objection. Nobody trusts a date a system produces without saying where it came from, and a product whose whole claim is "we compute the window for you" has to show its working or it will be checked by hand anyway, which would leave the spreadsheet exactly where it was.
Sometimes there is no day leftthat works.
This is the moment the product exists for. Patient 014-029 has a window that closes today, and every day still inside it is either past, has no imaging slot, or falls while the patient is away. The first workable day is three days after the window shuts.
Day 84 + 7, counted from this patient’s randomisation on 20 May 2026.
- 14 AugFirst workable dayImaging has no slot before then, and the patient is away 12–13 August.
- 3 daysOutside the windowWhich makes it a deviation whatever else is decided.
The product stops pretending there is one.
It lists every remaining day with the reason it does not work: past, no imaging, patient away, and then offers the three routes that actually exist: book late and record why, ask the medical monitor whether the assessment can be split across two days, or escalate to the sponsor for an extension, which is possible only until 23:59 today. Each carries its consequence in the same sentence. A screen that simply refused the booking would send the coordinator to the phone with no information; this one sends them with all of it.
Three decisions, andwhat each one cost.
The design bet was written first, and every screen was judged against it: move the moment of discovery earlier. Show the window while it is still open, not the deviation after it has closed.
- 01
A worklist, not a dashboard
The home screen answers one question: what must I do today. It opens on two groups only: windows closing now, and windows closing this week: each row carrying the patient, the visit, the window and the room left in it.
The trade-offA study manager gets almost nothing out of this screen. We accepted that. A screen built to serve both roles equally serves neither.
- 02
No date is ever shown alone
Every date is rendered as its window: the range, a marker for where today sits inside it, and how much room is left. A date tells you when something is due. A window tells you whether you are still safe.
The trade-offA window costs roughly three times the horizontal space of a date. The visit table caps at eight visits per view and pages beyond that.
Every date rendered as its window, across the whole site - 03
Capture the reason at the moment the rule breaks
When a booking has to fall outside the window, the reason is captured right there: category, root cause, and what happened, in the coordinator's own words. The deviation is filed from that record.
The trade-offThis puts a form in front of someone at their most rushed moment. We cut it to three fields and pre-filled two, but it is still friction, deliberately.
The reason, captured where the rule breaks Filed, with the trail attached
The other half ofthe same job.
Windows are what the coordinator is judged on. Queries and deviations are what they spend the rest of the week on, and the same rule applies to both: the record has to be made at the moment the thing happened, not reconstructed later from memory.
Queries, aged: the ones past thirty days are the ones that cost QueriesThirty-seven open, twelve of them past thirty days. Age is set in red the moment it starts to matter, because a query that has been open two months is a different problem from one raised yesterday and the list will not say so on its own.
Enough context to tell a transcription error from a real one Answering oneThe recorded value, the corrected value, and a reason for the change that the audit requires. Beside it: what else was measured at that visit, and this patient’s previous readings, so the coordinator can tell a transcription error from a real one without leaving the screen.
The register: and the one row where the reason was reconstructed Where a deviation ends upThe register the monitor reads. Every reason in it was written at the moment the decision was made: except the oldest row, which predates the console, was reconstructed weeks later at a monitoring visit, and was queried by the sponsor. That row is the argument for all of this.
Three of the nine. The console is not a window tracker with extras bolted on; the windows are simply the part that fails loudest.
The constraints that shapedevery screen.
None of these are negotiable in clinical research, and each one removed an option a cleaner design would have taken.
- Regulatory
Any change to submitted trial data needs an attributable, timestamped, permanent record. Nothing here can be silently edited.
- Legacy
The sponsor's systems own the data and are not being replaced. This concept reads from and writes to them rather than replacing them.
- Commercial
The sponsor holds the budget; the coordinator does the work. A tool designed for the site has to be paid for by someone else.
- Accessibility
Window state is never carried by colour alone. Every state also carries text and position.
We interviewed nobody.So here is what this assumes.
This is a concept, not a client engagement. Rather than dress that up, here is exactly what it is built on, and what would have to be true for it to work.
- A1
That coordinators, not sponsors, would be given a tool of their own. Commercially this is the hardest assumption, because the sponsor holds the budget.
- A2
That window arithmetic can be derived reliably from the protocol without manual configuration for every study.
- A3
That a justification captured at booking time is acceptable to sponsors and auditors as the deviation record itself.
- A4
That site staff will adopt one more system, when fewer systems is the thing they actually ask for.
A1 is the one most likely to kill it. It is listed first for that reason.
Built as a concept,in full.
Nothing here is measured. This section states what exists and what would be tested, not what was achieved.
- Problem framingConcept
- The user, and the job to be done
- Four named failure moments
- Why the existing category misses them
- The design bet, written before any screen
- Four assumptions, including the commercial one
- Product designConcept
- Eight desktop screens at 1440, plus the direction we rejected
- Today worklist, patient record and visit-window matrix
- Booking conflict, with every blocked day and its reason
- Out-of-window justification and the filed deviation
- Queries worklist, query detail and the deviation register
- What we would testHypothesis
- Missed windows per 100 visits, against the site's own previous two quarters
- Elapsed time between a window closing and the deviation being recorded
- Whether coordinators keep their spreadsheet anyway
A missed window should be visible the day it happens, not at the next monitoring visit. That is the hypothesis. It has not been tested.