Following a 2018 draft framework, FDA unveils long-awaited PDURS draft guidance

A long-awaited draft guidance on Prescription Drug Use-Related Software (PDURS) outlines when information from digital health tools could be represented on prescription drug labeling. Per the new draft guidance, key considerations include where the software gets its data inputs and what the expected benefit of the tool’s use could be.

Digital technologies as drug labeling: An intro to PDURS

• What is PDURS? In November 2018, the FDA published what it called a “proposed framework” on regulatory consideration for Prescription Drug Use-Related Software (PDURS). According to that document, PDURS are “software applications disseminated by or on behalf of drug sponsors for use with one or more of their prescription drug products.” In effect, technologies like a mobile health app that is intended to support a user (e.g., patient, caregiver) in the use of their medications (including both pharmaceuticals and biological products) would be considered PDURS. [See AgencyIQ’s full analysis of the 2018 framework, and industry response, here.]
• The goal of the framework, as described in a 2019 presentation from FDA staff on the subject, is to “provide prescription drug sponsors the flexibility to disseminate innovative software, while maintaining appropriate Agency oversight over the sponsors’ communications about their products.”
• The framework proposed by the FDA effectively outlined a preliminary approach that would mostly treat PDURS as part of a drug product’s labeling.
• There are technically two kinds of prescription drug labeling, and PDURS could be either. The FDA regulates both product labeling (21 CFR 201) and promotional labeling (21 CFR 202). The FDA-required labeling is the drug labeling that is submitted by the sponsor and reviewed and approved by the FDA as part of the drug’s marketing application (including a New Drug Application, Abbreviated NDA, or a Biologics License Application) – and includes prescribing information (PI). Separately, “promotional labeling” includes any type of promotional material – including advertisements, informational brochures or other disseminated copy from the drug’s manufacturer, packer or distributor. While changes to FDA-required labeling typically require a supplemental application to be approved before dissemination, promotional labeling/materials generally do not (there are some exceptions) – and promotional labeling must only be submitted to the FDA’s Office of Prescription Drug Promotion (OPDP) or Advertising and Promotional Labeling Branch (APLB) “at the time of initial dissemination” using Form 2253, “Transmittal of Advertisements and Promotional Labeling for Drugs for Human Use.”
• FDA anticipated at the time that most PDURS output would be promotional labeling, and therefore “would only be required to be submitted at the time of initial dissemination, pursuant to these existing regulations.” In effect, the agency proposed to treat the output of a PDURS similar to the way it treats an informational brochure. However, that doesn’t mean that the sponsor would be able to pull the output together and disseminate it without any input from the FDA. In addition to the pre-dissemination requirements for promotional labeling, the FDA recommended in the framework “that sponsors avail themselves of the opportunity for pre-dissemination review of such [PDURS] output through the voluntary advisory comment process for promotional materials.”
• However, the agency envisioned circumstances in which it would be considered FDA-required labeling, and therefore require review and approval (including in supplemental applications for changes). There were two key factors that would determine when a PDURS would be required labeling: First, if the PDURS provides “a clinically meaningful outcome,” with the sponsor demonstrating that to the FDA with “substantial evidence.” Second, PDURS could be required labeling when the PDURS provides a function or information “that is essential to one or more intended uses of a drug-led, drug-device combination product” in which the software is a device in the device constituent part.
• As defined, PDURS would only be software “disseminated by or on behalf of a drug sponsor,” and therefore the framework outlined in the notice “would not apply to third-party software developers who independently develop or disseminate software for use with prescription drugs.”
• In its framework, the FDA cited increased interest from both the drug industry and the end-users of these apps. According to that notice, these types of apps were already proliferating in 2018, with “many mobile applications (apps) available to consumers for a variety of health-related uses, such as tracking drug ingestion, monitoring certain medical conditions that require prescription drug medication, or providing information on how to use a drug—with more under development.” In addition, FDA explained that “drug sponsors developing or obtaining rights to market software for use with one or more of their prescription drug products have approached FDA seeking clarity regarding the regulatory status of such software” – the types of digital tools that were termed “PDURS” by the FDA at the time.
• The PDURS Framework garnered significant response from industry [see AgencyIQ’s full analysis here]. In particular, the PDURS framework applied regulatory expectations based on the developing entity. If another entity developed the software, than an entirely different regulatory framework would apply. Major pharmaceutical, biologic, and digital health associations called out this concern in their comments, raising concerns about different regulatory expectations for different entities, as well as the formal separation of the PDURS regulatory scheme from the rest of the agency’s digital health work. Several commenters also highlighted questions with the FDA’s seemingly creative interpretation of the labeling regulations that would encompass all PDURS outputs. They made the case that it appeared that FDA considers an output from a PDURS to be labeling because both “accompany” a drug, not because an output is actually labeling, and that this may go beyond the regulatory scope of labeling.
• The FDA committed to moving the PDURS policy along under the new prescription drug user fee program (PDUFA VII). Per that commitment: “By the end of FY 2023, FDA will publish draft, revised or final guidance on regulatory considerations for Prescription Drug Use-Related Software that includes information about software that is disseminated by a drug applicant for use with a prescription drug or biologic product that may be described in labeling, including prescribing information. This guidance will cover software that is distributed with a drug or integrated as part of a drug- or biologic-led combination product, as well as software that is distributed by an applicant independent of an approved product.” Interestingly, that commitment can be found in the letter’s section on commitments related to digital health technologies (DHTs), or digital products that are used to “obtain clinical trial data directly from patients,” a new category of tools that the FDA has defined only after the PDURS framework was initially released.

This week the FDA unveiled its long-awaited PDURS guidance. Here’s what you need to know:

• At a very high level, the guidance appears to recommend the following: If the PDURS gets its data from a medical device (specifically the device constituent part of a combination product), then information about it likely needs to be included in the FDA-required labeling as part of the prescribing information (PI), whether or not the sponsor has information demonstrating “clinically meaningful benefit” for the PDURS’ use (compared to use of the drug without the PDURS). However, the availability of this data is likely to impact where, exactly, the information about the PDURS output is reflected in the FDA-required labeling. Without data demonstrating clinical benefit associated with the PDURS’ use, then any information about end-user output should be considered promotional labeling, even as information about the PDURS would likely need to be reflected in the PI (e.g., HOW SUPPLIED/STORAGE AND HANDLING section) to help ensure safe use and give instructions, and potentially to “help differentiate between a combination product with and without device-connected software functions.” In general, the agency states that a PDURS that gets its information anywhere besides a medical device (e.g., patient inputting dose administration) will generally be considered promotional labeling, and likely will not be part of the FDA-required labeling. To this point, there are two notable exceptions: when the use of the PDURS is considered essential for safe use, or if the sponsor has evidence demonstrating a “clinically meaningful benefit.” The agency does say that the policy is informed by its experiencing reviewing these products, in which these types of non-device-data functions typically do not need to be incorporated into labeling.
• First up, let’s take a look at the draft guidance’s definition of PDURS: “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” – with the following addition added in the text of the guidance “regardless of whether the software is a device.” End user output, then, is defined as “Any material (content) that the prescription drug use-related software presents to the end user (a patient, caregiver, or health care practitioner).” This would be considered a type of drug labeling.
• There are two primary questions for the guidance to answer: What kind of role does PDURS play, and where does that information go?
• The use of the PDURS framework is to clarify how the end-user-facing content of a digital health tool, and specifically a PDURS, can (or must be) incorporated into labeling. As captured in the definition of the PDURS itself, the software must be “disseminated by or on behalf of a drug sponsor.” Therefore, and as the agency clarifies upfront, the guidance “does not apply to software developers (e.g., companies or individuals) who are unaffiliated with the drug sponsor even if the developer’s intention is for the software to be used with one or more drugs or combination products.” In effect, it appears that only the drug sponsor, the entity notably in control of and responsible for the drug’s labeling, would be able to subject to the regulatory expectations under the PDURS framework. Notably, the guidance specifies that it applies both to prescription drugs and “prescription drug-led, drug-device combination products” – meaning that the product for which PDURS may be included in its labeling may incorporate a digital health component that is considered a medical device.
• The way that PDURS output could be reflected in the labeling (and what type of labeling it may be included in) would be informed by the software function itself. AgencyIQ would note here that the FDA considers regulatory implications of a software product not as a whole, but on the basis of “functions,” or discreet, distinct purposes, as per the 21^st Century Cures Act definitions for software as a medical device (SaMD) regulation. This means that a specific software product can have multiple software functions, and that whether those functions are considered a medical device or not is made at the function level, not the product level. This definition is carried forward in the new PDURS framework: “A software function [per the Cures Act] is any distinct purpose of the software—in this case, prescription drug use-related software. Prescription drug use-related software can have one or more software functions.” [ Read more about how FDA defines software functions here.]
• For the purposes of the PDURS framework, the agency separates PDURS functions into two categories based on where they get their data. Per the draft guidance, “device-connected [PDURS] functions” (or device-connected software functions) are those that “rely on data directly transferred from the device constituent part of a combination product.” Separately, “all remaining” PDURS functions would be non-device-connected software functions, such as those that “rely on user-inputted data.”
• The guidance proposes that device-connected software functions could be included as prescribing information (PI) of FDA-required labeling, but the non-device-connected software functions FDA has seen so far generally do not need to be. “Typically, the PI should describe device-connected software functions and the end-user output of the device-connected software functions (e.g., in the HOW SUPPLIED/STORAGE AND HANDLING section). However, which section(s) of the PI include this information should be determined on a case-by-case basis, depending on the function and output of the software,” FDA explained. The guidance provides an example, noting that if the sponsor demonstrates as part of its study data that using the PDURS presents a “meaningful improvement in a clinical outcome” over drug use without the PDURS, this might warrant a mention in the CLINICAL STUDIES section of the PI. When a PDURS is not a device-connected software function, and instead receives data input from other sources (e.g., a patient self-reporting side effect severity and their outcomes), then this could be considered part of promotional labeling unless it is required for safe use or the drug sponsor demonstrates clinically meaningful benefit. However, the agency states that its “experience with software functions not considered to be device connected is that these software functions are more akin to an optional tool that is used with drug products (e.g., a patient diary that is an app or paper journal)” and that they “should not be described in the PI.”
• As described above, the agency expects that FDA-required labeling will need to include information about the PDURS if: (1) it gets its information from a medical device; and/or (2) if the sponsor can demonstrate “clinically meaningful benefit” from the use of the PDURS; and/or (3) the PDURS is essential for safe use of the drug product. Notably, these last two criteria could apply even if the PDURS is not a device-connected software function. The placement of PDURS information in the PI will depend on which of the criteria are met. Further, if the first criterion is met but the other two are not (i.e., the PDURS gets its information from a medical device but does not have a demonstrated benefit and/or is not essential for safe use), then information about the PDURS may need to be included in the FDA-required labeling as part of the PI, but the end-user output would be considered promotional labeling.
• A note about promotional labeling that is linked to a medical device: “When device software functions are subject to premarket review by CDRH, review of the end-user output for potential drug labeling-related issues will be part of the CDRH review in consultation with CDER or CBER. Under these circumstances, FDA would not expect separate submission of a Form FDA 2253” (see Appendix B of the guidance). In effect, if a device software function is linked to the PDURS, then promotional labeling updates do not need to be submitted to the FDA via Form FDA 2253 so long as the specific update is reviewed by CDRH. If there is an update that doesn’t require CDRH review, then the drug sponsor would need to submit Form FDA 2253. Under FDA’s guidance on when a new 510(k) is needed for a software change to an existing device, there are several updates that can be made to a software function that don’t need a device submission (e.g., strengthening cybersecurity, restoring a device to most recently cleared specifications, or making cosmetic changes); however, if that software function is linked to a PDURS and is part of the promotional labeling for a drug, then a Form FDA 2253 would be needed when a 510(k) isn’t.

Analysis:

• How does the draft guidance compare to the framework? In general, the new draft guidance aligns with the framework, although it is re-focused towards FDA-required labeling, and specifically the PI. Further, the draft guidance emphasizes the role of medical device software functions as a component of PDURS more strongly; notably, the 2018 framework specifically noted that “the focus of this proposed framework is not on whether the software is a device,” while the new draft guidance specifically cites how and whether a PDURS interacts with/is a medical device as the first criterion for determining where and how information would be included in labeling. While the original framework seemed to indicate that the FDA thought most PDURS would be considered promotional labeling,
• The draft guidance proposes that any device-linked PDURS would need to be included on FDA-required labeling, whether or not the drug sponsor demonstrates a clinically meaningful benefit of the PDURS’ use or if it is essential for safe use of the drug. In these circumstances, the agency focuses on the role of this labeling, and particularly the PI, as a way to communicate about the technology itself: “device-connected software functions are likely to require additional device features that a prescriber should be aware of when choosing the product,” the guidance explains, and goes on to make the case that the prescriber will need to be aware that the PDURS relies on data transferred from a medical device component of a combination product: “The prescriber should be made aware of this to inform the prescribing decision and so that the prescriber can also inform the patient that such information is directly transferred during their use of the product. The presence of this information in the PI also may help to differentiate between a combination product with and without device-connected software functions.”
• Compared to the 2018 framework, this does two things. First, it effectively expands what kinds of PDURS may need to have information reflected in the FDA-required labeling. Second, it seems to shore up the FDA’s original assertion, flagged as a concern by industry, that information on PDURS is appropriate for incorporation into labeling. As the agency seems to assert, the prescriber would need to know (and be able to explain to the patient) how the PDURS works to make an informed choice, and support correct use – which are core functions of the PI.
• Implications for generics and biosimilars (see footnotes 21 and 22): If an originator product is authorized (approved, licensed) with information related to PDURS on its labeling, then those labeling components would be key considerations for generic or biosimilar developers – and potentially raising concerns that adding a software component to the labeling could stymie follow-on products by adding a barrier to authorization. Specifically for generic products, the agency notes that “Labeling differences that stem from permissible differences in design between the user interface for a proposed generic product and its [reference listed drug] RLD may fall within the scope of permissible differences in labeling for a product approved under an [abbreviated new drug application] ANDA,” although the scope of these “permissible differences” is not defined in this context. Similarly, the agency simply notes that it would review potential biosimilar or interchangeable products consistent with its existing regulatory expectations for licensure. Going forward, the way that these labeling updates cause – or contribute to – product complexity is likely to be a key concern for generic and biosimilar developers.
• Comments are due December 18, 2023, and AgencyIQ expects significant input from the drug, device, digital health and information technology industries.

To contact the author of this item, please email Laura DiAngelo ( ldiangelo@agencyiq.com).To contact the editor of this item, please email Alexander Gaffney ( agaffney@agencyiq.com)

Key Documents and Dates

• • • Regulatory Considerations for Prescription Drug Use-Related Software
    • Comments due: December 18, 2023