On December 7th, the Food and Drug Administration (FDA) announced the release of a much-anticipated suite of guidance documents that loosen the regulatory requirements for digital health technologies. By clarifying what is – and what is not – subject to regulation, this set of guidance could create significant opportunities for digital health investors and innovators.

The FDA guidance is the latest stanza in FDA Commissioner Scott Gottleib’s effort to create a regulatory framework that reduces barriers to bringing products to market. To be fair, the FDA has been evolving its thinking on regulation of the digital health space for some time. For example, the discussion about how to regulate Clinical Decision Support (CDS) software dates back to 2011. That said, the most recent guidance documents mark a significant step forward in defining the regulatory landscape.

The package released last week consists of three guidance documents – one final and two drafts. The first, is CDS guidance, which sets out three key elements for deregulation of certain digital health software:

  1. Those that are not subject to regulation because they do not meet the definition of a medical device as amended by the 21st Century Cures Act (Cures);
  2. Those that may meet the definition of a medical device but for which FDA does not intend to enforce compliance with applicable requirements of the Food Drug and Cosmetic Act, including, but not limited to, premarket clearance and premarket approval requirements; and
  3. Those on which the FDA intends to focus its regulatory oversight.

Importantly, the guidance creates the standard for regulation by stating that CDS software “that allows for the provider to independently review the basis for the recommendations are excluded” from the FDA’s purview. Software programs that analyze medical images, signals from in vitro diagnostic devices, or patterns acquired from a processor like an electrocardiogram that use analytical functionalities to make treatment recommendations will still be considered medical devices and subject to oversight and regulation.

To illustrate the thresholds, the CDS guidance, starting on page 8, gives a host of examples of what technologies that the FDA doesn’t consider devices and are, thus, not subject to regulation. These include software that:

  • provides recommendations to health care providers by matching patient specific information (e.g., diagnosis, treatments, allergies, signs or symptoms) to reference information the medical community routinely uses in clinical practice (e.g., practice guidelines) to facilitate assessments of specific patients; and
  • suggests an intervention or test, consistent with clinical guidelines and/or drug labeling, based on or in response to a physician’s order, such as software suggesting that a health care professional order liver function tests before starting a statin.

Examples of the types of software the FDA does intend to regulate are:

  • Software that manipulates or analyzes images and other data obtained from a radiological device (e.g., CT, bone density, and distance) to create 3D models of the region intended to be used in planning orthopedic/dental surgical treatments with a device;
  • Software that customizes the patient-specific surgical plan and instrumentation based on analysis of imaging and device characteristics for orthopedic or dental implant 300 procedures;
  • Software that analyzes multiple physiological signals (e.g., sweat, heart rate, eye movement, breathing – from FDA-regulated devices) to monitor whether a person is having a heart attack or narcolepsy episode; and
  • Software that makes chemotherapeutic suggestions to a health care professional based on patient history, test results, and patient characteristics, including, for example, software suggesting a platinum-based chemotherapy for BRCA-positive individuals that is consistent with the drug labeling.

This guidance was the first time that FDA articulated specific types of CDS software.

The second guidance, also in draft, intends to clarify that, per Section of 3060 of Cures, “that certain digital health technologies – such as mobile apps that are intended only for maintaining or encouraging a healthy lifestyle – generally fall outside the scope of the FDA’s regulation.” However, if the software is for “diagnosis, cure, mitigation, prevention, or treatment of a disease or condition” then the guidance states that is not excluded from the definition of a medical device and therefore subject to regulation. The guidance gives three examples of applications that are not considered devices:

  • A mobile application that plays music to “soothe and relax” an individual and to “manage stress” (Illustrative Example 1)
  • A mobile application that solely monitors and records daily energy expenditure and cardiovascular workout activities to “allow awareness of one’s exercise activities to improve or maintain good cardiovascular health” (Illustrative Example 2) ·
  • A mobile application that monitors and records food consumption to “manage dietary activity for weight management and alert the user, healthcare provider, or family member of unhealthy dietary activity” (Illustrative Example 3)

Also of note is that the guidance states that when it is finalized, it will be “ incorporated into the following guidance documents: General Wellness: Policy for Low Risk Devices, issued July 29, 2016; Mobile Medical Applications, issued February 9, 2015; Off-The-Shelf Software Use in Medical Devices, issued September 9, 1999; Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices, issued February 9, 2015.

The third guidance is aimed at harmonizing the FDA’s efforts with international regulatory efforts. The document was produced by the International Medical Device Regulators Forum (IMDRF). The IMDRF is a global group of medical device regulators, including the FDA. Specifically, the document “provides a path for global regulators to converge on terminology, a risk-based framework, an understanding of quality management system principles” Software as a Medical Device (SaMD). For reference, SaMD is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. This final guidance that first appeared in draft in 2016. While the guidance states that it is not a regulation in and of itself, it should not be overlooked as the FDA will consider the principles when developing its own regulations. Further, it demonstrates that the FDA is looking to reduce the instances where U.S.-based digital health companies could be disadvantaged.

Comments will be accepted on the CDS and Cures guidance’s for 60 days. For the CDS guidance, comments are may be submitted here and for the Section 3060 guidance, comments may be submitted here. Comments on both of these guidances are due no later than February, 6, 2018. We will continue to monitor developments as these guidances become finalized and implemented