In a long-anticipated move, the United States Food and Drug Administration (FDA), on September 26, 2019, published six guidance documents clarifying its scope of authority and enforcement discretion policies with regards to Digital Health Content in light of the questions raised by the 21st Century Cures Act (Cures Act).

In this article, we take a look at the FDA’s draft guidance that proposes a framework of regulating Clinical Decision Support (CDS) Software, including software containing machine-learning algorithms (ML).

1. Clinical Decision Support Software

The FDA is accepting comments for this draft guidance until 12/26/2019.

This guidance provides clarity on the scope of the FDA’s oversight of CDS intended for health care professionals (HCPs), patients, or caregivers. CDS broadly means technology that provides HCPs and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care. Section 3060(a) of the Cures Act amended the Federal Food, Drug, and Cosmetics Act (FDCA) by excluding certain CDS software functions that meet all of the following conditions from the definition of “device,” and, thereby, make them no longer subject to FDA regulation:

Criteria:

i. not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;

ii. intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

iii. intended for the purpose of supporting or providing recommendations to a HCP about prevention, diagnosis, or treatment of a disease or condition; and

iv. iv. intended for the purpose of enabling such HCP to independently review the basis for such recommendations that such software presents so that it is not the intent that such HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

The draft guidance describes two types of CDS: Non-Device CDS and Device CDS. Non-Device CDS is consistent with the Cures Act, and includes software functions that meet all four criteria listed above, while Device CDS fails one or more of the above criterion. This draft guidance provides examples of how FDA intends to regulate different kinds of software functions – using these Device or Non-Device CDS designations in conjunction with a risk-based policy as set forth by the International Medical Device Regulatory Forum (IMDRF). The IMDRF risk framework categorizes medical devices based on (i) the seriousness of the health condition (i.e. non-serious, serious, or critical) and (ii) the significance of the information provided to the health provider (i.e. does it inform, drive, or treat/diagnose). Consequently, the FDA will classify and regulate Device and Non-Device CDS according to the following classifications:

Classifications: 

i. Non-Device CDS functions (not regulated by FDA);

ii. Device CDS functions for which, based on current understanding of the risks of these devices, the FDA will NOT enforce compliance with applicable requirements (enforcement discretion);

iii. Device CDS functions on which FDA intends to focus its regulatory oversight; and

iv. Non-CDS device functions on which FDA intends to focus its regulatory oversight.

The FDA provides several examples of Non-Device CDS Functions (i.e. meets all four criteria), with a key factor being whether the HCP is able to use independent judgment based on the software’s recommendation.

  • Software that 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, for example, software suggesting that an HCP order G6PD deficiency tests before starting an antimalarial. The software describes the inputs and basis for the recommendations in such a way that the HCP does not rely primarily on the software’s recommendation.
  • Software that compares patient signs, symptoms, or results with available practice guidelines (institutions-based or academic/clinical society-based) to recommend condition-specific diagnostic tests, investigations, or therapy. The practice guidelines are described as the basis for the recommendation and provided for the HCP to review, such that the HCP does not rely primarily on the software’s recommendation.

CDS functions that fail one or more of the criterions above are, consequently, classified as a Device CDS, but will not be subject to active regulation depending on the risks posed under the IMDRF framework. Key determinations under this category include Device CDS functions that inform clinical management of users for non-serious conditions. The FDA provides several examples.

  • Machine-learning algorithm, for which the logic and inputs are not explained, that trends and classifies patient-specific data (e.g., blood test results, weight) to alert HCPs to potential triggers that may be indicative of cholesterol management issues. At this time, FDA does not intend to enforce compliance with applicable device-requirements for this Device CDS because it intended to provide clinical information for a non-serious situation or condition (i.e., “inform x non-serious”).
  • Software that provides information or general instructions to patients or non-HCP caregivers that are not specific to any drug, biological product, or medical device labeling, such as general pre- and post-surgical care preparation and instructions. This software is Device CDS, because it is intended for a patient (fails criterion 3). At this time, FDA does not intend to enforce compliance with applicable device-requirements because it intended to provide clinical information for a non-serious situation (i.e., “inform x non-serious”), and because it is intended for the patient to be able to independently evaluate the basis for the software’s recommendations.

FDA will focus its regulatory oversight on Device CDS functions intended for HCPs that inform clinical management for serious or critical conditions. Furthermore, this regulatory oversight will also apply for Device CDS functions intended for patients or non-HCPs that inform for serious or critical conditions, regardless of whether the patient can use their independent judgment or not.

  • Machine learning algorithm, for which the logic and inputs are not explained, that identifies hospitalized, type 1 diabetic patients at increased risk of postoperative cardiovascular events. This software is a Device CDS function, because the HCP is not expected to be able to independently evaluate the basis for the software’s recommendations. FDA intends to focus its regulatory oversight on this software, because it is intended to inform clinical management for a critical situation or condition.
  • A software function that provides recommendations to caregivers of pediatric patients with cystic fibrosis by aggregating information on when they should bring such children to the emergency room, based on patient-specific symptoms and care guidelines. This software is a Device CDS function, because it is intended for caregivers (non-HCPS) and to inform clinical management. FDA intends to focus its regulatory oversight on this software, because it is intended to inform clinical management for a critical situation or condition, and because the target population is fragile with respect to the disease or condition.

Lastly, the FDA intends to focus its regulatory oversight on device functions that do not meet the definition of Device CDS under the Cures Act, but that are devices nonetheless. This would include software that does not intend for the independent judgment of the HCPs by attempting to drive clinical management or attempting to diagnose/treat conditions.

  • Software that analyzes near-infrared camera signals of a patient intended for use in determining and/or diagnosing brain hematoma. The software is a device function, because it is intended to analyze a medical signal and to aid in diagnosis.
  • Software that uses a patient’s image sets (e.g., CT, magnetic resonance (MR)) to create an individual treatment plan for review by an HCP for patients undergoing radiation therapy treatment with external beam or brachytherapy. This software is a device function, because this software is intended to analyze a medical image and to generate the treatment plan, which is intended to guide the next treatment intervention.
  • Software intended to generate an alarm or an alert to notify a caregiver of a life threatening condition, such as stroke, and the caregiver relies primarily on this alarm or alert to make a treatment decision. This software is a device function, because it is intended to analyze a medical signal and to aid in treatment of a disease or condition.

This draft guidance published by the FDA represents a critical framework for potential regulation of companies engaged in machine-learning, artificial intelligence, and CDS in the digital health environment. Companies should evaluate their products’ intended audiences (HCP or patient/caregiver), intended use-cases (non-serious, serious, or critical conditions), and effect on clinical judgment (inform, drive, or treat/diagnose) in order to most effectively navigate the FDA’s proposed regulatory framework.