2023 FDA Guidance - Regulatory Considerations for Prescription Drug Use-Related Software

 September 18, 2023
SHARE ON

Regulatory

Innolitics introduction 🔗

Innolitics provides US FDA regulatory consulting to startups and established medical-device companies. We’re experts with medical-device software, cybersecurity, and AI/ML. See our services and solutions pages for more details.

We have practicing software engineers on our team, so unlike many regulatory firms, we speak both “software” and “regulatory”. We can guide your team through the process of writing software validation and cybersecurity documentation and we can even accelerate the process and write much of the documentation for you (see our Fast 510(k) Solution).

About this Transcript 🔗

This document is a transcript of an official FDA (or IMDRF) guidance document. We transcribe the official PDFs into HTML so that we can share links to particular sections of the guidance when communicating internally and with our clients. We do our best to be accurate and have a thorough review process, but occasionally mistakes slip through. If you notice a typo, please email a screenshot of it to Mihajlo at mgrcic@innolitics.com so we can fix it.

Preamble 🔗

Document issued on September 18, 2023.

Draft document issued on .

For questions regarding this draft document, contact (CDER) Office of Medical Policy, CDEROMP@fda.hhs.gov, 301-796-2500 or (CBER) Office of Communication, Outreach and Development, 800-835-4709 or 240-402-8010.

Contains non-binding guidance.

I. INTRODUCTION 🔗

This guidance describes how FDA intends to apply its drug labeling authorities to certain software outputs that are disseminated by or on behalf of a drug sponsor1 for use with a prescription drug or a prescription drug-led, drug-device combination product (hereafter referred to as a “combination product”)2’3 that is assigned to the Center for Drug Evaluation and Research (CDER) or the Center for Biologics Evaluation and Research (CBER) as the lead center. This guidance expands on and was developed in response to comments submitted in response to the Federal Register notice “Prescription Drug-Use-Related Software; Establishment of a Public Docket; Request for Comments.”4

In this guidance, prescription drug-use-related software5 generally includes software that (1) is disseminated by or on behalf of a drug sponsor and (2) produces an end-user output that supplements, explains, or otherwise textually related to one or more of the sponsor’s drug products. A software function is any distinct purpose of the software, and end-user output is any material (content) that the prescription drug use-related software presents to the end user (a patient, caregiver, or health care practitioner). As discussed in this guidance, FDA considers end-user output a type of prescription drug labeling.6 Prescription drug labeling includes a variety of communications by sponsors about their drugs; FDA generally recognizes two broad categories of prescription drug labeling: (1) FDA-required labeling or (2) promotional labeling. As used in this guidance, the term FDA-required labeling includes the labeling reviewed and approved by FDA as part of a new drug application (NDA), an abbreviated new drug application (ANDA), or a biologics license application (BLA), as well as supplemental applications (21 CFR 314.50(c)(2) and 314.94(a)(8); 21 CFR 601.2(a)).7 The term promotional labeling is generally used to describe any labeling other than FDA-required labeling.

The guidance clarifies:

  • 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 (see 21 CFR 3.2(e) (defining “combination product”) and 21 CFR 4.2 (defining “constituent part”))
  • When and how sponsors should submit end-user output to FDA

This 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.

Generally, the recommendations provided in this guidance are intended to align with ongoing Agency initiatives across all product centers, including digital health initiatives at the Center for Devices and Radiological Health (CDRH).8 This guidance considers existing Agency policies for the regulation of software to ensure appropriately consistent regulation of such software and efficient, coordinated review in instances when prescription drug use-related software is reviewed by the Agency as a device. This guidance does not alter the regulatory framework for devices or the applicability of such framework to prescription drug use-related software. Rather, it 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 under the Federal Food, Drug, and Cosmetic Act (FD&C Act). Consistent 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.9

FDA anticipates that a significant proportion of prescription drug use-related software functions will be intended to provide information directly to a patient about the use of a prescription drug (e.g., helping a patient keep track of their own prescription drug use). While the end-user output of a software function is subject to FDA drug labeling authorities, some of these software functions may meet the definition of a device10 as defined in the FD&C Act and would be subject to device requirements. 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.11 Examples provided throughout this guidance should not be interpreted as determinations on whether the software would be regulated as a device or FDA’s intent to enforce applicable device requirements under the FD&C Act at this time.

In general, FDA’s guidance documents do not establish legally enforceable responsibilities. Instead, guidances describe the Agency’s current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in Agency guidances means that something is suggested or recommended, but not required.

II. BACKGROUND 🔗

FDA recognizes that the use of digital health technologies12 with prescription drugs has the potential to offer new opportunities for patient care, and the Agency is working to promote responsible, risk-based oversight of digital health. Various software functions, including those associated with mobile applications (apps), are currently available to consumers for a variety of health-related uses, such as assisting patients with tracking their own drug ingestion, allowing health care practitioners to monitor patients taking a prescription drug, or providing information on how to use a drug. 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, according to an evidence-driven, risk-based framework.

Section 201(m) of the FD&C Act defines labeling as all labels and other written, printed, or graphic matter upon any article or any of its containers or wrappers or accompanying such article. FDA generally recognizes two broad categories of prescription drug labeling: (1) FDA-required labeling and (2) promotional labeling.

For prescription drugs and prescription drug-led, drug-device combination products, FDA-required labeling is the labeling that is reviewed and approved by FDA as part of an NDA, ANDA, or BLA, as well as supplemental applications (21 CFR 314.50(c)(2) and 314.94(a)(8); 21 CFR 601.2(a)). The PI is part of the FDA-required labeling for drugs described in 21 CFR 201.56(b) and summarizes the essential scientific information needed for the safe and effective use of the drug.13 Sponsors must update their PI as needed to ensure that the labeling is accurate and is not false or misleading.14

Promotional labeling is generally any labeling other than the FDA-required labeling. Promotional labeling can include printed, audio, or visual matter descriptive of a drug that is disseminated by or on behalf of a drug’s manufacturer, packer, or distributor (21 CFR 202.1(l)(2)).15 Promotional labeling must be truthful and non-misleading, convey balanced information about a drug’s efficacy and its risks, and reveal material facts about the drug, including facts about the consequences that can result from use of the drug as suggested in a promotional piece.16

As mentioned in the Introduction, prescription drug use-related software generally includes 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 a device. When a sponsor proposes to disseminate prescription drug use-related software for use with a drug or combination product, FDA intends to 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 PI. These factors include (1) whether the prescription drug use-related software 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 prescription drug use-related software is used, and (3) whether the prescription drug use-related software relies on data directly transferred from the device constituent part of a combination product.

To help identify the labeling regulatory considerations for prescription drug use-related software, it is important to appropriately describe the software. As demonstrated by examples in Appendix A, prescription drug use-related software can be characterized using the following terminology that relates to the software’s design and intended use:

  • Software function: A software function17 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.
    • Device-connected prescription drug use-related software functions (hereafter referred to as “device-connected software functions”) rely on data directly18 transferred from the device constituent part of a combination product.
    • All remaining prescription drug use-related software functions (e.g., those functions that rely on user-inputted data) would not be considered device-connected software functions.
  • End-user output: Any material or content presented to a patient, caregiver, or health care practitioner (end user) by the prescription drug use-related software constitutes the end-user output, and such end-user output constitutes drug labeling. End-user output includes, for example, screen displays created by the software, whether static or dynamic, as well as sounds or audio messages created by the software.

When a prescription drug use-related software function receives input data 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 (regardless of whether the end-user output is FDA-required or promotional labeling).19 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.

Sponsors may propose to include information about prescription drug use-related software and its functions in the PI.20’21 One of the purposes of the PI is to allow the health care practitioner to make an informed decision about the benefits and risks of prescribing the drug. This prescribing decision could be informed by knowledge about a product’s prescription drug use-related software.

The PI must contain a summary of the essential scientific information needed for the safe and effective use of the drug product;22 for a combination product, this includes information on the drug and the device constituent part. Device-connected software functions are likely to require additional device features that a prescriber should be aware of when choosing the product. However, to date, the Agency’s 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) where patients record taking their medication on certain days of the week and might record other information, such as severity of symptoms. Functions such as these that are not directly transferring information from a device constituent part to software, including mobile apps, should not be described in the PI unless there is an additional factor (e.g., the function is necessary for safe and effective use of the drug) that warrants including this information in the PI.

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. For example, if a sponsor provided evidence from adequate and well-controlled studies that demonstrate that use of the prescription drug use-related software results in a meaningful improvement in a clinical outcome (e.g., compared to drug product use without the prescription drug use-related software), it might be appropriate to include such information in the CLINICAL STUDIES section of the PI.

FDA’s assessment of the prescription drug use-related software-related information included in the PI should be consistent with the general approach used for evaluation of PI content. 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 in this guidance. The following sections discuss the placement and extent of information describing software functions in the PI depending on the evidence submitted by the sponsor and whether the software functions are device-connected.

For prescription drug use-related software, sponsors may propose including information specifying that use of the prescription drug use-related software 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 (demonstrated by one or more adequate and wellcontrolled studies).23 For example, the evidence may demonstrate that a combination product with device-connected prescription drug use-related software (e.g., a dose-tracking app that relies on data on drug use directly transferred from a device constituent part within the product) leads to a meaningful change in a clinical outcome or validated surrogate endpoint compared to using the combination product without the device-connected prescription drug use-related software. FDA generally intends to recommend including such information in the CLINICAL STUDIES section of the PI.

If FDA determines the evidence demonstrates a clinically meaningful benefit, the end-user output associated with the software function generally would constitute FDA-required labeling, and certain post-approval changes to such output (e.g., end-user output from a mobile app specific to the software function) should be reviewed and approved by FDA as is required for other changes24 to FDA-required labeling. When a sponsor is considering developing clinical evidence to support the use of prescription drug use-related software and the sponsor would like to include this information in FDA-required labeling, the sponsor should work with the appropriate FDA review division early in the development process to discuss the types of data and information that would support inclusion of the prescription drug use-related software-related information in the PI.

In many cases, a sponsor may develop prescription drug use-related software that relies on data directly transferred from the device constituent part of a drug sponsor’s combination product without generating evidence showing that use of the prescription drug use-related software confers additional clinical benefit beyond that of the combination product alone. The following examples describe software with such device-connected software functions:

  • Software disseminated by a sponsor that allows connectivity between an inhaler and an app to provide general information about inhaler use. For example, a sponsor may develop (1) an inhaler that captures data about an inhaler event and (2) software that displays such data in a mobile app. The sponsor should propose including a brief description in the PI about the inhaler’s ability to track inhaler events with a compatible mobile app (e.g., in the HOW SUPPLIED/STORAGE AND HANDLING section).25
  • Software disseminated on behalf of a sponsor that allows connectivity between an autoinjector and a mobile app to provide information to a patient. For example, a sponsor may develop an autoinjector that captures when the autoinjector is used and transfers that information to a mobile app. The sponsor should propose including a brief description in the PI about the autoinjector’s ability to track injections with a compatible mobile app (e.g., in the HOW SUPPLIED/STORAGE AND HANDLING section).

Notably, in these examples, the prescription drug use-related software relies on data directly transferred from the device constituent part of the 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. In this situation, the PI (e.g., in the HOW SUPPLIED/STORAGE and HANDLING section) should provide a brief description of the device constituent part and the associated software function(s). 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. The end-user output would be considered promotional labeling and should not be described in the PI (e.g., from the example above regarding tracking inhaler events, the output could be the display of how frequently the inhaler is used).

The end-user output from prescription drug use-related software with no device-connected software functions generally would be considered promotional labeling and would not be described in the PI, unless the prescription drug use-related software is considered essential to the safe and effective use of a product or the drug sponsor submits evidence demonstrating that the use of prescription drug use-related software leads to a clinically meaningful benefit.26

C. Additional Considerations Relating to Review of End-User Output 🔗

End-user output and updates to end-user output from prescription drug use-related software that constitutes promotional labeling must be submitted to FDA by the applicant at the time of initial dissemination using Form FDA 2253 (Transmittal of Advertisements and Promotional Labeling for Drugs and Biologics for Human Use).27’28 Software updates that do not alter the end-user output, such as security patches, would not need to be submitted using Form FDA 2253. Furthermore, 21 CFR 202.1(j)(4) provides sponsors with a voluntary opportunity to submit promotional communications to FDA for comment before the dissemination or publication of their promotional communications.

In some cases, prescription drug use-related software can be submitted under a device marketing submission. For prescription drug use-related software that is regulated by FDA under an appropriate CDRH marketing submission, any considerations raised during CDRH’s premarket review related to representations about the drug within the prescription drug use-related software will be addressed within CDRH’s review, and CDRH will consult with CDER or CBER.29 Any subsequent postmarket revisions made to end-user output of such software that constitutes promotional labeling and does not require a CDRH marketing submission must be submitted on
Form FDA 2253 at the time of initial dissemination (see Appendix B).30 Form FDA 2253 is not a replacement for device marketing submission requirements for a device modification.31

FDA recommends that sponsors engage with the appropriate CDER or CBER review division if they are considering developing new or significantly modified device-connected software that requires a new or modified device constituent part or component of a combination product.

Example A 🔗

Example A is a mobile app intended to connect32 to and receive data directly transferred from a combination product and to analyze and display data about the patient’s use of the combination product with their health care practitioner. Specifically, Example A’s network-connected mobile app collects data (e.g., detection of tablet ingestion) from an oral tablet with an embedded sensor device system ingested by the patient, performs analysis of the ingestion data, displays the data on a screen via the mobile app, and wirelessly transfers data to a health care practitioner’s cloud-based web-application. The data showing ingestion over time are displayed on a mobile platform’s screen using the mobile app and are available for a health care practitioner’s review via access to their web-application. The end-user output relies on data that were received by the app from a sensor embedded in an oral tablet that records an ingestion event.

Example A can be characterized using the following terminology:

  • Software functions: The five distinct software functions include (1) the transfer of data from an embedded sensor device to a mobile app, (2) the analysis of ingestion data by the mobile app, (3) the transfer of data from the mobile app to a cloud-based web-application, (4) the display of ingestion data on the web-application, and (5) the display of ingestion data on the mobile app.
    • All five software functions are considered device-connected software functions because they rely on data that are directly transferred from the device constituent part of a sponsor’s combination product.
  • End-user output: The two end-user outputs are the mobile app’s display of ingestion data and the display of ingestion data on the web-application.

Example B 🔗

Example B is a mobile app intended to prompt patients to answer specific questions pertaining to their use of a prescription drug and provides a web-application for health care practitioners to review the patient’s self-reported data stored on a cloud-based application. More specifically, the Example B mobile app facilitates a patient’s ability to document in a standardized manner the incidence or severity of symptoms of their condition over time while taking their prescription drug and then transfers the self-reported information to a cloud-based application for their health care practitioner to review on a web-application.

Example B can be characterized using the following terminology:

  • Software functions: The four distinct software functions include (1) the capture of self-reported patient entry of information into the mobile app, (2) the display of symptom incidence and severity data via the mobile app display screen, (3) the transfer of self361 reported data to a cloud-based application, and (4) the display of data on the health care practitioner web-application.
    • All four software functions are not considered device-connected software functions because they do not rely on data directly transferred from the device constituent part of a sponsor’s combination product.
  • End-user output: The two end-user outputs are the mobile app’s display of symptom incidence and severity and the web-application’s display of self-reported information.

Example C 🔗

Example C is composed of a cloud-based analysis program, patient mobile app, and health care practitioner web-application. Example C is intended to be used with a combination product that includes a prescription drug and a device constituent part with a network-connected electronic interface that automatically uploads data (e.g., information about the dose of drug delivered, time of dosing) to a cloud-based analysis program. The cloud-based analysis program then processes and assesses the data to identify signals relating to the safe and effective use of the combination product and pushes notifications and alerts to the health care practitioner web-application. The patient mobile app facilitates self-reporting of symptoms relating to the use of the prescription drug, displays the information via the mobile app display screen, and transfers the self-reported data to the health care practitioner web-application independently of the data collected from the device constituent part of the combination product. The web-application aggregates the self-reported symptoms data and the data collected from the device constituent part of the combination product for the health care practitioner’s review to manage a patient’s use of a prescription drug.

Example C can be characterized using the following terminology:

  • Software functions: The nine distinct software functions include (1) the automatic transfer of data from the device constituent part to the cloud-based analysis program; (2) the cloud-based analysis of the data collected from the device constituent part of the combination product; (3) the transfer of notifications and alerts to a health care practitioner web-application; (4) the display of combination product data, notifications, and alerts on the web-application; (5) the display of the data collected from the device constituent part of the combination product via the patient mobile app screen display, (6) the collection of patient self-reported data on the mobile app; (7) the transfer of patient-self reported data to the health care practitioner web-application; (8) the display of patient-self reported data on the health care practitioner web-application; and (9) the display of the self-reported symptom data via the patient mobile app screen display.
    • Software functions (1), (2), (3), (4), and (5) are considered device-connected software functions because they rely on data that are directly transferred from the device constituent part of a sponsor’s combination product.
    • Software functions (6), (7), (8), and (9) are not considered device-connected software functions because they do not rely on data that are transferred directly from the device constituent part of a sponsor’s combination product.
  • End-user output: The four end-user outputs are the web-application’s display of data collected from the device constituent part of the combination product, notifications, and alerts; the web-application’s display of patient self-reporting data; the patient mobile app’s display of data collected from the device constituent part of the combination product; and the patient mobile app’s display of self-reported symptom data.

APPENDIX B: EXAMPLES OF DEVICE SOFTWARE FUNCTIONS THAT ARE REGULATED BY FDA UNDER AN APPROPRIATE CDRH MARKETING SUBMISSION AND WHERE THE END-USER OUTPUT IS CONSIDERED PROMOTIONAL LABELING 🔗

Example A: A manufacturer of insulin develops a mobile app intended for use with their insulin product. The software includes a dose calculator function to aid patients with mealtime insulin dose calculations. This is a device software function that is subject to the relevant device requirements, including the submission of a new premarket notification (510(k)) to CDRH. In addition to the dose calculator, the software output mentions the insulin product. This output is determined to be promotional labeling for the prescription drug.

Any considerations raised during CDRH’s premarket review related to representations about the drug will be addressed within CDRH’s review in consultation with CDER (including promotional review). The manufacturer receives clearance of the 510(k) from CDRH and disseminates the mobile app as cleared by CDRH. The manufacturer does not need to submit a Form FDA 2253 at that time.

Example B: The manufacturer of the cleared mobile app in Example 1 makes changes to the output of a device software function that is subject to the relevant device requirements, which do not affect the clinical use of the device, such as updating a logo after the device has received clearance. Referring to the guidance for industry and FDA staff Deciding When to Submit a 510(k) for a Software Change to an Existing Device (October 2017),33 the sponsor appropriately determines a 510(k) is not needed because the intended changes are not changes that could significantly affect the device’s safety or effectiveness or that constitute a major change or modification in the device’s intended use. The mobile app’s output must be submitted on Form FDA 2253 because it mentions the sponsor’s drug name (e.g., the insulin product), is drug
promotional labeling, and no 510(k) is required for these changes.34

Example C: After the device (the mobile app) has received clearance, the manufacturer of the cleared mobile app in Example 1 makes modifications to add a new function to the device: a welcome video. The welcome video includes information on the safety and effectiveness of the insulin product but does not provide information on the dose calculator. The software displaying
the welcome video function would not be an FDA-regulated device.35 In addition, the output of this software function does not impact the device that is the subject of the cleared 510(k). As such, no CDRH marketing submission is needed for the addition of this welcome video to the mobile app. However, the revised output must be submitted on Form FDA 2253 at the time of initial dissemination.36

GLOSSARY 🔗

Constituent Part: A drug, device, or biological product that is part of a combination product (21 CFR 4.2).

End-User Output: Any material (content) that the prescription drug use-related software presents to the end user (a patient, caregiver, or health care practitioner).

Prescription Drug Use-Related Software: 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.

Software Function: Any distinct purpose of the prescription drug use-related software.

Device-Connected Prescription Drug Use-Related Software Functions: Software functions that rely on data directly transferred from the device constituent part of a sponsor’s combination product.

Footnotes 🔗

  1. As defined in 21 CFR 3.2(c) and (p), a sponsor is any person who submits or plans to submit an application to the FDA for premarket review. Hereafter, in this guidance, the term sponsor refers to both sponsors and applicants. ↩

  2. In this guidance, all references to drugs or drug products include human drug products, including biological products, regulated by CDER or CBER, unless otherwise specified. ↩

  3. In this guidance, all references to combination products (21 CFR 3.2(e)) include products containing both a drug constituent part and a device constituent part. Combination products within the scope of this guidance are those with a drug primary mode of action (i.e., the drug provides the greater contribution to the intended therapeutic effects; see 21 U.S.C. 353(g)(1)(C) and 21 CFR 3.2(k) and (m)). Therefore, CDER or CBER will have primary jurisdiction for the review of these combination products and will consult with CDRH, as appropriate (see 21 U.S.C. 353(g)(1)(C), 21 CFR 3.2(k) and (m), and staff manual guide 4101 (Combination Products, Inter-Center Consult Request Process)). ↩

  4. See 83 FR 58574 (November 20, 2018), available at https://www.federalregister.gov/d/2018-25206. ↩

  5. Words and phrases in bold italics are defined in the Glossary. ↩

  6. 7 Section 201(m) of the Federal Food, Drug, and Cosmetic Act (FD&C Act) (21 U.S.C. 321(m)) defines labeling as “all labels and other written, printed, or graphic matter (1) upon any article or any of its containers or wrappers, or (2) accompanying such article.” The U.S. Supreme Court has explained that the language “accompanying such article” in the labeling definition is interpreted broadly to include materials that supplement, explain, or are otherwise textually related to the article. No physical attachment between the materials and the article is necessary; rather, “it is the textual relationship between the items that is significant” Kordel v. United States, 355 U.S. 345, 350 (1948). In evaluating whether materials “accompany” product, the Court also considered whether the drug product and the materials related to the drug product were part of an integrated distribution program (Ibid., 348). ↩

  7. See also 21 CFR 314.70 and 21 CFR 601.12. ↩

  8. The CDRH Digital Health Center of Excellence, which was established to empower stakeholders to advance health care by fostering responsible and high-quality digital health innovation, can also serve as a resource. For further information and examples of such initiatives, see https://www.fda.gov/medical-devices/digital-health-centerexcellence. ↩

  9. To see examples, see the guidance for industry and FDA staff Policy for Device Software Functions and Mobile Medical Applications (September 2013, updated September 2019 and September 2022). We update guidances periodically. For the most recent version of a guidance, check the FDA guidance web page at https://www.fda.gov/regulatory-information/search-fda-guidance-documents. See also the FDA web page Guidances with Digital Health Content at https://www.fda.gov/medical-devices/digital-health-centerexcellence/guidances-digital-health-content. ↩

  10. See section 201(h) of the FD&C Act. The term device does not include software functions excluded pursuant to section 520(o) of the FD&C Act (21 U.S.C. 360(o)). ↩

  11. Form FDA 2253 Transmittal of Advertisements and Promotional Labeling for Drugs and Biologics for Human Use. ↩

  12. In this guidance, digital health technologies are systems that use computing platforms, connectivity, software, and/or sensors for health care and related uses. ↩

  13. See 21 CFR 201.56(a)(1). ↩

  14. See, for example, sections 301(a), 301(b), and 502(a) of the FD&C Act (21 U.S.C. 331(a), 331(b), and 352(a)) and 21 CFR 201.56(a)(2). ↩

  15. Applicants, sponsors, and firms that choose to disseminate promotional communications, including promotional labeling, are subject to the postmarketing reporting requirements for submitting promotional materials to FDA (Form FDA 2253 submissions for prescription drugs and biologics). See 745A(a) of the FD&C Act (21 U.S.C.379k-1), 21 CFR 314.81(b)(3)(i), and 21 CFR 601.12(f)(4). ↩

  16. See sections 502(a) and 201(n) of the FD&C Act. ↩

  17. A function is any distinct purpose of the software, which could be the intended use or a subset of the intended use of the product, as described in the guidance for industry and FDA staff Multiple Function Device Products: Policy and Considerations (July 2020). ↩

  18. Directly refers to the electronic transfer of data. ↩

  19. 21 CFR 820.30(g). ↩

  20. If an applicant for an ANDA proposes a generic product with prescription drug use-related software
    considerations (e.g., prescription drug use-related software accompanies the proposed generic product and/or the reference listed drug (RLD)), FDA will consider, among other things, the proposed labeling. Labeling differences that stem from permissible differences in design between the user interface for a proposed generic product and its RLD may fall within the scope of permissible differences in labeling for a product approved under an ANDA. See section 505(j)(2)(A)(v) of the FD&C Act (21 U.S.C. 355(j)(2)(A)(v)) and 21 CFR 314.94(a)(8)(iv). A generic drug that is therapeutically equivalent to its RLD can be expected to have the same clinical effect and safety profile as the RLD when administered to patients under the conditions specified in the labeling. See 21 CFR 314.3(b). ↩

  21. FDA intends to evaluate a BLA proposing a biosimilar or interchangeable biological product with prescription drug use-related software considerations (e.g., prescription drug use-related software accompanies the proposed biosimilar or interchangeable biological product and/or the reference product) consistent with the requirements for licensure in section 351(k) of the Public Health Service Act (42 U.S.C. 262(k)). ↩

  22. See 21 CFR 201.56(a)(1). ↩

  23. See 21 CFR 314.126(b). ↩

  24. Applicants must notify FDA about changes to an existing NDA consistent with 21 CFR 314.70. Certain prescription drug use-related software function information may be submitted in an annual report if the information is consistent with 21 CFR 314.70(d)(2). ↩

  25. Ibid. ↩

  26. See 21 CFR 201.56(a)(1) and (2) ↩

  27. Under FDA’s regulations implementing postmarketing reporting requirements, applicants must submit specimens of mailing pieces and any other labeling or advertising devised for promotion of the drug product at the time of initial dissemination of the labeling and at the time of initial publication of the advertisement for a prescription drug product (21 CFR 314.81(b)(3)(i) and 21 CFR 601.12(f)(4)). ↩

  28. See the guidance for industry Providing Regulatory Submissions in Electronic and Non-Electronic Format — Promotional Labeling and Advertising Materials for Human Prescription Drugs (April 2022). ↩

  29. Please note that some changes to device software functions regulated by FDA under an appropriate CDRH marketing submission could require a marketing submission to CDRH. For example, changes that include new clinical claims or are inconsistent with the approved drug label affect the safety or effectiveness of the device (in the case of approved devices) (see 21 CFR 814.39(a)) or could significantly affect the safety or effectiveness of the device (in the case of cleared devices) (see 21 CFR 807.81(a)(3)), would require a marketing submission to CDRH. ↩

  30. See footnote 28 ↩

  31. See 21 CFR 814.39(a) or 21 CFR 807.81(a)(3). ↩

  32. In this instance, the term connect describes a wireless connection; however, a connection can be wired or wireless. ↩

  33. We update guidances periodically. For the most recent version of a guidance, check the FDA guidance web page at https://www.fda.gov/regulatory-information/search-fda-guidance-documents. ↩

  34. Under FDA’s regulations implementing postmarketing reporting requirements, applicants must submit specimens of mailing pieces and any other labeling or advertising devised for promotion of the drug product at the time of initial dissemination of the labeling and at the time of initial publication of the advertisement for a prescription drug product (21 CFR 314.81(b)(3)(i) and 21 CFR 601.12(f)(4)). ↩

  35. The manufacturer should also assess the impact of the new non-device software function on the safety and effectiveness of the device functions. See the guidance for industry and FDA staff Multiple Function Device Products: Policy and Considerations (July 2020). Although this analysis might lead to submission of an additional 510(k) for the device function, the new non-device software function would not itself be subject to review. ↩

  36. See footnote 35. ↩

SHARE ON
×

Get To Market Faster

Medtech Insider Insights

Our Medtech tips will help you get safe and effective Medtech software on the market faster. We cover regulatory process, AI/ML, software, cybersecurity, interoperability and more.