In September 2022, the U.S. Food and Drug Administration (FDA) issued its final guidance, “Clinical Decision Support Software,” representing a shift from what was proposed in the 2019 draft guidance. The guidance document is a critical policy tool in determining whether a software functionality will be considered CDS software beyond the FDA’s oversight or regulated by the agency as a medical device. Many software functionalities that the FDA would not have regulated according to the draft guidance may now be subject to FDA oversight.
Notable changes to the CDS software policy in the final guidance include: the absence of a risk-based enforcement discretion policy for functions determined to be lower risk according to the International Medical Device Regulators Forum (IMDRF) risk categorization framework; narrowing the interpretation of two CDS criteria from the statutory exemption from the definition of a medical device: medical information about a patient” and “other medical information;” and excluding from the statutory exemption from the definition of a medical device software that provides a “specific preventive, diagnostic or treatment output or directive” or that supports “time-critical decision-making.”
The final guidance and its potential impact are discussed in this alert.
Background
The 21st Century Cures Act (Cures Act) was enacted in December 2016 and specified in Section 520 that software functionalities satisfying four enumerated criteria would be excluded from the Federal Food Drug and Cosmetic Act’s (FD&C Act’s) definition of medical device and therefore not regulated by the FDA.
As part of its 2017 Digital Health Innovation Action Plan, the FDA announced its plans to issue a guidance document providing the agency’s interpretation of the Cures Act Section 520(o)(1)(E). The Clinical Decision Support Software (CDSS) Guidance Document was first proposed on December 8, 2017; however, based on dozens of comments from trade and professional associations, healthcare providers, and individuals critical of the initial draft, the FDA issued a revised draft guidance on September 27, 2019. As we previously reported, the revised draft guidance generally took a lighter touch with respect to CDS regulatory policy and proposed agency enforcement discretion for several scenarios that considered whether the intended user was a healthcare provider or patient; the IMDRF risk categorization framework; and whether the user could independently review the basis of the software’s recommendations. The most recent draft guidance prompted nearly twice as many comments as the prior draft guidance representing the same stakeholder cohorts.
Final Guidance
As stated above, when determining whether particular CDS software would trigger FDA oversight, the final guidance no longer factors into that calculus the IMDRF risk categories, including whether the intended user is a patient. Instead, the agency directs stakeholders to consult the statements of policy in the web of FDA digital health guidance documents. Recognizing this to be no simple task, the FDA has developed a Digital Health Policy Navigator to help the public determine whether a software functionality is regulated by the FDA as a medical device.
Four Clinical Decision Support Criteria
The FDA’s final guidance explains the agency’s interpretation of each of the four criteria in section 520(o)(1)(E) of the FD&C Act. These criteria describe the types of CDS software that are not regulated as devices. In order for a software function to be excluded from the device definition under this provision, it must meet all four criteria:
Criterion 1— The software is not intended to acquire, process, or analyze images, signals from an in vitro diagnostic device (IVD), or patterns or signals from a signal acquisition system.
Although many signal acquisition systems are intended to monitor signals for medical purposes and, therefore, are considered medical devices, some are not. For example, activity monitors or other signal acquisition systems that measure physiological parameters that are not specifically intended or marketed for a purpose identified in the device definition are not medical devices.
Criterion 2— The software is intended to display, analyze, or print medical information normally communicated between healthcare professionals.
The FDA interprets “medical information about a patient” to be the type of information that is normally communicated between healthcare providers in a clinical conversation, or between healthcare providers and patients in the context of a clinical decision, meaning that the relevance of the information to the clinical decision being made is well understood and accepted. The FDA interprets “other medical information” to include information such as peer-reviewed clinical studies, clinical practice guidelines, and information that is similarly independently verified and validated as accurate, reliable, not omitting material information, and supported by evidence.
Perhaps most notable with respect to this criterion is the role that sampling frequency plays. The FDA states that a discrete test or measurement result that is clinically meaningful (e.g., a blood glucose lab test result) is medical information that would exclude the software from the medical device definition, while a more continuous sampling of the same information (e.g., continuous glucose monitor readings) is a pattern/signal that would fail to meet this criterion, and thus be considered a regulated device.
Criterion 3— The software is intended for the purpose of supporting or providing recommendations (i.e., information or options) to a healthcare provider (HCP) rather than a specific output or directive.
The FDA believes that two aspects of software functionality may affect whether a software function is being used to support or provide recommendations to an HCP: 1) the level of software automation, and 2) the time-critical nature of the HCP’s decision making.
Automation bias is the propensity of humans to over-rely on a suggestion from an automated system and may be more likely to occur if software provides a user with a single, specific, selected output or solution rather than a list of options or complete information for the user to consider. In the former case, the user is more likely to accept a single output as correct without taking into account other available information to inform their decision-making. Similarly, decision-making that is time critical may carry similar risks when using decision support software. In situations that require urgent action, automation bias increases because there is not sufficient time for the user to adequately consider other information.
The guidance states both of these aspects are evaluated when determining whether a software function is being used to enhance, inform, and/or influence an HCP’s decision-making (meaning the product is not a medical device) or rather, to substitute, replace, or direct the HCP’s judgment (meaning the product is a medical device).
Therefore, the FDA interprets Criterion 3 to refer to software that:
- (i) provides outputs that are condition-, disease-, and/or patient specific recommendations to an HCP to enhance, inform, and/or influence a healthcare decision;
- (ii) does not provide a specific preventive, diagnostic, or treatment output or directive;
- (iii) is not intended to support time-critical decision-making; and
- (iv) is not intended to replace or direct the HCP’s judgment.
Criterion 4—The software is intended for the purpose of enabling a healthcare provider to independently review the basis for the software’s recommendations so that healthcare providers do not rely primarily on the software’s recommendations, but rather on their own judgment, to make clinical decisions for individual patients.
To permit informed decision making by the HCPs, the software output or labeling should provide adequate background information in plain language on the input(s), algorithm logic or methods, datasets, and validation, regardless of the complexity of the software and whether or not it is proprietary. Relevant sources should be identified and available to the intended user (e.g., clinical practice guidelines with the date or version, published literature, or information that has been communicated by the CDS developer to the intended user) and understandable by the intended user (e.g., data points whose meaning is well understood by the intended user). In order to enable independent evaluation of its basis, the recommendation should be based on information whose meaning could be expected to be independently understood by the intended healthcare provider user (e.g., the inputs used to generate the recommendations are identified, the recommendations are based on inputs that do not omit material information, and the quality and robustness of the datasets or clinical studies are described).
Illustrative Infographic
The final guidance provides several examples to help readers understand the applicability and interpretation of the four criteria and the FDA’s CDS policy. In addition, the agency created this helpful infographic to further illustrate its CDS policy. Additional agency CDS materials are also available from the FDA’s webinar webpage.
Software Pre-Certification Pilot Program
Prior to release of the final guidance, the agency also conducted a Software Precertification (Pre-Cert) Pilot Program. The FDA recognized that the current device regulatory framework, over 40 years old and only incrementally updated since then, had not been optimized for regulating the rapid, iterative development of software. The pilot explored innovative approaches to regulatory oversight of software as a medical device. The program’s goal was to provide more streamlined and efficient regulatory oversight of software-based medical devices from manufacturers who have demonstrated a robust culture of quality and organizational excellence and are committed to monitoring real-world performance.
In September 2022 report, the FDA concluded that additional legislative authority will be necessary to support the development and implementation of a new regulatory paradigm. In the meantime, the FDA, with leadership from the FDA’s Center for Devices and Radiological Health’s (CDRH’s) Digital Health Center of Excellence, intends to develop policies and tools within current authorities to improve the efficiency and effectiveness of regulatory oversight, including through collaborative engagement with the public, such as the Medical Device Innovation Consortium (MDIC).
