Software as a Medical Device (SaMD): FDA's 510(k) Requirements Explained

Software as a Medical Device — software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device — is one of the fastest-growing categories in FDA's 510(k) database. It's also one of the most complex to navigate.

The predicate search strategy for SaMD, the documentation FDA expects, and the review timeline all differ meaningfully from traditional hardware device submissions. Here's what you need to know.

Is your software a medical device?

Not all healthcare software requires FDA clearance. The 21st Century Cures Act (2016) explicitly excluded several software categories from device regulation:

• Administrative software (scheduling, billing, claims processing)
• General wellness software (fitness tracking, general health information)
• Electronic health record software
• Software that displays, transfers, or stores medical device data without analyzing or interpreting it
• Software that provides decision support to clinicians based on general principles and allows the clinician to review the basis for the recommendation

Software that analyzes patient data and provides a diagnosis, treatment recommendation, or clinical decision that the clinician cannot independently verify — or where overriding the software recommendation would require significant effort — is generally regulated as a medical device.

SaMD classification and product codes

SaMD classification follows the same Class I/II/III framework as hardware devices, but the risk factors are applied differently. FDA's SaMD framework (adapted from IMDRF guidance) considers two dimensions:

• State of the healthcare situation — critical, serious, or non-serious
• Significance of information provided — treat or diagnose, drive clinical management, or inform clinical management

Software that treats or diagnoses a critical condition (e.g., AI that detects stroke from CT images and recommends treatment) is high risk. Software that informs clinical management for a non-serious condition (e.g., a sleep quality scoring app) is low risk.

Product codes for SaMD are distributed across device panels based on the clinical area. A cardiology AI has a cardiovascular product code. A dermatology image analysis tool has a radiology product code. Finding the right product code for software requires understanding both the clinical application and how FDA has previously classified similar software.

Predicate selection for SaMD

Predicate selection for SaMD follows the same principles as hardware — same product code, same intended use, similar technological characteristics — but "technological characteristics" has a different meaning for software.

For SaMD, technological characteristics include: the algorithm type (rule-based, machine learning, deep learning), input data type (images, signals, text, structured data), output type (diagnosis, score, alert, recommendation), intended user (clinician vs. patient), and deployment environment (cloud, on-premise, mobile).

The hardest part of SaMD predicate search: many cleared AI/ML devices are relatively recent (post-2017), and the technology evolves faster than predicate coverage. You may find that your specific algorithm architecture has few or no direct precedents, requiring either a split predicate strategy or a De Novo application.

Software documentation FDA expects

Beyond the standard 510(k) elements, SaMD submissions require software-specific documentation aligned with IEC 62304 (software lifecycle) and FDA's own software guidance documents:

• Software description — architecture overview, intended operating environment, user interface description
• Software level of concern — major, moderate, or minor, based on injury potential if the software fails
• Software development lifecycle documentation — requirements, design, implementation, verification, validation records
• Hazard analysis — identification of software failure modes and their clinical consequences
• Verification and validation — evidence that the software works as intended under normal and abnormal conditions
• Cybersecurity documentation — for networked or internet-connected devices, FDA's cybersecurity guidance applies

AI/ML-specific considerations

Machine learning devices introduce regulatory complexity that rule-based software doesn't face. FDA's primary concern with ML devices is the "locked algorithm" question — whether the algorithm continues to learn and change after clearance, or is fixed at the version reviewed.

FDA has cleared many locked-algorithm ML devices via 510(k). Adaptive algorithms — those that continue learning from production data — are subject to FDA's evolving predetermined change control plan (PCCP) framework, which requires pre-approval of the types of changes the algorithm may undergo post-clearance.

For a first 510(k) submission, plan to submit a locked algorithm. Incorporate adaptive capability post-clearance through the PCCP mechanism after you've established the initial clearance.

Clinical validation data for SaMD

FDA almost always requires analytical validation data for SaMD — evidence that the algorithm performs as intended on representative patient data. For diagnostic or screening algorithms, this means sensitivity, specificity, positive and negative predictive value on a clinically representative dataset.

The dataset used for validation must reflect the intended use population. An algorithm validated on hospital data cannot claim clearance for home use without additional validation on home-collected data. An algorithm validated on one demographic cannot claim equivalence for diverse populations without representative data.