Member News

Software as a Medical Device: FDA Releases Draft Guidance

Companies that develop software that functions as a medical device should be aware that the Food and Drug Administration (FDA) has issued draft guidance that, once finalized, will classify the endless variety of Software as a Medical Device (SaMD), and impose risk-based criteria for evaluating the safety and effectiveness of such software. The draft guidance, titled Software as a Medical Device (SaMD): Clinical Evaluation,” is an attempt to determine what type of clinical evaluation is appropriate for SaMD that have growing patient and public health impact.

The October 14 release of draft guidance opens a 60-day comment period concluding on December 13, 2016, during which time the FDA welcomes written or electronic submissions before it issues a final version. Pepper lawyers are available to answer any questions about the draft guidance or to assist in submitting comments.

What Does the FDA Consider SaMD?

The FDA draft guidance defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” The document also includes a few notes clarifying the definition:

  • SaMD is a medical device and includes mobile apps and in-vitro diagnostic (IVD) medical devices.
  • SaMD is capable of running on general purpose (non-medical purpose) computing platforms.
  • “Without being part of” means software not necessary for a hardware medical device to achieve its intended purpose.
  • Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device.
  • SaMD may be used in combination (e.g., as a module) or interfaced with other products including medical devices, other SaMD software, and general purpose software.

Applying the definition, some examples of SaMD include software that: allows a commercially available smartphone to view images for diagnostic purposes obtained from an MRI scan; processes images from hardware medical devices for aiding in the detection of breast cancer ; or provides parameters that become the input for a different hardware medical device or other SaMD. SaMD does include mobile applications, provided they meet the other definitional requirements of SaMD. Software that would not be considered SaMD includes software that: drives or controls the pumping of medication in an infusion pump; encrypts data for transmission from a medical device; or enables such clinical communication and workflow as patient registration, scheduling visits, voice calling and video calling.

On February 9, 2015, FDA issued final guidance on “Mobile Medical Applications” specifically, but the release of new draft guidance relating to SaMD demonstrates a broader consideration of software regulated as a medical device. Mobile medical application vendors should be familiar with and adhere to both sets of guidance.

Risk-Based Criteria for Categorization and Clinical Evaluation of SaMD

The FDA sets forth risk-based criteria for recommending how a SaMD manufacturer must gather, analyze and evaluate data, and develop evidence to demonstrate the assurance of safety, effectiveness and performance of the SaMD. This is consistent with the mobile medical applications risk-based approach for enforcement the FDA articulated in its guidance on Mobile Medical Applications. See FDA has grouped SaMD by category (I-IV) based on two main factors: the significance of the information provided by the SaMD (inform clinical management, drive clinical management, or treat or diagnose) and the state of the healthcare situation or condition (non-serious, serious or critical). The new risk-based categories of SaMD should not be confused with and are not intended to inform FDA medical device classifications or PMA/510K status. Nor does the draft guidance explain how it is supposed to work with FDA regulations and medical device classifications.

Relying on the risk-based category framework, the draft guidance lays out the level of evidence required for clinical evaluation by category and device type (see Figure 8 – Summary of Clinical Evidence and Expectations by SaMD Category chart linked here). Types of evidence required include analytical validity, scientific validity, and clinical performance. Analytical validity refers to the ability of the SaMD to accurately and reliably generate the intended output from the input data. Analytical validity is always expected for an SaMD. Scientific validity establishes how accurately the output of the SaMD correlates with the intended clinical health care situation or condition of the intended use of the SaMD. Clinical performance is the ability of the SaMD to yield a clinically meaningful output associated with the target use of the SaMD output in the health care situation or condition identified in the SaMD definition statement. Clinical performance can be determined during development of the SaMD both before and after marketing the product. For each type of evidence, the draft guidance explains general methods for generating that evidence.

As with the level of evidence, the importance of independent review of evidence and data increases as the risk level and corresponding category of device increases.

For example, consider SaMD concerning malignant skin lesions. These lesions would be considered a critical healthcare situation or condition. Software that uses photos with rulers next to them and tracks the changes over time in terms of size and appearance would “inform clinical management” and put the SaMD in Category II.i. As a result, clinical evaluation of the device would require only evidence of analytical validity and scientific validity, without requiring evidence of clinical performance or independent review. Contrast this with another software that uses a high-magnification lens and external UV light source that detects cells typical of malignant melanoma. The health condition would still be considered critical, but the purpose of the device would be to “diagnose,” elevating it to Category IV.i. Clinical evaluation would then require a higher level of evidence, including scientific validity, analytic validity, and clinical performance. At this point, independent review would be important.

SaMD vs. Standard Medical Devices: Continuous Monitoring and Evolution

The draft guidance also emphasizes that unlike other medical devices where real-world experience is difficult to gather, the way “SaMD may leverage technology and connectivity i.e., the seamless communication between devices, technology and people to continuously monitor safety, effectiveness and performance of the SaMD” is unique. This makes continuous monitoring of clinical evaluation even more important and achievable. The focus is shifted towards “observed real world performance as part of post-market monitoring.”

The uniqueness of SaMD also allows for fluidity in the categorization of the devices and the ability of the devices to evolve over time. Learning may impact the original categorization of the SaMD, or could provide opportunities for evolution of the intended use of the device after introduction into the market.

Unanswered Questions from the Draft Guidance

The descriptions in the draft guidance give a theoretical explanation of the risk-based approach (demonstrated in Figure 8 – Summary of Clinical Evidence and Expectations by SaMD Category chart linked here), but are necessarily vague on what would constitute the required data for clinical evaluation. For example, the draft guidance states “[t]he SaMD manufacturer is responsible for identifying relevant data and determining the types and amount of data needed to establish clinical performance, and considering the advantages and limitations of each data type.” It also says that clinical performance studies do not necessarily imply “prospective randomized controlled trials.” This lack of detail may become confusing for manufacturers as it does not relate any of the risk-based categories to the existing regulatory scheme and the categories do not replace any existing classifications or 510K or PMA requirements.

The draft guidance was first prepared by the International Medical Device Regulators Forum (IMDRF), formerly the Global Harmonization Task Force, before being submitted for comment by the FDA. Although the draft guidance does not explain how it relates to the existing FDA regulatory framework, it does rely on concepts and definitions found in earlier IMDRF publications. These publications include: Software as a Medical Device (SaMD): Key Definitions (N10); Software as a Medical Device (SaMD): Possible Framework for Risk Categorization and Corresponding Considerations (N12); and Software as a Medical Device (SaMD): Application of Quality Management System (N23). There are also references to other Global Harmonization Task Force documents and international standards. The FDA has not stated whether it intends to incorporate any of these other documents into the draft guidance by reference. The current document does, however, restate the IMDRF definition of SaMD and relies upon the IMDRF framework for risk categorization. These references suggest the FDA may at least acknowledge the fundamental definitions and risk categorization framework outlined in the earlier IMDRF publications on SaMD.


Overall, the Draft Guidance seeks to ensure that appropriate principles for clinical evaluation are applied to SaMD as they would be applied to other medical devices, utilizing a risk-based approach, to ensure patient safety. But it also acknowledges the unique qualities of SaMD that inform methods for continuous clinical evaluation and potential evolution of the device.

As noted previously, the 60-day comment period on the draft guidance ends on December 13, 2016. If you have questions or need assistance crafting comments on the draft guidance, please contact one of the authors or other members of Pepper’s Digital Health team.

Compliments of Pepper Hamilton – a member of EACCNY