The Incredible Shrinking Exemption: FDA Final CDS Guidance Would Significantly Narrow the Scope of Exempt Clinical Decision Support Software Under the Cures Act
October 10, 2022On September 28, 2022, the FDA issued the long anticipated final Clinical Decision Support Software Guidance (CDS Guidance), which replaces the revised draft guidance document from 2019. The CDS Guidance interprets the “medical software” carve-out of the 21st Century Cures Act (2016) as it pertains to Clinical Decision Support (CDS) software functions. Specifically, the guidance interprets the Cures Act’s four criteria for exclusion of CDS software functions from FDA’s medical device jurisdiction (so-called “Non-Device CDS”). You can find our preliminary blog post on the release of this guidance here, and our blog posts on the draft CDS guidances here and here.
The final CDS Guidance represents a marked change in approach from prior drafts and foreseeably will result in the regulation of many types of CDS that were previously considered to be Non-Device CDS or low-risk Device CDS under enforcement discretion. The final guidance therefore may have significant implications for a wide range of stakeholders, including not only software developers but also health care providers, hospitals, patients and payors.
Interpretation of Statutory Criteria Under the Final Guidance
The CDS Guidance interprets the Cures Act’s definition of “medical software” that is excluded from the statutory “device” definition, as it relates to CDS software. As a refresher, the Cures Act established the following four criteria for Non-Device CDS software:
- Criterion 1: Non-Device CDS software functions do not acquire, process, or analyze medical images, signals from an in vitro diagnostic (IVD) device, or patterns or signals from a signal acquisition system.
- Criterion 2: Non-Device CDS software functions display, analyze or print medical information about a patient or other medical information.
- Criterion 3: Non-Device CDS software functions are intended for the purpose of supporting or providing recommendations about a patient’s care to a health care professional (HCP) user.
- Criterion 4: Non-Device CDS software functions provide sufficient information about the basis for the recommendations to the HCP user, so that the HCP user does not rely primarily on any of the recommendations to make a clinical decision about an individual patient.
Criterion 1: The first criterion describes the type of data inputs that are not permissible for Non-Device CDS (inputs that would render CDS software ineligible for the statutory medical software exclusion). While the final guidance includes the same definition of “signal” as that used in the draft guidance—i.e., signals that typically require the use of either an IVD or a signal acquisition system—it revises the definition for “medical image” and provides a definition for “pattern” for the first time. As newly defined, the terms “medical image” and “pattern” would appear to narrow the scope of Non-Device CDS.
“Medical image” is defined as including “those images generated by the use of medical imaging systems to view any parts of the body or images acquired for a medical purpose,” even if the images were not “originally acquired for a medical purpose but are being processed or analyzed for a medical purpose.” FDA interprets the term “pattern” to mean “multiple, sequential, or repeated measurements of a signal or from a signal acquisition system.” As these definitions were not proposed in the draft guidance, stakeholders have not previously had an opportunity to weigh in on the impact of these changes. Furthermore, the examples of software functions that fail Criterion 1 that are included in the final guidance do little to illustrate the application of these new definitions in practice, as the examples are limited to software products that have been regulated as medical devices for years.
Criterion 2: The second criterion describes the type of data inputs that are permissible for use in Non-Device CDS. Here again, FDA’s novel interpretation of statutory terms effectively narrows the scope of information that a software product can display, analyze, or print and still be considered Non-Device CDS. FDA gives no rationale for interpreting the apparently broad statutory term “medical information” in such a restrictive manner.
Medical information about a patient
The 2019 draft guidance interpreted “medical information about a patient” to mean the “kind of information used by the intended user to make decisions.” In contrast, the final guidance interprets this phrase to mean the “type of information that normally is, and generally can be, communicated between HCPs in a clinical conversation or between HCPs and the patient 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 CDS Guidance lists four general types of medical information that would meet the definition of “medical information about a patient”—a radiology study report, an ECG report, a blood pressure result, and a lab test result—but these examples shed little insight on how to apply the interpretation in practice. Furthermore, the subjective terminology in the revised definition gives rise to many questions, including what other types of information “normally” are or “generally can be” exchanged during a clinical conversation, who can determine that the relevance of the information is “well understood and accepted,” and what kind of objective documentation a software developer must collect to document that software inputs meet these conditions.
The CDS Guidance also adds a novel limitation to patient-specific medical information that may be used under Criterion 2, stating that the information must be a “single discrete test or measurement result.” In contrast, a “continuous sampling” of the same information would constitute a “pattern” or “signal” and therefore fail Criterion 1. The guidance provides no rationale for hinging the device status of CDS software on the frequency with which medical information is collected. Certainly we would expect clinical communications, as well as HCP-patient communications, to include discussions of test results over time as these would seem highly relevant to clinical decision making.
Other medical information
FDA interprets “other medical information” to include items 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.” Consistent with the 2019 draft guidance, the final guidance also includes textbooks, approved drug or medical device labeling, and government agency recommendations as other permissible types of medical information. The final guidance does not provide further insight as to what other types of information would be considered “similar” in their level of independent verification and validation, but could be read to exclude any reports, such as sponsor white papers, that have not undergone third-party peer review.
Criterion 3: The third criterion defines the scope of permissible intended uses for Non-Device CDS; namely, to support or provide recommendations about a patient’s care to the HCP. FDA’s 2019 draft guidance explicitly tied its interpretation of Criterion 3 to the International Medical Device Regulators Forum (IMDRF) risk-based categorization scheme, such that Non-Device CDS could only “inform” but not “drive” clinical management. While the final guidance continues to borrow some IMDRF concepts, it no longer limits Non-Device CDS to software that informs clinical management (per the IMDRF guidelines). Instead, the final guidance states that, to satisfy Criterion 3, Non-Device CDS must satisfy the following four conditions:
- Provide condition-, disease-, and/or patient-specific information and options to an HCP to enhance, inform, and/or influence a health care decision;
- Not provide a specific preventive, diagnostic, or treatment output or directive;
- Not be intended to support time-critical decision-making; and
- Not be intended to replace or direct the HCP’s judgment.
FDA justifies these new conditions as intended to prevent clinical errors caused by “automation bias,” i.e., the human propensity to over-rely on a suggestion from an automated system. The final guidance raises the concern that software that provides single, specific outputs or that is intended to support time-critical decisions will tend to replace or direct HCP judgment even if the software is not explicitly intended to do so. Thus, to meet Criterion 3 software functions must be designed to prevent automation bias by providing lists of options or follow up for the HCP to consider, and must not be intended to support time-critical decision making.
While the four new conditions on their face would appear to provide more flexibility than the 2019 draft guidance’s binary “inform vs. drive” standard, as interpreted by FDA these conditions appear to limit the scope of Non-Device CDS functions to an even greater extent, as the examples below illustrate.
Risk Scores Off the Table
The final guidance takes the position that software that informs an HCP that a patient “may exhibit signs” of a disease or condition, or that identifies a “risk probability or risk score” for a specific disease or condition, necessarily provides a “specific preventive, diagnostic or treatment output” and therefore is inconsistent with condition 2 and categorically excluded under Criterion 3. This interpretation of Criterion 3 does not clearly align with the statutory language and could cause more software to be regulated as a device than Congress intended in the Cures Act. Software providing a risk score for a specific disease could, plausibly, be intended to “support or provide recommendations” to HCPs and it therefore seems a stretch for the agency to categorically determine that such software, just because its output includes a risk probability or risk score, could never meet Criterion 3. FDA’s novel reading of Criterion 3 may dramatically affect the regulatory status of CDS software that includes risk probabilities or risk scores as outputs.
Criterion 4: The fourth criterion seeks to ensure that Non-Device CDS does not supplant an HCP’s independent clinical judgment. The statute achieves this through disclosure of information by the software manufacturer about the “basis for” the recommendations made by the software. The final guidance focuses on labeling as a means to effectuate Criterion 4. To that end, FDA recommends that:
- software output explains how the logic was applied to the patient and identify other variables to consider when interpreting the recommendation; and that
- software or labeling
- include the intended use, user, and intended patient population,
- a summary of the algorithm’s logic or methods (e.g., AI/ML techniques), a description of the datasets used, and clinical studies conducted to validate the algorithm/recommendations, and
- identification of required inputs, how the inputs are obtained and quality of inputs.
The final guidance stresses the importance of ensuring that an HCP can understand the “strength/limitations of the CDS software recommendations.”
A focus on information disclosure through labeling is generally consistent with the 2019 draft guidance and appears, at least on paper, a reasonable approach to interpreting Criterion 4. Software developers will need to carefully review their current software and labeling to ensure they provide adequate and understandable information concerning the intended use, inputs, algorithms, datasets and validation.
In addition to labeling, the final guidance adds that software developers “may need to perform usability testing to evaluate if their implementation meets Criterion 4.” Although not phrased as a requirement for demonstrating compliance with Criterion 4, it is possible that FDA in practice may expect software developers to perform usability studies to demonstrate HCP comprehension, which would add new burdens not clearly supported by the statute.
The Demise of Enforcement Discretion
The final guidance notably eliminates the category of low risk “Device CDS” subject to enforcement discretion that had been included in draft guidance. Under the draft guidance documents, FDA had provided numerous examples of HCP- and patient-directed CDS software that the agency did not intend to regulate as matter of policy. The final guidance instead suggests that the regulatory status of such software should be evaluated under FDA’s Policy for Device Software Functions and Mobile Medical Applications and Software as a Medical Device (SaMD): Clinical Evaluation; Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices—revised versions of which were released concurrently with the CDS Guidance—as well as under the 2019 General Wellness: Policy for Low Risk Devices.
Takeaways for Stakeholders:
Overall, this long-anticipated CDS Guidance includes a number of dramatic changes from past iterations, many of which would appear to limit the statutory exclusions for CDS software provided under the Cures Act. The final guidance foreseeably will lead to more CDS software needing to comply with FDA medical device requirements, including in some cases the requirement for premarket authorization, i.e., 510(k) clearance, de novo classification, or Premarket Approval. Developers and users of CDS software currently in distribution should carefully evaluate the effect of this guidance on their continued distribution and use of such software, respectively, as well as the impact on regulatory strategy for and timeline for availability of software currently in development. We expect this guidance will generate concerns not only from software developers but also from HCPs, health care institutions, payors, and patients. Stakeholders with such concerns may consider expressing them through the submission of public comments to the guidance document’s docket at regulations.gov, filing of Citizen Petitions, or legislative engagement.