Continuing review timelines and the cost of a regulatory lapse

The regulatory emergency that is entirely preventable

An IRB approval expiration is not like a driver's license renewal -- inconvenient if you miss it, but easily remedied with a trip to the DMV. When IRB approval lapses on a clinical trial, the consequences are immediate and cascading. Enrollment stops. Scheduled participant visits cannot proceed. The sponsor receives notification that one of their sites has lost regulatory coverage. The clinical research associate documents the lapse in a monitoring report. And every day the lapse continues, the damage to the site's reputation compounds.

I have watched this scenario unfold at sites that were, in every other respect, competent and well-run. The problem was never that someone did not care about continuing review. The problem was that no system existed to ensure that the continuing review timeline was visible across the portfolio early enough to prevent the crisis. A coordinator tracking one study knows that study's expiration date. But when 15 studies have 15 different expiration dates spread across 12 months, and each requires a submission package that takes three to four weeks to prepare, the margin for error is measured in days -- and the consequences of missing that margin are measured in months of recovery.

This lesson does not teach you what continuing review is. You know that from your CRC training. This lesson teaches you what happens when it goes wrong and how to build the operational infrastructure that ensures it never does.

Anatomy of a lapse: what happens when IRB approval expires

Per ICH E6(R3) Annex 1, Section 1.2.4, the IRB/IEC should conduct continuing review of each ongoing trial at intervals appropriate to the degree of risk to participants. Under U.S. regulations (21 CFR 56.108(a)), that review must occur at least once per year. When that review does not occur before the current approval period expires, the regulatory status of the trial changes fundamentally. The site no longer has IRB authorization to conduct the research. This is not a technicality -- it is a regulatory state change with immediate operational consequences.

The cascade is predictable and, in my experience, remarkably consistent across institutions. It unfolds in stages, each compounding the one before it.

Stage 1: Immediate enrollment freeze. No new participants can be enrolled. Screening visits in progress must be paused. Participants who were scheduled for their first study visit may need to be rescheduled or, depending on the protocol's enrollment window, withdrawn. For a trial actively enrolling, every day of the freeze represents lost participants -- participants who may enroll at a competitor site instead.

The portfolio multiplier: why one lapse becomes three

Here is the aspect of continuing review lapses that I find most underappreciated by sites that have not yet experienced one: a lapse does not only affect the study that lapsed. It destabilizes the entire portfolio.

Consider the mechanics. When a continuing review lapse is discovered, the regulatory coordinator must immediately shift from proactive portfolio management to crisis response. The lapsed study demands emergency attention: assembling the overdue package, negotiating expedited IRB review, notifying the sponsor, documenting the lapse, and managing the fallout. Every hour spent on crisis management is an hour not spent on the continuing reviews, amendments, and safety reports for the other 14 studies in the portfolio.

This is how one lapse becomes two. And two becomes three. The RC who is spending 40% of their week managing the consequences of a lapse on Study A does not have the bandwidth to notice that Study B's continuing review is now 45 days out with an incomplete package. By the time the Study A crisis is resolved, Study B is in the same position. The cascade is not hypothetical -- I have seen it happen at sites that were, on paper, adequately staffed and well-organized. The root cause is always the same: the absence of an early-warning system that would have flagged the approaching deadline with enough lead time to prevent the crisis.

Designing the early-warning system: 90, 60, and 30 days

The antidote to a regulatory lapse is not vigilance. Vigilance is a human capacity, and human capacities fail under sustained load. The antidote is infrastructure -- a system that generates alerts at defined intervals regardless of how busy you are, how many other deadlines are competing for your attention, or whether the coordinator who normally tracks that study is on vacation.

The early-warning system I am about to describe is not complex. But it must be implemented with the same rigor you would apply to a safety reporting system, because the consequences of its failure are comparable. It operates on three alert milestones, each triggering a specific set of actions.

The 90-day alert: begin preparation

At 90 days before the current approval expiration date, the tracking system generates the first alert. This is the preparation trigger. At this milestone, the RC takes three actions.

First, verify the expiration date. This sounds redundant, but I have seen sites operate on incorrect expiration dates pulled from outdated approval letters or transposed incorrectly into the tracking system. The 90-day alert is the moment to confirm the date against the most recent IRB approval letter. If the date in your system does not match the letter, fix it now.

Second, identify the data streams that will feed the continuing review package for this study. Which coordinator maintains the enrollment log? Who compiles the adverse event summary? Is the deviation tracker current, or does it need reconciliation before data can be pulled? The goal is not to assemble the package now -- that comes at the 60-day milestone -- but to identify any data collection gaps that would delay assembly later. Per ICH E6(R3) Annex 1, Sections 2.12.1 and 2.12.2, the investigator should ensure the integrity of trial data and maintain adequate source records that are attributable, legible, contemporaneous, original, accurate, and complete. The 90-day check verifies that those records are being maintained continuously, not scrambled together at the last minute.

The 60-day alert: assembly checkpoint

At 60 days, the system generates the second alert. This is the assembly checkpoint. By this milestone, three conditions must be met.

The data streams identified at the 90-day mark are now locked. The coordinator has provided the enrollment summary current through the data-lock date. The adverse event tally is complete. The deviation log is reconciled. These data elements are in the RC's hands, not still sitting in the coordinator's pending tasks.

The IRB-specific template for this continuing review is populated with the study-level data. Common elements -- study title, protocol number, PI name, approval dates -- are filled. IRB-specific sections -- the format they want for the enrollment summary, the level of detail they expect in the deviation narrative -- are drafted.

And the PI review window is scheduled. Not "we will get the PI to look at it sometime in the next two weeks" -- but a specific date, confirmed with the PI or the PI's assistant, during which the PI will review and sign the package. If the PI is unavailable during the planned review window, the 60-day checkpoint is the last moment at which alternative arrangements can be made without creating timeline risk.

The 30-day alert: submission deadline

At 30 days before expiration, the package must be submitted to the IRB. Not "nearly ready." Not "waiting for one signature." Submitted.

This milestone is non-negotiable because it accounts for the one variable you cannot control: IRB processing time. Most IRBs process continuing reviews in 15 to 25 business days. Some are faster. Some, particularly local institutional IRBs that meet on a monthly committee cycle, may take longer. But 30 calendar days provides the minimum safe buffer for most IRB types. If you are working with an IRB whose processing time routinely exceeds 20 business days, adjust your 30-day standard to 45 days and cascade the 60 and 90-day alerts accordingly.

What happens if you reach the 30-day mark and the package is not ready? This is an escalation event, not a scheduling adjustment. The RC must immediately assess what is preventing submission, escalate to whoever can resolve the block, and explore expedited options. Some IRBs offer expedited or emergency continuing review processing for packages submitted close to expiration. But these expedited pathways are favors, not entitlements. A site that uses them routinely signals a process problem that the IRB will eventually address through more uncomfortable channels.

Integrating early-warning into the tracking system

The early-warning system is not a separate tool. It is a feature of the submission tracking infrastructure you designed in Module 1, Lesson 3. If your tracking system captures each study's current IRB approval expiration date, then the early-warning system is a calculation: expiration date minus 90, 60, and 30 days, with each threshold generating an alert.

The implementation varies by tracking platform. A spreadsheet-based system uses conditional formatting to highlight studies approaching each threshold -- green at 90 days, amber at 60, red at 30. A CTMS module may offer automated email alerts at configured intervals. A shared calendar system uses recurring reminders set backward from the expiration date.

The specific technology matters less than the discipline. The system must generate alerts automatically, without requiring anyone to remember to check. It must be visible to the RC regardless of their current workload or focus. And it must be updated immediately when a continuing review is approved and a new expiration date is established -- because the cycle begins again the moment the current one ends.

Key takeaways

A continuing review lapse is not a paperwork delay -- it is a regulatory state change that immediately halts enrollment, disrupts participant visits, triggers sponsor escalation, and damages the site's competitive position. The consequences cascade across the portfolio because crisis management for the lapsed study consumes the bandwidth needed to prevent lapses on other studies.

The 90/60/30-day early-warning system is the operational infrastructure that prevents lapses. At 90 days, verify the expiration date, identify data collection needs, and check for dependencies. At 60 days, confirm that data is locked, the template is populated, and the PI review window is scheduled. At 30 days, the package must be submitted -- no exceptions. This system integrates with the submission tracking infrastructure from Module 1 and generates alerts automatically, without relying on individual memory.

The cost of building and maintaining this early-warning system is measured in hours per month. The cost of a single lapse is measured in months of recovery, lost enrollment, damaged relationships, and institutional corrective action. The math is not close.