Rescue studies are used when problems within an ongoing clinical trial begin to threaten delivery, data quality or the reliability of the eventual results. In this QCast episode, co-hosts Jullia and Tom look at what happens when a study reaches that point, from identifying the underlying cause of the problem to assessing the existing data environment, deciding how a database should be handled and planning a workable recovery.
The pressure to act quickly can make rescue decisions harder. A large query backlog may appear to need more resource when the real problem lies in CRF design or edit checks. Recruitment delays may reflect eligibility criteria or site activation rather than site numbers. Database replacement can also create migration and validation work that would not exist if the current environment could be retained. Effective rescue therefore depends on understanding what has already happened, what can still be corrected and which limitations need to remain visible.
The first visible problem is not always the problem that needs fixing. Query volumes, missed timelines or slow recruitment can result from weaknesses elsewhere in the study, including protocol design, site processes, vendor responsibilities or data flows. A useful rescue assessment builds a reliable picture of the current study before deciding what corrective action to take.
Moving a study to a new database is only one possible rescue route. An existing database may be transferred, administration may remain with the incumbent vendor, or a replacement build may be required if the current system is unsuitable. Where data are migrated or database changes are introduced, the history of existing records, discrepancies and decisions still needs to remain understandable and documented.
Some problems can be corrected through targeted queries, additional documentation, data verification or controlled system changes. Other limitations may no longer be fully recoverable, particularly where inconsistent data collection has already occurred. Those issues may need to remain visible through analysis, reporting and regulatory communication rather than being treated as though the rescue removed them.
Jullia
Welcome to QCast, the show where biometric expertise meets data-driven dialogue. I’m Jullia.
Tom
I’m Tom, and in each episode, we dive into the methodologies, case studies, regulatory shifts, and industry trends shaping modern drug development.
Jullia
Whether you’re in biotech, pharma or life sciences, we’re here to bring you practical insights straight from a leading biometrics CRO. Let’s get started.
Tom
Today we’re discussing rescue studies. Now when people hear the term, they likely assume we’re talking about a trial that has effectively failed and needs saving. Is that a fair way to think about it?
Jullia
Not necessarily. See, a rescue study is really a corrective intervention when an ongoing trial has developed problems serious enough to threaten delivery, data quality or the reliability of the eventual results. That could be recruitment falling well behind plan, persistent vendor performance problems, missed timelines, regulatory concerns, or issues with how the data is being collected and managed.
And importantly, the study may still be recoverable.
Tom
That sounds obvious, but I imagine the temptation is to act quickly when timelines are already slipping.
Jullia
Exactly. Speed is obviously important, but reacting to the visible symptom can make things worse.
Say you have a large query backlog. You could add people and start closing queries faster, but if the backlog exists because the CRF doesn't align properly with the protocol, or the edit checks are generating unnecessary queries, you've treated the workload rather than the cause. A rescue assessment needs to establish whether the problem sits with the protocol, sites, vendors, systems, data flow or reporting readiness.
Tom
Can you give another example where the apparent problem isn't the real problem?
Jullia
Recruitment is a good one. A study might look as though it simply needs more sites, but the real constraint could be very narrow eligibility criteria, slow site activation, or an operational burden that's making participation difficult.
Tom
So the rescue starts with diagnosis rather than a predetermined solution. Now when the problem is specifically within clinical data management, what are you looking at first?
Jullia
You need a reliable picture of the current state of the study. That usually means looking at the protocol and CRF together, the annotated CRF, data management and review plans, edit check specifications, coding dictionaries, external data arrangements, user access and any connected systems. You're also looking at what's already happened. How much data have sites entered? What's outstanding? Are queries being answered? Are adverse events reconciling properly? Are external lab uploads arriving as expected?
You're trying to understand both the design of the data process and how it has actually behaved during the trial.
Tom
There's a misconception I'd like you to challenge here. If the incoming CRO has stronger data management processes, couldn't it simply move the study onto its own database and start again from a cleaner position?
Jullia
It can sometimes build a new database, but that isn't automatically the best option. By the time a rescue happens, you may already have months of participant data, queries, audit history and linked systems sitting in the existing environment.
There are different ways you can handle that. The database might transfer to the incoming CRO. The existing vendor might retain administration while the new team takes over activities such as cleaning and query management. Or, if the database genuinely isn't fit for purpose, a replacement build may be needed.
Each route creates different work and different risks.
Tom
What makes the new-build option particularly demanding?
Jullia
Data migration is a big part of it. You have to decide how existing records move into the replacement structure, how discrepancies are handled and whether anything requires re-entry or remapping.
Then you need to validate the changes. If a dosing field behaved incorrectly in the original system, for example, you can't simply create a corrected field and assume the issue has disappeared. You need to understand what was entered previously, how the corrected setup behaves and how you'll preserve the history of what changed.
Database changes should go through controlled approval, programming, user acceptance testing, access checks and a documented go-live decision.
Tom
And that's presumably where traceability becomes important, right? Since you don't want the rescue itself creating questions about the data.
Jullia
Right. The intervention has to be explainable afterwards. If data has moved between systems, you need documentation showing what transferred and how. If discrepancies were identified, reviewers need to be able to see how they were assessed and resolved. And if some earlier data limitations can't be corrected, those need to remain visible rather than disappearing from the record. A rescue can improve the study considerably, but it can't rewrite its history entirely.
Tom
That last point feels important because rescue can sound like a reset button, but that’s not entirely true is it.
Jullia
Yes, and because of that, expectations need to be realistic. Some problems are recoverable. Others leave residual limitations.
Imagine site data was collected inconsistently for several months before the issue was identified. You might be able to verify part of that information, issue targeted queries or obtain missing documentation. But there may also be information you simply can't reconstruct reliably. The rescue plan has to distinguish between what can be corrected, what can be verified and what needs to be acknowledged later in the analysis or reporting.
Tom
How does that affect the regulatory side? Does entering rescue automatically mean regulators become involved?
Jullia
It really depends on what changes are required. A vendor handover or data-cleaning intervention doesn't automatically mean the protocol itself changes.
But if the rescue requires a protocol amendment, changes affecting informed consent, or other material changes to trial conduct, then the relevant approval and regulatory processes come into play. And regardless of whether the protocol changes, sponsors need to maintain the integrity and continuity of the trial record, particularly around database changes, data transfers, audit trails and decisions made during the rescue.
Tom
Suppose the sponsor decides it needs an external CRO to take over. What usually determines whether that handover goes smoothly?
Jullia
The quality of the information available at handover makes a huge difference.
The incoming team need the current data management documentation, CRFs, validation information, database configuration details, known data issues and external vendor arrangements. Depending on the wider rescue, they may also need site status, ethics approvals, monitoring information and relevant trial master file documentation.
If those records are fragmented, the incoming team first has to reconstruct the study before it can properly start correcting it.
Tom
And there's a commercial reality here as well. Once a study is under pressure, people may want a very aggressive recovery date.
Jullia
They do, but an unrealistic recovery date simply adds another problem.
You have to account for the scale of the backlog, the condition of the documentation, the amount of remediation required and the availability of people with the right expertise. A database rebuild, for example, may introduce validation and migration work that wouldn't exist if the current platform could be retained.
Cost and timeline decisions are linked to the rescue route you choose. The fastest-looking option at the outset isn't always the fastest once you account for the work it creates.
Tom
Would you say that's where having biometrics disciplines involved early helps, rather than treating rescue as purely an operational exercise?
Jullia
Yes. Clinical data management may identify problems with collection and cleaning, while statistical programmers can see what those problems mean for downstream datasets and outputs. Statisticians may need to assess whether data limitations affect planned analyses, and medical writing eventually has to explain the study clearly and consistently.
That cross-functional view helps you avoid fixing one part of the workflow while leaving a downstream problem untouched.
Tom
If someone listening is dealing with a study that's starting to lose control, what should stay with them from this conversation?
Jullia
First, establish the root cause before you start applying fixes. Second, understand what you're inheriting. And finally, be realistic about recovery. Some issues may need to be carried through transparently into analysis, reporting and regulatory communication.
Jullia
With that, we’ve come to the end of today’s episode on rescue studies. If you found this discussion useful, don’t forget to subscribe to QCast so you never miss an episode and share it with a colleague. And if you’d like to learn more about how Quanticate supports data-driven solutions in clinical trials, head to our website or get in touch.
Tom
Thanks for tuning in, and we’ll see you in the next episode.
QCast by Quanticate is the podcast for biotech, pharma, and life science leaders looking to deepen their understanding of biometrics and modern drug development. Join co-hosts Tom and Jullia as they explore methodologies, case studies, regulatory shifts, and industry trends shaping the future of clinical research. Where biometric expertise meets data-driven dialogue, QCast delivers practical insights and thought leadership to inform your next breakthrough.
Subscribe to QCast on Apple Podcasts or Spotify to never miss an episode.