EU MDR Rule 11 software classification

Start with the MDR Article 2(1) medical device definition and the manufacturer's intended purpose. The MDR expressly includes software when it is intended for medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation, investigation, replacement, modification, or providing information by in vitro examination of human specimens.

MDCG 2019-11 Rev.1 narrows the practical test: software must have a medical purpose on its own to qualify as medical device software. The same guidance says hosting location does not decide the question; cloud software, mobile apps, desktop software, and software embedded in a hardware device can all qualify if the intended purpose and function meet the medical-device test. The risk of harm from software use is not itself a qualification criterion.

Exclude functions that merely store, archive, communicate, compress without loss, or perform simple search unless the software also processes, analyses, creates, or modifies medical information for a medical intended purpose. Separately record any software that drives or influences a hardware medical device because it may be covered as a part, component, or accessory even if it does not have its own medical purpose.

For qualified MDR medical device software, apply Rule 11 by function and foreseeable decision impact. Software that provides information used for diagnosis or therapeutic decisions starts at class IIa, but moves to class III when those decisions may cause death or irreversible deterioration of health, and to class IIb when they may cause serious deterioration of health or surgical intervention.

Software intended to monitor physiological processes is class IIa. It becomes class IIb when it monitors vital physiological parameters and the nature of variation could create immediate danger to the patient. All other Rule 11 software is class I, unless another Annex VIII rule or implementing rule produces a higher class.

MDCG 2021-24 Rev.1 warns that software is an active device and should not be reviewed only in the context of Rule 11. Keep a short cross-check for active therapeutic, diagnosis and monitoring, closed-loop, and hardware-control rules when the software controls therapy, influences a class IIb active therapeutic device, monitors an active implantable device, or significantly determines patient management. If several Annex VIII rules or sub-rules apply to the intended purpose, implementing rule 3.5 requires the strictest one that results in the higher classification.

Rule 11 classification changes the market route. Class IIa, class IIb, and class III software require notified-body involvement under MDR Article 52. Class III software follows Annex IX or Annex X plus Annex XI. Class IIb software may follow Annex IX with technical documentation assessed for at least one representative device per generic device group, or Annex X plus Annex XI. Class IIa software may follow Annex IX with technical documentation assessed for at least one representative device for each category of devices, or Annex II and Annex III technical documentation plus Annex XI Section 10 or 18.

Class I software can generally be self-declared after the manufacturer draws up Annex II and Annex III technical documentation and issues the EU declaration of conformity, unless another class I feature requiring notified-body involvement applies. A Rule 11 record should state the resulting class, the conformity assessment consequence, and the applicable rule branch.

For software that drives or influences a hardware device, keep the software classification rationale aligned with the hardware device route. If the software changes the operation, output, risk controls, alarms, therapy delivery, or diagnostic information of another device, the conformity route discussion belongs in the combined device file.

A Rule 11 classification record is not enough to support medical claims. MDR Article 61 requires conformity with relevant general safety and performance requirements, benefit-risk acceptability, and undesirable side-effect evaluation to be based on clinical data providing sufficient clinical evidence. The manufacturer must specify and justify the level of clinical evidence needed for the device characteristics and intended purpose.

For decision-support or monitoring software, the clinical evaluation should tie the algorithm, data inputs, output, target users, patient population, clinical workflow, and claimed clinical benefit to evidence. MDCG 2020-6 describes clinical evaluation as a lifecycle process and highlights the need to incorporate PMS and PMCF data into the clinical evaluation.

When software changes, update the evidence question before release. New or modified algorithms, changed presentation of medical data, closed-loop replacement of user input, new diagnostic or therapeutic features, or new interoperability channels can affect safety, performance, classification, clinical evaluation, and notified-body handling. MDCG 2020-3 addresses whether such changes are significant for legacy devices using the Article 120 transition; it is not a general change-classification rule for every MDR-certified device.