3 Reasons Why Study Rescues Happen, and How to Prevent Them 

When a clinical trial database is consistently not working as expected or contains critical lack of alignment with the protocol objectives, a sponsor may consider bringing in a new programming team to assess the build, correct the problems, and move the study forward.

When a study rescue involves repairing a technology implementation, it is easy to assume that the technology itself is the source of the problem. In my experience, that is rarely the case. Most study rescues begin with human issues: Poor-quality work, spotty communication, and departmental silos result in sponsors having to spend hours understanding how decisions made months earlier produced a build that does not support the study. 

Poor study builds have tremendous downstream consequences. Nobody wants to find themselves in a position that necessitates a study rescue. 

With this in mind, and based on the studies I have helped rescue, here are three human-centric issues sponsors should look for—and address—before first patient in. 

1. Poor Quality of Work 

The most direct reason I have seen for a study rescue is poor quality of work. This does not necessarily mean the programmers working on the study build lacked technical expertise. More often, quality begins to break down when technical execution is separated from the communication, context, and oversight needed to make the build work for the study holistically. 

Poor work quality can appear anywhere: in the database design and its associated workflow, validations, impacts from migrations, or the way different parts of the implementation work as one cohesive unit. And it’s only during testing—or, in more serious cases, after the database is live—the sponsor discovers their technology does not behave as expected. 

What sponsors can do earlier 

Sponsors should evaluate work quality as more than the completion of programming tasks. 

Before the build begins, meet with the lead programmer, or even the team. Collaborate and strategize together how the protocol and study requirements are being translated into the database. Sponsors should also determine who is accountable for the quality of the complete build, as this often gets segmented amongst cross-functional teams to where gaps could arise. 

Even when several programmers or specialists support the project, one person should retain enough context to understand how decisions in one area affect the rest of the database. 

2. Lack of Communication 

In one rescue situation, I asked a sponsor what its programming team had said about problems discovered during testing. The answer: “We don’t talk to our programmers.” Instead, the sponsor communicated with data management as its primary point of contact. It wasn’t clear whether data management was correctly passing requirements or concerns to the programmers. 

This happens more often than it should. Roles are highly siloed, so questions and concerns move through intermediaries before reaching the people responsible for configuring the system—if they reach them at all. 

In another recent rescue, a sponsor was dealing with a workflow that didn’t function as requested. When my team and I examined the workflow, it became obvious that the technology being used could not support the workflow in the form in which it had been requested. But the sponsor had never been told that. No one brought the sponsor and the programming team together to discuss the constraint and identify a workable alternative. 

What sponsors can do earlier 

Before engaging a services team, sponsors should ask whether they will have direct access to the lead clinical programmer.  

Sponsors should not be expected to understand every capability or limitation of the technology. A data manager, statistician, safety representative, or clinical leader may know what the study needs to accomplish without knowing exactly how the system must be configured to support it. The programmer should help bridge that gap. Access to the programmer should begin during the project kick-off, continue through requirements gathering and study design, and even on throughout study conduct. 

3. Compartmentalization 

Many larger services providers divide database work among specialized functional teams. For instance, one team builds the eCRFs and casebook structure, another develops edit checks. Each function completes its assigned work and passes the project forward. While that structure supports scale, it can also compartmentalize the study implementation. 

Requirements lose context as they move from one team to another. Though one team may complete its assigned task, the sponsor may not receive a database that functions as a coherent whole. Here, the human problem is that no one has retained responsibility for understanding how the complete implementation is supposed to work. 

What sponsors can do earlier 

Before selecting a services partner, sponsors should understand how the provider organizes its clinical programming work. 

Ask whether a consistent lead will remain involved throughout the study. That person may not personally complete every programming task, but should retain responsibility for understanding the protocol, coordinating the work, preserving the context behind earlier decisions, and overseeing how the pieces fit together. 

Warning Signs That a Study May Need Intervention 

A sponsor may already have selected a provider and begun the database build process when something starts to feel wrong. 

The following signs may indicate that the study is moving toward a rescue: 

• The programming team is difficult or impossible to access 

• Questions repeatedly pass through several intermediaries 

• The database behaves differently from what the study team expected 

• Similar problems appear across multiple rounds of testing 

• No one can explain why a requirement was configured in a particular way 

• The sponsor is coordinating work the provider should be overseeing 

• No one appears accountable for the implementation as a whole 

When these signs appear, it’s time to bring together the people who understand the study requirements and the people who understand the system. It may also be time to consider whether the current services provider can deliver the communication, oversight, and quality the study requires. 

Effective Study Builds Require the Right Technology and the Right Teams 

Technology and automation can improve many parts of clinical database development, but they cannot independently clarify an ambiguous requirement, explain a platform limitation, negotiate an alternative, or recognize that a decision made today may create problems later in the study. 

Those activities depend on experienced teams who understand both the technology and the sponsor’s intended outcome. 

When the right people remain involved from design through delivery, issues are more likely to be identified while they are still manageable—and far less likely to become the reason a study needs rescuing. 

Preparing for a new database build or encountering problems in an active study? Learn how eClinical Solutions’ Biometrics Services combine clinical programming expertise, direct consultation, hands-on execution, and the elluminate Clinical Data Intelligence Platform to improve study design and build.