On September 26, 2019, the US Food and Drug Administration (FDA) published six guidance documents clarifying its scope of authority and enforcement discretion policies in light of the 21st Century Cures Act (Cures Act). The long-awaited draft guidance on Clinical Decision Support (CDS) software sets forth FDA’s proposed approach to regulating CDS, including software that incorporates machine learning (ML) technology. Companies developing ML software for life science applications should consider reviewing FDA’s planned approach to inform their regulatory strategies.

Key highlights from the new guidance documents:

1. Clinical Decision Support (CDS) Software. 

In a long-awaited move, FDA published a draft guidance on CDS software. With the rise of artificial intelligence (AI) and machine learning (ML), CDS presents a novel opportunity to analyze immensely large amounts of data for patterns or other information that may be relevant to a particular patient’s diagnosis. Section 3060(a) of the Cures Act amended the Federal Food, Drug, and Cosmetic Act (FDCA) by removing certain software functions, including CDS, from the definition of “device.” Under the Cures Act, CDS that meets all of the following criteria is no longer subject to regulation by FDA:

a. 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;

b. intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (e.g., clinical practice guidelines);

c. intended for the purpose of supporting or providing recommendations to a health care professional (HCP) about prevention, diagnosis, or treatment of a disease or condition; and

d. intended for the purpose of enabling such HCP to independently review the basis for recommendations that the software presents.

In the draft guidance, FDA provides numerous examples of CDS that would meet these criteria, and hence would not be subject to FDA regulation, including:

• Software that provides HCPs with recommendations on the use of a prescription drug (or medical device) that are consistent with the FDA-required labeling, and where the software describes the recommendations such that the HCP does not rely primarily on the software’s recommendation.

• Software that makes chemotherapeutic suggestions to an HCP based on patient history, test results, and patient characteristics, and describes the basis for the recommendation such that the HCP does not rely primarily on the software’s recommendation.

The ability of an HCP to understand the inputs to the CDS recommendation and make independent judgment based on the recommendation is key to the CDS meeting the exclusion criteria. CDS intended for patient use would not meet the exclusion criteria under the FDCA.

For CDS that does not meet the above exclusion criteria, FDA intends to apply a risk-based approach to regulation. The proposed approach is rooted in software risk categorizations set forth by the International Medical Device Regulatory Forum (IMDRF) in its 2014 framework. The framework categorizes the risk posed by medical device software using two factors: (i) the seriousness of the health condition (i.e., critical, serious, or not serious) and (ii) the significance of the information to the healthcare provider (i.e., whether the information informs clinical management, drives treatment, or diagnosis a patient).

FDA provides the following as examples of CDS software that, although they would meet the definition of “device” under the FDCA, would not be subject to active regulation (i.e., enforcement discretion). The common theme in these examples is the CDS “informs” clinical management for only “non-serious” conditions (using the IMDRF framework):

• Software that provides recommendations of potential allergens and common cold symptoms based on location-specific electronic health records, environmental conditions, and patient-reported outcomes to provide the HCP with options for different diagnoses (e.g., seasonal allergic rhinitis vs. common cold), where the HCP is able to independently evaluate the basis for the software’s recommendations.

• 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.

• Software that provides information to a patient about the use of a prescription drug that is consistent with the FDA-required labeling and the patient’s prescription, such as reminding the patient how or when to take a prescribed drug. Such software does not recommend changes in dose or drug discontinuation that HCPs do not oversee (unless drug labeling includes such recommendations).

• Software that assists a patient in identifying OTC cold or allergy medications to consider purchasing based on symptoms.

According to FDA, software that does more than inform clinical management—e.g., drives clinical decisions or generates a treatment plan—goes beyond CDS and would be subject to active regulation. Also, FDA intends to actively regulate CDS intended to “inform” clinical management for “serious or critical conditions” (using the IMDRF framework) and where the HCP in unable to independently evaluate the basis for the software’s recommendations. FDA provides the following examples of software that it will actively regulate:

• 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.

• Software that calculates the dimensions of a skin lesion and surrounding area and builds a structural map to provide diagnosis or identify whether the lesion is malignant or benign.

• Software that is intended to perform image analysis for diagnostically differentiating between ischemic and hemorrhagic stroke.

• Software that uses a patient’s image sets (e.g., MRI) to create an individual treatment plan for patients undergoing radiation therapy.

Companies developing ML or artificial intelligence software for life science or other medical applications should review FDA’s planned approach, and the numerous example provided, to understand how FDA intends to regulate their software. The intended audience (HCP or patient) and intended use (serious or non-serious conditions) will have a large impact on the available premarket and postmarket regulatory pathways.

2. Electronic health records (EHRs) and other Health IT. 

The Cures Act exempted Personal health records, EHRs, and other Health IT from the definition of “device” if they meet three criteria: (1) they are entered or reviewed by healthcare professionals (or those working under their supervision); (2) are certified under the Office of the National Coordinator (ONC) for Health Information Technology; and (3) are not intended for the analysis of patient records, including medical images, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.

FDA stated in its new guidance, Changes to Existing Medical Device Software Policies Resulting from Section 3060 of the 2st Century Cures Act, that it does not intend at this time to regulate EHR/health IT systems that fail to meet ONC certification, so long as the other criteria are met. As such, there now is no requirement for certification of EHR or health IT software. FDA stated, however, that its approach to health IT systems that contain both non-device functions (e.g., stores patient medical images) and device functions (e.g., provides analysis of patient medical images) will be described in a separate guidance document.

3. Medical Device Data Systems (MDDS) and other Medical Image Storage Devices.

Since 2011, FDA has lifted the regulatory hurdles for MDDS. MDDS are systems that store, transfer, display, and/or convert formats of medical data. MDDS connect to medical devices and act as conduits of medical information but do not change or modify the underlying data. Given their importance in promoting interoperability among devices with disparate sets of data, the FDA announced in 2015 a “hands-off” approach (i.e., a policy of enforcement discretion) toward MDDS that would otherwise meet the definition of a regulated device.

Under the new guidance, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices, FDA explains that the existing definition of MDDS under 21 C.F.R. §880.6310 is inconsistent with the definition in the Cures Act. The Cures Act excludes MDDS software functions from the definition of “device,” but the existing FDA regulation covers both software and hardware. In the guidance, FDA clarifies that MDDS hardware continues to be a device under the FDCA, but—consistent with its approach since 2015—it will exercise enforcement discretion against such hardware.

The new guidance adopts the terms “non-device-MDDS” and “device-MDDS” to distinguish between MDDS software and hardware. Although the terminology is a bit confusing, the bottom line remains the same: MDDS, whether software or hardware, is limited to technology that stores, transfers, displays, or converts medical data. Functions beyond that—such as modifying data, controlling connected devices, or sounding patient alarms based on data received from connected devices—are outside the scope of MDDS and therefore regulated devices. For example, a monitor that sounds a real-time alarm based on a patient’s elevated temperature in an ICU would not be an MDDS (and be regulated); software that transmits a child’s temperature to a parent while the child is in the nurse’s office would qualify as MDDS (and not be regulated).

Similarly, Laboratory Information Systems (LIS) and Laboratory Information Management Systems (LIMS) that are intended for administrative support of laboratories and that transfer, store, convert formats, or display clinical laboratory results remain outside the definition of “device.” LIS and LIMS software that analyze data in order to provide a notification or flag (e.g., that a parameter is out of range), however, continue to be regulated as devices.

4. General Wellness Devices. 

Since the proliferation of personal health and exercise trackers, such as Fitbit, and smart phone apps that monitor health/wellness, FDA’s policy on general wellness “devices” has evolved. In its 2016 guidance, FDA announced a policy of enforcement discretion for “general wellness” products, meaning consumer products intended for maintaining or encouraging a “healthy lifestyle” and that present low risk to users. For example, a bracelet that monitors a user’s pulse rate of while running, app that monitors and records daily energy expenditure during workouts, or an app that tracks sleep patterns are considered general wellness products.

The Cures Act codified FDA’s general wellness policy by excluding from the definition of “device” software functions intended “for maintaining or encouraging a healthy lifestyle” and that are “unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.” The definition is consistent with FDA’s 2016 policy, which provides a hands-off approach to products with healthy lifestyle claims, such as weight management, physical fitness, relaxation or stress management. The difference is that the Cures Act specifically excludes software from the definition of “device.” General wellness hardware, however, continues to be subject potential regulation under the FDCA (if it otherwise meets the definition of a device). In reality, the difference is merely technical because FDA will continue to apply its general wellness policy toward hardware functions.

5. Mobile Medical Apps.

FDA’s update to its Mobile Medical Applications guidance, re-named the Policy for Device Software Functions and Mobile Medical Applications to reflect a broader scope of software, does not introduce new policy. Instead, the modifications reflect the changed definition of “device” introduced by the Cures Act and policy announced in other FDA guidance (described here). For example, mobile apps that function as MDDS have been re-categorized from Appendix B (Examples of mobile apps for which FDA intends to exercise enforcement discretion) to Appendix A (Examples of mobile apps that are NOT medical devices) because the Cures Act specifically excludes MDDS from the definition of “device” under the FDCA.

Similarly, modifications to the existing off-the-shelf software guidance do not introduce new policy and instead reflect the updated medical device definition in the Cures Act.