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 is not a shortcut unless it is demonstrated against technical, biological, and clinical characteristics. 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.

PMCF 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. Grounding data states that the first four modules become mandatory from 28 May 2026.

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.