Software as a Medical Device (SaMD)

SaMD operates on general-purpose computing platforms (e.g., smartphones, cloud servers, workstations) without being embedded in a physical medical device. Its medical functionality is entirely software-driven.

• Key distinction: If the software is necessary for a hardware medical device to function, it is not SaMD—it is software in a medical device (SiMD).
• Example: A radiology image processing app running on a commercial tablet is SaMD; the firmware inside an MRI machine is not.

SaMD must perform one or more medical purposes without being part of a hardware medical device. These purposes include:

• Diagnosis or screening: Detecting or identifying a disease or condition.
• Monitoring: Tracking physiological processes or disease progression.
• Prediction: Forecasting the likelihood of a clinical event or outcome.
• Treatment or therapy: Providing recommendations that directly influence patient management.
• Mitigation: Reducing the severity of a disease or condition.

SaMD is classified by regulatory bodies based on the severity of the clinical condition and the significance of the information it provides to the healthcare decision.

• Class I (Low Risk): Software that informs clinical management for non-serious conditions.
• Class II (Moderate Risk): Software that aids in diagnosis or triage for serious conditions.
• Class III (High Risk): Software that provides critical information for life-threatening conditions where an error could lead to patient death or irreversible harm.
• Example: A melanoma detection app suggesting biopsy is Class III; a calorie tracking app is not SaMD at all.

The route to market depends on the device's novelty and risk profile:

• 510(k) Premarket Notification: Demonstrates substantial equivalence to a legally marketed predicate device. Most common for moderate-risk SaMD.
• De Novo Classification: For novel devices of low-to-moderate risk with no predicate. Creates a new classification regulation.
• Premarket Approval (PMA): The most stringent pathway, reserved for high-risk Class III devices requiring clinical evidence of safety and effectiveness.
• Example: An AI-based retinal screening tool with no predicate would pursue the De Novo pathway.

SaMD is categorized by whether its algorithm changes after deployment:

• Locked Algorithm: The model's parameters are fixed. Any update requires a new regulatory submission unless covered by a Predetermined Change Control Plan (PCCP).
• Adaptive Algorithm: The model learns from new data in real time. This requires rigorous pre-authorization of the learning mechanism, boundaries, and monitoring plan.
• Regulatory expectation: Manufacturers must define the scope of allowed modifications before deployment, not seek forgiveness after.

SaMD development demands a structured Quality Management System (QMS) and comprehensive documentation:

• IEC 62304: Governs software development lifecycle processes, from planning to maintenance.
• ISO 14971: Mandates systematic risk management throughout the product lifecycle.
• Design History File (DHF): A complete record proving the device was developed according to the approved design plan.
• Software Bill of Materials (SBOM): A formal inventory of all third-party and open-source components, critical for cybersecurity risk assessment.

The foundational regulatory statements that define a SaMD's purpose and scope. The Intended Use Statement declares the general purpose (e.g., diagnosis, screening), while the Indications for Use precisely specify the patient population, anatomical site, and clinical context. These statements determine the device classification and the stringency of the required premarket submission. A narrow, well-defined indication is critical for a successful regulatory pathway.

The international standard for medical device software development and maintenance. It classifies software safety into three classes (A, B, C) based on the severity of potential harm. Compliance requires a documented Software Development Plan, rigorous Software Requirements Specification, and detailed architectural design. For SaMD, this standard mandates strict configuration management and problem resolution processes throughout the entire lifecycle.

A regulatory mechanism specifically for machine learning-enabled SaMD. A PCCP is an FDA-authorized plan that details the types of modifications a manufacturer intends to make to a model post-clearance without requiring a new 510(k). It defines the SaLPM (Software as a Medical Device Pre-Specifications)—the planned changes to performance, inputs, or intended use—and the Algorithm Change Protocol (ACP)—the verification methods to ensure safety and effectiveness are maintained.

The evidence generation process required to demonstrate a SaMD's safety and performance. Analytical Validation assesses the technical accuracy of the algorithm's output in a controlled setting. Clinical Evaluation goes further, verifying that the device achieves its intended purpose in the target patient population, generating real-world clinical data. This process is continuous, feeding into Post-Market Surveillance (PMS) to monitor ongoing safety.

A mandatory, iterative process for SaMD, governed by FDA guidance. It requires a Cybersecurity Risk Assessment to identify threats and vulnerabilities, a Software Bill of Materials (SBOM) to list all third-party components, and a plan for coordinated vulnerability disclosure. The goal is to ensure the device's safety and effectiveness are not compromised by cyber exploits, with security controls integrated into the design from the outset.

The formalized organizational backbone for SaMD development, typically aligned with ISO 13485. A QMS documents all processes, procedures, and responsibilities for design, production, and post-market activities. Key outputs include the Design History File (DHF), which proves the device was developed according to plan, and the CAPA (Corrective and Preventive Action) system, which manages nonconformities and drives continuous improvement.