On December 8, FDA addressed the agency’s evolving approach to digital health by issuing two new draft guidance documents: “Clinical and Patient Decision Support Software” (the “CDS Draft Guidance”) and “Changes to Existing Medical Software Policies Resulting From Section 3060 of the 21st Century Cures Act” (the “Software Policies Draft Guidance”). These draft guidances announce the agency’s initial interpretation of the health software provisions enacted as part of last year’s 21st Century Cures Act (the “Cures Act”).

Given the rapid pace of digital health innovation across the life sciences, technology and health care sectors, FDA guidance on these topics is critical. Here are a few key takeaways from the draft guidances:

• FDA’s initial interpretation of the Cures Act provision related to clinical decision support (CDS) software may lead to a fairly narrow carve-out—in other words, many cutting-edge CDS software functions could remain subject to FDA regulation.
• FDA’s draft guidances do not directly address dynamic digital health solutions, such as those that incorporate machine learning, artificial intelligence (AI), or blockchain.
• FDA has proposed an enforcement discretion approach for decision support software aimed at patients that generally parallels the regulatory approach for CDS software aimed at clinicians, even though patient decision software was not addressed directly in the Cures Act.
• Consistent with the Cures Act, FDA’s draft guidances reflect that many of the software functions that were previously subject to FDA enforcement discretion (i.e., not actively regulated as devices) no longer meet the definition of “device.”
• Significant for pharmaceutical companies, CDER joined one of the draft guidances, and that draft guidance makes clear that other FDA requirements may apply to digital health products disseminated by or on behalf of a drug sponsor beyond those outlined in the draft guidance.

FDA’s regulatory approach has a significant impact on the investment in and development of digital health solutions across the digital health ecosystem. Stakeholders should consider submitting comments to the agency to help shape the direction of FDA’s final guidances on these topics.

Background

Over the last few years, FDA has outlined its approach to regulating digital health technologies in a series of agency guidance documents. At the end of last year, Congress made statutory changes to FDA’s authority over digital health in the Cures Act, which excluded certain low-risk software functions from the statutory definition of “device.” More information on those statutory changes can be found in our prior alert.

The Cures Act largely aligned with the agency’s existing approach to regulating digital health, but stakeholders had advocated for statutory changes in order to create more regulatory certainty (given FDA can change an enforcement discretion policy at any time). After much debate, Congress decided which software functions should be excluded from FDA’s “device” definition, and which functions should remain within the definition of device and, therefore, within the agency’s device jurisdiction. Congress also provided FDA with a means to “pull back” excluded functions into FDA jurisdiction under certain scenarios.However, like any statutory provision, the digital health provisions of the Cures Act contained areas that left room for interpretation. The draft guidance documents released by FDA are the first official indication of the agency’s position regarding those provisions.

CDS Software, Machine Learning, Artificial Intelligence

FDA’s initial interpretation of the CDS software provision of the Cures Act could lead to fewer cutting-edge technologies falling outside of FDA regulation than many stakeholders had expected following enactment of the Cures Act.

Specifically, one key factor for excluding CDS functions from FDA’s “device” definition under the statute is that the software must enable a healthcare professional to “independently review” the basis for the recommendation, so that it is not the intent that a healthcare professional “rely primarily” on the recommendation made by the CDS software. The CDS Draft Guidance states that, in order to meet this statutory exclusion, the user should be able to reach the same recommendation on his or her own without relying primarily on the software function. It further states that sources supporting or underlying the rationale for the recommendation should be publicly available (e.g., based on clinical practice guidelines and published literature). According to the draft guidance, a “practitioner would be unable to independently evaluate the basis of a recommendation if the recommendation were based on non-public information.”

This initial interpretation results in two noteworthy implications:

• Software that provides recommendations based on proprietary algorithms, complex analyses of large datasets or “big data”, or utilizing machine learning or AI, might not meet this statutory exclusion under FDA’s initial interpretation, and thus would be subject to FDA regulation.
• If the clinician could not independently develop the same recommendation as the software, the CDS software could be subject to FDA regulation, even if it is intended that the trained clinician act as an independent “check” by utilizing her or his own clinical judgment regarding the output of the software in clinical decision-making. In other words, even where the risk of a CDS function is mitigated by the fact that a trained clinician must assess the output of the CDS software and exercise independent clinical judgment regarding the recommended decision, the software function may still be subject to FDA regulation as a device.

Another key factor in excluding a CDS function from the “device” definition is that the CDS function cannot acquire, process, or analyze (i) a medical image or (ii) a signal from an IVD or “signal acquisition system.” In the CDS Draft Guidance, FDA defines “signal acquisition systems” broadly as electronic circuity and control processors that receive, as inputs, signals from sensors that are within, attached to, or external to the human body or a sample from the human body, for example, EEG, ECG, CT, MRI and digital pathology devices.

FDA states that its regulatory oversight is focused on CDS software that analyzes physiological signals to provide diagnostic, prognostic and predictive functionalities. Examples provided by FDA include algorithms that analyze images and perform feature identification and algorithms that analyze and interpret genomic variations to determine a patient’s risk for a particular disease. But many cutting-edge CDS software technologies utilize data from medical images, diagnostics, and other medical devices, in order to make recommendations. FDA’s draft guidance leaves questions about whether, if broadly interpreted, any CDS functions that incorporate patient data from these various sources could ever fall outside of FDA device regulation. For example:

• Must the CDS function directly acquire the image or signal that it analyzes to fall within the definition of a device? Many types of CDS software utilize information acquired second- or third-hand (for example, data recorded in an electronic patient record that was obtained from an IVD or other device), and questions remain about whether such CDS functions are regulated.
• If software functions that analyze and interpret genomic data are subject to device regulation, what are the implications for laboratories that use software in providing laboratory developed tests?
• Although FDA’s focus appears to be on CDS software that analyzes images and signals, will CDS functions that only acquire or process such information be subject to device regulation?

Decision Support Software Aimed at Patients

Although Congress did not directly address “patient decision support” (PDS) software in the Cures Act, FDA decided to exercise enforcement discretion for this category of software if the software otherwise meets the criteria for CDS software aimed at clinicians. As with CDS, to fall outside FDA regulation, PDS software must allow patients (or other non-HCP users) to independently review the basis of any recommendation, i.e., the intended user must be able to reach the recommendation on his or her own without primarily relying on the software function. In addition, FDA cautions that different kinds of explanations may be needed for patients, since they have different education and experience levels as compared to healthcare providers.

Electronic Patient Records; General Wellness; and Functions that Transfer, Store, Covert, Format, or Display Device and Laboratory Data

FDA implemented the Cures Act by confirming that many of the software functions that were previously subject to the agency’s enforcement discretion are now excluded from the “device” definition and are outside of FDA regulation as a device, including:

• Software functions related to maintaining or encouraging a general state of health or a healthy activity that do not make any reference to diseases or conditions;
• Software functions that serve as electronic patient records or enable individuals to interact with EHR systems;
• Software functions that provide patients with simple tools to organize and track their health information or help patients document, show, or communicate potential medical conditions to healthcare providers; and
• Software functions that transfer, store, convert format or display laboratory or device data and do not generate alerts or alarms or prioritize multi-patient display for immediate clinical action.

Digital Health Marketed by Pharmaceutical Manufacturers

The draft guidances continue to leave many unanswered questions for pharmaceutical companies regarding digital health offerings that they market or are marketed on their behalf. Specifically, although the Center for Drug Evaluation and Research (CDER) is identified as one of the centers responsible for issuing the CDS Draft Guidance, the document itself does not provide much-desired clarity around how drug sponsors should approach digital health solutions in the context of their “drug” regulatory requirements (e.g., labeling, advertising and promotion, pharmacovigilance).

Instead, the CDS Draft Guidance simply asserts that drug sponsors have additional considerations when developing and marketing digital health solutions: “[t]his guidance does not address other FDA statutory or regulatory requirements that may apply to certain decision support software, including software disseminated by or on behalf of a sponsor, for use with one or more of its drugs or biologics, such as requirements applicable to drug or biologic labeling or combination products.”

Of note, the CDS Draft Guidance states that software that provides HCPs with recommendations on the use of a prescription drug that are consistent with the FDA-required labeling is not considered to meet the definition of a “device” under section 201(h) of the FDCA.

The draft guidances retain FDA’s approach of regulating software products based on their intended use and functionality rather than the specific platform, which the Cures Act embraced. But the draft guidances do not address how FDA will approach software products that include multiple functions, including those with one device function and one function that is not a device. FDA intends to address the agency’s approach to such “multifunctionality” in a separate guidance document.

Commenting on the Draft Guidances

Companies who are marketing or developing digital health products will want to carefully review the new draft guidances and consider the implications of FDA’s proposed policies for their product portfolios. Companies should consider submitting comments on the draft guidances, which could include supporting particular proposals, noting concerns about ambiguity or implementation, or suggesting changes in approach. In addition, innovators developing digital health technologies that are not explicitly addressed by FDA in the draft guidance documents—such as software that utilizes machine learning and AI—should consider weighing in with FDA about those technologies. The FDA docket is open for comments until February 6, 2018. Comments can be submitted electronically via Regulations.gov.