Short Summary
Obtaining SaMD certification requires a clear understanding of regulatory requirements, proper classification of the device based on risk, and the implementation of a Quality Management System.
Key elements include compliance with standards such as ISO 13485 and IEC 62304, clinical validation, and comprehensive documentation.
Post-market surveillance is crucial for maintaining ongoing safety and effectiveness after certification.
Risk Categorisation for SaMD
The first step in the certification process is to classify the software based on its risk level (I, II, III, and IV).2
Healthcare Situation | Health Care Decision provided by SaMD | ||
Treat or Diagnose | Drive Clinical Management | Inform Clinical Management | |
Critical | IV | III | II |
Serious | III | II | I |
Non-Serious | II | I | I |
According to the FDA's risk classification system, Level IV corresponds to Software as a Medical Device (SaMD) with the highest potential impact on patient or public health, whereas Level I represents the lowest level of impact.
Implementation of Quality Management Systems
To achieve SaMD certification, it is essential to demonstrate that your software is developed in accordance with recognized quality and safety standards. Key standards include:
ISO 13485: This global standard outlines the requirements for Quality Management Systems (QMS) specific to medical devices, establishing criteria for documentation, risk management processes, and ongoing post-market monitoring.
IEC 62304: This standard focuses on medical device software development, providing a framework for the software life cycle processes.
ISO 14971: This standard details the risk management process for medical devices, ensuring that your software is safe and does not pose unnecessary risks to users.
21 CFR Part 820: Issued by the FDA, these regulations govern the Quality System Regulations for medical device manufacturers.
Risk Management
Risk management is a vital aspect of SaMD certification. The software must undergo thorough testing to identify and mitigate associated risks, including:
Risk Analysis: Identifying potential hazards (e.g., functionality errors or cybersecurity vulnerabilities) that could harm users or lead to mistakes.
Risk Control: Implementing measures to minimize risks to an acceptable level.
Residual Risk: Evaluating and documenting any remaining risk after mitigation.
All risk management activities and mitigation processes throughout the software lifecycle must be documented.
Clinical Evaluation and Validation
Depending on the software’s risk classification and intended use, clinical evaluations or trials may be necessary to demonstrate its performance and effectiveness in real-world scenarios:
Clinical Trials: Required for higher-risk devices (Class II and III) to confirm that the software performs as intended in actual clinical settings.
Clinical Evidence: If possible, gather data from real-world use cases to demonstrate the software’s safety and effectiveness.
Regulatory Documentation
A comprehensive set of documentation is required for submission to regulatory authorities. Commonly required documents include:
Technical File: This includes detailed information about the software’s design, development, and testing processes, along with documentation proving compliance with regulatory standards.
Risk Management Report: A detailed report documenting all risk analyses and mitigation efforts throughout the software lifecycle.
Clinical Evaluation Report: If applicable, this report demonstrates the software’s safety and efficacy using clinical data.
Software Validation Report: This confirms that the software has been thoroughly tested and validated to meet safety, quality, and performance standards.
