The Real Reason Clinical Trial Systems Don't Talk To Each Other

By John Oncea, Chief Editor, Clinical Tech Leader

Ask anyone in clinical research whether trial technology should be interoperable, and you’ll get the same answer every time: of course it should. Sponsors want it. Sites want it. Patients would benefit from it. So why, after more than a decade of talk, are sites still logging into a dozen or more disconnected systems to run a single study?

I put that question to two people with very different vantage points on the problem: Elisa Cascade, an industry veteran and advisor who has spent years inside sponsor and technology organizations, and David Vulcano, CEO of the Association of Clinical Research Professionals (ACRP) and a 27-year veteran of the site side of the business. Their answers converged on an uncomfortable conclusion: this was never really a technology problem. It’s an economics problem, and the industry has been treating the symptom instead of the cause.

An Industry Everyone Agrees Is Broken

Cascade described the scale of the issue bluntly. Large academic medical centers can have 800 to 1,000 studies running simultaneously, working across more than 100 different sponsors – each with its own systems, its own data definitions, and its own workflows. A site can’t realistically run a different process for every sponsor it works with. It has to operate in its own context and then push that data downstream into whatever system each sponsor happens to use.

The result is what Cascade calls a “one-to-many problem.” A site might run five internal systems. Multiply that by the number of sponsor systems it has to feed, and you get exactly the kind of tangle Cascade has seen firsthand: in one case, a single site needed to log into 22 separate systems just to run its studies. That’s not a training issue or a culture issue. That’s an architecture that was never designed to talk to other systems.

It’s Not The Technology

Vulcano pushed back on the instinct to blame the software in-and-of-itself. “I don’t know that I would necessarily call it a tech problem, because I believe the technology is there to do it,” he told me. The capability to exchange data exists. What doesn’t exist is the incentive to build it.

His explanation is straightforward: if a vendor’s system doesn’t talk to a competitor’s system, that vendor has more leverage to sell you their entire platform instead of just one product. Openness is a competitive disadvantage unless customers demand otherwise, and for the most part, they haven’t. Sponsors have historically been sold on the dashboard, not on whether the underlying data moves freely between systems. “That doesn’t seem to be prioritized,” Vulcano said.

He compared the situation to what he wishes existed: an “iOS for clinical trials.” A common operating layer, the way a phone user can move seamlessly from Yelp to OpenTable to a calendar app to Uber without thinking about it. Nothing like that exists in clinical research, he said, and he’s not convinced anyone can build it from scratch. AI can lower the cost of connecting two systems, he added, but it doesn’t remove the underlying requirement: both sides still have to be “ready, willing, and able” to pitch and catch data in a format the other can use. AI doesn’t change who pays for that capability, or why they would.

A Cautionary Tale From Nashville

Vulcano offered a case study that illustrates exactly how hard this is to solve through goodwill alone. Roughly 15 years ago, a group of major hospital CEOs, frustrated that medical devices and other technology couldn’t talk to their EMRs, pledged to stop buying non-interoperable technology. They funded a nonprofit lab, the Center for Medical Interoperability, based in Nashville, where vendors could get their products certified as interoperable.

It never reached meaningful scale. “The center did a lot of great work, but none of the customers really held themselves to their pledges,” Vulcano said. Without enforcement, there was no real incentive for vendors to prioritize openness over their own roadmaps, the same dynamic that’s holding back clinical trial technology today.

Why Nobody Wants To Go First

Cascade pointed to a second obstacle layered on top of the incentive problem: the cost of switching. Many trial technology systems are 10, 15, even 20 years old, and they’re woven into a site’s or sponsor’s other systems – finance, HR, document management, data capture – “like spaghetti,” she said. Pulling one out and replacing it means absorbing enormous change-management pain, and nobody wants to be the first to make that bet.

There’s also a regulatory dimension unique to this industry. Many key systems used in a clinical trial have to meet regulatory validation requirements – documented requirements, use cases, acceptance criteria, and testing methodologies before it can be trusted with regulatory-quality data. That validation burden raises the cost of building and rebuilding systems well beyond what a typical software company faces, which makes replatforming an even harder financial call.

What Would Actually Move The Needle

Vulcano sees a precedent in how the broader healthcare industry solved a similar problem. The Office of the National Coordinator for Health IT (ONC) used a mix of incentives and penalties to push EMRs toward interoperability: hospitals that certified their systems received additional Medicare payments; those that didn’t eventually faced penalties. He pointed to newer efforts, like Operation Trialblazer, as a sign the government could eventually apply similar leverage to clinical trial matching and data exchange.

Absent that kind of intervention, Vulcano expects market forces to sort it out – slowly. “The people that do it well are going to be the differentiators,” he said. “Their products are going to be sticky, and the people that don’t do it are just going to fall out by the wayside.” He’s not worried about a shortage of data standards, either. Frameworks like FHIR and CDISC already exist. “There’s enough standards out there,” he said. “It’s just challenging people to get them adopted and open up their systems for interoperability.”

Where This Leaves The Industry

Neither Cascade nor Vulcano sees interoperability as a problem the industry lacks the tools to solve. What’s missing is a forcing function – a customer, a regulator, or a competitive threat significant enough to make openness worth the switching cost. Until then, the sites absorbing that dysfunction every day will keep logging into system after system, entering the same data more than once, and waiting for the economics to catch up with the technology.

That daily cost to sites, and why it’s driven by duplication rather than the technology itself, is the subject of a companion piece: Duplicate Tech, Not Technology, Is Burning Out Trial Sites (coming September 3).