Policy For Device Software Functions and Mobile Medical Applications Guidance For Industry and Food and Drug Administration Staff

Contains Nonbinding Recommendations
Policy for Device Software Functions

and Mobile Medical Applications
Guidance for Industry and
Food and Drug Administration Staff
Document issued on September 27, 2019.
Document originally issued on September 25, 2013.
This document supersedes “Mobile Medical Applications” issued February

9, 2015.
For questions about this document regarding CDRH-regulated devices, contact the Division
of Digital Health by e-mail at digitalhealth@fda.hhs.gov.
For questions about this document regarding CBER-regulated devices, contact the Office of
Communication, Outreach, and Development (OCOD) at 1-800-835-4709 or 240-402-8010.
U.S. Department of Health and Human Services

Food and Drug Administration
Center for Devices and Radiological Health
Center for Biologics Evaluation and Research
Preface
Public Comment
You may submit electronic comments and suggestions at any time for Agency consideration
to https://www.regulations.gov. Submit written comments to the Dockets Management Staff,
Food and Drug Administration, 5630 Fishers Lane, Room 1061, (HFA-305), Rockville, MD
20852.
Identify all comments with the docket number FDA-2011-D-0530. Comments may not be
acted upon by the Agency until the document is next revised or updated.
Additional Copies
CDRH
Additional copies are available from the Internet. You may also send an e-mail request to
CDRH-Guidance@fda.hhs.gov to receive a copy of the guidance. Please use the document
number 1741 and complete title of the guidance in the request.
CBER
Additional copies are available from the Center for Biologics Evaluation and Research
(CBER), Office of Communication, Outreach, and Development (OCOD), 10903 New
Hampshire Ave., WO71, Room 3128, Silver Spring, MD 20903, or by calling 1-800-835-
4709 or 240-402-8010, by email, ocod@fda.hhs.gov, or from the Internet at
https://www.fda.gov/vaccines-blood-biologics/guidance-compliance-regulatory-information-
biologics/biologics-guidances.
Table of Contents
I. Introduction ......................................................................................................................... 1
II. Background ......................................................................................................................... 3
III. Definitions........................................................................................................................... 4
A. Mobile Platform ............................................................................................................... 4
B. Mobile Application (Mobile App) ................................................................................... 4
C. Mobile Medical Application (Mobile Medical App) ....................................................... 4
D. Regulated Medical Device ............................................................................................... 6
E. Mobile Medical App Manufacturer ................................................................................. 6
IV. Scope ................................................................................................................................... 9
V. Regulatory Approach for Device Software Functions ...................................................... 10
A. Device software functions: Subset of software functions that are the focus of FDA’s
regulatory oversight ............................................................................................................ 10
B. Software functions for which FDA intends to exercise enforcement discretion (meaning
that FDA does not intend to enforce requirements under the FD&C Act) ......................... 12
VI. Regulatory Requirements.................................................................................................. 14
Appendix A Examples of Software Functions that are NOT Medical Devices .................... 16
Appendix B Examples of Software Functions for which FDA intends to exercise
enforcement discretion ............................................................................................................ 22
Appendix C Examples of Software Functions that are the focus of FDA’s regulatory
oversight (Device Software Functions and Mobile Medical Apps) ........................................ 24
Appendix D Examples of current regulations ........................................................................ 27
Appendix E Brief description of certain device regulatory requirements ............................. 31
Appendix F Frequently Asked Questions (FAQs) ................................................................. 36
Appendix G Additional Resources ........................................................................................ 41
A. Guidance Documents ..................................................................................................... 41
B. Standards ........................................................................................................................ 41
Policy for Device Software Functions

and Mobile Medical Applications
Guidance for Industry and
Food and Drug Administration Staff
This guidance represents the current thinking of the Food and Drug Administration (FDA or
Agency) on this topic. It does not establish any rights for any person and is not binding on FDA or
the public. You can use an alternative approach if it satisfies the requirements of the applicable
statutes and regulations. To discuss an alternative approach, contact the FDA staff or Office
responsible for this guidance as listed on the title page.
I. Introduction
The Food and Drug Administration (FDA) recognizes the extensive variety of actual and
potential functions of software applications (apps) and mobile apps, the rapid pace of
innovation, and their potential benefits and risks to public health. The FDA is issuing this
guidance document to inform manufacturers, distributors, and other entities about how the
FDA intends to apply its regulatory authorities to select software applications intended for
use on mobile platforms (mobile applications or “mobile apps”) or on general-purpose
computing platforms. Given the rapid expansion and broad applicability of software
functions deployed on mobile or other general-purpose computing platforms, the FDA is
issuing this guidance document to clarify the subset of software functions to which the FDA
intends to apply its authority.
FDA refers to software functions that are device functions as “device software functions.”
Device software functions may include “Software as a Medical Device (SaMD)” and
“Software in a Medical Device (SiMD).1, 2” Software functions that meet the definition of a
device may be deployed on mobile platforms, other general-purpose computing platforms, or
in the function or control of a hardware device. If a software function that meets the
definition of a device is deployed on a mobile platform, it may be referred to as a “mobile
medical app.” The policies described in this guidance are independent of the platform on
which they might run, are function-specific, and apply across platforms. Therefore, the
policies described using terms such as “mobile medical apps,” “mobile medical app
manufacturers,” “device software functions,” and “device software function manufacturers”
1
See FDA website on “Software as a Medical Device (SaMD),” available at https://www.fda.gov/medical-
devices/digital-health/software-medical-device-samd.
2
See the International Medical Device Regulators Forum final document, “Software as a Medical Device
(SaMD): Key Definitions,” available at http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-
samd-key-definitions-140901.pdf.
1
are not specific to whether the the function is deployed on a mobile platform or other general
purpose-computing platform.
Many software functions are not medical devices (meaning such software functions do not
meet the definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic
Act (FD&C Act)), and FDA does not regulate them as devices. Some software functions may
meet the definition of a medical device, but because they pose a lower risk to the public,
FDA intends to exercise enforcement discretion over these devices (meaning it will not
enforce requirements under the FD&C Act).
Consistent with the FDA’s existing oversight approach that considers functionality of the
software rather than platform, the FDA intends to apply its regulatory oversight to only those
software functions that are medical devices and whose functionality could pose a risk to a
patient’s safety if the device were to not function as intended.
FDA is issuing this guidance to provide clarity and predictability for software manufacturers.
This document has been updated to be consistent with section 3060(a) of the 21st Century
Cures Act, which amended section 520 of the FD&C Act, removing certain software
functions from the definition of device in section 201(h) of the FD&C Act, and the guidance
document entitled “Medical Device Data Systems, Medical Image Storage Devices, and
Medical Image Communications Devices,” originally issued on February 9, 2015.3 Examples
of mobile apps and software on the FDA web site4 (that were added after September 25,
2013) were incorporated into the appropriate appendices of this document for consistency.
For the current edition of the FDA-recognized standard(s) referenced in this document, see
the FDA Recognized Consensus Standards Database.5 For more information regarding use of
consensus standards in regulatory submissions, please refer to the FDA guidance titled
Appropriate Use of Voluntary Consensus Standards in Premarket Submissions for Medical
Devices6 and “Standards Development and the Use of Standards in Regulatory Submissions
Reviewed in the Center for Biologics Evaluation and Research.”7
FDA's guidance documents, including this guidance, do not establish legally enforceable
responsibilities. Instead, guidances describe the Agency’s current thinking on a topic and
should be viewed only as recommendations, unless specific regulatory or statutory
requirements are cited. The use of the word should in Agency guidance means that
something is suggested or recommended, but not required.
3
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/medical-device-
data-systems-medical-image-storage-devices-and-medical-image-communications-devices.
4
Available at https://www.fda.gov/medical-devices/digital-health/device-software-functions-and-mobile-
medical-applications.
5
Available at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/search.cfm.
6
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/appropriate-use-
voluntary-consensus-standards-premarket-submissions-medical-devices.
7
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/standards-
development-and-use-standards-regulatory-submissions-reviewed-center-biologics-evaluation
2
II. Background
As mobile platforms become more user friendly, computationally powerful, and readily
available, innovators have begun to develop mobile apps of increasing complexity to
leverage the portability mobile platforms can offer. Some of these new software functions are
specifically targeted to assisting individuals in their own health and wellness management.
Other software functions are targeted to health care providers as tools to improve and
facilitate the delivery of patient care.
In 1989, FDA prepared a general policy statement on how it planned to determine whether a
computer-based product and/or software-based product is a device, and, if so, how the FDA
intended to regulate it. The document, “FDA Policy for the Regulation of Computer
Products,” became known as the “Draft Software Policy.” After 1989, however, the use of
computer and software products as medical devices grew exponentially and the types of
products diversified and grew more complex (and that trend has continued). As a result, the
FDA determined that the draft policy did not adequately address all of the issues related to
the regulation of all medical devices containing software. Therefore, in 2005, the Draft
Software Policy was withdrawn.8
Although the FDA has not issued an overarching software policy, the Agency has formally
classified certain types of software applications that meet the definition of a device and,
through classification, identified specific regulatory requirements that apply to these devices
and their manufacturers. These software devices include products that feature one or more
software components, parts, or accessories, as well as devices that are composed solely of
software.
The FDA has previously clarified that when a software application is used to analyze medical
device data, it has traditionally been regulated as an accessory to a medical device9 or as
medical device software. In 2014, the International Medical Device Regulators Forum
established globally harmonized vocabulary for such software applications and defined the
term “Software as a Medical Device (SaMD).10”
As is the case with traditional medical devices, certain software functions that are device
functions (referred to in this document as ‘device software functions’) can pose potential
risks to public health. Moreover, certain device software functions may pose risks that are
unique to the characteristics of the platform on which the software function is run. For
example, the interpretation of radiological images on a mobile device could be adversely
8
Annual Comprehensive List of Guidance Documents at the Food and Drug Administration (70 FR 824 at 890)
(January 5, 2005).
9
See “Medical Device Accessories - Describing Accessories and Classification Pathways” Guidance, available
at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/medical-device-accessories-
describing-accessories-and-classification-pathways.
10
See the International Medical Device Regulators Forum final document, “Software as a Medical Device
(SaMD): Key Definitions,” available at http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-
samd-key-definitions-140901.pdf.
3
affected by the smaller screen size, lower contrast ratio, and uncontrolled ambient light of the
mobile platform. FDA intends to take these risks into account in assessing the appropriate
regulatory oversight for these products.
This guidance clarifies and outlines the FDA’s current thinking. The Agency will continue to
evaluate the potential impact these technologies might have on improving health care,
reducing potential medical mistakes, and protecting patients.
III. Definitions
A. Mobile Platform
For purposes of this guidance, “mobile platforms” are defined as commercial off-the-shelf
(COTS) computing platforms, with or without wireless connectivity, that are handheld in
nature. Examples of these mobile platforms include mobile computers such as smart phones,
tablet computers, or other portable computers.
B. Mobile Application (Mobile App)

For purposes of this guidance, a mobile application or “mobile app” is defined as a software
application that can be executed (run) on a mobile platform (i.e., a handheld commercial off-
the-shelf computing platform, with or without wireless connectivity), or a web-based
software application that is tailored to a mobile platform but is executed on a server.
C. Mobile Medical Application (Mobile Medical

App)
For purposes of this guidance, a “mobile medical app” is a mobile app that incorporates
device software functionality that meets the definition of device in section 201(h) of the
FD&C Act11; and either is intended:
· to be used as an accessory to a regulated medical device; or
11
Products that are built with or consist of computer and/or software components or applications are subject to
regulation as devices when they meet the definition of a device in section 201(h) of the FD&C Act. That
provision defines a device as “…an instrument, apparatus, implement, machine, contrivance, implant, in vitro
reagent, or other similar or related article, including any component, part, or accessory”, that is “… intended for
use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease,
in man …” or “… intended to affect the structure or any function of the body of man or other animals…” and
“does not include software functions excluded pursuant to section 520(o) of the FD&C Act.” Thus, software
applications that run on a desktop computer, laptop computer, remotely on a website or “cloud,” or on a
handheld computer may be subject to device regulation if they are intended for use in the diagnosis or the cure,
mitigation, treatment, or prevention of disease, or to affect the structure or any function of the body of man. The
level of regulatory control necessary to assure safety and effectiveness varies based upon the risk the device
presents to public health. (See Appendix D for examples).
4
· to transform a mobile platform into a regulated medical device.
The intended use of a mobile app determines whether it meets the definition of a “device.”
As stated in 21 CFR 801.4,12 intended use may be shown by labeling13 claims, advertising
materials, or oral or written statements by manufacturers or their representatives. When the
intended use of a mobile app 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 mobile app is a device under section 201(h) of the FD&C
Act if it is not a software function excluded from the device definition by section 520(o) of
the FD&C Act.
One example is a mobile app that makes a light emitting diode (LED) operate. If the
manufacturer intends the system to illuminate objects generally (i.e., without a specific
medical device intended use), the mobile app would not be considered a medical device. If,
however, through marketing, labeling, and the circumstances surrounding the distribution,
the mobile app is promoted by the manufacturer for use as a light source for doctors to
examine patients, then the intended use of the light source would be similar to a conventional
device such as an ophthalmoscope.
In general, if a software function is intended for use in performing a medical device function
(i.e. for diagnosis of disease or other conditions, or the cure, mitigation, treatment, or
prevention of disease) it is a medical device, regardless of the platform on which it is run. For
example, mobile apps intended to run on smart phones to analyze and interpret EKG
waveforms to detect heart function irregularities would be considered similar to software
running on a desktop computer that serves the same function, which is regulated under 21
CFR 870.2340 (“Electrocardiograph”). FDA’s oversight approach to software functions is
focused on their functionality, just as we focus on the functionality of conventional devices.
Our oversight is not determined by the platform. Under this guidance, FDA would not
regulate the sale or general/conventional consumer use of smartphones or tablets. FDA’s
oversight applies to software functions performing medical device functions, such as when a
mobile medical app or software application transforms a mobile platform or a general
purpose computing platform into a medical device. However, as previously noted, we intend
12
“The words ‘intended uses’ or words of similar import … refer to the objective intent of the persons legally
responsible for the labeling of devices. The intent is determined by such persons' expressions or may be shown
by the circumstances surrounding the distribution of the article. This objective intent may, for example, be
shown by labeling claims, advertising matter, or oral or written statements by such persons or their
representatives. It may be shown by the circumstances that the article is, with the knowledge of such persons or
their representatives, offered and used for a purpose for which it is neither labeled nor advertised. The intended
uses of an article may change after it has been introduced into interstate commerce by its manufacturer. If, for
example, a packer, distributor, or seller intends an article for different uses than those intended by the person
from whom he received the devices, such packer, distributor, or seller is required to supply adequate labeling in
accordance with the new intended uses. But if a manufacturer knows, or has knowledge of facts that would give
him notice that a device introduced into interstate commerce by him is to be used for conditions, purposes, or
uses other than the ones for which he offers it, he is required to provide adequate labeling for such a device
which accords with such other uses to which the article is to be put.” 21 CFR 801.4.
13
“The term ‘labeling’ means 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.” Section 201(m) of the FD&C Act, 21 U.S.C.
321(m).
5
to apply this oversight authority only to those software applications whose functionality
could pose a risk to a patient’s safety if the software applications were to not function as
intended.
D. Regulated Medical Device

For purposes of this guidance, a “regulated medical device” is defined as a product that meets
the definition of device in section 201(h) of the FD&C Act and that has been cleared or
approved by the FDA review of a premarket submission or otherwise classified by the FDA.
This definition can include novel devices, whether or not on a mobile platform, that the FDA
will clear or approve by the review of a premarket submission or otherwise classify.
Examples of regulated medical devices are identified in Appendix D.
E. Mobile Medical App Manufacturer

For purposes of this guidance, a “mobile medical app manufacturer” is any person or entity
that manufactures mobile medical apps in accordance with the definitions of manufacturer in
21 CFR Parts 803, 806, 807, and 820.14 A mobile medical app manufacturer may include
anyone who initiates specifications, designs, labels, or creates a software system or
application for a regulated medical device in whole or from multiple software components.
This term does not include persons who exclusively distribute mobile medical apps without
engaging in manufacturing functions; examples of such distributors may include owners and
operators of “Google Play,” “iTunes App Store,” and “BlackBerry App World.” Examples of
mobile medical app manufacturers include any person or entity that:
· Creates, designs, develops, labels, re-labels, remanufactures, modifies, or creates a

mobile medical app software system from multiple components. This could include a
person or entity that creates a mobile medical app by COTS software components and
markets the product to perform as a mobile medical app;
· Initiates specifications or requirements for mobile medical apps or procures product

development/manufacturing services from other individuals or entities (second party)
for subsequent commercial distribution. For example, when a “developer” (i.e., an
entity that provides engineering, design, and development services) creates a mobile
14
Regulatory definitions of the term “manufacturer” or “manufacture” appear in 21 CFR Parts 803, 806, 807,
and 820. For example – under FDA’s 21 CFR 807.3(d) – establishment registration and device listing for
manufacturers and initial importers of devices – “Manufacture, preparation, propagation, compounding,
assembly, or processing of a device means the making by chemical, physical, biological, or other procedures of
any article that meets the definition of device in section 201(h) of the act. These terms include the following
activities: (1) Repackaging or otherwise changing the container, wrapper, or labeling of any device package in
furtherance of the distribution of the device from the original place of manufacture to the person who makes
final delivery or sale to the ultimate consumer; (2) Initial importation of devices manufactured in foreign
establishments; or (3) Initiation of specifications for devices that are manufactured by a second party for
subsequent commercial distribution by the person initiating specifications.”
6
medical app from the specifications that were initiated by the “author,” the “author”
who initiated and developed specifications for the mobile medical app is considered a
“manufacturer” of the mobile medical app under 21 CFR 803.3. For purposes of this
guidance, manufacturers of a mobile medical app would include persons or entities
who are the creators of the original idea (initial specifications) for a mobile medical
app, unless another entity assumes all responsibility for manufacturing and
distributing the mobile medical app, in which case that other entity would be the
“manufacturer.15” Software “developers” of a mobile medical app that are only
responsible for performing design and development activities to transform the
author’s specifications into a mobile medical app would not constitute manufacturers,
and instead the author would be considered the manufacturer;
· Creates a mobile medical app and hardware attachments for a mobile platform that
are intended to be used as a medical device by any combination of the mobile medical
app, hardware attachments, and the mobile platform;
· Creates a mobile medical app or a software system that provides users access to the
medical device function through a website subscription, software as a service, 16 or
other similar means.
In contrast, the following are examples of persons or entities that are NOT considered to be
mobile medical app manufacturers (i.e., persons not within the definition of manufacturer in
21 CFR Parts 803, 806, 807, and 820). Because they are not manufacturers, none of the
persons or entities in these examples would have to register their establishments, list their
products with the FDA,17 or submit a premarket application:
· Manufacturers or distributors of mobile platforms who solely distribute or market

their platform and do not intend (by marketing claims – e.g., labeling claims or
advertising material) the platform to be used for medical device functions. When
mobile medical apps are run on a mobile platform, the mobile platform is treated as a
component of the mobile medical app’s intended use.18 Therefore the mobile platform
manufacturer is exempt from the Quality System regulation and registration and
listing requirements.19 For example, if it is possible to run mobile medical apps on
BrandNamePhone but BrandNamePhone is not marketed by BrandNameCompany as
intended for use as a medical device, then BrandNameCompany would not be
considered a mobile medical app manufacturer or a medical device manufacturer.
Also, in this example, the BrandName Phone sold to consumers would not be
regulated by FDA as a medical device. FDA does not consider entities that
15
See 21 CFR 803.3 (definition of manufacturer) and 21 CFR 807.20(a)(2).
16
By this we mean to include any “server software application” that provides a service to a client software
application on a mobile platform.
17
See 21 CFR 807.65 and 21 CFR 807.85.
18
See 21 CFR 820.3(c), which defines a component as “any raw material, substance, piece, part, software,
firmware, labeling, or assembly which is intended to be included as part of the finished, packaged, and labeled
device.”
19
See 21 CFR 807.65(a) and 21 CFR 820.1(a).
7
exclusively distribute mobile medical apps, such as the owners and operators of the
“iTunes App Store” or the “Android Market,” to be medical device manufacturers.
FDA also does not consider mobile platform manufacturers to be medical device
manufacturer just because their mobile platform could be used to run a mobile
medical app regulated by FDA.
· Third parties who solely provide market access to mobile medical apps (i.e. solely
distribute mobile apps), but do not engage in any manufacturing functions as defined
in 21 CFR Parts 803, 806, 807, and 820. Examples of such third parties may include
owners and operators that are only engaged in providing an online market place that
allow mobile medical app manufacturers to commercially distribute their mobile
medical apps. Specific examples of such online market places include “Google Play,”
“iTunes Store,” and “BlackBerry App World”;
· Providers of tools, services, or infrastructure used in the development, distribution, or

use of a mobile medical app. Examples include providers of internet connectivity
(i.e., internet service), providers of general-purpose computer or information
technology, providers that host the web service for content or software application.
Other examples of providers of tools, services, or infrastructure include customer
support services, data center hosting services, cloud hosting services, application
hosting services, wireless carriers, or providers of software development kits.
However, a creator of a mobile medical app or a software system that provides users
access to the medical device function through a website subscription, software as a
service,20 or other similar means is considered a mobile medical app manufacturer;
· Licensed practitioners, including physicians, dentists, and optometrists, who

manufacture a mobile medical app or alter a mobile medical app solely for use in
their professional practice and do not label or promote their mobile medical apps to
be generally used by other licensed practitioners or other individuals.21,22 For
example, if Dr. XYZ, a licensed practitioner, creates a mobile medical app called the
“XYZ-recorder” that enables attaching an ECG electrode to a smartphone, and
provides the “XYZ-recorder” to his/her patient to use it to record the patient’s
electrocardiographic readings for 24 hours, Dr. XYZ is not considered a mobile
medical app manufacturer. If Dr. XYZ is in a group practice (including a telehealth
network) and permits other physicians in the practice to provide the XYZ-recorder to
their patients, Dr. XYZ is not considered a mobile medical apps manufacturer.
However, if Dr. XYZ, the licensed practitioner, distributes the “XYZ-recorder” and,
through labeling or promotion intends to make it generally available to or to be
20
As identified in footnote 15, we mean to include any “server software application” that provides a service to a
client software application on a mobile platform.
21
Section 510(g)(2) of the FD&C Act: – Registration of producers of drugs or devices – Exclusions from
application of section: “practitioners licensed by law to prescribe or administer drugs or devices and who
manufacture, prepare, propagate, compound, or process drugs or devices solely for use in the course of their
professional practice.”
22
See 21 CFR 807.65(d).
8
generally used by other physicians (or other specially qualified persons), Dr. XYZ
would be considered a mobile medical app manufacturer;
· Persons who manufacture mobile medical apps solely for use in research, teaching, or
analysis and do not introduce such devices into commercial distribution. We note that
while persons conducting research using mobile medical apps involving human
subjects are exempt from registration and listing, they may instead be subject to
investigational device exemption regulations.23,24
IV. Scope
This guidance explains the FDA’s intentions to focus its oversight on a subset of software
functions. Mobile medical apps, as defined in Section III, include only those mobile apps that
meet the definition of a device and either are intended:
· to be used as an accessory to a regulated medical device; or

· to transform a mobile platform into a regulated medical device.
Appendix A provides examples of software functions, some of which are mobile apps, that
FDA does NOT consider to meet the definition of a device and, therefore, are NOT device
software functions or mobile medical apps for the purposes of this guidance.
Section V.B and Appendix B provide examples of software functions, some of which are
mobile apps, that MAY meet the definition of a device but for which the FDA intends to
exercise enforcement discretion because they pose a low risk to patients.25
This guidance does not address the approach for software that performs patient-specific
analysis to aid or support clinical decision-making.
FDA’s policies regarding accessories to medical devices are not unique to device software
functions and go beyond the scope of this guidance. Specifically this guidance does not
address FDA’s general approach for accessories to medical devices.
If you are developing a software function that meets the definition of a device (such as a
mobile medical app) with an entirely new intended use, we encourage you to contact FDA to
discuss what regulatory requirements may apply.
23
See 21 CFR 807.65(f).
24
See 21 CFR 812.1.
25
This indicates that for certain device software functions, such as those in Appendix B, the FDA intends not to
pursue enforcement action for violations of the FD&C Act and applicable regulations by a manufacturer of a
software function that meets the definition of a device in section 201(h) of the FD&C Act as specified in this
guidance. This does not constitute a change in the requirements of the FD&C Act or any applicable regulation.
9
V. Regulatory Approach for Device Software Functions

As described in this guidance, FDA intends to apply its regulatory oversight to only those
software functions that are medical devices and whose functionality could pose a risk to a
patient’s safety if the device were to not function as intended. This approach to overseeing
device software functions is consistent with our existing approach to overseeing medical
device functionality of a product and the risks it poses to patients regardless of the shape,
size, or the platform. The FDA believes that this subset of device software functions poses
the same or similar potential risks to the public health as currently regulated devices if they
fail to function as intended.
The FDA strongly recommends that manufacturers of all software and mobile apps that may
meet the definition of a device follow the Quality System26 regulation (that includes good
manufacturing practices) in the design and development of their device software functions,
and initiate prompt corrections to their devices, when appropriate, to prevent patient and user
harm.
For device software functions, manufacturers must meet the requirements associated with the
applicable device classification. If the device, on its own, falls within a medical device
classification, its manufacturer is subject to the requirements associated with that
classification. A device software function, like other devices, may be classified as class I
(general controls), class II (special controls in addition to general controls), or class III
(premarket approval).27
A. Device software functions: Subset of software

functions that are the focus of FDA’s regulatory
oversight
Software functions may take a number of forms, but it is important to note that the FDA
intends to apply its regulatory oversight to only the subset of software functions identified
below and in Appendix C. These software functions can transform a general-purpose
computing platform or mobile platform into a regulated medical device by using attachments,
display screens, sensors, or other such methods. Regardless of the mechanism behind the
transformation, FDA considers such software to be device software functions.
The following are software functions that FDA considers to be device software functions
subject to regulatory oversight:
26
See 21 CFR Part 820.
27
See footnotes 8 and 10.
10
1. Software functions that are an extension of one or more medical devices by

connecting28 to such device(s) for purposes of controlling29 the device(s) or
analyzing medical device data.
o Examples of software functions that control medical devices include: software

that provides the ability to control inflation and deflation of a blood pressure
cuff through a mobile platform and mobile apps that control the delivery of
insulin on an insulin pump by transmitting control signals to the pumps from
the mobile platform.
Device software functions of these types are considered accessories to the

connected device and are required to comply with the controls applicable to
that connected device. The FDA considers such device software functions to
extend the intended use and functionality of the connected medical device. As
a result, the device software function would be required to comply with the
regulations applicable to the connected medical device in order to address any
associated risks.
2. Software functions (typically, mobile apps) that transform the mobile platform
into a regulated medical device by using attachments, display screens, or sensors
or by including functionalities similar to those of currently regulated medical
devices. Software functions that use attachments, display screens, sensors or
other such similar components to transform a mobile platform into a regulated
medical device are required to comply with the device classification associated
with the transformed platform.
o Examples of these types of software functions include: a software function that

uses a mobile platform for medical device functions, such as attachment of a
blood glucose strip reader to a mobile platform to function as a glucose meter;
or attachment of electrocardiograph (ECG) electrodes to a mobile platform to
measure, store, and display ECG signals; a software function that uses the
built-in accelerometer on a mobile platform to collect motion information for
monitoring sleep apnea; a software function that uses sensors (internal or
external) on a mobile platform for creating electronic stethoscope function is
considered to transform the mobile platform into an electronic stethoscope;
manufacturers of such a mobile app are required to follow the requirements of
21 CFR 870.1875(b) (Electronic Stethoscope); and similarly a software
function that displays radiological images for diagnosis transforms the mobile
platform into a class II Picture Archiving and Communications System
(PACS) under 21 CFR 892.2050.
The FDA has cleared several mobile medical apps with attachments to a
mobile platform. Specifically, patient monitoring mobile apps that monitor a
28
To meet this criterion, the device software functions or mobile medical apps need not be physically connected
to the regulated medical device (i.e. the connection can be wired or wireless).
29
Controlling the intended use, function, modes, or energy source of the connected medical device.
11
patient for heart rate variability from a signal produced by an

electrocardiograph, vectorcardiograph, or blood pressure monitor are
classified as cardiac monitoring software under 21 CFR 870.2300 (Cardiac
monitor). Other mobile medical apps that use a hardware attachment or
interface to a monitoring system that have been cleared include an automatic
electronic blood pressure monitor under 21 CFR 870.1130 and a perinatal
monitoring system under 21 CFR 884.2740.
3. Software functions that become a regulated medical device by performing

patient-specific analysis and providing patient-specific diagnosis, or treatment
recommendations. These types of functions are similar to or perform the same
function as those types of software devices that have been previously cleared or
approved.
o Examples of software functions that perform sophisticated analysis or

interpret data (electronically collected or manually entered) from another
medical device include: software functions that use patient-specific parameters
and calculate dosage or create a dosage plan for radiation therapy; Computer
Aided Detection software (CAD) image processing software30; and radiation
therapy treatment planning software31. We believe that these types of software
present the same level of risk to patients regardless of the platform on which
they run.
The FDA encourages manufacturers of such device software functions that perform patient-
specific analysis to contact FDA to discuss what, if any, regulatory requirements may apply.
For additional examples see Appendix C.
B. Software functions for which FDA intends to

exercise enforcement discretion (meaning that
FDA does not intend to enforce requirements
under the FD&C Act)
FDA intends to exercise enforcement discretion for software functions that:
1. Help patients (i.e., users) self-manage their disease or conditions without providing
specific treatment or treatment suggestions; or
2. Automate simple tasks for health care providers.
Some software functions in the above categories and listed below may be considered device
software functions, and others might not. For these examples listed below that are devices,
FDA intends to exercise enforcement discretion because they pose a low risk to patients.
30
21 CFR 892.2050.
31
21 CFR 892.2050.
12
The following examples represent software functions for which the FDA intends to exercise
enforcement discretion:
3. Software functions that provide or facilitate supplemental clinical care, by

coaching or prompting, to help patients manage their health in their daily
environment – These are software functions that supplement32 professional clinical
care by facilitating behavioral change or coaching patients with specific diseases or
identifiable health conditions in their daily environment. Examples include:
o Software functions that coach patients with conditions such as cardiovascular

disease, hypertension, diabetes, or obesity, and promote strategies for
maintaining a healthy weight, getting optimal nutrition, exercising and staying
fit, managing salt intake, or adhering to pre-determined medication dosing
schedules33 by simple prompting.
4. Software functions that provide easy access to information related to patients’

health conditions or treatments (beyond providing an electronic “copy” of a
medical reference) – This includes software that provides contextually-relevant
information to users by matching patient-specific information (e.g., diagnosis,
treatments, allergies, signs, or symptoms) to reference information routinely used in
clinical practice34 (e.g., practice guidelines) to facilitate a user’s assessment of a
specific patient. Examples include:
o Software functions that use a patient’s diagnosis to provide a clinician with

best practice treatment guidelines for common illnesses or conditions such as
influenza; or
o Software functions that are drug-drug interaction or drug-allergy look-up
tools.
5. Software functions that are specifically marketed to help patients communicate

with healthcare providers by supplementing or augmenting the data or
information by capturing an image for patients to convey to their healthcare
providers about potential medical conditions – These products either pose little or
no risk, or are the sole responsibility of the health care providers who have experience
with them in medical applications. Examples include:
32
By this we mean that the app can be safely used by a patient without active oversight by a medical
professional and, when used for serious conditions necessitating professional medical care, use of the app is not
intended to replace or discourage seeking treatment from a health care provider.
33
We consider these device software functions to be “medication reminders – Product code NXQ” currently
defined as “A medication reminder is a device intended for medical purposes to provide alerts to patients or
health care providers for pre-determined medication dosing schedules. The device may incorporate wireless
communication.” The FDA intends to not enforce applicable regulatory requirements for this specific product
code (NXQ) identified under 21 CFR 890.5050 – Daily activity assist device.
34
The type of information provided is from authoritative medical sources, as recognized by the field or
discipline that is the subject of the software.
13
o Apps specifically intended for medical uses that utilize the mobile device’s
built-in camera or a connected camera for purposes of documenting or
transmitting pictures (e.g., photos of a patient’s skin lesions or wounds) to
supplement or augment what would otherwise be a verbal description in a
consultation between health care providers or between health care providers
and patients/caregivers.
6. Software functions that perform simple calculations routinely used in clinical

practice – These are software functions that are intended to provide a convenient way
for clinicians to perform various simple medical calculations taught in medical
schools35 and are routinely used in clinical practice. This software is generally
tailored for clinical use, but retains functionality that is similar to simple general-
purpose tools such as paper charts, spread sheets, timers, or generic mathematical
calculators. Examples of such general-purpose tools include medical calculators for:
o Body Mass Index (BMI);

o Total Body Water / Urea Volume of Distribution;
o Mean arterial pressure;
o Glascow Coma Scale score;
o APGAR score;
o NIH Stroke Scale; or
o Delivery date estimator.
See Appendix B for additional examples for the above categories.
VI. Regulatory Requirements

This guidance, including Appendix C and existing medical device regulatory classifications
in Appendix D, is intended to assist manufacturers in determining if the software
functionality meets the definition of a device and FDA’s expectations for that product.
Additional information can be found in “Device Advice: Classify Your Medical Device.36”
This section describes in greater detail the regulatory requirements applicable to device
software functions under this guidance (as described in Section V).
Manufacturers of device software functions are subject to the requirements described in the
applicable device classification regulation below. Depending on the classification and the
associated regulation for the device software function, manufacturers are required to follow
associated controls established by the regulation.
In general, the associated controls for each class of device are outlined below.
35
The types of information in these calculators are available in medical sources, which includes medical
textbooks used in the curriculum of accredited medical schools.
36
Available at https://www.fda.gov/medical-devices/overview-device-regulation/classify-your-medical-device.
14
Class I devices: General Controls, including:
· Establishment registration, and Medical Device listing (21 CFR Part 807);
· Quality System (QS) regulation (21 CFR Part 820);
· Labeling Requirements (21 CFR Part 801);
· Medical Device Reporting (21 CFR Part 803);
· Premarket Notification (21 CFR Part 807);
· Reporting Corrections and Removals (21 CFR Part 806); and
· Investigational Device Exemption (IDE) requirements for clinical studies of
investigational devices (21 CFR Part 812).
Class II devices: General Controls (as described for Class I), Special Controls, and (for most
Class II devices) Premarket Notification.
Class III devices: General Controls (as described for Class I), and Premarket Approval (21
CFR Part 814).
Appendix E provides a brief summary of the above requirements. Additional information is

available at https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-
assistance, under “Overview of Medical Device Regulation37” and “How to Study and
Market Your Device.38” If you need further assistance, you may contact the Division of
Industry and Consumer Education (DICE): Email: DICE@fda.hhs.gov; phone: 301-796-7100
or 800-638-2041.
37
Available at https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-
assistance/overview-device-regulation.
38
Available at https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/how-
study-and-market-your-device.
15
Appendix A Examples of Software Functions that are

NOT Medical Devices
This Appendix provides a representative list of software functionalities to illustrate the types
of software that could be used in a health care environment, in clinical care, or patient
management, but are not considered medical devices. Because these software functions are
not considered medical devices, FDA does not regulate them. The FDA understands that
there may be other unique and innovative software functions that may not be covered in this
list that may also constitute health care related software. This list is not exhaustive; it is only
intended to provide clarity and assistance in identifying when a software function is not
considered to be a medical device.
Specific examples of software functions that FDA does not consider to be devices and with
no regulatory requirements under the current laws administered by FDA include:
1. Software functions that are intended to provide access to electronic “copies”

(e.g., e-books, audio books) of medical textbooks or other reference materials
with generic text search capabilities – These are not devices because the software is
intended to be used as reference material and is not intended for use in the diagnosis
of disease or other conditions, or in the cure, mitigation, treatment, or prevention of
disease by facilitating a health professional’s assessment of a specific patient,
replacing the judgment of clinical personnel, or performing any clinical assessment.
Examples of these types of software functions include:
o Medical dictionaries;
o Electronic copies of medical textbooks or literature articles such as the
Physician’s Desk Reference or Diagnostic and Statistical Manual of Mental
Disorders (DSM);
o Library of clinical descriptions for diseases and conditions;
o Encyclopedia of first-aid or emergency care information;
o Medical abbreviations and definitions;
o Translations of medical terms across multiple languages.
2. Software functions that are intended for health care providers to use as
educational tools for medical training or to reinforce training previously
received – These may have more functionality than providing an electronic copy of
text (e.g., videos, interactive diagrams), but are not devices because they are intended
generally for user education and are not intended for use in the diagnosis of disease or
other conditions, or in the cure, mitigation, treatment, or prevention of disease by
facilitating a health professional’s assessment of a specific patient, replacing the
judgment of clinical personnel, or performing any clinical assessment. Examples of
these types of software functions include:
o Medical flash cards with medical images, pictures, graphs, etc.;

o Question/Answer quiz apps;
16
o Interactive anatomy diagrams or videos;

o Surgical training videos;
o Medical board certification or recertification preparation apps;
o Games that simulate various cardiac arrest scenarios to train health
professionals in advanced CPR skills.
3. Software functions that are intended for general patient education and facilitate
patient access to commonly used reference information – This software can be
patient-specific (i.e., filters information to patient-specific characteristics), but is
intended for increased patient awareness, education, and empowerment, and
ultimately supports patient-centered health care. These functions are not devices
because they are intended generally for patient education, and are not intended for use
in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or
prevention of disease by aiding clinical decision-making (i.e., to facilitate a health
professional’s assessment of a specific patient, replace the judgment of a health
professional, or perform any clinical assessment). Examples include software
functions that:
o Provide a portal for health care providers to distribute educational information

(e.g., interactive diagrams, useful links, and resources) to their patients
regarding their disease, condition, treatment, or up-coming procedure;
o Help guide patients to ask appropriate questions to their physician relevant to
their particular disease, condition, or concern;
o Provide information about gluten-free food products or restaurants;
o Help match patients with potentially appropriate clinical trials and facilitate
communication between the patient and clinical trial investigators;
o Provide tutorials or training videos on how to administer first-aid or CPR;
o Allow users to input pill shape, color, or imprint and displays pictures and
names of pills that match this description;
o Find the closest medical facilities and doctors to the user’s location;
o Provide lists of emergency hotlines and physician/nurse advice lines;
o Provide and compare costs of drugs and medical products at pharmacies in the
user’s location.
4. Software functions that automate general office operations in a health care

setting and are not intended for use in the diagnosis of disease or other conditions, or
in the cure, mitigation, treatment, or prevention of disease. Examples include
software functions that:
o Determine billing codes like ICD-9 (international statistical classification of

diseases);
o Enable insurance claims data collection and processing and other apps that are
similarly administrative in nature;
o Analyze insurance claims for fraud or abuse;
o Perform medical business accounting functions or track and trend billable
hours and procedures;
17
o Generate reminders for scheduled medical appointments or blood donation

appointments;
o Help patients track, review, and pay medical claims and bills online;
o Manage shifts for doctors;
o Manage or schedule hospital rooms or bed spaces;
o Provide wait times and electronic check-in for hospital emergency rooms and
urgent care facilities;
o Allow health care providers or staff in health care settings to process
payments (for example, using a HIPAA compliant app to process payments);
o Track or perform patient satisfaction survey after an encounter or a clinical
visit.
5. Software functions that are generic aids or general-purpose products – This

software is not considered a device because it is not intended for use in the diagnosis
of disease or other conditions, or in the cure, mitigation, treatment, or prevention of
disease. Examples include software functions that:
o Use the mobile platform as a magnifying glass (but are not specifically
intended for medical purposes39);
o Use the mobile platform for recording audio, note-taking, replaying audio
with amplification, or other similar functionalities;
o Allow patients or health care providers to interact through email, web-based
platforms, video, or other communication mechanisms (but are not
specifically intended for medical purposes);
o Provide maps and turn-by-turn directions to medical facilities;
o Allow health care providers to communicate in a secure and protected method
(for example using a HIPAA compliant app to send messages between health
care providers in a hospital).
6. Software functions that are intended for individuals to log, record, track,
evaluate, or make decisions or behavioral suggestions related to developing or
maintaining general fitness, health or wellness, such as those that:
o Provide tools to promote or encourage healthy eating, exercise, weight loss, or

other activities generally related to a healthy lifestyle or wellness;
o Provide dietary logs, calorie counters or make dietary suggestions;
o Provide meal planners and recipes;
o Track general daily activities or make exercise or posture suggestions;
o Track a normal baby’s sleeping and feeding habits;
o Actively monitor and trend exercise activity;
39
Medical purpose magnifiers are regulated either under 21 CFR 886.5840 – Magnifying spectacles (“devices
that consist of spectacle frames with convex lenses intended to be worn by a patient who has impaired vision to
enlarge images”), or under 21 CFR 886.5540 – Low-vision magnifiers (“a device that consists of a magnifying
lens intended for use by a patient who has impaired vision. The device may be held in the hand or attached to
spectacles”).
18
o Help healthy people track the quantity or quality of their normal sleep
patterns;
o Provide and track scores from mind-challenging games or generic “brain age”
tests;
o Provide daily motivational tips (e.g., via text or other types of messaging) to
reduce stress and promote a positive mental outlook;
o Use social gaming to encourage healthy lifestyle habits;
o Calculate calories burned in a workout.
7. Software functions that enable individuals to interact with EHR software

certified under the ONC Health IT Certification Program – These are software
functions that provide individuals with access to health record systems or enable them
to gain electronic access to health information stored within an EHR system.
Software functions that only allow individuals to view, transfer, or download EHR
data are also included in this category. These software functions are generally meant
to facilitate general patient health information management and health record-keeping
activities.
8. Software functions that provide patients with simple tools to organize and track their
health information;
9. Software functions that provide easy access to information related to patients’ health
conditions or treatments;
10. Software functions that provide patients with simple tools to organize and
record their health information – These are software functions that provide patients
with tools to organize and record health information without providing
recommendations to alter or change a previously prescribed treatment or therapy.
Examples include:
o Software functions that provide simple tools for patients with specific
conditions or chronic disease (e.g., obesity, anorexia, arthritis, diabetes, heart
disease) to record their events or measurements (e.g., blood pressure
measurements, drug intake times, diet, daily routine, or emotional state) and
share this information with their health care provider as part of a disease-
management plan.
11. Software functions that are specifically marketed to help patients document,
show, or communicate to providers regarding potential medical conditions –
These products either pose little or no risk, or are the sole responsibility of the health
care providers who have used them in medical applications. Examples include:
o Software that serves as a videoconferencing portal specifically intended for

medical use and to enhance communications between patients, health care
providers, and caregivers.
19
12. Software functions that enable, during an encounter, a health care provider to access
their patient’s personal health record (health information) that is hosted on a web-
based or other platform;
13. Software functions for health care providers certified under the ONC Health IT
Certification Program, such as those that help track or manage patient immunizations
by documenting the need for immunization, consent form, and immunization lot
number;
14. Software functions that help asthmatics record (i.e., collect and log) inhaler usage,
asthma episodes experienced, location of user at the time of an attack, or
environmental triggers of asthma attacks;
15. Software functions certified under the ONC Health IT Certification Program that
prompt the health care provider to manually enter symptomatic, behavioral, or
environmental information, the specifics of which are pre-defined by a health care
provider, and store the information for later review;
16. Software functions that record the clinical conversation a clinician has with a patient
and sends it (or a link) to the patient to access after the visit;
17. Software functions that allow a user to record (i.e., collect and log) data, such as
blood glucose, blood pressure, heart rate, weight, or other data from a device to
eventually share with a heath care provider, or upload it to an online (cloud) database,
or personal or electronic health record (PHR or EHR, respectively) that is certified
under the ONC Health IT Certification Program;
18. Software functions that enable patients or health care providers to interact with PHR
systems or EHR systems that are certified under the ONC Health IT Certification
Program;
19. Software functions that meet the definition of Non-Device-MDDS40 – These are
software functions that are solely intended to transfer, store, convert formats, and
display medical device data or results, without controlling or altering the functions or
parameters of any connected medical device. These include those software functions
that are used as a secondary display to a regulated medical device when these apps
are not intended to provide primary diagnosis or to be used to make treatment
decisions, or software functions that are used in connection with active patient
monitoring;
40
Non-Device-MDDS is considered to be software functions that are solely intended to transfer, store, convert
formats, and display medical device data or results, in accordance with the “Medical Device Data Systems,
Medical Image Storage Devices, and Medical Image Communications Devices” Guidance, available at
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/medical-device-data-systems-
medical-image-storage-devices-and-medical-image-communications-devices.
20
20. Software functions that display patient-specific medical device data – These
include software functions that display medical images directly from a Picture
Archiving and Communication System (PACS) server;
21. Software functions that are intended for transferring, storing, converting
formats or displaying clinical laboratory test or other device data and results,
findings by a health care professional with respect to such data and results, general
information about such findings, and general background information about such
laboratory test or other device, unless such function is intended to interpret or analyze
clinical laboratory test or other device data, results and findings.
o Software functions that transfer, store, convert formats, and display medical
device data without modifying the data and do not control or alter the
functions or parameters of any connected medical device (i.e., software
functions that meet the definition of Non-Device-MDDS);
o Software functions that meet the definition of Non-Device-MDDS and
connect to a nursing central station and display (but do not analyze or
interpret) medical device data to a physician’s mobile platform for review;
o Software functions that are not intended for diagnostic image review such as
image display for multidisciplinary patient management meetings (e.g.,
rounds) or patient consultation (and include a persistent on-screen notice, such
as “for informational purposes only and not intended for diagnostic use”).
21
Appendix B Examples of Software Functions for which

FDA intends to exercise enforcement discretion
This Appendix provides examples of software functions that MAY meet the definition of
medical device but for which FDA intends to exercise enforcement discretion. These
software functions may be intended for use in the diagnosis of disease or other conditions, or
in the cure, mitigation, treatment, or prevention of disease. Even though this software MAY
meet the definition of medical device, FDA intends to exercise enforcement discretion for
these types of software functions because they pose lower risk to the public.
The FDA understands that there may be other unique and innovative software functions that
may not be covered in this list that may also constitute health care related software. This list
is not exhaustive; it is only intended to provide clarity and assistance in identifying the
software functions that will not be subject to regulatory requirements at this time.
1. Software functions that help patients with diagnosed psychiatric conditions (e.g.,
post-traumatic stress disorder (PTSD), depression, anxiety, obsessive compulsive
disorder) maintain their behavioral coping skills by providing a “Skill of the Day”
behavioral technique or audio messages that the user can access when experiencing
increased anxiety;
2. Software functions that provide periodic educational information, reminders, or

motivational guidance to smokers trying to quit, patients recovering from addiction,
or pregnant women;
3. Mobile apps that use GPS location information to alert asthmatics of environmental
conditions that may cause asthma symptoms or alert an addiction patient (substance
abusers) when near a pre-identified, high-risk location;
4. Software functions that use video and video games to motivate patients to do their
physical therapy exercises at home;
5. Software functions that prompt a user to enter which herb and drug they would like to
take concurrently and provide information about whether interactions have been seen
in the literature and a summary of what type of interaction was reported;
6. Software functions that use patient characteristics such as age, sex, and behavioral
risk factors to provide patient-specific screening, counseling, and preventive
recommendations from well-known and established authorities;
7. Software functions that use a checklist of common signs and symptoms to provide a
list of possible medical conditions and advice on when to consult a health care
provider;
22
8. Software functions that guide a user through a questionnaire of signs and symptoms
to provide a recommendation for the type of health care facility most appropriate to
their needs;
9. Software functions that are intended to allow a user to initiate a pre-specified nurse
call or emergency call using broadband or cellular phone technology;
10. Software functions that enable a patient or caregiver to create and send an alert or
general emergency notification to first responders;
11. Software functions that keep track of medications and provide user-configured
reminders for improved medication adherence;
12. Software functions that provide patients a portal into their own health information,
such as access to information captured during a previous clinical visit or historical
trending and comparison of vital signs (e.g., body temperature, heart rate, blood
pressure, or respiratory rate);
13. Software functions that aggregate and display trends in personal health incidents (e.g.,
hospitalization rates or alert notification rates);
14. Software functions allow a user to collect (electronically or manually entered) blood
pressure data and share this data through e-mail, track and trend it, or upload it to a
personal or electronic health record;
15. Software functions that provide oral health reminders or tracking tools for users with
gum disease;
16. Software functions that provide prediabetes patients with guidance or tools to help
them develop better eating habits or increase physical activity;
17. Software functions that display, at opportune times, images or other messages for a
substance abuser who wants to stop addictive behavior;
18. Software funtions that provide drug-drug interactions and relevant safety information
(side effects, drug interactions, active ingredient) as a report based on demographic
data (age, gender), clinical information (current diagnosis), and current medications.
23
Appendix C Examples of Software Functions that are the

focus of FDA’s regulatory oversight (Device Software
Functions and Mobile Medical Apps)
This Appendix provides examples of software functions that are considered medical devices
(i.e., device software functions), and on which FDA will focus its regulatory oversight. This
software meets the definition of a device under section 201(h) of the FD&C Act and its
functionality poses a risk to a patient’s safety if the software were to not function as intended.
Each example below provides a list of possible relevant product code(s) and/or regulation
number.
FDA also encourages device software manufacturers to search FDA’s public databases, such
as the “Product Classification41” database and the “510(k) Premarket Notification42”
database, to determine the level of regulation for a given device and for the most up-to-date
information about the relevant regulatory requirements.
Software functions (typically mobile apps) that transform a mobile platform into a
regulated medical device and therefore are the focus of FDA’s regulatory oversight:
These mobile apps use a mobile platform’s built-in features such as light, vibrations, camera,
or other similar sources to perform medical device functions (e.g., mobile medical apps that
are used by a licensed practitioner to diagnose or treat a disease). Possible product codes:
Varies depending on the intended use and software function; see additional examples below.
· Software functions that use a sensor or lead that is connected to a mobile platform to
measure and display the electrical signal produced by the heart (electrocardiograph or
ECG). Possible product code(s): DPS, MLC, OEY (21 CFR 870.2340), MLO, MWJ
(21 CFR 870.2800).
· Software functions that use a sensor or electrode attached to the mobile platform or
tools within the mobile platform itself (e.g., microphone and speaker) to
electronically amplify and “project sounds associated with the heart, arteries and
veins and other internal organs” (i.e., an electronic stethoscope). Possible product
code: DQD (21 CFR 870.1875(b)).
· Software functions that use a sensor or electrode attached to the mobile platform or
tools within the mobile platform itself (e.g., accelerometer) to measure physiological
parameters during cardiopulmonary resuscitation (CPR) and give feedback about the
quality of CPR being delivered. Possible product code: LIX (21 CFR 870.5200).
· Software functions that use a sensor attached to the mobile platform or tools within
the mobile platform itself to record, view, or analyze eye movements for use in the
41
Available at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/classification.cfm.
42
Available at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPMN/pmn.cfm.
24
diagnosis of balance disorders (i.e., nystagmograph). Possible product code: GWN

(21 CFR 882.1460).
· Software functions that use tools within the mobile platform (e.g., speaker) to
produce controlled levels of test tones and signals intended for use in conducting
diagnostic hearing evaluations and assisting in the diagnosis of possible otologic
disorders (i.e., an audiometer). Possible product code: EWO (21 CFR 874.1050).
the mobile platform itself (e.g., accelerometer) to measure the degree of tremor
caused by certain diseases (i.e., a tremor transducer). Possible product code: GYD (21
CFR 882.1950).
the mobile platform itself (e.g., accelerometer, microphone) to measure physiological
parameters (e.g., limb movement, electrical activity of the brain (EEG)) during sleep
and are intended for use in diagnosis of specific diseases or conditions such as sleep
apnea. Possible product code(s): OLV (21 CFR 882.1400), LEL, MNR (21 CFR
868.2375), FLS, NPF (21 CFR 868.2377).
· Software functions that use an attachment to the mobile platform to measure blood
oxygen saturation for diagnosis of specific disease or condition. Possible product
code(s): DQA, NLF, MUD, NMD (21 CFR 870.2700) or DPZ (21 CFR 870.2710).
· Software functions that present donor history questions to a potential blood donor and
record and/or transmit the responses to those questions for a blood collection facility
to use in determining blood donor eligibility prior to collection of blood or blood
components. Possible product code: MMH (21 CFR 864.9165).
· Software functions that use an attachment to the mobile platform to measure blood
glucose levels. Possible product code: NBW (21 CFR 862.1345).
· Software functions that use that use an attachment to the mobile platform (e.g., light
source, laser) to treat acne, reduce wrinkles, or remove hair. Possible product code:
OLP, OHT, OHS (21 CFR 878.4810), OZC (21 CFR 890.5740).
· Software functions that use a microphone or speaker within a mobile platform to

serve as a audiometer to allow health care providers to determine hearing loss at
different frequencies. Possible product code: EWO (21 CFR 874.1050).
· Software functions that analyze an image of a skin lesion using mathematical

algorithms, such as fractal analysis, and provide the user with an assessment of the
risk of the lesion.
Software functions that connect to an existing device type for purposes of controlling its
operation, function, or energy source and therefore are the focus of FDA’s regulatory
25
oversight: These software functions are those that control the operation or function (e.g.,
changes settings) of an implantable or body worn medical device. Possible product codes:
Varies depending on the intended use and function of the parent medical device; see
additional examples below.
· Software functions that alter the function or settings of an infusion pump. Possible
product codes: MEB, FRN, LZH, LZG, OPP, MEA (21 CFR 880.5725), FIH (21
CFR 876.5820), LKK.
· Software functions that act as wireless remote controls or synchronization devices for
computed tomography (CT) or X-Ray machines. Possible product code: JAK (21
CFR 892.1750), IZL (21 CFR 892.1720), KPR (21 CFR 892.1680).
· Software functions that control or change settings of an implantable neuromuscular

stimulator. Possible product code(s): GZC (21 CFR 882.5860).
· Software functions that calibrate, control, or change settings of a cochlear implant.

Possible product code(s): MCM.
· Software functions that control the inflation or deflation of a blood-pressure cuff.

Possible product code: DSJ (21 CFR 870.1100), DSK (21 CFR 870.1110), DXN (21
CFR 870.1130).
· Software functions that are used to calibrate hearing aids and assess the
electroacoustic frequency and sound intensity characteristics emanating from a
hearing aid, master hearing aid, group hearing aid or group auditory trainer. Possible
product code ETW (21 CFR 874.3310).
Software functions that are used in active patient monitoring to analyze patient-specific
medical device data and therefore are the focus of FDA’s regulatory oversight:
· Software functions that acquire or process physiological signals that connect to

bedside (or cardiac) monitors for active patient monitoring. Possible product code(s):
DSI, MHX, MLD (21 CFR 870.1025), DRT, MWI, MSX (21 CFR 870.2300).
· Software functions that process uterine contraction and fetal heart rate data for remote
monitoring of labor progress. Possible product code(s): HGM (21 CFR 884.2740).
· Software functions that are intended to process images for diagnostic review may be
regulated as a picture archiving and communications system. Possible product
code(s): LLZ (21 CFR 892.2050).
26
Appendix D Examples of current regulations

This Appendix provides additional examples of classifications for regulated medical devices,
the Class according to which they are regulated, and their regulation numbers as listed in
Title 21 of the Code of Federal Regulations (CFR). This list is intended as a starting point for
software manufacturers to assist them in identifying regulated medical devices.
In the table below -- Regulation Number 8xx.yyyy refers to regulation 21 CFR 8xx.yyyy;
Device Class 1, 2, 3 – indicates the classification that applies to the device; Submission Type
“510(k) exempt,” – means that the manufacturer is not required to submit a premarket
notification (i.e., 510(k)) prior to marketing the device. However, the 510(k) exemption may
be subject to certain limitations. Submission type “510(k),” – means that the manufacturer is
typically required to submit a premarket notification.
Regulation Regulation Example Device(s) Device Submission Type

number Description within the Regulation Class
(and current product
code)
862.1345 Glucose test system System, Test, Blood 2 510(k)
Glucose, Over The
Counter (NBW)
862.2100 Calculator/data Digital Image, Storage 1 510(k) exempt
processing module for And Communications,
clinical use Non-Diagnostic,
Laboratory Information
System (NVV)
864.9165 Blood Establishment Blood Establishment 2 510(k)
Computer Software Computer Software
and Accessories (BECS), Blood
Transfusion Management,
Blood Donation
Management
868.1850 Monitoring spirometer Spirometer, Monitoring 2 510(k)
(W/Wo Alarm) (BZK)
868.1920 Esophageal stethoscope Stethoscope, Esophageal, 2 510(k)
with electrical With Electrical
conductors Conductors (BZT)
868.2375 Breathing Frequency Ventilatory Effort 2 510(k)
Monitor Recorder (MNR)
868.2377 Apnea Monitor Monitor, Apnea, Home 2 510(k)
Use (NPF)
870.1025 Arrhythmia detector Detector and Alarm, 2 510(k)
and alarm (including Arrhythmia (DSI)
ST-segment
measurement and
alarm)
870.1110 Blood-Pressure Computer, Blood- 2 510(k)
Computer Pressure (DSK)
27

code)
870.1130 Noninvasive blood System, Measurement, 2 510(k)
pressure measurement Blood-Pressure, Non-
system Invasive (DXN)
870.1875(b) Stethoscope Lung Sound Monitor 2 510(k) exempt
(OCR)
Stethoscope, Electronic 2 510(k)
(DQD)
870.2300 Cardiac Monitor Monitor, Cardiac (Incl. 2 510(k)
(including Cardiotachometer & Rate
cardiotachometer and Alarm) (DRT)
rate alarm) Monitor, Physiological, 2 510(k)
Patient (Without
Arrhythmia Detection Or
Alarms) (MWI)
System, Network And 2 510(k)
Communication,
Physiological Monitors
(MSX)
870.2340 Electrocardiograph Monitor, St Segment 2 510(k)
(MLC)
Single Lead Over-the- 2 510(k)
Counter
Electrocardiograph
(OEY)
870.2700 Oximeter Oximeter (DQA) 2 510(k)
870.2770 Impedance Analyzer, Body 2 510(k)
plethysmograph Composition (MNW)
870.2800 Medical magnetic tape Electrocardiograph, 2 510(k)
recorder Ambulatory, With
Analysis Algorithm
(MLO)
Recorder, Event, 2 510(k)
Implantable Cardiac,
(Without Arrhythmia
Detection) (MXC)
874.1050 Audiometer Audiometer (EWO) 2 510(k) exempt
874.3400 Tinnitus masker Masker, Tinnitus (KLW) 2 510(k)
874.4770 Otoscope Otoscope (ERA) 1 510(k) exempt
876.1500 Endoscope and Endoscopic Video 2 510(k)
accessories Imaging
System/Component,
Gastroenterology-Urology
(FET)
876.1725 Gastrointestinal Recorder, External, 2 510(k)
motility monitoring Pressure, Amplifier &
system Transducer (FES)
28

code)
878.4160 Surgical camera and Camera, Cine, 1 510(k) exempt
accessories Microsurgical, With
Audio (FWK)
Camera, Still, 1 510(k) exempt
Microsurgical (FTH)
Camera, Television, 1 510(k) exempt
Endoscopic, With Audio
(FWG)
878.4810 Laser surgical Light Based Over The 2 510(k)
instrument for use in Counter Wrinkle
general and plastic Reduction (OHS)
surgery and in Over-The-Counter 2 510(k)
dermatology Powered Light Based
Laser For Acne (OLP)
880.2400 Bed-patient monitor Monitor, Bed Patient 1 510(k) exempt
(KMI)
880.2700 Stand-on patient scale Scale, Stand-On, Patient 1 510(k) exempt
(FRI)
880.2910 Clinical electronic Thermometer, Electronic, 2 510(k)
thermometer Clinical (FLL)
880.5580 Acupuncture needle Locator, Acupuncture 2 510(k) exempt
Point (BWJ)
880.6350 Battery-powered Light, Examination, 1 510(k) exempt
medical examination Medical, Battery Powered
light (KYT)
882.1400 Electroencephalograph Full-montage 2 510(k)
electroencephalograph
(GWQ)
Standard polysomnograph 2 510(k)
with
electroencephalograph
(OLV)
882.1550 Nerve conduction Device, Nerve conduction 2 510(k)
velocity measurement velocity measurement
device (JXE)
882.1620 Intracranial pressure Device, Monitoring, 2 510(k)
monitoring device Intracranial pressure
(GWM)
882.1890 Evoked response Stimulator, Photic, 2 510(k)
photic stimulator Evoked response (GWE)
882.1900 Evoked response Stimulator, Auditory, 2 510(k)
auditory stimulator Evoked response (GWJ)
882.1950 Tremor transducer Transducer, Tremor 2 510(k)
(GYD)
884.2730 Home uterine activity Monitor, Heart Rate, 2 510(k)
monitor Fetal, Non-Stress Test
(Home Use) (MOH)
884.2740 Perinatal monitoring System, Monitoring, 2 510(k)
system and accessories Perinatal (HGM)
29

code)
884.2800 Computerized labor System, Monitoring, For 2 510(k)
monitoring system Progress Of Labor (NPB)
884.2900 Fetal stethoscope Stethoscope, Fetal (HGN) 1 510(k) exempt
884.6120 Assisted reproductive Accessories, Assisted 2 510(k)
accessories Reproduction (MQG)
884.6190 Assisted reproductive Microscope And 1 510(k) exempt
microscopes and Microscope Accessories,
microscope accessories Reproduction, Assisted
(MTX)
886.1510 Eye movement monitor Monitor, Eye Movement, 2 510(k)
Diagnostic (HMC)
886.1570 Ophthalmoscope Ophthalmoscope, Battery- 2 510(k) exempt
powered (HLJ)
886.1930 Tonometer and Tonograph (HPK) 2 510(k)
accessories
886.5540 Low-vision magnifier Magnifier, Hand-Held, 1 510(k) exempt
Low-Vision (HJF)
Spectacle Microscope, 1 510(k) exempt
Low-Vision (HKC)
892.1560 Ultrasonic pulsed echo System, Imaging, Optical 2 510(k)
imaging system Coherence Tomography
(Oct) (NQQ)
892.2030 Medical image Digitizer, Image, 2 510(k) exempt
digitizer Radiological (LMA)
Digitizer, Images, 2 510(k) exempt
Ophthalmic (NFH)
892.2050 Picture archiving and System, Image 2 510(k)
communications Processing, Radiological
system (LLZ)
System, Image 2 510(k)
Management, Opthalmic
(NFJ)
30
Appendix E Brief description of certain device regulatory

requirements
This Appendix provides a high level description of certain regulatory requirements for
medical devices, including device software functions. The FDA has additional resources and
publications online that describe these and other requirements in detail.
1. Establishment Registration and Medical Device Listing
Under 21 CFR Part 807, manufacturers of medical devices are required to annually register
their establishments43 with FDA and provide a list of the devices they market. The
registration and listing requirement is a means of keeping FDA advised of who is
manufacturing devices, and of the types of devices an establishment is manufacturing.
Medical device manufacturers are required to register their establishments with FDA and to
list44 by identifying to FDA the devices they are marketing.
Additional information can be found in “Device Advice: Device Registration and Listing.45”
If you need further assistance, you may contact the Division of Risk Management
Operations, Regulatory Policy and Systems Branch: Email: reglist@fda.hhs.gov, phone: 301-
796-7400. Assistance is also available from, Division of Industry and Consumer Education
(DICE): Email: DICE@fda.hhs.gov, phone: 301-796-7100 or 800-638-2041.
2. Investigational Device Exemption (IDE) requirements
An IDE allows an investigational device to be used in a clinical study in order to collect

safety and effectiveness data required to support a Premarket Approval (PMA) application or
a Premarket Notification 510(k) submission to FDA. Clinical studies with devices of
significant risk must be approved by FDA and by an Institutional Review Board (IRB) before
the study can begin. Studies with devices of non-significant risk must be approved by the
IRB only before the study can begin.
Medical device manufacturers who are creating software with novel technologies are
encouraged to engage in early collaboration meetings with the FDA to receive
recommendations for testing and development of those devices requiring clinical
investigations to support marketing.
43
Under 21 CFR 807.3(c), “Establishment” is defined as “a place of business under one management at one
general physical location at which a device is manufactured, assembled, or otherwise processed.”
44
45
Available at https://www.fda.gov/medical-devices/how-study-and-market-your-device/device-registration-
and-listing.
31
Additional information about these meetings is described in guidance issued on February 28,
2001: “Early Collaboration Meetings Under the FDA Modernization Act (FDAMA); Final
Guidance for Industry and for CDRH Staff.46”
Further information regarding the investigational device exemption can be found in “Device
Advice: Investigational Device Exemption.47”
3. Labeling requirements
Medical device manufacturers are required to comply with applicable labeling regulations
found in 21 CFR Part 801 for medical devices and 21 CFR Part 809 for in vitro diagnostic
products.
4. Premarket submission for approval or clearance
Medical device manufacturers should identify the current classification covering their device.
Manufacturers are required to prepare and submit to the FDA an appropriate premarket
submission, as required for their device classification.
Additional information can be found in “Device Advice: Device Registration and Listing.48”
5. Quality System Regulation (QS Regulation)
Medical device manufacturers are required to comply with the QS regulation.49 The QS
regulation does not prescribe in detail how a manufacturer must produce a specific device,
but provides a framework for all manufacturers to develop and follow to help ensure that
their products consistently meet applicable requirements and specifications. As part of this
framework, manufacturers are required to develop requirements for their products that will
result in devices that are safe and effective, and to establish methods and procedures to
design, produce, and distribute their devices.
Furthermore, manufacturers are required, as part of the QS regulation (21 CFR 820.30), to
appropriately verify and validate their device software functions along with the computing
platform to ensure safe and effective operation of the device.
Manufacturers are required to ensure that adequate controls and processes are in place
through purchasing controls to ensure safe distribution, installation, and operation of the
device software function.
46
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/early-collaboration-
meetings-under-fda-modernization-act-fdama-final-guidance-industry-and-cdrh.
47
Available at https://www.fda.gov/medical-devices/how-study-and-market-your-device/device-advice-
investigational-device-exemption-ide.
48
Available at https://www.fda.gov/medical-devices/how-study-and-market-your-device/device-registration-
and-listing.
49
32
Additional information regarding the QS regulation and can be found at “Quality System
(QS) Regulation/Medical Device Good Manufacturing Practices.50”
6. Medical Device Reporting (MDR) (Adverse event reporting)
The Medical Device Reporting (MDR) regulation requires manufacturers and importers of
medical devices to submit reports to the FDA whenever they receive or otherwise become
aware of information, from any source, that reasonably suggests that a device they market
may have caused or contributed to a death or serious injury, or has malfunctioned and the
device or a similar device that they market would be likely to cause or contribute to a
reportable death or serious injury if the malfunction were to recur.51 MDR requires medical
device manufacturers to:
· Submit MDR reportable events involving their medical devices as described in 21

CFR 803.10(c) and 803.50;
· Submit 5-day reports as described in 21 CFR 803.53;
· Submit supplemental reports as described in 21 CFR 803.56;
· Develop, maintain, and implement written procedures for the identification and
evaluation of all medical device events to determine whether the event is MDR
reportable as described in 21 CFR 803.17;
· Conduct an investigation of each event and evaluate the cause of the event as
described in 21 CFR 803.50(b)(3); and
· Establish and maintain complete files for all complaints concerning adverse medical
device events as described in 21 CFR 803.18.
The MDR report (FDA Form 3500A) must contain all the information described in 21 CFR
803.52 that is reasonably known to the manufacturer. Information reasonably known includes
any information that:
· Can be obtained by contacting a user facility, importer, or other initial reporter;

· Is in the possession of the manufacturer; or
· Can be obtained by analysis, testing, or other evaluation of the device.
For additional instructions on how to complete the 3500A form, refer to the document titled
“Instructions for Completing Form FDA 3500A.52”
For additional guidance on the MDR regulation and the reporting requirements, refer to the
document titled “Medical Device Reporting for Manufacturers.53”
50
Available at https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-system-qs-
regulationmedical-device-good-manufacturing-practices.
51
52
Available at https://www.fda.gov/safety/forms-reporting-fda/instructions-completing-form-fda-3500.
53
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/medical-device-
reporting-manufacturers.
33
For Questions about Medical Device Reporting, including interpretation of MDR policy:
· Call: (301) 796-6670 (voice)

· Email: RSMB@fda.hhs.gov
· Mail: Food and Drug Administration, Center for Devices and Radiological Health,
Reporting Systems Monitoring Branch, 10903 New Hampshire Avenue, WO Bldg.
66, Room 3217, Silver Spring, MD 20993-0002
7. Correcting Problems
A medical device manufacturer may voluntarily take action at any time or may be requested
to take action by the FDA to correct problems. Voluntary action is usually taken by device
manufacturers. Examples of the types of actions that a device manufacturer may be requested
to take include, but are not limited to:
· Inspecting the device for problems;

· Repairing the device;
· Adjusting settings on the device; and
· Upgrading software to reduce risk from a “bug” or unintended response.
Under certain circumstances, FDA may initiate a request that a manufacturer address a
problem with a device through other means, including by removal of the product from the
market. When recommending corrective action, the FDA intends to take into account the
essential role that certain device software functions take as an integral part of a larger patient
care system.
Reporting Corrections to FDA:
In accordance with 21 CFR 806.10, medical device manufacturers are required to promptly
report, within 10 working days from the time the correction is initiated, to the FDA certain
actions concerning device corrections and removals. Specifically, medical device
manufacturers are required to report to FDA any corrections made to a device to reduce a risk
to health posed by the device or to remedy a violation of the FD&C Act caused by the device
that may present a risk to health.
The reporting requirement does not extend to all modifications to devices. For example,
certain actions that would improve the quality of a mobile medical app but that would not
reduce a risk to health posed by the mobile medical app or remedy a violation of the FD&C
Act are not required to be reported under 21 CFR 806.1(b).54 If there is not a "risk to health"
54
Under 21 CFR 806.1(b), the following actions are exempt from the reporting requirements of Part 806:
(1) Actions taken by device manufacturers or importers to improve the performance or quality of a device but
that do not reduce a risk to health posed by the device or remedy a violation of the act caused by the device.
(2) Market withdrawals as defined in 21 CFR 806.2(h).
(3) Routine servicing as defined in 21 CFR 806.2(k).
(4) Stock recoveries as defined in 21 CFR 806.2(l).
34
involved, a report to FDA is not required, but the device manufacturer must keep a record of
the correction. An example of such action taken by the manufacturer could be changes made
to correct a defect that creates a nuisance for the user but does not present a risk to the health
of the user or patient.
More information about reporting requirements under 21 CFR Part 806 is available in
“Device Advice: Recalls, Corrections, and Removals.55”
55
Available at https://www.fda.gov/medical-devices/postmarket-requirements-devices/recalls-corrections-and-
removals-devices.
35
Appendix F Frequently Asked Questions (FAQs)

1) I have a software function that is not identified in this guidance. What is the best
way to get additional information from the FDA about my product?
Answer: FDA recognizes that this guidance does not describe all types of software used in
health care. Some manufacturers may be unsure whether their software function is
considered a medical device that is subject to regulatory oversight, or whether their medical
device could be under FDA’s intent to exercise enforcement discretion. If the device is
subject to regulatory oversight, manufacturers may have questions about which regulatory
requirements are applicable to their software function.
After reviewing this guidance, FDA encourages software manufacturers to contact the
Agency to obtain more information using one of the following ways:
- Phone or e-mail – For information about regulatory requirements, contact the Division of
Industry and Consumer Education (DICE). Email: DICE@fda.hhs.gov; phone: 301-796-
7100 or 800-638-2041.
For information about whether your software or mobile app is considered a medical
device, contact digitalhealth@fda.hhs.gov.
If your question relates to apps used in blood establishments or another area of CBER
regulation, contact the Office of Communication, Outreach and Development, Center for
Biologics Evaluation and Research, 10903 New Hampshire Ave., Bldg. 71, Room 3128,
Silver Spring; e-mail: ocod@fda.hhs.gov; phone: 1-800-835-4709 or 240-402-7800.
- Online – The FDA has several resources and publications online that describe various
regulatory requirements in detail. FDA’s “Device Advice56” website and online courses
at “CDRH Learn57” are a good place to start. Other sections in this guidance provide links
to more detailed information related to more specific topics.
- Letter – For written feedback about the classification and the regulatory requirements that
may be applicable to a device software function, manufacturers should use the 513(g)
process. Specifically, a manufacturer should submit the following for a 513(g)
submission:
· User fee;
· Cover letter;
· Description of the software;
· Description of what the software is to be used for; and
· Any proposed labeling or promotional material for the software and, as
applicable, any labeling or promotional material of a similar, legally marketed
device, if available.
56
Available at https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance.
57
Available at https://www.fda.gov/training-and-continuing-education/cdrh-learn.
36
FDA will generally issue a response to the 513(g), in the form of a confidential letter to the
manufacturer, within 60 days of receipt of the request for information. For more specific
information about what to include in a 513(g) and where to send it, refer to FDA’s guidance
document titled “FDA and Industry Procedures for Section 513(g) Requests for Information
Contains Nonbinding Recommendations Under the Federal Food, Drug, and Cosmetic
Act.58” For more information about 513(g) user fees, refer to FDA’s guidance document
titled “User Fees for 513(g) Requests for Information.59”
2) Why does FDA recommend that manufacturers follow the Quality System (QS)
regulation for those software that MAY be devices and could be device software
functions but for which FDA intends to exercise enforcement discretion?
Answer: FDA believes all manufacturers of medical device software should have in place an
adequate quality management system that helps ensure that their products consistently meet
applicable requirements and specifications and can support the software throughout its total
life cycle. Adequate quality management systems incorporate appropriate risk management
strategies, good design practices, adequate verification and validation, and appropriate
methods to correct and prevent risks to patients and adverse events that may arise from the
use of the product. All of these elements are part of FDA’s QS regulation.
3) Is FDA’s QS regulation similar to software development practices I already use?
Answer: Most likely. Though not all of the principles in the QS regulation are applicable to
the development and manufacture of quality device software functions,60 the majority of
them are applicable and are consistent with commonly used and accepted good software
development practices, such as those from the Institute of Electrical and Electronics
Engineers’ (IEEE), Software Engineering Body of Knowledge (SWEBOK), and Carnegie
Mellon Software Engineering Institute’s Capability Maturity Model Integration (CMMI)
methods.
The FDA’s approach to QS regulation is also harmonized with certain international standards
such as ISO 9001 and ISO 13485.61 Similar to these international standards, the QS
regulation does not prescribe in detail how a manufacturer must produce a specific device,
but provides a framework for all manufacturers to develop and follow to help ensure that
their products consistently meet applicable requirements and specifications. The QS
regulation can apply to and be scaled for any size manufacturer and any type of product. It
58
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/fda-and-industry-
procedures-section-513g-requests-information-under-federal-food-drug-and-cosmetic.
59
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/user-fees-513g-
requests-information.
60
Certain portions of the QS regulation that apply to medical device hardware (such as the production and
process controls outlined in 21 CFR 820.70) may not clearly apply to device software functions.
61
ISO 9001 Quality management systems – Requirements and ISO 13485 Medical devices – Quality
management systems – Requirements for regulatory purposes.
37
also allows for a manufacturer to choose those requirements most appropriate for its given
device and manufacturing process.62
4) What are some examples of parts of the QS regulation that are of particular
importance to device software functions and where can I find more information
about them?
Answer: Though not a complete list, some examples of principles within the QS regulation
that are relevant to all device manufacturers include risk assessment and management, design
controls, and corrective and preventive actions. Risk assessment and management is a critical
part of good quality management systems. Good design practices are important to the
development and manufacture of safe medical devices. It is also important for manufacturers
to have procedures in place to identify, analyze, correct, and prevent software-related causes
of patient or user harm. References related to these examples are provided in Appendix E of
this guidance. Additional references about these principles that manufacturers may find
useful include the following:
FDA’s “Design Control Guidance for Medical Device Manufacturers,” available at

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-control-
guidance-medical-device-manufacturers.
FDA’s “General Principles of Software Validation” guidance, available at

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-
principles-software-validation.
5) Do all the device software function manufacturers have to submit a premarket

submission and receive FDA clearance or approval before marketing?
Answer: No, not all manufacturers have to submit a premarket submission (i.e., a 510(k) or
PMA) prior to marketing their device software function. This determination depends on the
classification of the device. Manufacturers of devices that are exempt from 510(k) or PMA
requirements do not have to file a submission with FDA prior to marketing their device. For
example, the majority of class I devices are exempt from the premarket submission
requirements and are subject to the least regulatory control.
Regardless of whether medical devices are subject to the premarket submission requirements,
most medical devices (including Class I devices) have to comply with other basic regulatory
requirements that are called “General Controls.” More information about what “General
Controls” are and what a medical device manufacturer should do to comply with these
requirements, can be found in “Device Advice: General Controls for Medical Devices” and
“Regulatory Controls.63”
62
See 21 CFR 820.1 (stating “if a manufacturer engages in only some operations subject to the requirements in
this part, and not in others, that manufacturer need only comply with those requirements applicable to the
operations in which it is engaged.”).
63
Available at https://www.fda.gov/medical-devices/regulatory-controls/general-controls-medical-devices and
at https://www.fda.gov/medical-devices/overview-device-regulation/regulatory-controls.
38
6) Some FDA classifications state they are “510(k) exempt.” What does 510(k)
exempt mean and how do I know if it applies to my product?
Answer: If a classification states the device type is “510(k) exempt,” this means that the
manufacturer is not required to submit a premarket notification (i.e., a 510(k)) prior to
marketing the device. However, the 510(k) exemption may be subject to certain limitations.
Manufacturers are encouraged to confirm the device’s exempt status and any limitations to
that status that may apply in accordance with 21 CFR Parts 862-892. Additional information
about 510(k) exempt devices can be found at:
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpcd/315.cfm.
7) If a 510(k) is required for my device software function, what type of software

documentation does FDA recommend I include in the submission?
Answer: FDA’s recommendations for the software-related documentation that you provide
in your premarket submission are addressed in detail in the FDA’s “Guidance for the Content
of Premarket Submissions for Software Contained in Medical Devices.64”
If the device software function uses off-the-shelf software, manufacturers should also refer to
FDA’s “Guidance for Industry, FDA Reviewers, and Compliance on Off-the-Shelf Software
Use in Medical Devices.65”
8) I am a medical device manufacturer and making my product labeling available

electronically using a mobile app. Is my app considered a mobile medical app?
Answer: Mobile apps that provide electronic access and are intended for use as a digital
version of medical device labeling or instructions for use are not considered a medical device
on their own and therefore are not considered mobile medical apps. These are apps from a
device manufacturer that provide information to support the company’s own device.
Examples include apps that provide an electronic copy of cleared or approved medical device
labeling or apps that provide video instruction for how to use a medical device. These types
of apps are not considered devices within themselves, but instead are considered part of the
medical device labeling and are subject to the regulatory labeling requirements relevant to
that particular product.
9) Is an electronic method of collecting clinical investigations, for example through

a mobile app, considered a device software function, and if so, what
requirements apply?
64
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/guidance-content-
premarket-submissions-software-contained-medical-devices.
65
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-
medical-devices.
39
Answer: Software used for data collection in clinical studies (such as electronic Patient
Reported Outcomes (ePRO) apps) is not considered on its own to be a device software
function. However, manufacturers and users of this type of software should see FDA’s
guidance related to use of computers in clinical trials, “Electronic Source Data in Clinical
Investigations,66” issued on September 17, 2013.
10) I am a medical device manufacturer. Is an electronic method of collecting and

storing quality systems information in my manufacturing process considered a
medical device?
Answer: Software used in the production process for medical devices, or for collecting,
storing and maintaining quality system data collection for medical devices (including
complaint submissions) is not considered a medical device on its own. This software does not
meet the definition of medical device but is part of the quality system. However this software
is required to comply with the appropriate good manufacturing practices (GMP) regulations
(see 21 CFR Part 820).
66
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-source-
data-clinical-investigations.
40
Appendix G Additional Resources
A. Guidance Documents
1. Guidance for Industry – Cybersecurity for Networked Medical Devices Containing Off-
the-Shelf (OTS) Software, available at https://www.fda.gov/regulatory-
information/search-fda-guidance-documents/cybersecurity-networked-medical-devices-
containing-shelf-ots-software.
2. Information for Healthcare Organizations about FDA's "Guidance for Industry:

Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS)
Software,” available at https://www.fda.gov/regulatory-information/search-fda-guidance-
documents/information-healthcare-organizations-about-fdas-guidance-industry-
cybersecurity-networked-medical.
B. Standards
AAMI = Association for the Advancement of Medical Instrumentation
ANSI = American National Standards Institute
IEC = International Electrotechnical Commission
IEEE = Institute of Electrical and Electronics Engineers
ISO = International Organization for Standardization
1. ISO/IEC/IEEE 90003 Software engineering – Guidelines for the application of ISO

9001:2015 to computer software.
2. ISO 9001 Quality management systems – Requirements.
3. ISO 13485 Medical devices – Quality management systems – Requirements for

regulatory purposes.
4. ISO 9000 Quality management systems – Fundamentals and vocabulary.
5. ISO 14971 Medical devices — Application of risk management to medical devices.
6. IEC 62304 Medical device software – Software life cycle processes.
7. IEEE Std 1012 IEEE Standard for System, Software, and Hardware Verification and
Validation.
41
8. ISO/IEC 25051 Software engineering – Systems and software product Quality

Requirements and Evaluation (SQuaRE) – Requirements for quality of Ready to Use
Software Product (RUSP) and instructions for testing.
9. ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes.
10. AAMI TIR36 Validation of software for regulated processes.
11. IEC/TR 80002-1 Medical device software – Part 1: Guidance on the application of ISO
14971 to medical device software.
12. ANSI/AAMI ES60601-1 Medical electrical equipment – Part 1: General requirements

for basic safety and essential performance (particularly clause 14).
13. IEC 61508-2 Functional safety of electrical/electronic/programmable electronic safety-

related systems – Part 2: Requirements for electrical/electronic/programmable electronic
safety-related systems.
42

Policy For Device Software Functions and Mobile Medical Applications Guidance For Industry and Food and Drug Administration Staff

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Policy For Device Software Functions and Mobile Medical Applications Guidance For Industry and Food and Drug Administration Staff

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Policy For Device Software Functions and Mobile Medical Applications Guidance For Industry and Food and Drug Administration Staff

Uploaded by

Copyright:

Available Formats

Contains Nonbinding Recommendations

Policy for Device Software Functions

Document originally issued on September 25, 2013.

This document supersedes “Mobile Medical Applications” issued February

U.S. Department of Health and Human Services

Policy for Device Software Functions

B. Mobile Application (Mobile App)

C. Mobile Medical Application (Mobile Medical

· to be used as an accessory to a regulated medical device; or

· to transform a mobile platform into a regulated medical device.

D. Regulated Medical Device

E. Mobile Medical App Manufacturer

· Creates, designs, develops, labels, re-labels, remanufactures, modifies, or creates a

· Initiates specifications or requirements for mobile medical apps or procures product

· Manufacturers or distributors of mobile platforms who solely distribute or market

· Providers of tools, services, or infrastructure used in the development, distribution, or

· Licensed practitioners, including physicians, dentists, and optometrists, who

· to be used as an accessory to a regulated medical device; or

V. Regulatory Approach for Device Software Functions

A. Device software functions: Subset of software

1. Software functions that are an extension of one or more medical devices by

o Examples of software functions that control medical devices include: software

Device software functions of these types are considered accessories to the

o Examples of these types of software functions include: a software function that

patient for heart rate variability from a signal produced by an

3. Software functions that become a regulated medical device by performing

o Examples of software functions that perform sophisticated analysis or

B. Software functions for which FDA intends to

3. Software functions that provide or facilitate supplemental clinical care, by

o Software functions that coach patients with conditions such as cardiovascular

4. Software functions that provide easy access to information related to patients’

o Software functions that use a patient’s diagnosis to provide a clinician with

5. Software functions that are specifically marketed to help patients communicate

6. Software functions that perform simple calculations routinely used in clinical

o Body Mass Index (BMI);

See Appendix B for additional examples for the above categories.

VI. Regulatory Requirements

Class I devices: General Controls, including:

Appendix E provides a brief summary of the above requirements. Additional information is

Appendix A Examples of Software Functions that are

1. Software functions that are intended to provide access to electronic “copies”

o Medical flash cards with medical images, pictures, graphs, etc.;

o Interactive anatomy diagrams or videos;

o Provide a portal for health care providers to distribute educational information

4. Software functions that automate general office operations in a health care

o Determine billing codes like ICD-9 (international statistical classification of

o Generate reminders for scheduled medical appointments or blood donation

5. Software functions that are generic aids or general-purpose products – This

o Provide tools to promote or encourage healthy eating, exercise, weight loss, or

7. Software functions that enable individuals to interact with EHR software

o Software that serves as a videoconferencing portal specifically intended for

Appendix B Examples of Software Functions for which

2. Software functions that provide periodic educational information, reminders, or

Appendix C Examples of Software Functions that are the

diagnosis of balance disorders (i.e., nystagmograph). Possible product code: GWN

· Software functions that use a microphone or speaker within a mobile platform to

· Software functions that analyze an image of a skin lesion using mathematical

· Software functions that control or change settings of an implantable neuromuscular