FDA Issues Guidance on Prescription Drug Use-Related Software

The U.S. Food & Drug Administration (FDA) recently issued final guidance — Regulatory Considerations for Prescription Drug Use-Related Software (PDURS) — to address when and how software disseminated by (or on behalf of) sponsors fits into existing drug-labeling requirements. The agency describes this as a response to longstanding uncertainty and a push toward a clearer, more consistent approach across FDA’s drug and device centers. 

FDA’s core move is definitional. PDURS generally means software that is disseminated by or on behalf of a drug sponsor and produces end-user output that “supplements, explains, or is otherwise textually related” to one or more of the sponsor’s products. FDA explicitly treats that end-user output as a type of prescription drug labeling which then splits into FDA-required vs. promotional labeling.  

Two scope boundaries matter in practice: 

According to FDA, if the output is not specific to the sponsor’s drug (e.g., purely disease-state content), it would generally fall outside PDURS scope. However, device authorities might still apply. If the software is not disseminated by or on behalf of the sponsor, it is outside the guidance’s scope even if the developer expects it will be used with a drug. Dissemination by or on behalf of a drug sponsor could include situations where a drug company or a software developer working under an agreement with the drug company distributes or directs end users to the software.  

Why FDA Treats PDURS Output as Labeling (And Why Sponsors Should Care) 

FDA anchors the PDURS framework in the statutory and case-law concept of labeling as materials “accompanying” a product — where textual relationship and an integrated distribution program can be enough, even without physical attachment. FDA’s practical point is that if sponsor-linked software produces end-user content that supplements, explains, or is otherwise textually related to a sponsor’s prescription drug(s), the compliance analysis should start from: this is labeling — and then determine which labeling bucket it falls into (i.e., FDA-required vs. promotional).  

Sponsors should treat PDURS as a labeling governance issue, not just as a “digital” issue. If content is labeling, then promotional review, substantiation standards, submission mechanics, and lifecycle controls can all attach — sometimes in ways software teams do not expect.  

FDA generally defines PDURS as software that is disseminated by or on behalf of a drug sponsor. It also produces 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 also regulated as a device. The following scope points can materially change a sponsor’s obligations: 

• • “By” or “on behalf of” can include third parties. FDA notes this can include situations where a sponsor or a software developer working under agreement with the sponsor distributes the software or directs users to it.  
  • End-user output includes more than screens. FDA explicitly includes static/dynamic screen displays and sounds or audio messages created by the software.  

The final guidance indicates that software output that is focused only on a disease or condition, rather than on the sponsor’s drugs, generally falls outside of PDURS. However, FDA encourages sponsors to consider whether medical device requirements still apply.  

Sponsors should start with a detailed inventory, rather than just a list of apps. For each software tool, identify: 

• • What each function does. 
  • How users access it, including through sponsor-controlled or partner channels. 
  • What users see or hear, including notifications and audio. 
  • Whether the output relates to specific drugs or only to a disease or condition 

FDA-Required Labeling vs. Promotional Labeling 

FDA generally recognizes two broad categories of prescription-drug labeling: FDA-required labeling and promotional labeling. The agency applies that same split to PDURS end-user output. The final guidance explains that sponsors can submit evidence showing use of PDURS results in a meaningful improvement in a clinical outcome compared to use of the drug without PDURS — supported by one or more adequate and well-controlled studies. FDA notes such studies can incorporate real-world data, as appropriate, to generate real-world evidence for effectiveness claims.  

If FDA determines there is evidence of meaningful clinical-outcome improvement, FDA states that the related end-user output generally would constitute FDA-required labeling, and certain post-approval changes to that output should be reviewed and approved consistent with other FDA-required labeling changes.  

Where a sponsor does not submit evidence of meaningful clinical-outcome improvement (and where the software is not essential to safe and effective use), FDA indicates end-user output will generally be treated as promotional labeling with the related implications for submission and review.  

This is an early strategy decision with downstream operational impact. If a sponsor intends to argue PDURS drives meaningful outcomes (or is essential to safe/effective use), the program should be designed with evidence planning, labeling placement, and change-control discipline in mind from the start. Success can move output into FDA-required labeling with tighter post-approval constraints.  

What Belongs in the Prescribing Information  

The final guidance states that sponsors can propose including information about PDURS functions in the prescribing information (PI). However, it emphasizes that, in general, standalone software functions should not be described in the PI unless there is an additional factor warranting inclusion (e.g., the function is necessary for safe/effective use, or the sponsor provides sufficient evidence for FDA to determine the function leads to meaningful improvement in a clinical outcome).  

FDA’s final guidance also includes an Appendix A decision tree that organizes the core labeling determinations and explicitly notes that it addresses drug-labeling recommendations only, and that other requirements (including device-related requirements) may apply. 

FDA indicates that the PI should typically describe device-connected software functions on a case-by-case basis. FDA gives examples like inhalers or autoinjectors that transfer use/dose information to an app. In these examples, the PI includes a brief description of the device/app connectivity while the end-user output itself is treated as promotional labeling.   

If PDURS is not considered necessary for safe and effective use, the PI should state that the software is not needed for that purpose. FDA provides illustrative language in Appendix B.  

Standalone PDURS functions may be described in the PI (e.g., clinical studies) if they are essential to safe and effective use or if there are adequate and well-controlled studies that show meaningful clinical-outcome improvement. Conversely, where FDA determines the standalone function is not necessary for safe/effective use, and no meaningful outcome improvement evidence is submitted, end-user output generally would be considered promotional labeling and would not be described in the PI. 

PI drafting should avoid unintended messaging, such as inadvertently implying a tool is required when FDA views it as optional. It should also ensure the PI description aligns with the actual software behavior, the evidence package, and how teams intend to message the tool externally.  

Submissions and Lifecycle Management 

The final guidance states that end-user output (and updates to end-user output) that constitutes promotional labeling must be submitted to FDA at the time of initial dissemination using Form FDA 2253. The form includes a “PDURS” material type for submissions. FDA also acknowledges that some updates (e.g., certain security patches or operating system changes) may not change the content of previously submitted end-user output. In that case, sponsors are not required to resubmit the previously submitted output. 

FDA further emphasizes that Form 2253 is not a replacement for a device marketing submission (e.g., modifications to an authorized device). It recommends engaging with the appropriate CDER/CBER review division when considering new or significantly modified device-connected software functions.  

The guidance implicitly pushes sponsors toward an internal PDURS operating model that looks a lot like “promo ops” and “software release ops” combined, including: 

• • Versioning and audit trails for end-user output. 
  • Rules for what counts as a content change vs. technical-only change. 
  • A submission-ready way to capture app screens, notifications, and audio scripts tied to specific releases. 
  • Escalation paths when a software change could introduce new clinical claims or misalign with the approved label. 

PDURS Can Raise Device-Quality and Medication-Error Expectations  

The final guidance underscores that PDURS may meet the definition of a medical device and may be subject to device requirements. For device-connected software functions, FDA intends to assess whether the combination product and PDURS accurately and reliably provide data, perform analyses (if applicable), and display end-user output. This is regardless of whether that output is FDA-required or promotional labeling. Sponsors should provide information indicating that the function is not expected to result in medication errors (e.g., inaccurate dosing data that leads to inappropriate extra doses or missed doses). Programs that connect to device constituent parts should assume FDA will expect a coherent story across labeling, technical performance/reliability, and medication-error risk. Even where the end-user output is ultimately promotional labeling submitted on Form 2253, the underlying function may still pull in device-style documentation and change-control expectations.  

Classifying PDURS output as labeling carries real enforcement consequences. Under section 502(a) of the FD&C Act, labeling that is false or misleading constitutes misbranding. Promotional output must be truthful and non-misleading and should convey balanced information about the drug’s efficacy and risks. Output that fails this standard, including unauthorized efficacy or safety claims, can expose sponsors to both misbranding liability and OPDP enforcement action. 

Next Steps for Sponsors 

Sponsors should consider the following six steps:  

1. 1. Build a PDURS inventory (functions, outputs, dissemination pathways, and whether content is drug-specific).  
   2. Run FDA’s decision tree (Appendix A) across each function/output and document your rationale for whether output is likely FDA-required or promotional.  
   3. Make an evidence decision early: Are you trying to demonstrate meaningful clinical-outcome improvement (and accept the labeling and post-approval implications), or keep output promotional?  
   4. Align PI language with your strategy, especially for device-connected functions (HOW SUPPLIED/STORAGE AND HANDLING) and any recommended “not necessary for safe and effective use” statement, where applicable.  
   5. Operationalize Form 2253 submissions and define resubmission triggers for software changes, including a process for separating content changes from technical-only updates.  
   6. Identify where device submissions may also be required and ensure change-control pathways account for both drug-labeling and device-regulatory expectations.  

Crowell & Moring’s Health Care, Life Sciences and Digital Health teams support companies navigating FDA oversight, privacy/security, liability risk, and commercialization for digital products and connected technologies. Please reach out with any questions or for assistance with implementing this guidance.