Between Brussels and Washington: The Regulatory Maze of Clinical Decision Support Software

Verena Wieser profile image
12 min read

Article Summary

CDSS faces stricter classification in the EU under MDR Rule 11, often placing even low-risk tools into higher-risk categories. In the US, the FDA allows certain CDSS to avoid medical device status if they meet four criteria focused on data type, intended use, human oversight, and transparency. Developers are encouraged to follow core software and risk-management standards to ensure safety and support multi-market deployment.

Introduction

This article provides a concise overview of key regulatory considerations for Clinical Decision Support Software (CDSS) across the EU and the US. It aims to bring clarity to a complex international framework that continues to evolve alongside rapid technological innovation. 

Few technologies align as naturally with the needs of modern healthcare as AI-driven CDSS. By processing vast amounts of medical data and translating it into actionable insights, these systems have the potential to support clinical decisions with greater speed, consistency, and scale than ever before.

What Makes Clinical Decision Support Software Unique? 

So, what distinguishes CDSS from other medical device software?  While both CDSS and other medical software can be stand-alone applications, their purposes differ. Medical device software typically performs or controls medical functions such as diagnosis, treatment execution, physiological monitoring, or device operation. In contrast, CDSS supports – but does not replace – healthcare professionals in making clinical decisions. It processes patient data (e.g., lab results, imaging, medical history), applies medical guidelines or algorithms, and generates outputs such as alerts, recommendations, or treatment options. 

How is CDSS Regulated in the EU?

Let’s take a closer look at the EU market and its requirements for CDSS. Since CDSS is considered medical device software, the relevant information for determining the correct classification is most likely found in the much-discussed and often feared Rule 11. 

Why is Rule 11 So Challenging for CDSS Developers?

Rule 11 has gained a reputation for being particularly strict because it significantly expands the range of software that falls into higher-risk classes. In fact, once software is considered a medical device – meaning it is intended to diagnose, monitor, or treat a medical condition – it almost automatically qualifies as at least class IIa. As a result, classification as Class I is rarely possible, since the definition of a medical device already aligns with the criteria for higher-risk classification under Rule 11. This triggers more stringent regulatory obligations, including oversight by a notified body and the certification of the quality management system. 

Can CDSS Ever Be Classified as Class I Under the MDR?

For many CDSS applications, a class IIa classification appears overly strict given the actual risk involved. While regulators have yet to address this issue, one often seek ways to justify a lower classification, ideally class I. A logical starting point is the available guidance documents. 

Does EU Guidance Offer Any Flexibility?

The updated MDCG 2019-11 Guidance (June 2025) defines CDSS as computer-based tools that combine general medical information and patient-specific data to support diagnosis, prognosis, monitoring, or treatment decisions. It confirms that CDSS generally qualifies as a medical device but provides no criteria for classification.

A review of MEDDEV 2.1/6 yields identical wording, offering no additional flexibility. As a result, even low-risk CDSS are effectively treated on par with higher-risk tools such as diagnostic image viewers or ECG analysis apps, leaving class IIa as the prevailing classification. 

How Does the FDA Approach CDSS Regulation?

Feeling somewhat discouraged, we turn away from the EU market and take a closer look at what the FDA expects from CDSS. We come across the promising-sounding guidance document Clinical Decision Support Software. This guidance aims to clarify the boundary between regulated medical devices and non-device software, while promoting innovation in clinical decision support without imposing unnecessary regulatory burdens. It focuses on software intended to assist healthcare professionals in making well-informed decisions about patient care — for example, by providing: 

  • Medication recommendations
  • Alerts about contraindications
  • Prognostic assessments 

What Are the FDA’s Four Criteria for Non-Device CDSS?

The core purpose of a CDSS is to support, not replace, clinical decision-making. To avoid being classified as a medical device, a CDSS must meet four specific criteria. 

The first is straightforward: a CDSS is considered a medical device if it analyses or interprets medical images, signals, or patterns. The FDA distinguishes these by sampling frequency — a single discrete result (e.g., a blood glucose test) counts as medical information, while continuous readings represent a signal or pattern. 

The second criterion states that the CDSS must only display, analyse, or print medical information about a patient or other established medical sources. Such data typically reflects information shared among healthcare professionals during clinical decision-making. When this type of information serves as input, the function is generally not considered a device function 

The FDA emphasises in criterion three that the healthcare professionals are only to be supported in their decision but never to be replaced. The FDA interprets criterion three as referring to software that provides healthcare professionals with condition-, disease-, or patient-specific recommendations intended to support, inform, or influence clinical decision-making — without replacing or directing the healthcare professional’s judgment. 

Why Does the FDA Emphasise Human Oversight and Transparency?

The guidance highlights the risk of automation bias — the tendency to over-rely on automated recommendations. In CDSS, this can lead to errors of commission (acting on incorrect advice) or omission (failing to act without a prompt), especially when only a single, preselected output is provided. The FDA prefers a prioritised list of options instead of a single preselected output and emphasises that non-device CDSS should not be used for time-critical clinical decisions. Healthcare professionals must have adequate time to review and validate the system’s recommendations.

What Documentation Does the FDA Expect for CDSS?

The final criterion requires CDSS to be transparent and allow users to understand how recommendations are derived. This can be achieved through explainable algorithms, clear presentation of input parameters, and proper source referencing. Such transparency benefits both healthcare professionals and those responsible for post-market surveillance and clinical follow-up. 

The FDA further expects a clear description of the software’s purpose, intended use, target user group, and patient population. CDSS should specify the required medical information, outline how it is obtained, and define its relevance and quality standards. A comprehensible summary of the algorithm’s development and validation, including the logic used, data sources, and clinical evidence, must be provided. Patient-specific inputs and potential data gaps should also be identified. Finally, the system should enable independent verification of its recommendations and present all information in clear, accessible language to support informed clinical decision-making. 

Is Non-Device CDSS Still Expected to Follow Medical Software Standards?

When fulfilling these four criteria the CDSS is not considered a device function and does not fulfil the definition of a medical device. Unfortunately, the guidance does not give any hints how to place such a software on the market. I would recommend even though not being a medical device to develop and maintain the software according to the requirements of IEC 62304, IEC 62366 and ISO 14971. At the end of the day, it’s about developing safe software for patients. Especially when aiming to launch the software across multiple markets, adhering to the relevant standards is essential.

Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.

Get It Done, With Certainty.

Contact us about your testing requirements, we aim to respond the same day.

Get resources & industry updates direct to your inbox

We’ll email you 1-2 times a week at the maximum and never share your information