Timelines & Surge Management at Study End

Why this matters

The last 8–12 weeks of a trial rarely behave like the middle. New sites get activated late, participants cluster near last visits, vendors ship bigger batches, and coding/adjudication queues swell. If you staff for the average month, the peak month will overwhelm you and slip your interim analysis or lock.

Plain‑language terms used here

• LPLV: Last Participant (Patient) Last Visit.
• DSMB: Data and Safety Monitoring Board (independent committee, also called a DMC, that reviews accumulating safety and efficacy data).
• FTE: Full‑Time Equivalent (one full‑time person’s working time, about 40 hours a week).
• CRO: Contract Research Organization (your outsourced operational partner).
• “%>14 days”: The share of open queries older than 14 days (a common timeliness indicator).
• Burndown: a weekly view of the remaining backlog against the target date.
• Expectedness: the share of the forms or records due by now that have arrived.
• CRA: Clinical Research Associate, the site monitor.

Common sources of surge

1. Late site additions or re‑activations New or low‑enrolling sites often batch‑enter CRFs near LPLV. That creates a wave of new data, edits, and queries in a short period.

2. High‑frequency vendor feeds ramping with enrollment ePRO, device, IRT, imaging, and central lab files get larger as cohorts mature. Reconciliation, import checks, and variance reviews scale with those batches.

3. Medical coding and endpoint adjudication backlogs As visit density increases, so do AEs, concomitant medications, and outcome events. Auto‑coding handles the easy terms, leaving a harder tail that lands right when committees are preparing to review.

4. Amendments and late CRF/design changes Even small changes create re‑training needs, re‑validation work, and backfills—exactly when you wanted quiet.

5. Aging spikes at a few sites or vendors A handful of contributors can dominate your late backlog. If %>14 days rises before a DSMB or lock, you need targeted action, not broad reminders.

A quick FTE model

When the volume rises, convert work into people as simply as possible. No equations needed—use this four‑step approach:

1. Count the items you will need to process in a given period Examples: number of vendor files per week; number of new AEs to code; number of reconciliations to complete.

2. Estimate minutes per item for the actual work you’ll do at surge time Use recent samples: first‑pass review, validation checks, reconciliation, coding, QC, and documentation.

3. Convert to weekly hours Multiply items by minutes to get total minutes per week, then divide by 60 to get hours per week.

4. Translate hours to FTEs For surge tasks, plan on 25–30 focused hours per FTE per week (the rest goes to meetings, escalations, and admin).

   • If the work is 15 hours/week, you need about 0.5 FTE.
   • If the work is 30 hours/week, you need about 1.0 FTE (both at 30 focused hours).
   • Monthly version: a month is about 4.33 weeks (52 ÷ 12), not 4. Monthly hours = weekly hours × 4.33; divide by the hours in an FTE‑month (often 160 paid hours). Example: 30 hours/week × 4.33 = 130 hours/month; 130 ÷ 160 ≈ 0.8 FTE. This is lower than the 1.0 above because 160 counts all paid hours, not only focused ones, so always say which figure you used.

Tips

• Use two numbers per workstream: base (most weeks) and peak (last 6–8 weeks). Staff to the peak, not the mean.
• Add onboarding overhead for temporary staff (training and SOP read‑and‑sign, then access). A practical buffer is 10–20% above the raw hours.

Playbook: intervene & escalate

1) See the surge early

• Build a burndown view 8–12 weeks before LPLV: queries by age, unreviewed CRFs, vendor variances, coding backlog, adjudication queue, and import failures.
• Segment by site and vendor so hotspots are obvious.

2) Coach where it matters

• Target the few sites/vendors driving most aging.
• Offer micro‑training (15–30 minutes) on expectedness, timeliness, and common edit checks instead of generic webinars.

3) Add temporary capacity (surge pods)

• Spin up focused pods for reconciliation, coding, and import QC for 6–8 weeks.
• Complete training and SOP read‑and‑sign first, then set up personal, least‑privilege accounts, quick guides, and reference cases ahead of the surge so new team members can start producing on day 1.
• Keep surge tasks standardized (checklists, templates) to minimize rework.
• Surge staff review, reconcile, code, and raise queries; they never enter or correct site data in the EDC. Extra data‑entry hands are the site’s own trained, delegated staff.

4) Escalate through the contract line

• When timeliness threatens DSMB or lock, escalate through CRO/vendor leadership.
• Sponsor DM’s channel to sites is the EDC query; follow‑up with a slow site goes through its CRA—keep the operational chain clean and documented.

5) Protect the calendar

• Declare freeze windows around lock rehearsal and the lock ceremony: no CRF changes, no dictionary upgrades, and scheduled vendor batches only. This is a change freeze on the build and versions; sites keep entering and correcting data until the lock ceremony makes the EDC read‑only.
• Align DSMB/interim dates with realistic data‑arrival dynamics, not wishful thinking: plan backwards from the meeting date (report due, preparation, cleaning window, data cut‑off), using real entry, query and vendor‑transfer times (Example D).

Pitfalls & misconceptions

• “Our average month looks fine.” Peaks decide lock feasibility, not averages.
• “We’ll add help if it gets bad.” Training, access, and oversight create a delay; by the time you feel it, it’s late.
• “Aging is a site problem.” Sometimes it’s a vendor presence gap (expected records that never arrived) or import failures; diagnose before coaching sites.
• “Any help is good help.” Non‑standardized surge work increases QC finds and rework—use checklists and narrow task scopes.
• “Freeze windows are optional.” Without them, late changes ripple into avoidable defects at lock.

Practice in the wild (checklist)

• Plot backlog and %>14 days by site and vendor weekly starting T‑12 weeks from LPLV.
• Convert each workstream to hours/week and then to FTEs; have temporary capacity trained and with access by T‑8 weeks.
• Define escalation triggers (e.g., any site >20% over 14 days for two consecutive weeks; any vendor feed with unresolved import errors for >5 business days).
• Publish freeze windows (rehearsal and lock) and obtain sign‑off from sponsor, CRO, and key vendors.
• Pre‑write surge playbooks: reconciliation steps, coding conventions, import QC checklist, and canned messages for sites/vendors.
• Hold a weekly surge huddle (15–30 minutes) to review bottlenecks and assign actions.

Worked examples

These examples are self‑contained. Use the steps exactly as written.

Example A — ePRO/vendor file reconciliation

Scenario

Your ePRO vendor will deliver 50 files per week during the last 8 weeks. A timed sample shows it takes 20 minutes per file to perform checks, reconcile exceptions, and document outcomes.

Steps

1. Items per week: 50 files.
2. Minutes per item: 20 minutes.
3. Total minutes per week: 50 × 20 = 1,000 minutes → 16.7 hours.
4. FTEs needed: With 30 focused hours/FTE/week, 16.7 ÷ 30 ≈ 0.56 FTE.
5. Add 20% buffer for onboarding and coverage: 16.7 × 1.2 = 20 hours/week; 20 ÷ 30 ≈ 0.67 FTE (about 0.7) for 8 weeks.

Outcome

Assign one part‑time surge specialist or alternate two people for coverage.

Example B — Medical coding surge with mixed difficulty

Scenario

Ahead of DSMB, you expect 1,200 new AE terms. Auto‑coding handles about 60%. The remaining 40% (480 terms) need manual coding.

• Easy manual terms (300): ~1 minute each (select the matching MedDRA lowest level term).
• Hard manual terms (180): ~3 minutes each (review narrative, synonyms, QC note; a term too vague to code goes back to the site as a query).

Steps

1. Minutes for easy terms: 300 × 1 = 300 minutes.
2. Minutes for hard terms: 180 × 3 = 540 minutes.
3. QC spot‑check: ~10% of all 1,200 terms at 0.5 minute each = 60 minutes.
4. Total minutes: 300 + 540 + 60 = 900 minutes → 15 hours.
5. FTEs needed: 15 hours ÷ 30 focused hours/week = 0.5 FTE for the week you clear the queue.
6. If you want it cleared in 3 days (3 × 6 = 18 focused hours per FTE), plan 15 ÷ 18 ≈ 0.8 FTE for that short window.

Outcome

Stand up a small coding pod (coder + QC reviewer) for one week.

Example C — Site aging hot‑spot and escalation

Scenario

Three sites account for 65% of queries older than 14 days.

• Site 12: staff turnover; needs refresher on expectedness and visit windows.
• Site 27: import failures from a local device; not a site behavior issue.
• Site 34: PI travel; slow query responses.

Actions

1. Site 12: 20‑minute micro‑training + job aid, arranged through the CRA; set an interim target of <10% over 14 days within 2 weeks.
2. Site 27: Open vendor ticket for the device mapping issue; sponsor/CRO escalate to vendor success manager; remove site from aging watch once imports stabilize and the related queries close.
3. Site 34: CRA and CRO project manager agree a coverage plan with the PI (trained, delegated staff answer queries); the site holds 2 dedicated query‑response sessions this week.

Result

Within 2 weeks the program drops from 22% to 11% over 14 days (still above the ≤5% run‑up threshold, and every query must be closed by lock, so the watch continues); DSMB cut remains on calendar.

Example D — Planning a DSMB data cut backwards

Scenario

The DSMB meets on 2025‑09‑18. Its charter wants the report 2 weeks earlier, the independent statistician needs 2 weeks, and real entry, query and lab‑transfer times call for a 3‑week cleaning window.

Steps

1. Report due: 2025‑09‑04.
2. Cleaned snapshot to the statistician: 2025‑08‑21.
3. Data cut‑off: 2025‑07‑31, 7 weeks before the meeting.

Outcome

Announce the cut‑off to sites (through the CRAs) and vendors in advance. The snapshot is a dated copy, not a lock; the charter or DMP says which data must be clean. In a blinded study the study team stays blinded: only the independent statistician and the DSMB see unblinded results.

Key points to remember

• Staff to the peak, not the average—lock readiness is driven by surges in queries, coding, and reconciliation.
• Convert volume × frequency × minutes into hours/week → FTEs, and add a 10–20% buffer for onboarding/coverage so timelines are defensible with sponsors/CROs.
• Target hotspots (the few sites/vendors driving aging and backlog) with micro‑training and focused fixes; segment burndown by site/vendor and watch %>14 days.
• Stand up surge pods for reconciliation, coding, and import QC; use standardized checklists and QC to minimize rework and keep the burndown moving.
• Protect the calendar: plan each DSMB/interim data cut backwards from the meeting date against real data‑flow and enforce freeze windows around rehearsal and lock.
• Escalate through the contract line (CRO/vendor leadership) when timeliness is at risk; keep the chain clean and documented—sponsor DM raises queries in EDC and leaves site follow‑up to the CRA.