[Federal Register Volume 83, Number 224 (Tuesday, November 20, 2018)]
[Notices]
[Pages 58574-58582]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2018-25206]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Food and Drug Administration
[Docket No. FDA-2018-N-3017]
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
[[Page 58575]]
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, [email protected].
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
[[Page 58576]]
more of that sponsor's prescription drugs.\2\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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).
---------------------------------------------------------------------------
\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).
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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
[[Page 58577]]
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.
---------------------------------------------------------------------------
\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).
---------------------------------------------------------------------------
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\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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) (Sec. 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
[[Page 58578]]
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\
---------------------------------------------------------------------------
\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 Sec. CFR
3.2(e)(3) and (4)).
---------------------------------------------------------------------------
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.
[[Page 58579]]
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.
---------------------------------------------------------------------------
\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 Sec.
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.
---------------------------------------------------------------------------
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 (Sec.
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 (Sec. Sec. 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.
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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.''
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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
[[Page 58580]]
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 Sec. 314.81(b)(3)(i) or to CBER pursuant to Sec.
601.12(f): \14\
---------------------------------------------------------------------------
\14\ Under Sec. 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.
---------------------------------------------------------------------------
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.''
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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
[[Page 58581]]
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.
---------------------------------------------------------------------------
\16\ Available at: https://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM443702.pdf.
---------------------------------------------------------------------------
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
Sec. 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?
[[Page 58582]]
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 Sec. 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.
[FR Doc. 2018-25206 Filed 11-19-18; 8:45 am]
BILLING CODE 4164-01-P