U.S. FDA: labeling guidance for sponsors incorporating prescription drug use-related software

Background

Back in 2018, the U.S. Food and Drug Administration published a proposed framework for regulating output of digital health tools accompanying prescription drugs as labeling. As we reported at the time, FDA introduced the term “prescription drug-use-related software”, defined as software disseminated by or on behalf of a drug sponsor that accompanies one or more of the sponsor’s prescription drugs (including biologics).

The more recent PDS Guidance drops one hyphen, and now defines prescription drug use-related software (PDS) 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. End-user output 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), and FDA considers end-user output to be a type of prescription drug labeling, which can either be FDA-required labeling (reviewed by FDA as part of a marketing application or promotional labeling (any other labeling). The draft guidance also provides clarity regarding:

• How FDA intends to apply its drug labeling authorities to end-user output of prescription drug use-related software;
• How the FDA-required labeling, in particular the Prescribing Information (PI), should describe prescription drug use-related software that:
  • is determined to be essential for the safe and effective use of the drug product, or
  • relies on data directly transferred from the device constituent part of a combination product; and
• When and how sponsors should submit end-user output to FDA.

Alignment with CDRH

As opportunities for increased use of digital health technologies with prescription drugs have grown exponentially in the intervening years, so too have the Agency’s digital health initiatives at the Center for Devices and Radiological Health (CDRH). 

The PDS Guidance is intended to align with ongoing initiatives around digital health, and, consistent with FDA policies, focuses on the software functions that are devices and whose functionality could pose a risk to a patient’s safety if the device were not to function as intended. The PDS Guidance does not alter the regulatory framework for medical devices or the applicability of this framework to prescription drug use-related software. Rather, the PDS Guidance focuses on the application of drug labeling authorities to the end-user output of prescription drug use-related software, regardless of whether such software is regulated as a device and should be viewed as a guidance that augments existing guidance on the treatment of software functions regulated by CDRH. Further, the agency makes clear that addressing the labeling requirements for the drug product with respect to software outputs does not supplant any requirements that may exist for the regulation of software functions. Accordingly, to the extent that sponsors of drug products or combination products disseminate digital health technologies for use with one or more of their drugs, FDA intends to implement its policies and exercise its authorities, including drug labeling authorities and device approval authorities, according to an evidence-driven, risk-based framework. 

Labeling considerations: FDA-required or promotional?

When a sponsor proposes to disseminate PDS for use with a drug or combination product, FDA will analyze several factors to determine whether the 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 Prescribing Information (PI). These factors include:

1. whether the PDS 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 when the PDS is used, and
3. whether the PDS relies on data directly transferred from the device constituent part of a combination product.

Importantly, the software must be appropriately described according to its design and intended use. For example, prescription drug use-related software can have one or more software functions, each of which is a distinct purpose of the software. A software function can be device-connected, meaning it relies on data directly transferred from the device constituent part of a combination product. In contrast, a software function relying on user-inputted data is not considered a device-connected software function. 

As noted above, FDA considers any material (content) that the PDS presents to the end user (a patient, caregiver, or health care practitioner) to be end-user output. This may include, for example, screen displays created by the software, as well as sounds or audio messages created by the software.

In the context of data received from the device constituent part of a combination product (i.e., device-connected software function), FDA intends to assess whether the combination product used with the software can accurately and reliably provide the data, perform analyses, and display the end-user output. Sponsors should provide information to support how the combination product used with the software will not lead to medication errors, such as inappropriate administration of extra doses.

Describing PDS in the PI

Because a product’s PDS could inform prescribing decisions, sponsors may propose to include information about prescription drug use-related software and its functions in the PI.

A combination product PI includes information on the drug and the device constituent parts. Therefore, device-connected software functions are likely to require additional device features about which prescribers should be aware. On the other hand, software functions not considered to be device-connected are more akin to an optional tool, such as a patient diary that is an app or a journal. Functions such as these should not be described in the PI, unless there is an additional factor that warrants including this information, such as where the function is necessary for safe and effective use of the drug.

In addition, consideration of which section(s) of the PI should include information related to device-connected software functions and the end-user output of device-connected software functions, should be determined on a case-by-case basis. For example, appropriate evidence that use of the PDS results in a meaningful improvement in a clinical outcome may be appropriately indicated in the CLINICAL STUDIES section of the PI. However, some software functions may be better suited for the HOW SUPPLIED/STORAGE AND HANDLING section. FDA intends to base decisions about the placement and extent of such information in the PI on the data provided by the sponsor, the labeling requirements, and the principles outlined of the PDS Guidance.

Sponsor submits evidence of “clinically meaningful benefit” of data

Sponsors may propose including information specifying that use of the PDS with the product results in a meaningful improvement in a clinical outcome as compared to use of the product without the prescription drug use-related software, such as where use of the software leads to a meaningful change in clinical outcome or validated surrogate endpoint.

If FDA determines the evidence demonstrates a clinically meaningful benefit, the associated end-user output would generally constitute FDA-required labeling. Sponsors considering developing clinical evidence to support these uses should work with FDA early in the development process to discuss the types of data and information that would support inclusion of the PDS-related information in the PI.

Sponsor does not submit evidence of “clinically meaningful benefit” of data

The Agency also contemplates circumstances where software relies on data directly transferred from the device constituent part of a sponsor’s combination product that does not generate evidence showing that use of the PDS confers additional clinical benefit beyond that of the combination product alone. For example, software may allow connectivity between an inhaler and an app, or between an autoinjector and an app. The sponsor should propose including an appropriate description of these interactions, e.g., in the HOW SUPPLIED/STORAGE AND HANDLING section of the PI.

In each of these scenarios, the PDS relies on data directly transferred from the device constituent part of the combination product, and the prescriber should be made aware of this to inform the prescribing decision and the patient. However, information beyond describing the device constituent part and associated software function(s) or statements suggesting a clinical benefit should not be included in the PI, and any end-user output would generally be considered promotional labeling.

Additional considerations

End-user output and updates to end-user output from PDS that constitutes promotional labeling must be submitted using Form FDA 2253. Where the prescription drug use-related software’s functions  trigger the need for a device marketing submission, such a submission should be obtained and satisfaction of the PDS labeling requirements alone will not be sufficient. If PDS is regulated by FDA under a CDRH submission, any premarket considerations raised by CDRH will be addressed by CDRH, in consultation with CDER or CBER. Subsequent postmarket revisions to end-user output that constitute promotional labeling (and which do not require a CDRH marketing submission) must be submitted on Form FDA 2253 and comply with other promotional labeling rules.

Finally, FDA recommends that sponsors engage the appropriate CDER or CBER review division if device-connected software will require a new or modified device constituent part or component of a combination product.

Next steps

Stakeholders should consider the PDS Guidance and would benefit from analyzing their specific software function and resultant end-user output compared to the Examples provided by the Agency. Sponsors should work with FDA early in their development processes to understand whether, or to what extent, disseminated software might require modifications to the product labeling.

FDA is accepting comments on the draft guidance through December 18 under docket number FDA-2023-D-2482. If you have questions on the proposed framework, PI labeling more generally, or wish to submit a comment, please contact the authors of this alert or the Hogan Lovells attorney with whom you generally work.

Authored by Meredith Manning, Randy Prebula, and Jodi Scott.