EU MDR FAQ

The MDR applies when the product is a medical device, an accessory for a medical device, or an Annex XVI product covered by common specifications. The first check is intended purpose: diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation, investigation, replacement, modification, or control of conception can bring a product within the medical device definition.

Do not qualify the product from engineering features alone. Record the manufacturer-stated intended purpose, claims, user instructions, target users, patient population, and the function that creates the medical purpose.

Start with qualification, then classification. MDCG 2019-11 says software must have a medical purpose on its own to qualify as medical device software; simple storage, archiving, communication, lossless compression, or simple search is not enough by itself.

For MDR Rule 11, software that provides information used for diagnostic or therapeutic decisions is generally class IIa, with higher classes where wrong information could cause death, irreversible deterioration, serious deterioration, or surgical intervention. Software that only monitors physiological processes is also generally class IIa, with class IIb for vital parameters where variation could create immediate danger.

A notified body is normally needed for class IIa, IIb, and III devices. Class I devices are generally under the manufacturer's responsibility, but notified-body involvement is required for class I devices placed on the market sterile, with a measuring function, or as reusable surgical instruments for the relevant conformity-assessment aspects.

Choose the notified body by MDR designation scope, device technology, applicable codes, capacity, and certificate route. Do not assume an MDD/AIMDD relationship covers MDR work unless the body is designated for the MDR scope needed.

The clinical evaluation must be planned, continuous, and documented in a clinical evaluation report. It should use enough clinical data to support safety, performance, clinical benefits, claims, intended purpose, and benefit-risk conclusions for the specific device.

Equivalence can support the clinical evaluation only when the manufacturer demonstrates the technical, biological, and clinical characteristics required by the MDR. For implantable and class III devices relying on another manufacturer's equivalent device, the MDR requires access to that manufacturer's technical documentation through a contract.

Where PMCF is applicable, it is part of post-market surveillance and continuously updates the clinical evaluation. The PMCF plan should identify general and specific activities, rationale, limitations, timelines, links to risk management and the CER, and the expected PMCF evaluation report.

PSUR and SSCP are not the same artifact. The Basic UDI-DI is used across regulatory documentation such as product certificates, declarations of conformity, technical documentation, SSCP, and PSUR to connect device groupings with the same intended purpose, risk class, and essential design and manufacturing characteristics.

The MDR UDI system is built for traceability. Manufacturers need Basic UDI-DI, UDI-DI, UDI-PI, labelling, documentation, and EUDAMED registration decisions that match device groupings, packaging, configurations, reprocessing status, and role changes.

EUDAMED contains modules for actor registration, UDI/device registration, notified bodies and certificates, clinical investigations and performance studies, vigilance and post-market surveillance, and market surveillance. Actor registration, UDI/device registration, and notified bodies and certificates became mandatory on 28 May 2026, as did market surveillance for competent authorities and the Commission. The Commission currently lists the clinical-investigation module as under analysis and the vigilance/PMS module as in development, so teams must continue using the applicable current reporting routes until those modules become mandatory.

Only where the relevant Member State permits it. Under Article 17(2), a person who reprocesses a single-use device is treated as its manufacturer and assumes the MDR manufacturer obligations for the reprocessed device. The reprocessor's name and address and the fact that the device is reprocessed must appear on the label and, where applicable, in the instructions for use. The original manufacturer must be identified in the instructions for use.

Article 17(3) lets a Member State decide not to apply all manufacturer rules to a single-use device reprocessed and used within a health institution, provided the common specifications are followed. An external reprocessor can work for the health institution only where the returned device remains the health institution's device in its entirety and the external reprocessor meets the applicable requirements. Commission Implementing Regulation (EU) 2020/1207 adds common specifications for risk management, staff and premises, process validation, maximum reprocessing cycles, quality management, technical documentation, incident collection and reporting, and traceability.

Only if the Article 120 transition conditions remain satisfied. Regulation (EU) 2023/607 extended transition periods for eligible legacy devices, but it also ties that benefit to conditions including continued Directive compliance, no significant change in design or intended purpose, MDR PMS/vigilance/registration requirements, a QMS by 26 May 2024, and timely notified-body application and written agreement where required.

MDCG 2020-3 says significance is assessed case by case. If a proposed change concerns design or intended purpose and the applicable flowchart reaches a significant-change outcome, the device cannot rely on the legacy route for that changed design or intended purpose.

For each answer, keep the fact pattern and the regulatory conclusion together. A useful MDR record identifies the device, intended purpose, claims, risk class, software function if relevant, accessory or custom-made rationale, conformity route, notified-body status, clinical evidence basis, UDI/EUDAMED impact, and post-market follow-up.

The record should also say what was not concluded. For example, a software qualification answer does not prove the clinical evidence is sufficient, and a non-significant legacy change assessment does not remove PMS, vigilance, registration, or notified-body surveillance obligations.