Clinical Trial Tech Fails On Systems, Not Software
By John Oncea, Chief Editor, Clinical Tech Leader
Ask most people why a piece of clinical trial technology failed, and they’ll point to the tool: it was clunky, it wasn’t intuitive, the vendor overpromised. Liam Devenish, who spent roughly nine months as a sub-investigator on HIV and STI prevention trials at Wits RHI in Johannesburg before moving into health policy and economics research at the London School of Economics, sees it differently. In his experience, the tools themselves were rarely the problem; it was the system they sat inside of.
“Managing the system or the architecture of a clinical trial in practice is probably as important as the tools that you then click into that architecture,” Devenish said. It’s a distinction that reframes a lot of what gets written about clinical trial technology adoption, and it’s grounded in what he actually watched happen, day to day, at one trial site.
A Site That Ran On Six Different Systems
Devenish’s trials didn’t run on a single unified platform. They ran on a patchwork he describes candidly as “a bit of a messy system, to be honest.”
“We would request certain laboratories using certain tools, other laboratories using other tools,” he said. “We would have pharmacy requests on paper. We would record CRFs or patient data in one specific tool, but then we would randomize using a different tool. We would keep all of our regulatory documents for one company on one server. For another company, it would be another server.”
None of the individual tools were badly designed. The case report forms his site used were purpose-built for the trials they supported, and adverse event reporting followed the standard set by DAIDS, the NIH division overseeing HIV and infectious disease research, an established, widely used framework across the field. The randomization platform did what it needed to do. The problem was that nothing was built to talk to anything else. Each laboratory vendor had its own reporting format. Regulatory documents lived on separate servers depending on which sponsor owned them. There was no single system pulling the pieces together, because no single system was ever asked to.
Redundancy Isn’t A Bug – It’s The Regulation Working
It would be easy to read that fragmentation as inefficiency waiting to be solved by better software. Devenish pushes back on that framing directly, particularly when it comes to the duplication between paper and digital records that frustrates a lot of site staff.
“There’s redundancy, and I don’t see how that could be removed,” he said, “because it is just part of the regulatory environment of clinical trials that redundancy is built in for accountability and for review purposes.” Every patient record needs a single, defined source document or, as Devenish put it, “You need to have one document, which is the source document from which all others flow,” and depending on which system holds that designation, the other copy has to exist specifically as a check against it. Digitizing the process doesn’t eliminate the duplication; it just changes which copy is doing the checking.
That reframes a common complaint in clinical operations. Double data entry isn’t a workflow that technology failed to fix. It’s often a workflow technology isn’t supposed to be fixed, because redundancy is the point.
Where The Seams Actually Break
If the individual tools weren’t the failure point, where were the real gaps? Devenish is specific: at the boundaries between systems that were never designed to connect.
“Each laboratory will have their own way of reporting and communicating results,” he said. “And that rarely integrated with the platforms that we were using. And so, we would have to do manual insertion of results, which was time-consuming.” Every external vendor trial site depends on – labs, pharmacies, referral networks – introduces another interface that has to be bridged by hand, because building a permanent integration for what might be a short-term or single-trial relationship rarely makes economic sense for either side.
This is the piece that gets lost when technology vendors pitch a platform as a complete solution. A tool can be excellent at what it does and still leave a site with hours of manual reconciliation, simply because it was never the tool’s job nor the vendor’s incentive to connect to the three other systems the trial also depends on.
What “Improved Trial Operations” Really Means
Devenish’s most useful reframe may be about what success even looks like. Ask a technology vendor what their platform saves and the answer is almost always time. Ask Devenish, and he’ll tell you time isn’t really the metric that matters most.
“I don’t think I really view it as a time-saving device so much as I view it as a safety and risk reduction device,” he said of the tools he relied on for randomization and record-keeping. The value wasn’t primarily speed; it was that a well-built system, backstopped by the right redundancy, made a protocol deviation less likely. In an environment where a single deviation can jeopardize years of work and millions of dollars in trial investment, that’s a meaningfully different success criterion than “did this save the coordinator twenty minutes.”
The Real Test For New Clinical Trial Technology
Asked what technology leaders most often miss about trial sites, Devenish didn’t point to a feature gap or a UX complaint. He pointed to scale: “Just the enormous complexity. The number of processes, the degree of regulation, the stringency, and the ethical standards that have to be maintained make it a really unique environment to develop technology.”
That’s the test he’d apply to any new tool entering the space: not whether it’s well-designed in isolation, but whether it was built with an understanding of the architecture it’s being dropped into, the redundancy it has to respect, the external vendors it will need to interface with by hand or not at all, and the fact that reducing risk, not just saving time, is often the actual job. Sites don’t fail because they pick bad software. They struggle when good software gets asked to solve a systems problem on its own.