Most teams ask what class their software falls into before asking whether it is a medical device at all. That is the wrong order, and it is an expensive mistake in both directions: qualifying when you should not adds a conformity assessment you never needed, and failing to qualify when you should puts an uncertified device on the market. This guide works through the qualification test in MDCG 2019-11 Rev.1 step by step, sets out what falls outside it, and explains why the intended purpose you wrote decides the answer before any classification rule applies.

Qualification Comes Before Classification

Two separate questions sit behind every software regulatory decision, and they run in sequence. Qualification asks whether the software falls under the Medical Devices Regulations at all. Classification asks, given that it does, which risk class it belongs to. Rule 11 of MDR Annex VIII answers the second question. It has nothing to say about the first.

The guidance is direct about the threshold: “Software must have a medical purpose on its own to be qualified as a MDSW.” To qualify, a product must meet both the definition of software in the guidance and the definition of a medical device in Article 2(1) of the MDR. For in vitro diagnostic software, it must additionally meet the IVD definition in Article 2(2) of the IVDR.

One consequence catches people out. The term “standalone software” from the old Directives is no longer used, because software is now qualified and classified on its intended purpose alone, regardless of where it runs — embedded, on a platform, in the cloud. The operating system, server or virtual environment has no bearing on the answer.

The Intended Purpose Decides, Not the Technology

Rev.1 opens its qualification section with a passage that did not exist in the 2019 version, and it is worth reading closely:

“Crafting a well-defined and clear intended purpose is paramount for the regulatory compliance and safe use of MDSW... A precise intended purpose statement ensures that the MDSW aligns with the appropriate qualification and classification rules and meets all relevant regulatory requirements. Ambiguities can lead to misclassification, resulting in non-compliance and potential market access issues.”

Under the MDR, intended purpose is not an internal engineering note. Article 2(12) defines it as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, or in promotional or sales materials or statements, and as specified in the clinical evaluation. Your marketing copy is part of the legal record.

Rev.1 also ties this to Article 7: any claim relating to the intended medical purpose must be supported by an appropriate level of clinical evidence. If it is not, the software cannot be CE marked as a medical device, nor present those claims. Writing a bolder purpose than you can evidence is not a shortcut to a higher class; it is a compliance problem in its own right.

The Five Decision Steps

MDCG 2019-11 sets out the qualification test as an ordered sequence. Each step depends on the ones before it, so they cannot be answered out of order:

  1. Is it software? If the product meets the guidance definition of software, it may be MDSW. If not, it is outside this guidance, though it may still be covered by the Regulations as something else.
  2. Is it an Annex XVI device, an accessory, or software driving or influencing a device? If any of these, it is regulated as part of that device, or independently as an accessory. This step diverts a large amount of software off the MDSW path without exempting it from anything.
  3. Does it act on data beyond storage, archival, communication, simple search or lossless compression? If it does nothing more than move or hold data intact, it does not proceed.
  4. Is the action for the benefit of individual patients? Software intended only to aggregate population data, provide generic diagnostic or treatment pathways, serve scientific literature, medical atlases, models or templates, or support epidemiological studies and registers is not acting for individual patients.
  5. Does it meet the MDSW definition? Software intended to be used, alone or in combination, for a purpose specified in the medical device definition — whether independent or driving or influencing a device.

A counterintuitive point, stated explicitly in the guidance: the risk of harm is not a qualification criterion. Whether the software could hurt someone if it malfunctioned has no bearing on whether it qualifies as a medical device. Risk enters at classification, not before. Teams routinely argue their way out of qualification on safety grounds, and the argument does not exist in the text.

Already know your software qualifies? The Classification Wizard walks all 22 Annex VIII rules, including Rule 11, and returns the reasoning behind the class rather than just the letter.

Check your class

What Does Not Qualify

The guidance is unusually concrete about software that falls outside the Regulations. Not everything used in healthcare is a medical device:

Where the “Simple Search” Line Actually Falls

Step 3 excludes “simple search”, which the guidance defines as retrieving records by matching metadata against search criteria — library functions, in other words. This exclusion is narrower than it first appears.

Software is not performing simple search if it contributes to achieving a medical purpose. The guidance gives natural language processing search as an example: an NLP feature that surfaces clinically relevant findings is doing something beyond retrieval, and the exclusion no longer covers it. The same logic applies to interface search features whose results feed a medical decision.

On the other side of the line, software that processes, analyses, interprets, calculates, creates or modifies medical information may qualify when that work is governed by a medical intended purpose. The guidance lists three worked cases: software that alters the representation of data for a medical purpose; software that searches medical images for findings supporting a diagnostic hypothesis; and software performing contrast stretching, edge enhancement or sharpening so that it serves as decision support.

Software That Drives or Influences a Device

Step 2 pulls out a category that is easy to misread as an exemption. Software that does not have a medical purpose of its own, but that operates, modifies the state of, or controls a medical device — or supplies output related to that device’s functioning — is still covered by the Regulations. It is regulated either as a part or component of that device, or as an accessory in its own right.

The guidance gives software used to operate a clinical chemistry analyser, and software with built-in electronic controls for IVD quality control procedures. Neither diagnoses anything. Both are inside the regulatory perimeter.

Modules: One Product, Several Regulatory Statuses

This is where qualification most often goes wrong in practice, and it is the section Rev.1 expanded. A single product may be segregated into modules, some serving a medical purpose and some not. The status is assessed per module, not per product.

The guidance sets out a hospital software example where the modules split cleanly:

Rev.1 adds a second scenario with sharper commercial consequences: modular functionality that can be activated or deactivated on demand, adding higher-risk functions — advanced diagnostic algorithms, enhanced image analysis, complex data interpretation — to devices already placed on the market. Where such a module meets the device definition, it is MDSW and needs conformity assessment at its own risk class. A feature flag can change your regulatory obligations.

Rev.1 also requires that the intended purpose of each module be clearly defined, and that dependencies between modules be transparently communicated and justified. Modules without a medical purpose stay outside the Regulations, but the boundary has to be documented rather than assumed.

Worked Examples from the Guidance

These are drawn directly from the annexes of MDCG 2019-11 Rev.1. They show how far a product can go before it crosses into qualification, and how modest a qualifying device can be:

Software Status Why
Fertility app calculating fertile status from basal body temperature and cycle days, using a validated statistical algorithm MDSW — Class I Qualifies as a device, but provides no information for a diagnostic or therapeutic decision and monitors no vital parameter, so it falls to Rule 11(c). A device can qualify and still be Class I.
App helping people with a communication disorder speak by converting selected symbols into spoken language MDSW — Class I Compensates for a disability, which is a medical purpose under Article 2(1), so it qualifies. It supports no diagnostic or therapeutic decision, so Rule 11(c) applies.
Software listing and ranking available chemotherapy options for BRCA-positive individuals MDSW — Class IIa Informs clinical management of a critical disease, so it provides information used for a therapeutic decision under Rule 11(a).
Software operating a clinical chemistry analyser Not MDSW — but regulated No medical purpose of its own, but it drives the use of a device. Regulated as part of that device, or as an accessory.
Hospital module storing patient medical history and handling invoicing Not MDSW Storage and administrative functions only. It does not act on data beyond storage, so it stops at step 3.

What Rev.1 Changed for Qualification

MDCG 2019-11 Revision 1 was published on 17 June 2025 and is the version to cite. Its own change log lists the qualification-side updates:

Once You Qualify: On to Rule 11

If your software clears all five steps, qualification is settled and classification begins. For software, that means Rule 11 of MDR Annex VIII, which sets the class by the severity of the harm that could follow from acting on wrong information — not by how likely that error is. It is the rule that pushes most medical software above Class I. We cover it line by line, with a decision tree and five worked examples, in our guide to MDR Annex VIII Rule 11.

If your software uses AI and qualifies at Class IIa or above, the AI Act stacks on top of the MDR rather than replacing it. That overlap is covered in our guide to the EU AI Act for medical device and SaMD developers.

Find your device’s MDR class in minutes

Once qualification is settled, our MDR Classification Wizard walks all 22 Annex VIII rules and returns a defensible class with the reasoning behind it.

Open the Classification Wizard
Share this article:

Sources and further reading