EU MDR Software Qualification: The Question Rule 11 Assumes You Already Answered

Most software classification memos open with Annex VIII Rule 11 and never look back — run the intended purpose through the rule's logic, land on a class, move on. That order skips a question MDCG 2019-11 Rev.1 puts first for a reason: is this software a medical device at all? Rule 11 has nothing to say about software that never clears that bar.

Two questions, not one

MDCG 2019-11 structures the whole exercise as a sequence. The first question is qualification: does this software meet the definition of a medical device under MDR Article 2(1), or the equivalent in vitro diagnostic definition under IVDR? Only if the answer is yes does the second question — classification — open up, and only at that point does MDR Rule 11's classification logic have anything to decide. Teams that write a classification memo without a qualification section haven't skipped a formality; they've assumed the harder answer without writing it down.

Where "simple search" ends and MDSW begins

The qualification test turns on a single distinction: does the software perform an action on data beyond storage, archival, lossless compression, communication, or simple search? A database that stores clinical records is not MDSW on that basis. A system that transmits images between departments is not MDSW on that basis. A tool that retrieves records by matching metadata against search criteria — a library-catalogue function, in MDCG 2019-11's own framing — is not MDSW on that basis. None of those examples do anything to the data; they move it, hold it, or find it.

The line moves the moment software calculates, analyzes, interprets, or creates or modifies medical information, and that output serves an individual patient's diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease — the medical purposes Article 2(1) lists. A tool that flags an abnormal lab value using a fixed reference range is doing more than storage. A clinical decision support algorithm that recommends a dose adjustment is unambiguously past the line. The technology stack is irrelevant to this test; a spreadsheet formula and a trained model are qualified the same way, by what the output is claimed to do.

The claimed intended purpose decides qualification. A more sophisticated model doesn't qualify software that a simpler one wouldn't — and a simple rule engine doesn't stay unqualified because it looks unsophisticated. Why the intended-purpose test outruns the technology

Where this gets genuinely hard: EHR and health-information software

Electronic health record systems sit closest to the boundary, and Rev.1 added explicit language on exactly this case: software that only processes health information — storing, structuring, or transmitting it — stays outside MDSW unless that processing directly serves a medical purpose. An EHR module that simply displays a patient's medication list is processing information, not qualifying as a device. The same module adding a dosing calculation, a drug-interaction check, or an alert that changes a clinical decision crosses into MDSW territory, and Rev.1's reference to the EU's new European Health Data Space framework signals the Commission expects this boundary to get more contested, not less, as health-data platforms add features. AI/ML compliance teams should treat every new EHR feature as its own qualification question rather than assuming the parent system's status carries over.

• Usually outside MDSW: record storage and archival, image and document transmission, simple search/retrieval, lossless compression, generic dashboards that display data without acting on it.
• Usually inside MDSW: calculations that inform a clinical decision, interpretation of clinical or diagnostic data, algorithms that create or modify medical information, software driving or influencing treatment.
• Genuinely contested: EHR modules that add clinical logic, AI-enabled features layered onto administrative systems, modular products where one module qualifies and its siblings don't.
• Modular products: Rev.1 reinforces that each module needs its own intended-purpose statement and its own qualification answer — one qualifying module does not pull the whole platform into MDSW, and it does not exempt the others either.

Getting qualification wrong runs in both directions, and neither is cheap. Call a device non-qualifying when it isn't and the product reaches the market without a technical file, a notified body, or a vigilance system behind it — the kind of gap a market-surveillance authority finds, not the kind a company discloses. Call software MDSW when it genuinely isn't and a software-as-a-medical-device compliance program gets built for a product that never needed one, burning budget and calendar time a real device launch will need later. Both failure modes trace back to the same shortcut: treating Rule 11 as the starting point instead of the second question in a sequence EU MDR & IVDR compliance work has to run in order.