RTSM and IRT Development: What Breaks When Randomisation and Drug Supply Stop Talking

Why randomisation and drug supply are one system, not two

A patient is in the chair at a site in Warsaw. The coordinator has confirmed eligibility and needs an assignment now. The system has to pick a treatment arm honouring the stratification factors, hold the blind so nobody in the room learns anything, select a specific kit from what is physically on that site's shelf, confirm that kit has not passed its expiry, decrement the site inventory, decide whether that dispense drops the site below its trigger level, and if it does, raise a shipment from a depot that is licensed to ship into Poland with product that has been released for that market. All of it in a few seconds while a person waits.

Split that into a randomisation system and an inventory system and you have created the failure mode the whole category exists to prevent: an assignment that no physical kit can satisfy. That is why RTSM is one system, and why sponsors treat it as safety-critical spend rather than tooling. A stockout at an enrolling site does not cost you a shipment. It costs you the enrollment slot, the site's confidence, and sometimes a protocol deviation.

Problem 1: the randomisation list is the most dangerous file in the company

Whatever generates the allocation, whether stratified permuted blocks, minimisation with a random element or a response-adaptive scheme, the output is a sequence that must be unpredictable to everyone at the site and reproducible for the statistician who has to defend it. Two failures matter. Predictability, where a coordinator who has seen the last four assignments can guess the fifth because the block size was fixed and small. And leakage, where an unblinded role, a log file, an error message, a report export or a database backup exposes what should not be exposed.

What a build must include: allocation generated and sealed by an unblinded statistician outside the operational team, stored encrypted with access recorded at the row level, variable block sizes where the design allows, and a hard architectural separation between blinded and unblinded views that is enforced at the query layer rather than by hiding a column in the interface. Test scripts must attempt leakage deliberately, including through exports, error messages and the audit trail itself. If your partner has not thought about what an unhandled exception prints, they are not ready for this work.

Problem 2: the resupply algorithm is protocol-specific and vendors bill for every change

Site inventory strategy sounds simple and never is. A trigger and top-up level per site sounds fine until you have a titration protocol where a subject's next visit consumes an unpredictable number of kits, a cohort escalation design where a whole arm may stop, a seasonal enrollment pattern that leaves stock sitting at sites while a new country opens with nothing, and a product with a short retest date where shipping too early wastes supply that took nine months to manufacture.

Suvoda is a strong product with a reputation for fast builds on complex protocols, and 4G Clinical markets a protocol-driven build approach specifically to shorten setup. Endpoint Clinical and Signant Health both do this work competently, and Almac IXRS is a sensible choice when you already use Almac's depot and packaging services, though that coupling is exactly what some sponsors are trying to avoid. The complaint we hear from sponsors is rarely about capability. It is about the operating model: every protocol is a configuration project with a fee, every mid-study change is a change order with a lead time, and a sponsor running fifteen similar protocols a year pays fifteen times for a design family they could describe in a paragraph.

What a custom build does: it makes the resupply policy a parameterised strategy rather than a per-study configuration. Encode the two or three design families you actually run, expose their parameters, and a new protocol becomes a configuration your own supply lead completes in a day. That is the whole financial argument, and it only works if you genuinely have a repeating design family. If every protocol you run is unlike the last one, buy.

Problem 3: expiry, retest dates and the country release map

Investigational product carries an expiry or a retest date, and both move. A retest extension is issued and suddenly kits at eleven sites are usable again, if and only if the system can relabel them logically and record who approved it. Country release adds another layer: product released for one market may not be shippable to another, import licences have validity windows, and a depot that is fine for Germany may not serve Türkiye. Getting this wrong does not just waste supply, it creates a regulatory problem.

The build needs kit-level lot identity, expiry and retest dating with an amendment history, a country and depot matrix with effective dates, and a hard rule that no assignment can select a kit the rules do not permit at that site on that date. Then temperature excursions: a shipment arrives with a logger reading out of range, the kits go to quarantine automatically, and they do not come back into available stock until a named person releases them with a documented rationale. Every one of those states needs to be visible in an audit trail, because the question at inspection is not what the stock is now, it is what it was when subject 214 was dispensed.

Problem 4: emergency unblinding at three in the morning

An investigator needs to know the treatment assignment to manage a serious adverse event. This has to work immediately, without a support ticket, without a phone tree, and it must record who broke the blind, when, for which subject and on what stated reason. It must notify the right people afterwards without notifying the blinded team of the content. And it must be tested as a scenario rather than as a feature, including at 3am when your on-call engineer is asleep and the site is on a connection that drops.

Design the unblinding path to be the least clever thing in the system. Independent of the main authorisation flow where practical, with a pre-issued fallback procedure documented for sites, and rehearsed before first patient in. Anyone who demonstrates a beautiful RTSM and has not rehearsed the code break has shown you the easy half.

Problem 5: the study is live around the clock and your change window is not

Sites in three time zones enroll continuously. You cannot take the system down on a Tuesday evening because a mid-study amendment changed a stratification factor. That constraint should drive the architecture: configuration changes must be versioned and applied by effective date, deployments must be zero-downtime, and any change that alters allocation behaviour has to be reviewable and signed before it takes effect. In our experience this is where a build genuinely beats a vendor relationship, because the constraint on a change order is rarely engineering hours, it is the vendor's release process and queue position.

One honest note on artificial intelligence in this category. The valuable maths here is simulation, not machine learning: Monte Carlo runs over enrollment scenarios, dropout, titration behaviour and shipping lead times to answer how much overage you actually need and where to hold it. That is a solved statistical problem and it should be built. A model has a narrow legitimate role in drafting a study configuration from protocol text for a human to correct, and in flagging dispensing patterns at a site that do not fit the protocol. Anyone selling you AI randomisation is selling you a risk you cannot explain to a regulator.

Validation, and why it costs what it costs

RTSM is regulated computerised system territory: 21 CFR Part 11, EU Annex 11, GAMP 5 as the framework, with a validation plan, requirements traced to executed test scripts, installation, operational and performance qualification, change control and periodic review. Because the system carries patient safety consequences, expect the qualification effort at the higher end of the range, in our experience 20 to 30 percent on top of engineering, plus per-study user acceptance testing before each protocol goes live. Budget it explicitly. A quote that omits it is not cheaper, it is incomplete.

What this costs and how long it takes

A first release with randomisation and stratification, kit assignment, site and depot inventory, trigger-based resupply, emergency unblinding and the validation package runs $130,000 to $260,000 and ships in 16 to 24 weeks, based on Digital Heroes delivery experience. A full platform adding supply simulation, expiry and retest handling, country release and import rules, excursion quarantine, drug accountability and reconciliation, a configuration library and site-facing interfaces runs $350,000 to $800,000 phased over 10 to 18 months.

What drives price up in RTSM specifically: the number of design families you must support, since each additional randomisation scheme is real work. Depot and third-party logistics integrations, because every provider's file format and cadence is its own project. Interactive voice access, if any of your sites still require it. Multi-language site interfaces with validated translations. Integration with EDC and with your safety system. And the depth of the simulation model, if you want it to drive manufacturing decisions rather than just reassure people. What keeps it down: implementing one design family properly and running two live studies on it before you widen scope.

Build versus buy, and when licensing is clearly right

Licence, and do not call us, if you are running one pivotal study, if your timeline to first patient in is the binding constraint, or if you have no unblinded statistical function and no quality group willing to own validation of a safety-critical system. Suvoda, Endpoint Clinical, 4G Clinical and Signant Health exist because that is a real and common situation, and they will get you live faster than a build will.

Build when two or more of these hold. You run enough protocols a year that per-study configuration fees have become a visible budget line. Your protocols share a design family, so the same parameters keep reappearing under different study numbers. Vendor change order lead times have delayed an amendment more than once. You have your own depot network or supply operation whose data you want joined to the assignment layer. Or you are a sponsor with a platform trial or master protocol, where cohorts open and close continuously and the vendor operating model was never designed for that pace. The tipping point is not features, it is that your supply strategy has become a repeatable asset and you are paying to rebuild it every time.

How to choose a developer for RTSM

Ask them to whiteboard how the blind is protected. A partner who has done this talks about query-layer separation, row-level access logging, what an exception message is allowed to contain, and how backups and exports are scoped. A partner who says the interface hides the column has not built a blinded system.

Ask them to walk through a dispense that fails because the only kit on the shelf expires the following week. The right answer covers what the coordinator sees, what the system does about the shipment, and whether the subject can still be randomised. Then ask them to describe emergency unblinding at 3am with the primary authentication service unavailable.

Ask which validation deliverables they write and whether they have executed qualification for a system with patient safety exposure. Confirm in writing before kickoff that you own the repository, the infrastructure accounts and the validation package, because the qualification evidence is what lets a future partner take over without starting from zero. At Digital Heroes all of that is the client's from the first commit.