RTSM Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the randomisation engine get scoped without the supply model?

Because randomisation is the part that sounds like software and supply sounds like logistics. A statistician can describe stratified permuted blocks in a meeting, a developer can implement an allocation sequence, and everybody leaves believing the hard part is done. Inventory then gets treated as a second phase, or worse as a spreadsheet the supply lead maintains alongside.

That split creates the exact failure the category exists to prevent. An assignment is only real if a specific kit, physically present at that site, in date, from a lot released for that market, can be dispensed against it. Split the two systems and the allocation happens first and the disappointment happens second, in front of a subject.

The model that works treats one transaction as atomic. Pick the arm honouring stratification, hold the blind so nobody in the room learns anything, select an actual kit from that site's shelf, verify its expiry or retest date and its country release status, decrement inventory, evaluate whether the dispense drops the site below its trigger, and if it does raise a shipment from a depot licensed to serve that country. All of it in a few seconds while a person waits. If any step fails, the coordinator sees the constraint before the assignment rather than after. Whether randomisation may proceed with dispensing deferred is a protocol question, and the system has to encode the protocol's answer rather than leave a coordinator improvising at the bedside.

What goes wrong when you migrate study configuration and kit inventory off a vendor system?

Sponsors moving off a vendor platform underestimate this consistently, because the data looks structured and is not.

Kit inventory is the first problem. What you hold is a position, and what you need is a history: which kits were where on which date, which were quarantined and released by whom, which were destroyed and against what accountability record. Vendors export current state readily and history reluctantly, and history is precisely what an inspector asks about, since the question is never what the stock is now but what it was when subject 214 was dispensed. Ask for the historical extract in writing before you commit to a migration date, and look at a real file rather than a data dictionary.

Study configuration is the second. It exists as a validated configuration document plus whatever the vendor's build team entered, and the two are not always identical. Reconstructing intent from a configuration export is guesswork, so plan on rebuilding configuration from the protocol and the statistical analysis plan, with the old system's behaviour used to check yourself rather than as the source. Third, allocation data. It should already sit with your unblinded statistical function rather than only inside the vendor system, and if it does not, that is a finding worth acting on independently of any build.

The practical sequence is to migrate no live study. Stand the new system up, run one new protocol on it end to end, and let existing studies finish where they are. Mid study migration of a randomisation system is a risk with almost no upside.

Why do the depot, EDC and safety system integrations break after launch?

Three integrations matter and each fails in its own way.

Depots and third party logistics providers are the noisiest. Every provider has its own file format, its own cadence and its own definition of a shipment status, and files arrive late, arrive twice, or carry a status your model does not have. Build for idempotent ingestion so a resent file cannot double count stock, hold a reconciliation queue for records that do not match, and alert when a feed has not arrived rather than reading silence as nothing shipped.

Electronic data capture is the second, and the failure is subtler. Visit dates and subject status drive resupply forecasting, so a mapping that drifts after a mid study amendment quietly degrades your projections without producing an error anywhere. Reconcile subject counts between systems on a schedule and treat a mismatch as an incident.

The safety system is the third. Emergency unblinding must notify the right people and record the event without leaking treatment information to blinded roles through a notification body, an email subject line or a case narrative field. Review every automated message for what it contains, not only where it goes.

What happens when validation and emergency unblinding are treated as features?

This is regulated computerised system territory. 21 CFR Part 11 and EU Annex 11 apply, with GAMP 5 as the practical framework: a validation plan, requirements traced to executed test scripts, installation, operational and performance qualification, documented change control and periodic review. Because the system carries patient safety consequences, qualification effort in our delivery experience lands at the higher end, roughly twenty to thirty percent on top of engineering, plus user acceptance testing for each protocol before it goes live. A quote that omits that line is not cheaper, it is incomplete, and you will find out in the week your quality group first reads it.

Emergency unblinding is where the same carelessness shows up operationally. An investigator needs the treatment assignment to manage a serious adverse event, at three in the morning, on a poor connection, possibly while your primary authentication service is unavailable. This has to work without a support ticket and without a phone tree, and it must record who broke the blind, when, for which subject and on what stated reason.

Design it as the least clever thing in the build. Independent of the main authorisation flow where practical, with a documented fallback procedure issued to sites before first patient in, and rehearsed rather than demonstrated. Anyone who shows you an elegant system and has not rehearsed the code break has shown you the easy half. Test leakage deliberately as well, through exports, error messages, log files and database backups, because those are the paths that get missed when everyone is looking at the screen.

Should you build custom or configure what you already own?

Licence if you are running one pivotal study, if time to first patient in is your 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 situation is common and legitimate, and they will get you live faster than any build. Almac IXRS is a sensible choice when you already use Almac for depot and packaging services, though that coupling is exactly what some sponsors are trying to reduce.

The honest test is not feature comparison. It is whether your supply strategy has become a repeatable asset that you keep paying to rebuild. If every protocol you run genuinely differs from the last, configuration fees are the correct price for genuinely bespoke work and you should keep paying them.

Build when two or more of these hold. Per study configuration fees have become a visible budget line. Your protocols share a design family, so the same resupply parameters keep reappearing under different study numbers. Vendor change order lead times have delayed an amendment more than once. You operate your own depot network whose data you want joined to the assignment layer. Or you run platform trials or master protocols where cohorts open and close continuously, which is a pace the per study configuration model was never designed for.

How do hidden costs get into the quote?

Validation is the first, and it is the line most often left out. Ask explicitly which deliverables the developer writes, which your quality group writes, and who executes qualification. Ask whether per protocol acceptance testing is included or billed later, because it recurs for the life of the system.

Second, the number of randomisation design families. Each additional scheme is real engineering and real test scripts, and a sponsor needing minimisation as well as permuted blocks has roughly doubled a significant part of the work. Third, depot integrations, since each provider is its own project and the count is rarely known at quoting time. Fourth, interactive voice access if any sites still require it. Fifth, validated multi language site interfaces, where translation is the small part and revalidating each language is the larger one.

Sixth, the depth of the supply simulation. Monte Carlo modelling over enrolment scenarios, dropout, titration behaviour and shipping lead times is genuinely valuable and it is a distinct piece of work. If you want it to drive manufacturing decisions rather than reassure a committee, scope it deliberately and pay for it. It is also the honest home of the advanced mathematics in this category. Anyone marketing artificial intelligence randomisation is offering a risk you will not be able to explain to a regulator.

What separates a build that works from one that fails here?

The programmes that succeed implement one design family properly and run two live studies on it before widening scope. That is slower than it sounds and it is the only sequence that produces a system your quality group will keep signing. The ones that fail try to parameterise every protocol shape the sponsor has ever run, and spend eighteen months in specification while studies continue on vendor platforms.

Second, architecture has to assume there is no maintenance window. Sites across time zones enrol continuously, so configuration changes are versioned and applied by effective date, deployments are zero downtime, and any change altering allocation behaviour is reviewed and signed before it takes effect. This is where owning the system genuinely beats a vendor relationship, because the constraint on a change order is usually release queue position rather than engineering hours.

Third, blind protection has to be architectural. Separation enforced at the query layer, row level access logging, allocation data sealed by an unblinded statistician outside the operational team, and a deliberate answer to what an unhandled exception is allowed to print. Hiding a column in the interface is not a design.

Finally, settle ownership before kickoff: the repository, the infrastructure accounts and the full validation package. At Digital Heroes the client owns all of it from the first commit. The qualification evidence matters as much as the code here, because it is what lets a future partner take over without starting the whole exercise again.