I N S I D E
T H E
M I N D S
Recent Developments
in Food and Drug Law
Leading Lawyers on Dealing with Increased
Enforcement, Keeping Up-To-Date with FDA
Requirements, and Developing Compliance
Practices
2014 EDITION
2013 Thomson Reuters/Aspatore
All rights reserved. Printed in the United States of America.
No part of this publication may be reproduced or distributed in any form or by any means, or stored in
a database or retrieval system, except as permitted under Sections 107 or 108 of the U.S. Copyright Act,
without prior written permission of the publisher. This book is printed on acid free paper.
Material in this book is for educational purposes only. This book is sold with the understanding that
neither any of the authors nor the publisher is engaged in rendering legal, accounting, investment, or any
other professional service. Neither the publisher nor the authors assume any liability for any errors or
omissions or for how this book or its contents are used or interpreted or for any consequences resulting
directly or indirectly from the use of this book. For legal advice or any other, please consult your
personal lawyer or the appropriate professional.
The views expressed by the individuals in this book (or the individuals on the cover) do not necessarily
reflect the views shared by the companies they are employed by (or the companies mentioned in this
book). The employment status and affiliations of authors with the companies referenced are subject to
change.
For customer service inquiries, please e-mail West.customer.service@thomson.com.
If you are interested in purchasing the book this chapter was originally included in, please visit
www.west.thomson.com.
Where the “App” World and
FDA Collide: Current Status of
the FDA’s Regulation of
Medical Device Software and
Mobile Medical Apps
Suzan Onel
Partner
K&L Gates LLP
By Suzan Onel
Introduction
Often the term “medical device” conjures up images of hardware such as
pacemakers, intravenous (IV) pumps, thermometers, and mesh patches;
however, the US Food and Drug Administration (FDA) regulates a broader
spectrum of products as “devices.” If a product is intended for use in
diagnosing, curing, mitigating, treating, or preventing diseases or other
conditions (and is not regulated as a “drug”), device statutory and regulatory
requirements apply to the product. Within this large category of products is
“software,” which can be a device by itself or can be a component, part, or
accessory of another device. The fast pace of technological innovations has
led the FDA to develop regulatory schemes specific to different types of
medical device software based on the risk the device poses to the patient
should it fail to perform in accordance with its specifications. Medical
device software includes software utilized in electronic health information
systems, such as laboratory information systems, medical imaging
management systems, medical device data systems, and electronic patient
records, as well as software used in the developing area of mobile medical
applications (commonly referred to as “apps”). This chapter provides
practical guidance regarding the FDA’s current approach to the regulation
of mobile medical apps after first framing the discussion with an overview
of the FDA’s regulation of medical device software.
FDA Regulation of Medical Device Software
By statute, a medical “device” is defined as an “instrument, apparatus,
implement, machine, contrivance, implant, in vitro reagent, or other similar
or related article, including any component, part, or accessory, which
is…intended for use in the diagnosis of disease or other conditions, or in
the cure, mitigation, treatment, or prevention of disease…or intended to
affect the structure or function of the body.” 1 The key to whether software
is deemed a “device,” and how it is therefore regulated, depends on its
intended use.
FDA regulations define “intended use” as the objective intent of the
persons legally responsible for labeling a device, which may be shown by
1
21 USC § 321(h).
Where the “App” World and FDA Collide
labeling claims, advertising materials, or written statements by such persons
or their representatives. 2 If software meets the definition of a “device”
under the Federal Food, Drug, and Cosmetic Act (FDCA), it is subject to
all applicable FDA device statutory and regulatory provisions, including
device general controls (such as establishment registration and device
listing, compliance with applicable portions of the Quality System
Regulation (QSR), and compliance with the medical device reporting and
recordkeeping requirements). 3 It may also be subject to additional special
controls (such as premarket clearance or approval). Whether a device is
subject to additional special controls depends on if it is classified as a Class
I (low risk), Class II (moderate risk), or Class III (high risk) device, which is
based on the device’s intended use. 4
Thus, the same software system may be subject to different regulatory
requirements depending on its intended use. The spectrum is significant,
and ranges from the software being exempt from the statutory definition of
a medical device by FDA policy or regulation, covered by a specific device
regulation, or considered an accessory to a medical device and therefore
subject to the same level of regulation as the parent device.
Software Exempt from Device Requirements
Historically, the FDA has treated certain systems as exempt from FDA
regulations and authorities, even though they technically could meet the
definition of a medical device, including:
•
•
•
2
software intended only for use as traditional “library” functions, such
as storage, retrieval, and dissemination of medical information;
software intended only for use in general accounting or
communication functions; and
software intended for educational purposes rather than for
diagnosis or treatment. 5
21 CFR § 801.4.
21 USC § 301 et seq. (1938).
4
All devices, whether Class I, II, or III, are subject to the general controls and the general
statutory prohibitions against misbranding and adulteration.
5
Policy for the Regulation of Computer Products (draft), CDRH, FDA (FDA Nov. 13, 1989)
(withdrawn); see also 70 Fed Reg, 824, 890 (Jan. 5, 2005); 76 Fed Reg, 8637, 8638; Draft
Guidance for Industry and Food and Drug Administration Staff: Mobile Medical Applications
3
By Suzan Onel
Certain other software products are specifically exempted from the FDA’s
device authority by regulation. These software products include:
•
•
•
general purpose software (for example, spreadsheet, database, and
word processing software) intended for broad general use, as long
as it is not labeled or promoted for medical use; 6
software manufactured or altered by medical practitioners solely for
use in their own practices; 7 and
software intended solely for use in nonclinical research, teaching, and
analysis. 8 This exemption applies to research and development efforts
that have not progressed to the stage of human experimentation.
Because these products are recognized as medical devices, they remain
subject to the FDCA’s general adulteration and misbranding provisions. 9
Software Subject to Specific Device Regulation
The FDA has specifically defined and issued regulations for specific types of
software systems. Examples include laboratory information systems, medical
imaging management systems, and medical device data systems (MDDS).
These regulations describe the regulatory class under which the product falls
(Class I, II, or III) and detail the premarket submission requirements (if any),
as well as whether the product must comply with the QSR. 10
Laboratory Information Systems
Laboratory information systems are regulated as devices under title 21 of
the Code of Federal Regulations, Section 862.2100. Under this regulation,
(FDA July 2011), available at www.fda.gov/downloads/MedicalDevices/DeviceRegulation
andGuidance/GuidanceDocuments/UCM263366.pdf (“FDA Draft Mobile Medical Apps
Guidance”).
6
21 CFR § 807.65(c) (1993).
7
21 CFR § 807.65(d).
8
21 CFR § 807.65(f).
9
21 USC §§ 351 & 352 (1938).
10
The FDA has issued numerous guidance documents providing additional information on the
content of premarket submissions for software controlled devices, the use of off-the-shelf
software, cybersecurity for networked medical devices, and general principles of software
validation. We encourage the close review of these documents when planning a premarket
submission for software controlled devices or incorporating changes to software.
Where the “App” World and FDA Collide
“an electronic device intended to store, retrieve, and process laboratory
data” is regulated as a Class I, 510(k) exempt device (unless the device falls
within a limitation listed in 21 CFR Section 862.9).
Devices and software products that interface directly with laboratory
information systems are considered accessories to the laboratory
information systems, and, as such, are subject to the same regulatory
classification. As a result, an accessory to a laboratory information system is
regulated under 21 CFR, Section 862.2100 and is exempt from submitting a
510(k) premarket notification, but is required to register, list, and comply
with the QSR and medical device reporting requirements.
Medical Imaging Management Systems
Devices and software products that interface directly with medical
imaging equipment generally are regulated as accessories to the
underlying medical devices. As a result, they take on the same regulatory
classification and requirements as the parent device. A distinction exists
for five medical imaging devices, which are separately classified under
their own regulations:
•
•
•
•
•
medical image storage devices; 11
medical image communication devices; 12
medical image digitizers; 13
medical image hardcopy devices; 14 and
picture archiving and communication systems (PACS). 15
Devices and device accessories meeting the definition of a medical image
storage device, medical image communication device, medical image
digitizer, medical image hardcopy device, or a PACS device are all regulated
under their respective individual regulations.
11
21 CFR § 892.2010; Class I, 510(k) exempt.
21 CFR § 892.2020; Class I, 510(k) exempt.
13
21 CFR § 892.2030; Class II, 510(k) required.
14
21 CFR § 892.2040; Class II, 510(k) required.
15
21 CFR § 892.2050; Class II, 510(k) required.
12
By Suzan Onel
Medical Device Data Systems (MDDS)
Devices and software products intended to “transfer, store, convert from
one format to another according to preset specifications, or display medical
device data” are regulated as MDDSs. 16 The FDA issued a final rule
formally classifying MDDSs to the lowest risk (Class I) category in 2011.
“Medical device data” means “any electronic data that is available directly
from a medical device or that was obtained originally from a medical
device.” 17 Thus, the MDDS acts as a “communication conduit,” and does
not modify the medical device data or the display of such data. 18
Because an MDDS does not provide new or unique algorithms or functions,
the FDA determined that applying only general controls to the design and
development of MDDSs provided sufficient regulatory control to mitigate risks
to patients and provide reasonable assurance of safety and effectiveness. 19
Furthermore, general controls include the QSR, which governs the “methods
used in, and the facilities and controls used for, the design, manufacture,
packaging, labeling, storage, installation, and servicing of devices and is
intended to ensure that finished devices will be safe and effective.” 20
Data entered manually into a medical device is not “medical device data”
unless it is subsequently transmitted from the device as electronic data.
MDDSs may include physical communications media (including wireless
hardware), modems, interfaces, and communication protocols. Products
that are accessories or components of other devices are also regulated as
MDDSs—not as accessories or components of the other devices—if their
uses meet the intended uses of MDDSs. 21
The FDA has offered examples of MDDSs, including:
• software that collects output from a ventilator about a patient’s
carbon dioxide level and transmits the information to a central
patient data repository;
16
73 Fed Reg, 7498 (Feb. 8, 2008) (proposed rule); 76 Fed Reg, 8637, 8638, 8649 (Feb. 15,
2011) (codified at 21 CFR § 880.6310).
17
76 Fed Reg at 8641.
18
Id. at 8638-39.
19
Id. at 8638-39.
20
Id. at 8639.
21
Id. at 8644.
Where the “App” World and FDA Collide
•
•
•
software that stores historical blood pressure information for a
health care provider’s later review;
software that converts digital data generated by a pulse oximeter
into a digital format that can be printed; and
software that displays the previously stored electrocardiogram for a
particular patient. 22
Products explicitly excluded from the MDDS rule are those that
control or alter the functions or parameters of the medical device that
provides data to, or receives data through, the MDDS, and products
used in active patient monitoring. These products are likely to be
subject to more rigorous requirements. Additionally, MDDSs do not
include devices that fall under another existing device classification
and therefore have additional functions that are outside the scope of
an MDDS. 23
On the other side of the spectrum, the FDA stated that while certain
functions of an MDDS may be present in an electronic record product, it
“expect[s that] electronic health record software [will] generally [fall] outside
the MDDS classification.” 24 Additionally, the MDDS rule is not intended to
regulate software that allows a doctor to enter or store a patient’s health
history in a computer file, and certain other general uses. 25 The FDA
provided examples of products that are not MDDSs, including:
•
•
22
general-purpose information technology (IT) infrastructures used
in health care facilities that are not altered or reconfigured outside
of their manufactured specifications. This includes components
that are used as part of a general IT infrastructure that may
transfer, store, display, or convert medical device data;
networks used to maintain medical devices to see which systems are
running or malfunctioning, or other similar uses that do not meet the
definition of a medical device under FDCA, Section 201(h);
See U.S. FDA, Identifying an MDDS (Apr. 19, 2011), available at www.fda.gov/
MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/Medica
lDeviceDataSystems/ucm251906.htm (“FDA MDDS Statement”).
23
76 Fed Reg at 8642.
24
Id.
25
Id.
By Suzan Onel
•
•
standard IT software that is not specifically sold by the
manufacturer as an MDDS, which may have MDDS functionality
such as reading serial numbers, barcodes, unique device identifiers
(UDI), or other data from a medical device, but is not used in
providing patient care; and
off-the-shelf passive network-sniffing software that is generally
used to monitor any network performance by reading transmission
control protocol/internet protocol (TCP/IP) packets on a
network, if this software is not intended to connect directly to a
medical device. 26
Electronic Patient Records
Electronic patient recordkeeping systems, and those products that interface
solely with these medical information systems to provide a historical record
of patient information (as distinguished from providing real-time
monitoring of vital statistics), have historically been exempt from active
regulation as medical devices. The basis for this position is that the features
of a patient recordkeeping system are consistent with historic charting
functions; however, more recently, the FDA has been reexamining this
position. It may be that only certain portions or functionalities of the
software or systems fall under the “device” definition. The FDA has
established a working group within its Center for Devices and Radiological
Health (CDRH) to more closely examine the issue. Its intent is to develop a
risk-based, flexible approach that accommodates different electronic health
record systems and adapts as the technology evolves.
Software as Components and Accessories
Pursuant to the FDCA, software that is integrated with a medical device
or intended to be used with a medical device (meaning it meets the
definition of a “component,” “part,” or “accessory”) is regulated as a
“device.” The FDA regulates these products according to the
requirements of the parent device unless the software is separately
classified by regulation (for example, laboratory information systems,
medical image storage devices, PACSs, or MDDSs).
26
See FDA MDDS Statement.
Where the “App” World and FDA Collide
A “software component” is defined as “any…software…intended to
be included as part of the finished, packaged[,] and labeled device.” 27
Most medical device software used by health care practitioners is
incorporated into medical devices as software components. For
example, software is frequently used in infusion pumps, ventilators,
magnetic resonance imaging (MRI) devices, diagnostic x-ray systems,
and clinical laboratory instruments. The FDA evaluates and actively
regulates software components during the regulatory review of the
parent device.
A “software accessory” is a software “unit…intended to be attached to or
used in conjunction with another finished device, although the accessory
may be sold or promoted as an independent unit.” 28 Accessories are
typically marketed as finished devices, although usually not by the same
manufacturer who produces the device with which the accessory is used.
Some examples the FDA has provided include software for the conversion
of pacemaker telemetry data, offline analysis of electroencephalography
(EEG) data, calculation of rate response for a cardiac pacemaker,
calculation of bone fracture risk from bone densitometry data, statistical
analysis of pulse oximetry data, and calculation of the refractive power of
intraocular lenses.
In some cases, a software accessory may have a significantly lower inherent
risk than the parent device. To date, the FDA has not developed an
alternate, less restrictive procedure for evaluating new software accessory
products that impose less risk than the parent device or make the parent
device safer to operate. In essence, if a regulation does not exist for the
software accessory, it is either regulated as a new Class III device, or under
the same regulation as the parent device. This is the crux of the mobile
medical app conundrum.
Mobile Medical Apps
Smartphone and mobile platform apps cover a wide gamut of subjects with
significant growth in the medical and health arena. Medical apps range from
27
61 Fed Reg 52602, 52655 (Oct. 7, 1996).
U.S. FDA, Guidance for the Content of Premarket Submissions for Software Contained in
Medical Devices (May 1998) (superseded by May 2005 Guidance) available at http://www.
fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm.
28
By Suzan Onel
those that help consumers manage their own health and wellness (for
example, the National Institutes of Health’s LactMed app, which gives
nursing mothers information about the effects of medicines on breast milk
and nursing infants) to those that help health care providers improve and
facilitate patient care (for example, the Radiation Emergency Medical
Management app that gives health care providers guidance on diagnosing
and treating radiation injuries), to those that aid consumers in diagnosing
certain health ailments (for example, apps aiding in the diagnosis of rashes
and heart irregularities). 29 Recent estimates show at least 40,000 healthrelated mobile apps on the market, with revenues for health care apps
increasing from $718 million to $1.3 billion between 2011 and 2012. 30 It is
not surprising, then, that the FDA has increased its attention in regulating
“mobile medical apps.” Although the FDA’s first clearance of a mobile
medical app was in 1997, 31 the recent upsurge in mobile apps has left the
FDA to determine how best to regulate mobile medical apps as compared
to its regulation of traditional medical devices in balancing an array of
concerns including patient safety, technological innovations, and consumer
product integration with at-home use devices, medical cost savings, and
consumer demand. As the FDA has recognized, the unique characteristics
of the platforms supporting mobile medical apps may lead to additional or
different risks than traditional medical devices. 32
While the FDA is determining the best regulatory scheme for mobile
medical apps, software companies developing medical apps are left with
uncertainty regarding whether the FDA regulates their products, and, if
so, which requirements they are required to follow. This regulatory
uncertainty complicates the process of commercializing and integrating
29
See U.S. FDA, FDA Proposes Health ‘App’ Guidelines (“Health App Guidelines Article”)
(July 2011), available at www.fda.gov/ForConsumers/ConsumerUpdates/ucm263332.htm.
30
Statistics regarding health care apps revenues calculated by the Mobile Health Market
Report 2011-2016. See Stephen G. Pelletier, Explosive Growth in Health Care Apps Raises
Oversight Questions, AAMC REPORTER, Oct. 2012, available at www.aamc.org/newsroom/
reporter/october2012/308516/health-care-apps.html.
31
Christy Foreman, Testimony before the House Committee on Energy and Commerce. Health
Information Technologies: Administration Perspectives on Innovation and Regulation, (Mar. 21,
2013) available at energycommerce.house.gov/hearing/health-information-technologiesadministration-perspectives-innovation-and-regulation#video (“Foreman House Testimony”).
32
See Draft Mobile Medical Apps Guidance, supra note 5. See also FDA’s Mobile Medical
Apps page, available at http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/
ConnectedHealth/MobileMedicalApplications/default.htm.
Where the “App” World and FDA Collide
mobile medical apps, including how best to present a regulatory plan to
sophisticated investors. We discuss below the FDA’s current approach to
regulating mobile medical apps, the enforcement climate, and the agency’s
likely next steps. 33
Current Regulatory Framework
In July 2011, the FDA issued its long-awaited draft guidance document
on how the agency plans to oversee mobile health technologies. 34 The
FDA’s draft guidance document addresses the “mobile medical app,”
which the FDA defined as a “software application that can be executed
(run) on a mobile platform, or a web-based software application that is
tailored to a mobile platform but is executed on a server.” 35 “Mobile
platforms” are commercial off-the-shelf computing platforms, with or
without wireless connectivity, that are handheld in nature. 36 The FDA’s
regulation does not include the sale or general consumer use of
smartphones or tablets, and does not reach all health-related apps—only
those mobile apps that meet the definition of “device” in FDCA,
Section 201(h) and are intended either to be used as accessories to
regulated medical devices or to transform mobile platforms into
regulated medical devices. 37 For example, an “accessory” to a regulated
medical device includes an app that enables a health care professional to
view medical images on a mobile device, such as an iPad, and make a
diagnosis. 38 An example of an app that transforms a mobile platform
into a regulated medical device is one that turns a smartphone into an
electrocardiography (ECG) machine to detect abnormal heart rhythms
or determine if a patient is experiencing a heart attack. 39
33
Note that the Federal Trade Commission (“FTC”) has not been silent on the issue of mobile
medical apps. In August 2012, the FTC issued a guidance focused on truthful and nonmisleading advertising called, “Marketing Your Mobile App, Get It Right from the Start” and
has taken action against companies making allegedly unsubstantiated claims for their mobile
medical apps.
34
Draft Mobile Medical Apps Guidance, supra note 5.
35
Id. at 7.
36
Id.
37
Id. at 7-8.
38
See Health App Guidelines Article, supra note 29.
39
Id.
By Suzan Onel
Whether a mobile app meets the definition of a “device” depends on the
app’s intended use as demonstrated by labeling 40 claims, advertising
materials, or oral or written statements by manufacturers or their
representatives. 41 If the app’s intended use is for “the diagnosis of disease
or other conditions, or the cure, mitigation, treatment, or prevention of
disease, or is intended to affect the structure or any function of the body of
man,” the FDA will regulate it as a device. 42 The FDA intends to focus on
mobile apps that “either have traditionally been considered medical devices
or affect the performance or functionality of a currently regulated medical
device,” because of the same or similar potential risks they pose if they were
to fail to function as intended. 43 Therefore, the FDA is not regulating the
following examples of mobile apps:
•
•
•
•
•
electronic “copies” of medical textbooks, teaching aids, or
reference materials, or apps that are solely used to provide
clinicians with training or reinforce training previously received;
apps solely used to log, record, track, evaluate, or make decisions
or suggestions related to developing or maintaining general health
and wellness;
apps that automate only general office operations with
functionalities that include billing, inventory, appointments, or
insurance transactions;
generic aids that assist users but are not commercially marketed for
a specific medical indication; and
apps that perform the functionality of an electronic health record
system or personal health record system.44
As previously noted, medical devices are classified in one of three
classes: Class I (lowest risk devices requiring general controls), Class II
(typically requiring the submission and clearance of a 510(k) premarket
notification), and Class III (typically requiring approval of a premarket
40
The FDCA broadly defines “labeling” as “all labels and other written, printed, or graphic
matter (1) upon any article or any of its containers or wrappers, or (2) accompanying such
article.” See 21 U.S.C. § 321(m) (2009).
41
See Draft Mobile Medical Apps Guidance, supra note 5 at 7-8.
42
Id. at 8.
43
Id. at 12.
44
Id. at 10-11.
Where the “App” World and FDA Collide
approval application (PMA)). Using this classification structure,
manufacturers of mobile medical apps subject to regulatory oversight
must meet the requirements associated with the applicable device
classification. Thus, if a mobile medical app falls within a medical device
classification on its own, it is subject to the same requirements
associated with that classification. 45 A mobile medical app that adds
medical device “functionality” to a mobile platform must meet the
classification requirements applicable to that functionality. 46 Similarly, a
mobile medical app that is an “accessory” to a medical device is typically
expected to meet the requirements associated with the classification of
the parent device. 47
While the FDA has recognized that not all mobile medical apps that meet
the “accessory” definition require the same level of regulation as the parent
device, and in fact has stated it plans to apply a “risk-based” enforcement
approach, to date it remains unclear which apps will be held to the
accessory requirements. Because the definition of an “accessory” is broad,
without clear guidance from the FDA, many low risk mobile medical apps
used on non-device products such as iPhones could be regulated as medical
devices if they are intended to work with a medical device, such as a glucose
test strip, blood pressure monitor, or even a body mass index scale. The
same is true for other interoperable products such as mobile phones and
other IT products—they could be regulated as accessories to highly
complex medical devices and therefore take on the regulatory classification
of the high-risk device.
Some examples of mobile medical apps the FDA has said it will regulate as
medical devices include:
•
45
mobile apps that act as an extension of one or more medical
devices by connecting to such devices for purposes of controlling
the devices or displaying, storing, analyzing, or transmitting patientspecific medical device data; 48
Id. at 13.
Id.
47
Id.
48
Id.
46
By Suzan Onel
•
•
•
mobile apps that transform the mobile platform into a medical device
by using attachments, display screens, or sensors, or by including
functionalities similar to those currently regulated medical devices; 49
mobile apps that allow users to input patient-specific information
and—using formulae or processing algorithms—output a patientspecific result, diagnosis, or treatment recommendation to assist in
making clinical decisions; 50 and
mobile apps that allow users to take photographs or view medical
images on a mobile platform to perform clinical analyses, medical
functions, or diagnoses. 51
In its draft guidance, the FDA explained it intends to exercise enforcement
discretion for mobile apps that do not meet the definition of a “mobile
medical app” but meet the FDCA’s definition of a “medical device.” 52 The
FDA, however, did not provide any clear delineation for the enforcement
discretion line, and, instead, “strongly recommend[ed]” that manufacturers
of all mobile apps that may meet the definition of a “device” follow
requirements such as the QSR. 53 As a result, software companies, app
developers, telecommunication service companies, and medical device
companies should exercise care when developing mobile apps and carefully
scrutinize the FDA’s definition of “mobile medical apps” and associated
guidances and policy statements to determine whether their products will be
regulated as medical devices, and, if so, which regulatory requirements will
apply. Additionally, the definition of “mobile medical app manufacturer” is
broad and includes anyone who “initiates specifications, designs, labels, or
creates a software system or application in whole or from multiple software
components.”54 As a result, specification developers for mobile medical
apps may be mobile medical app manufacturers, unless another party
assumes all responsibility for manufacturing and distributing the mobile
medical app.
49
Id. at 14.
Id.
51
Id. at 18-19.
52
Id. at 12.
53
Id.; see also 21 C.F.R. § 820.5 (Quality Systems Regulation).
54
See Draft Mobile Medical Apps Guidance, supra note 5 at 8-10.
50
Where the “App” World and FDA Collide
To date, the FDA has received 142 comments on the Draft Guidance. 55
While the issuance of a final guidance has been anticipated for some time, it
is not likely to be issued before October 2013. Some of the reasons for the
delay relate to the complexity of issues and competing concerns of various
interest groups such as mobile medical app developers, mobile platform
manufacturers, health care institutions, medical device companies,
telecommunication service providers, technology companies, patient
advocacy groups, and individual consumers. Meanwhile, industry can look
to the FDA’s other public statements and actions on this issue. According
to the FDA, the agency is sensitive to both the interests of technology
providers and the need to ensure patient safety, and intends to use a riskstratification approach to mobile health regulation based on intended use
and the level of potential risk to the patient. 56 The agency has also indicated
it is likely to use a quality systems approach to help ensure design integrity.
For example, when using a software upgrade or security patch for a piece of
software, the product developers can review and validate the effect of the
software on the larger system. 57
Further, in March 2013 statements before a House subcommittee hearing
and subsequent follow-on statements, the FDA restated its stance that the
agency’s mobile medical app oversight will focus on apps intended either
to be used as accessories to regulated medical devices, or to transform
mobile platforms into regulated medical devices. 58 The FDA explained
“only a fraction of mobile apps would require FDA review,” specifically
any mobile app “doing the job of a medical device.” 59 The FDA offered
examples of mobile medical apps, including those that control the delivery
55
The current draft guidance does not address wireless safety considerations, classification and
submission requirements related to clinical decision support software, or application of quality
systems to software. Id. at 10. It is anticipated the FDA will address these issues in other
guidance documents. The draft guidance document is also silent on cybersecurity and privacy
considerations.
56
The Gray Sheet, ELSEVIER BUS. INTELLIGENCE at 14 (Nov. 15, 2010).
57
Id.
58
Christy Foreman, Statement to the House Committee on Energy and Commerce. Health
Information Technologies: Administration Perspectives on Innovation and Regulation,
Hearing, Mar 21, 2013, available at doc.house.gov/meetings/IF/IF02/20130321/100544/
HHRG-113-IF02-Wstate-ForemanC-20130321-U1.pdf (“Foreman House Statement”).
59
Christy Foreman, Keeping Up With Mobile App Innovations, FDA VOICE (Mar 21, 2013),
available at blogs.fda.gov/fdavoice/index.php/2013/03/keeping-up-with-mobile-app-innovations/
(“FDA Voice Mobile App Statement”).
By Suzan Onel
of insulin, act as stethoscopes, take patient-specific information, and
provide clinicians with radiation dosage calculations. 60 It also reiterated
that the agency’s proposed policy will not regulate the sale or general
consumer use of smartphones or tablets, and will not apply to mobile
apps that perform the functionality of an electronic health record system
or personal health record system. 61
Notable Mobile Medical App Submissions and Clearances
Overall, it is estimated the FDA has cleared more than seventy-five 510(k)s
with some mobile software component. 62 These cleared apps fall largely
into five main categories: chronic condition management (for example, a
digital logbook that receives data from a companion medical device for
diabetes, asthma, and blood pressure management); ECGs, usually as a
remote, mobile viewer for ECG data; vital sign monitoring apps; imaging
apps; and medication adherence apps. 63
In February 2011, the FDA cleared one of the first mobile medical apps,
which allowed physicians to view medical images and make medical
diagnoses based on computed tomography (CT), MRI, and positron
emission tomography (PET). 64 According to company statements, the FDA
had initially rejected the 510(k) pathway and directed the company to
pursue the PMA process, but subsequently reversed course. A large factor
that ultimately contributed to the device’s clearance was the way the app
ensures that image quality remains sufficient for diagnostic interpretation
60
Id.
See Foreman House Statement, supra note 58.
62
These statistics were compiled by MobiHealthNews, a trade publication for app developers and
other members of the mHealth industry. See Brian Dolan, Analysis: 75 FDA-cleared mobile
medical apps, MOBIHEALTHNEWS (Dec. 20, 2012), available at mobihealthnews.com/19638/
analysis-75-fda-cleared-mobile-medical-apps/. MobiHealthNews reviewed the FDA’s database
of summary decisions for 510(k) clearances and included in its count of cleared mobile medical
apps only those that specifically included mobile software components in the summary
description.
63
Id.
64
See FDA, Press Release, FDA clears first diagnostic radiology application for mobile
devices, available at www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm
242295.htm (Feb 4, 2011). The clearance excludes mammography usage and specifically
states that the device “is not intended to replace full workstations” and should be used “only
when there is no access to a workstation.”
61
Where the “App” World and FDA Collide
under the recommended lighting conditions. 65 By July 2011, the FDA had
cleared a “handful” of mobile medical apps used by health care
professionals, 66 and that number has only since increased.
Examples of recently cleared mobile medical app 510(k) premarket
notifications include:
•
•
•
WelchAllyn’s iPhone app, iExaminer, 67 which is used in
conjunction with an ophthalmoscope to allow users to capture,
send, store, and retrieve images of the eye;
Nephosity’s iPad app, MobileCT Viewer, 68 used for wireless and
portable diagnostic viewing of CT, MRI, and x-ray images. The app
is not intended to replace full workstations and may be used only
when there is no access to a workstation; and
Proteus’ ingestible event marker, Proteus Patch Including
Ingestible Sensor. 69 The patch is a wearable data-logger for
ambulatory recording of metrics such as heart rate, activity, body
angle relative to gravity, and certain patient-logged events that are
signaled by swallowing the ingestible sensor accessory. The patch
then stores and wirelessly sends the data to a general computing
device for display.
As of March 2013, the FDA reported all of the mobile medical apps
reviewed by the agency were considered either Class I or Class II medical
devices; the FDA had not yet found any mobile medical apps to be Class
III medical devices. 70 In terms of time to market, anecdotal research
indicates the FDA review time for mobile medical app device applications
may be shorter than the average time to clearance for medical devices
generally. Time to clearance for medical devices generally has decreased
from an average of 146 days in 2010 to 138 days in 2011, compared to an
65
The Gray Sheet, ELSEVIER BUSINESS INTELLIGENCE at 1 (Feb. 11, 2011). In December 2011,
the FDA cleared the first iPhone-compatible glucose meter. The Gray Sheet, ELSEVIER
BUSINESS INTELLIGENCE at 26 (Dec. 12, 2011).
66
See Health App Guidelines Article, supra note 29 at 1.
67
510(k) number K121405.
68
510(k) number K123082.
69
510(k) number K131524.
70
See Foreman House Testimony.
By Suzan Onel
average of 110 days for mobile medical apps in 2011; however the sample
size for mobile medical apps may be too small to draw any relevant
conclusions. 71 According to the FDA data (which does not include days
when the review clock has “stopped” due to discussions or data requests
related to the submission), reviews of mobile medical apps take
approximately sixty days to complete. 72
FDA Enforcement Activity
While the FDA to date has generally treaded rather lightly in enforcing the
device authorities against manufacturers of mobile medical apps, the agency
has not utterly abdicated oversight. In May 2013, the FDA issued its first
mobile medical app enforcement letter, focusing on a product that
transformed a mobile platform into a regulated medical device. However,
rather than sending a warning letter, which is typical in such cases, the FDA
exercised notable restraint by sending an “It Has Come to Our Attention
Letter.” In that letter, the FDA informed Biosense Technologies (Biosense)
that its urinalysis app (uChek) is a medical device because it allows a mobile
phone to perform in the same manner as a urinalysis test system,
notwithstanding the fact that the company does not sell urinalysis dipsticks.
The FDA advised Biosense that “any company intending to promote their
device for use in analyzing, reading, and/or interpreting these dipsticks
needs to obtain clearance for the entire urinalysis test system (i.e., the strip
reader and the test strips, as used together).” 73 The FDA’s letter indicates
that in the absence of written guidance and clear rules, the agency is
approaching enforcement in this area in a measured fashion, taking a caseby-case approach.
Subsequently, in responding to the FDA’s letter, Biosense focused on the
FDA’s identification of the uChek app’s indication to analyze occult blood
71
Statistics were compiled by the Emergo Group, a global regulatory consulting company for
medical device and in-vitro diagnostic companies, and MobiHealthNews. See Brian Dolan,
Average time to FDA clearance drops again, mobile medical apps still shorter, Feb. 18, 2013,
available at mobihealthnews.com/20400/average-time-to-fda-clearance-drops-again-mobilemedical-apps-still-shorter/.
72
See FDA Voice Mobile App Statement, supra note 59.
73
See FDA Letter to Biosense Technologies Private Limited Concerning the uChek Urine
Analyzer, May 21, 2013, available at www.fda.gov/MedicalDevices/ResourcesforYou/
Industry/ucm353513.htm.
Where the “App” World and FDA Collide
and glucose in urine as “problematic.” 74 Biosense removed these two test
features from its original uChek app and launched the modified app as
“uChek Lite.” 75 Biosense has stated it will be submitting a 510(k) for the
full-feature uChek app and will sell that app as “uChek Universal.” 76
Food and Drug Administration Safety and Innovation Act (FDASIA)
January 2014 Report Requirement
In addition to the release of the FDA’s final mobile medical app
guidance, the FDA, in conjunction with the Federal Communications
Commission (FCC) and the Office of the National Coordinator for
Health Information Technology (ONC), is required by FDASIA to issue
a report by January 2014 with recommendations for a risk-based
regulatory framework pertaining to health IT, including mobile medical
apps. The recommendations are intended to promote innovation,
protect patient safety, and avoid regulatory duplication. 77 To meet the
FDASIA requirement, a workgroup has been created within the Health
IT Policy Committee, including three ex-officio members from the
FDA, ONC, and FCC. 78 During the workgroup’s April 2013 kickoff
meeting, the FDA representative publicly acknowledged the need to
balance patient safety against innovation, and the importance of using a
“judicious” application of the risk-based approach to regulation. 79 The
workgroup will present recommendations to the Health IT Policy
Committee and work from September 2013 through January 2014 to
prepare its report for public comment. 80
74
Biosense Modifies Urinalysis App To Comply With FDA. The Gray Sheet, ELSEVIER
BUSINESS INTELLIGENCE, Jul. 20, 2013.
75
Id. To date, it is unclear whether the FDA has found these steps to be fully responsive to its
concerns.
76
Id.
77
Food and Drug Administration Safety and Innovation Act, Pub. L. No. 112-144, § 618, 126
Stat. 993 (2012). The FDA and FCC have a Memorandum of Understanding to work together
to help promote wireless health care innovation. See Memorandum of Understanding between
the Federal Communications Commission and the Food and Drug Administration Center for
Devices and Radiological Health (July 2010).
78
See FDASIA Workgroup Outlines Priorities, HIMSS, May 3, 2013, available at www.
himss.org/News/NewsDetail.aspx?ItemNumber=18278.
79
Id.
80
Id.
By Suzan Onel
Conclusion
Although the regulation of certain types of medical device software is
largely in place, medical device software technology is constantly evolving
and requires the FDA to continually balance interests of patient safety and
technological innovation in its regulation of these devices. In the past three
years alone, considerable regulatory developments have addressed health
information technology, including the final rule downclassifying MDDSs
from Class III devices to Class I devices, the FDA’s draft guidance defining
and setting (some) parameters for regulating mobile medical apps, and the
FDA’s first enforcement action against a mobile medical app manufacturer.
As Congress recognized when enacting FDASIA, health information
technology is a key area requiring examination by not just the FDA, but also
other agencies including the ONC and FCC. In the coming months, the
health information technology industry should have further direction from
the FDA’s promised final guidance document regarding mobile medical
apps and the FDASIA report of strategy and recommendations for a
regulatory framework for health information technology. What answers
these new documents will provide and how many new questions they will
generate are uncertain. What is certain is that this area will be one to watch
for years to come.
Key Takeaways
•
•
•
•
Carefully analyze the intended use of a software product to
determine if, and under which device classification, it will be
regulated. The device classification will dictate how the product is
regulated and if a premarket submission is required.
Monitor developments including FDA statements, enforcement
actions, guidance documents, and competitive premarket
submissions. For mobile medical apps, FDA’s draft guidance and
other FDA statements and activity can serve as useful indicators of
the FDA’s current thinking and direction on the issue.
Once issued, review the FDA’s final guidance document regarding
mobile medical apps and the January 2014 FDASIA report and
recommendations.**
When counseling mobile medical app developers, advise them to
comply with the FDA’s Quality Safety Regulation (QSR) and
Where the “App” World and FDA Collide
•
review the FDA’s released 510(k) summaries to examine whether
premarket submissions have been made for comparable mobile
medical apps. This will be a useful indicator of whether the FDA is
likely to expect a particular type of mobile medical app to require
premarket clearance and the type of data and information that
should be included in such a submission.
The FDA’s review of submissions for mobile medical apps will
likely vary in intensity depending on the complexity of the app.
Apps with greater reliance on the functionality of the smartphone
and those providing clinical or diagnostic decision support will
likely face more hurdles in obtaining 510(k) clearance.
Suzan Onel is a partner at the global law firm K&L Gates LLP and chairs the firm’s
FDA practice. Ms. Onel advises on all aspects of the FDA law and regulatory
compliance across medical device, pharmaceutical, food, supplement, and cosmetic
industries. Ms. Onel has extensive experience representing medical device, in vitro
diagnostic (IVD), and biotechnology companies on a wide range of issues including
market entry strategies, premarket submissions (510(k)s, PMAs, IDEs), labeling and
promotional activities, adverse event reporting, recalls, and enforcement defense. She also
regularly advises clients on the development of corporate compliance programs and
regulatory strategy. Her transactional work includes conducting regulatory due diligence
for life science companies and investors, drafting supplier contracts and clinical research
agreements, and conducting executive training sessions.
Ms. Onel is a frequent author and lecturer on the FDA-related topics. She is co-editor
and a contributing author of the treatise, Medical Devices Law and Regulation Answer
Book (PLI, 3rd edition (2014) forthcoming) and is co-chair of FDLI’s Medical Device
Committee. She also chairs the ABA’s Food, Cosmetics and Nutraceuticals Committee
and was a past co-chair of the editorial board of FDLI’s magazine, Update. Ms. Onel
received her law degree from the University of Virginia School of Law and she received
her BA with honors in neurobiology and history from the University of Pennsylvania.
Acknowledgment: With grateful acknowledgment to Jacqueline Chan, associate,
K&L Gates LLP, for her assistance in the preparation of this chapter.
Jacqueline J. Chan is an associate at the global law firm K&L Gates LLP. Ms.
Chan’s practice focuses on FDA law and counseling FDA-regulated clients regarding
By Suzan Onel
regulatory compliance and liability risks. She advises domestic and foreign device,
pharmaceutical, food/food additive, cosmetic, dietary supplement, and tobacco clients in a
broad range of matters including US labeling and promotional activities, enforcement risk
assessment and defense, FDA submissions, post-marketing obligations, state regulatory
compliance, and regulatory strategy development.
Ms. Chan received her law degree from the George Washington University Law School
and she received her BA with honors from the Johns Hopkins University. Her legal
experience also includes representation of FDA-regulated companies in complex products
liability litigations in state and federal courts across the country, including multi-district
litigations and consolidated mass tort proceedings. Ms. Chan is a member of the ABA’s
Food, Cosmetics, and Nutraceuticals Committee and is a co-author for the Committee’s
FCN Digest.
** FDA’s final guidance on Mobile Medical Applications was issued on
September 25, 2013, after the date this chapter was submitted for
publication. The final guidance largely follows the positions outlined in the
2011 draft and provides expanded explanations and examples. The final
guidance is available at::
www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/gui
dance documents/ucm263366.pdf.
Aspatore Books, a Thomson Reuters business, exclusively publishes C-Level
executives and partners from the world's most respected companies and law
firms. Each publication provides professionals of all levels with proven
business and legal intelligence from industry insidersdirect and unfiltered
insight from those who know it best. Aspatore Books is committed to
publishing an innovative line of business and legal titles that lay forth
principles and offer insights that can have a direct financial impact on the
reader's business objectives.
Each chapter in the Inside the Minds series offers thought leadership and
expert analysis on an industry, profession, or topic, providing a futureoriented perspective and proven strategies for success. Each author has
been selected based on their experience and C-Level standing within the
business and legal communities. Inside the Minds was conceived to give a
first-hand look into the leading minds of top business executives and
lawyers worldwide, presenting an unprecedented collection of views on
various industries and professions.