News
November 29, 2018

FDA Seeks Comments on the Regulatory Framework for Prescription Drug-Use-Related Software

Advisory

Virtually all pharmaceutical companies have been exploring the use of various software tools in both drug development and in conjunction with marketed products. In the future, such software will be a routine part of drug treatment, providing a better physician and patient understanding of the course of treatment, supporting adherence and proper dosing, and many other applications. While the Food and Drug Administration (FDA or Agency) must ensure that such software is reliable, does not misbrand or adulterate the drug product, and is otherwise consistent with statutory requirements, all stakeholders have an interest in ensuring that the potentially enormous benefits of these tools are achieved.

To that end, on November 20, 2018, FDA published a Federal Register notice requesting comments on a proposed framework for the regulation of prescription drug-use-related software, which the FDA defines broadly to include any software disseminated by drug sponsors to be used with one or more of the sponsor's prescription drugs.1 The proposed framework was issued for discussion purposes only—it is not intended as draft guidance or a proposed rule. Rather, the goal is to seek early input from stakeholders prior to development of a draft guidance. Comments on the framework are due by January 22, 2019.

The range of prescription drug-use-related software varies widely, including both simple and complex tools designed for use by patients, providers, and in conjunction with medical devices, including software designed to, among other applications:

  • record and track dosages, provide reminders to take a drug, and measure a patient's physical activity or other attributes while using a specific drug;
  • enable a healthcare provider to enter dosing instructions for a specific drug that a patient may review and retrieve; and
  • interface 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.

Notably, the framework is not intended to focus on the software itself, but rather "on the output of such software that is presented to the end user."

Highlights of the framework include:

  • FDA would regulate drug-use-related software "output" as drug labeling. Under the proposed framework, software "output" would be regulated as drug labeling. As such, the framework distinguishes output that would be classified as "FDA-required labeling," which requires approval prior to dissemination, from output that is characterized as "promotional labeling." Promotional labeling must be submitted to FDA at the time of initial dissemination of the promotional materials (with the exception of accelerated approval drugs subject to special provisions on submission prior to use). Under some circumstances, however, the framework recommends that promotional software output be submitted for pre-dissemination review under the Agency's existing voluntary process for requesting advisory comments where it may increase the potential for harm to patients compared to the use of the drug without such output.
  • The framework does not address precisely when prescription drug-use-related software is considered a device but—not surprisingly—contemplates overlap between software outputs and medical device regulatory requirements. The focus of the proposed framework is not on when prescription drug-use-related software is considered a device, and it does not propose to alter the regulatory framework for such devices. However, FDA anticipates overlap between this proposed framework regulating software output and device regulation, for instance, in the case of combination products.
  • The framework distinguishes between software disseminated by drug sponsors versus independent third-parties. The proposed framework is only intended to apply to software disseminated by, or on behalf of, a drug sponsor for the use with one or more of the sponsor's prescription drugs. Other software disseminated by third parties unaffiliated with a drug sponsor would not fall under the purview of this framework, even if the intention of the software is for it to be used in conjunction with a particular prescription drug and the third-party software meets the definition of a device. Such software would be regulated under existing device authorities, to the extent applicable. However, where a drug sponsor licenses software originally developed or disseminated by a third party and then disseminates the software for use in conjunction with the sponsor's prescription drug, the software would then fall under the purview of the proposed framework.

A more detailed review is found below.

I. Prescription Drug-Use-Related Software Output as "Drug Labeling"

A major goal of the framework is to ensure that sponsors' digital communications about their prescription drugs are consistent with applicable prescription drug labeling requirements, while preserving flexibility in the development and use of software that will help patients. The framework advances a risk-based approach designed to regulate the "output" of prescription drug-use-related software. "Output" includes all material presented to the end user (i.e., a patient, caregiver, or healthcare professional), such as screen displays created by the software, whether static or dynamic, as well as sounds or audio messages. For instance, output might include a screen display that:

  • permits patients to enter a record of their ingestion of a drug and view records of ingestion over time, as well as track physical activities or symptoms;
  • reminds patients to take medication at appropriate times;
  • shows dosing instructions that a patient may retrieve through an app; or
  • provides a risk calculator to assist healthcare providers in deciding when to prescribe medication and how to calculate the appropriate dose.

Under the proposed framework, prescription drug-use-related software "output" would be regulated as drug labeling. Because this software output accompanies a specific prescription drug—often by explaining how to use the drug or by supplementing the use of the drug—the FDA framework recognizes it as "drug labeling" within the definition found in the Federal Food, Drug, and Cosmetic Act.2

Under current authorities, the FDA recognizes two broad categories of labeling for drugs:

  • FDA-required labeling: Information essential for a provider to make an informed decision about the risks and benefits of prescribing the drug for a patient as well as information needed to safely and effectively use the drug. This type of labeling must be reviewed and approved by FDA prior to dissemination as a part of a new drug application.
  • Promotional labeling: Any other information devised for promotion or advertisement of the product or that is otherwise descriptive of a drug. Promotional labeling is usually not approved by FDA in advance of dissemination but is submitted to the FDA at the time of initial dissemination or publication of the promotional labeling.

Under the proposed framework, whether software output will be considered FDA-required labeling or instead constitutes promotional labeling depends on how the output is used with the prescription drug. FDA anticipates that 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 existing regulations.

A. FDA-Required Labeling

The FDA describes two situations where it anticipates prescription drug-use-related software output may be included in FDA-required labeling:

  • A 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 prescription drug-use-related software and chooses to include this information in the drug application. If the use of the software with the drug demonstrably indicates improved clinical outcomes compared to the use of the drug alone without the software, such evidence would be sufficient to support a labeling claim.
  • A drug-led, drug-device combination product where prescription drug-use-related software is either (1) a device constituent part or (2) an element of a device constituent part, and such software provides a function or information that is essential to one or more intended uses of the combination product.3

In these instances, the output of prescription-drug-use-related software would be regulated as FDA-required labeling and would be reviewed and approved by FDA as a part of the new drug application.

B. Promotional Labeling

Under the proposed framework, output not included in the FDA-required labeling would be considered promotional labeling. As such, it would be submitted to FDA by drug sponsors in the same way that drug sponsors currently submit promotional materials.4 Submissions would include screenshots or other appropriate representations of how the user will experience software output. Examples of promotional labeling output include content that:

  • reminds providers of interventions or tests, consistent with FDA-required labeling, needed before prescribing a drug product;
  • provides patients with information about the prescribed drug also found on the FDA-required labeling, like instructions for use;
  • offers patients simple tools to track their health information related to a condition or drug, enter a dosing regimen, and remind the patient of when the next dose is appropriate; and
  • permits prescribers to provide dosing instructions to patients that are consistent with FDA-required labeling

However, the proposed framework also addresses situations in which prescription drug-use-related software output has the potential to be inconsistent with FDA-required labeling and potentially increases the risk of harm to patient health compared to the use of the drug alone without such output. Specifically, FDA cites as higher risk software that provides recommendations directing patients to make decisions about their drug or disease that would normally be made in consultation with healthcare providers. FDA notes that 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. In these circumstances, the proposed framework recommends that sponsors avail themselves of the opportunity for pre-dissemination review of such prescription drug-use-related software output through the existing voluntary advisory comment process for promotional materials.5 Examples of these instances include software output that instructs patients on when to adjust their dose without first consulting a healthcare provider, or and processes symptom-related information and provides recommendations on when the patient should or should not contact a healthcare provider.

Software and medical technology developers should take note of this proposal, as there is no analog to the routine FDA post-marketing prescription drug labeling submission requirement in medical device regulations. Companies should also consider the extent to which the contours of FDA's recent enforcement discretion policy for general wellness technologies and the availability of statutory exemptions for clinical decision support tools are affected by the approach set forth in the proposed framework, particularly when they "marry" those technologies with prescription drug marketing or disease awareness education programs. For example, software outputs which historically have not been subjected to FDA post-marketing labeling review requirements (either due to exemptions from FDA's premarket notification or approval process, or due to FDA's enforcement discretion policy for wellness products) could now potentially be reviewed under FDA's standards for claim substantiation, fair balance, and consistency with approved indication. Further, while the proposed framework is not intended to disrupt current FDA regulatory approaches to the underlying software, a question about the substantiation for a software output "claim" with the labeling of the referenced prescription drug product could have the effect of calling into question the validation of the software for its intended uses.

II. Prescription Drug-Use-Related Software as a Medical Device

FDA does not intend for the proposed framework to alter the current regulatory landscape for medical devices. For example, if adopted, the framework would not impact the regulation of stand-alone software functions that do not accompany a prescription drug. However, FDA recognizes points of overlap between the framework and existing device regulations. For example, prescription drug-use-related software that meets the definition of a device based on its function would be subject to regulation of its device functionality, as well as regulation of its output under the framework for drug labeling. According to FDA, however, the proposed framework takes into account existing Agency policy to ensure an efficient and coordinated review. For instance, if a prescription drug-use-related software is cleared or approved as a device, and is not a constituent of an approved drug-device combination product, sponsors would only need to submit software output for FDA review once at the time of dissemination through the promotional labeling review process. Because such software was reviewed as a device by Center for Devices and Radiological Health, FDA would not expect that the use of that software would result in an increased potential for harm to patients.

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. 21 C.F.R. § 3.2(e)(3) and (4)). For regulated companies that do not normally develop or commercialize drug-device combination products, this potential distinction is critical, as the investment in modified drug-device combination product quality and adverse event management systems—particularly post-marketing internal company systems intended to identify device failures which could result in significant patient harm—can be significant and require different systems and expertise than "conventional" pharmacovigilance requires.

* * * * *

FDA's new docket on the regulatory framework for prescription drug-use-related software presents an important opportunity to shape the future regulation of software that is increasingly an essential part of drug development, approval, and labeling. Companies planning to develop and/or utilize such software should carefully consider FDA's notice in their software and drug development activities, and consider commenting on the non-binding framework. As noted, comments are currently due on January 22, 2019. After considering comments submitted to the docket, FDA expects to issue a draft guidance that will convey FDA's proposed approach and recommendations.

*Ira Stup contributed to this Advisory. He is a University of Michigan Law School graduate employed at Arnold & Porter Kaye Scholer LLP and is not admitted to the District of Columbia Bar.

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

  1. 83 Fed. Reg. 58574 (Nov. 20, 2018).

  2. See 21 U.S.C. § 321(m).

  3. As an example, FDA cites the approval of 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. See Evaluation of Automatice Class III Designation (De Novo) for Proteus Personal Monitor Including Ingestion Event Marker. Software can be used to interact with the external patch to organize and display the information about ingestion for a patient, provider, or both. The software program that communicates with the patch, which gathers the information from the IEM, is essential to allow review of the data collected by the IEM about ingestion. The 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 use—tracking ingestion of the drug.

  4. Under FDA's postmarket reporting regulations, drug sponsors must submit FDA "labeling or advertising devised for promotion" of a drug using Form FDA 2253 ("Transmittal of Advertisements and Promotional Labeling for Drugs for Human Use") and a copy of the drugs professional labeling. See 21 C.F.R. § 314.81(b)(3)(i); § 601.12(f)(4). Special pre-submission rules apply to certain accelerated approval products. 21 C.F.R. § 314.550; § 601.45.

  5. See 21 CFR 202.1(j)(4).

Email Disclaimer