Digital Tech: BIO Comments on FDA Prescription Drug-Use-Related Software

April 29, 2019

Dear Sir/Madam:

The Biotechnology Innovation Organization (BIO) thanks the Food and Drug Administration (FDA or Agency) for the opportunity to submit comments regarding the open docket on Prescription Drug-Use-Related Software.

BIO is the world's largest trade association representing biotechnology companies, academic institutions, state biotechnology centers and related organizations across the United States and in more than 30 other nations. BIO members are involved in the research and development of innovative healthcare, agricultural, industrial, and environmental biotechnology products.

BIO appreciates the FDA’s release of the Prescription Drug-Use-Related Software (PDURS) Framework with the goal of encouraging innovation and ensuring that developers are aware of regulatory pathways available for bringing novel technologies to the healthcare and medical sectors, as it currently stands there is insufficient clarity regarding the current regulatory pathway and jurisdiction of such software technologies.

BIO is also concerned that aspects of the Framework indicate FDA’s intent to regulate beyond the longstanding accepted confines of “labeling,” traditionally recognized in the industry and reinforced by courts. More specifically, the Framework appears to indicate that virtually all outputs from the prescription drug-use-related software constitute labeling, without regard to the content or scope of the output, which, as the Framework indicates, screen displays, sounds, alerts, and other outputs. It cannot be the case that all media carry the regulatory tag of a label. To do so would ultimately stifle much of the innovation the Framework itself seeks to inspire.

To be sure, and as the Framework itself contends, the Supreme Court has provided that labeling broadly “includes materials that supplement or explain an article.”[1] Yet this holding was not without limitations. In fact, Kordel likely stands more for the proposition that a product shipped separately from printed material cannot save a manufacturer from a misbranding claim. Nevertheless, the Court did not say that all materials that mention a product constitute labeling under the FD&C Act, rather, the content and type of the communication determines whether it is considered labeling. In Kordel the Court examined the content of the communications, evaluating aspects including whether the communication “constituted an essential supplement to the label attached to the package” and recognized in the instant context that “nowhere else was the purchaser advised” how to use the product. In the context, then, determining that “the products and the literature were interdependent.” Thus, not every communication medium – written, printed, etc… -- that simply refers to a product is considered regulated labeling. As such, neither should every output from a prescription drug-use-related software program automatically be considered product labeling. With that in mind, we urge FDA to more specifically outline the types of communications it intends to subject to regulation, bearing in mind the concepts elucidated in Kordel as to whether a communication is an essential supplement and interdependent with the product. We anticipate that not all outputs from a drug-use-related software program will rise to this standard.

In addition to the concern described above, we have included several additional considerations for the FDA below.

Coordination Across the FDA Centers

While BIO appreciates that the Framework clearly outlines how CDER may review different types of PDURS, the Framework does not clearly outline how review of similar products will be made consistent across FDA Centers. For example, an Agency supported approach and policy for analytical validation of software is important to facilitate development and commercialization of innovative software. To this end, the Framework should indicate that CDER recognizes and adopts existing FDA guidance on software validation and cybersecurity. Additionally, CDRH currently reviews software as a medical device (SaMD), software in a medical device (SiMD), and PDURS. Given the release of the new Framework, it is unclear as to how CDRH and CDER will coordinate review of such software moving forward. BIO suggests that products classified as medical devices remain under review by CDRH, with consultation with CDER/CBER on the drug components and/or the software output that relates to the use of the prescription drug. If the software is not classified as a medical device, BIO suggests that CDER/CBER oversight should remain solely on whether the outputs are deemed promotional labeling.

In order to further support consistency, it would be helpful if the FDA outlined clear Agency-wide definitions for terms such as “alert”, “alarm”, “notification”, “reminders”, and “caregiver”. Encouraging all FDA centers to use common definitions for the terms outlined above will help support constancy across Centers and Divisions.

Risk-Based Approach to Regulating Prescription Drug-Use-Related Software:

The FDA’s Framework indicates that “’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 Framework also indicates that, “[r]egardless 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, 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.”[2] Considering the above statements, BIO is concerned that the proposed Framework would create two regulatory standards to market based upon who develops the software (e.g., sponsor-developed versus third-party-developed) resulting in uneven regulatory oversight for software products that would ultimately be used by the same patient population for the same intended purpose.

BIO strongly believes that the level of review of PDURS output should be based upon the potential risks to the end user or patient of the given software, not on the type of product developer releasing the PDURS. While we agree with the intention of the Framework, to ensure Sponsor’s communications about a product via software are consistent with labeling requirements, we recommend that the Agency take a risk-based, Agency-wide (i.e., consistent across Centers and Divisions) approach to regulating software output. Such an approach would identify clear regulatory requirements for any developer. As FDA states, the goal of the Framework is to encourage innovation and ensure that the inventors of today will not be discouraged from bringing novel ideas to the healthcare and medical product sectors, as such it is imperative that the Framework establishes risk-based regulatory predictability in the development pathway for all types of software products regardless of the reviewing Division or Center. 

Clarification about how the Framework interacts with Other FDA Guidance:

BIO requests that the Agency clarify the interaction of the proposed PDURS Framework with previously published draft guidance such as “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act” and “Clinical and Patient Decision Support Software.” Specifically, BIO request the FDA to clarify the following points:

The PDURS Framework states: “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.”

BIO requests that the FDA provide additional clarity regarding how the FDA is making distinctions between software and PDURS output. We also ask the Agency to clarify whether dosing reminders and/or adjustments constitute “immediate clinical action.” The draft guidance, “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21^st Century Cures Act” (Section 3060 draft guidance), states that software that generates alarms or alerts on which caregivers would rely to take immediate clinical action will be regulated as medical devices, whereas software providing a notification where immediate clinical action is not needed will not be considered medical devices. We note that the current proposed Framework cites PDURS output tracking drug dose regimen as an example of software output that would only be submitted to the Agency at the time of initial dissemination and thereby not be regulated as a medical device. The example cited above is PDURS that a patient could rely upon to take immediate clinical action (e.g., drug dose). Depending on the type of drug and the immediacy of the dose required, these PDURS outputs could be regulated as a medical device according to the Section 3060 draft guidance. Under the current proposed Framework, however, this software output and other comparable types of software with reminder or alert functions will not be regulated as medical devices.

The PDURS Framework indicates: “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.”

We note that the draft guidance, Clinical and Patient Decision Support Software” (CDS/PDS draft guidance), provides an example of a software functionality that would be regulated by the Agency because it recommends a dose adjustment that the intended user could not reach on his or her own without primarily relying on the software function. We reference the cited example from the CDS/PDS draft guidance here: “FDA intends to focus its regulatory oversight on PDS that do not follow the recommendations outlined above. Below is an example of such a software functionality: For patients performing home blood testing required with use of warfarin, an anticoagulant (“blood thinner”), the software makes recommendations for dosing adjustments based on the outcome of the home blood test (i.e., the International Normalized Ratio (INR)) and published algorithms, without the patient seeking consultation with their healthcare provider.”

The proposed Framework, however, provides as an example a PDURS output that instructs patients on when to adjust their dose based on symptoms without first consulting a healthcare provider. In this example, FDA recommends the output be submitted to the Agency by the Sponsor in advance of dissemination using the existing voluntary process for requesting advisory comment and thus the output would not be considered a medical device. We note that the example cited above from the proposed Framework is very similar to the example provided in the CDS/PDS draft guidance, as in both cases, the software provides dosing recommendations to patients based on published guidelines and algorithms without oversight by a healthcare provider, however the software example provided within the CDS/PDS draft guidance would be regulated as a medical device, while the software example provided in the current proposed Framework would not. BIO also requests that the FDA provide clarity regarding submissions to the Office of Prescription Drug Promotion consult and whether those submissions absolve a sponsor of CDRH requirements.     

Additional Comments:

• For clarity, BIO requests that the Draft Framework indicate whether disease awareness or brand-agnostic software is considered PDURS and whether such software would be subject to the Framework. BIO believes that this type of software should not require submission or are not covered by the guidance, as they are not labeling. 
• BIO requests that the FDA provide additional information on what constitutes “output” in the context of software products. For example, software “output” could be large in scope including vibrations and other noises which may be complex to characterize. Software may also provide different outputs depending on the specific characteristics of the patient (e.g., patients with a particular symptom are prompted with different alerts). Output also may not involve communication of the drug in many cases, as it may include other data from wearables that is not being used for drug administration but overall patient management. BIO request the FDA to clarify whether a sponsor would need to submit to the FDA each variation of the “output”.

• In reference to the Agency’s request for feedback on considerations related to the proposed Framework that would facilitate timely generic competition, we recommend that the Agency clearly define how PDURS that are reviewed and referenced int eh product label will be regulated when generics of the branded drug are developed. We request that the Agency delineate whether the labeling of generics will include the original software information after the branded drug goes off-patent, how software regulated by FDA will be subject to exclusivity (e.g., if the software is developed and marketed with a drug, would the drug exclusivity automatically apply to the software), and how generic versions of software will be regulated (e.g., what is equivalence and how can branded software become generic)?
• The proposed Framework recommends that Sponsors seeking additional software claims to the FDA-required labeling of an already approved drug “submit information to the Agency as a new original application for review.” We note that the meaning of “a new original application for review” is unclear and request that the Agency clarify whether a “new original application” means a New Drug Application (NDA) for the software or whether the application would be a supplement to the drug application. If an NDA for the software is required, we ask the Agency to clarify whether the requirements would be the same as those for a new drug. We further request the Agency to clarify its perspective on how benefit claims may be included in the label of a drug, including what type(s) of data the Agency would require from a Sponsor seeking to make such a benefit claim.
• BIO requests that FDA consider the unique characteristics of mobile application platforms (“mobile apps”) such as: inherent space constraints, smaller screen sizes, and other formatting limitations when deciding how to address the communication of risk information within the new proposed Framework. By definition, a mobile app is a software application developed specifically for use on small-screened, wireless computing devices, such as smart phones and tablets, that are not intended for use on larger-screened desktop or laptop computers.[3] FDA adopted this approach in the “Draft Guidance for Industry and Food and Drug Administration Staff-Mobile Medical Applications”, when it acknowledged the unique characteristics of mobile platforms (e.g., smaller screen size, lower contrast ratio, etc.), and concluded that FDA would take such limitations into account when assessing the appropriate regulatory oversight for these products.[4]
• Given the space limitations inherent in mobile medical apps, we request that FDA’s Framework provide illustrative scenarios that describe the factors FDA will consider when evaluating risk disclosure in mobile medical apps. Due to these inherent platform space constraints, we recommend that FDA’s eventual draft guidance adopt a similar approach to that taken in the “Internet/Social Media Platforms with Character Space Limitations—Presenting Risk and Benefit Information for Prescription Drugs and Medical Devices” guidance (or any subsequent revision) regarding the disclosure of risk information in mobile medical apps.
• BIO also requests that the FDA provide information on lifecycle management of software. The rapid iteration of software requires an agile regulatory framework and CDRH is already developing policies that will allow iterations without prior clearance or approval, but it remains unclear as to whether PDURS would be eligible to precertification programs or the AI/ML proposed framework, as applicable.

Finally, BIO encourages the FDA to support predictability to enable investments, and also to ensure the requirements for PDURS are not overly burdensome so as a disincentivize Sponsors from developing such health technologies in the first place. To this end, BIO encourages the Agency to ensure that the Framework will be relevant to the software of tomorrow and with that in mind, it’s critical that the language used is flexible enough to allow for evolutions in these technologies.

BIO appreciates this opportunity to submit comments regarding FDA’s open docket on Prescription Drug-Use-Related Software Framework. We would be pleased to provide further input or clarification of our comments, as needed.