Software Classification under MDR Annex VIII Rule 11

1. Key takeaways

Medical device software (MDSW) is classified under Rule 11 of Annex VIII, and the criterion is the clinical consequence of the information provided by the software, not its technical form. Software intended to provide information used to take decisions with diagnosis or therapeutic purposes generally falls into Class IIa; where such decisions may result in death or in an irreversible deterioration of a state of health, it falls into Class III; where they may result in a serious deterioration of health or a surgical intervention, it falls into Class IIb. Software intended to monitor physiological processes is generally in Class IIa, except where monitoring of a vital physiological parameter may result in immediate danger to the patient, in which case it is Class IIb. All other software falls into Class I. The rule therefore reads the software through its intended use and the decisions it informs, which is why the intended purpose statement carries so much weight in every software file.

2. Legal basis

3. Expert insights

Insight 1: Rule 11 replaced technology with clinical consequence as the axis of classification.

Under the previous directive, Directive 93/42/EEC, standalone software was mostly assessed under the rules for active devices and usually landed in low-risk classes. The MDR added Rule 11 and grades software directly by what decisions the information is used for and what happens if the decision is wrong. The result is that the large majority of software providing diagnostic or therapeutic decision information falls at least into Class IIa, which necessarily involves a notified body. This is a cost and a timeline that did not exist in the old regime, and companies migrating from the directive era should rebuild their classification from the ground up rather than carrying old assumptions forward into MDR submissions.

Insight 2: MDCG 2019-11 splits Rule 11 into three sub-rules and narrows Class I.

MDCG 2019-11 presents Rule 11 as three sub-rules: 11a for information used to take decisions with diagnosis or therapeutic purposes, 11b for monitoring physiological processes or parameters, and 11c for other purposes, and it maps the rule against the SaMD risk framework of the IMDRF. The practical outcome is that the space available for Class I software has been compressed into a narrow range, covering functions such as certain conception support and communication assistance features. A company that self-classifies as Class I on the argument that it is only a tool software needs a traceable justification for that position, because notified bodies routinely test Class I software claims against the sub-rules.

Insight 3: Implementing rule 3.3 stacks with Rule 11, and the higher class applies.

Software that drives or influences the use of another device falls into the class of that device; software independent of other devices is classified in its own right. A software product can therefore trigger both routes simultaneously, and the final classification follows the higher class. This matters for embedded and companion software: a control module inside a certified pump, and the standalone analytics dashboard built on its data, may sit in different classes under different routes even though they share one codebase. The route analysis must be documented before the assessment plan is fixed.

Insight 4: COM(2025) 1023 proposes to adjust the classification rules, but Rule 11 remains the current text.

In its simplification proposal submitted on 2025-12-16, the European Commission proposed adjustments to several classification rules of the MDR, including Rule 11. The proposal has not been adopted by the European Parliament and the Council under the ordinary legislative procedure and is not binding. Current projects must still be executed under Rule 11 and MDCG 2019-11, and no classification may be lowered in advance on the basis of the proposal. Companies should monitor the file, but plan and budget against the rule text in force, since adopting the proposed relaxation early would create non-compliant documentation and a rework burden if the proposal changes during the legislative process.

4. Practical recommendations

1. First perform the qualification: does the software fall within the definition of Article 2(1)? Only then perform the classification.
2. Build the classification reasoning around intended purpose and decision consequence, stating the information flow and the clinical consequence assumptions.
3. When citing MDCG 2019-11, label it as an interpretive document and keep a record of the applicability of the sub-rules (11a, 11b, 11c).
4. For combination products (hardware plus software), classify each component and set the overall class at the higher of the two.
5. Establish a review node for Rule 11: any change in the intended purpose triggers a new classification.

5. Verification checklist

• □ Software qualification has been completed (Article 2(1))
• □ A classification conclusion has been given under the three paragraphs of Rule 11
• □ The applicability of the MDCG 2019-11 sub-rules (11a, 11b, 11c) has been recorded
• □ The driving or standalone route has been determined under implementing rule 3.3
• □ The overall classification of combination products has been set at the higher class
• □ COM(2025) 1023 is marked as a pending proposal and no classification has been adjusted on its basis

Regulatory information verified as of 29 October 2026.

About GRZAN. GRZAN supports software manufacturers through qualification and classification under Regulation (EU) 2017/745, from the Article 2(1) qualification file to the Rule 11 classification and the notified body submission that follows. We track the legislative files that may reshape the classification rules, keep your documentation aligned with the text in force, and design CE marking routes for the European Union that survive regulatory change. For software projects entering the EU MDR market, contact info@grzanglobal.com.