Validating Clinical AI: What FDA SaMD Guidance Means for Your Product

The Regulatory Landscape Has Changed

For most of the history of medical device regulation, software was either a component of a hardware device or a standalone tool with predictable, static behavior. The FDA's regulatory frameworks were designed for devices that do what they're programmed to do, consistently, without changing over time.

AI/ML-based medical software doesn't fit this model. Adaptive algorithms change their behavior as they encounter new data. The model that was validated before clearance may behave differently six months post-market as it learns from real-world patient populations.

The FDA's Action Plan for AI/ML-Based Software as a Medical Device, published in 2021 and updated since, represents an attempt to create a regulatory framework for software that changes over time. Understanding this framework is essential before designing your clinical AI system — not after.

Is Your Product SaMD?

Software as a Medical Device is defined by the IMDRF (International Medical Device Regulators Forum) as software intended to be used for medical purposes that performs these purposes without being part of a hardware medical device.

The key determiner is intended use. A dermatology AI that analyzes photos to diagnose melanoma is SaMD. An administrative tool that schedules patient appointments is not. A clinical decision support tool that provides information to a clinician who independently makes the final decision occupies an ambiguous middle ground — and the FDA has provided guidance on where that line falls.

If you're building in the gray zone, get FDA feedback early. The Pre-Submission (Q-Sub) program allows you to describe your intended device and ask the FDA to characterize its regulatory status before you invest in your development program.

The Software Development Lifecycle Requirements

FDA-regulated medical software must follow a documented software development lifecycle that demonstrates: requirements are defined before development begins, design decisions are documented and reviewed, code is tested against requirements, changes are managed with version control and impact assessment, and defects are tracked and resolved.

For clinical AI specifically, the development lifecycle documentation must also include:

• Training data description: source, population, size, labeling methodology, and quality controls
• Algorithm selection rationale: why this model architecture was chosen
• Performance testing methodology: what metrics were evaluated and how the test set was constructed
• Failure mode analysis: what happens when the model is wrong and how the device handles it
• Human factors: how the AI output is presented to clinicians to support appropriate reliance

The Predetermined Change Control Plan

The PCCP is one of the most practically significant developments in FDA AI policy. Traditionally, any change to a cleared medical device that could significantly affect safety or effectiveness requires a new 510(k) submission — a process that takes months. For AI/ML devices that learn from post-market data, this created a fundamental tension: the devices could improve with real-world data, but regulatory requirements effectively prevented them from doing so.

The PCCP framework allows a manufacturer to pre-specify the types of changes they plan to make (algorithm updates, expansion to new patient populations, changes to intended use) and the performance testing they will conduct to validate each change type. If the device performs within the pre-specified bounds on the pre-specified tests, the change can be implemented without a new submission.

The practical implication: if you're building a clinical AI product that will benefit from continuous learning, you should design your PCCP into the product architecture from the beginning — not add it as an afterthought before submission.

Building for Regulatory Success

The teams that navigate FDA SaMD review successfully share a common characteristic: they treat regulatory compliance as an engineering requirement, not a documentation exercise. The model architecture, training pipeline, evaluation framework, and post-market monitoring system are all designed from the start with regulatory documentation in mind.

This means more upfront work. It also means that when the 510(k) submission is being prepared, the evidence package largely writes itself from the development documentation that already exists — rather than requiring a retrospective reconstruction of decisions that were made informally months earlier.