Building A Clinical Trial Tech Stack That Actually Works
By John Oncea, Chief Editor, Clinical Tech Leader
The first article in this series documented the real sources of site burden in clinical trial technology: disconnected systems, delayed documents, and manual workarounds that sponsors rarely see. The second examined the integration dilemma: when both sponsors and sites have technology in place, deciding whose platform takes precedence, and making the economics work for both sides. This article focuses on what comes next: building a tech stack that actually reduces burden, supports the diversity of sites running today’s trials, and gives sponsors the consistency they need to operate at scale.
The spoiler is this: the right stack isn’t the most feature-complete one. It’s the one built with sites rather than for them, funded appropriately, and disciplined enough to remove friction instead of adding new layers of it.
This article is the third of a three-part series based on the Clinical Tech Leader Live event, Managing The Tech Stack In Today's Trials.
The Most Expensive Mistake Is More Tools
Rosie Filling of Keenova Therapeutics was direct: the industry has to stop treating comprehensiveness as a proxy for quality. Adding more tools to a site’s workflow doesn’t reduce burden; it redistributes and often amplifies it. Sites are already managing studies for dozens of sponsors simultaneously, each with different systems, requirements, and expectations. Every new platform is another login, another training requirement, another surface for things to break.
“We need sites and participants way more than they need us,” Filling said. That’s not a rhetorical flourish; it reflects a real market dynamic. Sites with resource constraints are increasingly selective about which sponsors they work with. A sponsor whose technology creates friction is a sponsor that sites can choose not to work with. The practical consequence is that sponsors who ignore site burden risk undermining their own ability to run trials.
Joe Dustin of Dauntless eClinical Strategies argued that the solution runs in the opposite direction from more tools: fewer systems, more integration built upfront, and a willingness to subsidize site readiness when it makes business sense. Sites shouldn’t be absorbing the cost of standing up sponsor-required technology on their own.
Fix The Protocol Before Fixing The Platform
Beth Harper of the Tufts Center for the Study of Drug Development offered what may be the least glamorous – and most impactful – piece of advice in this entire conversation: fix protocol quality first. Technology can’t solve friction that originates in inconsistent, contradictory, or incomplete operational documents.
“Get your protocols accurate and consistent with all the other requirements, vendor manuals, et cetera,” Harper said. “It’s not a technology challenge. It’s a protocol inconsistency, inaccuracy challenge.” As documented in the first article in this series, it takes six weeks on average for sites to receive the final core documents they need to begin source preparation, and 86% of sites flag the final protocol as a rate-limiter to study activation. No amount of integration fixes that problem. Better planning does.
This matters because it reframes where investment should go. Sponsors who pour resources into platform integration while leaving protocol quality unaddressed are optimizing the wrong part of the system. The friction sites experience often starts upstream, before any technology is ever deployed.
Pay Sites For The Work They Actually Do
Filling identified what she called the highest-leverage, most underinvested action available to sponsors: pay sites for the work they do, including training on sponsor-required technology. Sites are currently absorbing costs – staff time, system configuration, workflow disruption – that sponsors created but haven’t accounted for in study budgets.
This isn’t an abstract call for fairness. It’s a business argument. Sites that are financially supported in standing up new capabilities are sites that can dedicate more time to recruitment, protocol execution, and participant support. Sponsors who fail to account for these costs don’t eliminate them; they transfer them to the site, where they become constraints that slow down the very trials the sponsor is trying to run.
Filling was equally direct about what sites should do when sponsors aren’t offering this support: ask. If a technology is being used across multiple studies and generates value for the sponsor, there’s a legitimate case for cost-sharing. Mid-size sponsors, at least in her experience, are more open to that conversation than sites assume. As she put it, if a site never asks, they’ll never know what might have been negotiable.
Design With Sites, Not Just For Them
Harper and Filling both returned repeatedly to the same principle: sites need to be included in technology selection, testing, and rollout, not consulted after decisions have already been made. Sponsors who design workflows based on an imaginary average site end up with systems that work well for no one.
The diversity of sites running clinical trials today is not an obstacle to be managed. It’s information. Sites have different EMR configurations, different staffing models, different participant populations, and different workflow patterns. Understanding those differences – specifically, not generically – is what makes it possible to identify where common infrastructure can work and where local flexibility has to be preserved.
“Design with them and not just for them,” Filling said. “It’s really not that hard.” The industry’s resistance to that principle isn’t technical; it’s organizational. It requires sponsors to admit uncertainty, to treat feasibility questions as genuine inquiries rather than checkboxes, and to act on what they hear. Dustin put it plainly: don’t ask if you’re not prepared to do something with the answer.
Architecture Is Already Shifting
Dustin described a longer-horizon shift that’s already underway. The industry is moving – gradually but visibly – toward a post-EDC model in which data flows into data lakes rather than being manually entered into case report forms. EDC, in this model, becomes more of a viewer and query-management interface than the primary system of record. The workflow that currently requires sites to log into EDC to manage queries, deviations, and investigator signatures would be absorbed into other systems, either the site’s own platform or a purpose-built sponsor interface.
Harper noted that the volume of data coming directly from participants – through wearables, imaging, and other direct-capture tools – is already high and rising. That trend makes the data-lake model more plausible, but it also raises important questions about how operational data, source data, and review workflows connect. Solving those questions is where the next generation of clinical technology vendors is focusing.
Dustin pointed out that newer vendors are building differently from their predecessors. API-first, interoperability-first, standards-first architectures are the baseline expectation now, not an afterthought. Legacy systems, built primarily to satisfy regulatory requirements without thinking about downstream connectivity, are increasingly a liability in a landscape that requires integration to function. The shift happening at the backend level will matter more to the next decade of clinical research than any front-end feature currently being marketed.
The Practical Path Forward
Reducing site burden in clinical trial technology doesn’t require waiting for industry-wide transformation. The actions that would have the most immediate impact are, in most cases, already within reach.
Sponsors can start by improving protocol quality, making sure the documents sites need to begin work are accurate, consistent, and delivered without the six-week lag that’s currently the norm. They can reduce the number of systems a site has to use by integrating upfront rather than requiring sites to manage the handoffs. They can ask sites specifically what technology they have, what they’ve invested in, and where integration would genuinely help versus where it would just add friction. And they can fund the parts of the process that sites are currently absorbing on their own.
Sites can advocate for themselves, proactively sharing their technology investments during feasibility, raising the cost-sharing conversation when it applies, and pushing back when a new system creates more work than it eliminates.
The theme connecting all of this, as explored across this three-article series, is communication. The tech stack problem in clinical trials is not primarily a technology problem. It’s a collaboration problem, one that better tools can support but cannot solve on their own. What it requires, more than anything else, is for sponsors and sites to stop designing around each other and start designing with each other.