The MDR in brief
Regulation (EU) 2017/745 on medical devices (Medical Device Regulation, MDR) has applied directly in all EU member states since 26 May 2021. It replaced the earlier directives and significantly tightened the requirements for manufacturers, authorised representatives, importers and distributors – especially regarding clinical evidence, market surveillance, traceability and transparency.
For devices with valid certificates under the old directives, Regulation (EU) 2023/607 extended the transition periods – depending on the risk class until the end of 2027 or the end of 2028, and only under conditions such as a QMS in line with Art. 10(9) and a timely application to a notified body. Check the status of your devices individually.
Key obligations for manufacturers
| Obligation | Reference | Typical evidence |
|---|---|---|
| General safety and performance requirements | Annex I | GSPR checklist with evidence |
| Risk management system | Art. 10(2), Annex I | Risk management file, usually per ISO 14971 |
| Clinical evaluation | Art. 61, Annex XIV | Clinical evaluation plan and report |
| Technical documentation | Annexes II, III | Device file including PMS documentation |
| Quality management system | Art. 10(9) | QMS, usually per ISO 13485 |
| Person responsible for regulatory compliance (PRRC) | Art. 15 | Appointment and evidence of qualification |
| UDI and registration | Art. 27, 29 | UDI assignment, registration in EUDAMED |
| Post-market surveillance | Art. 83–86 | PMS plan, PMS report or PSUR |
| Vigilance | Art. 87–92 | Reporting procedure, trend reports, field safety corrective actions |
Technical documentation under Annexes II and III
Technical documentation is the central evidence of conformity. Notified bodies review it in the conformity assessment, and authorities can request it at any time. It must be clear, organised and readily searchable, and kept up to date throughout the lifecycle.
- Device description and specification including variants, accessories and UDI-DI
- Information to be supplied by the manufacturer: labelling and instructions for use
- Design and manufacturing information
- General safety and performance requirements with evidence
- Benefit-risk analysis and risk management
- Product verification and validation, including clinical evaluation
- Technical documentation on post-market surveillance (Annex III)
How docxpert supports MDR compliance
Post-market surveillance
The MDR requires an active, systematic PMS system proportionate to the risk class. Data from complaints, incidents, literature, registries and user feedback is collected, analysed and used to update risk management, clinical evaluation and instructions for use.
| Risk class | PMS document | Update |
|---|---|---|
| Class I | PMS report (Art. 85) | When necessary |
| Class IIa | PSUR (Art. 86) | When necessary, at least every two years |
| Class IIb and III | PSUR (Art. 86) | At least annually |
Practical tips
- Structure before content: a consistent structure of the technical documentation following Annex II makes review easier for notified bodies and maintenance easier for you.
- Bring PMS to life: a PMS plan that only exists on paper is a frequent finding. Define data sources, owners and analysis intervals concretely.
- Close the loop: findings from PMS and vigilance must demonstrably feed into risk management and clinical evaluation.
- Involve the PRRC: the responsible person must be able to check conformity – give them access to all relevant documents.
Further guidance for medtech companies is on the Medtech page.
Frequently asked questions
How do I keep technical documentation up to date?
Assign an owner and update triggers to every part of the documentation – such as design changes, new standards, PMS findings or changes to the instructions for use. Change requests and approvals keep every update traceable.
Does the MDR also apply to software?
Yes. Software with a medical intended purpose is a medical device and is classified under rule 11 of Annex VIII, often at least as class IIa. Standards such as IEC 62304 for the software lifecycle are also relevant.
Is ISO 13485 mandatory under the MDR?
The MDR requires a QMS under Art. 10(9) but does not explicitly mandate ISO 13485. As a harmonised standard it is the usual way to demonstrate compliance.
What is the difference between a PMS report and a PSUR?
Manufacturers of class I devices prepare a PMS report; manufacturers of class IIa, IIb and III devices prepare a periodic safety update report (PSUR) with a benefit-risk assessment.
Can docxpert submit reports to authorities?
No. Reports to authorities and registrations in EUDAMED go through the official channels. docxpert documents the vigilance procedure, assessment and evidence.
How long must technical documentation be retained?
At least ten years after the last device has been placed on the market, and at least fifteen years for implantable devices. In docxpert every approved version is kept with its audit trail; older versions are archived rather than deleted.
Who needs a PRRC under Art. 15?
Every manufacturer must designate at least one person with the required expertise. Micro and small enterprises may have such a person permanently and continuously at their disposal externally.
Is there an automatic gap analysis for the MDR?
There is currently no dedicated requirement catalogue for the MDR. The ISO 13485 gap analysis covers the QMS requirements, and the 30 templates show their mapping to MDR articles and annexes.
How can I keep technical documentation consistent across product variants?
Define which information is common to all variants and which differences need their own rationale or review. A product-family structure can reduce repetition, but it must not hide variant-specific characteristics, intended purposes or risk assessments. Link each relevant change to affected sections, test reports, labels and approvals. Use a controlled change assessment so design, manufacturing and surveillance information do not drift apart. Before revising a file, check whether dependent records such as instructions for use and PMS documentation are also affected. Make the underlying revision and approval status clear so teams do not rely on outdated evidence by mistake. The structure should fit the product and regulatory role and be reviewed by the responsible specialists.
_1762866128417-DS2_OO1j.png)
