FDA’s Latest Twist on Digital Health Oversight Brings Big Shift // Cooley // Global Law Firm

Facing novel, swiftly evolving technologies in the digital health space, the US Food and Drug Administration has been trying to balance fostering innovation with providing reasonable assurance of safety and effectiveness under a regulatory framework for devices that dates back to 1976. Major changes impacting digital health companies came with the passage of the 21st Century Cures Act in 2016, which carved out certain categories of software from FDA oversight. Since then, the FDA has issued numerous guidance documents providing details on these carve outs, as well as the agency’s general approach to regulating digital health technologies.

In its early digital health guidance documents, the FDA sought to harmonize its thinking with that of the international community, but it also announced specific areas of enforcement discretion for low-risk devices. On September 28, 2022, however, the FDA issued three new final guidance documents in the digital health space – on clinical decision support (CDS) software, mobile medical applications and medical device data systems – as well as a report summarizing its findings on the Software Precertification (Pre-Cert) Pilot Program. The FDA’s recent efforts signal that the agency is moving toward more oversight of digital health companies. With more than 500 medical device approvals and clearances involving artificial intelligence (AI) and machine learning (ML) under its belt, the agency has a better understanding of the regulatory pressure points for these products, and in response, it has updated its current thinking on how it can regulate software as a medical device, given the Cures Act carve outs.

The most significant revision to the FDA’s current interpretation of the Cures Act is the recently finalized guidance on CDS software, in which the agency provides a more detailed interpretation of several statutory elements. On December 15, 2022, the FDA also updated its Digital Health Policy Navigator, a tool developed by the agency’s Digital Health Center of Excellence, to help industry understand the Cures Act analyses, including the non-device CDS exemption. Below, we’ve analyzed the practical implications of the most significant of these changes.

CDS software guidance

Per the Cures Act, software functions that meet the following four criteria are not devices under the Federal Food, Drug, and Cosmetic Act (FDCA):

It 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.
It 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).
It is intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition.
It is intended for the purpose of enabling a healthcare professional to independently review the basis for recommendations that the software presents, but not rely primarily on those recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.¹

While the agency cites this same statutory language in previous CDS draft guidance documents, as well as the newly issued final guidance document, the FDA’s new interpretation as explained in the final guidance includes parameters not specifically delineated by the statute.

Three key takeaways from the final CDS guidance

The final CDS guidance on its face appears to be significantly different from the previous draft guidance. Some changes, however, are more to form than substance. For example, rather than include a table indicating that CDS software that provides outputs focused on caregivers or patients does not qualify for the non-device CDS carve out and is instead subject to enforcement discretion, the FDA refers readers to its other Cures Act guidance documents announcing enforcement discretion policies for low-risk devices, such as its mobile medical applications guidance or general wellness policy for low-risk devices. Similarly, the International Medical Device Regulators Forum (IMDRF) framework is now referenced only in passing,²although several principles from that framework, such as the reference to intended use based on “label and instructions for use” (rather than FDA’s broader intended use regulation³), remain. The FDA acknowledges in this final CDS guidance that while the IMDRF provides “additional information regarding risk categorization and considerations that may apply to certain software functions,” it no longer embraces this framework as the foundation for the FDA’s revised current thinking as it did in the previous draft guidance.⁴ Beyond these changes intended to streamline the guidance, there are three areas where the agency’s current interpretation appears to narrow the non-device CDS exemption, particularly when compared to the 2019 draft guidance and the plain statutory language.

FDA’s current interpretation restricts non-device CDS inputs

The final guidance includes newly announced definitions for “medical image,” “signal” and “pattern” as those terms are used in Criterion 1. “Medical image” includes not only those images generated by medical imaging systems to view any parts of the body, but also images acquired for a medical purpose.⁵ Further, “pattern” refers “to multiple, sequential, or repeated measurements of a signal or from a signal acquisition system.” Notably, these definitions serve to exclude virtually all CDS functions that analyze continuous monitoring data, data from DNA sequencing or systems that track medical information over time. Recognizing that none of these technologies can qualify for the Cures Act carve out, the FDA falls back on the statute, noting that such products may be exempted if they do not qualify as a medical device based on their intended uses. Of course, the CDS carve out would be superfluous if it only applied to products that did not meet the device definition in the first place – i.e., products not intended to cure, mitigate, treat, prevent, or diagnose a disease or other condition, nor to affect the structure or any function of the body.

The FDA’s interpretation further restricts CDS inputs by narrowly defining “medical information” as the type of information that normally is, and generally can be, communicated between healthcare providers in a clinical conversation, or between healthcare providers and patients in the context of a clinical decision. This narrow reading could exclude from the non-device CDS carve out functions that can provide real value and time savings to healthcare providers, such as AI-driven technology and algorithms that aggregate and sort data, including data from sources that may be overlooked in current medical practice but may give insight into medical diagnoses or treatment. Taken together, the FDA’s broad interpretation of “medical image,” “signal” and “pattern” in Criterion 1, and the agency’s narrow interpretation of “medical information” in Criterion 2, restrict the allowable inputs for the non-device CDS exemption.

FDA’s final guidance is at odds with the agency’s approach to the ‘practice of medicine’

Perhaps the most significant change in the final guidance is the FDA’s interpretation of Criterion 3, including a newly announced focus on the potential for automation bias, particularly for time-sensitive decision making.⁶Specifically, the FDA voices a concern that healthcare providers may “over-rely on a suggestion from an automated system,” which could lead to poor outcomes if the system provides inaccurate information or an erroneous treatment option. To account for this risk, FDA suggests that non-device CDS software functions provide healthcare providers a prioritized list of treatment options, rather than one “specific preventive, diagnostic, or treatment output or directive.”⁷ The FDA further explains that it “considers software that … identifies a risk probability or risk score for a specific disease or condition” to fall outside the non-device CDS exemption, as such software functions provide a “specific preventive, diagnostic, or treatment output.”⁸

The CDS guidance also notes that functions “intended to support time-critical decision-making” likely would not be exempted because the agency posits that for “situations that require urgent action, automation bias increases because there is not sufficient time for the user to adequately consider other information.”⁹ The guidance similarly takes aim at devices that provide an alarm. Per the final guidance, software, including software “that provides time-critical alarms or alerts intended to trigger potential clinical intervention to assure patient safety,” would not satisfy Criterion 3.¹⁰ For software functions that provide specific recommendations in time-sensitive situations, FDA has signaled that it would expect sponsors to seek agency premarket review rather than view such products as non-device CDS.¹¹

This prohibition on non-device CDS that utilizes alarms or scoring functions appears to significantly narrow non-device CDS in emergency rooms where alarms are often used, and ignores the fact that healthcare practitioners who are specifically trained in emergency medicine must “regularly ‘make instantaneous decisions often without the benefit of medical histories, consultation, or time for reflection.’”¹² It is also curious that the cited support for this concern is a 2004 article, written three years before smartphones began gaining traction across the globe as a common element of daily life.¹³ In today’s world, many professionals, including healthcare professionals, are accustomed to receiving information from automated systems, such as text messages, throughout the day. Moreover, the FDA’s interpretation of this element appears on its face to run counter to the agency’s long-standing precedent to defer to the judgment of healthcare practitioners.¹⁴

While statutory language for Criterion 3 of the CDS carve out is consistent with the FDA’s approach to defer to “the practice of medicine” – in that it states that a product is not a device and therefore not regulated by FDA if it is “intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition” (emphasis added) – the FDA’s newly announced interpretation of Criterion 3 does not reflect this deference required by the FDCA and generally supported by the courts.¹⁵ Whereas the FDCA expressly allows for even off-label uses given the physician’s ability to make judgments in the best interest of patient care, in its interpretation of Criterion 3, the FDA is skeptical of physician decision making such that automated tools that provide specific recommendations or probability scores aimed at assisting providers in making clinical decisions do not appear to qualify for the non-device CDS exemption.

There is further tension in the FDA’s interpretation for Criterion 3, when contrasted with its interpretation of Criterion 4, in which the agency requires software to “identify the required input medical information” with a “plain language description of the underlying algorithm development and validation that forms the basis for the CDS implementation, including a summary of the logic or methods relied upon to provide the recommendations.”¹⁶ The FDA’s interpretation of Criterion 4 would arguably address any “automation bias” concerns because the clinicians would have to be provided with details about the software inputs and outputs.

FDA’s guidance requires labeling even for exempted products

Lastly, the agency’s interpretation of Criterion 4 raises a question about the agency’s reach over products intended to be exempted from its jurisdiction. The FDA explains in its Criterion 4 analysis that to fit within the non-device CDS exemption, software should include labeling that describes its purpose and intended use, the required inputs and medical information, and the underlying algorithm, among others. Yet if the product is exempted from the device definition, can the FDA really require specific labeling for such products? Additionally, given the agency’s long-standing approach to the intended use analysis,¹⁷ it is unclear whether the FDA would be satisfied with express labeling only to determine whether a product can qualify as non-device CDS, or whether it would engage in a broader intended use analysis.¹⁸ Perhaps this interpretation is a holdover from the IMDRF framework, in which intended use is determined on the “Label and Instructions for Use for Medical Devices” only.¹⁹ In any event, to the extent the FDA appears to be requiring products exempted from agency oversight to carry specific labeling, the agency’s interpretation of Criterion 4 potentially raises First Amendment concerns.

Practical considerations

The FDA’s interpretation of the non-device CDS carve out as announced in the final guidance will, at a minimum, require software developers and device manufacturers to have an increased understanding of FDA labeling requirements and conform descriptions of their software to a format and level of detail that the FDA finds acceptable. Given the FDA’s interpretation of Criterion 4, this is essential even for products that ultimately are exempted from FDA regulation. Developers also should pay particular attention to the language used in designing the user interfaces and promoting CDS software products, keeping in mind the principles in the FDA’s final guidance. For example, the difference between the FDA regulating a product as a device and the same product being exempt as non-device CDS software could hinge not only on the express language the agency suggests for Criterion 4, but also on a description of the software output as a consideration, rather than a risk score or probability. Additionally, developers need to keep in mind that diagnostic devices almost always will require FDA clearance or approval, as the non-device CDS exemption does not apply to diagnostic devices.

In addition to more careful device and output descriptions, software developers must take care to plainly “show their work” to qualify for the non-device CDS exemption.²⁰ In other words, to be excluded from the definition of a device, the software function must enable healthcare providers to independently review the basis for the recommendations presented by the software. In the final guidance, the FDA presents a few examples of labeling and device functions that fulfill this requirement. For example, in the case of a hypothetical software function that analyzes patient-specific medical information regarding end-stage renal disease and provides a list of treatment options based on practice guidelines, the FDA outlines a laundry list of required information that must to be provided to the healthcare provider to satisfy Criterion 4, including the intended use, patient population, medical information, data quality requirements, a plain language description of the underlying algorithm development and validation that forms the basis for recommendations, etc.²¹ This, according to the FDA, enables healthcare providers to rely on their own judgment, rather than such recommendations, to make clinical decisions for individual patients. Software developers should be prepared to provide adequate background information in plain language on the input(s), algorithm, datasets, validation and more, and they must describe in detail how their software functions analyze and calculate data to determine the recommendations they provide. This requirement, however, assumes that physicians have a sophisticated understanding of software and hence requires non-device CDS software to clearly explain the outputs such that a healthcare provider knows the full bibliography of information analyzed by the software. However, many physicians do not have data science or software engineering backgrounds, and requiring sophisticated algorithm development and validation to be explained in “plain language” could therefore be an exercise in futility.

Although the FDA has approved and cleared many devices with AI/ML and digital health technologies, undoubtedly many newly regulated devices will need to utilize the De Novo clearance process due to a lack of adequate predicate devices for these novel products.²² Thus, large companies that are already familiar with the De Novo process and have existing regulatory departments well-versed in FDA clearance and approval processes may be at an advantage in ultimately getting CDS products to market. Smaller companies interested in innovating will need guidance from those experienced in these areas to determine whether novel software might qualify for the non-device CDS exemption, given the final guidance, and also analyze software under the FDA’s enforcement discretion policies as explained in the mobile medical application, software as a medical device, medical device data systems and general wellness guidance documents.

Digital Health Policy Navigator

In the wake of the FDA’s final guidance, it is even more important to lean into FDA’s long-standing practice of analyzing software devices on a function-by-function basis.²³ Recognizing this need, FDA established the Digital Health Policy Navigator on September 28, 2022, to help determine whether a software function is subject to or the focus of the FDA’s regulatory oversight as a device, and it provides considerations that could be useful to determining the applicable FDA-specific legal and regulatory requirements and recommendations. Each step in the navigator is crafted to answer a question about the device function and often corresponds to a specific FDA-issued guidance document on the topic. For example, Step 6 helps determine if the software function is intended to provide clinical decision support.

Although the Digital Health Policy Navigator was announced when the final CDS guidance was published on September 28, the FDA only updated this tool with details on Question 6, which is the CDS analysis question, on December 15. We had wondered whether the FDA might share additional insights with industry on how to interpret the CDS analysis through the navigator’s answers to Question 6, but the FDA’s analysis with this tool merely tracks the examples provided in the CDS guidance. For example, the navigator explains that software with outputs rooted in clinical guidelines – such as physicians’ order sets, software linking patient-specific information to established clinical guidelines or reminders for preventive care based on such guidelines – could meet the elements required for the exemption. Similarly, the navigator notes that software identifying drug-drug interactions or drug-allergy interactions to avoid adverse events for patients may be exempted.

While the navigator does a good job of pulling the various digital health guidance documents into one streamlined questionnaire, the FDA makes certain to point out that the navigator’s results “are not a formal FDA device determination for your product.” The navigator can be useful for individuals without an FDA background to get a general idea of whether their software may be regulated by the FDA as a medical device. However, many novel devices raise more nuanced issues or questions regarding software functions that do not fit squarely into the questionnaire. In this case, a more comprehensive review of the FDCA, its implementing regulations and the FDA’s various guidance documents will be required to determine the appropriate regulatory pathway for software functions.

What’s next?

While some developers may wait in the wings to see how the FDA enforces this new guidance given the agency’s limited resources and risk-based approach to enforcement, the most likely impact of the final CDS guidance is an anticipated increase in the number of premarket submissions to the FDA for CDS products. Because premarket applications are not made public by the FDA until clearance or approval, it may be months or even years before we can evaluate the impact of this guidance on the volume of applications.

FDA lawyers at Cooley are well-equipped to advise on questions about these and other complex, cross-sectional issues raised by this guidance. If you have any questions or concerns, please reach out to the Cooley contacts listed below.

Notes

21 US Code § 360j(o)(1)(E).
See, Policy for Device Software Functions and Mobile Medical Application: Guidance for Industry and Food and Drug Administration Staff at 13.
21 CFR § 801.4
See, Clinical Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff (September 19, 2019) at 13. (“This guidance uses factors from the International Medical Device Regulators Forum (IMDRF) Framework to apply a risk-based policy for CDS software functions. This approach is consistent with FDA’s commitment to implement IMDRF documents specifically and advance global medical device regulatory harmonization generally.”)
See, Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff at 7.
Id. at 11 (“Automation bias is the propensity of humans to over-rely on a suggestion from an automated system. In the context of CDS, automation bias can result in errors of commission (following incorrect advice) or omission (failing to act because of not being prompted to do so).”) (citing M.L. Cummings, Automation Bias in Intelligent Time Critical Decision Support Systems. American Institute of Aeronautics and Astronautics 1st Intelligent Systems Technical Conference, Vol. 2, 2004, pp. 557-62).
Id. at 12.
Id. at 12-13.
Id. at 11.
Id. at 12.
Id.
See, Miranda v. National Emergency Services, Inc, 35 Cal. App. 4th 897 (1995) (citing James v. St. Elizabeth Community Hospital, 30 Cal. App. 4th 73 (1994)) (“Physicians covering emergency rooms must make instantaneous decisions, often without the benefit of medical histories, consultation, or time for reflection”).
See supra n. 9.
21 USC § 396; see also e.g., Wash Legal Found. v. Friedman, 13 F. Supp. 2d 51 (D.D.C. 1998), at 66 (“FDA does not purport to regulate the practice of medicine, and the agency has long recognized that, in general, physicians may use an approved drug or device for an unapproved use”).
21 USC § 360j(o)(1)(E)(iii); see also e.g., Judge Rotenberg Educ. Ctr., Inc. v. U.S. Food & Drug Admin., 3 F.4th 390 (D.C. Cir. 2021); United States v. California Stem Cell Treatment Center, Inc., No. EDCV 18-1005 JGV (C.D. Cal. Aug. 30, 2022). But see United States of America v. Regenerative Sciences, LLC, 741 F.3d 1314 (D.C. Cir. 2014).
See, Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff at 14.
See, e.g., United States v. Travia, 180 F. Supp. 2d, 115 (D.D.C. 2001) at 199 (“It is also well established that the ‘intended use’ of a product, within the meaning of the Act, is determined from its label, accompanying labeling, promotional claims, advertising, and any other relevant source”) (quoting Hanson v. U.S., 417 F. Supp. 30, 35 (D. Minn.)). In the FDA’s public statement in 2020 regarding types of evidence the agency considers when determining intended use, the FDA clarified that a manufacturer’s knowledge of a healthcare provider’s use of a medical product for unapproved use is not sufficient to establish the product’s intended use. In issuing this statement, the FDA reaffirmed its “longstanding position … that, in evaluating a product’s intended use, any relevant source of evidence may be considered.”
Id.
See, “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations at 7.
Id. at 13.
Id. at 19.
At present, devices generally are reviewed by the review division within the FDA’s Center for Devices and Radiological Health (CDRH) that has jurisdiction over the disease or condition that will be addressed by the device, with input by CDRH’s Digital Health Center of Excellence as necessary. An open question is whether, with a large influx of new software-based device applications, CDRH will continue to review CDS products in this manner or whether we will see increased involvement by the Digital Health Center of Excellence in these submissions.
The FDA traditionally has analyzed medical devices on a function-by-function basis. Per the FDA’s guidance on multiple function device products: “In accordance with existing policies, FDA intends not to review a device function subject to an enforcement discretion policy merely because it is part of a multiple function device product. Instead, FDA intends to review the device function(s) for which clearance or approval is being sought (e.g., the device function-under-review). For example, if a manufacturer seeks clearance or approval for a device function (e.g., analysis), and not the device function for which FDA has expressed its intention not to enforce compliance (e.g., trend), then FDA intends to only review the analysis function and assess the trend function only insofar as it could negatively impact the analysis function. In that instance, because FDA is reviewing the analysis function only, FDA’s decision to clear or approve applies only to the analysis function.”