IWRS: randomisation, dispensing and the problem of things you cannot undo

Allocation, pharmacy dispensing, drug accountability and administration records. Designing for actions that cannot be reversed.

A different class of feature

Most of a clinical platform handles records. If a record is wrong you correct it, the audit trail keeps both versions, and the system is still true.

Randomisation and dispensing are not like that. Once a subject is allocated, the allocation is spent. Once a kit is dispensed, it has left the pharmacy. Once a dose is administered, it is in the patient. There is no edit, there is only a deviation report.

That single property drove every decision in this module. The question was never "how do we let users fix mistakes." It was "how do we make the mistake difficult to make in the first place, and recordable when it happens anyway."

What it covers

Allocation. Randomisation schedules generated and held by the system, with allocation concealed until the moment of assignment. Simple and stratified schemes, with block structure invisible to the site so sequence cannot be predicted from recent assignments.

Pharmacy dispensing. Kit assignment against allocation, with the pharmacy seeing what they need to dispense and nothing about the arm. Stock visible per site, so a site is never allocated a subject it cannot supply.

Drug accountability. Kit lifecycle from receipt through dispensing, return and destruction, reconciled continuously rather than at close out, when discrepancies are no longer resolvable.

Administration. What was actually given, when, by whom, recorded against the subject and reconciled against what was dispensed. The gap between dispensed and administered is where accountability findings come from.

Design choices that follow from irreversibility

Confirmation is proportional to consequence. Entering a date of birth needs no confirmation. Confirming a randomisation does, and it says plainly what is about to happen and that it cannot be undone.

The system refuses rather than warns where it can. A warning is a question. A refusal is an answer. If supply at the site cannot cover the allocation, the system does not warn and allow, it blocks and tells the coordinator what to do next.

Unblinding is a designed path, not an exception. Emergency unblinding will happen. Treating it as an edge case means it gets handled by someone improvising at midnight. It is a first class workflow with its own authority model, its own record, and immediate notification, so the person who needs it can use it without hesitating and everyone who needs to know finds out at once.

Reconciliation runs continuously. Accountability discrepancies found at close out are findings. The same discrepancies found the same week are housekeeping.

The trade

A module designed this way is deliberately slower to use than one that trusts the user. Every refusal is friction, and friction at a busy site is a real cost that somebody pays in time.

I accepted that cost, consistently, because the asymmetry is not close. A few seconds of friction against a dosing error or a broken blind is not a difficult trade to make. It is only difficult to defend in the meeting where someone asks why this screen has an extra click.

Inside the platform

Inside this workflow

Real interfaces with demonstration data. Select a screen for a closer look.