On December 7, 2017, the Food and Drug Administration (FDA or the Agency) released three guidance documents that together aim to clarify the framework for the regulation of software and digital health products to bring FDA regulatory policy into line with the 21st Century Cures Act (Cures Act) enacted by Congress in December 2016. These guidance documents included a long-awaited and much anticipated draft guidance on clinical decision support software, Clinical and Patient Decision Support Software (CDS Guidance), a draft guidance regarding how FDA plans to modify existing guidance documents to implement elements of the Cures Act, Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act (Changes Guidance) as well as a final guidance document, Software as a Medical Device (SAMD): Clinical Evaluation (SaMD Guidance), adopting principles for regulation of software first proposed by the International Medical Device Regulators Forum (IMDRF). These new releases follow FDA's recent announcement and recruitment for its digital health software precertification pilot program (Pre-Cert).

CDS Guidance

The CDS Guidance explains the Cures Act provisions exempting from regulation Clinical Decision Support (CDS) tools that meet certain criteria. Following years of Agency discussion about CDS, the draft guidance provides the first formalized Agency guidelines for determining whether specific decision support software tools would be regulated.

The Federal Food, Drug and Cosmetic Act (FDC Act) was amended by the Cures Act to state that software functions meeting all of the following four criteria are no longer considered medical devices, and therefore are not subject to FDA regulation:

  1. not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;
  2. intended to display, analyze, or print medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
  3. intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition; and
  4. intended to enable such healthcare professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such healthcare professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient. 1  

For purposes of the guidance, FDA interprets CDS to refer to those software functions that meet the first three criteria above.2 However, a CDS function is only excluded from the definition of a device when it also enables independent review of the software’s basis for clinical recommendations. The crux of this fourth criterion is that a healthcare professional must be able to rely on his/her own judgment, rather than primarily on the software’s recommendations, to make clinical decisions for individual patients. To that end, the software function should clearly explain its purpose or intended use, the intended user, the inputs used to generate the recommendation (e.g., patient age), and the rationale or support for the recommendation. The intended user should be able to reach the same recommendation on his/her own, so the sources supporting the recommendation or underlying the rationale for it should be identified, easily accessible, and understandable to the intended user. If a recommendation is based on non-public or difficult to understand information, the user could not independently evaluate the basis for it or easily identify erroneous output, and as such, it would not be excluded from the definition of a device.

Spectrum of Regulation for Clinical Decision Support

Taking a similar approach to the Mobile Medical Application guidance, FDA has categorized CDS software functionalities into three buckets: (1) those that do not meet the definition of a device under the current statutory definition as amended by the Cures Act; (2) those that may meet the definition of a device but for which FDA intends to exercise enforcement discretion, i.e., not to enforce compliance with FDC Act requirements applicable to medical devices; and (3) those on which FDA intends to focus its regulatory oversight.  

Types of CDS functions that are not devices because they meet all four criteria set forth above from the Cures Act include, among others:

  • software that provides recommendations by matching patient-specific information (e.g., diagnosis, allergies, symptoms) to reference information routinely used by the medical community in clinical practice (e.g., practice guidelines, FDA-approved drug labeling), to facilitate assessment or treatment of specific patients;
  • software that provides recommendations on the use of a prescription drug that are consistent with the current FDA-required labeling;
  • software that makes chemotherapeutic suggestions based on patient history, test results, and patient characteristics, including, e.g., suggesting a platinum-based chemotherapy for BRCApositive individuals that is consistent with the drug labeling; and
  • software intended to aid in diagnosing suspected diabetes mellitus, where the healthcare practitioner enters patient parameters and laboratory test results and the device suggests whether the patient’s condition meets the definition of diabetes per established guidelines.

Many software functions intended to support healthcare professionals are not affected by the recent amendment of the device definition, and continue to be considered medical devices. For low risk products, such as software that performs calculations routinely used in clinical practice, FDA intends to continue its existing policy of enforcement discretion.

Examples of CDS functions that remain devices and on which FDA intends to focus its regulatory oversight include, among others, software that:

  • uses a patient’s image sets (e.g., CT or MRI) to create an individual plan for radiation therapy treatment, where the healthcare professional is meant to rely primarily on the treatment recommendations in determining how the patient will be treated;
  • manipulates or analyzes images and other data obtained from a radiological device to create 3D models of the region intended to be used in planning surgical treatments;
  • software that analyzes sound waves captured when users recite certain sentences to diagnose bronchitis or sinus infection; or
  • employs an algorithm undisclosed to the user to analyze patient information to determine which drug class is likely to be most effective in lowering a patient’s blood pressure. 

Importantly, all of the above examples present scenarios in which the provider would necessarily rely on the model, analysis, or conclusion generated by the software, without being able to independently derive that recommendation or review its underlying basis. It should also be noted that, through the examples provided in the draft CDS Guidance, FDA appears to be drawing a distinction between software functions that analyze sensor or other data to produce new clinical metrics (regulated) and software functions that use existing clinical metrics or physiological data to make recommendations that are based on published guidelines (not regulated).

“New” Category: Patient Decision Support Tools

Notably, the draft CDS Guidance establishes a new category of products, patient decision support software (PDS), to cover decision support software intended for use by patients and caregivers who are not healthcare professionals. While such functionalities are not excluded from the statutory definition of a device, FDA recognizes that some are low-risk; therefore, it plans to adopt an enforcement discretion policy for PDS that parallels the CDS for healthcare professionals excluded from the device definition. Accordingly, PDS will be subject to enforcement discretion if they satisfy the first two exclusion criteria above and fulfill slightly modified versions of the third and fourth criteria:

  • support or provide recommendations to patients or non-healthcare professional caregivers, in terms understandable to the intended recipient, about prevention, diagnosis, or treatment of a disease/condition; and
  • enable the patient or non-healthcare professional caregiver to independently review the basis for the recommendation3 so that it is not the intent that such person rely primarily on the recommendation to make a decision regarding a patient.

The examples provided of PDS that would be subject to enforcement discretion parallel those of CDS no longer considered to be medical devices, such as software that provides information to a patient about use of a prescription drug that is consistent with the current FDA-required labeling

By contrast, PDS that do not meet the criteria outlined above will be subject to active FDA regulatory oversight. 

Changes Guidance

The Changes Guidance addresses planned modifications to FDA’s existing guidance documents related to software products that were impacted by the enactment of the Cures Act. Specifically, the guidance addresses the provisions in the Cures Act amending the FDC Act to exclude certain types of software functions from the definition of a medical device.4

This new guidance proposes updates to the following existing FDA guidance documents to reconcile them with the new law:

  • General Wellness: Policy for Low Risk Devices
  • Mobile Medical Applications
  • Off-The-Shelf Software Use in Medical Devices
  • Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices

The draft Changes Guidance provides specific proposed revisions to each of the above guidance documents, largely focused on clarifying the types of products that will no longer be regulated by FDA as a medical device, as well as where FDA will focus its enforcement activities.

In large part, these changes simply align with the Cures Act carve outs for certain types of software. Accordingly, examples or product discussions in each of these guidance documents related to administrative support, general wellness, electronic records, and medical device data functions of transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results will be clearly delineated as outside the scope of FDA regulation.For example, one such functionality that is now not considered a medical device is software that allows for the display of medical images for non-diagnostic use, as long as such software contains a persistent on-screen notice that the display is intended for informational purposes and is not intended for diagnostic use.

FDA also proposes certain enforcement priorities for software functions that are intended to serve as electronic patient records. Section 520(o) of the amended FDC Act outlines three requirements for software serving as electronic patient records to be excluded from the definition of a medical device, including: (1) the involvement of a healthcare professional in the creation, storage, transfer or review of the record; (2) certification of the associated information technology for the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program; and (3) the software functions are not intended for interpretation or analysis of patient records for purposes of diagnosis, cure, mitigation, prevention or treatment of a disease or condition. However, FDA notes that it will not enforce the ONC certification requirement if the software functions meet the other criteria. The Agency also clarifies that personal health records where a healthcare professional is not involved would not be considered medical devices because such records are not intended for use in the diagnosis, cure, mitigation, prevention or treatment of a disease or condition.

Regarding software functions that are intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition,” FDA indicates that it will interpret this exclusion from the device definition consistent with those devices for use in maintaining a “general state of health or health activity”, as provided in the General Wellness guidance. The General Wellness guidance defines two categories of general wellness products: (1) maintaining or encouraging a general state of health or a healthy activity; and (2) relates to the role of a healthy lifestyle with helping to reduce the risk or impact of a certain chronic disease or conditions where healthy lifestyle choices may impact health outcomes. The Changes Guidance provides that the second category of general wellness products would not be excluded from the definition of a device. That being said, the agency notes that it will continue to exercise enforcement discretion for this category of general wellness products, where the functionality presents low safety risks.

FDA also proposes to update the Medical Device Data Systems guidance to indicate that medical device data systems (MDDS), medical image storage devices and medical image communications devices meeting the criteria outlined in the new Section 520(o) of the FDC Act are no longer considered to be medical devices. In the same vein, medical image management devices, as discussed in the Guidance for the Submission of Premarket Notifications for Medical Image Management Systems, are no longer medical devices and accordingly, the agency intends to withdraw this guidance. Interestingly, the definition of the MDDS products provided in the historical guidance and in the classification regulation (21 C.F.R. § 880.6310) compared to the definition provided in the amended FDC Act are somewhat different, where the revised statutory language has expanded text defining MDDS systems as “software, electronic, or electrical hardware” and notes that the definition applies regardless of whether or not the transfer, storage, conversion or display of the data is “for immediate clinical action.” The Changes Guidance notes that the new definition will be adopted for the MDDS Guidance however is silent on implementing conforming changes to the MDDS classification regulation.

The new definition does not appear to dramatically impact FDA’s interpretation of when such systems will trigger FDA regulatory jurisdiction. The Changes Guidance notes that if any of the MDDS, medical image storage devices and medical image communications devices analyze or interpret medical device data, generate alarms or alerts, prioritize multi-patient displays, or flag out-of-range parameters, such functionality will bring these products back into FDA’s regulatory purview as medical devices. However, the guidance goes on to note that FDA intends to exercise its enforcement discretion for such low risk devices where the analysis of data that generates a notification is one for which “immediate clinical action” is not needed.

Finally, the Changes Guidance makes reference to one additional related guidance document that will be forthcoming regarding devices with multiple functionalities, where certain of these software functionalities are now considered products outside the definition of a medical device. The guidance appears on CDRH’s priority “A list” of draft guidance documents for 20185 and is expected in Q1 of 2018.

SaMD guidance 

The third guidance released by FDA is a final version of a guidance initially issued in draft form in late 2016. FDA’s SaMD Guidance implements a guidance originally issued by the International Medical Device Regulators Forum (IMDRF) (a global harmonization effort). It is the fourth document in a four part series addressing Software as a Medical Device, but is the only one in the series to be issued as a U.S. guidance.

In a preface to the final guidance, FDA notes that the guidance is only an adoption of the principles agreed upon by IMDRF, but does not provide recommendations for FDA staff or industry to apply. Rather, FDA notes that the Agency plans to use the concepts to develop further regulatory policy in the U.S. and will do so in a way that provides for public comment. Thus, the concepts in the guidance are not intended for immediate implementation in either regulatory submissions or review. Nonetheless, they are summarized briefly here for completeness.

Consistent with the draft, the final guidance does not (and could not) explain the specific data requirements for each new software product. Such requirements are always based on the specific design of the product and the intended use. However, the guidance does provide a general framework for considering how to approach clinical evaluation given the complexities of medical software. The guidance explains that clinical evaluation encompasses both determining whether there is “a valid clinical association between the output of a SaMD and the targeted clinical condition,” as well as whether the software “provides the expected technical and clinical data.” To these ends, clinical evaluation requires (1) valid clinical association (i.e., extent to which the clinical output is clinically accepted or well founded), (2) analytical / technical validation (i.e., ability to accurately, reliably and precisely generate the intended technical output), and (3) clinical validation of a SaMD.

Like the draft, the final guidance describes four categories of products that are defined by the state of the healthcare situation or condition (non-serious, serious, critical) and the significance of the information provided by the SaMD to the healthcare decision (inform clinical management, drive clinical management, treat or diagnose). The extent to which clinical evaluation is needed is based on the category into which the software falls.

The principles outlined in the final guidance appear to be reasonably consistent with the draft. It will be interesting to see the steps that FDA takes to further implement those principles into U.S. regulatory policy. 


  • The draft CDS Guidance provides some much needed direction on the Cures Act language and where the Agency draws the line between CDS that falls outside the amended definition of a medical device and CDS that is considered a medical device.
  • The draft CDS Guidance creates a corollary for PDS, although it is not quite clear what type of information would be appropriate to convey to patients and caregivers as the basis for recommendations, as a lay person may not have the same ability as a healthcare provider to understand, for example, clinical practice guidelines. 
  • The draft CDS Guidance draws a distinction between software functions that analyze sensor or other data to produce new clinical metrics (regulated) and software functions that use existing clinical metrics to make recommendations based on published guidelines (not regulated).
  • The Changes Guidance largely serves to bring existing guidance documents in line with the Cures Act provisions. In doing so, many examples in the existing guidance documents have been pushed into different regulatory categories to note where products are now outside the definition of a medical device or are subject to FDA’s enforcement discretion.
  • While the Changes Guidance carves out electronic patient records from the definition of a medical device if they are, among other things, certified by ONC, at this time, FDA does not intend to enforce FDA requirements for those that meet all of the criteria but are not certified by ONC. The guidance does not address when or if FDA intends to start enforcing regulatory requirements for those that are not ONC certified.
  • The SaMD Guidance is a first step toward adoption of international consensus principles for implementation in U.S. regulation of this category of software product.
  • Additional guidance will be forthcoming in Q1 2018 further implementing new provisions of the Cures Act with regard to FDA regulation of products incorporating now exempt software functionalities.