When is software a medical device under the EU MDR?

Start with the intended purpose stated on the label, in the instructions for use, in promotional or sales materials or statements, and in the clinical evaluation. MDR Article 2(1) includes software intended for specific medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or disability; or investigation, replacement, or modification of anatomy or a physiological or pathological process or state.

MDCG 2019-11 Rev.1 gives a practical qualification test. Software may qualify when it processes, analyses, interprets, calculates, creates, or modifies medical information for a medical intended purpose. A feature described as "simple search" is not automatically outside the MDR: a search or natural-language-processing function can be MDSW when it contributes to achieving the medical purpose. Cosmetic display changes or compatibility conversions do not qualify on that basis alone.

Keep the MDR and IVDR boundary clear. Software whose purpose is to provide information from the in vitro examination of human specimens may instead fall under Regulation (EU) 2017/746. Software without its own medical purpose can still fall under the MDR as an accessory or as software that drives or influences a hardware medical device. Qualification does not depend on whether the software runs in a cloud service, phone, computer, embedded device, server, or virtual environment.

After qualification, classify the software from its intended purpose and all applicable Annex VIII implementing and classification rules. Rule 11 addresses software that provides information used for diagnostic or therapeutic decisions and software intended to monitor physiological processes, but it is not the only possible rule. Depending on the purpose and configuration, Rules 12, 13, 15, or 22 and the rules for software that drives or influences another device may also matter.

Rule 11 generally classifies software used for diagnostic or therapeutic decisions as class IIa, unless the decision impact may cause death or irreversible deterioration, which moves it to class III, or serious deterioration or surgical intervention, which moves it to class IIb. Software intended to monitor physiological processes is class IIa, except vital-parameter monitoring where variations could create immediate patient danger, which is class IIb. Other software is class I.

Software that only drives or influences another device falls in the same class as that device. Software that has its own medical purpose is classified in its own right; MDCG 2019-11 Rev.1 explains that if it also drives or influences hardware, its class should not be lower than the hardware device's class. When several rules or sub-rules apply, the rule producing the higher class controls.

Keep a qualification and classification file that a reviewer can follow without product-history context. It should show the intended purpose, claims, users, patient population, input data, output data, medical action, module boundaries, Rule 11 analysis, applicable Annex VIII rules, and final class.

For MDR software, technical documentation should connect the device description and architecture to risk management, verification and validation, cybersecurity, usability, clinical evaluation, post-market surveillance, labels and instructions, conformity assessment, UDI identifiers, and EUDAMED registration where applicable. The depth of evidence depends on the intended purpose, class, risks, claims, users, and deployment context.

MDR Article 61 and Annex XIV require a clinical evaluation for a medical device. The plan and report must address relevant clinical data, the intended purpose and claimed clinical benefits, favourable and unfavourable data, gaps in evidence, and post-market clinical follow-up (PMCF), unless the manufacturer can justify why PMCF is not applicable.