MDCG 2019-11: Qualification and classification of software, explained

Who this applies to

You are affected if you develop software with any medical connection — standalone apps, algorithms, clinical decision support, or software driving a hardware device — under either the MDR or the IVDR. If your software analyses data from in-vitro samples (blood, tissue, lab values), the IVDR side of this guidance applies.

Qualification: is it a medical device at all?

The guidance walks through decision steps that hinge on what your software does with data and for whom:

The decisive input is your intended purpose — the claims you make in labelling, instructions, and marketing. Identical software can be a medical device or not depending on what you say it is for. Rev.1 sharpened this point: craft the intended purpose deliberately, because every downstream obligation follows from it.

Classification: which class under MDR Rule 11?

Rule 11 sorts almost all MDSW by the severity of what could go wrong with the decisions it informs:

1. Software providing information for diagnostic or therapeutic decisions starts at class IIa — rising to IIb if a wrong decision could cause serious deterioration or surgery, and to class III if it could cause death or irreversible deterioration.
2. Software monitoring physiological processes is class IIa — or IIb when monitoring vital parameters whose variation could create immediate danger.
3. All other MDSW is class I — in practice a small residual category; most software that qualifies as a medical device at all lands in IIa or higher.

For IVD software, classification follows the IVDR's own rules (Annex VIII IVDR) instead. The guidance's annexes contain worked examples — from PACS and telemedicine systems to expert systems and home-care monitoring — that are worth checking for the case closest to yours.

What changed in Rev.1

Rev.1 (June 2025) did not change the qualification logic or Rule 11's structure. Per its change log, it clarified the document's scope (including Annex XVI software), stressed the importance of a clearly crafted intended purpose, added references to modular MDSW and new examples (including software intended to treat), clarified Rule 11 sub-rule (a) with examples on illness-prevention software, elaborated the "Modules" chapter, addressed the interplay with the European Health Data Space Regulation for electronic health record systems, and added a new class I example.

What this means for you, practically

1. Write the intended purpose before writing code decisions around it. It determines qualification, classification, and your entire regulatory pathway — treat it as a design input, not marketing copy.
2. Document the qualification decision even when the answer is "not a medical device." When a competent authority asks why your app isn't MDSW, a reasoned assessment against this guidance is your answer.
3. Walk Rule 11 honestly. The temptation is to argue class I; the structure of Rule 11 makes that rare. Budget for a notified body if your software informs clinical decisions.
4. Split modular products deliberately. If only one module has a medical purpose, the guidance lets you scope the medical device boundary around it — but the interfaces must be defined and the medical module must comply on its own.