Is Your Software a Medical Device? MDR Rule 11 and MDCG Guidance

Short answer: Software is Medical Device Software (MDSW) under the EU MDR (Regulation (EU) 2017/745) if its manufacturer intends it for one or more medical purposes (diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease) and it does this by processing data — not merely storing, communicating or performing a simple search. When it qualifies, MDR Rule 11 applies, and most MDSW falls in Class IIa or above. The reference document for qualification is MDCG 2019-11.

Key takeaways

• What decides is not what the software does but the intended purpose the manufacturer states.
• MDSW can be standalone software or software that drives or influences a device.
• Rule 11: software providing information is at least IIa; if a decision could cause serious deterioration or surgical intervention, IIb; if it could cause death or irreversible deterioration, III. Software that only monitors physiological processes is IIa; IIb for vital physiological parameters.
• Health records / scheduling / billing / general wellness software is usually not a medical device.
• AI / machine learning does not change whether software is a device; if it qualifies, the same rules apply, plus expectations on datasets, validation and change management.

This article is part of the What is the EU MDR? pillar and the medical device classification article.

---

Step 1: Is the software "MDSW"? (Qualification)

Following MDCG 2019-11, answer in order:

1. Is the product "software"? (Firmware needed for hardware to run is assessed separately.)
2. Is it an accessory to a device, or does it drive another device? If so, it is already in scope.
3. Does it have a medical purpose of its own? Does it meet at least one of the purposes in MDR Article 2(1)?
4. Does it only store / archive / communicate / simply display data, or does it process / interpret / compute? Storage and communication alone are not "MDSW"; computation or decision support are.
5. Is the benefit for an individual patient? Population-level epidemiology is usually out of scope.

If all five are "yes," your software is likely MDSW.

Examples: MDSW vs not

May be MDSW	Usually not MDSW
Insulin dose calculator	Electronic health record (EHR) system
Lesion detection/measurement on a radiology image	Image storage/communication only in a PACS
Algorithm interpreting an ECG	Appointment and resource planning software
Chemotherapy dose/protocol calculation	General fitness/step-counter wellness app
App that triages or suggests a likely diagnosis from symptoms	Encyclopedia app presenting disease information

Step 2: Write the intended purpose

Qualification and classification depend entirely on the intended purpose. State clearly: the target disease/condition, the type of information provided (diagnostic, treatment-driving, monitoring), the intended user (clinician or patient), its weight in the clinical decision (sole determinant, or a verifiable input), and the care setting.

Step 3: Classify with Rule 11

Rule 11 in brief:

• Software intended to provide information used to take decisions → Class IIa
  • if that information could lead to decisions causing serious deterioration or a surgical intervention → Class IIb
  • if it could lead to decisions causing death or an irreversible deterioration → Class III
• Software intended to monitor physiological processes → Class IIa
  • if it monitors vital physiological parameters where variation could result in immediate danger → Class IIb
• All other software → Class I

In practice, most software feeding a clinical decision starts at IIa under Rule 11; "Class I software" is the exception (for example tools purely for patient comfort with no effect on clinical decisions).

Note on modules: where an MDSW module is combined in one product with a higher-class module, the whole product is managed at the highest class — but modules can be separated and classified individually.

Step 4: Extra expectations for MDSW

Once qualified as MDSW, the technical documentation is expected to include:

• Software lifecycle processes and a software safety class (A/B/C) per IEC 62304.
• Usability engineering per IEC 62366-1 (use errors are a major risk source).
• ISO 14971 risk management; for cybersecurity, IEC 81001-5-1 and MDCG 2019-16.
• Clinical evaluation: scientific validity + analytical/technical performance + clinical performance (MDCG 2020-1).
• Version/change management and a "significant change" assessment (MDCG 2020-3).
• Definition of the operating environment and minimum hardware/OS requirements.

Mobile health apps

A mobile app that has a medical purpose and processes data is subject to the MDSW rules; being "in an app store" changes nothing. A calculator/algorithm module inside the app may be a device while an information/education module is not — the boundaries must be drawn clearly.

AI and machine learning

An AI-based tool is a medical device if its intended purpose qualifies, and it follows the same classification rules. Notified bodies additionally review: the representativeness and separation of training/validation/test datasets, performance metrics and subgroup analysis, whether the model is "locked" or continues to learn, and whether model updates constitute a significant change. In the EU, the intersection with the AI Act must also be assessed.

The most common mistakes

1. Assuming Class I because "it is only decision support and the clinician decides." Rule 11 turns on "providing information"; clinician review does not lower the class.
2. Writing the intended purpose broadly in marketing and narrowly in the IFU. The auditor compares the two.
3. Choosing IEC 62304 safety class "A" without justification.
4. Presenting the whole app as one block without defining module boundaries.
5. Leaving cloud/infrastructure and cybersecurity out of scope.

Frequently asked questions

Are SaMD and MDSW the same? SaMD (Software as a Medical Device) is an IMDRF term for standalone software. The EU term is MDSW, which covers both standalone software and software driving a device.

Is my Excel macro / internal calculation tool a medical device? If it is used only in-house and not placed on the market commercially, the "in-house device" exemption (Article 5(5)) may apply — its conditions must be assessed carefully.

Does a software update require re-certification? If it is a "significant change," yes. Assess it with the MDCG 2020-3 decision tree.

Does offering it for free exempt me? No. It is placing on the market and intended purpose that matter, not price.

How MEGACERT helps

We support MDSW qualification and Rule 11 classification files, IEC 62304/62366-1 compliance planning, AI performance dossiers and significant-change assessments. Let us confirm whether your software is a device in 30 minutes. → Contact

---

Sources

1. Regulation (EU) 2017/745, Article 2(1) and Annex VIII Rule 11. EUR-Lex.
2. MDCG 2019-11 — Qualification and classification of software. European Commission.
3. MDCG 2019-16 — Guidance on cybersecurity for medical devices.
4. MDCG 2020-1 — Clinical evaluation of medical device software.
5. MDCG 2020-3 — Significant changes under the transitional provisions.
6. IEC 62304, IEC 62366-1, ISO 14971, IEC 81001-5-1.

Last updated: 30 August 2026. General information only; your product needs a specific assessment.

---