Clinical Decision Support Software Frequently Asked Questions (FAQs)
Clinical Decision Support (CDS) software are important tools in modern health care. While some CDS software has been excluded from the definition of a medical device by the 21st Century Cures Act (Cures Act), many software functions continue to meet the definition of a medical device and are the focus of the Food and Drug Administration’s (FDA) regulatory oversight. Because a wide variety of software can be described as “decision support,” understanding the regulatory requirements that may apply to such software can be challenging.
On this page:
- FDA’s CDS Guidance
- Digital Health Policy Tool
- Frequently Asked Questions (FAQs)
- Resources Cited in this FAQ
- Contact Us
FDA’s CDS Guidance
The FDA published the final guidance, “Clinical Decision Support Software” (CDS Guidance), in September 2022 to provide clarification on the Agency’s interpretation of the types of CDS software functions that are excluded from the definition of device by the criteria in section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act, or FD&C Act (“Non-Device CDS criteria”). The guidance also includes helpful examples of software that would be considered Non-Device CDS software, as well as examples of software that may provide decision support but continue to meet the definition of a medical device. A general summary overview of the guidance and interpretation of the Non-Device CDS software criteria can be seen below.
Your Clinical Decision Support Software: Is It a Device?
The FDA issued a guidance, Clinical Decision Support Software, to describe FDA’s regulatory approach to Clinical Decision Support (CDS) software functions. This graphic gives a general and summary overview of the guidance and is for illustrative purposes only. Consult the guidance for the complete discussion and examples. Other software functions that are not listed may also be device software functions.
Your software function must meet all four criteria to be considered Non-Device CDS.
Summary Interpretation of CDS Criteria
- Your software function does NOT acquire, process, or analyze medical images, signals, or patterns.
- Your software function displays, analyzes, or prints medical information normally communicated between health care professionals (HCPs).
- Your software function provides recommendations (information/options) to a HCP rather than provide a specific output or directive.
- Your software function provides the basis of the recommendations so that the HCP does not rely primarily on any recommendations to make a decision.
If all four criteria are met, your software function may be non-device CDS.
Non-Device Examples
According to criteria 1 and 2: Non-Device examples display, analyze, or print the following examples of medical information, which must also not be images, signals, or patterns:
- Information whose relevance to a clinical decision is well understood
- A single discrete test result that is clinically meaningful
- Report from imaging study
According to criterion 3, non-device examples provide:
- Lists of preventive, diagnostic, or treatment options
- Clinical guidances matched to patient-specific medical info
- Relevant reference information about a disease or condition
According to criterion 4, non-device examples for provide:
- Plain language descriptions of the software purpose, medical input, underlying algorithm
- Relevant patient-specific information and other knowns/unknowns for consideration
Your software function must meet all four criteria to be Non-Device CDS.
Device Examples
According to criterion 1: Device examples acquire, process, or analyze:
- Signal acquisition systems
- In vitro diagnostics
- Magnetic resonance imaging (MRI)
- Next Generation Sequencing (NGS)
- Continuous Glucose Monitoring (CGM)
- Computer aided detection/diagnosis (CADe/CADx)
According to criterion 2: Device examples display, analyze, or print:
- Continuous signals/patterns
- Medical images
- Waveforms (ECG)
- More continuous sampling (aka – a signal or pattern)
According to criterion 3: Device examples provide:
- Risk scores for disease or condition
- Probability of disease or condition
- Time-critical outputs
According to criterion 4: Device examples:
- Basis of recommendations is not provided
If any one of the 4 criteria is not met, your software function is a device.
Importantly, the guidance did not bring new software functions under the focus of the FDA’s regulatory oversight as devices. The FDA has long regulated the types of software functions that are described as devices in the CDS guidance. In addition, the FDA has published several other guidances describing software functions that are excluded from the definition of a device, are functions for which the Agency intends to exercise enforcement discretion or are functions that continue to meet the definition of a device and are the focus of the FDA’s regulatory oversight. It is important to consider that the CDS guidance is one of several guidances that can help determine whether or not a software function meets the definition of a device and should not be used as the sole reference. Sometimes software can be helpful to support clinical decision making but the Non-Device CDS criteria do not directly relate to the software function’s purpose, so additional considerations are needed to determine its regulatory status. In general, and in these cases, it can be helpful to consider other digital health policies that may apply.
Digital Health Policy Tool
To learn more about digital health polices and regulatory considerations used to determine whether the FDA regulates a certain software function and if it is the focus of FDA’s oversight, consider visiting the FDA’s Digital Health Policy Navigator. The Digital Health Policy Navigator tool includes a collection of guidances that describe how the FDA intends to apply its device regulatory authority to software functions and can be used to walk through these policies with your product in mind. The Navigator includes seven steps, each with a set of questions intended to be answered for each of your product's software functions. Your answers to these questions will help guide you to relevant FDA medical device regulatory considerations.
Frequently Asked Questions (FAQs)
While not an exhaustive list, below are some frequently asked questions (FAQ) about software functions that may be described as “decision support.” These FAQs are intended to help sponsors identify whether their CDS software may or may not meet the definition of a device and provide additional resources specifically to those developing CDS software tools.
A: Yes, software functions that are only meant to provide an electronic means of distributing, completing, and sharing a well-understood survey are not medical devices. For example, software functions that provide patients with simple tools to organize and record their health information or are specifically marketed to help patients document, show, or communicate to health care professionals regarding potential medical conditions are not medical devices (see “Policy for Device Software Functions and Mobile Medical Applications” Appendix A, Example 12). Additionally, software functions that automate simple tasks for health care professionals are generally functions for which FDA would exercise enforcement discretion (meaning they are software functions that may meet the definition of a medical device, but because they pose a lower risk to the public, FDA does not, at this time, intend to enforce requirements under the FD&C Act) if they do meet the definition of a device.
A: Software that is meant to perform simple medical calculations routinely used in clinical practice is not considered within the scope of the Non-Device CDS policy. However, the FDA intends to exercise enforcement discretion for these functions, as they automate simple tasks for health care professionals and can be calculated manually if needed (see guidance “Policy for Device Software Functions and Mobile Medical Applications,” example 3 on page 14).
While not an exhaustive list, the following are examples of simple medical calculations:
- Body Mass Index (BMI)
- Total Body Water/Urea Volume of Distribution
- Mean arterial pressure
- Glasgow Coma Scale score
- APGAR score
- NIH Stroke Scale
- Delivery date estimator
A: Software that is meant to support time-critical decision making do not meet the definition of Non-Device CDS. Often, time sensitive or critical outputs detect life-threatening and/or time critical conditions and may generate an alarm or an alert to notify a health care professional. This can include conditions such as ventricular fibrillation detection, sepsis, or even stroke (see guidance “Policy for Device Software Functions and Mobile Medical Applications,” example 3 on page 13). In such situations, it is difficult to support that a clinician is not meant to solely rely on a provided recommendation or that the clinician will spend time to understand its specific basis. Therefore, these kinds of software generally cannot meet all the criteria for Non-Device CDS software.
However, intending that a software be used in time critical settings, such as the emergency department, does not mean the product cannot be a Non-Device CDS software. For example, software that automatically pulls up relevant patient information, such as recent lab results or medication history, when a clinician goes to place an order for tests can enhance decision-making efficiency. Such software used in a setting where time critical decision-making occurs could still be considered Non-Device CDS software (see guidance “Policy for Device Software Functions and Mobile Medical Applications,” example 11 on page 21 in Appendix A).
A: No, there are many software functions that fail one or more of the four Non-Device CDS criteria and still are not software functions that fall within the definition of a medical device or are device functions for which the FDA intends to exercise enforcement discretion. We recommend reviewing the guidance document “Policy for Device Software Functions and Mobile Medical Applications” to help determine if your software may be one that is not a device or for which FDA intends to exercise enforcement discretion, beyond the policy described in the CDS guidance. If a software function does not meet one of the four exclusion criteria specified in the CDS guidance, the "Policy for Device Software Functions and Mobile Medical Applications" provides additional context, criteria, and examples to help manufacturers understand when a software function may or may not be subject to FDA oversight. In addition, the Digital Health Policy Navigator tool is another resource that describes how FDA intends to apply its device regulatory authority to software functions and can be used to walk through these policies with your product in mind.
A: The FDA understands that many software products have more than one function. Consistent with the FD&C Act, as amended by the Cures Act, the FDA reviews “device functions” in products with multiple functions and will consider the impact of other functions that are not device functions on the “device-function(s)-under-review.” Thus, it is possible to have a software product with both Non-Device CDS functions as well as device functions that are the focus of the FDA’s oversight.
The guidance “Multiple Function Device Products: Policy and Considerations” outlines the FDA’s approach to products that have both device functions and “other functions” that are not the FDA’s focus. When reading these recommendations, it’s important to remember that the FDA uses the word “function” in this context to mean a distinct purpose of the product, which may be the product’s intended use or a subset of the intended use. “Functions,” in this case, aren’t inherently associated with a software product’s architecture.
In addition to guidance documents “Clinical Decision Support Software” and “Policy for Device Software Functions and Mobile Medical Applications,” we recommend using the Digital Health Policy Navigator tool to determine whether the FDA regulates each software function in a product with multiple functions and if it is the focus of FDA’s regulatory oversight.
A: No, providers of tools, services, or infrastructure used in the development, distribution, or use of software with a medical function are not considered device manufacturers to the FDA. Examples include internet service providers, providers of general-purpose computer or information technology, or providers that host the web service for content or software applications.
However, even if a developer is not a device manufacturer according to the FDA, other laws and regulations may apply. For example, both the Federal Trade Commission and the HHS Office of the National Coordinator for Health Information Technology have worked in cooperation with the FDA to identify additional requirements, documentation, and U.S. laws that may apply to your software. You can learn more by using the Mobile Health App Interactive Tool.
It is important to note that those who develop software tools that are the focus of FDA regulatory oversight as devices on one of these platforms are considered device manufacturers even if the platform developer may not be. Additionally, a developer that is providing users access to a medical device software through a website subscription, software as a service, or other similar means, is also considered a device manufacturer. Therefore, it is important to consider if a platform or service is providing access to software functions that may be the focus of FDA’s regulatory oversight (see guidance “Policy for Device Software Functions and Mobile Medical Applications,” section E on pages 8-9).
A: The Assistant Secretary for Technology Policy / Office of the National Coordinator (ASTP/ONC) recently published its final rule on the “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1)” in which it defined predictive DSI and a number of intervention risk management (IRM) requirements regarding predictive DSI supplied by developers of certified health IT as part of their products. ASTP/ONC has defined predictive DSIs as “technology intended to support decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.”
Please note that some predictive DSIs may meet the definition of a device in section 201(h) of the FD&C Act, while others may not. If the predictive DSI meets the definition of a device, it must comply with applicable FDA laws and regulations. To the extent predictive DSIs could be considered to provide clinical decision support, manufacturers of such software should consult FDA’s “Clinical Decision Support Software Guidance” for assistance in assessing whether their software might be excluded from the definition of a device.
For more information about predictive DSI and the criteria for certifying health IT products with decision support functionalities under the ONC Health IT Certification Program, you can consult ONC’s guide, Decision Support Interventions (DSI) Criterion Resource Guide.
Resources Cited in this FAQ
- FTC Mobile Health App Interactive Tool
- ONC’s HTI-1 Final Rule
- 9 Key Functionalities and Requirements of the New (b)(11) DSI Criterion
- Clinical Decision Support Software
- Policy for Device Software Functions and Mobile Medical Applications
Contact Us
The Digital Health Center of Excellence (DHCoE) is also happy to further assist you on your questions regarding FDA’s digital health policies via our inbox. If you are seeking more specific feedback about a particular medical device, we suggest you consider exploring the Pre-Submission process in the FDA guidance “Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program."