The 11 Commandments of IRT — A Quick Reference

1.     The IRT system is to serve only its primary purposes

 IRT exists to enroll and randomize patients, manage IMP from release through return or destruction, and provide an unblinding mechanism — full stop. Using it to collect data that belongs in the EDC or manage site adherence leads to longer timelines, additional validations, and reconciliation headaches. Design your IRT for its primary purposes only and leave the rest where it belongs.

2.     Thou shall not defer functionality

Deferring IRT features to a second or third release to hit a go-live date is a false economy — compromised quality, regulatory risk, and change control failures are well-documented consequences. The idea that IRT is the rate-limiting factor for first patient in is largely a myth. If the study is truly the most important in the company, treat it that way with quality, not just speed.

3.     Thou shall not conflate visit date and transaction date

Visit dates reflect the clinical timeline; transaction dates reflect when the IRT action occurred — and they are allowed to differ. Forcing alignment between the two generates unnecessary reconciliation work to fix a problem that isn't actually a problem. IRT manages IMP allocation for visits, not visit dates; that's EDC territory.

4.     Thou shall limit IRT-to-EDC data point integrations

The only data that needs to flow from IRT to EDC is what establishes that a participant exists, their basic identifiers, and their randomization or enrollment transaction date. Going beyond that invites the "system of record" debate and the reconciliation loop of doom. Sponsors who standardize and limit integrations gain consistency, speed, and sanity across every study they run.

5.     Thou shall think long and hard about reconciliation

Reconciliation is a heavy resource activity that, under most circumstances, should not be undertaken. If IRT is designed for its primary purposes and integrations are appropriately limited, most reconciliation simply disappears. The IRT is the natural source of truth for randomization and IMP allocation — reconciling those against another system is unnecessary and, often, illogical.

6.     The randomization schedule is sacred and shall not be modified

Randomization is a discrete moment in time that becomes part of a study's permanent record the instant it occurs — removing or adjusting it after the fact undermines the integrity of the randomization process itself. Even when errors occur, the clinical record can evolve, but the randomization record cannot. Intent-to-treat principles exist for exactly this reason.

7.     IRT providers shall not develop scripts for or perform sponsor UAT

UAT is a confirmation that the system is fit for purpose, and that accountability belongs with the sponsor — not the vendor who built it. Having the system builder test and approve their own work is the central conflict of interest, regardless of whether a CRO or third party might have biases of their own. The EMA has stated this explicitly: sponsors are expected to write their own test scripts.

8.     Thou shall protect the blind

Unblinding doesn't always come from a single obvious disclosure — shipment patterns, kit ID schemes, resupply timing, and access patterns can each leak treatment assignment, or do so in combination. IRT providers operate across both blinded and unblinded domains and carry special responsibility in system design, access control, and support processes. Sponsors must define precisely what constitutes unblinding, who is considered unblinded, and when unblinded data may be accessed or distributed.

9.     Thou shall remember the site and the patient

Sponsors are the client; sites and patients are the customers — and there is almost always a patient sitting in a clinic room while the system is being used. Once accuracy is addressed, speed and usability are what matter most to sites operating under real-world conditions. Every feature or workflow that falls outside IRT's core purposes adds friction for the people who need the system to be fast and right.

10.  Thou shall not have hard stops

Hard stops that require human intervention before a transaction can proceed almost always get overridden when a patient is physically on site — creating panic, scrambling, and manual workarounds. Systems should guide, warn, and document exceptions, but should not prevent appropriate clinical action from occurring. There is a meaningful difference between protecting protocol integrity and impeding patient care.

11.  Thou shall develop and enforce standards — until it is time to break them

Standards bring consistency, repeatability, and scalability to IRT operations, and serve as a bulwark against the "this study is different" instinct that drives unnecessary customization. But standards are a tool, not a religion — there will be situations where a unique design or operational constraint makes deliberate deviation the right call. When that time comes, the deviation should be intentional, cross-functionally agreed upon, and never casual.