FDA Issues Prescription Drug Use-Related Software Guidance after a Several-Year Delay

The U.S. Food and Drug Administration (FDA) has finalized its guidance, Regulatory Considerations for Prescription Drug Use-Related Software (PDURS), clarifying how the agency applies its drug labeling authorities to software disseminated by or on behalf of prescription drug sponsors.¹ Growth in digital health technology used by and on behalf of drug developers (e.g., mobile applications like digital diaries and similar tools) has necessitated regulatory creativity, as neither the FDA drug paradigm nor the device one clearly applies to these kinds of software and its outputs. FDA published draft guidance in September 2023, and the agency now has finalized that guidance.

Scope of the Guidance

Defining PDURS. As it did in the draft guidance, the final guidance defines prescription drug use-related software, or 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 regardless of whether the software is regulated as a device.”² Also as in the draft guidance, the final guidance focuses on regulation of the end-user output — i.e., material that the software presents to an end user, such as screen displays and even sounds and messages, whether that person is a patient, caregiver, or health care practitioner. FDA will consider any such end-user outputs to be prescription drug labeling, which can be required labeling (i.e., the labeling reviewed and approved by FDA as part of an NDA or BLA) or promotional labeling (generally any labeling other than required labeling).³

“By or on Behalf of” a Drug Sponsor. The final guidance clarifies that dissemination “by or on behalf of” a sponsor may include a drug company or a software developer working under an agreement with the company distributing software or directing users to it. As such, sponsors should consider the guidance when structuring arrangements with third-party developers, including arrangements under which the sponsor directs patients or health care practitioners to software.⁴ On the other hand, outputs from software that is not specific to the sponsor’s prescription drug products, such as entirely disease-focused output, generally falls outside the PDURS framework. Such software may nevertheless be subject to FDA’s device authorities, which the guidance excludes from the scope and instead refers readers to FDA’s various software-related guidance documents.⁵

PDURS’ Relationship to Software as a Medical Device. FDA appears to be broadening its focus on PDURS: the final guidance deletes the draft’s statement that, “[c]onsistent with FDA’s policies for the regulation of device software functions, at this time, FDA intends to focus its device regulatory oversight on only those 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 final guidance thus no longer affirmatively commits the PDURS framework to CDRH’s risk-based focus. Instead, the final guidance states only that it “does not alter the statutory or regulatory framework for devices,” that its examples should not be read as a position on whether a function is a device or on FDA’s “intent to enforce applicable device requirements,” and, in a footnote, points readers to CDRH’s digital health web pages to determine whether a function “may be the focus of FDA’s device regulatory oversight.”⁷ In other words, the guidance is clear that whether or not software is considered PDURS is a separate inquiry from whether or not the software is regulated as a medical device and that FDA will be scrutinizing the output of both device and non-device software as PDURS. Sponsors that have relied on a software function’s low-risk character, or its status as a non-device or enforcement-discretion function, should no longer assume that status insulates the output from drug labeling review.

Inclusion of PDURS in Drug Prescribing Information

As the draft guidance did, the final guidance distinguishes between describing a software function in prescribing information and treating the function’s actual output as FDA-required labeling. The final guidance also adds contours to how FDA intends to include describe software functions in prescription drug prescribing information, i.e., as “required labeling.” It provides direction on treatment of standalone and device-connected software, treatment of software-related statements in prescription drug prescribing information (the USPI), and evidence necessary to support inclusion. 

First, the final guidance delineates differences between device-connected and standalone software functions. Device-connected functions rely on data from a device or the device constituent part of a combination product; standalone functions encompass the remaining functions, including those relying on user-entered data.⁸ These terms describe connectivity and data sources, but as mentioned, they do not alone determine whether the software is regulated as a device. Software that relies on data transferred from a device constituent part, i.e., device-connected software, typically will be included in the HOW SUPPLIED and STORAGE and HANDLING sections of a drug’s USPI. Standalone software functions will not be described in a drug’s USPI unless either (1) the software is essential to safe and effective use or (2) FDA determines that there is a meaningful improvement in a clinical outcome as a result of the software use.

Second, the final guidance discusses the data necessary for inclusion of PDURS as required labeling. Software that is essential to safe and effective use of the drug as demonstrated by sponsor data — whether device-connected or standalone — typically will be included in the CLINICAL STUDIES section of the label when adequate and well-controlled studies demonstrate that using the drug with the software produces a meaningful improvement in a clinical outcome compared with using the drug without the software. The final guidance also recognizes that such studies may incorporate real-world data, as appropriate.⁹ An added example illustrates this approach for a standalone diabetes app that provides dose reminders, tracks health information, and delivers behavioral coaching.¹⁰ The example describes a randomized trial comparing the drug used with a software application with use of the drug without the application. FDA explains that if the evidence demonstrates a clinically meaningful improvement, the associated software output would be treated as FDA-required labeling. The guidance emphasizes that sponsors pursuing this approach should engage with FDA early concerning study design, endpoints, and the proposed labeling.

The body of the guidance states that PDURS placement in the USPI will is determined “on a case-by-case basis” and that, where software is necessary for safe and effective use, “where and how the software is addressed in the PI will be determined during FDA’s review.”¹¹ However, the more specific text, as well as the decision tree in Appendix A, appears to contemplate three specific PDURS-related labeling scenarios: (1) software described in the CLINICAL STUDIES section; (2) software described in the HOW SUPPLIED/STORAGE AND HANDLING sections; or (3) software not described in the USPI at all. Neither the guidance text nor the decision tree routes software to the INDICATIONS AND USAGE, DOSAGE AND ADMINISTRATION, or DOSAGE FORMS AND STRENGTHS sections, and the guidance offers no example of software that affects these considerations, such as software that determines whether, or in what dose, a patient should receive the drug, even though it acknowledges possible PDURS uses such as “providing individualized dosing recommendations” and “predicting treatment response.”¹² Sponsors developing eligibility-, selection-, or dosing-type software should seek early FDA input on where, if at all, the function will be reflected in the prescribing information.

Finally, optional device-connected software may warrant a brief description in the HOW SUPPLIED/STORAGE AND HANDLING section even when the sponsor has not demonstrated a meaningful improvement in a clinical outcome. In that situation, however, the output generally remains promotional labeling.¹³ FDA also adds a recommendation that, when software is not necessary for safe and effective use of the drug, the prescribing information should state that limitation where the software function and device constituent part are described. This recommendation applies regardless of whether the sponsor has submitted evidence demonstrating a meaningful improvement in a clinical outcome. A new appendix supplies illustrative autoinjector labeling reflecting this approach.¹⁴

For drug sponsors developing or partnering on digital health tools (referred to now simply as software), the guidance thus presents opportunities to describe clinically supported software in FDA-approved labeling, though inclusion of software functions in the prescribing information will be appropriate only where the drug sponsor has demonstrated a meaningful improvement in a clinical outcome (including improvement in a validated surrogate endpoint) and/or the software is connected to a device — and even then will be relegated to later sections of the USPI and generally will not appear in the INDICATIONS or DOSAGE AND ADMINISTRATION sections. In addition, without evidence of clinically meaningful impact, claims about the benefits of using a drug use-related app not connected to any device will not be included in FDA-approved labeling. 

PDURS Outputs as Promotional Labeling

Unless the software is essential to safe and effective use or has been shown to produce a meaningful improvement in a clinical outcome, the end-user PDURS output “generally would constitute promotional labeling” according to the final guidance.¹⁵ This is the case whether or not the PDURS is “device connected.”

Thus, the final guidance takes the position that promotional labeling process and requirements apply to PDURS output. With respect to Form FDA 2253 submissions, the guidance maintains the default obligation of submission at the time of initial dissemination, not preclearance, using the electronic format described in FDA’s April 2022 promotional submissions guidance. The guidance also expressly reminds sponsors of the opportunity to submit promotional communications for voluntary advisory comment before dissemination, which it suggests may be worthwhile for novel or interactive output. Because the guidance also removes PDURS output from the scope of the 2014 interactive promotional media draft guidance, sponsors lack a ready template; they should document how submitted screenshots, scripts, content libraries, or representative output sets capture the range of output users will see, and consider raising the approach with OPDP or APLB. The guidance also discusses promotional-material submission requirements for accelerated-approval products, and states that PDURS promotional output falls outside the scope of FDA’s 2014 draft guidance addressing postmarketing submissions of interactive promotional media.¹⁶

The final guidance takes as different position from the draft’s discussion of overlapping device and drug promotional-labeling review. The draft guidance expressly stated that the Center for Drug Evaluation and Research (CDER) would not expect a separate Form FDA 2253 submission if the Center for Devices and Radiological Health (CDRH) had reviewed software output in consultation with CDER or Center for Biologics Evaluation and Research (CBER). The draft guidance also limited subsequent Form FDA 2253 submissions to promotional-output changes that did not require a CDRH marketing submission.¹⁷ However, the final guidance removes those statements and instead explains that post-market revisions to related PDURS output (i.e., constituting promotional labeling) also must be submitted on Form FDA 2253 at initial dissemination, without the draft’s qualification concerning whether a device submission is also required.¹⁸ Sponsors may wish to revisit submission procedures that rely on device review as a substitute for promotional-labeling submissions and consider obtaining agency feedback where the applicable processes overlap.

First Amendment Implications of PDURS As Drug Labeling

Interestingly, FDA concurrently published a nonbinding memorandum justifying its treatment of PDURS as promotional labeling from a First Amendment perspective, seemingly acknowledging that its extension of the “labeling” definition to software outputs is far from clearcut. The memorandum reasons that, under Kordel v. United States, 335 U.S. 345 (1948), and United States v. Urbuteit, 335 U.S. 355 (1948), output that “supplements, explains, or is otherwise textually related” to a sponsor’s drug is part of an “integrated transaction” and thus labeling.¹⁹ It then argues that FDA’s extension of the broad “labeling” concept to PDURS is appropriate under the First Amendment because (1) misleading speech and speech concerning unlawful activity are unprotected; (2) using speech as evidence of intended use raises no First Amendment concern; (3) premarket review regulates conduct, not speech; and (4) in any event, the approach satisfies Central Hudson.²⁰

The memorandum is curious because it does not directly acknowledge that FDA’s treatment of PDURS output as promotional labeling actually restricts speech by preventing drug sponsors from including information about software in their FDA-approved USPIs other than the specific sections mentioned above. But the very existence of the memo reflects FDA’s recognition that its position raises serious questions under the First Amendment. Yet its answers to those questions are flawed in a number of critical respects.

First, FDA does not appear to recognize that software output is itself speech. The Supreme Court has held that “the creation and dissemination of information are speech,” and that content- and speaker-based burdens on pharmaceutical marketing trigger heightened scrutiny.²¹ Under the appropriate heightened scrutiny framework, then, a regulatory construct that applies only to drug sponsors and that FDA describes as reaching output “even if seemingly unrelated to the drug” — such as sleep-tracking data displayed with an anxiety drug — is potentially an overbroad, speaker-based, speech restriction.

Second, much of the authority on which FDA relies involved products that could not lawfully be sold at all, such as unapproved drugs or devices.²² PDURS, on the other hand, definitionally accompanies approved drugs. And truthful, non-misleading information about the lawful use of an approved product is protected commercial speech.²³ FDA pays short shrift to Caronia, but that case supports the proposition that FDA could not, in fact, use PDURS outputs, standing alone, as evidence of a new intended use for the relevant drug.

Even accepting the memorandum’s reliance on the Central Hudson framework, FDA’s argument rests on general literature about off-label prescribing and detailing, and on hypothetical examples (such as antifungal app output implying a mood benefit), rather than any actual evidence of harm from PDURS output that will be alleviated to a material degree by regulation of PDURS as promotional labeling. And it fails to distinguish the modest burden of submission at first dissemination from the far heavier burdens of prior approval and open-ended risk of misbranding liability.

Managing Software Updates

The final guidance retains the principle that software updates that do not change previously submitted outputs do not require resubmission of that output on Form FDA 2253. Examples include certain security patches and operating system changes. FDA states that its review of output will focus on issues affecting safe and effective drug use, including promotional-labeling considerations, and leaves open the possibility of further guidance on updates.²⁴ Thus, before a modification goes into effect, sponsors should assess whether the output has changed such that a new Form FDA 2253 is required.

This applies regardless of whether the software is regulated as a device by FDA. Although not mentioned in the guidance, sponsors may want to consider this when seeking a pre-determined change control plan of an FDA-regulated PDURS device. Along these lines, sponsors should establish processes that distinguish changes to software functionality from changes to end-user content and assess the applicable drug labeling and device submission requirements. 

Interaction With Other FDA Software Initiatives

FDA states that the PDURS recommendations are intended to align with ongoing agency initiatives across product centers, including CDRH’s digital health initiatives, and points sponsors to the CDRH Digital Health Center of Excellence as a resource.²⁵ Because the guidance does not alter the device regulatory framework, sponsors whose software functions may meet the device definition will need to apply CDRH’s existing digital health policies, including its Multiple Function Device Products guidance, alongside the drug labeling principles in the PDURS guidance.²⁶

The guidance also ties PDURS change management to CDRH’s guidances on PMA supplements and on deciding when to submit a 510(k) for a software change, emphasizing that Form FDA 2253 is not a replacement for a required device submission. On the evidence side, FDA’s statement that adequate and well-controlled studies may incorporate real-world data to generate real-world evidence connects PDURS labeling claims to the agency’s broader use of real-world evidence in drug development. Taken together, sponsors should coordinate drug labeling, device, and clinical development strategies for software rather than evaluating each pathway in isolation.

*           *           *

FDA has not explained the timing of the final guidance, which comes roughly three years after the September 2023 draft and nearly eight years after the agency first opened a public docket on prescription drug use-related software in November 2018. We expect several factors contributed, based in part on FDA’s press release announcing the guidance’s availability. First, the final guidance’s more developed treatment of standalone software, including a new example of an app supported by a randomized trial, suggests that FDA needed time to work through how clinical-benefit claims for software not connected to a device fit within its labeling framework for pharmaceutical products. Second, the final guidance’s express emphasis on alignment with CDRH’s digital health initiatives, and its revisions to the draft’s approach to overlapping device and promotional-labeling review, suggest that coordination took a while between CDER, CBER, CDRH, and the Office of Combination Products. Third, as most noted in the press release, the steady growth of sponsor-developed apps and connected combination products has likely increased pressure on the agency to provide sponsors with firmer expectations, particularly regarding Form FDA 2253 submissions for software output which may likewise be connected to FDA’s increased enforcement of direct to consumer promotional materials.

If you have any questions or would like more information, please reach out to one of the authors of this Advisory or your existing Arnold & Porter contacts.

© Arnold & Porter Kaye Scholer LLP 2026 All Rights Reserved. This Advisory is intended to be a general summary of the law and does not constitute legal advice. You should consult with counsel to determine applicable legal requirements in a specific fact situation.