Search every question across sub-FAQs

The PSUR 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 record 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 manufacturer's intended purpose controls the accessory test. The article must not itself be a medical device, and the manufacturer must intend it for use with one or more particular medical devices to enable their intended use or to specifically and directly assist their medical functionality.

A general-purpose article does not become an accessory merely because it is compatible with a medical device. If the article has its own medical intended purpose, assess it as a medical device instead; if it only provides general support without the specific device link in Article 2(2), document why it falls outside the accessory definition.

MDCG classification guidance gives a useful boundary: software or equipment attached to a device is not an accessory when it does not specifically enable the device's intended use or specifically and directly assist its medical functionality. By contrast, Annex VIII Rule 8 treats accessories to active implantable devices as class III, including non-implantable or non-active accessories, which shows why the accessory's own rule analysis matters.

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 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.

The Commission describes six EUDAMED modules: actor registration, UDI/device registration, notified bodies and certificates, clinical investigations and performance studies, vigilance and post-market surveillance, and market surveillance. The first four modules declared functional - Actor, UDI/Device, Notified Bodies and Certificates, and Market Surveillance - became mandatory on 28 May 2026.

The Commission has not made the remaining two modules available for routine use. It lists Clinical Investigations and Performance Studies as under analysis and Vigilance/PMS as in development, with no voluntary-use period before they become mandatory. Continue using the applicable current submission channels for those records until the Commission activates the modules.

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.

An EUDAMED entry does not establish full MDR compliance. 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.