I spent 12 years as a medical officer at FDA's Center for Devices and Radiological Health. Before that, I was a cardiothoracic surgeon for 25 years. And in all that time, the question I hear most often from software device companies still surprises me with how often it gets answered wrong.
"We already have clinical evidence. We generated it for our 510(k). Why do we need to do more?"
I get why people think that way. For most of medical device history, that logic held. You built a product, you validated it, you generated evidence that it was safe and effective, you submitted it, and you got clearance. The product didn't change much after that. Your evidence stayed current.
Software doesn't work that way, and that mismatch between how companies think about clinical evidence and how regulators evaluate it is creating real risk. I want to walk through why the traditional model breaks down and what a better approach actually looks like in practice.
The core problem: your product is never finished
The fundamental assumption behind traditional clinical evidence strategy is a fixed product. You generate evidence for a specific version of a specific device. That version gets cleared. You're done.
When I was at FDA, we started grappling seriously with this in 2019 when we published the white paper on the regulation of AI-enabled medical devices. The question that was keeping people up at night was: what do you do with a device that learns and changes over time? How do you regulate something that's different on Tuesday than it was on Monday?
Most software as a medical device products today aren't truly adaptive in that sense, but they still change constantly. Algorithms get updated, alert thresholds get refined, risk controls get modified, the user interface evolves, and new integrations get added. Each of those changes creates a question that most companies aren't asking systematically: does my existing clinical evidence still support this version of the product?
The answer, more often than not, is: partially. And partially is a problem.
Materiality: the code change is the wrong measurement
Here's the concept I want you to walk away with, because I've seen this save companies a lot of wasted effort and a lot of regulatory exposure: materiality is not about the size of the code change. The clinical impact of the change is the only measurement that matters.
I've seen companies panic over major refactors, running full clinical trials for changes that had zero effect on how a clinician would use the product or what decision they'd make. I've also seen companies wave through two-line changes that completely altered the output a clinician was acting on. The code delta is irrelevant. The clinical delta is everything.
When you're evaluating whether a software update requires new clinical evidence, there are four dimensions to assess: clinical meaning (did the output change?), clinical action (does it change what a clinician does next?), risk controls (did warnings or mitigations change?), and use context (did the user population, care settings, or integrations change?). Any of these reaching a threshold means your old evidence supports a different product than the one you're about to release.
The practical implication is that every SaMD team needs a documented, repeatable decision framework they apply at every release. When an FDA investigator asks how you decided what evidence to generate, you need to have a documented rationale ready. The investigators who ask that question are not looking for a perfect answer. They're looking for a defensible one.
Match the evidence to the impact, not the other way around
"We need new clinical evidence" doesn't always mean "we need to run a new clinical trial." I use a four-level framework: Level 0 is documentation only when there's no material clinical impact. Level 1 is verification and validation of the updated software version. Level 2 is a focused real-world evidence study or retrospective dataset for clear clinical impact. Level 3 is a full validation suite and prospective study for major changes like new indications for use.
The framework gives you a principled way to avoid both failure modes: generating more evidence than necessary, and generating less evidence than required.
Build evidence review into the release cycle, not onto the end of it
I see companies treat clinical evidence review as a final checkpoint before shipping. That approach consistently produces surprises. The right structure is to integrate the materiality assessment at the point when you're contemplating a release. Running that assessment early means you can scope the evidence collection work to fit the release timeline.
A lifecycle-integrated approach is also what makes the predetermined change control plan (PCCP) framework meaningful. You tell FDA in your original marketing application what changes you're planning to make and what evidence you'll generate to support them. FDA approves the plan, and you can execute those planned changes without coming back for a new 510(k).
Own your evidence even when you outsource the work
Outsourcing evidence collection to a CRO doesn't transfer the regulatory responsibility. You are the 510(k) holder. Four failure modes appear when evidence ownership gets diffused: traceability breaks down, speed of access suffers, signal detection weakens, and credibility erodes. The fix is a clear internal evidence owner, version-controlled evidence artifacts, a review cadence aligned to your release schedule, and a living evidence map of which evidence supports which version.
FDA and EU MDR are converging on the same principle
EU MDR mandates continuous clinical evaluation through the CER and mandatory post-market clinical follow-up. FDA's approach has been more risk-based, but FDA is now adopting ISO 13485 by reference and the PCCP signals the same directional shift. Both systems are converging on lifecycle traceability as the core requirement.
The infrastructure question no one wants to answer
Most SaMD teams have quality systems designed around a fixed product model. The evidence review cadence, if it exists at all, is calibrated for annual reviews. The gap between that operating model and what a continuously evolving SaMD product requires is exactly where regulatory exposure accumulates, quietly, release by release, until an inspection makes it visible all at once.
The companies that get this right aren't necessarily the ones with the biggest compliance teams. They're the ones that decided to treat clinical evidence as a living system rather than a closed file. That decision is mostly about process discipline, and you can start building it at the next sprint planning meeting.
If you want to go deeper on this topic, the full session is available on demand. Watch "Continuous clinical evidence for software that never stops changing" to see the complete framework including the materiality decision matrix and the evidence level examples.
Keep reading
BONUS RESOURCE: 3-in-1 SaMD Gap Assessment Tool
