> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
Does my software qualify as a SaMD under FDA regulations?
FDA determines SaMD status by evaluating intended use. Software is a medical device if it meets the device definition in section 201(h) of the FD&C Act - intended to diagnose, cure, mitigate, treat, or prevent a disease or condition, or to affect the body's structure or function. The 21st Century Cures Act (Section 3060) carved out four categories of non-device software: administrative support, healthy lifestyle (non-medical purpose), electronic patient records, and certain CDS where clinicians can independently review the basis of the recommendation. If your software falls outside those exclusions and makes disease-related claims, it is likely a device. Consult regulatory counsel with your specific intended use statement before concluding it is out of scope.
What software safety class should I assign under IEC 62304?
IEC 62304 defines three software safety classes based on the severity of patient harm that could result from software failure. Class A: no injury or damage to health. Class B: non-serious injury. Class C: death or serious injury. The safety class drives required development activities - Class C requires the most rigorous documentation, unit testing, and code coverage requirements. Assign the safety class by performing a hazard analysis: for each software item, identify the worst credible harm, estimate severity, then assign the class. Document the assignment in the risk management file. Note: IEC 62304 is a copyrighted standard - reference by clause number only in documentation; do not reproduce clause text verbatim.
Which FDA regulatory pathway applies to my SaMD?
The regulatory pathway is determined by device classification (Class I, II, or III). Class I: general controls only; most exempt from 510(k). Class II: general and special controls; most require 510(k) premarket notification. Class III: general controls and PMA; required for SaMD that supports or sustains human life or presents high risk. If your SaMD has no predicate (new technology, novel intended use), consider the De Novo pathway for novel Class I/II devices. Consulting the FDA's Product Classification Database (productcode.accessdata.fda.gov) for similar devices helps identify the classification and applicable product codes.
What must be included in the Software Requirements Specification (SRS) for FDA submission?
The SRS for FDA review must document: (1) functional requirements (what the software does); (2) performance requirements (response time, accuracy, precision); (3) interface requirements (hardware, software, network); (4) safety requirements (requirements derived from hazard analysis); (5) security requirements (access controls, encryption, authentication); and (6) maintainability and reliability requirements. FDA expects each requirement to be uniquely identified, testable, and bidirectionally traceable - linked forward to design elements and backward from test results. The SRS is part of the DHF and must be version-controlled.
What cybersecurity documentation does FDA require in a premarket submission?
Per FDA's 2023 Cybersecurity Guidance ("Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions"), submissions must include: (1) a cybersecurity risk assessment covering threat modeling (STRIDE or equivalent), vulnerability identification, and residual risks; (2) an SBOM listing all software components and dependencies; (3) documentation of security controls implemented (authentication, encryption, patching mechanism); (4) a software update and patch deployment process; and (5) a coordinated vulnerability disclosure policy. The SBOM enables FDA reviewers to identify known CVEs in third-party components.
How do I manage post-market software changes - when do I need a new 510(k)?
FDA's guidance "Deciding When to Submit a 510(k) for a Software Change to an Existing Device" (2017) and the associated flowchart define when changes require new premarket submission. A new 510(k) is generally required when: the change is to a 510(k)-required device; it could significantly affect safety or effectiveness; or it is a major change to intended use. "Significant" changes include new algorithms, substantial changes to operating algorithms, or changes that introduce new disease claims. Changes that are minor bug fixes, security patches, or performance improvements with no effect on safety can typically be made under the existing clearance with appropriate design change documentation in the DHF.
What is substantial equivalence and how do I establish it for SaMD?
Substantial equivalence (SE) requires showing that your SaMD has (a) the same intended use as a predicate, or (b) a different intended use but with technological characteristics that do not raise new questions of safety and effectiveness AND are at least as safe and effective as the predicate. For SaMD, the SE argument typically compares: intended use statements (must overlap), device description and algorithm approach, and performance data (sensitivity/specificity for diagnostic devices). Performance data for SaMD can come from bench testing, clinical studies, or real-world validation depending on the risk level. Predicate selection is the critical first step - file a Pre-Submission (Q-submission) with FDA early if there is uncertainty.
What is a Pre-Submission (Q-Sub) and when should I request one?
A Pre-Submission (Q-Sub) is a formal FDA meeting request or written feedback request made before submitting a premarket application. FDA strongly encourages Q-Subs when: you are unsure of the regulatory pathway, you have questions about clinical study design or performance endpoints, your device uses novel technology, or you want feedback on an AI/ML algorithm change protocol. Q-Sub meetings typically occur within 90 days of FDA's acceptance. They provide non-binding but valuable feedback that can prevent costly rework after submission. Request via the eSTAR electronic submission platform or directly via FDA's eStar system.
What is the algorithm change protocol (ACP) for AI/ML SaMD?
The ACP describes the types of changes a manufacturer anticipates making to an AI/ML algorithm over the device lifecycle and the performance testing to be conducted before implementing each change. It enables a "predetermined change control" model where certain types of algorithmic updates can be made without a new 510(k), provided the changes stay within predefined bounds and the manufacturer follows the ACP testing protocol. An ACP must specify: types of anticipated changes, performance bounds (metrics, thresholds), the real-world evidence or validation data that will be collected, and a description of how changes will be monitored post-deployment. (FDA AI/ML SaMD Action Plan, 2021)
What clinical validation data does FDA expect for diagnostic SaMD?
FDA expects clinical validation data demonstrating that the SaMD performs as intended in the clinical population and environment. For diagnostic SaMD, this typically means: sensitivity, specificity, positive predictive value (PPV), negative predictive value (NPV), and area under the ROC curve (AUC) measured on a clinically representative dataset. The dataset must represent the intended patient population (age, sex, disease severity, comorbidities). Reader studies, locked retrospective validation studies, or prospective studies may be appropriate depending on risk level. FDA provides feedback on study design through the Q-Sub process.
How do I handle third-party software components (SOUP) in my SaMD?
For each SOUP item (e.g., open-source libraries, OS, commercial components), the manufacturer must: (1) document the SOUP item's title, manufacturer, and version in the DHF; (2) identify the requirements and SOUP is used to meet; (3) identify the system requirements and hardware on which it operates; (4) assess the risks that arise from the use of the SOUP; and (5) establish test procedures to verify that the SOUP meets its required functionality. Per IEC 62304, the rigor of SOUP verification depends on the software safety class. For FDA, the SBOM provides the formal inventory of all SOUP items.
What are the MDR reporting thresholds for SaMD incidents?
Under 21 CFR Part 803, SaMD manufacturers must report to FDA when they become aware that a device has or may have caused or contributed to: (1) a death - report within 30 calendar days; (2) a serious injury - report within 30 calendar days; (3) a malfunction that, if it were to recur, could cause or contribute to death or serious injury - report within 30 calendar days. If the incident requires remedial action to prevent unreasonable risk to public health, report within 5 days. Manufacturers must establish written MDR procedures and maintain event files for each reportable event.
How do I establish traceability for FDA design controls compliance?
Traceability in SaMD design controls means linking each artifact in the development lifecycle to related artifacts. Implement a traceability matrix with four levels: (1) user needs → device requirements; (2) device requirements → software requirements (SRS); (3) SRS requirements → design elements (architecture, modules); (4) design elements → test cases (unit, integration, system). For risk management: link each identified hazard → risk control requirement → verification test. FDA expects bidirectional traceability - you must be able to show that every requirement has a test and every test was generated from a requirement.
What is the QMSR and how does it affect SaMD development?
FDA published the Quality Management System Regulation (QMSR) in February 2024, effective February 2026, harmonizing 21 CFR Part 820 with ISO 13485:2016. Key changes relevant to SaMD: (1) ISO 13485 design and development requirements replace the prior design control structure; (2) risk management integration with ISO 14971 is more explicit; (3) software validation requirements reference IEC 62304 for medical device software. For builders, the practical impact is that ISO 13485-compliant QMS processes will satisfy FDA QSR requirements, enabling dual compliance. Existing 510(k)-cleared SaMD manufacturers must update QMS documentation by February 2026.
How should I implement a vulnerability disclosure program for SaMD?
FDA's 2023 Cybersecurity Guidance requires manufacturers to have a coordinated vulnerability disclosure (CVD) policy and process. The CVD policy must: (1) provide a public channel for security researchers to report vulnerabilities; (2) define response SLAs (FDA recommends acknowledgment within 10 business days and remediation timeline communication within 90 days); (3) include a no-penalty safe harbor for good-faith security research; and (4) commit to publishing security advisories. Implement using a dedicated security disclosure email address, a VDP page on your website, and integration with MITRE/CVE program for CVE ID assignment. The CVD policy must be submitted as part of the cybersecurity section of premarket submissions.
What records must I maintain and for how long for SaMD?
FDA records retention requirements for SaMD: DHF records - 2 years beyond the expected device life or device market life, whichever is greater; DHR records - 2 years; MDR records - 2 years; complaint files - 2 years; CAPA records - 2 years. For electronic records subject to 21 CFR Part 11, the system must protect records from modification and maintain audit trails for the required retention period. Best practice is 5-7 years beyond last sale to cover potential litigation. Cloud-stored records must be backed up, version-controlled, and accessible for FDA inspection.