Your clinical decision support software may now be regulated by FDA as a medical device
Clinical Decision Support (CDS) software is an area driven by innovative technologies that is often intertwined with traditional clinical practice. On September 28, 2022, FDA issued the long-awaited final guidance for the regulation of Clinical Decision Support Software (Final Guidance). The final guidance elaborates on FDA’s interpretation of the statutory guidelines set out in the 2016 21st Century Cures Act (Cures Act), adds new definitions and, most importantly, provides several new examples that inform software developers on how to navigate the complex regulatory framework surrounding CDS.
The Final Guidance is far more expansive in scope than the 2019 revised Draft Guidance. Most notably, based on our assessment of the Final Guidance, many software products previously not regulated by FDA under the Draft Guidance may now be subject to FDA oversight under the Final Guidance. The Final Guidance departs from familiar concepts like IMDRF risk levels from the Draft Guidance, in lieu of new concepts like “automation bias” that shift the analysis.
Below, we provide a comprehensive overview of FDA’s regulatory approach to CDS software and discuss the key changes in the Final Guidance, as compared to the 2019 revised Draft Guidance.
The statutory framework
Software that meets the definition of a device in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act) has long been regulated by the FDA. Section 520(o) of the FD&C Act (21 USC § 360j) carves out certain software functions from the definition of device in Section 201(h) of the FD&C Act, allowing marketing of those products without the need for FDA submission and approval/clearance. Specifically, section 520(o)(1)(E) of the FD&C Act excludes CDS software from the definition of medical device if the software functions meet all of the following four criteria:
Criterion 1: The software function is 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
Criterion 2: The software function is 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)
Criterion 3: The software function is intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis or treatment of a disease or condition and
Criterion 4: The software function is intended for the purpose of enabling such healthcare professional to independently review the basis for such recommendations that the software presents so that it is not the intent for such healthcare professional to rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.
However, FDA’s interpretation of these statutory provisions is important for understanding whether a company would be subject to enforcement risk. Since Congress enacted the Cures Act in 2016, FDA published two draft guidance documents (2017 Draft Guidance and 2019 Revised Draft Guidance) before it issued the Final Guidance. These multiple rounds of guidance documents reflect the complexity of the statutory exclusion criteria and FDA’s commitment to clarifying its regulatory priorities for CDS.
Analysis of the Final Guidance
The Final Guidance is largely a rewrite of the 2019 revised Draft Guidance, with very few elements remaining consistent. The most noticeable difference between the 2019 Revised Draft Guidance and the Final Guidance is that Final Guidance removed the International Medical Device Regulators Form (IMDRF) risk categorization and the risk-based enforcement discretion policy. Instead, the Final Guidance establishes a more binary system: (i) Non-Device CDS and (ii) Device CDS. The Final Guidance focuses less on risk and more on elaborating on the agency’s interpretation of the four exclusion criterion from the statute. In addition, the 2022 Final Guidance provides more examples of Non-Device CDS and Device CDS, detailing FDA’s analysis of how a specific software functionality would meet, or fail to meet, certain statutory criteria for exemption from the definition of a medical device. We describe FDA’s interpretation of each of the criteria in turn, below.
Criterion 1 and Criterion 2: Data inputs
Criteria 1 and 2 relate to data inputs. Criterion 1 defines the types of data inputs that will be indicative of a Device CDS. Criterion 1 describes three types of data inputs: (1) medical images, (2) signals from an in-vitro diagnostics (IVD) and (3) patterns or signals from a signal acquisition system.
FDA maintains that if any of these data inputs are “used [as] an input, then the software function remains a device within the meaning of section 201(h),” so long as the intended use still meets the medical device definition.
With regard to defining what constitutes these inputs, in the 2019 revised Draft Guidance, FDA defined only “physiological signals.” In the Final Guidance, FDA now includes a definition for “medical images” and notes that “[i]mages that were not originally acquired for a medical purpose but are being processed or analyzed for a medical purpose are also considered medical images.” FDA maintains its definition for “signal” with no changes, but adds a new definition of “pattern,” which now “refer[s] to multiple, sequential, or repeated measurements of a signal or from a signal acquisition system,” such as Next Generation Sequencing (NGS) based genetic sequences, or repeated glucose measurements by a continuous glucose monitor (CGM).
Any software functions that assess or interpret the clinical implications or clinical relevance of a signal, pattern or medical image are software functions that do not meet Criterion 1 and will be regulated as a medical device by FDA because such software functions “acquire, process, or analyze” and therefore fail the statutory criteria for exclusion from the definition of medical device.
Criterion 2 identifies data inputs that may support a Non-Device CDS conclusion, so long as the software also meets Criteria 1, 3 and 4. For Criterion 2, FDA previously only provided an abbreviated interpretation of this provision without elaborating on what “medical information about a patient” means, or what “other medical information” entails. The Final Guidance goes further, as FDA added interpretative definitions to all these terms.
Specifically, FDA defines “medical information about a patient” as “the type of information that normally is, and generally can be, communicated between health care professionals (HCPs) in a clinical conversation or between HCPs 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.” Significantly, FDA clarifies that data sampling frequency is an important factor in determining whether the data input is a pattern or signal under Criterion 1 or “medical information” under Criterion 2. A single, discrete test or measurement result that is clinically meaningful (eg, a blood glucose lab test result) is “medical information” under Criterion 2, while a more continuous sampling of the same information (eg, continuous glucose monitor readings) is a pattern/signal and falls into a data input under Criterion 1. It remains to be seen what the precise contours are between medical information and signals.
FDA also now defines “other medical information” as generally referring to “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.” Some examples of “other medical information” include, but are not limited to, clinical practice guidelines, peer-reviewed clinical studies, textbooks, approved drug or medical device labeling and government agency recommendations. If the data inputs are limited to those now described by FDA in Criterion 2, including the display or analysis of a single reading of a data point, then it is possible that the software function would be a Non-Device CDS, so long as the software function also meets the requirements of Criterion 3 and 4.
Criterion 3 and Criterion 4: Data outputs
Criteria 3 and 4 are focused mainly on the data output of the software. The Final Guidance significantly altered FDA’s interpretation and guidance of Criterion 3. It is under this criterion that the removal of the IMDRF risk categorization is most noticeable. Previously, under the 2019 revised Draft Guidance, parties would need to extensively consider the IMDRF matrix framework for whether the software informed, drove, diagnosed or treated a non-serious, serious or critical condition to determine whether the software function met criterion 3.
Under the Final Guidance, FDA provides an interpretation of this statutory criterion in a narrative fashion, finding that “software that provides condition-, disease-, and/or patient-specific recommendations to an HCP to enhance, inform and/or influence a health care decision, but is not intended to replace or direct the HCP’s judgement” can be a Non-Device CDS function. Stated differently, if “a software function provides a specific preventive, diagnostic or treatment output or directive, the software function fails Criterion 3.”
FDA is clear, for the first time, that indications that a patient “may exhibit” a disease or condition symptom language and presenting risk probabilities and risk scores that are patient specific outputs that would fail Criterion 3. FDA provided the following examples of Non-Device CDS functions that successfully pass Criterion 3: (i) evidence based clinical order sets for an HCP to choose from, (ii) contextually relevant information about a disease or condition, (iii) drug-formulary guidelines and (iv) patient data reports (ie, discharge summaries).
Another key difference is that the Final Guidance introduces, for the first time, the concept of two contextually relevant details about the data output that influences FDA’s determination of whether the software function is actually substituting, replacing or directing the HCP’s judgement, and thus failing Criterion 3. These two additional factors are: (1) the level of software automation (and the potential for “automation bias”) and (2) the time criticality of the HCP decision at issue.
Automation bias is, according to FDA, “the propensity of humans to over-rely on a suggestion from an automated system.” Put simply, and as alluded to above, if a software provides a user with a single output rather than a list of options, then a user may be prone to such bias by accepting the only output presented without considering other information to inform their decision-making.
When determining whether a software functionality satisfies or fails Criterion 3, FDA intends to consider both of these additional, contextual aspects to the data output. A software function will fail Criterion 3 if the level of automation is intended to replace or direct HCP decision making or if the data output supports a time-critical HCP decision, such as providing time-critical alarms or alerts intended to trigger potential clinical intervention to assure patient safety.
One consistent interpretation from FDA is regarding the intended audience for the CDS data output. The Final Guidance deals solely with data outputs directed toward HCPs. CDS software that provides data output (support or recommendations) to a patient, caregiver or consumer directly is not covered by this Final Guidance. Rather, such software will continue to be subject to FDA’s other digital health guidance documents, such as the (i) Policy for Device Software Functions and Mobile Medical Applications, (ii) Software as a Medical Device (SaMD): Clinical Evaluation, (iii) Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices, and (iv) General Wellness: Policy for Low Risk Devices. Notably, FDA updated many of these guidance documents at the same time that it issued the Final Guidance and removed certain categories of enforcement discretion that it previously offered under those guidance documents in an effort to align with this Final Guidance.
Criterion 4 requires that HCPs be able to independently review the basis for the software’s recommendations that have successfully “passed” the requirements in the preceding Criterion 3. FDA expanded its interpretation of this requirement significantly from the 2019 revised Draft Guidance. In the Final Guidance, FDA provided extensive labeling or transparency recommendations to software developers, which must inform the recipient HCP of the basis for the recommendation in order to prevent such HCP from relying primarily on the data output, but rather encourage the HCP to rely on their own clinical judgment when making patient care decisions.
These labeling and disclosure requirements are extensive and, by their nature, effectively prohibit an HCP from using the data output in time sensitive or time-critical situations because such situations would have an insufficient amount of time to allow for the HCP to independently review the full basis of the recommendations presented by the software. These requirements seem to require transparency in both the reasoning behind the recommendations and the process of training and validating software, placing a clear and enhanced onus on HCPs to become AI literate and stand as learned intermediaries for software as well as more traditional interventions.
Indeed, FDA is now requiring specific “plain language instructions” on how the software obtained the data input(s), what data quality requirements the software applied, how the software developer designed and validated the underlying algorithm logic or methods, whether there are performance limitations in the software outputs, and whether there is patient-specific variability in the data output that the HCP should consider (ie, missing data, outlier data). The labeling information provided must be readily available to the HCP, with specific citations, and must be understandable to the HCP with no material omission of information. The information provided would, ideally, provide details on how the software matched patient specific data to the relevant data sets or guidelines provided, which would allow the HCP to independently assess the strength of the data output and evaluate the basis for the recommendation.
Setting aside the high standards for data fluency and interpretation that this places on the HCP, this level of transparency and validation may be very difficult for developers of CDS software to achieve. Interestingly, FDA noted for the first time in this Final Guidance that developers may need to utilize usability testing to verify if the implementation of the software functionality meets Criterion 4. Overall, we expect that many software developers will need to further build out the independent review materials in order to meet Criterion 4.
Next steps
In addition to the Final Guidance and other updated guidance documents, FDA also provided further resources to help the industry and interested stakeholders navigate the regulatory system, including a new Digital Health Policy Navigator tool. Additionally, FDA scheduled a on October 18, 2022, to discuss the Final Guidance. Given the extensive revisions to FDA’s interpretation of the statutory requirements, the wealth of new examples provided and the complete elimination of categories of enforcement discretion in this Final Guidance and other related digital health guidance documents, we expect ongoing public debate and criticism could result in further FDA actions.
We will continue to monitor any updates from the FDA and provide timely updates on this topic. For information about CDS and the changing digital health landscape and associated FDA regulation, please contact your DLA Piper relationship partner, the authors of this alert or any member of our FDA industry group.
