EU MDR technical documentation

EU MDR Article 10(4) requires technical documentation for every device, and EU MDR Annex II and EU MDR Annex III say what goes in it: the device and its purpose, labelling, design and manufacture, evidence against the safety and performance requirements of EU MDR Annex I, risk management, verification and validation, and the post-market surveillance file.

The requirement in plain English

Keep it, and keep it current (EU MDR Article 10(4)). The file must let a notified body or competent authority judge whether the device conforms, and it changes with the device. You keep it, with the declaration and any certificates, for at least 10 years after the last device is placed on the market, or 15 years for implants (EU MDR Article 10(8)).

What Annex II asks for, in six parts:

1. The device. What it is and its intended purpose, users and patients; its Basic UDI-DI; how it works; why it is a device; its class and the rule applied; variants, accessories and earlier generations.
2. What the user receives. Every label and the instructions for use, in the languages of the countries where you sell.
3. Design and manufacture. How the design was developed, how it is made and validated, and every site, including suppliers, where design or manufacture happens.
4. The safety and performance requirements. For each applicable requirement in Annex I, the method used to show it is met, the standards or common specifications applied and where the evidence sits, and a reason for each one that does not apply.
5. Benefit-risk and risk management. The benefit-risk analysis and the risk management file.
6. Verification and validation. Bench, software, biocompatibility, usability and other test results, and the clinical evaluation report with the plan for post-market clinical follow-up.

What Annex III adds. The post-market surveillance plan, and the PSUR or surveillance report it produces.

Annex I behind it all. Its three chapters set general requirements, including a risk management system (section 3) and reducing the risk of use error (section 5); requirements on design and manufacture, including software developed to the state of the art with information security (section 17); and requirements on labels and instructions for use (section 23).

Standards and specifications. A device meeting a harmonised standard published for EU MDR is presumed to meet the requirements it covers (EU MDR Article 8). Common specifications, where they exist, must be met unless you justify an equivalent level of safety (EU MDR Article 9).

Identification. Each device carries a unique device identifier under the system in EU MDR Article 27 and EU MDR Annex VI. Class III and implantable devices also need a summary of safety and clinical performance (EU MDR Article 32).

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 25-person company makes a Class IIa app that adjusts insulin dose advice. Its technical documentation is a controlled index, not one long PDF. The index follows the six Annex II parts and Annex III, and each line points to a controlled document or record with its version.

The heart of the file is the safety and performance checklist: one row per Annex I requirement, marked applicable or not with a reason, the method of proof, the standards applied by edition, and links to the evidence. Software rows point to the software development plan, architecture, verification records and release record kept under IEC 62304. Use-error rows point to the usability engineering file under IEC 62366-1. Risk rows point to the risk management file, whose hazards trace forward to controls and backward to the checklist.

A regulatory lead owns the index; engineering, clinical and quality own their sections. Every design change raises a documentation impact check, and the index is re-approved with each release. Before each notified body audit the team walks five checklist rows end to end, from requirement to raw evidence, to check the links still hold.

Evidence an auditor expects

• The Annex II and III file (required): the notified body checks it is complete, organised and searchable, as Annex II asks.
• Safety and performance checklist: the usual form of the section 4 evidence; the notified body samples rows and follows them to raw data.
• Risk management file (required): benefit-risk conclusions consistent with the checklist and the clinical evaluation.
• Verification and validation reports (required): for software, evidence of a lifecycle, testing and information security.
• Labelling and instructions for use (required): consistent with the intended purpose and the classification.
• UDI assignments: Basic UDI-DI in the file, the declaration and the labels, matching each other.
• Change history: shows the file kept pace with design changes.

Common mistakes

A checklist that points nowhere

Rows that say “complies” with no method, standard or evidence reference are the most common finding. Every applicable row needs a pointer a reviewer can follow in under a minute.

Standards cited without editions

“IEC 62304” with no edition, or an edition withdrawn years ago, invites a state-of-the-art finding. Name the edition and, where it is not the newest, say why.

Assuming every standard you follow is harmonised

The presumption of conformity in Article 8 covers only standards whose references the Commission has published for EU MDR. Check the current list before you rely on the presumption, and justify the rest as state of the art.

A file frozen at certification

Post-market findings and design changes that never reach the file make it wrong within a year. Tie the file to change control and to the PSUR cycle.

Inconsistent identities

A device name, model or Basic UDI-DI that differs between the file, the declaration and the labels undermines everything else. Hold identifiers in one controlled record.

How Sted helps

Related guides and terms

• EU MDR conformity assessment and notified bodies: who reviews the file, and when.
• EU MDR clinical evaluation: the report the file must contain.
• ISO 14971: the risk management process behind section 5 of the file.
• ISO 13485 design and development: the design records the file draws on.
• Document control: keeping every item the index points to versioned and approved.
• Documented information: the controlled documents and records a technical file is built from.

Frequently asked questions