Software as Medical Device (SaMD)
Software as a Medical Device (SaMD) is defined by the International Medical Device Regulators Forum (IMDRF) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." SaMD runs on general-purpose computing platforms (smartphones, cloud servers, desktop computers) and is distinct from software that is embedded in or controls a hardware medical device (Software in a Medical Device, SiMD).
IEC 62304 Software Life Cycle
IEC 62304:2006+AMD1:2015 defines the life cycle processes for medical device software. It is recognized by FDA and listed as a harmonized standard under the EU MDR. The standard requires software to be classified into one of three safety classes, which determines the rigor of documentation and processes required:
| Safety Class | Definition | Required Activities |
|---|---|---|
| Class A | No injury or damage to health is possible | Software development planning, requirements analysis, risk management, configuration management, problem resolution |
| Class B | Non-serious injury is possible | All Class A activities plus: architectural design, detailed design (partial), unit/integration/system testing, design verification |
| Class C | Death or serious injury is possible | All Class B activities plus: detailed design for all units, unit verification, additional documentation rigor throughout |
Key IEC 62304 processes include software development planning, software requirements analysis, software architectural design, software detailed design, software unit implementation, software integration and integration testing, software system testing, software release, software maintenance, software configuration management, software problem resolution, and software risk management (which connects to ISO 14971).
IMDRF SaMD Classification
The IMDRF framework (documents N10, N12) classifies SaMD based on two dimensions: the significance of the information provided by the SaMD to the healthcare decision, and the state of the healthcare situation or condition.
| State of Healthcare Situation | Treat or Diagnose | Drive Clinical Management | Inform Clinical Management |
|---|---|---|---|
| Critical | Category IV | Category III | Category II |
| Serious | Category III | Category II | Category I |
| Non-Serious | Category II | Category I | Category I |
Category IV represents the highest risk (e.g., SaMD that diagnoses a critical condition), and Category I represents the lowest (e.g., SaMD that informs management of a non-serious condition). FDA has adopted this framework in its guidance documents.
FDA Guidance on Clinical Evaluation
FDA's "Software as a Medical Device (SaMD): Clinical Evaluation" guidance (based on IMDRF N41) establishes expectations for demonstrating SaMD clinical validity. The level of clinical evidence required depends on the SaMD category:
- Valid clinical association: Is there a clinically valid association between the SaMD output and the targeted clinical condition?
- Analytical validation: Does the SaMD correctly process input data to generate accurate, reliable, and precise output?
- Clinical validation: Does the SaMD produce clinically meaningful output in the target population under defined conditions of use?
Higher-risk categories (III, IV) require more rigorous clinical evidence. Category I SaMD may rely primarily on analytical validation with supporting clinical literature, while Category IV SaMD typically requires prospective clinical studies.
Software Documentation Levels
FDA's guidance "Content of Premarket Submissions for Device Software Functions" (2023) defines documentation expectations based on the risk level of the software function:
| Documentation Level | Risk Level | Required Documentation |
|---|---|---|
| Basic | Minor: failure unlikely to cause injury | Software description, system/software architecture diagram, software risk assessment summary, unresolved anomaly list |
| Enhanced | Moderate: failure could cause non-serious injury or impede treatment | Basic documentation plus: software requirements specification (SRS), architecture design chart, software design specification, traceability analysis, software testing as part of V&V |
| Comprehensive | Major: failure could cause serious injury or death | Enhanced documentation plus: complete SRS with traceability to tests, detailed architecture and design specifications, full V&V protocols and reports, unresolved anomaly analysis with risk assessment |
Cybersecurity Requirements
FDA's guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (2023) establishes premarket and postmarket cybersecurity expectations for devices with software functions:
Premarket Expectations
- Threat modeling and security risk assessment throughout the device lifecycle
- Security architecture documentation including security controls
- Software Bill of Materials (SBOM) in machine-readable format
- Cybersecurity testing (vulnerability scanning, penetration testing, fuzz testing)
- Security design and development practices (secure by design)
- Plans for addressing post-market cybersecurity vulnerabilities
- Defined end-of-support date for cybersecurity updates
Postmarket Expectations
- Coordinated vulnerability disclosure process
- Monitoring for new vulnerabilities (e.g., through SBOM component tracking)
- Timely deployment of patches and updates for identified vulnerabilities
- Communication of cybersecurity information to users and customers
- Cybersecurity events may need to be reported under MDR requirements (21 CFR 803)
AI/ML-Enabled SaMD
FDA has published specific guidance for AI/ML-based SaMD, including the "Artificial Intelligence and Machine Learning (AI/ML)-Enabled Device Software Functions" guidance and the Predetermined Change Control Plan framework. Key considerations include:
- Good Machine Learning Practice (GMLP) principles
- Data management practices (training, validation, and test datasets)
- Transparency and explainability of algorithm outputs
- Predetermined Change Control Plans for modifications to ML algorithms without requiring a new submission
- Real-world performance monitoring for continuous learning algorithms
- Bias assessment and mitigation across diverse patient populations