Tech Support: FDA’s Evolving Regulatory Plan for Drug- and Device-Enabling Software

By Scott Liebman, Dominick DiSabatino, Arushi Pandya & Audrey Crowell

It is no secret that the U.S. Food & Drug Administration (FDA or the agency) has struggled to pace regulatory policy with the rapidly evolving digital health landscape—in fact, FDA Commissioner, Dr. Robert Califf, M.D., confirmed the same in a press conference earlier this year.^[1] It turns out, regulating individual digital health technologies is tricky because, as a general matter, regulation tends to be proportionally reactive to the speed and complexity of innovation. This has resulted in piecemeal policymaking and categorical schema which, by nature, can fail to capture nuance within drug- and device-enabling software, putting the industry in jeopardy of potential over-enforcement.

Thankfully, principles like the FDA concept of “intended use” tend to be the best guidance for tricky regulatory frameworks and enforcement landscapes. For manufacturers of drug- and device-enabling software products, it is key to consider whether FDA would view descriptions of software product capabilities in promotional materials as problematic (e.g., exceeding the specific intended use approved or cleared by FDA), especially if the software is consumer-facing, which FDA has identified as presenting a potentially increased risk to patient safety. What strategies is FDA employing to ensure that software products are safe and effective for patient use, and how do we apply first principles to help mitigate enforcement risk?

I. FDA’s Classification of Software Products

The current regulatory scheme for drug- and device-enabling software is beginning to take shape but remains something of a puzzle of often overlapping product classifications. As a general principle, if a software function is intended for use in performing a medical device function (i.e., for diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease), it is regulated as a medical device-enabling software.^[2] Similarly, if a software function is intended for use in supplementing, explaining, or otherwise enabling a drug product, it is generally regulated as drug-enabling software.^[3]

In determining whether a software function warrants FDA regulation and, if so, the appropriate type of regulation, the agency looks at the function and intended use of the product, rather than other product features, such as the delivery platform. The following FDA-created classifications add to the patchwork that is the agency’s current regulatory approach to overseeing digital health products.

a. Device Software Functions

FDA refers to software functions that meet the Federal Food, Drug, and Cosmetic Act (FDCA) definition of device (i.e., are intended for use in the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease) as “device software functions.”^[4] Device software functions include Software as a Medical Device (SaMD)^[5] and so-called “mobile medical applications,”^[6] which FDA defines in relevant guidance documents. A third category of device software functions, which may or may not also qualify as SaMD or a mobile medical application, is a “remote monitoring device.” Although the term is not defined in regulation, FDA describes a remote monitoring device as a device, or a device component, used to acquire patient physiological data on a remote basis without the need for in-clinic visits and to facilitate patient management by healthcare providers and patients alike.^[7]

FDA has specifically created a “Patient Monitoring and Control Program” to identify and find solutions for regulatory gaps and challenges with respect to remote monitoring devices—another distinct example of technology outpacing regulatory capabilities—which primarily pertain to the lack of available testing methods to ensure the safety and efficacy of remote monitoring devices before they are relied upon by patients and healthcare professionals in the market.^[8] The creation of this specific program, as well as FDA’s issuance of multiple Warning Letters targeting remote monitoring devices this year, indicate that the remote monitoring device subset of digital health software is a top concern and a priority for the agency.

FDA deems device-enabling software to be a medical device “component,”^[9] which is subject to the same level of regulation as the predicate device if the software is “intended for use in the diagnosis of disease or other conditions or in the cure, mitigation, treatment, or prevention of disease.”^[10] However, as explained in FDA’s Guidance on Policy for Device Software Functions and Mobile Medical Applications, many device-related software functions are not regulated by FDA, either because they do not meet the definition of a device or because they pose a lower risk to the public and, accordingly, FDA exercises its enforcement discretion. Therefore, “FDA intends to apply its regulatory oversight to only those software functions that are medical devices and whose functionality could pose a risk to a patient’s safety if the device were to not function as intended.”^[11]

b. Artificial Intelligence and Machine Learning (AI/ML)

Software that incorporates AI/ML is increasingly prevalent and, although it presents a host of potential therapeutic benefits,^[12] it also poses a unique challenge for regulatory oversight, and, accordingly, is an area of significant FDA concern. Due to AI/ML software’s hallmark characteristic of continuous, automated development and evolution, this new type of software does not fit within FDA’s current regulatory framework for device component modifications, which typically requires that manufacturers of software components receive approval and/or clearance from FDA before introducing a software modification that materially affects the safety and/or efficacy of the device.^[13] Consequently, FDA is still developing a regulatory strategy for these technologies. Indeed, by definition, these AI/ML platforms evolve continuously, which can be a problem for regulation and means that FDA may need to create an entirely novel regulatory approach. Determining when an algorithm has been sufficiently changed to warrant reevaluation is difficult, especially in the context of adaptive algorithms, which learn and self-modify in response to real-time data. Further still, AI/ML programs tend to incorporate different algorithmic approaches within the same model.^[14]

To compound FDA’s regulatory challenge in this space, AI/ML capabilities have increased significantly in recent years, and even in recent months, without signs of slowing, due to the development of what FDA calls “large language models” (LLMs). LLMs are generative AI models that are trained on very large datasets, enabling them to recognize, summarize, translate, predict, and generate content (e.g., ChatGPT). Although FDA has not cleared or approved any LLM software products to date, it will no doubt be a significant item on the regulatory agenda moving forward.^[15]

In response to this increasingly complex regulatory conundrum, FDA asked the industry to weigh-in, issuing multiple publications, including discussion papers and guidance documents,^[16] to elicit proposals for a regulatory approach that will allow for continued growth in the same stride as ensuring consumer protection. Most recently, FDA proposed a transparency-based regulatory framework that would require a “predetermined change control plan” in premarket submissions for regulated drugs and/or devices enabled by AI/ML technology. Manufacturers would be required to agree to a range of pre-authorized modifications (i.e., automated enhancements), as well as associated verification and validation testing and acceptance criteria to assure the device remains safe and effective across relevant patient populations as the software implements automated self-improvements.^[17]

c. Prescription Drug Use-Related Software

Although most of FDA’s recent regulatory activity with respect to medical software regulation has been in the device space, the agency recently issued a draft guidance that illustrates a concerted focus to unify the regulatory approach to digital health across all regulated categories (e.g., drugs, biologics, and devices). The draft guidance adds a piece to the ever-expanding puzzle that is FDA’s regulatory framework for digital health products and clarifies how FDA plans to apply its drug labeling regulations to software products that: i) are disseminated by or on behalf of a drug sponsor; and ii) “supplement, explain, or otherwise textually relate to” the use of a prescription drug.^[18] Specifically, FDA will require manufacturers of prescription drug use-related software to present so-called “end-user outputs” to FDA either before or after marketing the product, depending on whether the end-user output qualifies as “FDA-required labeling” or “promotional labeling,” as described in the draft guidance. FDA intends to analyze multiple factors to determine whether an end-user output should be treated as FDA-required labeling or promotional labeling and how, or if, the corresponding software function should be described in the drug’s Prescribing Information.

d. Unregulated Software Products

FDA has identified several categories of software products, including Clinical Decision Support (CDS) Software and “General Wellness Products,” that either do not qualify as devices or that technically qualify as devices but that FDA deems appropriate for enforcement discretion due to a relatively minimal risk to public safety. FDA’s decision to exercise enforcement discretion for these software product categories is in many ways an acknowledgment that the agency simply cannot and should not regulate the entirety of digital health technologies. FDA typically prioritizes the riskiest software products and has deemed the following categories to be safe—or, at least, safe enough—to self-regulate until FDA further elaborates or decides otherwise.

i. Clinical Decision Support (CDS) Software

One such category is what FDA deems “Non-Device CDS Software,” which has been the subject of recent enforcement action.^[19] In 2016, the 21st Century Cures Act (Cures Act) amended the FDCA to exempt certain low-risk software, including certain CDS Software, from the definition of “device.”^[20] While there is no single definition for CDS Software and the term is used broadly and in differing ways depending on the context, CDS Software has been described as software “providing healthcare providers (“HCPs”) and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care.”^[21] In its Guidance on CDS Software, FDA sets forth a list of software functions and criteria for classification that constitute Non-Device CDS Software. If a software function meets all four of the following criteria, it is considered Non-Device CDS Software and, thus, is not subject to FDA regulation: the software function is i) 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; ii) intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information; iii) intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and iv) intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.^[22]

ii. General Wellness Products

Software products that qualify as “General Wellness Products” (i.e., low-risk products that promote a healthy lifestyle) are also generally free from FDA regulation. The Cures Act amendment also exempts from the definition of “device” “software that is intended for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.”^[23] In its Guidance on General Wellness: Policy for Low-Risk Devices, FDA refers to this statutorily excepted product category as “General Wellness Products.” This approach aligns with the agency’s regulatory plan for digital health products overall, which is to focus only on those products that could pose a risk to public safety if left unregulated.

II. The Need for Regulatory Oversight

As touted a myriad of times by Congress, FDA, and industry, the need for regulatory oversight with respect to all drug- and device-enabling software boils down to one key concern—patient safety.

a. Overview

Because FDA has not been able to keep pace with the technological advancements in the drug- and device-enabling software space, many sophisticated products are being marketed without regulatory oversight of any kind. This presents an obvious safety risk for patients and HCPs who rely on these products to diagnose and/or treat various, sometimes very serious, conditions, despite the fact that the products have not been verified to have met FDA’s standards for safety and efficacy—especially when the product is consumer-facing and, thus, lacks the safety net of intermediary clinical judgment.^[24]

FDA regulates some software products through traditional regulatory pathways, such as pre-market approval (PMA), new drug application (NDA), 510(k) clearance, or post-market labeling review, which focuses on a software product’s congruence with the specific intended use approved or cleared by FDA prior to commercialization. However, a consistent regulatory challenge is that many of these products are being promoted and/or used in a manner that exceeds the scope of the product’s approved or cleared intended use, which thwarts the entire purpose of FDA’s assessment of intended use—to ensure that it is safe and effective for the ultimate consumer. Thus, FDA has dedicated significant enforcement effort to crack down on manufacturers’ unilateral expansion of intended use, thereby underscoring the importance of looking to intended use as a first principle when making risk assessments.

b. Recent Enforcement Action

i. Device Enabling-Software

FDA has issued only a handful of Warning Letters to medical-device manufacturers this year, with two of the letters aimed at devices and associated remote monitoring software that were promoted in a manner exceeding the scope of intended use in the products’ 510(k) clearance, and a third aimed at a device manufacturer who improperly promoted its product without FDA approval under the attempted cover of the Non-Device CDS Software exemption. These enforcement actions indicate that FDA is keeping a close eye on the scope of intended use for software-enabled medical devices, and, in order to determine if and when so-called “intended use creep” has occurred, is closely assessing promotional claims that suggest a function which has not been approved and/or cleared by FDA for the product.

1. Intended Uses Exceeding 510(k) Clearance

On May 25, FDA issued a Warning Letter to iRhythm Technologies, Inc. (the “iRhythm Warning Letter”),^[25] and one month later, on June 21, FDA issued a Warning Letter to Zyto Technologies, Inc. (the “Zyto Warning Letter”)^[26] citing the companies’ promotion of remote monitoring software for functions outside the scope of intended use cleared under the devices’ 510(k) clearances. FDA took specific issue with promotional materials associated with iRhythm’s Zio AT System that suggested that the device could be used to provide real-time monitoring to high-risk cardiac patients. Similarly, FDA scrutinized Zyto for promotional materials that suggested that its Galvanic Skin Response (GSR) measurement tool could be used to identify “stressors” that could indicate specifically named conditions, as well as “balancers” representing specific treatments, mitigations, and preventative measures for a given stressor.

As emphasized in the Warning Letters, promotion of the software products for these purposes posed a significant threat to patient safety because the software products had not been previously cleared as safe and effective for either of these uses—the Zio AT System was only cleared for long-term monitoring of symptomatic and asymptomatic cardiac events in adults, and the Zyto Hand Cradle was only cleared to measure GSR. Moreover, the risk posed by intended use creep in these instances was escalated by the fact that the products were consumer-facing. In both instances, high-risk patient groups would be likely to improperly and detrimentally rely on these promotional claims (and, in turn, use the devices for purposes exceeding the products’ pre-cleared intended use), even though the devices had not been cleared as safe and effective to warrant such reliance from these high-risk patient populations.

2. Narrow Application of the Non-Device CDS Software Exemption

On September 19, FDA issued a Warning Letter to Abiomed Inc. (the “Abiomed Warning Letter”),^[27] citing the company’s promotion of its Class III Impella Connect System—which incorporates remote monitoring functions—without having obtained an approved PMA. FDA’s finding was, in part, based on the product’s website instructions, which indicate that device components consisting of a web-based user portal (i.e., software) and a remote link module (i.e., hardware) allow users to remotely monitor the performance of an automated pump and view case information on demand, as well as filter notifications by alarm status, to facilitate the patient’s ventricular activity in a critical care setting.

Despite Abiomed’s argument that the software functions of its product qualify as Non-Device CDS Software functions because they provide metrics to clinical users, FDA maintained that the software functions do qualify as device functions that pose a significant enough risk to public health so as to warrant FDA oversight because the functions “provide patient-specific medical information to detect a life-threatening condition and generate time-critical alarms intended to notify an HCP.” The Abiomed Warning Letter provides an important reminder to industry participants that FDA construes the Non-Device CDS Software exemption narrowly and that a device software function is not exempt from regulatory oversight simply because one of its functions is to provide decision support to HCPs. Because the website instructions for the Impella Connect System would reasonably induce an HCP to rely on the automated alarms in order to take time-critical action to address one or more life-threatening conditions, even though the software has never been assessed for safety and/or efficacy with respect to this purpose, it poses a significant risk to patient safety.

ii. Drug-Enabling Software

FDA’s guidance on prescription drug use-related software was closely preceded by two back-to-back Warning Letters issued to pharmaceutical manufacturers who failed to comply with FDA’s CGMP regulations for finished drugs, each of which cited failure to adequately verify and control software associated with the drug’s laboratory process. On July 28 of this year, FDA issued a Warning Letter to Intas Pharmaceuticals Limited (the “Intas Warning Letter”)^[28] and less than a month afterward, on August 2023, FDA issued a nearly identical Warning Letter to Lex Inc. (the “Lex Warning Letter”).^[29] Both letters expressed concern for the manufacturers’ lack of knowledge regarding software functions that support laboratory functions necessary to the manufacturing of the companies’ drug products. Although the Instas and Lex Warning Letters did not address the end-user output labeling concerns cited in FDA’s guidance on prescription drug use-related software, when taken with the subsequently issued guidance, they do suggest that FDA is concerned with enabling software at all stages of a drug or device’s life cycle, and that the agency intends to hold manufacturers accountable for the operation of such software to the extent necessary to ensure that the final product is safe and effective for use by the intended patient population.

III. Key Takeaways

a. Promotional Considerations for Industry Participants

Recent FDA activity in the digital health space, including agency intentions stated in guidance documents and violations emphasized in recent Warning Letters, indicates that one of FDA’s prime concerns with respect to drug- and device-enabling software is the unilateral expansion of the software’s intended use for purposes that have not been approved or cleared by FDA. To monitor this issue, FDA has been looking closely at manufacturers’ promotional product claims. Intended use creep will be an ongoing enforcement priority for FDA, as it reflects the difficulties inherent in regulating digital health products through the product lifecycle and, more importantly, potential jeopardization of patient safety by exposing patient populations to functions that have not been assessed for safety and/or efficacy, especially when the software product is consumer-facing.

With several of the mere handful of medical device Warning Letters issued by FDA this year focusing on the promotion of device software functions outside the scope of FDA approval or clearance, FDA has clearly taken a heightened focus on software, specifically. Further, FDA’s issuance of two Warning Letters and one guidance document that all focus on drug-enabling software in the span of only a few months suggests an expansion of FDA’s focus from strictly device-enabling software to drug- and biologic-enabling software. FDA is closely scrutinizing the addition of, and/or modification to, software that supports a drug or device, especially if the software incorporates diagnostic and/or treatment capabilities, as this has the potential to alter the functionality of the drug or device itself and may jeopardize user safety if it is not developed and commercialized through the proper channels.

Ultimately, FDA is looking to crack down on manufacturers who purport to unilaterally expand the software function of a drug or device product without adhering to the safeguards that FDA has carefully designed to ensure public safety. Product development teams should be familiar with the scope of a product’s intended use under an FDA marketing approval and/or clearance, and should remain vigilant about conducting testing and seeking expanded approval and/or clearance when new or modified product capabilities may exceed the scope of intended use.

b. Product Categories in FDA’s Spotlight

FDA has, through guidance documents, webinars, and other administrative publications, as well as recent enforcement actions, expressed particular interest in software products that: i) have an AI/ML component, ii) have a remote monitoring function, iii) claim to be CDS Software, and/or iv) are consumer-facing. Manufacturers of software products with one or more of these features should anticipate increased regulatory activity from FDA.

Specifically, given that the primary impetus for regulating drug- and device-enabling software in the first place is patient safety, FDA is particularly concerned with consumer-facing software products. Drug- and device-enabling software functions encompass varying levels of risk based upon the intended end user, and products that are consumer-facing are more likely to offer a therapeutic impact without the safety net of intermediary clinical management in the event of a software malfunction or the patient’s misuse of the product. So, manufacturers of consumer-facing software products should expect an increased level of regulatory scrutiny and should carefully evaluate intended beneficiaries during all stages of the product lifecycle.

c. Implications of a Reactive Regulatory Structure

FDA’s inability to keep pace with rapidly advancing technology in the digital health space appears to be a consistent theme that, absent a significant boost in regulatory initiatives, will carry forward into 2024 and beyond. As noted, FDA’s regulation of sophisticated, ever-advancing digital health products has been reactive to innovation, rather than proactive, which creates a notable lag and undermines many regulatory initiatives before they are even able to get off the ground. In turn, manufacturers of these complex software products are placed with the precarious task of continuing innovation in a forward-looking posture while reacting to regulatory requirements that are, often times, structured for outdated software functions.

In recognition of the negative impact of its current regulatory approach, FDA has taken a significant step toward overcoming its deficiencies in regulating digital health products by launching a Digital Health Advisory Committee (“Committee”).^[30] The Committee, which is set to be fully operational in 2024, will consist of nine digital health experts, who will help create a regulatory approach to ensure that FDA’s regulation of digital health products keeps “an appropriate pace” while maintaining FDA’s safeguards for patient safety. Additionally, the Committee is tasked with helping FDA understand how to best address certain issues that span all categories of digital health products—including decentralized trials, patient-generated health data, cybersecurity, and ensuring that products are safe and effective for diverse populations. By creating the new Committee, FDA acknowledges the unique regulatory challenge posed by the digital health industry and the necessity of embracing collaborative solutions to strike the ever-important balance between innovation and safety.

In the spirit of this collaborative approach, and given FDA’s inability to keep pace in an area that is undoubtedly very complex, the agency has also indicated a unique receptiveness to input from the industry at large. For example, FDA’s recent discussion paper on the proper regulatory scheme for AI/ML products requests high-level feedback from industry participants on how the overall regulatory framework should be structured^[31]—a solicitation that is distinctly broader than usual FDA requests, which are typically limited to request for comments on narrowly tailored questions. Accordingly, industry participants should keep a watchful eye on FDA publications in this space and should take every opportunity to provide meaningful input in order to help create a regulatory framework that protects patient safety without hindering technological innovation.

IV. Conclusion

Like other areas of technology, regulators are constantly chasing innovation in the digital healthcare landscape. With no sign of a coming slowdown, FDA will be consistently reviewing and restructuring regulatory strategies in order to try and keep pace and to, ultimately, protect public safety. Industry participants should pay particular attention to FDA activity in the digital health space, especially with respect to drug- and device-enabling software functions, and should remain experts in the operation of their own software products and the first-principle parameters of FDA’s approval and/or clearance of such products, especially in terms of the intended use rule. Further, careful consideration should be given to product promotion when the product is a consumer-facing product, especially if the product incorporates AI/ML or remote monitoring functionality or is allegedly exempt from regulation as a CDS Software product. When it comes to digital health, technological advancement seems limitless—but patient safety remains a limit that regulators and industry participants, alike, must respect.

 

[1] See Speech by Robert M. Califf, M.D. to the National Health Council’s 2023 Science for Patient Engagement Symposium—Patient Empowerment in the Digital Health Era, U.S. Food & Drug Admin. (May 8, 2023).

[2] See 21 C.F.R. §321(h).

[3] See FDA Draft Guidance on Regulatory Considerations for Prescription Drug-Use Related Software, U.S. Food & Drug Admin. (Sept. 2023).

[4] See FDA Guidance: Policy for Device Software Functions and Mobile Medical Applications, U.S. Food & Drug Admin. (Sept. 28, 2022).

[5] See Software as a Medical Device (SaMD), U.S. Food & Drug Admin. (last accessed Oct. 26, 2023).

[6] See supra note 4.

[7] See FDA Guidance: Enforcement Policy for Non-Invasive Remote Monitoring Devices Used to Support Patient Monitoring, U.S. Food & Drug Admin. (Oct. 19, 2023); Patient Monitoring and Control Program, U.S Food & Drug Admin. (last accessed Oct. 31, 2023).

[8] See Patient Monitoring and Control Program, U.S Food & Drug Admin. (last accessed Oct. 31, 2023).

[9] FDA defines “component” in regulation as “any raw material, substance, piece, part, software, firmware, labeling, or assembly which is intended to be included as part of the finished, packaged, and labeled device” (emphasis added). See 21 C.F.R. §820.3(c).

[10] See 21 C.F.R. §321(h).

[11] See FDA Guidance, supra note 4, at p. 2.

[12] FDA cites one of the greatest potential benefits of AI/ML software as “its ability to create new and important insights from the vast amount of data generated during the delivery of health care every day.” AI/ML-Enabled Medical Devices, U.S. Food & Drug Admin. (Oct. 19, 2023).

[13] See FDA Guidance on Deciding When to Submit a 510(k) for a Change to an Existing Device, U.S. Food & Drug Admin. (Oct. 2017).

[14] See Artificial Intelligence and Machine Learning (AI/ML)-Enabled Medical Devices, U.S. Food & Drug Admin. (last accessed Oct. 30, 2023).

[15] See id.

[16] See, e.g., Patrizia Cavazzoni, M.D., FDA Releases Two Discussion Papers to Spur Conversation about Artificial Intelligence and Machine Learning in Drug Development and Manufacturing, U.S. Food & Drug Admin. (last accessed Oct 26, 2023); Draft Guidance on Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions, U.S. Food & Drug Admin. (Apr. 2023).

[17] See FDA Draft Guidance on Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions, U.S. Food & Drug Admin. (Apr. 3, 2023).

[18] See supra note 3.

[19] See Warning Letter: Abiomed Inc., U.S. Food & Drug Admin. (Sept. 19, 2023).

[20] See FDCA §520(o)(1)(E).

[21] See What is Clinical Decision Support (CDS)?, HealthIT.gov (last accessed Oct. 26, 2023).

[22] See FDCA §520(o)(1)(E).

[23] See FDCA §520(o)(1)(B).

[24] See, e.g., 21 C.F.R., Chapter I, Subchapters A, C, D, and H.

[25] See Warning Letter: iRhythm Technologies, Inc., U.S. Food & Drug Admin. (May 25, 2023).

[26] See Warning Letter: ZYTO Technologies, Inc., U.S. Food & Drug Admin. (June 21, 2023).

[27] See supra note 13.

[28] See Warning Letter: Intas Pharmaceuticals Limited (July 28, 2023).

[29] See Warning Letter: Lex Inc. (Aug. 17, 2023).

[30] See News Release – FDA Establishes New Advisory Committee on Digital Health Technologies, U.S. Food & Drug Admin. (Oct. 12, 2023).

[31] See Discussion Paper and Request for Feedback: Using Artificial Intelligence & Machine Learning in the Development of Drug & Biological Products, U.S. Food & Drug Admin. (May 10, 2023).