With the rise of artificial intelligence and machine learning, clinical decision support, or CDS, software 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 or health care options.
In late September, the U.S. Food and Drug Administration published a draft guidance on clinical decision support software that sets forth the agency’s proposed approach to regulating CDS, including CDS that incorporates machine learning technology.
The FDA published the draft guidance, along with five other guidance documents in a larger effort to articulate its enforcement policies on digital health in light of the 21st Century Cures Act. Section 3060(a) of the Cures Act amended the Federal Food, Drug and Cosmetic Act to remove certain software functions, including CDS, from the definition of “device” under Section 201.
CDS That Is Exempt Under the FDCA
Under the Cures Act, CDS that meets all of the following criteria is exempted from the definition of “device,” and hence is not subject to regulation by the FDA:
- 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;
- Intended for the purpose of displaying, analyzing or printing medical information about a patient or other medical information (e.g., clinical practice guidelines);
- Intended for the purpose of supporting or providing recommendations to a health care professional, or HCP, about prevention, diagnosis or treatment of a disease or condition; and
- Intended for the purpose of enabling such HCP to independently review the basis for recommendations that the software presents.
- The first criterion means that software that analyzes data from an image (such as feature identification), detects a patient’s genetic variant from an in vitro diagnostic test, or characterizes a patient’s abnormality based on the shape, appearance or other functional aspects of an image will not be excluded from the “device” definition.
For example, software that calculates the dimensions of a skin lesion, and compares those dimensions to a database of images to identify whether the lesion is malignant or benign, would not be exempt. Likewise, a software that detects a genomic variance, and compares the variance to a large set of genomic data, also would not be exempt.
CDS that is for patient use, as opposed to use by a health care provider, also is not exempt from regulation.
The draft guidance provides some examples of CDS that meet the exemption criteria (and hence would not be subject to FDA regulation):
- 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.
CDS That Is Subject to Regulation Under the FDCA
For CDS that does not meet all of the above exclusion criteria, the FDA intends to apply a risk-based approach to regulation. CDS that presents low risk would not be subject to active regulation by the FDA. In other words, the FDA will not enforce regulatory requirements for nonexempt, low-risk CDS.
The proposed risk-based approach is rooted in software risk categorizations set forth by the International Medical Device Regulatory Forum in its 2014 framework.
The framework categorizes the risk posed by medical device software using two factors: (1) the seriousness of the health condition (i.e., critical, serious or not serious) and (2) the significance of the information to the health care provider (i.e., whether the information informs clinical management, drives treatment or diagnosis a patient). The higher risk presented, the more likely the FDA will actively regulate the software.
According to the FDA, software that does more than inform clinical management — e.g., drives clinical decisions or determines a diagnosis — goes beyond CDS and will be subject to active regulation. The distinction, however, between “inform” and “drive” is not abundantly clear. For example, the FDA states that software that suggests an intervention or diagnostic test could be CDS. Suggesting a next-step intervention or diagnostic test arguably, however, may be “driving” treatment.
The 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) because they present low risk. The common theme in these examples is that the CDS informs clinical management for nonserious conditions (using the IMDRF framework):
- 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; and
- Software that assists a patient in identifying OTC cold or allergy medications to consider purchasing based on symptoms.
The FDA intends to actively regulate software that informs clinical management for serious or critical conditions (and that otherwise does not meet the CDS exemption criteria in the FDCA). Examples of actively regulated software include:
- Machine learning algorithms, 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 is intended to perform image analysis for diagnostically differentiating between ischemic and hemorrhagic stroke;
- Software that uses a patient’s image set (e.g., MRI) to create an individual treatment plan for radiation therapy; and
- Software that detects and highlights abnormalities in an image and assesses associated disease severity.
Transparency Is Key for Companies Aiming to Develop Unregulated CDS
For companies developing software for diseases or other serious conditions, one clear advantage of meeting the four exemption criteria is that the CDS will not be regulated, no matter how serious the condition or disease. In contrast, the FDA will actively regulate CDS that is intended for diseases/serious conditions and that does not meet the exemption criteria.
The ability of an HCP to understand the inputs to the CDS recommendation is key to meeting the fourth exemption criterion. For example, a CDS that makes suggestions for cancer treatment would be exempt, so long as the HCP can review the underlying data — such as patient records and test results.
The CDS also could pull from other sources, so long as those sources are transparent to the HCP. CDS that pulls from large volumes of clinical practice guidelines, for example, could identify the guidelines upon which it relied by providing a title and date/ version of the guideline. Without transparency of the underlying sources, CDS that makes cancer treatment suggestions would be actively regulated by the FDA.
An argument can be made that a HCP realistically would not have the time to independently review the basis for recommendations where the CDS that pulls from large volumes of data, such as medical guidelines and other literature. This alone, however, should not exclude the CDS from exemption.
After all, the benefit of CDS is the software’s ability to analyze and filter large amounts of data to inform treatment for particular patient. Clinicians do not have the time to pour over the latest studies or complex research for each individual patient. Providing a reference/citation to the guidelines identified by the software algorithm should suffice to meet the fourth exemption criterion.
CDS that pulls from proprietary data that is not made available to the HCP, or that uses ML technology and does not explain the inputs to the ML algorithm, will not be exempt from regulation. If no predicate device exists, and it may not in this emerging space, a de novo request would have to be submitted to the FDA.
Companies developing CDS software for life science or other medical applications should review the FDA’s planned approach, and the numerous example provided, to understand how the FDA intends to regulate their software. Making adjustments to the software — for example, by adding transparency to the end user — could shift the regulatory profile of the software.
FDA is accepting comments to the draft guidance until Dec. 26.
This article was originally posted in Law360 on November 4, 2019