Contains Nonbinding Recommendations
The 21st Century Cures Act (Cures Act), enacted on December 13, 2016, amended the definition 
of device in the Federal Food, Drug, and Cosmetic Act (FD&C Act) to exclude certain 
software functions. On September 27, 2019, FDA issued this guidance, Changes to Existing 
Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act, to 
provide our current thinking regarding the amended device definition and the interpretation of 
section 3060(a) of the Cures Act, including sections 520(o)(1)(A)-(D) of the FD&C Act. This 
guidance also detailed changes the amended device definition had on FDAs guidances that 
existed at that time related to medical device software, including:
 General Wellness: Policy for Low Risk Devices
 Policy for Device Software Functions and Mobile Medical Applications
 Off-The-Shelf Software Use in Medical Devices
 Medical Device Data Systems, Medical Image Storage Devices, and Medical Image
Communications Devices
This guidance, Changes to Existing Medical Software Policies Resulting from Section 3060 of 
the 21st Century Cures Act, remains FDAs policy and interpretation of section 3060(a) of the 
Cures Act, including sections 520(o)(1)(A)-(D) of the FD&C Act, and will continue to serve as 
reference for this topic. As of September 27, 2022, FDA does not intend to continue to update 
this guidance. Rather, as FDA receives comments from the public and FDAs thinking related to 
medical device software evolves, FDAs other guidances related to medical device software, 
including those referenced on this page, may be updated, if appropriate, in accordance with 21 
CFR 10.115.
We also note that FDA has issued two other guidance documents related to FDAs 
interpretation of section 520(o) of the FD&C Act:
 Clinical Decision Support Software, which interprets and explains the changes in section
520(o)(1)(E) of the FD&C Act, and
 Multiple Function Device Products: Policy and Considerations, which interprets and
presents FDAs approach to section 520(o)(2) of the FD&C Act.
FDAs guidances related to medical device software, including those listed above, will continue 
to be updated as FDAs thinking evolves, and should be consulted for FDAs current thinking on 
these topics.  Contains Nonbinding Recommendations 
Changes to Existing Medical Software 
Policies Resulting from Section 3060 of 
the 21st Century Cures Act 
______________________________________________________________________________ 
Guidance for Industry and 
Food and Drug Administration Staff 
Document issued on September 27, 2019. 
The draft of this document was issued on December 8, 2017. 
For questions about this document regarding CDRH-regulated devices, contact the Division of 
Digital Health 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  Contains Nonbinding Recommendations 
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-2017-D-6294. 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 include the document number 
17030 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., 
Bldg. 71, Room 3128, Silver Spring, MD 20993-0002, 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.  Contains Nonbinding Recommendations 
Table of Contents
 
I.  Introduction ........................................................................................................................................................... 1 
II.  Background ........................................................................................................................................................... 2 
III.  Scope ................................................................................................................................................................ 3 
IV.  Interpretation of the Cures Act and Modifications to Existing Guidance Documents ...................................... 3 
A.  Software Function Intended for Administrative Support of a Health Care Facility .............................................. 4 
B.  Software Function Intended for Maintaining or Encouraging a Healthy Lifestyle ............................................... 4 
C.  Software Function Intended to Serve as Electronic Patient Records .................................................................... 7 
D.  Software Function Intended for Transferring, Storing, Converting Formats, Displaying Data and Results ....... 11  Contains Nonbinding Recommendations 
Changes to Existing Medical Software 
Policies Resulting from Section 3060 of 
the 21st Century Cures Act
 
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 
Section 3060(a) of the 21st Century Cures Act (Cures Act) amended section 520 of the Federal 
Food, Drug, and Cosmetic Act (FD&C Act) on December 13, 2016, removing certain software 
functions from the definition of device in section 201(h) of the FD&C Act. This guidance 
provides FDAs current thinking regarding the amended device definition and the resulting effect 
the amended definition has on FDAs guidances related to medical device software. The 
concepts detailed in this guidance are also reflected in the following guidance documents 
through Level 2 updates:1
  General Wellness: Policy for Low Risk Devices2
  Mobile Medical Applications3
  Off-The-Shelf Software Use in Medical Devices4
                                                          
1 A Level 2 guidance document sets forth existing practices or minor changes in interpretation or policy. Level 2 
guidance documents include all guidance documents that are not classified as Level 1 (21 CFR 10.115(c)(2)).  
Because this final guidance sets forth the initial interpretations of FDAs statutory and regulatory requirements 
relating to software functions, it is a Level 1 guidance (21 CFR 10.115(c)(1)). FDA is making Level 2 updates to the 
listed guidance documents to make them consistent with existing practices as expressed in this final guidance. 
2 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-
low-risk-devices. 
3 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-
functions-and-mobile-medical-applications. 
4 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-
medical-devices. 
1  Contains Nonbinding Recommendations 
  Medical Device Data Systems, Medical Image Storage Devices, and Medical Image 
Communications Devices5
The following guidance document has been withdrawn, for the reasons described in Section 
IV.D: 
  Guidance for the Submission of Premarket Notifications for Medical Image Management 
Devices 
FDA's guidance documents, including this guidance, do not establish legally enforceable 
responsibilities. Instead, guidances describe the Agencys 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. 
II.  Background 
On December 13, 2016, the Cures Act was enacted. Section 3060(a) of this legislation, titled 
Clarifying Medical Software Regulation, amended the FD&C Act to add section 520(o), which 
describes software functions that are excluded from the definition of device in 201(h) of the 
FD&C Act. Section 3060(d) of the Cures Act amended section 201(h) of the FD&C Act to state 
that the term device does not include the software functions excluded pursuant to section 520(o). 
This guidance focuses on section 520(o)(1)(A)  (D) of the FD&C Act, reproduced below. 
Section 520 of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360j) 
(o) REGULATION OF MEDICAL AND CERTAIN DECISIONS SUPPORT SOFTWARE. 
(1) The term device, as defined in section 201(h), shall not include a software 
function that is intended 
(A) for administrative support of a health care facility, including the 
processing and maintenance of financial records, claims or billing information, 
appointment schedules, business analytics, information about patient 
populations, admissions, practice and inventory management, analysis of 
historical claims data to predict future utilization or cost-effectiveness, 
determination of health benefit eligibility, population health management, and 
laboratory workflow; 
(B) for maintaining or encouraging a healthy lifestyle and is unrelated 
to the diagnosis, cure, mitigation, prevention, or treatment of a disease or 
condition; 
(C) to serve as electronic patient records, including patient-provided 
information, to the extent that such records are intended to transfer, store, 
convert formats, or display the equivalent of a paper medical chart, so long as 
(i) such records were created, stored, transferred, or reviewed 
by health care professionals, or by individuals working under 
supervision of such professionals; 
(ii) such records are part of health information technology that 
is certified under section 3001(c)(5) of the Public Health Service Act; 
and 
                                                          
5 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. 
2 Contains Nonbinding Recommendations 
(iii) such function is not intended to interpret or analyze 
patient records, including medical image data, for the purpose of the 
diagnosis, cure, mitigation, prevention, or treatment of a disease or 
condition; 
(D) 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... 
III.  Scope
 
This guidance details the changes to existing guidance documents that relate to the regulation of 
the software functions described in section 520(o)(1)(A)  (D) of the FD&C Act. These sections 
describe software functions that do not meet the device definition in 201(h) of the FD&C Act. 
Section 3060 also describes limited circumstances when software functions described in 
520(o)(1)(A)  (D) would remain devices.6, 7
FDA provides clarification of its proposed interpretation of section 520(o)(1)(E) of the FD&C 
Act, which is for software functions intended to provide decision support for the diagnosis, 
treatment, prevention, cure, or mitigation of disease or other conditions (often referred to as 
clinical decision support software), in a separate guidance document. Section 520(o)(2) of the 
FD&C Act describes the regulation of a product with multiple functions, including at least one 
device function and at least one software function that is not a device. FDA also provides its 
proposed recommendations on the regulation of such products with multifunctionality in a 
separate guidance document. 
IV.  Interpretation of the Cures Act and Modifications to 
Existing Guidance Documents 
FDAs interpretation of each provision of section 520(o)(1)(A)  520(o)(1)(D) of the FD&C Act, 
described in Sections A  D below has been added to the Background sections of the indicated 
guidances that have been revised, after consideration of timely filed comments, through Level 2 
updates to incorporate the changes detailed in this guidance. Similarly, FDA has made changes 
to the examples in the guidances, after consideration of comments, through Level 2 updates, as 
described below. 
                                                          
6 The Cures Act also provides that a software function described in section 520(o)(1)(A)  (D) of the FD&C Act 
will not be excluded from the device definition under section 201(h) of the FD&C Act if FDA makes a finding that 
the software function would be reasonably likely to have serious adverse health consequences and certain 
substantive and procedural criteria are met. (Section 520(o)(3) of the FD&C Act). 
7 The Cures Act further provides that a software function described in section 520(o)(1)(A)  (D) of the FD&C Act 
will not be excluded from the device definition under section 201(h) of the FD&C Act if the software meets the 
criteria for class III classification under section 513(a)(1)(C) of the FD&C Act. (Section 520(o)(4)(C) of the FD&C 
Act). The Cures Act also states that this statutory provision shall not be construed to limit FDAs authority to 
regulate software used in the manufacture and transfusion of blood and blood components to assist in the prevention 
of disease in humans. (Section 520(o)(4)(B) of the FD&C Act). 
3 Contains Nonbinding Recommendations 
Section 3060 of the Cures Act created a function-specific definition, and as such, the functions 
excluded from the device definition under section 520(o) of the FD&C Act are independent of 
the platform on which they might run. In order to clarify this, we have made changes to the 
relevant guidances, through Level 2 updates. Additionally, where appropriate, we are clarifying 
that the policies in the guidance documents are function-specific and apply across platforms. For 
example, as appropriate, instances of mobile application in the Mobile Medical Applications 
(MMA) guidance has been changed to software function, and the title of the guidance has been 
revised to Policy for Device Software Functions and Mobile Medical Applications. 
A.  Software Function Intended for Administrative 
Support of a Health Care Facility 
Section 520(o)(1)(A) of the FD&C Act states that the term device does not include a software 
function that is intended for administrative support of a health care facility, including the 
processing and maintenance of financial records, claims or billing information, appointment 
schedules, business analytics, information about patient populations, admissions, practice and 
inventory management, analysis of historical claims data to predict future utilization or cost-
effectiveness, determination of health benefit eligibility, population health management, and 
laboratory workflow. FDA has not historically considered most of these software functions to 
be devices; however, we propose the following modification in order to provide additional 
clarity. 
Section 3.2.2. of the Guidance for Off-the-Shelf Software Use in Medical Devices,8 titled 
Exemption of Laboratory Information Management Systems, has been removed from the 
guidance. Laboratory Information Systems (LIS) and Laboratory Information Management 
Systems (LIMS) functions intended for administrative support of laboratories and/or for 
transferring, storing, converting formats, or displaying clinical laboratory test data and results are 
not considered to be within the definition of the term device, according to section 201(h) of the 
FD&C Act, as amended by the Cures Act (see section 520(o)(1)(A) and (D) of the FD&C Act). 
Therefore, these software functions are not subject to requirements under the FD&C Act. 
However, some LIS and LIMS include software functions that remain device functions, 
including software functions that analyze medical device data in order to provide a notification 
or flag (e.g., that a parameter is out of range) and such functions will continue to be regulated as 
devices as specified in Section IV.D. 
B.  Software Function Intended for Maintaining or 
Encouraging a Healthy Lifestyle 
FDA considers a product with an intended use for maintaining or encouraging a healthy 
lifestyle to mean a product with an intended use that encourages or maintains a general state of 
health or healthy activity, as defined in the FDA guidance General Wellness: Policy for Low 
                                                          
8 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-
medical-devices. 
4 Contains Nonbinding Recommendations 
Risk Devices (General Wellness Guidance).9 In that guidance, CDRH defines a general 
wellness product as products that (1) are intended for only general wellness use, as defined in 
that guidance, and (2) present a low risk to the safety of users and other persons. That guidance 
defines two categories of general wellness intended uses: 
(1)  an intended use that relates to maintaining or encouraging a general state of health 
or a healthy activity, or 
(2)  an intended use that relates the role of healthy lifestyle with helping to reduce the 
risk or impact of certain chronic diseases or conditions and where it is well understood 
and accepted that healthy lifestyle choices may play an important role in health outcomes 
for the disease or condition. 
Section 520(o)(1)(B) of the FD&C Act states that the term device does not include a software 
function that is intended for maintaining or encouraging a healthy lifestyle and is unrelated to 
the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition. This provision 
affects the two categories of general wellness intended uses differently, as described below: 
1.  General Wellness Intended Use That Relates to Maintaining or Encouraging a General 
State of Health or a Healthy Activity 
According to section 520(o)(1)(B) of the FD&C Act, a software function with a healthy lifestyle 
claim (e.g., products that fall within the first category of general wellness intended uses as 
defined by the General Wellness Guidance) is not a device as long as its claims are unrelated to 
the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition. For example, 
software with healthy lifestyle claims, such as weight management, physical fitness, relaxation 
or stress management, mental acuity, self-esteem, sleep management, or sexual function, are not 
devices when not related to the diagnosis, cure, mitigation, prevention, or treatment of a disease 
or condition. 
Section 520(o)(1) of the FD&C Act describes software functions, not hardware products, that do 
not meet the definition of a device under section 201(h) of the FD&C Act as amended. 
Therefore, hardware with general wellness intended uses that relate to maintaining or 
encouraging a general state of health or healthy activity that otherwise meet the definition of 
device in section 201(h) will continue to be regulated as devices. FDA notes that many such 
functions do not otherwise meet the definition of a device under section 201(h) of the FD&C 
Act; however, for those hardware products that do otherwise meet the definition of device, FDA 
intends to apply the considerations in the General Wellness Guidance. 
2.  General Wellness Product Use That Relates the Role of Healthy Lifestyle with Helping to 
Reduce the Risk or Impact of Certain Chronic Diseases or Conditions and Where it is 
Well Understood and Accepted That Healthy Lifestyle Choices May Play an Important 
Role in Health Outcomes for the Disease or Condition 
If the intended use of the software function is related to the diagnosis, cure, mitigation, 
prevention, or treatment of a disease or condition, then the product is not excluded from the 
                                                          
9 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-
low-risk-devices. 
5 Contains Nonbinding Recommendations 
definition of the term device under section 520(o)(1)(B) of the FD&C Act. Since the second 
category of a general wellness intended uses, as defined in the General Wellness Guidance, 
relates to the mitigation or prevention of a disease or condition, these products are not excluded 
from the definition of device as modified by this new provision of the FD&C Act. This second 
category of general wellness intended uses relates to sustaining or offering general improvement 
to functions associated with a general state of health while making reference to help reduce the 
risk of or help living well with certain chronic diseases or conditions. FDAs policy for general 
wellness products in the second category can be found in the General Wellness Guidance.10
The following examples in Section V of the General Wellness Guidance are not devices: 
  A mobile application that plays music to soothe and relax an individual and to 
manage stress. Such a software function is not a device function (Illustrative 
Example 1). 
  A mobile application that solely monitors and records daily energy expenditure and 
cardiovascular workout activities to allow awareness of ones exercise activities to 
improve or maintain good cardiovascular health. Such a software function is not a 
device function (Illustrative Example 2). 
  A mobile application that monitors and records food consumption to manage dietary 
activity for weight management and alert the user, health care provider, or family 
member of unhealthy dietary activity. Such a software function is not a device 
function (Illustrative Example 3). 
These examples remain in the General Wellness Guidance, because they continue to meet the 
definition of general wellness products; however, the title of Section V has been changed to 
Examples of General Wellness Products that Are Not Medical Devices and Examples of 
General Wellness Products that Are Medical Devices for which FDA Does Not Intend to Enforce 
Requirements to reflect the bullets above that indicate that some of these examples are not 
medical devices under section 201(h) of the FD&C Act. 
 
For the MMA guidance,11 the following examples in Appendix B (Examples of mobile apps for 
which FDA intends to exercise enforcement discretion) have been moved to Appendix A 
(Examples of mobile apps that are NOT medical devices) of the MMA Guidance, because they 
no longer meet the definition of the term device pursuant to section 520(o)(1)(B) of the FD&C 
Act: 
  Mobile apps 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; 
                                                          
10 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-
policy-low-risk-devices. 
11 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-
functions-and-mobile-medical-applications. 
6 Contains Nonbinding Recommendations 
o  Provide meal planners and recipes; 
o  Track general daily activities or make exercise or posture suggestions; 
o  Track a normal babys sleeping and feeding habits; 
o  Actively monitor and trend exercise activity; 
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. 
C.  Software Function Intended to Serve as Electronic 
Patient Records 
Under section 520(o)(1)(C) of the FD&C Act, the term device does not include certain software 
functions that are intended to serve as electronic patient records. Specifically, software functions 
that are intended to transfer, store, convert formats, or display electronic patient records that are 
the equivalent of a paper medical chart are not devices, if all the following three criteria outlined 
in section 520(o)(1)(C)(i)  (iii) are met: 
1.  Such records were created, stored, transferred, or reviewed by health care 
professionals (HCPs), or by individuals working under supervision of such professionals, 
(section 520(o)(1)(C)(i) of the FD&C Act); 
2.  Such records are part of information technology certified under a program of 
voluntary certification kept or recognized by the Office of the National Coordinator for 
Health Information Technology (ONC) under section 3001(c)(5) of the Public Health 
Service Act (ONC Health IT Certification Program)12 (section 520(o)(1)(C)(ii) of the 
FD&C Act); and 
3.  Such software functions are not intended for interpretation or analysis of patient 
records, including medical image data, for the purpose of the diagnosis, cure, mitigation, 
prevention, or treatment of a disease or condition (section 520(o)(1)(C)(iii) of the FD&C 
Act). 
1.  Records created, stored, transferred, or reviewed by HCPs, patients, or other individuals 
Section 520(o)(1)(C)(i) of the FD&C Act describes software functions that are intended to 
transfer, store, convert formats, or display electronic patient records that are not devices, if those 
functions are performed by HCPs or individuals working under HCP supervision. 
                                                          
12 About the ONC Health IT Certification Program, available at https://www.healthit.gov/policy-researchers-
implementers/about-onc-health-it-certification-program. A comprehensive listing of all health information 
technology, which has been certified under the ONC Health IT Certification program, is available at the Certified 
Health IT Product List at https://chpl.healthit.gov/#/resources/overview. 
7 Contains Nonbinding Recommendations 
Software functions that enable patients, individuals, or non-HCPs to create, store, or transfer 
health records are considered personal health records (PHRs). These software functions in PHR 
systems that are not intended for use in the diagnosis, cure, mitigation, prevention, or treatment 
of a disease or condition are not devices under section 201(h) of the FD&C Act. 
2.  Certified under ONC Health IT Certification Program 
Under section 520(o)(1)(C) of the FD&C Act, the term device does not include software 
functions that meet the other criteria in section 520(o)(1)(C)(i) and (iii) of the FD&C Act and 
that are certified under the ONC Health IT Certification Program. 
Based on our current understanding of the risks of these devices, FDA does not intend at this 
time to enforce compliance to the requirements of the FD&C Act for software functions that are 
not certified under the ONC Health IT Certification Program if they meet the other criteria in 
section 520(o)(1)(C)(i) and (iii) of the FD&C Act.13
As described above, software functions in PHR systems that are intended for use by patients, 
individuals, or non-HCPs are not devices under section 201(h) of the FD&C Act (not by 
operation of section 520(o) of the FD&C Act). As such, there is no requirement for ONC 
certification of these PHR software functions. 
3.  Not intended for interpretation or analysis of patient records 
Software functions excluded from the device definition by section 520(o)(1)(C) of the FD&C 
Act may be contained in electronic health record (EHR) systems, PHR systems, and other health 
information technology (IT). Such EHR or PHR systems may also contain other software 
functions that could meet the definition of a device. FDAs approach to oversight of software 
functions that meet the definition of a device in a system with software functions that do not 
meet the definition of device (products with multiple functions) will be addressed in a separate 
guidance document. Similarly, FDAs approach to oversight of software functions that provide 
interpretation or analysis of records will be addressed in a separate guidance document on 
section 520(o)(1)(E) of the FD&C Act. 
Therefore, in the MMA Guidance,14 the following examples in Section V.B (Examples of mobile 
apps for which FDA intends to exercise enforcement discretion) are not devices (pursuant to 
section 520(o)(1)(C) of the FD&C Act), and have been moved to Appendix A (Examples of 
mobile apps that are NOT medical devices) of that guidance: 
  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 
                                                          
13 Nothing in this subsection shall be construed as limiting the authority of the [FDA] to (A) exercise 
enforcement discretion as to any device subject to regulation under this Act . . . (section 520(o)(4) of the FD&C 
Act). 
14 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-
functions-and-mobile-medical-applications. 
8 Contains Nonbinding Recommendations 
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. 
o  Note: This example has been changed to clarify that only EHR software functions 
certified under the ONC Health IT Certification Program are not devices 
according to the FD&C Act, as amended by the Cures Act. This example has also 
been changed where it previously described mobile apps to the term software 
function. As described above, similar changes are made throughout the MMA 
guidance, but not detailed in this guidance. 
o  For clarity, this example and other types of electronic patient record functions 
must meet the full description of section 520(o)(1)(C) in the FD&C Act, in that 
they are not devices only if they are reviewed by HCPs, certified under the ONC 
Health IT Certification Program, and are not intended for interpretation or 
analysis for the purpose of the diagnosis, cure, mitigation, prevention, or 
treatment of a disease or condition. However, FDA does not intend, at this time 
and based on our current understanding of the risks of these devices, to enforce 
compliance with requirements of the FD&C Act that apply to these software 
functions if the only requirement of 520(o)(1)(C) that they fail to meet is 
certification under the ONC Health IT Certification Program. 
  Provide patients with simple tools to organize and track their health information; 
  Provide easy access to information related to patients health conditions or treatments; 
  Help patients document, show, or communicate potential medical conditions to health 
care providers; 
  Mobile apps that provide patients with simple tools to organize and track their 
health information  These are apps that provide patients with tools to organize and 
track health information without providing recommendations to alter or change a 
previously prescribed treatment or therapy. Examples include: 
o  Apps 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. 
  Note this example has been modified to replace log, track, or trend 
with record to align with the language in the Cures Act. 
  Mobile apps that are specifically marketed to help patients document, show, or 
communicate to providers 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  Apps that serve as videoconferencing portals specifically intended for 
medical use and to enhance communications between patients, health care 
providers, and caregivers; 
o  Note this example has been modified to remove the sentence: These are apps 
that in their labeling or promotional materials are not promoted for medical 
uses but which, by virtue of other circumstances surrounding their 
distribution, may meet the definition of a medical device. 
9 Contains Nonbinding Recommendations 
o  The second example included as a sub-bullet remains a device function under 
enforcement discretion, because its functions extend beyond functions 
intended to transfer, store, convert formats, or display the equivalent of a 
paper medical chart. This example remains in Section V.B (Examples of 
mobile apps for which FDA intends to exercise enforcement discretion) of the 
MMA guidance: Apps specifically intended for medical uses that utilize the 
mobile devices built-in camera or a connected camera for purposes of 
documenting or transmitting pictures (e.g., photos of a patients 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. 
And in the MMA Guidance,15 the following examples have been moved from Appendix B 
(Examples of mobile apps for which FDA intends to exercise enforcement discretion) to 
Appendix A (Examples of mobile apps that are NOT medical devices). The phrase that is [or 
are] certified under the ONC Health IT Certification Program was added to these examples, as 
appropriate, to clarify that EHR software functions are not devices only if they are certified 
under the ONC Health IT Certification Program. 
  Mobile apps that enable, during an encounter, a health care provider to access their 
patients personal health record (health information) that is hosted on a web-based or 
other platform; 
  Software functions for HCPs 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. 
o  This example has been changed from assessing the need for immunization to 
documenting the need... because the example is intended to serve as an 
example of an electronic patient record, and not clinical decision support 
software. FDA intends to provide clarification of section 520(o)(1)(E) of the 
FD&C Act and clinical decision support software in a separate guidance 
document. 
  Mobile apps 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. 
o  Note this example has been changed to replace the word track with record (i.e., 
collect and log). 
  Software functions certified under the ONC Health IT Certification Program that prompt 
the HCP to manually enter symptomatic, behavioral or environmental information, the 
specifics of which are pre-defined by a HCP, and store the information for later review; 
  Mobile apps 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; 
  Mobile apps 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 
                                                          
15 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-
functions-and-mobile-medical-applications. 
10 Contains Nonbinding Recommendations 
health care provider, or upload it to an online (cloud) database, personal health record, or 
electronic health record that is certified under the ONC Health IT Certification Program. 
o  Note this example has been modified to replace collect, log, track and trend 
with record (i.e., collect and log). 
  Enable patients or providers to interact with PHR systems or EHR systems that are 
certified under the ONC Health IT Certification Program. 
o  Note, this example is considered not a medical device because interacting with 
PHR or EHR systems is an example of transferring, storing, converting formats, 
or displaying EHR or PHR data. 
D.  Software Function Intended for Transferring, 
Storing, Converting Formats, Displaying Data and 
Results 
Under section 520(o)(1)(D) of the FD&C Act, the term device does not include a software 
function that is intended for transferring, storing, converting formats, or displaying clinical 
laboratory test or other device data and results unless such function is intended to interpret or 
analyze clinical laboratory test or other device data, results, and findings (section 520(o)(1)(D) 
of the FD&C Act). 
Medical Device Data Systems, medical image storage devices, and medical image 
communications devices are defined as: 
1.  Medical Device Data System (MDDS), defined as a software, electronic, or electrical 
hardware that is intended to provide one or more of the following uses, whether or not it 
is intended for immediate clinical action (i.e., active patient monitoring), without 
controlling or altering the functions or parameters of any connected medical devices: 
a.  The electronic transfer of medical device data; 
b.  The electronic storage of medical device data; 
c.  The electronic conversion of medical device data from one format to another 
format in accordance with a preset specification; or 
d.  The electronic display of medical device data. 
Examples of MDDS include physical communications medium (including 
wireless hardware), modems, interfaces, and a communications protocol. 
2.  Medical image storage device, defined as a device that provides electronic storage and 
retrieval functions for medical images. Examples include devices employing magnetic 
and optical discs, magnetic tape, and digital memory. 
3.  Medical image communications device, defined as a device that provides electronic 
transfer of medical image data between medical devices. It may include a physical 
communications medium, modems, interfaces, and a communications protocol. 
The software functions that meet the definitions of Medical Device Data Systems (MDDS), 
medical image storage devices, or medical image communications devices provided in the 
Medical Device Data Systems, Medical Image Storage Devices, and Medical Image 
11 Contains Nonbinding Recommendations 
Communications Devices Guidance (or MDDS Guidance),16 and the Guidance for the 
Submission of Premarket Notifications for Medical Image Management Devices, are now not 
devices under section 201(h) of the FD&C Act, pursuant to section 520(o)(1)(D) of the FD&C 
Act. As such, software functions that are solely intended to transfer, store, convert formats, and 
display medical device data and results, including medical images, waveforms, signals, or other 
clinical information are not devices and thus are not subject to FDA regulatory requirements. 
However, software functions that analyze or interpret medical device data in addition to 
transferring, storing, converting formats, or displaying clinical laboratory test or other device 
data and results remain subject to FDAs regulatory oversight, unless they meet the criteria 
outlined in section 520(o)(1)(E) of the FD&C Act. 
Section 520(o)(1) of the FD&C Act describes software functions, not hardware products, that do 
not meet the definition of a device under section 201(h) of the FD&C Act. Therefore, the 
hardware included in the identification above (such as electrical hardware, magnetic and optical 
discs, physical communications medium, etc.) that are intended to transfer, store, convert 
formats, and display medical device data and results remain devices. FDAs existing policy, 
described in the MDDS Guidance,17 applies to such devices, provided that the hardware function 
is limited to assisting the following software functions: electronic transfer, storage, conversion of 
formats, or display of medical device data. Specialized medical display hardware devices for 
digital mammography, radiology, pathology, and ophthalmology (see, for example, 21 CFR 
892.2050) and other specialized medical display hardware integral to the safe and effective use 
of a medical device hardware product (such as integral 3D displays in robotic surgery systems 
and displays built into ICU bedside monitors) have not been considered MDDS, medical image 
storage, or medical image communications devices. Such medical display hardware devices and 
other specialized medical display hardware integral to a medical device are not excluded from 
the device definition by the Cures Act. 
There may be MDDS products that are considered multiple function products in that they may 
have a software function that is not a device and another function that is a device. Consistent 
with section 520(o)(2) of the FD&C Act, FDA does not regulate the MDDS software functions 
that meet the definition of 520(o)(1)(D) of the FD&C Act in a MDDS multiple function product. 
If a multiple function product contains MDDS hardware functions, FDA does not, at this time 
and based on our current understanding of the risks of these devices, intend to enforce the 
requirements under the FD&C Act. However, FDA may assess the impact that such software and 
hardware MDDS functions have on the safety and effectiveness of the device function(s) in a 
multiple function device product. As noted above, FDA intends to provide recommendations on 
the regulation of such products with multifunctionality in a separate guidance document. 
In some cases, software functions that transfer, store, convert formats, or display medical device 
data and results are utilized on hardware that is not intended by the hardware manufacturer for a 
device function under section 201(h) of the FD&C Act. For example, general-purpose hardware 
IT infrastructure intended for data transfer (e.g., network router), data storage (e.g., network 
                                                          
16 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. 
17 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. 
12 Contains Nonbinding Recommendations 
attached storage (NAS)), conversion of data (e.g., PDF software), and display of data (computer 
monitor) are not device functions. Such products do not meet the definition of a device in section 
201(h) of the FD&C Act for either the software or hardware function and are therefore not 
regulated as devices. 
Section 520(o)(1)(D) of the FD&C Act does not capture software functions intended to generate 
alarms or alerts or prioritize patient-related information on multi-patient displays, because these 
functions involve analysis or interpretation of laboratory test or other device data and results. For 
example, if a software function is intended to prioritize patients in an Intensive Care Unit based 
on their clinical status, then this function is intended to interpret or analyze device data, results, 
and findings and is, therefore, not excluded from the definition of device under section 
520(o)(1)(D) of the FD&C Act. Similarly, software functions that analyze medical device data in 
order to provide a notification or flag (e.g., that a parameter is out of range) are not excluded 
from the definition of device under subsection (D)). The examples included in the draft of this 
guidance that described alarms, alerts, or flags have been removed from this guidance, because 
they are not excluded from the definition of device under subsection (D). These functions are 
addressed in section 520(o)(1)(E) of the FD&C Act, the regulation of which will be described in 
a separate guidance document. 
The MDDS Guidance18 has been revised to clarify that software functions that are solely 
intended to transfer, store, convert formats, and display medical device data and results, 
including medical images, waveforms, signals, or other clinical information are not devices and 
thus are not subject to FDA regulatory requirements, whether or not the use is for immediate 
clinical action. Accordingly, the definition of MDDS has been revised in that guidance to 
describe hardware that transfers, stores, converts formats, and displays medical device data as 
Device-MDDS whereas the software functions that transfer, store, convert formats, and display 
data have been defined as Non-Device-MDDS. Additional updates to the MDDS guidance 
include: 
  In the Background section, the following list of examples has been labeled as Non-
Device-MDDS, because they are examples of MDDS software functions: 
o  The electronic transfer or exchange of medical device data. For example, this 
would include software that collects output from a ventilator about a patient's CO  
2
level and transmits the information to a central patient data repository. 
o  The electronic storage and retrieval of medical device data. For example, software 
that stores historical blood pressure information for later review by a health care 
provider. 
o  The electronic conversion of medical device data from one format to another in 
accordance with a preset specification. For example, software that converts digital 
data generated by a pulse oximeter into a digital format that can be printed. 
o  The electronic display of medical device data. For example, software that displays 
a previously stored electrocardiogram for a particular patient. 
                                                          
18 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. 
13 Contains Nonbinding Recommendations 
  In the Background section, the following examples of MDDS have been revised to clarify 
that only the software functions are Non-Device-MDDS: 
o  Any assemblage or arrangement of network components that includes specialized 
software expressly created for a purpose consistent with the intended for use in 
the MDDS regulation. 
  Note or hardware has been removed from this example. 
o  Software functions specifically labeled (per 21 CFR Part 801) by the 
manufacturer as a MDDS, provided such software functions do not provide 
additional functionality. 
  Note products has been replaced with software functions. 
o  Custom software that is written by entities other than the original medical device 
manufacturer (for example, hospitals, third party vendors) that directly connects 
to a medical device, to obtain medical device information. 
o  Modified portions of software that are part of an IT infrastructure created and/or 
modified (writing and compiling software) for specific MDDS functionality. For 
example, when modifying software for MDDS functionality, only the modified 
portion is considered MDDS; the original software is not. 
  Note or hardware has been removed from this example. 
  In the Background section, the section title Examples of devices that perform 
monitoring but are not considered to perform active patient monitoring has been 
revised to Examples of products that transfer, store, convert formats, or display medical 
device data and are Non-Device-MDDS. 
  In the Policy section of the MDDS guidance, FDA describes its compliance policy with 
respect to the following devices: 
o  MDDS subject to 21 CFR 880.6310, 
o  Medical image storage devices subject to 21 CFR 892.2010, and 
o  Medical image communications devices subject to 21 CFR 892.2020. 
As described above, FDA intends to continue this policy for hardware products 
considered MDDS, medical image storage, or medical image communications devices, 
provided that the hardware function is limited to the excluded software functions of 
electronic transfer, storage, conversion of formats, or display of medical device data. 
FDA intends to amend the regulations so that they describe the hardware functions that 
remain device functions, and to remove reference to software functions that are not 
device functions pursuant to section 520(o)(1)(D) of the FD&C Act. Accordingly, the 
Policy section has been amended to include the following: 
o  Software functions that meet the definitions of MDDS, medical image storage 
devices, or medical image communications devices are not devices under section 
201(h) of the FD&C Act. Hardware that are intended to transfer, store, convert 
formats, and display medical device data and results remain devices. FDA does 
not intend to enforce the requirements under the FD&C Act for hardware products 
considered MDDS, medical image storage, or medical image communications 
devices. 
14 Contains Nonbinding Recommendations 
In the MMA Guidance,19 the following example has been revised and moved from Section V.A 
(Subset of mobile apps that are the focus of FDAs regulatory oversight) to Appendix A 
(Examples of mobile apps that are NOT medical devices): 
  Examples of displays of patient-specific medical device data include: software function to 
display medical images directly from a Picture Archiving and Communication System 
(PACS) server. 
o  Note: The remote display of data from bedside monitors has been removed from 
this example, because such non-device display functions are covered in other 
examples, while this example is not likely to be a real-world example of a 
product, since such product would likely include other software functions that 
analyze or interpret medical device data that may continue to be subject to FDAs 
regulatory oversight. 
In the MMA Guidance, the following examples have been moved from Appendix B (Examples 
of mobile apps for which FDA intends to exercise enforcement discretion) to Appendix A 
(Examples of mobile apps that are NOT medical devices): 
  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., mobile apps that meet the definition 
of MDDS). 
o  Software functions that meet the definition of MDDS and connect to a nursing 
central station and display (but do not analyze or interpret) medical device data to 
a physicians 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). 
o  Note that in these examples, mobile apps has been replaced with software 
functions to clarify that the software functions are Non-Device-MDDS. 
In the MMA Guidance, the following examples in Appendix C (Examples of mobile apps that 
are the focus of FDAs regulatory oversight) have been revised as described below: 
  Mobile apps that are used in active patient monitoring or analyzing patient-specific 
medical device data and therefore are the focus of FDAs regulatory oversight: 
                                                          
19 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-
functions-and-mobile-medical-applications. 
15 Contains Nonbinding Recommendations 
o  Mobile apps that connect to bedside (or cardiac) monitors and transfer the data to 
a central viewing station for display and active patient monitoring. Possible 
product code(s): DSI, MHX, MLD (21 CFR 870.1025), DRT, MWI, MSX (21 
CFR 870.2300). 
  This sub-bullet has been revised to say: Software functions that acquire or 
process physiological signals. Possible product code(s): DSI, MHX, MLD 
(21 CFR 870.1025), DRT, MWI, MSX (21 CFR 870.2300). 
o  Mobile apps that connect to a perinatal monitoring system and transfer uterine 
contraction and fetal heart rate data to another display to allow for remote 
monitoring of labor progress. Possible product code(s): HGM (21 CFR 884.2740). 
  This sub-bullet has been revised to say: 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). 
o  Mobile apps that are intended to display images for diagnostic review may be 
regulated as a picture archiving and communications system. Possible product 
code(s): LLZ (21 CFR 892.2050). 
  This sub-bullet has been revised to say: 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). 
And the following example of a software function and its associated text in Section V.B of the 
MMA Guidance is no a longer device pursuant to section 520(o)(1)(D) of the FD&C Act and has 
been moved to Appendix A (Examples of mobile apps that are NOT medical devices) of that 
guidance: 
  Software functions that meet the definition of Medical Device Data Systems  These are 
software functions that are intended to transfer, store, convert formats, and display 
medical device data, without controlling or altering the functions or parameters of any 
connected medical device. These include those software functions for a secondary display 
to a regulated medical device when these apps are not intended to provide primary 
diagnosis, to be used to make treatment decisions, or to be used in connection with active 
patient monitoring. 
o  Note the text of this example has been modified to clarify that only the software 
functions intended to transfer, store, convert formats, and display medical device 
data are not medical devices (i.e., Non-Device-MDDS). 
The Guidance for the Submission of Premarket Notifications for Medical Image Management 
Devices has been withdrawn, because some software functions described in that guidance no 
longer meet the definition of a device, as amended. For the limited subset of Medical Image 
Management Devices that continue to meet the definition of a device and continue to require a 
510(k) submission, the information provided in that document, which was written in 2000, is out 
of date. CDRH encourages manufacturers to reference the most recent FDA-recognized versions 
of relevant voluntary consensus standards instead. 
16