The U.S. Food and Drug Administration (FDA) issued significant revised guidance in January 2026 concerning Clinical Decision Support (CDS) software. This update is crucial for digital health innovators and AI developers, as it clarifies the conditions under which CDS software will not be regulated as a medical device. This potential exclusion from regulation could allow developers to bring tools to market with less extensive oversight than typically required for medical devices. The updated guidance builds upon the 21st Century Cures Act and defines a four-point test that CDS tools must meet to be excluded from the statutory definition of a medical device under U.S. law.
To avoid classification as a regulated medical device, a CDS software function must satisfy all four statutory criteria. Firstly, the function must be Non-Image/Non-Signal, meaning it must not be intended to acquire, process, or analyse medical images, signals (such as from sensors), or patterns from repeated measurements. Tools that analyse medical images, for example, will continue to be regulated. The second criterion requires the software to Display or Analyse Medical Information—such as EHR data or clinical guidelines—about a patient or medical facts. Critically, it must do this without making automated diagnostic or predictive interpretations.
The third requirement is that the software must Support Clinical Decision-Making by providing support or recommendations to a healthcare professional (HCP) regarding prevention, diagnosis, or treatment. The 2026 update specifically broadens this to include tools offering even a single, clinically appropriate option, a relaxation of previous interpretations. Finally, the most important criterion is Enable Independent Review (Transparency), which mandates that the tool must allow the HCP to independently review the basis of the recommendation (e.g., its logic and data). This ensures the clinician does not primarily rely on the software’s output for patient decisions, emphasising transparency, explainability, and the preservation of clinician judgement. Failure to meet even one of these four criteria will result in the software function being considered a regulated medical device, requiring compliance with standards like 510(k) clearance or De Novo classification.
The clarification provided by the FDA is vital for innovators, especially those targeting the U.S. market, as previous regulatory ambiguity often resulted in slowed investment or unnecessary, costly regulatory submissions. With these clearer rules, development teams can now design products from the start to align with Non-Device CDS expectations, optimising their time and resources. A core focus of the 2026 guidance is the twin theme of transparency and explainability. The FDA requires developers to provide plain-language descriptions of input requirements, data sources, logic, and validation methods underpinning their tools. This requirement is intended to mitigate automation bias, preventing clinicians from over-relying on automated outputs without fully understanding the underlying recommendation basis. Developers must remember that software functions analysing complex patterns, medical images, or continuous signals—such as AI models that infer diagnoses—remain firmly within the FDA’s device regulatory framework, necessitating compliance with quality management systems, clinical evidence, and regulatory submissions.
