2018-25206. Prescription Drug-Use-Related Software; Establishment of a Public Docket; Request for Comments

AGENCY:

Food and Drug Administration, HHS.

ACTION:

Notice; establishment of a public docket; request for comments.

SUMMARY:

The Food and Drug Administration (FDA or the Agency) is announcing the establishment of a docket to solicit public comment on a proposed framework for regulating software applications disseminated by or on behalf of drug sponsors for use with one or more of their prescription drug products. Recognizing the opportunities for increased use of digital technology with prescription drugs, the Agency is proposing a framework that would provide prescription drug sponsors the flexibility to develop and disseminate innovative software, while maintaining appropriate Agency oversight over the sponsors' communications about their products. The framework proposed in this notice focuses not on prescription drug-use-related software itself, but rather on the output of such software that is presented to the end user. For purposes of the notice, prescription drug-use-related software refers to software disseminated by or on behalf of a drug sponsor that accompanies one or more of the sponsor's prescription drugs (including biological drug products). Software that is developed for use with prescription drugs but is not disseminated by or on behalf of a drug sponsor is not addressed in this proposal. The proposed framework is being issued for discussion purposes only and is not a draft guidance. This document is not intended to communicate FDA's proposed (or final) regulatory expectations but is instead meant to seek early input from groups and individuals outside the Agency prior to development of a draft guidance.

DATES:

Submit either electronic or written comments by January 22, 2019.

ADDRESSES:

You may submit comments as follows. Please note that late, untimely filed comments will not be considered. Electronic comments must be submitted on or before January 22, 2019. The https://www.regulations.gov electronic filing system will accept comments until 11:59 p.m. Eastern Time at the end of January 22, 2019. Comments received by mail/hand delivery/courier (for written/paper submissions) will be considered timely if they are postmarked or the delivery service acceptance receipt is on or before that date.

Electronic Submissions

Submit electronic comments in the following way:

• Federal eRulemaking Portal: https://www.regulations.gov. Follow the instructions for submitting comments. Comments submitted electronically, including attachments, to https://www.regulations.gov will be posted to the docket unchanged. Because your comment will be made public, you are solely responsible for ensuring that your comment does not include any confidential information that you or a third party may not wish to be posted, such as medical information, your or anyone else's Social Security number, or confidential business information, such as a manufacturing process. Please note that if you include your name, contact information, or other information that identifies you in the body of your comments, that information will be posted on https://www.regulations.gov.
• If you want to submit a comment with confidential information that you do not wish to be made available to the public, submit the comment as a written/paper submission and in the manner detailed (see “Written/Paper Submissions” and “Instructions”).

Written/Paper Submissions

Submit written/paper submissions as follows:

• Mail/Hand delivery/Courier (for written/paper submissions): Dockets Management Staff (HFA-305), Food and Drug Administration, 5630 Fishers Lane, Rm. 1061, Rockville, MD 20852.
• For written/paper comments submitted to the Dockets Management Staff, FDA will post your comment, as well as any attachments, except for information submitted, marked and identified, as confidential, if submitted as detailed in “Instructions.”

Instructions: All submissions received must include the Docket No. FDA-2018-N-3017 for “Prescription Drug-Use-Related Software; Establishment of a Public Docket; Request for Comments.” Received comments, those filed in a timely manner (see ADDRESSES), will be placed in the docket and, except for those submitted as “Confidential Submissions,” publicly viewable at https://www.regulations.gov or at the Dockets Management Staff between 9 a.m. and 4 p.m., Monday through Friday.

• Confidential Submissions—To submit a comment with confidential information that you do not wish to be made publicly available, submit your comments only as a written/paper submission. You should submit two copies total. One copy will include the information you claim to be confidential with a heading or cover note that states “THIS DOCUMENT CONTAINS CONFIDENTIAL INFORMATION.” The Agency will review this copy, including the claimed confidential information, in its consideration of comments. The second copy, which will have the claimed confidential information redacted/blacked out, will be available for public viewing and posted on https://www.regulations.gov. Submit both copies to the Dockets Management Staff. If you do not wish your name and contact information to be made publicly available, you can provide this information on the cover sheet and not in the body of your comments and you must identify this information as “confidential.” Any information marked as “confidential” will not be disclosed except in accordance with 21 CFR 10.20 and other applicable disclosure law. For more information about FDA's posting of comments to public dockets, see 80 FR 56469, September 18, 2015, or access the information at: https://www.gpo.gov/​fdsys/​pkg/​FR-2015-09-18/​pdf/​2015-23389.pdf.

Docket: For access to the docket to read background documents or the electronic and written/paper comments received, go to https://www.regulations.gov and insert the docket number, found in brackets in the heading of this document, into the “Search” box and follow the prompts and/or go to the Dockets Management Staff, 5630 Fishers Lane, Rm. 1061, Rockville, MD 20852.

FOR FURTHER INFORMATION CONTACT:

Chris Wheeler, Center for Drug Evaluation and Research, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 51, Rm. 3330, Silver Spring, MD 20993, 301-796-0151, [e-mail].

SUPPLEMENTARY INFORMATION:

I. Background

FDA recognizes that digital health has the potential to offer new opportunities to improve patient care, and is working to promote responsible development in digital health.^[1] There are currently 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. 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, referred to herein as prescription drug-use-related software. In considering digital health and its application to the use of prescription drugs, the Agency is evaluating how FDA authorities apply when such software is disseminated by or on behalf of a drug sponsor for use with one or more of that sponsor's prescription drugs.^[2]

The proposed framework described in this notice is intended to align with ongoing Agency initiatives and foster innovation while ensuring sponsors' communications are consistent with applicable prescription drug labeling requirements. For purposes of this notice, “prescription drug-use-related software” refers to software disseminated by or on behalf of a drug sponsor that accompanies one or more of the sponsor's prescription drugs, including biological drug products. The material presented to the end user of the prescription drug-use-related software (including a patient, caregiver, or healthcare professional) constitutes the output. This includes, for example, screen displays created by the software, whether static or dynamic, as well as sounds or audio messages. For purposes of this notice, FDA is focused on the output of prescription drug-use-related software. Because, as used in this notice, “prescription drug-use-related software” refers to software disseminated by or on behalf of a drug sponsor, this proposed framework would not apply to third-party software developers who independently develop or disseminate software for use with prescription drugs.

The proposed framework is designed to take a risk-based approach to prescription drug-use-related software. Under this approach, it is anticipated that in most cases, the output of such software will not require review by FDA prior to dissemination. This proposed framework is being issued for discussion purposes only and is not a draft guidance. This document is not intended to communicate FDA's proposed (or final) regulatory expectations but is instead meant to seek early input from groups and individuals outside the Agency (21 CFR 10.115(g)(1)). FDA expects to issue a draft guidance after considering the comments submitted in response to this notice that will convey FDA's proposed approach and recommendations regarding prescription drug use related software and output.

Software used in digital health products may have distinct functions. Whether software is a device is determined by Center for Devices and Radiological Health (CDRH) and may depend upon the software's functions.^[3] The focus of this proposed framework is not on whether the software is a device. While FDA anticipates that some prescription drug-use-related software will meet the definition of a device, other prescription drug-use-related software will not meet this definition. This proposed framework does not alter the regulatory framework for devices, but focuses on the output of software disseminated by or on behalf of a drug sponsor for use with one or more of its prescription drug(s).

Regardless of whether a software function meets the definition of a device, or is a device that falls within an FDA enforcement discretion policy related to software as a device,^[4] under this proposed framework, only the output of the software disseminated by or on behalf of a drug sponsor for use with one or more of the drug sponsor's prescription drugs would be treated as drug labeling.

A. Drug Labeling

Under the proposed framework, prescription drug-use-related software output would be regulated as labeling because it “accompanies” a specific drug. Software output that does not accompany a specific drug would not be regulated as labeling unless its categorization changes, such as if a drug sponsor licenses software originally disseminated by an independent third party and then disseminates the software for use in conjunction with the sponsor's drug.

Section 201(m) (21 U.S.C. 321(m)) of the Federal Food, Drug, and Cosmetic Act (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. 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 or explain an 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 a product, Kordel also considered whether the drug product and the materials relating to the drug product had a “common origin and common destination” and whether they were part of an integrated distribution program (Id. at 348).

FDA generally recognizes two broad categories of labeling for drugs: (1) FDA-required labeling and (2) promotional labeling. For prescription drugs and biological products, FDA-required labeling is the labeling, drafted by the manufacturer, that is 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), including supplemental applications (21 CFR 314.50(c)(2), 314.94(a)(8), and 601.2(a)). It includes the information that is essential for a provider to make an informed decision about the risks and benefits of prescribing the drug for a patient and the information needed to safely and effectively use the drug. Most changes to such drug labeling require review and approval by FDA.

In contrast, promotional labeling is generally any labeling other than FDA-required labeling that is devised for promotion of the product. Promotional labeling may have other functions in addition to promotion. 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)).

Promotional labeling is not approved by FDA in advance of dissemination. Rather, applicants must submit to FDA's Office of Prescription Drug Promotion (OPDP) or Advertising and Promotional Labeling Branch (APLB), as appropriate, “labeling or advertising devised for promotion” of a drug product at the time of initial dissemination or publication of such promotional labeling or advertisement (21 CFR 314.81(b)(3)(i) and 601.12(f))). FDA anticipates that under this proposed framework, most forms of prescription drug-use-related software output would be considered promotional labeling and thus would only be required to be submitted at the time of initial dissemination pursuant to these existing regulations. The submission of promotional materials to OPDP or APLB at time of initial dissemination by drug sponsors is a longstanding requirement applicable to all communications that are considered promotional labeling, regardless of the content of those communications or the medium used for distribution. Therefore, such prescription drug-use-related software output would be subject to the same regulations as other promotional materials disseminated by or on behalf of the drug sponsor, such as patient brochures and detail pieces.

Last year, drug sponsors submitted over 100,000 promotional pieces to OPDP at the time of initial dissemination. FDA employs a risk-based approach to review these materials. For the vast majority of sponsors, there are no further interactions with FDA about a piece after it is submitted. Sponsors can also avail themselves of the voluntary advisory comment process and receive FDA comments before disseminating a proposed promotional labeling piece.^[5] As discussed herein, for certain prescription drug use-related software output, the Agency will recommend under the proposed framework that a sponsor use the voluntary advisory comment process prior to dissemination.

B. Software as a Medical Device

Following enactment of the 21st Century Cures Act (Pub. L. 114-146), which amended the FD&C Act by excluding certain software functions from the statutory device definition in newly added section 520(o) (21 U.S.C. 360j(o)), FDA continues to develop its digital health device policies.^[6] For example, FDA has issued draft guidance to explain its proposed interpretation of section 520(o)(1)(E) of the FD&C Act, which excludes certain clinical decision support software functions from the device definition in section 201(h) of the FD&C Act.^[7] Clinical decision support software is intended for use by healthcare providers. In that guidance, FDA also proposes to adopt an enforcement discretion policy for applicable device requirements for certain patient decision support software functions intended for patients and caregivers who are not healthcare professionals.^[8]

The proposed framework for prescription drug-use-related software outlined in this notice, if adopted, would not impact FDA's regulation of a stand-alone software function that does not accompany a prescription drug (e.g., a software function that uses complex algorithms to analyze a skin lesion to determine whether it contains cancerous cells or blood establishment computer software and accessories used in the manufacture of blood and blood components). If, however, software that is a device is disseminated by or on behalf of a sponsor of a prescription drug for use with that drug, it may be subject to regulation under drug, biologic, and device authorities, as appropriate. For example, when prescription drug-use-related software meets the definition of a device because of its function, it would be subject to regulation as a device and its output may also constitute drug labeling. Additionally, such prescription drug-use-related software would constitute a combination product if use of the software and drug together meet the definition of combination product under 21 CFR 3.2(e) (§ 3.2(e)). The proposed framework takes into consideration existing Agency policy for the regulation of software to ensure efficient, coordinated review in instances when prescription drug-use-related software is reviewed by the Agency as a device. As noted above, this proposed framework does not apply to software developed by 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 prescription drugs. This proposed framework only applies to the output of such software when the software is disseminated by or on behalf of a drug sponsor specifically for use with one or more of the sponsor's prescription drugs.

II. FDA's Proposed Framework for Prescription Drug-Use-Related Software Output

This section outlines FDA's proposed framework for oversight of prescription drug-use-related software output, including distinguishing when information about the output may be included in FDA-required labeling and when the output would be considered promotional labeling, as well as the Agency's expectations for submissions of each type of labeling. FDA is establishing this docket to solicit input from stakeholders on this proposed framework, as well as on the list of specific questions in section III. FDA solicits comment on all aspects of the proposed framework described in this notice, including the examples used to illustrate the proposal.

A. Prescription Drug-Use-Related Software Output as Labeling for a Prescription Drug

Prescription drug-use-related software may be developed by or on behalf of a sponsor for use with the sponsor's prescription drug or drugs, or could be software widely available from a third party that a sponsor adapts for use with the sponsor's prescription drug or drugs. Although software with similar properties may be available from other sources, it is only when a sponsor disseminates such software for use with its prescription drug or drugs that the sponsor would be subject to this proposed framework. For example, if software to measure physical activity is branded with the name of a drug indicated to alleviate pain from osteoarthritis and is disseminated by or on behalf of the drug sponsor to patients to allow them to record their degree of physical functioning while taking the drug, the software output may be considered prescription drug use-related software and be regulated as drug labeling, even if its functionality does not meet the definition of a device. Other examples of software that could be prescription drug-use-related software, if disseminated by or on behalf of a prescription drug sponsor, might include the following:

• Software branded with a drug name that a sponsor intends for patients to use to record and track their use of the sponsor's drug with a mobile application (app). Such an app may allow a patient to share these data with a caregiver or healthcare provider.
• Software that is designed by a drug sponsor for its specific drug and enables a healthcare provider to enter dosing instructions for a sponsor's prescription drug product for a patient that the patient can retrieve through this software. For example, an interactive app that could be programmed by the provider to give the patient information on how to adjust the insulin doses for a specific type of insulin based on blood glucose levels (i.e., an electronic sliding scale).
• Software designed by a drug sponsor to communicate with a device in a drug-led, drug-device combination product. For example, an app that communicates with a device that is embedded in an oral tablet of a specific drug to automatically record when the tablet has been ingested by the patient.

As stated above, the material presented to the end user of the prescription drug-use-related software (including a patient, caregiver, or healthcare professional) constitutes the output. This includes, for example, screen displays created by the software, whether static or dynamic, as well as sounds or audio messages. Examples of prescription drug-use-related software output might include the following:

• For software that a sponsor disseminates to patients to record and track their prescription drug use with an app, the prescription drug-use-related software output would include the screen display where patients can enter a record of their ingestion of the drug and see the records of their ingestion over time.
• For software that a sponsor disseminates to patients taking its drug to record not only when they took the drug but also activity levels or symptoms related to their disease, the prescription drug-use-related software output would include the screen display where patients can enter their symptoms or view a summary of their activity or symptoms (e.g., a graphic representation of steps per day). If the software receives input directly from a separate device (e.g., a step counter or blood pressure monitor), the prescription drug-use-related software output would also include the display of such information (e.g., step count or blood pressure measurements).
• For software that a sponsor disseminates to healthcare providers to enter dosing instructions for a sponsor'[s drug that can be viewed through an app, the prescription drug-use-related software output would include the screen display of dosing instructions that the patient can retrieve through the app.
• For software that is branded with a cholesterol-lowering drug name and provides a risk calculator to assist healthcare providers in deciding when to prescribe that medication and how to calculate the appropriate dose, the prescription drug-use-related software output would include the screen display of the risk calculator. While such an app would likely not be a device, the communication by the sponsor of information about its drug would make the software's output drug labeling under this proposed framework.
• For software a sponsor disseminates to patients to communicate information from an embedded device that tracks drug ingestion to an app, the prescription drug-use-related software output would include screen displays that show the information on drug ingestion. In addition, if the app provides alerts (e.g., a dose is registered as ingested) or reminders (e.g., it reminds the patient to take their medication), these messages would also be considered prescription drug-use-related software output. If the alert or reminder includes sounds, vibrations, or an audio message, these would also be considered prescription drug-use-related software output.

Under the proposed framework, the output of prescription drug-use-related software constitutes drug labeling because it accompanies a drug, for example by explaining how to use the drug (e.g., by reminding patients when it is time for them to take the drug), or by supplementing the use of the drug (e.g., by enabling a physician to provide dosing modification instructions to a patient). Prescription drug-use-related software output also shares a common origin and destination with the drug with which the software is to be used—it is disseminated by or on behalf of a drug sponsor to the ultimate end user—and the drug and software are part of an integrated distribution program.

As discussed below, information about prescription drug-use-related software output may be included in FDA-required labeling or constitute promotional labeling, depending on how the output is used with the sponsor's prescription drug.

B. Information About Prescription Drug-Use-Related Software Output That May Be Included in FDA-Required Labeling

FDA expects that, generally, information about prescription drug-use-related software output may be included in FDA-required labeling in two situations: (1) Where the drug sponsor demonstrates to FDA that there is substantial evidence of an effect on a clinically meaningful outcome as a result of the use of the prescription drug-use-related software or (2) where the prescription drug-use-related software provides a function or information that is essential to one or more intended uses of a drug-led, drug-device combination product of which such software is a device constituent part or an element of a device constituent part.

In the first situation, where a sponsor demonstrates through substantial evidence (from one or more adequate and well-controlled investigations, as necessary) that the use of software with a drug results in a clinically meaningful improvement compared to using the drug alone, and the sponsor chooses to submit such evidence as part of a drug application, information about the prescription drug-use-related software output would be included in FDA-required labeling (e.g., prescribing information, medication guide, or instructions for use). In this scenario, evidence might consist of a demonstration of improvement in a clinical outcome or a validated surrogate endpoint that predicts a change in a clinical outcome. For example, evidence might be developed that shows that use of prescription drug-use-related software with a drug improves patient compliance and thus improves blood levels of the validated endpoint ^[9] hemoglobin A1c (HbA1c) compared to drug use alone. Reductions in HbA1c directly reflect improvement in glycemic control. Therefore, if there is substantial evidence that the use of a dose-tracking or reminder app with an antidiabetic drug results in a reduction in HbA1c compared to taking the drug without using the app, such evidence would be sufficient to support a labeling claim and the prescription drug-use-related software and its output would be described in the FDA-required drug labeling, if the sponsor chooses to submit such evidence as part of a drug application.^[10]

When a sponsor develops clinical evidence from adequate and well-controlled investigations regarding the use of prescription drug-use-related software with a previously approved drug and the sponsor would like to include this information in FDA-required labeling, under this proposed framework, we would expect the sponsor to submit the information to the Agency as a new original application for review. The sponsor should work with the appropriate review division within FDA in developing the submission.

Under the second situation described above, the prescription drug-use-related software is software that is part of a system comprising a device constituent part or is itself a device constituent part of a prescription drug-led, drug-device combination product, and such software provides a function or information that is essential to one or more intended uses of that drug-led, drug-device combination product. In that case, if such software meets the device definition, the software would be considered part of the device that is a constituent part of the combination product and would be regulated as such.^[11] For example, CDRH has cleared an ingestible event marker (IEM) designed to communicate a time-stamped confirmation of IEM device ingestion via volume conduction communication, also known as intrabody communication, with an external patch (https://www.accessdata.fda.gov/​cdrh_​docs/​reviews/​K113070.pdf). Software can be used to interact with the external patch to organize and display the information about ingestion for a patient, provider, or both. CDER recently approved Abilify MyCite, which is a drug-led, drug-device combination product comprised of aripiprazole tablets embedded with this IEM. The IEM is intended to track drug ingestion, and patients can opt to share these data with their healthcare providers. The software program that communicates with the patch, which gathers the information from the IEM, is essential to allow the patient (or, at the patient's election, the healthcare provider) to review the data collected by the IEM about ingestion. In this example, information about that function of the software was included in the FDA-required drug labeling because that function is essential for the combination product to achieve one of its intended uses—tracking ingestion of the drug.

In both cases, the software that will be used with the prescription drug will be developed prior to the marketing of the drug or combination product with the software. During the software development phase, the software could be regulated as a device, but under the proposed framework, FDA-required drug labeling regulations (which apply to the sponsor of the drug or combination product) would not apply until the drug or combination product was approved for distribution and disseminated by or on behalf of the drug sponsor.

C. Prescription Drug-Use-Related Software Output That Constitutes Promotional Labeling

Under this proposed framework, when information about prescription drug-use-related software output is not included in FDA-required labeling, the output would be considered promotional labeling for the sponsor's prescription drug when the software is disseminated by or on behalf of the drug's sponsor. Under FDA's postmarket reporting regulations, drug sponsors must submit to FDA “labeling or advertising devised for promotion” of a drug at the time of initial dissemination or publication of such promotional labeling or advertisement (§ 314.81(b)(3)(i)). Prescription drug-use-related software output that is not included in FDA-required labeling is devised, at least in part, to promote use of a sponsor's prescription drug. For example, such output would likely display the name of the drug and may be marketed as part of an integrated system to encourage use of the drug over a competing product. While prescription drug-use-related software output that promotes a prescription drug may also serve additional purposes, such as providing electronic reminders or other information about the prescription drug or the disease it is intended to treat, it is nonetheless devised, at least in part, to promote the use of the sponsor's prescription drug.

Under this proposed framework, prescription drug-use-related software output that constitutes promotional labeling would be submitted to FDA by drug sponsors at the time of initial dissemination using Form FDA 2253 (“Transmittal of Advertisements and Promotional Labeling for Drugs for Human Use”), in the same way that drug sponsors currently submit their other promotional materials. Each submission of prescription drug-use-related software output would include screenshots or other appropriate representations of what the user will experience, and must be accompanied by a completed Form FDA 2253 and a copy of the drug's current professional labeling (§§ 314.81(b)(3)(i) and 601.12(f)(4)).^[12] Updates should be submitted to FDA at the time of initial dissemination only when an update to such software results in changes to the output experienced by the user. Software updates, such as security patches and other software updates that do not alter the output, would not need to be resubmitted. This approach will provide drug sponsors the flexibility to innovate and to disseminate prescription drug-use-related software without prior FDA approval.

In some cases, there may be uncertainty regarding whether the output of prescription drug-use-related software is consistent with FDA-required labeling. In order to help evaluate whether a sponsor's communication is consistent with FDA-required labeling, FDA recently published a guidance entitled “Medical Product Communications That Are Consistent With the FDA-Required Labeling—Questions and Answers.” ^[13] That guidance explains that, in evaluating whether a product communication is consistent with the FDA-required labeling for that product, among other factors, FDA will evaluate whether product communications “increase the potential for harm to health relative to the information reflected in the FDA-required labeling.”

FDA anticipates that, in general, most uses of prescription drug-use-related software output would not lead to an increase in the potential for harm to health for the user. For example, an app that a sponsor makes available that allows patients to track signs and symptoms or reminds patients to take an upcoming dose, but does not instruct them to alter their dose or intake of a drug, would not be expected to increase risks associated with use of the drug provided it functions as intended. FDA believes use of such prescription drug-use-related software output poses a comparable risk to other promotional labeling currently in use that are intended to help patients take their drugs as prescribed (e.g., drug branded pill boxes, paper calendars, patient diaries). FDA recognizes, however, that the user interface is also an important component and expects sponsors to consider how the design of the user interface could affect the use of the prescription drug-use-related software output with their drugs. Similarly, prescription drug-use-related software output directed to healthcare providers is generally not expected to pose additional risk (e.g., an app made available by a sponsor that gives healthcare providers information on when dosing adjustments consistent with the labeling for that sponsor's drug might be warranted based on clinical data) because of the healthcare providers' training and expertise in properly evaluating treatment options.

The following are examples of prescription drug-use-related software output that, under the proposed framework, drug sponsors would only be required to submit at time of initial dissemination to CDER pursuant to § 314.81(b)(3)(i) or to CBER pursuant to § 601.12(f): ^[14]

• Prescription drug-use-related software output that reminds providers of interventions or tests, consistent with the FDA-required labeling, needed before prescribing a drug product. For example, an app that reminds providers to obtain a blood test before prescribing or renewing a drug prescription as recommended in the FDA-required labeling.
• Prescription drug-use-related software output that provides patients with information about their prescribed drug that is also found in the FDA-required labeling directed to patients (i.e., instructions for use or patient labeling or both).
• Prescription drug-use-related software output that provides patients with simple tools to track their health information related to the condition for which they were prescribed the drug. For example, an app that allows a patient to record the incidence or severity of symptoms of their condition.
• Prescription drug-use-related software output that allows prescribers to provide dosing instructions to a patient that are consistent with the FDA-required labeling (e.g., increase short-acting insulin based on pre-meal glucose level).
• Prescription drug-use-related software output that allows a patient to enter a regimen for a drug and then reminds the patient to take a dose if the patient fails to record taking a dose at the scheduled time of administration.
• Prescription drug-use-related software output that allows a healthcare provider to program a patient-adjusted weight-based dosing schedule for an immunosuppressant medication and then reminds patients to take their doses at the correct time.

However, FDA anticipates that it is possible that certain prescription drug-use-related software output may increase the potential for harm to health where it provides recommendations that may direct patients to make decisions about their drug or disease that would normally be made in consultation with a healthcare provider. In certain cases, such software might be considered a device if it provides recommendations to patients to prevent, diagnose, or treat a disease or condition.^[15] If such software is a device and subsequently is disseminated by or on behalf of a drug sponsor to be used with its prescription drug, the output would be submitted at the time of dissemination and the appropriate centers (e.g., CDER or CBER, and CDRH) would coordinate review (See section II.E below). Software that is not a device may still make recommendations to patients on how to manage their disease; for example, when it is necessary to contact a healthcare provider. If that software is subsequently disseminated by or on behalf of a drug sponsor to be used with its prescription drug, then under the proposed framework, FDA would recommend that sponsors avail themselves of the opportunity for pre-dissemination review of such prescription drug-use-related software output through the voluntary advisory comment process for promotional materials. This would enable sponsors to obtain the benefit of FDA's thinking about whether the proposed prescription drug-use-related software output is consistent with the FDA-required labeling, including whether the output increases the potential for harm to health and whether it is truthful and non-misleading. In evaluating whether the prescription drug-use-related software output is consistent with FDA-required labeling, FDA would evaluate the output using the factors outlined in the guidance entitled “Medical Product Communications That Are Consistent With the FDA-Required Labeling—Questions and Answers.”

The following are categories of prescription drug-use-related software output that, under the proposed framework, FDA would recommend be submitted to the Agency by the drug sponsor in advance of dissemination, using the existing voluntary process for requesting advisory comment, because the use of the prescription drug-use-related software output may increase the potential for harm to health of patients compared to the use of the drug without such output (in which case the prescription drug-use-related software output would not be consistent with the FDA-required labeling):

• Prescription drug-use-related software output that instructs patients on when to adjust their dose based on symptoms without first consulting a healthcare provider. For example, an app that allows patients to calculate an insulin dose based on blood glucose levels based on published treatment guidelines and recommends an insulin dose different than that prescribed by the patients' physician could pose a risk to the patient.
• Prescription drug-use-related software output that provides recommendations on when a patient should contact a healthcare provider based on symptom-related information. Use of such software may or may not increase the potential for harm to the health, relative to the use of the drug without the software, depending on the context and content of the recommendation. For example, if the FDA-required labeling states that patients should contact a healthcare provider if they experience a rash and when the patient enters the word “rash” into the app, the app recommends contacting their provider, this output would be consistent with the labeling and its use would not increase the potential for harm to health relative to the information contained in the FDA-required labeling. However, where an app processes symptom-related information and provides recommendations on when the patient should or should not contact a healthcare provider, the use of such recommendations could increase potential for harm to health by making implicit recommendations on when it is not necessary to seek medical attention. For example, prescription drug-use-related software that communicates with a scale in a patient's home to allow the tracking of weight in patients with heart failure and uses the information to generate output with a recommendation of when to contact a healthcare provider is implicitly making a recommendation that it is not necessary to contact the provider if weight gain has not reached a certain threshold. The potential for harm to health stems from the use of any recommendation, explicit or implicit, that the patient's signs and symptoms, as entered into the app, do not require attention from a healthcare provider.

FDA's proposed approach applies existing regulations and policies in a risk-based manner that fosters innovation and use of digital technologies with prescription drugs, and leverages FDA's existing mechanisms, such as postmarketing reporting requirements, to provide oversight that is commensurate with other communications by sponsors about their prescription drugs.

It is also important to recognize that whether prescription drug-use-related software output is consistent with the FDA-required labeling may be dependent upon reliability of the underlying software to produce its output as intended. Unlike other types of promotional labeling, such as patient brochures and booklets, prescription drug-use-related software output could change if, for example, the software does not function as intended. Therefore, under this proposed framework, it would be expected that prescription drug-use-related software output submitted by a drug sponsor to the Agency, including prescription drug-use-related software output that is considered promotional labeling, would be reliably produced by the software. It is the responsibility of the drug sponsor to ensure the reliability of the prescription drug-use-related software it disseminates; FDA's labeling oversight described in this proposed framework focuses only on the output, not the software.

Under this proposed framework, FDA would ask that drug sponsors who voluntarily submit their prescription drug-use-related software output (e.g., screenshots) to OPDP or APLB before initial dissemination under the voluntary advisory comment process review the guidance entitled, “Providing Regulatory Submissions in Electronic and Non-Electronic Format—Promotional Labeling and Advertising Materials for Human Prescription Drugs.” ^[16] This guidance provides standard recommendations regarding content, format, and references for sponsors to consider when voluntarily requesting comments on promotional labeling materials. FDA does not expect sponsors to submit materials pertaining to software coding or programming.

D. Output of Prescription Drug-Use-Related Software That Contains Multiple Functions

As noted above in section II (Background), prescription drug-use-related software may contain multiple functions, some of which may be considered a device. Those functions that meet the device definition may be regulated as device constituent parts of a combination product, or as elements of a system comprising a device constituent part of a combination product, if use of the functions together with the prescription drug meets the definition of combination product under § 3.2(e). Also as discussed above, information about prescription drug-use-related software output may be included in FDA-required labeling for a combination product of which the prescription drug-use-related software is a device constituent part or element thereof, if such software provides a function or information that is essential to one or more intended uses of that drug-led, drug-device combination product. If the output of a function is not essential to an indication for the combination product, that output would be considered promotional labeling.

For example, some prescription drug-led, drug-device combination products may have prescription drug-use-related software that includes within a single app a function that is required for use of the combination product and functions that are not required for use of the product. For example, one software function may track drug ingestion through communication with data from an IEM, whereas other software functions may allow the patient to record symptoms like pain or fatigue, which are not required to achieve the intended effect of the combination product and may not be considered a device constituent of a drug-led, drug-device combination product. In such situations, FDA may require a drug sponsor to provide users of prescription drug-use-related software with adequate disclosure(s) within the prescription drug-use-related software output (and, if appropriate, in FDA-required labeling) that certain functions have not been evaluated by FDA.

Another example of prescription drug-use-related software that may contain multiple functions is where clinical studies are done to show an effect on a clinical endpoint. For example, if the use of a dose-tracking app with an antidiabetic medication led to an improvement in serum HbA1c, and information about that prescription drug-use-related software output is included in FDA-required labeling, the sponsor might add additional software functions, such as an electronic carbohydrate counter. If there are no clinical studies to show the electronic carbohydrate counter software function improves HbA1c, the prescription drug-use-related software output from this function would be treated as promotional labeling under this proposed framework.

E. Output of Prescription-Drug-Use-Related Software That Has Been Cleared or Approved by CDRH

If prescription drug-use-related software is cleared or approved by CDRH as a device and is not a constituent of an approved prescription drug-device combination product, drug sponsors would only need to submit the prescription drug-use-related software output to CDER or CBER (as appropriate) at the time of first dissemination. Because such software was reviewed by CDRH, and CDRH would have consulted with CDER or CBER during the premarket review, FDA would not expect that the use of such software would result in an increased potential for harm to patients. Therefore, FDA would not recommend that a drug sponsor submit the prescription drug-use-related software output for voluntary advisory comment prior to first use, but would still expect such output to be promotional labeling and must submit on Form FDA 2253 at the time of first use.

III. Additional Issues for Consideration

FDA is soliciting public input from a broad group of stakeholders regarding this proposed framework for prescription drug-use-related software and the output of such software. In addition to general comments, FDA is interested in responses to the following questions:

1. FDA is seeking to foster innovation in the use of digital technology with prescription drugs while maintaining a consistent approach to communications by sponsors about their drugs. Does the proposed approach to prescription drug-use-related software adequately foster innovation by drug sponsors?

2. What alternative regulatory approaches could the Agency consider?

3. What should FDA take into consideration with respect to applying prescription drug labeling requirements in this context (e.g., the requirement that labeling bear adequate directions for use)? Does the proposed approach adequately preserve FDA's ability to ensure that existing prescription drug labeling requirements are met?

4. In a situation where the output of prescription drug-use-related software includes a benefit claim about the drug, what should FDA consider when providing recommendations on how to appropriately address the balancing of benefit information and risk information?

5. Does the proposed framework appropriately characterize the types of prescription drug-use-related software output that should be submitted for advisory comment? (See Section II.C., Prescription Drug-Use-Related Software Output That Constitutes Promotional Labeling) Are there other examples for which advisory comment should be recommended because there is a strong potential that the prescription drug-use-related software output will increase the potential for harm to health if used with a drug?

6. Does the proposed framework appropriately identify the materials and information that should be submitted by drug sponsors as part of a voluntary request for comment under § 202.1(j)(4)? Are there other materials or information FDA should consider in its evaluation of whether prescription drug-use-related software output submitted by drug sponsors is consistent with FDA-required labeling and is truthful and not misleading (e.g., human factors study results)?

7. Regarding software functions, FDA's proposed expectation is that sponsors are responsible for ensuring that prescription drug-use-related software reliably produces its output as intended. Is this approach sufficient to ensure patient safety?

8. FDA recognizes that software will have frequent updates, many of which will not alter prescription drug-use-related software functionality. FDA proposes that for prescription drug-use-software output that is considered promotional, if changes in the software do not alter the output experienced by the user, FDA would not need to be notified of those changes. Does this approach strike an appropriate balance between allowing for software innovation while providing adequate oversight of sponsor communications about their prescription drugs?

9. What can be done to ensure that the end user has access to the prescription drug-use-related software that is appropriate to the specific drug dispensed at the pharmacy (e.g., in cases of generic substitution)?

10. What issues should the Agency consider as it develops this proposed framework in order to facilitate timely generic competition for prescription drugs that are approved with prescription drug-use-related software output included in the FDA-required labeling?

Dated: November 14, 2018.

Leslie Kux,

Associate Commissioner for Policy.

Footnotes

1.  For more information on medical devices and digital health, see the FDA Medical Devices Digital Health web page available at: https://www.fda.gov/​MedicalDevices/​DigitalHealth/​default.htm.

2.  For the purposes of this notice, all references to drugs or drug products include human drug products, including biological products, regulated by the Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research (CBER), unless otherwise specified.

3.  The term “software function” is a distinct purpose of the product, which could be the intended use or a subset of the intended use of the product. For example, a software product with an intended use to analyze data has one function: analysis. A product with an intended use to store, transfer, and analyze data has three functions: (1) Storage, (2) transfer, and (3) analysis. A software function may be its visual output (e.g., the software function is intended to graphically display blood pressure values) or a software function may not have a visual output (e.g., the software function is intended to transfer blood pressure values from one device to another).

4.  See “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act: Draft Guidance for Industry and Food and Drug Administration Staff,” available at: https://www.fda.gov/​downloads/​MedicalDevices/​DeviceRegulationandGuidance/​GuidanceDocuments/​UCM587820.pdf and “Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff,” available at: https://www.fda.gov/​downloads/​MedicalDevices/​DeviceRegulationandGuidance/​GuidanceDocuments/​UCM587819.pdf.

5.  See 21 CFR 202.1(j)(4). For drug products being considered for accelerated approval, unless otherwise informed by the Agency, applicants must submit to the Agency for consideration during the preapproval review period copies of all promotional materials, including promotional labeling as well as advertisements, intended for dissemination or publication within 120 days following marketing approval. After 120 days following marketing approval, unless otherwise informed by the Agency, the applicant must submit promotional materials at least 30 days prior to the intended time of initial dissemination of the labeling or initial publication of the advertisement (21 CFR 314.550; 21 CFR 601.45).

6.  FDA has issued several software-related draft guidances in this effort. These guidance documents can be found at Guidances with Digital Health Content, https://www.fda.gov/​MedicalDevices/​DigitalHealth/​ucm562577.htm.

7.  See “Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff,” available at: https://www.fda.gov/​downloads/​MedicalDevices/​DeviceRegulationandGuidance/​GuidanceDocuments/​UCM587819.pdf. When finalized, this guidance will represent FDA's current thinking on the topics it addresses.

8.  Patient decision support software is not excluded from the device definition by section 520(o) of the FD&C Act.

9.  https://www.ncbi.nlm.nih.gov/​books/​NBK453484/​?report=​reader.

10.  If the prescription drug-use-related software meets the device definition and, according to its labeling, is intended for use with an approved individually specified drug, where both the software and drug are required to achieve the intended use, indication, or effect, then the software and drug together may constitute a “cross-labeled” combination product (see § CFR 3.2(e)(3) and (4)).

11.  If the software being used as prescription drug-use-related software does not meet the definition of a device (for example, because it is clinical decision support software that is excluded from the device definition by section 520(o) of the FD&C Act) and is not an element of a system that comprises a device, then the regulated product may not be a “combination product” under § 3.2(e), because there is no “device” constituent part. In such a case, the regulated product would be a drug product, but information about such software could still be included in the FDA-required labeling if there is substantial evidence of an effect on a clinically meaningful outcome as a result of the use of the software with the drug product.

12.  See draft guidance entitled “Providing Regulatory Submissions in Electronic and Non-Electronic Format-Promotional Labeling and Advertising Materials for Human Prescription Drugs,” available at: https://www.fda.gov/​downloads/​Drugs/​GuidanceComplianceRegulatoryInformation/​Guidances/​UCM443702.pdf. When final, this guidance will represent FDA's current thinking on this topic. Form FDA 2253 is available at https://www.fda.gov/​downloads/​AboutFDA/​ReportsManualsForms/​Forms/​UCM083570.pdf. The Instructions for Form FDA 2253 is available at https://www.fda.gov/​downloads/​AboutFDA/​ReportsManualsForms/​Forms/​UCM375154.pdf.

13.  See “Medical Product Communications That Are Consistent With the FDA-Required Labeling—Questions and Answers, Guidance for Industry,” available at: https://www.fda.gov/​downloads/​Drugs/​GuidanceComplianceRegulatoryInformation/​Guidances/​UCM537130.pdf.

14.  Under § 202.1(j)(4), promotional materials may be voluntarily submitted for advisory comment prior to first dissemination. This policy would not alter a sponsor's ability to seek such advisory comment on any such material.

15.  See “Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff,” available at: https://www.fda.gov/​downloads/​MedicalDevices/​DeviceRegulationandGuidance/​GuidanceDocuments/​UCM587819.pdf.

16.  Available at: https://www.fda.gov/​downloads/​Drugs/​GuidanceComplianceRegulatoryInformation/​Guidances/​UCM443702.pdf.