FDA Clinical Decision Support Software, When CDS Is Not a Medical Device

Clinical Decision Support software, commonly referred to as CDS, plays an increasingly central role in modern healthcare by helping clinicians interpret information, identify risks and consider treatment options. As software becomes more sophisticated, particularly with the integration of machine learning and real-time data analysis, the regulatory boundary between non-regulated clinical support tools and regulated Software as a Medical Device has become more complex. To address this, the FDA issued final guidance clarifying how it interprets the statutory exclusion for certain CDS software functions under the Cures Act. Understanding this guidance is essential for developers, product leaders and regulatory teams because it determines whether a CDS function falls outside FDA medical device regulation or must comply with SaMD requirements.

Scope of the FDA Clinical Decision Support Guidance

The FDA guidance on Clinical Decision Support software focuses specifically on CDS functions intended for use by healthcare professionals. It does not apply to software that provides recommendations directly to patients or caregivers, which are generally considered medical devices and remain subject to FDA oversight. The guidance explains how the FDA interprets the statutory criteria that allow certain CDS functions to be excluded from the definition of a medical device. Only software that meets all four criteria qualifies as Non-Device CDS. If even one criterion is not met, the software function is considered a device and is regulated accordingly. This binary outcome has important implications for software design, data use and product positioning.

The Four Criteria for Non-Device CDS

The statutory exclusion for Non-Device CDS is based on four criteria set out in section 520(o)(1)(E) of the Federal Food, Drug and Cosmetic Act. Each criterion addresses a different aspect of how the software operates and how it influences clinical decision-making.

The first criterion restricts the types of inputs the software may use. To qualify as Non Device CDS, the software must not acquire, process or analyse medical images or signals from in vitro diagnostic devices or from signal acquisition systems. This includes image analysis such as CT, MRI or pathology slides, physiological signal processing such as ECG waveforms or continuous glucose monitoring data and laboratory assay signal processing.

The second criterion defines what inputs are permitted. The software may display, analyse or print medical information about a patient or other medical information. This includes patient demographics, test results, discharge summaries, vital signs, clinical guidelines and peer-reviewed literature. However, the FDA draws a clear distinction between discrete medical information and continuous or time-sensitive data streams, which it considers signals or patterns rather than medical information.

The third criterion focuses on the nature of the recommendation. The software must support or inform a healthcare professional and must not direct or replace clinical judgment. Outputs should present options, considerations or contextual information rather than a single definitive diagnosis or treatment decision, particularly in time-critical situations.

The fourth criterion requires transparency. The software must enable the healthcare professional to independently review the basis for the recommendations. This means the clinician must be able to understand how the software arrived at its output without relying solely on the software itself.

How the FDA Interprets Inputs and Data Sources

The final guidance narrows earlier interpretations of what constitutes acceptable input data. The FDA clarified that patterns include multiple, sequential or repeated measurements of a signal, even if each individual measurement might otherwise be considered medical information. For example, a single blood glucose value is medical information, but continuous glucose monitor data constitutes a signal or pattern. Similarly, certain genetic sequencing data may be considered signal processing rather than simple medical information.

This distinction has significant implications for machine learning driven CDS tools that rely on longitudinal patient data. If the software analyses continuous streams or time-dependent data, it fails the first criterion and is considered a medical device. Developers must therefore carefully assess not only the type of data used but also how it is processed over time.

Supporting Versus Directing Clinical Decisions

The third and fourth criteria are designed to ensure that the healthcare professional remains in control of clinical decisions and that the software does not introduce automation bias. The FDA is concerned that highly automated outputs, especially those that present a single answer or directive, are more likely to replace clinician judgment. Examples include software that outputs a specific diagnosis, calculates a definitive risk score intended to drive treatment or generates urgent alarms that prompt immediate action.

To qualify as Non-Device CDS, the software should provide contextual support rather than direction. This may include highlighting relevant patient information, summarising guidelines, presenting multiple options or identifying potential considerations. The intent is to inform the clinician, not to determine the decision. Time-critical outputs are particularly scrutinised because they increase the likelihood that the clinician will defer to the software rather than exercise independent judgment.

Transparency and Independent Review

Transparency is a cornerstone of the Non-Device CDS framework. The FDA expects developers to provide plain language explanations that allow clinicians to understand the basis of the software recommendations. This includes identifying the required input medical information, describing the underlying logic or algorithm in general terms and explaining how the software was developed and validated.

Developers should also disclose information about data quality, limitations and known uncertainties. The goal is not to expose proprietary algorithms in detail but to provide sufficient context for a clinician to assess whether the recommendation is reasonable. Without this transparency, the software fails the fourth criterion and is considered a device.

Examples of Non-Device CDS Functions

Certain categories of CDS functions are more likely to meet all four criteria when implemented appropriately. These include evidence-based clinician order sets tailored to specific conditions, software that matches patient information to reference guidelines, contextual educational information about diseases, drug interaction and allergy alerts, medication reconciliation tools, duplicate testing warnings and preventive care reminders. Patient data summaries and reports that aggregate existing information for clinician review may also qualify. The common feature of these examples is that they support clinical workflow without analysing signals or directing decisions.

Examples of Regulated CDS Software

By contrast, software that performs image analysis, signal processing or pattern recognition generally does not qualify as Non-Device CDS. This includes software that analyses radiological images, pathology slides, ECG waveforms or continuous sensor data. Software that converts raw laboratory signals into diagnostic results is also considered a device. Additionally, CDS tools that provide specific diagnostic or therapeutic directives, particularly in urgent or time-sensitive contexts, fall under medical device regulation.

Key Changes Introduced by the Final Guidance

The final guidance introduced two important changes compared to earlier drafts. First, it removed the proposed risk-based enforcement discretion approach. This means that regulatory status is now determined strictly by whether the software meets all four criteria, rather than by an assessment of overall risk. Second, the guidance tightened definitions around signals, patterns and specific recommendations, making it more likely that advanced machine learning driven CDS tools will be regulated as SaMD.

These changes increase clarity but also increase the regulatory burden on developers, who must carefully evaluate each software function against the criteria. Mixed functionality products may have some features that qualify as Non-Device CDS and others that do not, requiring a function-level regulatory strategy.

Practical Implications for Developers

Developers should not assume that CDS software is automatically excluded from device regulation. A careful analysis of inputs, outputs and transparency is required. Early regulatory assessment can help identify whether a product or feature set will be regulated and which pathway applies. For products that do qualify as Non-Device CDS, developers should prioritise clear documentation, user-facing explanations and disclosure of logic and limitations. For products that do not qualify, teams should be prepared to engage with existing FDA digital health and SaMD frameworks, including premarket submission where required.

LFH supports software and digital health developers in navigating FDA Clinical Decision Support and Software as a Medical Device regulation. Our team helps assess regulatory status, define compliant product boundaries and build evidence strategies aligned with FDA expectations, supporting confident development and market entry.

FAQs – FDA Clinical Decision Support Software