MDCG 2019-11: Qualification and classification of software, explained
Is your software a medical device at all — and if so, which class? The decision steps, explained.
Rev.1 · 2025Published August 12, 2026
Reviewed by
Dr. Oliver Eidel
MDCG 2019-11 answers the two questions every software company entering the medical market faces: is your software a medical device at all (qualification), and if so, which risk class (classification)? The answers hang almost entirely on your intended purpose — what you claim the software does — not on how the software works. Rev.1 (June 2025) added clarifications on intended purpose, modular software, and Rule 11.
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:
Usually medical device software (MDSW)
Usually not a medical device
Analyses patient data to support diagnosis or treatment decisions
Storage, archival, communication, or simple search of data
Monitors physiological parameters and flags concerning values
Calculates drug doses or treatment parameters for a patient
General wellness and lifestyle apps without medical claims
Processes data for the benefit of individual patients
Software that only aggregates data for population-level research
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:
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.
Software monitoring physiological processes is class IIa — or IIb when monitoring vital parameters whose variation could create immediate danger.
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
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.
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.
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.
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.
