SaMD Regulatory Pathway: FDA Classification and Submission Requirements

SaMD Regulatory Pathway: FDA Classification and Submission Requirements

Key Takeaways

What Is Software as a Medical Device

The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device (SaMD) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." This definition, published in the IMDRF SaMD Key Definitions document (IMDRF/SaMD WG/N10FINAL:2013), distinguishes SaMD from Software in a Medical Device (SiMD), which is software that is integral to a hardware medical device and cannot function independently.

The distinction matters for regulatory purposes. A software algorithm running on a general-purpose computing platform (smartphone, tablet, cloud server) that analyzes medical images to detect pathology is SaMD. The same algorithm embedded in a dedicated imaging device is SiMD, regulated as part of the parent device.

FDA adopted the IMDRF SaMD framework through a series of guidance documents beginning in 2017. The agency's Digital Health Center of Excellence (DHCoE), established in 2020, serves as the central coordination point for digital health and SaMD regulatory policy within CDRH.

SaMD vs Non-Device Software

Not all health-related software qualifies as a medical device. Section 520(o) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), added by the 21st Century Cures Act of 2016, excludes certain software functions from the definition of a medical device, including:

• Administrative support software (scheduling, billing)
• Software for maintaining or encouraging a healthy lifestyle (general wellness)
• Electronic patient records that do not interpret or analyze data
• Software that transfers, stores, converts, or displays medical device data without clinical interpretation
• Clinical decision support software meeting all four Cures Act criteria

FDA's guidance document "Policy for Device Software Functions and Mobile Medical Applications" (September 2019, updated September 2022) provides the framework for determining whether a software function meets the device definition.

IMDRF SaMD Risk Categorization Framework

The IMDRF developed a two-dimensional risk categorization framework for SaMD based on two factors:

1. Significance of the information provided by the SaMD to the healthcare decision
2. State of the healthcare situation or condition the SaMD is intended to address

The IMDRF Risk Matrix

Significance of information definitions:

• Treat or Diagnose: SaMD provides information used to take immediate or near-term action that treats, diagnoses, or prevents disease. The information alone drives the clinical action.
• Drive Clinical Management: SaMD provides information that is the primary basis for a clinical management decision, but is used in conjunction with other information.
• Inform Clinical Management: SaMD provides information that is used as one factor among many in a clinical management decision. The information is not the sole or primary basis for the decision.

State of healthcare situation definitions:

• Critical: The condition is life-threatening, requires urgent intervention, or has irreversible impact on health.
• Serious: The condition is significant but not immediately life-threatening. Intervention is important but time-sensitive rather than urgent.
• Non-Serious: The condition is minor or self-limiting. Incorrect information may cause inconvenience but is unlikely to cause significant harm.

How IMDRF Categories Map to FDA Classification

FDA does not directly adopt the IMDRF I-IV categories as regulatory classifications. However, the IMDRF framework informs FDA's risk assessment when establishing device classification:

These are general correlations, not rigid mappings. FDA evaluates each SaMD product individually based on its intended use, indications for use, technological characteristics, and risk profile.

FDA SaMD Classification Process

Step 1: Determine if the Software Is a Medical Device

Apply the device definition under Section 201(h) of the FD&C Act and the exclusions under Section 520(o). If the software meets the device definition and is not excluded, proceed to classification.

Step 2: Identify the Product Code and Classification

Search the FDA Product Classification Database for existing product codes that match the SaMD's intended use. Many SaMD product types now have established classifications:

If no existing product code matches, the SaMD may require De Novo classification (for novel, low-to-moderate risk devices) or may default to Class III requiring PMA.

Step 3: Select the Submission Pathway

The pathway depends on the classification and the availability of a legally marketed predicate device:

510(k) Premarket Notification:

• Applicable when a legally marketed predicate device exists with the same intended use and similar technological characteristics
• Most common pathway for SaMD in established product categories
• FDA review timeline: 90 calendar days from acceptance (statutory clock)

De Novo Classification Request:

• For novel devices that are low-to-moderate risk but have no predicate
• Establishes a new product classification and creates a predicate for future 510(k) submissions
• FDA review timeline: 150 review days (MDUFA V commitment)
• Has become the primary pathway for novel AI/ML-based SaMD

Premarket Approval (PMA):

• Required for Class III devices (highest risk)
• Requires clinical evidence of safety and effectiveness
• FDA review timeline: 180 FDA days (statutory clock)
• Relatively uncommon for SaMD but required for high-risk applications (e.g., autonomous diagnostic decisions in critical conditions)

Pre-Submission Program

FDA strongly encourages Pre-Submission (Q-Sub) meetings for SaMD, particularly for novel software functions, AI/ML-based devices, or products where classification is unclear. The Pre-Submission program is described in FDA's guidance "Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program" (last updated 2023).

A Pre-Submission for SaMD should address:

• Whether the software meets the device definition
• Proposed classification and regulatory pathway
• Intended use and indications for use
• Clinical evaluation strategy
• Software validation approach
• Cybersecurity considerations
• For AI/ML devices: algorithm description, training data, performance testing plan

Clinical Evaluation for SaMD

The IMDRF published "Software as a Medical Device: Clinical Evaluation" (IMDRF/SaMD WG/N41FINAL:2017), which FDA has referenced in its guidance. Clinical evaluation for SaMD differs from traditional clinical trials for hardware devices.

Clinical Evaluation by IMDRF Category

Valid Clinical Association: Demonstrating that the SaMD's output (e.g., a risk score, a diagnostic conclusion) is associated with the targeted clinical condition. This is typically established through published literature and existing clinical evidence.

Analytical Validation: Demonstrating that the SaMD correctly processes input data to generate accurate, reliable, and precise output data. For AI/ML-based SaMD, this includes algorithm performance testing on curated datasets.

Clinical Validation: Demonstrating that the SaMD's output achieves the clinically meaningful intended purpose in the target population and use environment. This may range from retrospective analysis of clinical data to prospective clinical trials, depending on the IMDRF category.

FDA's Expectations for Clinical Evidence

FDA's guidance "Clinical Performance Assessment: Considerations for Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data" (2020) provides specific expectations for radiological AI/ML SaMD. Key requirements include:

• Standalone performance testing on diverse, representative datasets
• Reader studies comparing physician performance with and without the SaMD
• Demographic subgroup analysis (age, sex, race/ethnicity, disease severity)
• Testing across multiple clinical sites and imaging equipment

For non-radiology SaMD, FDA evaluates clinical evidence expectations on a case-by-case basis, using the IMDRF framework as a guide.

Predetermined Change Control Plans

FDA's August 2025 final guidance "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions" describes the current PCCP framework for AI-enabled device software functions.

What Is a PCCP

A PCCP is a plan included in a premarket submission (510(k), De Novo, or PMA) that describes:

1. Modification Protocol: Specific, planned modifications the manufacturer intends to make to the device after authorization, and the methodology for implementing those modifications
2. Impact Assessment: An assessment of the benefits and risks of the planned modifications, including how the modification will be validated
3. Description of Modified Device: A description of the device after the planned modification is implemented, including updated performance specifications

If FDA authorizes the PCCP as part of the premarket submission, the manufacturer can implement the described modifications without submitting a new premarket submission, provided the modifications fall within the scope of the authorized PCCP and the manufacturer follows the described methodology.

PCCP Scope and Limitations

The FDA guidance specifies that a PCCP should describe modifications that are:

• Planned and specifically described (not open-ended)
• Bounded by defined performance specifications
• Subject to a documented validation methodology
• Monitored through real-world performance monitoring

A PCCP is not a blanket authorization for unlimited changes. Each planned modification must be specifically described, and the bounds of acceptable performance after modification must be defined. If a modification falls outside the authorized PCCP, a new premarket submission is required.

PCCP and the Total Product Lifecycle

The PCCP concept is part of FDA's Total Product Lifecycle (TPLC) approach to AI/ML-based SaMD. Under this approach, FDA envisions a continuous cycle of:

1. Premarket review (including PCCP authorization)
2. Post-market modification within PCCP scope
3. Real-world performance monitoring
4. Periodic reporting to FDA
5. Updated premarket submission if modifications exceed PCCP scope

This framework acknowledges that AI/ML algorithms may need frequent updates to maintain or improve performance, and that requiring a new premarket submission for each update would be impractical.

Software Documentation Requirements

Software Lifecycle Documentation

FDA's guidance "Content of Premarket Submissions for Device Software Functions" (last updated June 2023) describes the documentation required for SaMD premarket submissions. The level of documentation depends on the Level of Concern:

The 2023 update retired the previous three-tier "Minor," "Moderate," "Major" Level of Concern framework and replaced it with a two-tier system.

Cybersecurity Requirements

FDA's guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (September 2023) applies to all SaMD. Key requirements include:

• Secure Product Development Framework (SPDF)
• Threat modeling
• Cybersecurity risk assessment
• Software Bill of Materials (SBOM)
• Vulnerability management plan
• Patch management and update processes

For SaMD that connects to networks, cloud services, or other devices, cybersecurity documentation is a required component of the premarket submission.

Software Validation and Verification

Design Controls

SaMD is subject to the Quality System Regulation (QSR) under 21 CFR Part 820, including design controls (21 CFR 820.30). The revised QSR (Quality Management System Regulation, or QMSR), finalized in February 2024 to align with ISO 13485:2016, maintains design control requirements for software.

Design controls for SaMD include:

• Design Planning: Software development lifecycle model, configuration management
• Design Input: Software requirements specification (functional, performance, interface, safety)
• Design Output: Software architecture, detailed design, source code
• Design Review: Formal reviews at defined lifecycle milestones
• Design Verification: Testing that software meets its specifications (unit testing, integration testing, system testing)
• Design Validation: Testing that software meets user needs and intended uses in simulated or actual use environments
• Design Transfer: Procedures for transitioning from development to production/deployment
• Design Changes: Change control procedures for all modifications

IEC 62304 Compliance

While FDA does not mandate compliance with IEC 62304 (Medical device software — Software life cycle processes), the standard is recognized by FDA as a consensus standard. Manufacturers who demonstrate conformance to IEC 62304 can use the standard to satisfy relevant portions of FDA's software documentation expectations.

IEC 62304 classifies software into three safety classes:

Digital Health Center of Excellence

FDA's Digital Health Center of Excellence (DHCoE), established within CDRH in September 2020, serves as a centralized resource for digital health regulatory policy. DHCoE coordinates:

• Pre-Submission feedback for digital health and SaMD products
• Guidance document development related to SaMD, AI/ML, and digital health technologies
• The Digital Health Advisory Committee
• International harmonization efforts with IMDRF and other regulatory bodies

DHCoE published the "Digital Health Technologies for Remote Data Acquisition in Clinical Investigations" guidance (December 2024) addressing the use of SaMD and digital health technologies in clinical trials.

FDA's Evolving SaMD Regulatory Framework

FDA has acknowledged that the traditional medical device regulatory framework was designed for hardware devices and does not fully accommodate the characteristics of software. Key ongoing initiatives include:

• Total Product Lifecycle (TPLC) approach: Moving from point-in-time premarket review to continuous oversight
• Predetermined Change Control Plans: Enabling iterative software improvement without repeated premarket submissions
• Good Machine Learning Practice (GMLP): FDA, Health Canada, and MHRA jointly published guiding principles for GMLP in October 2021, covering data management, training practices, transparency, and evaluation
• Transparency and Real-World Performance Monitoring: FDA is developing frameworks for post-market surveillance of AI/ML-based SaMD

Practical Considerations for SaMD Sponsors

Common Classification Pitfalls

1. Overclassifying or underclassifying risk: Use the IMDRF matrix as a starting point, but verify against FDA product codes and prior De Novo decisions
2. Confusing SaMD with SiMD: If the software cannot function independently of dedicated hardware, it is SiMD and is regulated as part of the parent device
3. Ignoring Cures Act exclusions: Some software functions that appear clinical are excluded from device regulation under Section 520(o)
4. Assuming a predicate exists: Many novel SaMD functions have no predicate, requiring De Novo rather than 510(k)

Pre-Submission Strategy

For novel SaMD, a Pre-Submission meeting is strongly recommended to:

• Confirm the product meets the device definition
• Agree on classification and regulatory pathway
• Align on clinical evidence expectations
• Discuss PCCP scope if AI/ML-based
• Clarify cybersecurity documentation requirements

Timeline Expectations

These estimates assume a well-prepared submission. SaMD submissions frequently receive Additional Information (AI) requests, particularly regarding algorithm performance data, cybersecurity, and clinical evidence.

Key Regulatory References

References