FDA Regulatory Approach to Clinical Decision Support Software
The need for Clinical Decision Support (CDS) using digital solutions and AI is rapidly growing and its benefits are clear especially during the COVID-19 pandemic.
In this emerging technologies market we can find CDS software that follow the clinician’s prescriptions and notify the user via a pop-up alerts on a Mobile App; CDS software which analyze patient physiological parameters to enable doctors to take optimal therapy decisions among varieties of provided treatment schemes; CDS system based on AI and medical imaging processing that improve breast cancer early detection, etc.
Many medical device companies develop CDS software tools aiming to improve clinical practice and health outcomes.
But which tool is subject to FDA regulation and which tool can benefit from FDA Enforcement Discretion Policy?
FDA draft guidance on CDS software from Sep 2019 provides some insight on the way it intends to regulate CDS. FDA defines categories based on risk: CDS that would be subject to FDA oversight, CDS for which it intends not to enforce applicable regulatory requirements (known as Enforcement Discretion) and CDS that do not meet the definition of a medical device.
NON-device CDS:
In the draft guidance FDA excludes from the definition of device (hence are not subject to medical device regulation) software functions that meet all of the following four criteria:
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.
Intended for the purpose of supporting or providing recommendations to an HCP about prevention, diagnosis, or treatment of a disease or condition.
Intended for the purpose of enabling an HCP to independently review the basis for the recommendations that such software presents so that it is not the intent that the HCP rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.
Risk based approach for device regulation:
FDA intends to apply a risk-based policy by leveraging IMDRF (International Medical Device Regulators Forum) Framework, which defines two major factors for the risk categorization of a SaMD (Software as a Medical Device):
The significance of information provided by a SaMD to the health care decision: Drive Clinical Management, Treat or Diagnose, Inform Clinical Management.
Driving clinical management infers that the information provided by the SaMD will be used to aid in treatment or diagnoses, to triage or identify early signs of a disease or condition which can be used to guide next diagnostics or next treatment interventions.
Treatment or diagnosis functions provide the actual diagnosis or prompt an immediate or near-term action.
SaMDs which inform clinical management are intended to provide information, such as treatment or diagnostic options or aggregating clinical information.
2. The state of the health care situation or condition: Critical, Serious, Non-serious
Critical: accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration on health.
Serious: accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions or timely interventions are important to mitigate long term irreversible consequences on health.
Non-serious: accurate diagnosis and treatment is important but not critical for interventions to mitigate long term irreversible consequences on health.
According to the draft guidance, SaMDs which inform clinical management are CDS because they are intended to support a recommendation to an HCP, patient, or caregiver.
On the other hand, SaMD functions that drive clinical management, treat or diagnose are not CDS because they go beyond supporting or providing recommendations.
CDS risk level is further analyzed according to the intended user, e.g is it an HCP, patient or caregiver and whether or not the user can independently review the basis for the recommendation so that it is not the intent of the CDS that the user relies primarily on any such recommendation.
The table below summarizes FDA regulatory approach to CDS software functions (source: FDA CDS draft guidance, Sep 2019)
Below are some examples of CDS software functions and the way FDA intends to regulate them:
Device CDS intended for HCP on which FDA intends to exercise enforcement discretion: 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 on Non-Serious conditions such as potential cholesterol management issues.
Device CDS intended for patient for which FDA intends to exercise enforcement discretion: Software that provides information to a patient about the use of a prescription drug that is consistent with the FDA-required labeling, such as reminding the patient how or when to take a prescribed drug.
Device CDS intended for HCP on which FDA intends to focus its regulatory oversight: 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 (informs serious clinical condition). FDA further clarifies that if the HCP could evaluate the basis for the software’s recommendations, then this software would be considered Non-Device CDS.
Non-Device CDS: Software that uses a patient’s diagnosis to provide an HCP with current practice treatment guidelines for common illnesses or conditions such as influenza, and provides the source of the guidelines.
Conclusion:
Clinical decision support (CDS) software tools have a clear potential to improve clinical decision making. FDA risk-based approach as described in the draft guidance provides some roles to developers which can be utilized during the design stage and help establish the device' regulatory strategy. It is highly important to encourage the development of software tools to support providers in diagnosing and treating patients, while also ensuring the software doesn’t expose the patient to unacceptable risk.
When there is a question regarding the device classification and whether it is subject to FDA regulation or can benefit from FDA enforcement discretion policy it is recommended to submit a 513(g) Requests for Information.
Does your company develop software which may fall under FDA CDS definition? Need assistance in defining your global regulatory strategy?
Don't hesitate to contact us.