Why Clinical Trial Technology Often Redistributes Work, Not Reduces It
By John Oncea, Chief Editor, Clinical Tech Leader
Ask most sponsors whether their technology reduces burden on research sites, and the answer is almost always yes. Ask a coordinator, and the answer is more complicated.
“I would say what helps is a real-time hub,” says Anna Thirakul, MS, CCRP, research program leader in the spine division at Duke University, describing the platform her institution uses to track IRB approvals, budget negotiations, and contract negotiations in one place. “Any clinical research professional in your organization can go to this central place and look and see status updates before a study goes live. And once it goes live, you can continue using this hub to understand any regulatory compliance.” A single system that tracks a study from first submission through ongoing review, she says, is “really helpful for any kind of site.”
That’s the version of technology working as intended. It’s also, by Thirakul’s account, the exception rather than the rule.
Where The Burden Just Changes Address
The clearest case of redistribution rather than reduction, in Thirakul’s experience, has nothing to do with clinical research software at all. It’s the information her team needs from offices that were never built with clinical research in mind.
“A workflow challenge is tracking and understanding different offices within a large academic medical center that might not directly be involved in clinical research, but we still rely on their expertise to build things like our budget,” she says – procedure costs, hospital billing codes, the kind of data required for contract negotiations but housed outside her team’s own tracking systems. Getting it, “especially if you’re following up on email and trying to see what the status is of a certain component,” is manual, and it stays manual regardless of how sophisticated her own research systems get.
It’s a useful distinction for sponsors to sit with: a site’s technology stack can be excellent and still leave staff dependent on email follow-up with departments a sponsor has no visibility into at all.
Ten Systems, One Coordinator
Asked how many different software systems she touches on a typical day, Thirakul counted in real time: “One, two, three, four, five, six, seven, eight … 10.” Five of those, she says, were already in place when she started at Duke nearly nine years ago; the other five have rolled out since, with one now in the process of being retired as part of a broader consolidation she expects will eventually bring the total down by six systems.
The rollouts, by her account, have gone reasonably well – “It works out eventually,” she says – but not without friction. A new IRB system had to sync with Duke’s clinical trial management system shortly after she joined, and syncing issues between systems have surfaced more than once since. The timeline for retiring legacy systems is also often unclear until close to the change itself: it “will get determined, announced at a more formal date,” rather than communicated well in advance.
Why Sponsor Technology Isn’t The Usual Friction Point
Notably, Thirakul doesn’t point to sponsor-mandated platforms as the main source of added burden. Duke requires sponsors to use its institution-wide regulatory binder system, a policy she frames as a genuine efficiency win, since it lets sponsor CRAs conduct remote monitoring without a site visit. On the EDC and CTMS side, sponsors typically set expectations early, during study startup, about what platforms a site will need to use.
“I’ve noticed a lot of sponsors typically use the same sets of EDCs or imaging upload platforms,” she says. “It is not an outrageous ask … the learning curve isn’t drastic, because we’re probably most likely already using it for a different study with a different sponsor.” In other words, the redistribution problem in Thirakul’s experience isn’t sponsor technology forcing sites to learn new systems. It’s the cross-departmental, non-clinical-research information her team still has to chase down manually, no matter how many sponsor systems have been standardized.
What Genuine Burden Reduction Looks Like
Put together, Thirakul’s account suggests a fairly specific definition of technology that actually reduces burden: it consolidates information that was previously scattered, it’s synced closely enough to other systems that staff aren’t re-entering the same data twice, and its rollout timeline is communicated clearly enough that staff can plan around it. Technology that adds a new login without retiring an old one, or that requires staff to chase information through channels a system doesn’t reach, doesn’t meet that bar, no matter how capable the underlying software is.
That’s a more specific test than “does it have a dashboard” or “does it save clicks.” It’s closer to a retirement test: for every new system a sponsor or institution introduces, does something else on staff’s plate actually go away? By that measure, Thirakul’s team is partway there: five legacy systems, five additions, and one now in the queue to be retired, with more consolidation planned. The gap between ten systems today and six eventually retired is, in a sense, a running scorecard for how well Duke’s technology strategy is living up to its own goal.
For sponsors evaluating their own site-facing technology, that scorecard model may be worth borrowing: not just tracking what gets deployed, but tracking what gets retired alongside it and being honest about the gap between the two.