When Regulation (EU) 2017/745 (MDR) started to apply on 26 May 2021, it brought in Rule 11, a classification rule written specifically for software (MDR; European Commission Q&A). Since then the guidance has kept moving: MDCG 2019-11 Rev.1 on the qualification and classification of software was published in June 2025, FDA revised its Clinical Decision Support Software guidance in January 2026, and Regulation (EU) 2026/1744 has reset the dates on which the AI Act’s high-risk requirements apply to AI in medical devices (MDCG 2019-11 Rev.1; FDA; Regulation (EU) 2026/1744).
For software manufacturers, the medical device classifications that apply are therefore no longer a single question. In this post we look at how software is classified under the MDR, the IVDR and FDA’s system, and how the AI Act builds on that result. The general mechanics of both systems are covered in our article on the classification of medical devices in the EU and US; here the focus is on software and AI.
Classification comes after qualification
Before any class can be assigned, the software has to be a device. Under the MDR and IVDR, MDCG 2019-11 Rev.1 sets out how to decide whether software qualifies as medical device software (MDSW), starting from the manufacturer’s intended purpose (MDCG 2019-11 Rev.1). In the US, section 520(o) of the FD&C Act, added by the 21st Century Cures Act of 13 December 2016, excludes certain software functions from the device definition, and FDA’s Clinical Decision Support Software guidance explains how it reads the criteria for non-device clinical decision support (FDA).
The order matters. A classification rationale that starts at Rule 11 without first establishing that the software is a device, and which part of it is, rests on an assumption the notified body or FDA will test first.
The EU MDR: Rule 11 and the implementing rules
Article 51 of the MDR divides devices into classes I, IIa, IIb and III and requires classification under Annex VIII (MDR). For software, three provisions do most of the work (MDCG 2019-11 Rev.1).
Rule 11 has three parts:
-
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is in class IIa, except where such decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health (class III), or a serious deterioration of a person’s state of health or a surgical intervention (class IIb).
-
Software intended to monitor physiological processes is in class IIa, except where it is intended for monitoring vital physiological parameters and the nature of variations of those parameters could result in immediate danger to the patient (class IIb).
-
All other software is in class I.
Implementing rule 3.3 adds that software which drives a device or influences the use of a device falls within the same class as that device, while software that is independent of any other device is classified in its own right. Implementing rule 3.5 adds that where several rules or sub-rules apply, the strictest rule and sub-rule resulting in the higher classification applies. MDCG 2021-24 Rev.1 is the general classification guidance that sits alongside these provisions (MDCG 2021-24 Rev.1).
The practical effect is that most software informing diagnostic or therapeutic decisions starts at class IIa, which means a notified body is involved in the conformity assessment. We set out what that route involves in our article on the CE mark for a medical device.
The EU IVDR: software that is an IVD
Software can also be an in vitro diagnostic medical device. Under Article 47 of Regulation (EU) 2017/746 (IVDR), IVDs are divided into classes A, B, C and D, taking into account their intended purpose and inherent risks, and classified under Annex VIII of the IVDR (IVDR). MDCG 2019-11 Rev.1 covers the qualification and classification of software under both regulations, and explains when software is MDSW under the MDR or under the IVDR (MDCG 2019-11 Rev.1).
The structure differs from the MDR in one important respect: the IVDR has no equivalent of Rule 11. Software that is an IVD is classified using the same IVDR rules as any other IVD, based on its intended purpose, with the IVDR’s own implementing rule assigning software that drives or influences a device to the class of that device. A manufacturer that has worked only with the MDR should therefore not carry its Rule 11 reasoning into an IVDR file.
The United States: one system for hardware and software
FDA does not have a software-specific classification rule. It has classified approximately 1,700 generic types of devices in 16 medical specialty panels in 21 CFR Parts 862 to 892, and a software function that is a device is classified in the same way as any other device: by finding the classification regulation whose description matches its intended use and indications for use (FDA, Classify Your Medical Device). FDA uses the IMDRF definition of software as a medical device, “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device” (FDA, SaMD).
Where no existing classification regulation fits, the device is a postamendments device and is automatically placed in Class III under section 513(f)(1), until it is classified through the De Novo process under section 513(f)(2), reclassified, or found substantially equivalent to a predicate that does not require premarket approval (FDA, Reclassification). For novel software functions, that makes the De Novo pathway a realistic outcome of the classification question rather than an exception (FDA, De Novo). Where the answer is unclear, a 513(g) request gives FDA’s formal view, for a user fee (FDA).
The AI layer
The AI Act, Regulation (EU) 2024/1689, does not replace any of the above. It builds on it. An AI system is high-risk under Article 6(1) where it is, or is a safety component of, a product covered by the Union harmonisation legislation in Annex I, which includes the MDR and IVDR, and that product requires third-party conformity assessment (AI Act; MDCG 2025-6).
In other words, the MDR or IVDR class largely answers the AI Act question. MDCG 2025-6 sets out the outcome by class:
| MDR / IVDR class | Notified body involved | Article 6(1) AI Act conditions met |
|---|---|---|
| MDR class I (non-sterile, non-measuring, not reusable surgical) | No | No |
| MDR class I sterile, measuring or reusable surgical | Yes | Yes |
| MDR class IIa, IIb, III | Yes | Yes |
| IVDR class A (non-sterile) | No | No |
| IVDR class A sterile | Yes | Yes |
| IVDR class B, C, D | Yes | Yes |
Source: MDCG 2025-6, Table 1.
MDCG 2025-6 also makes clear that high-risk status under the AI Act does not change the device’s MDR or IVDR class. On timing, Regulation (EU) 2026/1744 moved the date from which the high-risk requirements apply to AI covered by Article 6(1) and Annex I, which includes medical devices, to 2 August 2028; MDCG 2025-6, published in June 2025, still refers to the earlier date because it predates the amendment (Regulation (EU) 2026/1744). We covered the wider interplay in our article on AI Act requirements for medical devices.
Medical device classifications for software compared
| Question | EU MDR | EU IVDR | US FDA |
|---|---|---|---|
| Classes | I, IIa, IIb, III (Art. 51) | A, B, C, D (Art. 47) | I, II, III (section 513) |
| Software-specific rule | Rule 11 | None; IVDR rules apply as for any IVD | None; device-type classification regulations |
| Software driving or influencing a device | Same class as that device (rule 3.3) | Same class as that device | Classified with the device type |
| Several rules apply | Strictest rule applies (rule 3.5) | Highest applicable class | Not applicable |
| No match | Not applicable | Not applicable | Automatically Class III; De Novo or PMA |
| AI layer | AI Act Art. 6(1) if a notified body is involved | AI Act Art. 6(1) if a notified body is involved | Not applicable |
Sources: MDR, IVDR, MDCG 2019-11 Rev.1, MDCG 2025-6; FDA, Classify Your Medical Device and Reclassification.
There is no one-to-one mapping between these classes. A US Class II software function is not the same thing as an EU class IIa or IIb device, and each market needs its own rationale.
Example: an AI tool for imaging
To show how the layers combine, take a hypothetical case. A company develops AI software that analyses CT images and flags suspected findings for a radiologist to review.
In the EU, the company first establishes that the software is MDSW under the MDR, following MDCG 2019-11 Rev.1. Rule 11 then applies: the software provides information used to take decisions with diagnostic purposes, so it is at least class IIa, and the analysis has to show whether the impact of those decisions puts it in class IIb or III. Because a class IIa or higher device needs a notified body, the AI system meets the Article 6(1) conditions and is a high-risk AI system under the AI Act, with those requirements applying from 2 August 2028.
In the US, the company compares the software’s intended use and indications for use with the identification text of candidate classification regulations. If one matches, the regulation sets the class and the premarket route; if none does, the software is automatically in Class III, and De Novo becomes the realistic route. If the answer is uncertain, a 513(g) request settles it before the submission strategy is fixed.
The same code ends up with three answers: an MDR class, an AI Act status and an FDA class, each reached through a different test. What links them is the intended purpose statement, which is why it deserves the most care.
Keeping the classification current
Software changes faster than hardware, and every release can touch the intended purpose. A new output, a new user group, a new clinical claim or a model update that changes what the software is used to decide can move it to another Rule 11 tier, another FDA classification regulation, or into the AI Act’s scope. In our view, the classification rationale for software belongs under change control, reviewed against the intended purpose at every release, not only at the first submission. Our SaMD technical documentation checklist shows where that rationale sits in the technical file.
Conclusion
For software and AI, medical device classification is a sequence: qualification first, then the MDR or IVDR class, then the AI Act status in the EU, and a separate device-type classification in the US. The MDR’s Rule 11 places most decision-support software in class IIa or higher, the IVDR has no software-specific rule, FDA classifies software through the same regulations as any other device, and the AI Act takes its answer largely from the MDR or IVDR class. In our view, the manufacturers that handle this well are the ones that write one controlled intended purpose and then run each framework’s test against it separately, rather than translating one market’s answer into another.
Our advice is simple: settle qualification before classification, document every rule considered, map the AI Act status from the MDR or IVDR class, and treat each software release as a potential classification change. If you need help building that rationale, our regulatory strategy team can support you, or you can contact the MedQAIR team.
Frequently asked questions
Is all medical software class IIa or higher under the MDR?
No. Under Rule 11, software that provides information used for diagnostic or therapeutic decisions, or that monitors physiological processes, starts at class IIa, but all other software is class I. Software that drives or influences a device takes the class of that device (MDCG 2019-11 Rev.1).
Does Rule 11 apply to software IVDs?
No. Rule 11 is an MDR rule. Software that qualifies as an IVD is classified into classes A to D under Article 47 and Annex VIII of the IVDR (IVDR; MDCG 2019-11 Rev.1).
Does FDA have a classification rule for software?
No. FDA classifies software functions that are devices under the same device-type classification regulations in 21 CFR Parts 862 to 892 as other devices; where none fits, the device is automatically Class III until classified through De Novo or another route (FDA; FDA, Reclassification).
Does the AI Act change my device’s MDR class?
No. MDCG 2025-6 states that high-risk status under the AI Act does not change the MDR or IVDR class; it is the MDR or IVDR class, through notified body involvement, that determines whether Article 6(1) applies (MDCG 2025-6).
When do the AI Act’s high-risk requirements apply to AI in medical devices?
From 2 August 2028, following Regulation (EU) 2026/1744, which moved the original date of 2 August 2027 (Regulation (EU) 2026/1744).
