If you’ve run a device study, you’ve probably had the conversation. The one where someone looks at the enrollment curve around week six or eight and says: we’re behind.
It’s not a surprise, exactly. Device teams tend to build buffer into their timelines because they’ve learned to expect delays. Site activation takes longer than pharma. Participants are harder to find. Something always comes up with consent.
What’s less often examined is why. Not the surface-level answer — “enrollment is hard” — but the specific places where device trials lose time before a single participant is enrolled.
There are four of them. And none of them are inevitable.
1. Site activation timelines are built for pharma studies — not device ones
The industry benchmark for site activation in pharma trials is already uncomfortable: often eight to twelve weeks from site selection to first patient screened. In device studies, it tends to run longer.
Some of that is structural. Device studies involve additional regulatory submissions, IDE-specific documentation, and in many cases, device training for site staff before anyone can see a participant. These aren’t optional steps.
But a significant portion of the delay comes from systems that weren’t designed with device workflows in mind. When site onboarding involves moving between multiple platforms — one for training, one for documentation, one for the study itself — every handoff is a potential bottleneck. Sites get confused. Coordinators wait for IT. Activation drags.
Most teams accept slow site activation as the cost of doing business in device trials. It doesn’t have to be.
The teams that close this gap aren’t doing less. They’re working in environments where site setup, documentation, and study access happen in one place instead of three.
2. Enrollment data lives somewhere other than your study system
Ask most device clinical operations leads where their enrollment data lives and the answer is some version of: a spreadsheet, updated weekly, shared on a Friday.
This is the result of recruitment and data capture tools that were never designed to talk to each other. The participant funnel — from outreach to screen to enrollment — happens in one system (or no system). The study data lives somewhere else. Connecting them is a manual process that someone has to own.
The problem isn’t just inconvenience. It’s visibility — or the lack of it. When you can’t see enrollment against timeline in real time, you can’t intervene early. You find out you’re behind when you’re already behind.
A meaningful share of enrollment delays in device trials come down to visibility failure rather than recruitment failure. Teams that had the participants but didn’t see the slowdown coming until it was too late to course-correct without extending the timeline.
3. Consent workflows weren’t designed for device modifications
Device studies change. That’s not a flaw in the process — it’s how iterative device development works. A design modification mid-study is routine. What isn’t routine is how most clinical software handles the consent implications of that modification.
When a device design changes in a meaningful way, participants may need to be re-consented. In a well-designed study system, that triggers an automated workflow: updated consent forms go to the right participants, signatures are collected and tracked, and the audit trail stays clean.
In most device studies, it works differently. The modification gets flagged. Someone updates the consent form manually. Sites get notified by email. Coordinators track re-consent status in a spreadsheet. Someone is responsible for chasing down the participants who haven’t responded yet.
This is a compliance risk, a timeline risk, and a site burden issue, all at once. And it’s almost entirely a systems problem. The work that gets done manually in most device studies can be automated. Most teams just haven’t had a study platform that was built to handle it.
4. Most clinical software treats device studies as a variant of pharma — they’re not
This is the root cause underneath the other three.
The majority of clinical software on the market was built for pharma trials. EDC platforms, consent tools, recruitment systems — the design assumptions, the default workflows, even the language baked into the interface — all of it was shaped by pharma use cases.
Device studies don’t use “IND amendments.” They use device iterations. They don’t have “Phase 1” and “Phase 2” in the same way — they have first-in-human, feasibility, pivotal, and post-market surveillance. They have combination products that involve both a device and a drug component, each with their own regulatory pathway. They have IDE requirements that have no pharma equivalent.
When your study platform uses the wrong language, requires workarounds for standard device workflows, or simply doesn’t have fields for the data your regulatory team needs, you spend time managing the gap between your study and your software. That time comes out of your timeline.
The four causes of enrollment delay in device trials — slow site activation, invisible enrollment data, manual re-consent, and pharma-first software — share a common thread. They’re systems problems, not research problems.
What this means in practice
The device teams that consistently hit their enrollment timelines aren’t necessarily working with better protocols or easier patient populations. They’re working in systems that were built for how device studies actually run — where site activation, consent, enrollment visibility, and data capture happen in one environment.
The gap between a device study that runs on time and one that doesn’t is often less about the trial itself and more about the operational infrastructure around it.
That’s a solvable problem.
Coming up next
Next week we’re publishing a practical checklist for device sponsors: the enrollment visibility gaps that slow most pivotal studies down, and what to look for in a study system that’s actually built for device workflows. Check back here — or follow OpenClinica on LinkedIn so you don’t miss it.
