Devinka Hapugalle explains why medical device EDC systems should be designed around visits, workflows, users, and operational reality.
A lot of device trial Electronic Data Capture (EDC) system builds look good during the start-up phase of the study. The Case Report Forms (CRFs) are comprehensive, the edit checks are extensive with tight controls, and every protocol requirement has been accounted for. Everything starts off feeling controlled and complete.
However, once the study goes live, the experience at the site level can tell a very different story. This is because many device studies are still being built inside frameworks originally designed for traditional drug trials.
Medical device trials are inherently more operational than drug studies. In addition to endpoint data, we need to manage procedures, technical workflows, serial numbers, calibration tracking, firmware updates, device deficiencies and repeat interventions.
Build Around the Visit, Not the Protocol
One of the biggest improvements Sponsors and CROs can make is designing workflows around how coordinators actually move through a patient visit. Sites are not following protocol sections while managing a procedure, they are thinking about timing, patient flow, device prep, troubleshooting, repeat assessments, and everything else happening in real time during the visit itself.
When EDCs are built to mirror the protocol too closely, navigation in the EDC becomes clunky almost immediately. Coordinators end up bouncing between forms, duplicating information, or documenting events in ways that satisfy the system but don’t accurately reflect how the visit unfolded. This is where the frustration usually starts.
Stop Treating Every Data Point Like It Carries Equal Weight
One issue that shows up repeatedly in medical device studies is the tendency to over-collect data. Extra fields are added because the information might become useful at a later date. Over time, the system becomes clunkier and harder to use, even though most of those additions have little real value.
Funnily enough, the overly complex builds often create more inconsistency across data, not less.
When sites are constantly interrupted by low-value automatic queries or repetitive data entry, attention naturally shifts toward getting through the system rather than engaging carefully with the data itself. This is why good design requires restraint. Not every possible discrepancy needs an automatic query. Not every field needs to be mandatory. And not every theoretical scenario needs to be built into the workflow on day one.
Sites Usually Identify Problems Early
What’s interesting is that sites often recognize usability problems almost immediately, because they can tell when a workflow was designed without enough consideration for what actually happens in clinic. And in many cases, these issues are predictable long before the first patient is enrolled.
The best EDC builds tend to come from teams that work closely with the site teams, to spend time understanding operational workflows upfront instead of trying to solve everything through additional system logic later.
EDC usability is often treated as a technical consideration, when, in reality, it directly impacts study performance. Poor usability slows visits, increases queries, contributes to site fatigue, and creates downstream cleaning delays. The operational impact is much larger than most teams expect.
In Summary
In device studies, operational complexity already exists. The EDC should help absorb that complexity and not become another source of it.
And that often comes down to a simple but overlooked question: Was the system designed around the protocol or around the people responsible for executing it?