Last month, the US Food and Drug Administration’s (FDA) Center for Device and Radiological Health (CDRH) issued a Draft Guidance for industry entitled Software as a Medical Device (SaMD): Clinical Evaluation (Draft Guidance).  The Draft Guidance was developed by the International Medical Device Regulators Forum (IMDRF), of which FDA is a member, and demonstrates FDA’s continued focus on the growing importance of software in healthcare (our discussion of other software-related FDA guidances is available here).  Once finalized, the Draft Guidance will classify the whole gamut of SaMD and establish globally harmonized risk-based criteria for assessing the software’s safety and effectiveness.

Comments on the Draft Guidance are due to CDRH by December 13, 2016 (Docket No. FDA-2016-D-2483).  Once the comment period closes, a final version of the Draft Guidance will be submitted to the IMDRF management committee in February 2017.

The Draft Guidance relies on IMDRF concepts and definitions to define SaMD, outline clinical evaluation methods that would be useful for SaMD and to determine the appropriate level of clinical evidence required by SaMD in categories established in a 2014 IMDRF final guidance.

“Based on the significant impact SaMD has on clinical outcomes and patient care, a SaMD manufacturer is expected to gather, analyze, and evaluate data, and develop evidence to demonstrate the assurance of safety, effectiveness and performance of the SaMD,” the Draft Guidance states.

What is a SaMD?

As defined in the Draft Guidance, SaMD is “software intended to be used for one or more medical purposes that perform these purposes without begin part of a hardware medical device.”  SaMD runs on general computing platforms and is not intended to drive a hardware medical device; therefore, it does not come into direct contact with patients.  SaMD may be used in combination with other products including medical devices, and also may be interfaces with other medical devices, SaMD software, and general purpose software.

Mobile applications that meet the above definition are considered SaMD and are therefore subject to the applicable requirements under the Draft Guidance.  Note that these new requirements are in addition to the requirements imposed on mobile medical application vendors by the 2015 FDA Guidance for Industry: Mobile Medical Applications (MMA Guidance).

Other examples of SaMD include software that diagnose a condition using the triaxial accelerometer that operated on the embedded processor on a digital camera, performs image post-processing for the purpose of aiding in the detection of breast cancer running on a general purpose computing platform located in the image-acquisition hardware medical device, conducts treatment planning by supplying information used in a linear accelerator, and allows commercially available smartphone to view images for diagnostic purposes obtained from a MRI.

Risk-Based Evaluation of SaMD

Consistent with the MMA Guidance’s risk-based enforcement approach, the Draft Guidance lays out a risk-based criteria on how to regulate different kinds of software and what kind of evidence is needed for each regulatory category.  The Draft Guidance proposes to stratify software into categories I-IV based on two factors: whether the device informs care, drives care, or treats/diagnoses and whether the condition in question is non-serious, serious, or critical.  As such, software that treats or diagnoses a critical condition is in the highest risk category, while software that informs care about a non-serious condition is in the lowest.  The Draft Guidance does not mention how the SaMD categories fit together with the FDA medical device classifications and associated regulations.

Section 8.5 of Draft Guidance includes a chart summarizing the clinical evidence and expectations by SaMD category.  Types of evidence required include analytical validity (i.e., the technical performance related to accuracy, reliability, and reproducibility), scientific validity (i.e., the association of the SaMD output to a clinical condition/physiological stated), and clinical performance (i.e., the ability of a SaMD to yield a clinically meaningful output associated to the target use of SaMD output in the healthcare situation).  Also, the higher the risk level and category of the SaMD, the higher the importance of independent review of the evidence.

The Draft Guidance recognizes the need to incorporate continuous clinical evaluation into the lifecycle of all software devices, regardless of clinical significance.  As such, depending on post-marketing data, including real-world evidence, a SaMD may be re-categorized.

*             *             *

Overall, the Draft Guidance is a significant step in establishing common clinical evaluation principles for demonstrating the safety, effectiveness, and performance of SaMD.  Nonetheless, there are some holes.  For example, while the Draft Guidance acknowledges the value of collecting real-world evidence, it does not clearly articulate the circumstances when such evidence can replace a premarket clinical study.  Further, it is difficult to discern exactly what data is required for clinical evaluation.  Lastly, FDA has not explained how the Draft Guidance fits in with IMDRF’s other publications or whether IMDRF’s related publications will be incorporated by reference into the Draft Guidance.  The final version of the Draft Guidance may shed light on some of these issues.