The FDA’s new draft guidance on clinical decision support software (CDS) is a major revision of a prior draft guidance issued on December 8, 2017. It explains the FDA’s method of interpreting section 520(o) of the Federal Food, Drug, and Cosmetic Act (“FD&C Act”). This section of law was added by the 21st Century Cures Act (“Cures Act”) and excludes certain CDS from being defined as medical devices (and therefore excluding them from the requirements of FDA approval).
According to the guidance, the FDA intends to classify CDS functions that:
- “Do not meet the definition of a device as amended by the Cures Act
- May meet the definition of a device but which, based on our current understanding of the risks of these devices, FDA does not intend at this time to enforce compliance with applicable device requirements of the FD&C Act” …
- “Meet the definition of a device and on which FDA intends to focus its regulatory oversight”
4 Criteria of Non-Device Clinical Decision Support Software
The guidance expands upon each of the four criteria required in order to be not considered a medical device:
1. 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 (section 520(o)(1)(E) of the FD&C Act);
The new draft describes a relatively broad definition of “signal” which would classify as devices software that intended to identify features in medical images, analyze accelerometer data for measuring progression of neurological disorders, or analyze and interpret genomic data to determine a patient’s risk for a particular disease.
It also clarifies that physiological signals collected for non-medical purposes would not be considered medical devices.
2. 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) (section 520(o)(1)(E)(i) of the FD&C Act);
The guidance gives examples such as patient information such as demographic information, symptoms, test results, medical device outputs, clinical practice guidelines, clinical studies, textbooks, approved drug or medical device labeling.
3. intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition (section 520(o)(1)(E)(ii) of the FD&C Act); and
Notably, this classifies all patient decision support software as medical devices. The prior draft of the guidance allowed for enforcement discretion that allowed patient decision support software to be regulated similarly to CDS. Although narrower than before, the FDA is willing to consider the risks involved in patient software and may not enforce compliance for low risk medical conditions or decisions. The risk assessment framework in use is described later. For patient decision support software to be considered for enforcement discretion it must still meet criterion 4.
4. intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient (section 520(o)(1)(E)(iii) of the FD&C Act).
The guidance recommends that to meet criterion 4, Non-Device CDS manufacturers should be able to describe in plain language:
- The purpose or intended use of the software function;
- The intended user (e.g., ultrasound technicians, vascular surgeons);
- The inputs used to generate the recommendation (e.g., patient age and sex); and
- The basis for rendering a recommendation.
It is clear that regardless of the complexity or proprietary nature of the software, the HCP must be able to understand the underlying data used to develop the algorithm as well as the logic used by an algorithm to render a recommendation. While this requirement doesn’t exclude artificial intelligence or machine learning software, they must provide enough information to allow HCP to independently confirm the basis for the recommendations. Similar to criterion 3, the FDA may exercise enforcement discretion for software that cannot meet criterion 4 but is informing clinical management of non-serious conditions.
Risk Assessment for Enforcement Discretion
In a notable addition compared to the previous draft, the FDA intend to use the 2014 International Medical Device Regulators Forum (IMDRF) Framework for risk categorization of software as a medical device (SaMD) to determine which CDS will be the focus of regulatory oversight. The IMDRF Framework identifies four risk categories based on the state of the health care condition and the significance of the information provided by the software:
The IMDRF Framework
Software that treats, diagnoses, or drives clinical management will be considered medical devices. Software that informs clinical management and meets all of the 4 criteria listed above would not be considered a medical device. The IMDRF describes informing clinical management as “ the information provided by the SaMD will not trigger an immediate or near-term action:
- To inform of options for treating, diagnosing, preventing, or mitigating a disease or condition.
- To provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.).”
The Guidance provides the following table of its regulatory policy for CDS software functions:
* “Can the User Independently Review the Basis?” asks whether the function is intended for the purpose of enabling the user to independently review the basis for the recommendations so that it is not the intent that user relies primarily on any such recommendation (part of criterion (4)).
** “Enforcement Discretion” indicates that, based on our current understanding of the risks of these devices, FDA does not intend at this time to enforce compliance with applicable device requirements.
So, what does this all mean for you? Generally, the new guidance reduces the regulatory burden in the US compared to the interpretation of prior policies. There’s also a clear intent to harmonize globally along with other medical device guidelines. Of special note is the impending EU Medical Device Regulation that is set to make major changes on the oversight and requirements for medical device and software sponsors. In interpreting software policies for the US and EU, it is important to look at this FDA guidance along with any applicable regulations before and after the impending 2020 date.
The guidance ends with a very useful list of examples of device and non-device CDS and with description of the FDA’s rationale for the classification and regulation of each. If you have any remaining questions about the regulatory or quality requirements for CDS or SaMD in general reach out to me at Isabella@ProximaCRO.com.
