Search every question across sub-FAQs

A new UDI-DI is required when a change could lead to device misidentification or ambiguity in traceability. MDR Annex VI makes a new UDI-DI mandatory for changes to the name or trade name, device version or model, single-use status, packaged-sterile status, need for sterilisation before use, quantity in a package, or critical warnings or contraindications such as latex or DEHP.

The list does not replace the general misidentification and traceability test. MDCG 2022-7 applies that test to package quantity and substance-based devices. Software has additional Annex VI rules: a modification that changes original performance, safety or intended use, or interpretation of data requires a new UDI-DI, while minor revisions generally require a new UDI-PI.

MDR Article 27(7) requires the manufacturer to keep an up-to-date list of all assigned UDIs in the technical documentation. The supporting record should also link each identifier to the product facts that justify it: Basic UDI-DI grouping rationale, issuing entity rule, device and packaging level, label or carrier evidence, EUDAMED data, and the change assessment explaining why the identifier stayed the same or changed.

For reprocessing and relabelling situations, keep traceability back to the original device identifier where the guidance or MDR rule calls for it. MDCG 2022-7 says a reprocessor who becomes the manufacturer should keep the original product UDI in technical documentation and the QMS, and MDR Annex VI requires manufacturers that relabel or repackage devices with their own label to retain the original manufacturer's UDI.

PMCF is a continuous process that updates the clinical evaluation under Article 61 and Annex XIV, Part B. It must be addressed in the manufacturer's PMS plan and performed under a documented PMCF plan.

The technical documentation may instead contain a justification that PMCF is not applicable, but the MDR does not create a blanket class-based exemption. The justification must be specific to the device and its clinical evidence, residual risks, expected lifetime, uncertainties, and post-market questions; where a notified body is involved, its clinical-evaluation assessment covers that non-performance justification.

The plan should identify the device and covered variants, intended purpose, users, patient population, indications, contraindications, warnings, classification, expected lifetime, and the PMCF objectives for that device. It should also reference the clinical evaluation report and risk management file so the post-market clinical questions being followed are clear.

Keep evidence showing that PMCF was planned, performed, analysed, and used to update the device file. The retained record should let a reviewer trace each PMCF activity from the clinical question or risk being monitored to the data source, method, result, conclusion, and follow-up action.

The PMCF evaluation report becomes part of the clinical evaluation report and technical documentation. PMCF conclusions must be considered in the clinical evaluation and risk management; where PMCF identifies a need for preventive or corrective measures, the manufacturer must implement them.

Start with the intended purpose as stated in labels, instructions for use, advertising, clinical documentation, and software release material. MDR classification is based on intended purpose and inherent risk, and Annex VIII applies the strictest applicable rule when more than one rule fits the device.

Treat the reassessment as a conformity-route question. A label update alone is insufficient. Moving from class I self-declaration into class Is, Im, Ir, IIa, IIb, or III can add notified-body involvement; moving between higher classes can change the depth of technical documentation, clinical evaluation, certificate scope, and surveillance expectations.

Keep classification and legacy-device significant-change decisions separate. A corrected or newly interpreted class does not by itself answer whether a design or intended-purpose change is significant under Article 120, and a non-significant legacy change does not validate the existing class. Record both analyses when both issues arise.

For software, reassess the medical purpose, the information the software provides, the clinical decision it supports, the user population and setting, and whether the software drives or influences another device. A change in algorithm, output, indication, user group, integration, or risk-control logic can change the Annex VIII analysis.

The evidence file should let a reviewer see why the old class is still valid or why the device needs a new conformity route. Keep the classification rationale with the technical documentation rather than as a separate project note.

Where a notified body is involved, retain the submission, questions, decisions, certificate supplement or new-certificate path, and any surveillance-transfer or transitional-provision correspondence. Where the conclusion is that no class change occurred, retain the classification analysis and the device facts that kept the same Annex VIII rule and class. If a separate Article 120 review concludes that a legacy-device change is not significant, retain that assessment separately.

The MDR allows a clinical evaluation to rely on clinical data for another device only where equivalence to the device under evaluation can be demonstrated. The manufacturer must still plan, continuously conduct, and document the clinical evaluation in a clinical evaluation report.

The equivalence argument has to cover technical, biological, and clinical characteristics. The comparison should identify differences, explain why they are not clinically significant for safety or clinical performance, and point to the underlying data rather than relying on a shared product category or broad similarity claim.

For implantable devices and class III devices, clinical investigations are generally required. The same-manufacturer modification route in Article 61(4) applies only when the manufacturer demonstrates equivalence to its already marketed device, the notified body endorses that demonstration, the marketed device's clinical evaluation is sufficient for the modified device, and the notified body confirms that the PMCF plan is appropriate and includes post-market studies.

Where a manufacturer of an implantable or class III device claims equivalence to a device from another manufacturer, MDCG 2020-5 identifies the MDR contract requirement: the manufacturer needs full access to the technical documentation on an ongoing basis. The guidance also notes that this means relying on a device certified only under the old directives will not be possible for that route.

Equivalence evidence should remain connected to the clinical evaluation and the PMCF plan or justification why PMCF is not applicable. MDR Annex XIV treats PMCF as the continuous process that updates the clinical evaluation, confirms safety and performance over the device lifetime, checks the benefit-risk ratio, and detects emerging risks on factual evidence.

Equivalent or similar devices may also matter after market entry, but not as a substitute for data on the device under evaluation. PMCF should identify which equivalent or similar-device data will be monitored, why it is relevant, and how new findings will update the clinical evaluation, risk management, or corrective actions.

Retain a reviewer-ready record showing which device was assessed, which presumed equivalent device was used, what data were available, and why the manufacturer concluded that the MDR equivalence criteria were met. The record should sit with the clinical evaluation report and technical documentation, not in an informal rationale detached from the conformity-assessment file.

Use a structured equivalence table with device-by-device comparisons, data references, identified differences, scientific justifications, and conclusions on whether any difference is clinically significant.

A product, including software, is within the MDR device definition when the manufacturer intends it to be used for one or more MDR medical purposes for human beings. Core medical-purpose language includes diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, injury, or disability; investigation, replacement, or modification of anatomy or a physiological or pathological process or state; and certain in vitro information uses.

Do not use the MDR reference to in vitro examination as a shortcut for an IVD decision. Regulation (EU) 2017/746 is the principal framework for in vitro diagnostic medical devices, while this page addresses qualification under the MDR. A product that examines human specimens needs a separate MDR/IVDR scope analysis based on its intended purpose and the applicable definitions.

The MDR does not limit intended purpose to a single formal statement. It is read from data supplied by the manufacturer on the label, instructions for use, promotional or sales materials or statements, and as specified in the clinical evaluation. Advertising and product claims also matter because Article 7 prohibits claims that mislead users or patients about intended purpose, safety, or performance.

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.

Article 86 requires electronic submission for class III and implantable devices through the Article 92 system, but the EUDAMED Vigilance/PMS module is still in development as of 24 July 2026. Until it becomes mandatory and available, manufacturers should follow the current notified-body and competent-authority arrangements rather than claim that an EUDAMED PSUR upload has been completed.