Regulatory Guidance on SaMD
In December of 2017, the FDA released a guidance document addressing software used for medical purposes that is not part of a hardware device. The document, Software as a Medical Device (SAMD):Clinical Evaluation; Guidance for Industry and Food and Drug Administration Staff, December 7, 2017, was originally drafted by the International Medical Device Regulators Forum (IMDRF)—of which the FDA is a member. The intent is for the guidelines to be applicable to SaMD developers worldwide.
The guidance defines SaMD as software (not part of a hardware medical device) used to
•Treat or Diagnose
•Drive Clinical Management
•Inform Clinical Management
The software can run on general purpose (non-medical purpose) computing platforms, such as a smartphone, tablet, or PC. Additionally, it may be used in combination or interfaced with other products, including hardware medical devices, other SaMD, and/or general-purpose software. Examples are:
•Mobile apps
•In-vitro diagnostic (IVD) medical devices.
The guidance excludes software that retrieves information, organizes data or optimizes processes as well as software that is part of, or embedded in, a medical device whose intended purpose is to drive the hardware medical device.
The guidance recognizes that “Development of SaMD is … heavily influenced by new entrants unfamiliar with medical device regulations and terminology developing a broad spectrum of applications.” Additionally, the technology format is dynamic, fluid and capable of real-time connectivity. Therefore, there is some flexibility based on a software’s targeted function and risk categorization.
However, SaMD will need to meet many of the compliance guidelines applicable to hardware medical devices. This means that developers will still need a quality management system for document control, verification, and validation as well as other elements to comply with regulations.
The design control process for SaMD, as well as verification and validation, should be managed under a process suitable for creating reliable software and being certain that risks are properly mitigated. Using a software life cycle process, such as IEC 62304:2006 Medical device software -- Software life cycle processes, will create a framework for determining software risks, software risk mitigation, developing software and performing verification and validation on the software in a structured, traceable framework.
Developers and quality professionals will still need to make risk-based criteria and clinical evaluation a priority despite the unique nature of stand-alone healthcare apps. Aggregation of specific data for compliance and the demand for efficiency highlight the importance of a reliable Quality Management System, as well as a robust software development framework.