A clinical decision support system is a medical device under MDR Article 2(1) when it processes patient-specific data to inform clinical decisions about diagnosis, prevention, monitoring, prediction, prognosis, or treatment. MDR Annex VIII Rule 11 then places almost every CDSS at Class IIa, Class IIb, or Class III depending on the severity of the decisions the software informs. The MDCG 2019-11 Rev.1 four-step decision flow is the filter that decides where a CDSS lands.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • CDSS qualification follows MDR Article 2(1), with intended purpose defined by MDR Article 2(12) as everything the manufacturer says about the product.
  • Classification follows MDR Annex VIII Rule 11 and is driven by the severity of the clinical decision that the software informs, not by the sophistication of the algorithm.
  • Class IIa is the baseline for decision-support software. Class IIb applies when decisions may cause serious deterioration or a surgical intervention. Class III applies when decisions may cause death or irreversible deterioration.
  • MDCG 2019-11 Rev.1 provides the four-step decision flow that qualifies and classifies CDSS products.
  • Founders who try to argue CDSS down to Class I almost always lose that argument in stage 1 of the notified body audit.

Why CDSS is the highest-friction category in digital health

Clinical decision support is the part of digital health where software directly touches clinical judgment. The product reads patient-specific inputs, applies logic, machine learning, or a rule engine, and returns an output that the clinician or patient uses to make a decision. That decision has consequences.

Tibor has audited several CDSS products across 15 years as a notified body lead auditor and has guided 50+ companies through MDR certification. The pattern he sees most often is founders who underestimate Rule 11. They build a decision-support module thinking it will be Class I because it "only suggests". The first notified body stage 1 review rejects that framing, and the project resets to Class IIa at minimum.

Felix has coached founders through the resulting planning shock. The technical work is usually manageable. The issue is that the team planned the runway, the QMS scope, and the clinical evaluation strategy for a Class I product. A Class IIa CDSS needs a notified body, a full QMS under EN ISO 13485:2016+A11:2021, and clinical evidence that meets MDR Article 61. A Class IIb CDSS adds the notified body design-dossier scrutiny. A Class III CDSS adds the clinical evaluation consultation procedure under MDR Article 54.

What MDR actually says about CDSS

MDR Article 2(1) defines a medical device to include software intended by the manufacturer for a medical purpose including diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. CDSS by definition performs at least one of these functions, because the entire point of the software is to support a clinical decision.

MDR Article 2(12) defines intended purpose as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation. The intended purpose is what qualifies the CDSS as a medical device. It is also what determines the class under Rule 11.

MDR Annex VIII Rule 11 is the classification rule for software. The text places software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes at Class IIa as a baseline. The class escalates to Class IIb when such decisions may cause serious deterioration of a person's state of health or a surgical intervention, and to Class III when the decisions may cause death or irreversible deterioration. Software intended for monitoring of physiological processes is Class IIa unless the monitored parameters are vital and their variation could result in immediate danger, in which case it is Class IIb.

Rule 11 was introduced by the MDR. Under the former Medical Device Directive the same software often sat at Class I, and many founders still operate with the pre-MDR mental model. The up-classification is one of the most commercially significant changes MDR brought to software.

The MDCG 2019-11 Rev.1 four-step flow

MDCG 2019-11 Rev.1 is the authoritative MDCG guidance on qualification and classification of software under MDR and IVDR. The guidance provides a four-step decision flow.

Step 1. Is the product software in the MDR sense? The guidance defines software as a set of instructions that processes input data and creates output data. A CDSS is always software in this sense.

Step 2. Does the software perform an action on data beyond simple storage, archival, communication, or simple search? A product that only stores, transmits, or searches data without processing it is not software in the MDR medical device sense. A CDSS always performs an action on data, because it applies logic to transform inputs into recommendations.

Step 3. Is the action performed for the benefit of an individual patient? The guidance distinguishes between software that supports general administrative tasks or population-level statistics and software that acts on individual patient data. A CDSS is almost always patient-specific.

Step 4. Does the intended purpose match one of the medical purposes listed in MDR Article 2(1)? If the intended purpose is diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, the software is a medical device. If the intended purpose is general wellness, fitness, or administrative workflow, it is not.

A CDSS that answers yes to all four steps is a medical device under MDR and is classified under Rule 11. Tibor's experience is that almost every product that calls itself CDSS passes all four steps. The founders who arrive hoping for a different answer are usually running a product that is not actually CDSS but an information display, a simple calculator used only by the user, or a workflow tool.

Class IIa, IIb, or III: what drives the escalation

Rule 11 drives the class of a CDSS from the severity of the clinical decision the software informs. The notified body reads the intended purpose and the worst-case clinical consequence of a wrong output, then applies the rule.

Class IIa. The baseline for any decision-support software under Rule 11. Applies when the software informs a clinical decision whose worst case is not serious deterioration. Examples in practice: - A medication dosing calculator that suggests a starting dose for a non-critical drug in outpatient care, with clinician review before administration. - A triage support tool that suggests priority categories for non-emergency patients. - A trend detector that flags non-urgent changes in a chronic-disease monitoring context.

Class IIb. Applies when wrong output may cause serious deterioration of a person's state of health or a surgical intervention. Examples: - A decision-support tool that informs chemotherapy dose selection. - A system that recommends whether to proceed with surgical intervention. - An algorithm that informs insulin dose calculation for intensive glycemic management. - A sepsis early-warning system whose output drives escalation of care.

Class III. Applies when wrong output may cause death or irreversible deterioration. Examples: - A closed-loop insulin dosing decision module in a critical care environment. - An algorithm driving automatic adjustment of life-supporting therapy. - A decision-support module embedded in a critical care device where a wrong output directly causes immediate harm.

Tibor's rule of thumb when reviewing a CDSS intended purpose: ask what happens if the software is completely wrong and the clinician follows the output uncritically. If the answer is "the patient has an inconvenient outcome", the class is probably IIa. If the answer is "the patient is seriously harmed", the class is IIb. If the answer is "the patient dies", the class is III.

The argument that a clinician will always catch a wrong output is not a defense against up-classification. Rule 11 looks at the worst case, not at the average clinician.

A worked example: a sepsis early-warning CDSS

A startup builds a sepsis early-warning system. The product ingests vital signs, lab values, and clinical notes from a hospital EHR, applies a machine learning model, and returns a risk score and an alert when the score crosses a threshold. The intended purpose is "early identification of patients at risk of sepsis in acute care settings, to support clinician decisions about escalation and treatment".

Step 1: software in the MDR sense. Yes.

Step 2: action on data beyond storage and transmission. Yes, the product applies an ML model to produce a risk score.

Step 3: patient-specific. Yes, the score is computed for individual patients.

Step 4: medical purpose under MDR Article 2(1). Yes, the purpose is prediction and monitoring of sepsis, which is disease-related.

The product is a medical device. Under Rule 11, the class depends on the worst-case consequence of a wrong output. Sepsis escalation decisions can lead to delayed antibiotic administration, ICU admission decisions, and mortality outcomes. The worst case is serious deterioration, which places the product at Class IIb under Rule 11.

Conformity assessment under MDR Annex IX requires notified body involvement. The technical file must include software lifecycle evidence under EN 62304:2006+A1:2015, risk management under EN ISO 14971:2019+A11:2021, usability engineering, cybersecurity under MDR Annex I §17, and clinical evaluation under MDR Article 61 with supporting clinical data.

Felix has coached founders through exactly this planning reset. Teams that start with "we will be Class I because we only show information" typically need six to twelve weeks to reset their QMS scope, technical file plan, clinical evaluation strategy, and notified body engagement. Teams that start with the correct class on day one spend that same runway on the product.

The Subtract to Ship playbook for CDSS startups

  1. Write the intended purpose paragraph before writing the code. Make it explicit about what clinical decision the output informs and what the worst-case clinical consequence of a wrong output is.
  2. Run the MDCG 2019-11 Rev.1 four-step flow on paper. Record the answers in the QMS.
  3. Assume Class IIa as the starting point. Move up to IIb or III only if the worst-case consequence is clearly more severe. Never assume Class I for a product that processes patient-specific data to inform clinical decisions.
  4. Plan the clinical evaluation early. A CDSS needs clinical data that shows the output is useful and safe in the real clinical context, not just that the model has good cross-validation metrics.
  5. Treat software lifecycle under EN 62304 as a first-class deliverable from the first commit, not a retrofit before the audit.
  6. Integrate the cybersecurity module into the EN ISO 14971 risk management file. A CDSS that runs inside a hospital network is an attack target.
  7. Design for explainability. Notified bodies increasingly ask how the clinician is expected to judge the output. A CDSS that returns a single number with no justification is a harder audit than one that shows the drivers of the recommendation.

Reality Check

  • Has the team written an intended purpose paragraph that explicitly names the clinical decision the CDSS informs?
  • Has the team walked through the MDCG 2019-11 Rev.1 four-step flow and recorded the answers?
  • Has the team named the worst-case clinical consequence of a wrong output and mapped it to a Rule 11 class?
  • Is the planning class consistent with what a notified body would read into the intended purpose, or is the team quietly hoping for a lower class?
  • Is the EN 62304 software lifecycle in place from the first commit, or is it a retrofit plan?
  • Is the clinical evaluation planned around real clinical use, or only around algorithm validation metrics?
  • Is the cybersecurity module integrated with the risk management file under EN ISO 14971:2019+A11:2021?

If more than two of these answers are no, the CDSS is not ready for a stage 1 notified body audit.

Frequently Asked Questions

Can any CDSS realistically be Class I under MDR? In practice, no. Rule 11 sets the baseline for decision-support software at Class IIa. The only way a product that looks like CDSS stays at Class I is if it is not actually decision-support, for example an administrative workflow tool that displays patient data without processing it. The notified body will read the intended purpose and push back on any argument that tries to downclass a genuine CDSS.

What is the difference between Rule 11 Class IIa and Class IIb for CDSS? The difference is the severity of the worst-case clinical consequence. Class IIa applies when the wrong output does not cause serious deterioration. Class IIb applies when the wrong output may cause serious deterioration or a surgical intervention. Tibor uses the "what if the clinician follows the output uncritically" test to place the product.

Does machine learning or AI change the qualification logic? No. MDCG 2019-11 Rev.1 and Rule 11 treat software by intended purpose, not by algorithm type. An AI-based CDSS and a rule-based CDSS land in the same class if they inform the same decision with the same worst-case consequence. AI-specific considerations come in on top of the base qualification, for example in how clinical evaluation, change control, and post-market performance monitoring are planned.

What clinical evidence does a Class IIa CDSS need? MDR Article 61 requires clinical evaluation sufficient to demonstrate conformity with the relevant General Safety and Performance Requirements. For a CDSS, sufficient evidence usually means real-world performance data against a clinical endpoint relevant to the intended purpose, not just offline model validation on a retrospective dataset. The level of evidence scales with the class.

Does the clinician being "in the loop" downgrade the class? No. Rule 11 does not recognize clinician review as a class-lowering factor. The worst-case analysis assumes the clinician acts on the output. Designing the product so that the output is difficult to misread is good practice, and it reduces residual risk, but it does not change the Rule 11 class.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(1), Article 2(12), Annex VIII Rule 11.
  2. MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and Regulation (EU) 2017/746, June 2025.
  3. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.
  4. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.