Medical Device Software and FDA Regulations in the USA: What Healthcare App Builders Need to Know in 2026

A digital health team spent 18 months building an AI diagnostic tool for dermatology, trained on 500,000 images, achieving 94% sensitivity for melanoma detection, beating dermatologist performance in several study metrics.

They launched to 40 clinical sites, processed 10,000 patient images, and received a warning letter from FDA 6 months later.

The problem wasn’t the AI performance. The problem was the regulatory classification. Their tool was making specific diagnostic recommendations that clinicians relied on for treatment decisions. That made it Software as a Medical Device. They had launched without FDA clearance.

Remediation cost them $2.1 million and 14 months. Two of the 40 clinical sites permanently terminated their contracts rather than wait.

Understanding FDA SaMD classification is not an afterthought for AI healthcare product builders. It is the first conversation.

What Is Software as a Medical Device (SaMD)?

Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device.

The FDA defines SaMD as software that: (1) diagnoses, treats, cures, mitigates, or prevents disease in a patient; (2) provides decision support for clinical decisions that are not independently verified by the clinician before acting on them; or (3) is intended to be used in connection with any other medical device. SaMD requires FDA regulatory oversight, either 510(k) clearance, De Novo classification, or PMA depending on the risk level of the intended use.

The SaMD Classification Framework

The FDA uses a risk-based framework adapted from the International Medical Device Regulators Forum (IMDRF) to classify SaMD. Two dimensions determine classification:

Dimension 1: State of healthcare situation or condition:

• Critical: The situation is life-threatening or requires immediate action (ICU, acute care, critical care)
• Serious: Decisions are important but not immediately life-threatening (chronic disease management, diagnosing non-critical conditions)
• Non-serious: Decisions have a minor impact on patient management

Dimension 2: Significance of information provided:

• Treat or diagnose: The software directly treats a patient or provides a definitive diagnosis
• Drive clinical management: The software informs clinical decisions that directly affect patient management
• Inform clinical management: The software provides information used as one input among many that a clinician independently verifies

The risk category determines the regulatory pathway:

The Three FDA Pathways

• 510(k) Clearance: Demonstrates “substantial equivalence” to an existing legally marketed predicate device. Timeline: 90–180 days for straightforward software devices. Cost: $50,000–$300,000 in regulatory preparation. The most common pathway for Category II and some Category III software devices.
• De Novo Classification: For novel devices without a predicate. The FDA establishes a new regulatory classification based on the device’s specific characteristics. Timeline: 12–24 months. Cost: $200,000–$800,000. Required when the technology is genuinely new and no predicate exists for 510(k).
• Premarket Approval (PMA): Required for Class III devices (highest risk). Most common for SaMD in oncology diagnosis, life-critical support systems, and novel therapeutic applications. Timeline: 1–3 years. Cost: $500,000–$2,000,000+. Requires clinical trials demonstrating safety and effectiveness.

The Non-Device Exceptions: What Doesn’t Require FDA Clearance

Not all healthcare software is SaMD. Understanding the exceptions is as important as understanding the regulation.

The FDA’s five non-device software functions (21st Century Cures Act):

1. Administrative support software: Billing, scheduling, insurance claims, appointment reminders. Not a medical device.

2. General wellness software: Healthy lifestyle apps tracking diet, exercise, sleep, when not making claims about diagnosing, treating, or preventing disease. Not a medical device.

3. Electronic health records: EHR systems transferring, storing, and displaying patient health information. Not a medical device in most configurations.

4. Decision support software intended for non-serious conditions where clinicians independently verify: If your software provides information a clinician can independently verify before acting, reference information, educational content, general risk calculators and the condition is non-serious, this is not a medical device. This is the exception most builders try to rely on. It has specific conditions.

5. Software that facilitates communication and results: Patient portals, lab result displays, appointment notifications. Not medical devices.

The critical nuance of exception 4: The FDA published guidance clarifying that “independent verification” must be genuine. A clinician reviewing an AI recommendation by looking at the same data the AI used and applying their own clinical judgment is independent verification. A clinician accepting an AI recommendation because they trust the algorithm, without independently analyzing the underlying data, is not. This distinction is difficult to engineer and even harder to demonstrate in an audit.

The AI/ML SaMD Challenge in 2026

Traditional SaMD regulatory frameworks were designed for static software, a device that does the same thing every time, approved as-is. ML models are different: they learn from new data, potentially changing their behavior post-clearance.

FDA published its AI/ML-Based Software as a Medical Device action plan in 2021 and has been developing a Predetermined Change Control Plan (PCCP) framework that allows AI models to update within pre-approved parameters without re-clearance.

The current status: FDA accepts PCCPs as part of 510(k) submissions, allowing modest performance improvements and retraining on similar data distributions without requiring a new submission.

The post-market surveillance obligation: Once cleared, AI SaMD is subject to FDA post-market surveillance requirements: adverse event reporting, performance monitoring, and real-world evidence collection. For AI model development, this means maintaining outcome tracking infrastructure, connecting model predictions to patient outcomes, monitoring for performance drift, detecting bias in subpopulations.

Practical Guidance for Healthcare App Builders

Step 1: Perform the SaMD determination before building.

Ask: Is this software intended to make a diagnostic or therapeutic claim? Is the clinician expected to act on the recommendation without independent verification? Is the condition critical or serious? If yes to any of these, engage FDA regulatory counsel before your first sprint.

Step 2: Design toward the non-device exception if you can do so honestly.

If your software provides reference information that clinicians independently verify before acting, and the condition is non-serious, design the product and user experience to genuinely support independent verification. Documentation, UI design, and user training all matter. “The algorithm recommends X” with a one-click accept is closer to the device side. “Here are the factors that suggest X, here is the evidence, you decide” is closer to the non-device side.

Step 3: If SaMD, engage the FDA Pre-Sub program.

FDA’s Pre-Submission program allows companies to request feedback on their regulatory approach before submitting a formal application. For novel AI devices, a Pre-Sub meeting can save 12–24 months by confirming the intended pathway before preparation is complete.

Step 4: Build audit-ready infrastructure from day one.

Clinical validation studies, human factors studies, and post-market surveillance infrastructure are not built in the last sprint before FDA submission. They are built into the product from the beginning. The data you collect during development and early deployment becomes the clinical evidence in your 510(k) submission.

Author: Mayank Pratap | Co-Founder, EngineerBabu | Google AI Accelerator 2024 · CMMI Level 5

FAQ

• Does my healthcare app need FDA clearance?

Only if it qualifies as Software as a Medical Device. Administrative software, wellness apps, EHRs, and decision support software where clinicians independently verify before acting on non-serious conditions are generally not regulated as medical devices. AI systems making specific diagnostic or treatment recommendations in serious or critical clinical contexts likely require FDA clearance.

• What is the difference between 510(k) and De Novo?

510(k) clearance demonstrates substantial equivalence to an existing cleared device (the predicate). De Novo classification is for genuinely novel devices without a predicate, the FDA establishes a new device type. 510(k) is faster when a predicate exists; De Novo is the pathway for true innovation.

• How long does FDA clearance take for AI software?

510(k): 90–180 days for straightforward software devices. De Novo: 12–24 months. PMA: 1–3 years with clinical trials. Pre-Submission program feedback typically takes 60–90 days and can significantly de-risk the formal submission timeline.

• What is a Predetermined Change Control Plan (PCCP)?

A PCCP defines the parameters within which an AI/ML model can be updated after clearance without requiring a new FDA submission. It specifies the allowed changes (retraining on additional data within the same distribution, minor performance optimizations), the performance thresholds that trigger re-review, and the post-market monitoring required to detect unintended performance changes.

• What happens if I deploy AI clinical software without FDA clearance?

If the software qualifies as SaMD and is deployed without clearance, FDA can issue warning letters, require product recall, impose injunctions, and in cases of intentional violations, pursue criminal charges. Civil penalties can reach $15,000 per violation per day. The reputational impact with health system clients, who typically audit their software vendors for FDA compliance is often more immediately damaging than the regulatory action itself.