backREAD OUR ARTICLE IN LAW360
With the exponential growth in digital health technology, drug and software developers alike increasingly have turned to mobile applications and other digital tools to improve patient experience. The result is prescription drug use-related software (“PDURS”)—things like diary digital apps in which patients input their symptoms and autoinjectors that can track and record the amount of drug dispensed.
This pairing of drug use and software has long existed in a kind of regulatory limbo: the software may or may not be regulated as a medical device, and approved drug labeling may or may not incorporate digital tools. FDA issued a Federal Register notice in 2018 proposing a loose framework for agency oversight of software disseminated by or on behalf of a drug sponsor. Now, nearly five years later, FDA has issued its long-promised draft guidance, Regulatory Considerations for Prescription Drug Use-Related Software (“PDURS Draft Guidance”).1Notice of availability, Regulatory Considerations for Prescription Drug Use-Related Software; Draft Guidance for Industry; Availability, 88 Fed. Reg. 64,443 (Sept. 19, 2023). The draft guidance explains FDA’s thinking regarding regulation of PDURS (and drug/software combinations more generally). While informative as a starting point, the draft guidance also leaves us with a lot of questions.
PDURS Output v. Software Function
FDA defines PDURS as “software that (1) is disseminated by or on behalf of a drug sponsor and (2) produces an end-user output that supplements, explains, or is otherwise textually related to one or more of the sponsor’s drug products.”2PDURS Draft Guidance § III. On the first of these prongs, the draft guidance is conspicuously silent on what FDA means by “disseminated … on behalf of” a drug sponsor. (Query, for example, whether a contract between a drug sponsor and a software developer would render the two parties “affiliated” and mean the software would be captured as “PDURS.”) The draft guidance focuses instead on regulation of the end-user output—i.e., any material, such as screen displays and even sounds and messages, that the software presents to an end user, whether that person is a patient, caregiver, or health care practitioner. FDA will consider such output to be prescription drug labeling, under the same labeling authorities that govern FDA’s review of prescribing information (“PI”) and patient labeling and other forms of labeling.
The guidance thus sets up a dual regulatory framework with the end-user output considered as distinct from the software function. In point of fact, whether or not the software will be considered a medical device (“software as a medical device” or “SAMD”), the software output will be considered under PDURS and will be regulated as either FDA-required labeling or as promotional labeling.
Further, for PDURS that relies on data directly transferred to the device constituent part of a combination product, which FDA calls “device-connected” PDURS, the Agency will review the software as part of a drug-device combination product. As such, sponsors will be expected to support applications with information to demonstrate that the software constituent part will not lead to medication errors. For other, “non-device-connected” PDURS, FDA review will depend on whether the software independently meets the definition of a “device,” with FDA emphasizing that the PDURS Draft Guidance does not alter the regulatory framework for SAMD.
Interestingly, FDA appears to take the position that, when warranted, review of the SAMD constituent of a SAMD-PDURS combination would occur in a standalone device marketing application, with Center for Devices and Radiological Health (“CDRH”) reviewing representations about the drug, in consultation with the Center for Drug Evaluation Research (“CDER”) or the Center for Biologics Evaluation and Research (“CBER”)—while CDER or CBER would review a drug application type.3See id. § IV.C & n.30.This approach raises a number of questions. In particular, it seems to conflict with the requirement that FDA “[s]hall conduct the premarket review of any combination product under a single application, whenever appropriate,” and the FDA Guidance for Industry, Principles of Premarket Pathways for Combination Products (2020), which explains that generally a single marketing application should suffice.4See section 503(g)(1)(B) and 503(g)(6) of the FD&C Act; see also FDA Guidance for Industry, Principles of Premarket Pathways for Combination Products (Jan. 2022) (“In limited situations, FDA may determine that a single application is not appropriate and thus that an application for each constituent part is warranted.”). We expect FDA will get a lot of comments on how these complicated regulatory frameworks can all be expected to interact without adding burdens on drug and device developers alike.
PDURS Output as Labeling
With the above framework in mind, the PDURS Draft Guidance sets out to distinguish between scenarios in which end-user output will be considered FDA-required labeling and those in which it will be considered promotional labeling. As a corollary issue, the draft guidance seems to reflect a struggle with the question of whether the PI should describe PDURS end-user output and software functions and, if so, in what sections.
The draft guidance outlines three factors that inform this analysis: (1) whether the PDURS provides a function that is essential to the safe and effective use of the product; (2) whether evidence is provided to support a clinical benefit from use of PDURS; and (3) whether the PDURS is “device-connected”.
- Essential to safe and effective use: the PDURS Draft Guidance barely makes further reference to this factor, and it does not describe how FDA will determine whether software is necessary for safe and effective use. The draft guidance also is noticeably silent as to how PDURS would or should be incorporated into the PI if necessary for safe and effective use.
- Evidence to support clinical benefit: FDA explains that sponsors may seek to include information in the PI demonstrating that use of the PDURS results in a meaningful improvement in clinical outcome with respect to the drug in question. The draft guidance suggests that clinical benefits must be demonstrated by at least one adequate and well-controlled study (presumably to the exclusion of human factors data). If they are, the end-user output will constitute FDA-required labeling. FDA recommends inclusion of such clinical benefit information, if any, in the CLINICAL STUDIES section of the PI, as clinical studies that “facilitate an understanding of how to use the drug safety and effectively.”521 C.F.R. 201.57(c)(15).
- Device connectivity: For device-connected PDURS, the draft guidance explains FDA’s thinking that prescribers should be made aware of these additional device features to inform their prescribing decisions and communicate the data transfer capabilities to their patients. The draft guidance walks a fine line, however, with respect to whether and how the PDURS should be reflected in the PI under these circumstances. On the one hand, FDA recommends inclusion of a brief description of the device and associated software functions in the PI’s HOW SUPPLIED/STORAGE and HANDLING section.6See PDURS Draft Guidance § IV (lines 202-210); see also id. § IV.B. On the other hand, FDA explains that the end-user output would be considered promotional labeling and should not be described in the PI7See id. § IV.B.—creating an obvious tension that will need to be navigated moving forward.
These three prongs are described as independent of one another—and in particular the guidance treats the “clinically meaningful benefit” analysis as distinct from the question of device connectivity. However, as a matter of practical application, there seems to be a significant amount of overlap, especially with respect to the question of how and where PDURS will be referenced in other sections of the PI when warranted. We decode FDA’s proposed analysis (which again, is remarkably devoid of detail on the question of PDURS that is considered necessary for safe or effective use) as follows:
PDURS and Post-Approval Changes
We read the way that FDA has teed up inclusion of PDURS and PDURS output in labeling to mean that changes to end-user output that are regulated as FDA-required labeling will be subject to the same reporting requirements as any other change to FDA-required labeling, in accordance with 21 C.F.R. §§ 314.70 (drugs) and 601.12 (biologics). Even when the PDURS output is regulated as promotional labeling, FDA expects to be notified of the change, either under the existing requirements for promotional labeling,8See 21 C.F.R. §§ 314.81(b)(3)(i), 601.12(f)(4). or a premarket submission to CDRH. Changes to software that do not impact the end-user output, such as a security patch, however, would not be submitted to FDA.
PDURS and Follow-On Products
The draft guidance fails to directly tackle the significant issue of how inclusion of PDURS software functions and end-user outputs in labeling will impact generic and biosimilar applicants. The PDURS Draft Guidance does not suggest incorporating PDURS into the INDICATIONS AND USAGE or DOSING AND ADMINISTRATION sections of the PI, leaving open the possibility that inclusion of either software function or clinical benefit information will not preclude follow-on competition. However, the draft guidance leaves unanswered many of the complicated questions as to when, and under what circumstances, a generic or biosimilar can differ from its respective reference listed drug (“RLD”) or reference product (“RP”) in the context of PDURS.
For example, while generics and biosimilars routinely carve out information from the CLINICAL STUDIES section of the RLD and RP labeling, it is difficult to envision how a generic or biosimilar could carve out PDURS that provides a clinically meaningful benefit and still satisfy the standards for therapeutic equivalence (generics) or no clinically meaningful differences (biosimilars). Intellectual property considerations also could preclude a generic or biosimilar from incorporating an identical PDURS, but the PDURS Draft Guidance provides no insight into permissible differences across PDURS.
Things become even more opaque with respect to device-connected PDURS. The HOW SUPPLIED/STORAGE and HANDLING section of the PI often differs between a generic or biosimilar and its RLD or RP, but FDA’s position that information about device-connected PDURS can inform prescribing decisions and differentiate the product raises the specter as to whether a device-connected PDURS would be considered a condition of use that the generic or biosimilar must match.
Conclusion
We were glad to see FDA’s draft guidance as so many questions have permeated with respect to use of software in conjunction with prescription drugs. Now that we have read the guidance, we are already anxiously awaiting finalization in the hopes that some of our new (and lingering) questions will be answered. For instance, how does the PDURS framework co-exist with the exclusion of clinical decision support software from SAMD?921 U.S.C. § 360j(o)(1)(E); see also FDA Guidance for Industry, Clinical Decision Support Software (Sept. 2022). How will FDA define the contours of “essential to the safe and effective use”? How will FDA determine primary mode of action for assigning application types to PDURS combination products? How will the CDER Office of Prescription Drug Promotion absorb submissions of software output as promotional materials? What kinds of PDURS output may be submitted in an annual report consistent with 21 C.F.R. § 314.70(d)(2)?
Perhaps most importantly, how will this framework function in practice? The PDURS Draft Guidance provides examples of PDURS functions and end-user outputs, but it does not tell us how the identified software functions and end-user output would ultimately be reflected in the drug’s PI in the scenarios described. Similarly, the draft guidance provides examples of device software functions regulated by CDRH for which the end-user output is considered promotional labeling. But, it does not tell us what happens if the software is excluded as clinical decision support software, nor how a drug sponsor should navigate a new pairing of such software with a drug in a way that renders the software “essential to the safe and effective use.” We will be paying close attention to these issues and more.
***
King & Spalding LLP regularly counsels drug and device manufacturers and other life sciences companies on product development and the submission of drug, biological product, and device applications to FDA. Comments on the PDURS Draft Guidance are due to FDA by December 18, 2023. Please let us know if you have any questions regarding the PDURS Draft Guidance or are interested in submitting a comment.
This article was originally published in Law360.
