Search every question across sub-FAQs

MDCG software guidance says software must have a medical purpose on its own to qualify as medical device software, unless it is an accessory, an Annex XVI product, or software that drives or influences a medical device. The location of the software, such as cloud, mobile, computer, or a hardware device, does not determine qualification.

The practical split is the function and intended purpose. General administration, invoicing, staff planning, storage, archival, communication, simple search, or population-only analytics are not enough by themselves. Software that processes, analyses, creates, or modifies medical information for an individual patient and for a medical intended purpose can qualify as medical device software.

Annex XVI is the MDR route for listed groups of products without an intended medical purpose, such as certain contact lenses, invasive anatomy-modification products, dermal fillers, adipose-tissue reduction equipment, high-intensity electromagnetic radiation equipment for skin treatment, and brain-stimulation equipment. That is different from saying a product has no MDR relevance.

The contrast matters: a product with both medical and non-medical intended purposes must satisfy both sets of applicable requirements. Do not use Annex XVI language to neutralize medical claims if the same product materials also claim diagnosis, treatment, monitoring, or another MDR medical purpose.

Keep the qualification record with the technical documentation or equivalent product-compliance file. MDR Annex II expects a product description including intended purpose and users, medical conditions to be diagnosed, treated or monitored where relevant, qualification rationale, classification rationale, labels, instructions for use, and user-facing specifications such as brochures or catalogues.

The evidence should let a reviewer reconstruct the decision without interviews. Keep the source rule, the claim inventory, the software or product function map, the intended-user and patient-population analysis, screenshots or controlled copies of claims, clinical-evaluation linkage where applicable, approvals, unresolved assumptions, and triggers for review after claim, feature, indication, user, output, or market changes.

Prepare a PSUR when the device is class IIa, class IIb, or class III. MDR Article 86 applies the duty to each device and, where relevant, to each category or group of devices.

Class IIb and class III PSURs must be updated at least annually. Class IIa PSURs must be updated when necessary and at least every two years. Except for custom-made devices, the PSUR is part of the technical documentation under Annexes II and III; for custom-made devices, it belongs with the Annex XIII documentation.

The PSUR is not a standalone narrative. It summarizes the results and conclusions of PMS data analysis gathered under the Article 84 PMS plan, together with the rationale and description of preventive or corrective actions.

Across the device lifetime, the PSUR must set out the conclusions of the benefit-risk determination, the main findings of PMCF, the device sales volume, an estimated evaluation of the size and characteristics of the user population, and usage frequency where practicable.

Retain the evidence needed to reproduce the PSUR conclusions and the notified-body or authority review path. The file should show which PMS inputs were collected, how they were analyzed, what changed in benefit-risk or risk management, and which actions were opened or closed.

Because Annex III requires PMS technical documentation to be clear, organized, readily searchable, and unambiguous, keep PSUR evidence indexed against the device, Basic UDI-DI or internal device identifier, risk class, reporting period, PMS plan, PMCF plan or justification, and the technical documentation version.

The MDR accessory test is not whether the article looks like a medical device. It is whether the manufacturer intends it to be used together with one or more particular medical devices to enable those devices to be used for their intended purpose, or to specifically and directly assist their medical functionality.

That intended-purpose link should be visible in the retained evidence: labels, instructions for use, marketing claims, compatibility statements, interface specifications, risk analysis, and any decision explaining why the product is or is not an MDR accessory.

A useful accessory file should let a reviewer see the product boundary, the medical device relationship, and the MDR duties triggered by the conclusion. Keep the rationale close to the technical file rather than as a standalone label decision.

Reopen the decision when intended purpose, compatible devices, claims, software or firmware, interfaces, packaging, UDI grouping, supplier evidence, risk controls, or PMS findings change.

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.

The EU MDR trigger is specific: implantable devices and class III devices need an SSCP unless they are custom-made or investigational devices. Do not create the answer from a broad risk label alone; confirm classification, implantable status, intended purpose, and whether an exclusion applies.

The SSCP is not a marketing brochure, instructions for use replacement, implant-card replacement, or general treatment guide. Its purpose is public access to an updated summary of clinical data and other safety and clinical performance information for the device.

The SSCP should be sourced from the device technical documentation. Keep a traceable pack showing where each public statement came from and how it remains aligned with the current technical file.

For the clinical evaluation link, retain the clinical evaluation plan and report, the clinical evidence used to support conformity, both favourable and unfavourable clinical data considered, and the PMCF plan and PMCF evaluation report where PMCF updates the clinical evaluation. Where equivalence is used, keep the equivalence rationale and the evidence access basis.

EUDAMED is not one generic evidence bucket. The Commission describes six modules: actor registration, UDI/device registration, notified bodies and certificates, clinical investigations and performance studies, vigilance and post-market surveillance, and market surveillance.

For MDR work, map the record to the module that creates or receives it. Actor registration identifies the economic operator and SRN. UDI/device registration identifies the device, Basic UDI-DI, UDI-DI, EMDN data, market status, and legacy-device links where relevant. The notified bodies and certificates module holds certificate and notified-body information. Clinical investigations, vigilance/PMS, and market surveillance each have their own electronic-system purpose under the MDR.

Keep a module-level record that explains what was submitted or reviewed, why it belongs in that module, who owns the EUDAMED account action, and what must be updated when the device, certificate, incident, investigation, or authority status changes.

For actor work, retain the actor registration request, SRN, competent-authority approval trail, information-security declaration, authorised-representative mandate summary for non-EU manufacturers where applicable, and the active Local Actor Administrator coverage needed to preserve access. For UDI/device work, retain the Basic UDI-DI, UDI-DI, EMDN code, market status, certificate references where required, legacy-device link logic, version history, and update rationale.

A EUDAMED entry is not the same thing as a full MDR compliance conclusion. MDR Annex VI states that presence of a device UDI-DI in the UDI database must not be assumed to mean that the device conforms with the Regulation.

Treat EUDAMED as a structured registration and reporting system. The underlying MDR evidence still sits in the QMS, technical documentation, clinical evaluation, PMS/PMCF records, vigilance files, certificate files, labels, and change-control records.