Inside A Sponsor-Site Relationship That Actually Worked

By John Oncea, Chief Editor, Clinical Tech Leader

The friction between sponsors and trial sites is one of the most reliably told stories in clinical research: sponsors build tools and set requirements around their own priorities; sites absorb the consequences. Liam Devenish’s account of the two international trials he supported as a sub-investigator at Wits RHI in Johannesburg doesn’t fit that story. His site had a governance structure – not luck – that made the relationship function. It’s a case study worth examining precisely because it’s the exception.

A Trial Site Built On Attention To Detail

Devenish’s site wasn’t unusually well-resourced or unusually lucky with its sponsors. What set it apart, in his telling, was the caliber of leadership running it. “The clinical leaders or the protocol leaders were extremely experienced and also had a definite knack for attention to detail,” he said. “It was something that I struggled with at the beginning, not because I thought it was ridiculous, but because I couldn’t quite believe the level of detail that was required in thinking or the granularity with which decisions were made.”

That granularity showed up as structure, not just vigilance. The site ran on a fixed reporting cadence. “We would have weekly meetings where we would have a specific report that we would go through with the entire team that was the same every week with updates,” said Devenish. “Biweekly, we would have a meeting with seniors where we would have a specific report that we would go through with specific things.” SOPs covered the operation down to communication channels: “How you communicate with trial participants via SMS to how you develop an online case report form to how you deal with this type of protocol deviation,” as Devenish put it.

Why Escalation Had A Clear Path

The mechanism that mattered most for the sponsor relationship specifically was a defined, two-tier escalation process. When the site identified a problem with a tool or a case report form, the response wasn’t ad hoc.

“We could raise something and say, ‘We have a particular issue with this case report form or this platform. It’s not fit for purpose for this reason. We think it’s going to lead to this type of risk and therefore protocol deviation, and we think it needs to be fixed in this way,’” Devenish said. “If it was a simple issue, it would be fixed immediately according to our recommendation. If it was a more complicated issue, it would be escalated to the protocol development team.”

That’s a meaningfully different dynamic than a site raising a concern and waiting to hear whether the sponsor agrees it’s worth acting on. The site’s technical judgment on straightforward fixes was treated as sufficient on its own; only genuinely complex issues required sponsor-side sign-off. The distinction kept small problems from turning into bigger ones.

The Co-Chair Model That Balanced Power

Underlying that escalation path was a structural choice about who held decision-making authority. “There was sort of equipoise in managerial seniority between the sponsors and our local team, in the sense that our clinical trial lead and their clinical trial lead were co-chairs and had worked well together in the past, and so they made decisions together all the time,” Devenish said.

Co-chairing isn’t a technology decision, and it’s easy to overlook in a publication focused on tools and platforms. But it’s arguably the single structural choice that most shaped how technology decisions actually got made at this site. When the site’s lead and the sponsor’s lead hold equivalent formal authority and have an existing working relationship, disagreements about whether a platform is fit for purpose get resolved as a negotiation between equals rather than a request sent up a hierarchy. “I didn’t ever get the sense that we were lower down the food chain,” Devenish said. “At the end of the day, we were manifesting their vision, and so they were quite responsive to our needs.”

When Something Did Go Wrong: The CAPA Process

None of this meant the site never encountered a technology failure; it meant the site had a defined way of processing one when it happened. Devenish described a single notable technology issue during his time there, resolved through a formal Corrective and Preventive Action (CAPA) process. “You basically go through a process of root cause analysis of trying to understand where the issue was that led to the failure downstream,” he said. “There was one technology issue which we had, which we realized relatively early on. It was a minor issue which led to a protocol deviation; we did a CAPA, it was fixed quickly, and it never happened again.”

Beyond that one instance, the disruptions were the ordinary kind that come with any digital infrastructure. “Now and then the server would drop, and you wouldn’t be able to randomize for an hour or whatever.” Devenish is careful to distinguish that kind of problem from design or implementation failure, saying, “That’s just technology. That’s unavoidable.”

What Other Sites Can Take From This

Devenish is candid that his experience isn’t representative. “I suspect it’s because I worked at a very, very good trial site,” he said, noting that the tools involved were largely purpose-built and purpose-chosen rather than imposed. “The protocol chairs were also those who chose the tool and who, to some degree, owned the tool, as opposed to having to mold our institutional processes and SOPs to an external platform that was imposed upon us, which I think is probably quite difficult if you’re doing a lot of external clinical trials.”

This is a companion piece to Clinical Trial Tech Fails On Systems, Not Software, which explores why Devenish sees technology adoption as a systems problem rather than a software problem.