MDCG 2019-11 — Software Qualification and Classification

The guidance supports consistent EU software decisions

MDCG 2019-11 rev.1 provides guidance on qualification and classification of software under Regulation (EU) 2017/745 on medical devices and Regulation (EU) 2017/746 on in vitro diagnostic medical devices. Revision 1 was published in June 2025 and is the current version listed by the European Commission.

MDCG guidance is not legally binding. It presents a common understanding of how the Regulations should be applied, while the legal definitions and classification rules remain those in the MDR and IVDR.

MTL-307 — EU MDR and IVDR General Safety and Performance Requirements provides the wider regulatory context.

Start with the manufacturer's intended purpose

Qualification is driven by the intended medical purpose expressed through labels, instructions, promotional material, technical documentation and the software's actual functions. Technology, deployment location and commercial description do not decide the question by themselves.

• Identify the medical condition, physiological state or clinical process addressed.
• Define intended users, patients and use environments.
• Describe the information received, processed and produced.
• Explain the decision or action supported by the output.
• Separate medical claims from administrative, storage or communication functions.
• Ensure claims are consistent across product, clinical, regulatory and marketing records.

Build this foundation through MTL-102 — Intended Purpose, Users and Use Environments.

Medical device software performs a medical purpose on information

Software may qualify as medical device software when it is intended, alone or in combination, for a purpose covered by the MDR medical-device definition or the IVDR in-vitro-diagnostic definition. It normally performs an action on data beyond simple storage, archival, communication or lossless search.

Relevant actions can include calculation, analysis, interpretation, creation or modification of medical information where the output serves an individual patient's medical purpose. General-purpose wellness, administrative, communication or workflow software may fall outside the device definitions when it has no specific medical purpose.

Qualification requires the complete function and claim to be understood. A software product can contain regulated and non-regulated modules, but the boundaries and interactions must be credible.

Define modules, dependencies and the regulated boundary

Modular products may combine medical-device functions with functions that do not have a medical purpose. Identify which modules meet the definition, which support them and how data or control crosses the boundary.

A narrow boundary cannot be used to exclude software whose failure can affect the medical function. Supporting modules may still require control because they influence safety or performance.

Software that drives or influences hardware follows a separate route

Software intended to drive or influence the use of a hardware medical device may fall within the hardware device's regulatory framework rather than being classified independently under Rule 11. Examples can include software controlling therapy delivery, acquiring signals or changing device operating parameters.

Document the allocation of medical functions between software and hardware, the relationship to the device intended purpose and the effect of software failure. Software that is an accessory may itself be a device and requires its own qualification and classification rationale.

Select the MDR classification rule from intended function

For software under the MDR, consider all Annex VIII rules that could apply. Rule 11 is central for software providing information used to make diagnostic or therapeutic decisions and software monitoring physiological processes. Other rules may apply where software drives or influences a device or has a different specific function.

Classification should reflect the significance of the information or monitoring and the possible consequence of an incorrect result. Do not begin with a desired conformity-assessment route and reverse-engineer the rationale.

Rule 11 scales class with decision and monitoring consequence

Connect the classification to the precise output, intended decision and plausible consequence. Use risk analysis as supporting evidence, but do not substitute company risk-acceptability categories for the legal rule wording.

IVD software is classified through the IVDR rules

Software qualifies under the IVDR when it provides information derived from the in-vitro examination of specimens for an IVDR purpose. Classification then follows Annex VIII of the IVDR, considering the intended purpose, analyte, population, decision and public-health or patient consequence.

Stand-alone IVD medical device software is classified in its own right. Software driving or influencing an IVD generally falls within the same class as that device. Where software is independent of another device, apply the classification rules to the software's own intended purpose.

Do not assume all laboratory software is IVD software: laboratory information management, billing, transport or generic data-display functions may not have an IVDR medical purpose.

Deployment technology does not remove the medical purpose

Medical device software can run on a mobile phone, general-purpose computer, cloud platform, browser, wearable or embedded processor. Location and ownership of the infrastructure do not decide qualification.

Define platform assumptions, supported configurations, cybersecurity, data protection and dependencies. Online platforms that distribute medical-device software create additional responsibilities, but the app's qualification still begins with its intended function.

MTL-129 — Privacy and Data Protection by Design and MTL-108 — Medical-device Cybersecurity address related design obligations.

Record a reproducible qualification and classification decision

• State the product and software functions assessed.
• Quote the controlled intended-purpose and claims sources.
• Define input, processing, output and medical use.
• Identify the MDR or IVDR legal definition satisfied.
• Explain excluded non-device modules and their interfaces.
• Apply each potentially relevant classification rule.
• Describe the decision or monitoring consequence supporting the class.
• Identify accessories and software driving or influencing hardware.
• Record assumptions, evidence, reviewers and approval date.
• Link the decision to regulatory strategy and change control.

The rationale belongs in technical documentation and should be understandable without relying on verbal explanations from its original author.

Reassess when software or claims change

New algorithms, outputs, patient groups, clinical decisions, integrations, platforms or promotional claims can alter qualification, classification and conformity-assessment obligations. Screen changes before implementation and market release.

Post-market information may also reveal that the actual clinical use or consequence differs from the original rationale. Keep the classification decision connected to risk management, clinical or performance evaluation, labelling and configuration control through MTL-127 — Configuration and Change Management.

Common misconceptions

Practical decision checklist

• Is the intended purpose specific, controlled and consistent?
• Does the software perform an action beyond storage, communication or simple search?
• Does the output serve an MDR or IVDR medical purpose?
• Are regulated modules and supporting functions clearly bounded?
• Does software drive or influence a hardware device?
• Have all relevant MDR or IVDR rules been considered?
• Is Rule 11 consequence reasoning explicit where applicable?
• Are platform and external-service dependencies documented?
• Is the rationale linked to clinical evidence and risk management?
• Will change control trigger reassessment?