FDA SaMD Guidance Explained: What Every Life Sciences Product Manager Needs to Know

If you're building AI products in life sciences, you will eventually hit a three-letter acronym that determines whether your product ships in months or years: SaMD - Software as a Medical Device.

I've worked through FDA regulatory strategy across multiple clinical AI products at HCLTech. Here's the practical guide I wish I'd had on day one.

What Is SaMD?

Software as a Medical Device is software intended to be used for medical purposes without being part of a hardware medical device. Think: a diagnostic algorithm running on a standard laptop, not embedded in an MRI machine.

Examples of SaMD: AI that reads radiology images, clinical decision support tools that recommend treatments, algorithms that predict patient deterioration from EHR data.

Examples that are not SaMD: EHR systems (administrative), hospital scheduling software, fitness trackers (wellness), lab information management systems.

The Classification Framework: Class I, II, and III

Class I (Low Risk) - General controls only. Example: software that logs patient symptoms for doctor review.
Class II (Moderate Risk) - Requires 510(k) or De Novo. Most AI/ML medical devices land here. Example: AI flagging diabetic retinopathy.
Class III (High Risk) - Requires PMA. Example: AI autonomously diagnosing life-threatening conditions.

Key insight: Your classification determines timeline and cost. Class II 510(k): 6-12 months, $200K-$500K. Class III PMA: 2-4 years, $2M-$10M.

Regulatory Pathways

Building on a Solid Foundation: Your Quality Management System

Regulatory Pathways Building on a Solid Foundation: Your Quality Management System You can have the best AI model, but without a strong Quality Management System (QMS), your SaMD won't get far with the FDA. This isn't just about good practice; it's a regulatory requirement. I've seen teams underestimate this, leading to significant delays. Your QMS needs to cover everything from design and development to production, distribution, and post-market activities.

The gold standard here is ISO 13485. This international standard specifically outlines requirements for a QMS where an organization needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and regulatory requirements. It's not optional for serious players. Within this, design controls are paramount. You must document your design inputs, outputs, reviews, verification, and validation activities. Every decision, every change, needs a paper trail.

Risk management also lives within your QMS, guided by ISO 14971. This means identifying potential hazards, estimating and evaluating risks, controlling them, and monitoring the effectiveness of those controls throughout the product's entire lifecycle. For AI SaMD, this includes risks like model bias, drift, or misinterpretation of outputs by a clinician. Thinking about risk early can shape your product's safety features and regulatory strategy.

The FDA's Eye on Your Code: SDLC for SaMD

Developing SaMD isn't like building a typical enterprise app. The FDA expects a highly structured and documented Software Development Lifecycle (SDLC). This isn't just about agile sprints; it's about demonstrating control and safety at every step. The international standard IEC 62304, "Medical device software - Software life cycle processes," is your blueprint here. It classifies software based on risk (Class A, B, C) and defines processes for development, maintenance, and risk management.

Verification and validation (V&V) take on a deeper meaning. Verification ensures you're building the product right - for example, unit tests, code reviews, integration tests. Validation ensures you're building the right product - that it meets user needs and intended use in a clinical setting. For an AI that detects a specific disease, validation means demonstrating its diagnostic accuracy against ground truth data, often from clinical studies. This goes beyond typical software QA.

Traceability is another critical piece. You need to show a clear link from every user requirement to its design specification, code implementation, and testing. Tools like Jira with specific plugins or dedicated requirements management systems can help manage this. This level of rigor proves to the FDA that your software is developed systematically, minimizing the chances of errors that could impact patient safety. It's about demonstrating engineering discipline.

Keeping Watch: Post-Market Surveillance and Real-World Data

FDA clearance isn't the finish line; it's a major milestone. After your SaMD is on the market, you enter the phase of post-market surveillance. The FDA requires you to actively monitor your device's performance and collect real-world data. This is crucial for patient safety and for demonstrating continued effectiveness. You'll need systems in place to track adverse events, which are any undesirable experiences associated with the use of a medical device.

If your SaMD is linked to an adverse event, you're typically required to report it to the FDA via the MedWatch program within a specific timeframe, often 30 days for serious events. This isn't just about compliance; it's about learning and improving. Many companies implement continuous performance monitoring dashboards for their AI models, tracking metrics like accuracy, precision, and recall on live data. This helps detect model drift or data shift early.

Real-world data (RWD) collected post-market can also be incredibly valuable. It can support future product iterations, provide evidence for expanding your device's indications, or even be used to update your Predetermined Change Control Plan. For example, if your AI was cleared for adults, RWD on its performance in an adolescent population could support a future submission to expand its use. Collecting this data systematically is a long-term strategy for product evolution.

Designing for Humans: The Role of Human Factors Engineering

Even the most accurate AI can be unsafe if users misinterpret its output or interact with it incorrectly. This is where Human Factors Engineering (HFE) comes in. HFE focuses on designing the user interface and overall system to minimize the potential for use error. For SaMD, especially those providing diagnostic or treatment recommendations, ensuring clinicians understand and correctly act on the AI's output is paramount.

The FDA provides guidance on applying HFE principles to medical devices. You'll typically conduct a use-related risk analysis early in development. This involves identifying potential scenarios where a user might make a mistake - for instance, misreading a probability score, overlooking a critical alert, or inputting incorrect patient data. Then, you design controls to mitigate these risks, such as clear visual cues, simplified workflows, or mandatory confirmation steps.

Formative usability studies, where you observe target users interacting with prototypes, help identify and fix design flaws early. A summative validation study, often performed with a near-final product, demonstrates that the device can be used safely and effectively by its intended users in a realistic environment. This study typically results in an HFE report that's included in your regulatory submission. It shows you've thought deeply about how your SaMD fits into a clinician's workflow and how to prevent errors that could harm patients.

510(k) - The Predicate Device Pathway

Demonstrate substantial equivalence to an already-cleared device. Fastest for Class II. Start predicate searches early using the FDA's public database.

De Novo - The Novel Device Pathway

For low-to-moderate risk devices with no predicate. Increasingly common for AI/ML. Takes 12-18 months. Creates new classification for future devices.

PMA - The Gold Standard

For Class III, high-risk devices. Requires clinical trial data. Most AI teams should design products to include physician oversight, keeping them in Class II territory.

The Clinical Decision Support Exemption

The 21st Century Cures Act exempts CDS software meeting ALL four criteria: not processing medical images/signals, displaying/analyzing medical information, intended for healthcare professionals, and enabling the HCP to independently review recommendations. The fourth criterion is key - explainability isn't just nice-to-have, it's a regulatory strategy.

Predetermined Change Control Plans (PCCPs)

PCCPs let you define upfront how your algorithm will change post-clearance - what data it learns from, how performance is monitored, what triggers resubmission. This means continuous improvement without a new 510(k) every time your model updates. Plan for this from day one.

Key Takeaways

Regulatory strategy is product strategy. Start planning in discovery, not after development.
Design for Class II. Include physician oversight to avoid Class III/PMA.
Explore the CDS exemption. Transparency in AI reasoning can mean no FDA regulation at all.
Plan PCCPs from day one. If your AI improves, build change control into your initial submission.
Engage FDA early. Pre-Submission meetings are free and can save months.

For more terms, see the glossary.