When is software regulated as SaMD under the EU MDR?

Start with the intended purpose stated in labels, instructions for use, promotional material, sales statements, and the clinical evaluation. MDR Article 2 includes software in the medical-device definition when it is intended for medical purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, or diagnosis, monitoring, treatment, alleviation, or compensation for injury or disability.

MDCG 2019-11 turns that into a practical software test. Software may qualify where it processes, analyses, creates, or modifies medical information for the benefit of individual patients and for a medical intended purpose. Software that only stores, archives, communicates, performs simple search, or performs lossless compression is not medical device software on that function alone.

Software that drives or influences a hardware medical device is still covered in the device's regulatory process as a part, component, or accessory, even if it does not create medical information on its own.

After qualification, classify the software from its intended purpose and Annex VIII rules. For independent medical device software, MDCG 2019-11 points to Rule 11 for software that provides information used for diagnosis or therapeutic decisions, or software intended to monitor physiological processes.

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.

If software drives or influences a device, Annex VIII implementing rules matter too: software can fall in the same class as the device, independent software is classified in its own right, and the strictest applicable rule controls where multiple rules apply.

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 software description to risk management, verification and validation, cybersecurity and usability evidence where relevant, clinical evaluation, PMS or PMCF planning, labels, IFU, UDI identifiers, and EUDAMED device-registration data where the software is placed on the market as a device.

Clinical evaluation is not optional for software with medical claims. MDR Annex XIV requires a clinical evaluation plan and report, with clinical data relevant to the device and intended purpose, gaps in clinical evidence, favourable and unfavourable data, and PMCF where needed to update the evaluation after market release.