MDCG 2019-11 for IVD Software: Qualification and Classification Under the IVDR

Introduction

MDCG 2019-11 is the guidance that decides two things about a piece of software: whether it is a device at all, and if so, which regulation and which class it falls under. For in vitro diagnostic software the second question has a feature that catches almost everyone coming from the medical device side — there is no software classification rule in the IVDR. Rule 11 exists under the MDR and has no counterpart under Regulation (EU) 2017/746.

That absence is not an oversight and it is not a gap to be filled by analogy. IVD software is classified by what the information it produces is about, using the same seven rules that classify a reagent, and the consequences run all the way to whether a notified body is involved. This guide follows MDCG 2019-11 through qualification and then through IVD classification, and stops at the points where a file built on MDR software habits produces the wrong answer. For the wider framework, start with the IVDR guide; for what the classification then costs you in documentation, the IVDR technical documentation guide covers Annex II.

Table of Contents

Which version of MDCG 2019-11 you are reading

The document is titled Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR. The current version is Revision 1, published on 17 June 2025. MDCG documents are published and dated on the European Commission guidance page, which is the only place worth checking a version against. The original was issued in October 2019 and circulated widely for six years, which means a large proportion of the copies saved in quality systems are the superseded one.

Revision 1 is not a rewrite. The qualification logic, the decision steps and the classification approach are unchanged, and a correct classification made under the original text will almost always survive. What it adds is clarification in four areas that had produced inconsistent practice: the treatment of modular software, where each module's intended purpose has to be defined and documented in its own right; the first appearance of the term medical device artificial intelligence, reflecting that AI-enabled software is a subset of MDSW and separately in scope of the AI Act; an elaboration of sub-rule 11a on the MDR side; and a new passage on the interplay with the European Health Data Space and electronic health record systems.

The practical instruction is dull and worth following anyway: check the date on the PDF in your technical documentation before you cite a passage from it. A classification rationale that quotes the 2019 text by section number is quoting a document that has been reissued.

Qualification: is it software, is it a device, and under which regulation

MDCG 2019-11 runs qualification as a sequence of decision steps, and the sequence matters because each one disposes of a different question. Software has to be software within the meaning of the guidance, it has to be a device rather than an accessory or a component, and only then does the question of MDR or IVDR arise.

The qualification path for in vitro diagnostic softwareMDCG 2019-11 Rev.1. Each step disposes of a different question, and the third one is wherethe MDR and the IVDR separate.STEP 1Is it softwareat all?Drivers, operatingsystems and storage,archiving, losslesscompression,communication or simplesearch are out.Anything thattransforms data intoinformation survives.STEP 2Does it meet adevicedefinition?For an IVD, Article2(2): the informationmust be derived fromthe examination ofspecimens from thehuman body. Nospecimen, no IVD.STEP 3MDR or IVDR?Weight the data sourcesagainst the intendedpurpose. Substantiallyachieved through IVDdata — IVDR. OtherwiseMDR. Qualitative, anddocumented.STEP 4Which class?IVDR Annex VIII: tenimplementing rules,then sevenclassification rules.No software rule exists— the analyte and theintended purposedecide.Step 3 has no numerical threshold. The guidance asks which data sources substantially achieve the intended purpose,qualitatively — so the determination is only as good as the reasoning written down beside it. A conclusion with novisible reasoning is the finding.
Figure 1 — The four decision steps, and the one that separates the MDR from the IVDR

The first step is definitional and it eliminates less than people expect. Software that is a driver for hardware, or is an operating system, or is not performing an action on data beyond storage, archival, lossless compression, communication or simple search, is not MDSW. Everything that transforms data into information for a medical purpose survives this step.

The second step is the device definition itself. For an IVD this is Article 2(2) of the IVDR, and it is narrower than the medical device definition in a specific way: the information has to be derived from the examination of specimens derived from the human body. Software that produces clinical information from a patient's vital signs, imaging or history is not an IVD however diagnostic its output, because no specimen was examined.

Decision Step 3 decides MDR or IVDR, and it is a weighting exercise

The step that generates most of the real disagreement is the one that separates the two regulations when software uses both kinds of input. A tool that combines a laboratory result with imaging findings, or an assay output with demographic and clinical data, meets both definitions on a literal reading.

MDCG 2019-11 resolves this by asking which data sources substantially achieve the intended purpose. The guidance describes a weighting of the data sources based on the significance of the information in relation to fulfilling the intended purpose, and it is explicitly qualitative — there is no percentage threshold to compute. If the intended purpose is substantially achieved through data from IVD sources, the software is an IVD and the IVDR applies. If not, the MDR applies, and the presence of a laboratory value among the inputs does not change that.

Two consequences follow that are easy to miss. First, the weighting is a documented determination, not a conclusion: it belongs in the classification rationale with the reasoning visible, because a reviewer who disagrees with the outcome will start by looking for the reasoning and find nothing. Second, the answer can change when the intended purpose changes. Adding an input, or broadening a claim, can move a product from one regulation to the other, and there is no gradual path between them.

What sits outside, and why the boundary is drifting

Laboratory information systems, middleware that routes results without transforming them, and hospital information systems are not devices on their own. The guidance is equally clear that modules within them can be, and that a module qualifying as MDSW is assessed in its own right regardless of the platform it ships inside.

Revision 1 sharpens this. A system that is not a device does not shelter a module that is, and the manufacturer is expected to define each module's intended purpose separately and document it. Read the other way, the same point is an opportunity: separating a medical module from the non-medical platform around it can keep the regulatory burden on the part that actually needs it, rather than dragging an entire information system into scope.

✦ EU IVDR Technical Documentation Kit

The classification rationale is the first document in the Annex II file.

Everything downstream is scoped by the class you land on — the depth of the performance evaluation, whether a notified body is involved, whether post-market surveillance closes with an Article 80 report or a PSUR. The kit carries the Annex II set as one coordinated file, so the classification, the intended purpose and the evidence sections state the same thing.

✓ Word templates · Regulation (EU) 2017/746 Annex II and Annex III

✓ Classification rationale structured on the Annex VIII implementing rules

See the EU IVDR Technical Documentation Kit →

There is no Rule 11 under the IVDR

MDR Annex VIII contains Rule 11, a classification rule written specifically for software, with sub-rules that escalate by the seriousness of the decision the software informs. It is the rule every software manufacturer in Europe has learned. IVDR Annex VIII contains no equivalent.

What IVDR Annex VIII contains is ten implementing rules followed by seven classification rules, and none of the seven mentions software. The rules themselves, with worked IVD examples, are set out in MDCG 2020-16, the classification guidance that sits alongside this one. The classification of IVD software is therefore governed entirely by its intended purpose, run through the same seven rules that classify any other IVD — which means the question is not what kind of software it is but what the information is about.

Why MDR software habits give the wrong IVD classRule 11 exists in MDR Annex VIII and has no counterpart in the IVDR. The two regulationsclassify software on different things.MDR — REGULATION (EU) 2017/745IVDR — REGULATION (EU) 2017/746Software ruleRule 11 of Annex VIII, writtenspecifically for software, with sub-rules11a, 11b and 11c.None. Annex VIII has seven classificationrules and not one of them mentionssoftware.What drives theclassThe seriousness of the decision the outputinforms: death or irreversibledeterioration, serious deterioration,surgical intervention.What the information is about. The analyte,the condition and the population, runthrough the same rules that classify areagent.Implementing rules3.3 for software driving a device, 3.5 forthe strictest applicable rule.1.4 for software driving a device, 1.8 formultiple intended purposes, 1.9 for thestrictest applicable rule.Self-certificationClass I only, and Rule 11 rarely landsthere.Class A only. Everything from class Bupwards needs a notified body.Typical wrong answer—A class reasoned in the shape of Rule 11:escalated by how serious the clinicaldecision is, rather than by the rule thatcovers the analyte.The subtle version of this error never cites Rule 11. It simply argues from the seriousness of the decision — whichis Rule 11 reasoning applied under a Regulation that does not contain it.
Figure 2 — Rule 11 exists under the MDR and nowhere in the IVDR, and the two classify on different things

This is a better system than it first appears, and it produces different answers than Rule 11 would. Under the MDR, software informing a decision that could cause death or irreversible deterioration lands in class III by the nature of the decision. Under the IVDR, software that interprets a sequencing result for a transfusion-transmissible agent is class D because of what the analyte is, not because of how the output is used. A manufacturer who reasons by analogy to Rule 11 will produce a class that is defensible-sounding and wrong.

The two implementing rules that decide software

Of the ten implementing rules in IVDR Annex VIII, two do the work for software and both are short enough to quote in a rationale.

Implementing rule 1.4. Software which drives a device or influences the use of a device falls within the same class as the device; if the software is independent of any other device, it is classified in its own right. MDCG 2019-11 adds a limit that is frequently ignored: rule 1.4 applies only to software that drives or influences the use of an in vitro diagnostic device. Software driving an analyser inherits the analyser's class — which for most instruments is class A under rule 5. Software that reaches its own conclusion about a specimen is independent, and it is classified on what it concludes.

Implementing rule 1.9. Where several rules, or several sub-rules within a rule, apply to the same device, the strictest one resulting in the higher classification applies. Combined with rule 1.8, which puts a device with multiple stated intended purposes into the higher class, this is the rule that punishes broad claims. A panel that reports twenty analytes is classified by the one that scores highest, and a claim added for marketing reasons can move an entire product up a class.

The border case worth naming is software that both reaches its own conclusion and drives an instrument. MDCG 2019-11 treats it as classified in its own right on the intended purpose it achieves, with the qualification that its class cannot be lower than that of the device it drives.

Working an IVD software classificationImplementing rules first, then the seven classification rules, then rule 1.9 as the check.SOFTWAREHOW IT IS CLASSIFIEDWHERE IT LANDSDrives an immunoassayanalyserImplementing rule 1.4, first sentence. Itdoes not reach a conclusion of its own, so itinherits the instrument's class.Same class as the analyser —usually class A.Standalone interpretivealgorithmIndependent of any other device under rule1.4, second sentence. Classified in its ownright on the intended purpose.Whatever the analyte and contextgive. Rarely class A.Interprets and drives theinstrumentClassified in its own right on the purpose itachieves, with a floor: never lower than thedevice it drives.The higher of the two.Multi-analyte panelreportingRule 1.8 for the multiple intended purposes,then rule 1.9 for the strictest rule amongthem.The class of the single mostdemanding analyte.Module inside a laboratorysystemThe platform is not a device. The module isqualified and classified separately, with itsown documented intended purpose.Independent of the platform'sstatus.Delta checks and QCtrackingUsually no transformation into informationfor a medical purpose about an individualpatient — check step 1 before classifying.Frequently not MDSW at all.Rule 1.9 is applied last and applied always. If two rules reach the device, the higher class wins — which is why anintended purpose written broadly for commercial reasons is a classification decision as much as a marketing one.
Figure 3 — Six software cases, the rule that decides each one and where it lands

The intended purpose is the classification input, and it is written before the rules are read

Every rule in Annex VIII is applied to the intended purpose, which means the classification is decided by a paragraph the manufacturer wrote rather than by a rule the manufacturer read. MDCG 2019-11 Rev.1 underlines the point by insisting that a clear intended purpose is a precondition of qualification, not an output of it.

For software the intended purpose has to say four things, and rationales routinely omit two of them. What the software does with the data — detects, quantifies, interprets, predicts, or simply presents. What the information is about: the analyte, the marker, the condition or the physiological state. Who the information is for, and what they are expected to do with it. And what specimen the underlying data comes from, because that is the sentence that keeps the product inside the IVDR at all.

Two habits that produce an unusable purpose

Two habits cause most of the damage. The first is describing the technology rather than the purpose — a paragraph about the model architecture, the training set and the platform, from which no rule can be applied. The second is writing the purpose to cover every use the product might one day have, which is commercially attractive and regulatorily expensive: implementing rules 1.8 and 1.9 then classify the product on the most demanding claim in the paragraph.

The discipline that avoids both is to write the intended purpose so that a reader who has never seen the product can pick a rule from Annex VIII without asking a question. If they cannot, the rationale is not finished, and a notified body reviewer will start exactly there.

Adding a claim is a classification change

Because the class follows the purpose, extending a claim is a regulatory event rather than a marketing one. Adding a second analyte to a panel, extending a population, or adding a predictive output to software that previously only reported a measured value can move the product up a class, across a conformity assessment route, and in some cases from the MDR to the IVDR or back.

The practical consequence for a change control procedure is that claim changes have to be routed through classification before they reach the label, and the assessment has to be recorded even when the answer is that nothing moved. A change file that shows the classification was reconsidered and held is a much easier conversation than one that shows it was never asked.

What the class then costs

Classification is not an administrative label; under the IVDR it determines the conformity assessment route and most of what follows from it.

Class A software that is not sterile is self-certified, and a manufacturer can declare conformity without a notified body. Everything from class B upwards requires one. That single step is where the IVDR bites hardest on software, because a great deal of software that was self-declared under the old Directive is not class A under the Regulation, and the arithmetic of the IVDR transition depends on which side of that line a product falls.

The class then propagates. It sets the depth of the performance evaluation and the scientific validity, analytical performance and clinical performance evidence behind it, covered in the MDCG 2022-2 guide. It decides whether post-market surveillance closes with an Article 80 report or an Article 81 periodic safety update report, as set out in MDCG 2025-10. It determines whether a summary of safety and performance is required. For class D it adds EU reference laboratory involvement and batch verification.

None of that is software-specific, which is the point. Once the class is fixed, an IVD software product carries the obligations of an IVD of that class, with IEC 62304 and the software lifecycle sitting inside the technical documentation rather than replacing any part of it.

✦ IEC 62304 Software Documentation Kit

The lifecycle file that sits inside the technical documentation, not beside it.

Once the class is fixed, an IVD software product carries the obligations of an IVD of that class — and the IEC 62304 lifecycle records are part of the Annex II file rather than a substitute for any of it. Software development plan, architecture and detailed design, unit and integration verification, SOUP management, problem resolution and the release records a reviewer will ask to see.

✓ IEC 62304 lifecycle · safety classification A, B and C

✓ SOUP inventory and cybersecurity documentation included

See the IEC 62304 Kit →

What Revision 1 actually changed for IVD software

Three of the four changes touch IVD software directly, and none of them alters an existing correct classification.

The elaboration on modules is the most immediately useful. Where a laboratory platform bundles result routing, quality control tracking, delta checking and an interpretive algorithm, the guidance now expects each module's intended purpose to be defined and documented, and the qualification question answered for each. The interpretive algorithm may be an IVD while the rest of the platform is not.

The introduction of medical device artificial intelligence as a term does not create a separate regime under the IVDR. An AI-based interpretive algorithm is MDSW, qualified and classified by the same steps as any other software. What the term signals is the separate applicability of the AI Act, which runs alongside the IVDR rather than instead of it, and which a class B or higher IVD software product will generally also be caught by.

The passage on the European Health Data Space and electronic health record systems matters for any IVD software that writes results into, or reads context from, an EHR. The regimes are separate and cumulative, and the technical documentation is expected to show that the interaction was considered rather than assumed away.

Where IVD software files fail

The recurring findings cluster around the classification rationale rather than the software engineering, and they are visible in a document that is usually two pages long.

Where IVD software files failSix findings, nearly all of them visible in a classification rationale that is usually twopages long.CRITICALRule 11 reasoningunder the IVDREither cited outright, orapplied in shape: the classescalated by how serious theclinical decision is, ratherthan by the rule covering theanalyte.CRITICALStep 3 concluded, notreasonedThe MDR-or-IVDR determinationstated as an outcome with noweighting of the data sourcesagainst the intended purposewritten beside it.MAJORIntended purposewritten wideRules 1.8 and 1.9 then classifythe product on its mostdemanding claim. Narrowing itlater means rescoping theperformance evaluation.MAJORModules neverseparatedA whole laboratory platformdragged into scope, or aqualifying module shelteredinside a system that is not adevice. Rev.1 closes both.MAJORRule 1.4 stretchedClaimed for software thatreaches its own conclusion.Inheriting the analyser's classonly works where the softwaredoes not interpret.MINORCiting the 2019 textRevision 1 was published on 17June 2025. A rationale quotingthe original by section numberis quoting a reissued document.
Figure 4 — Six ways an IVD software file fails, nearly all of them in the classification rationale

The Rule 11 failure is the signature one and it takes two forms. The obvious form cites Rule 11 outright in an IVDR rationale. The subtle form does not cite it but reasons in its shape — escalating the class by the seriousness of the clinical decision the output informs, rather than by the rule that covers the analyte. The second form is harder to spot and produces the same wrong answer.

The intended purpose failure is the expensive one, because it is not a documentation defect. A purpose written broadly to preserve commercial flexibility drags rule 1.8 and rule 1.9 into play, and the product is classified on its most demanding claim. Narrowing an intended purpose after the technical documentation is built means revisiting the performance evaluation that was scoped to the broad one.

Frequently asked questions

What is MDCG 2019-11?

MDCG 2019-11 is the Medical Device Coordination Group guidance on the qualification and classification of software under the MDR and the IVDR. It sets out decision steps for determining whether software is a medical device or an in vitro diagnostic medical device, and how it is then classified. The current version is Revision 1, published on 17 June 2025. It is not legally binding.

Does Rule 11 apply to IVD software?

No. Rule 11 is a classification rule in Annex VIII of the MDR and has no equivalent in the IVDR. IVD software is classified using the seven classification rules of IVDR Annex VIII, applied to the intended purpose — in practice, to what the information the software produces is about. Reasoning by analogy to Rule 11 is one of the most common errors in an IVD software classification rationale.

How do I know whether my software falls under the MDR or the IVDR?

By weighting the data sources. MDCG 2019-11 asks whether the intended purpose is substantially achieved through data derived from the examination of specimens from the human body. If it is, the software is an IVD and the IVDR applies; if not, the MDR does. The weighting is qualitative, there is no numerical threshold, and the determination belongs in the classification rationale with its reasoning visible.

What class is software that drives an analyser?

The same class as the analyser, under implementing rule 1.4 of IVDR Annex VIII. Most instruments are class A, so driving software is normally class A as well. This applies only where the software drives or influences the use of an in vitro diagnostic device and does not reach a diagnostic conclusion of its own; software that interprets the specimen is independent and is classified on what it concludes.

Is IVD software ever class A?

Yes, but less often than manufacturers hope. Software driving an instrument is normally class A, as is software whose output falls under rule 5. Standalone interpretive software is classified by the analyte and the clinical context, and lands in class B or above far more often than not. Anything above class A requires a notified body.

Does the AI Act apply as well as the IVDR?

Generally yes, for AI-based IVD software above class A. Revision 1 introduced the term medical device artificial intelligence to acknowledge AI-enabled MDSW as a subset, but it does not create a separate IVDR regime for it. The AI Act runs alongside the Regulation, and the two sets of obligations are cumulative rather than alternative.

Do modules inside a laboratory information system need to be classified?

Each module that meets the device definition does, in its own right. A laboratory or hospital information system is not a device, but a module within it that transforms data into information for a medical purpose can be. Revision 1 expects each module's intended purpose to be defined and documented separately, which also allows a non-medical platform to stay out of scope.

Conclusions

MDCG 2019-11 Rev.1 does not change how IVD software is qualified or classified. It clarifies four areas that had been applied inconsistently and it restates a structure that was already there — which makes it a good moment to re-read a classification rationale written against the 2019 text.

Three things carry most of the value for an IVD. The regulation is decided by weighting the data sources against the intended purpose, qualitatively and on the record. There is no Rule 11 under the IVDR, so the class comes from what the information is about and not from how serious the decision is. And implementing rules 1.4, 1.8 and 1.9 do more work than any classification rule: they decide whether software inherits an instrument's class, and they punish an intended purpose written more broadly than the product needs.

The EU IVDR Technical Documentation Kit covers the Annex II file that a classified IVD software product has to produce, with the classification rationale, the performance evaluation and the post-market documents in one coordinated set.