Annex II is the MDR technical file map for the device itself: description, specification, design and manufacturing information, GSPR demonstration, benefit-risk and risk management, verification, validation, clinical evaluation, and PMCF evidence.
Annex III is the post-market surveillance file: the PMS plan, PMS report or PSUR, complaint and incident data, trend methods, CAPA links, and evidence that updates the risk and clinical files.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this page as an MDR technical documentation index. It separates the Annex II pre-market technical file from the Annex III post-market surveillance file, then names the records that should cross-reference each other so a reviewer can trace the device claim, test evidence, clinical evidence, risk controls, PMS signals, UDI records, and EUDAMED submissions.
Start the Annex II file with a device description that can identify exactly what is being assessed. The MDR calls for the product or trade name, intended purpose, intended users, Basic UDI-DI or another unambiguous reference until UDI-based identification applies, intended patient population, medical conditions, indications, contraindications, warnings, operating principles, device qualification rationale, risk class, classification-rule justification, novel features, accessories, variants, configurations, key functional elements, materials, and technical specifications.
Keep design and manufacturing records close to that description. Annex II expects information that lets the design stages be understood, complete manufacturing-process and validation information, continuous monitoring and final product testing, and identification of the sites, suppliers, and subcontractors where design or manufacturing activities are performed.
The GSPR checklist should not be a yes/no table without evidence. Annex II requires the applicable General Safety and Performance Requirements from Annex I, an explanation for non-applicable requirements, the method used to demonstrate conformity, any harmonised standards, common specifications, or other solutions applied, and the exact controlled documents that prove conformity.
The same file should link benefit-risk analysis, risk management outputs, and product verification and validation. Verification and validation should include results and critical analyses of tests or studies used to show MDR conformity, including pre-clinical evidence such as engineering, laboratory, simulated-use, animal, biocompatibility, characterization, electrical safety, EMC, software verification and validation, stability, performance, and safety evidence where relevant.
Use the MDR technical-file map to connect device claims, GSPR evidence, risk controls, validation records, clinical evaluation, PMS outputs, UDI data, and EUDAMED submissions.
Annex II places the clinical evaluation plan, clinical evaluation report, report updates, PMCF plan, and PMCF evaluation report in the technical documentation. The clinical file should therefore cite the exact device description, intended purpose, risk controls, state-of-the-art position, and claims being supported.
The PMCF plan should not sit apart from the file. MDR Annex XIV treats PMCF as a continuous process that updates clinical evaluation through proactive clinical-data collection, confirms safety and performance, checks continued acceptability of identified risks, detects emerging risks, and documents results in a PMCF evaluation report that feeds clinical evaluation and risk management.
Annex III is the technical documentation on post-market surveillance. It should contain the PMS plan drawn up under Article 84 and the PMS report for class I devices or PSUR for class IIa, IIb, and III devices. The PMS plan must show how the manufacturer collects and uses information from serious incidents, PSURs, field safety corrective actions, non-serious incidents, undesirable side effects, trend reporting, literature, databases, registries, user feedback, distributor and importer feedback, complaints, and public information about similar devices.
The PMS plan also needs methods, not just inputs. Annex III calls for proactive and systematic collection, methods to assess data, indicators and thresholds for continuous benefit-risk and risk-management reassessment, complaint investigation methods, trend-report protocols, authority and notified-body communication methods, procedures for Articles 83, 84, and 86, corrective-action procedures, device-tracing tools, and a PMCF plan or a justification that PMCF is not applicable.
Annex II expects the Basic UDI-DI when device identification is based on the UDI system, or another unambiguous product reference until then. The UDI record should align with the product name, model, version, sterile status, single-use status, quantity per package, warnings, contraindications, and software identification used in labels, declarations, certificates, EUDAMED entries, and technical documentation.
Commission EUDAMED material states that MDR and IVDR introduce a UDI-based device identification system for traceability and that manufacturers must submit UDI/device information in EUDAMED for devices placed on the EU market. The UDI/device module information page also identifies Basic UDI-DI and UDI-DI concepts, UDI/device data sets, EMDN use, and UDI helpdesk material as implementation references.
The practical output is a controlled evidence matrix, not a narrative policy. Each row should identify the claim or requirement, device version or configuration, document owner, source requirement, evidence document, file location, approval status, open questions, and the trigger that will reopen the row.
Use release gates that check whether Annex II and Annex III still agree with each other. A design change, supplier change, software release, new complaint trend, PMCF finding, new safety signal, UDI data change, EUDAMED update, new or revised standard, or notified-body question can affect the device description, GSPR checklist, clinical evaluation, risk management, PMS plan, PSUR, labels, or declaration of conformity.
"Harmonised standards are European standards"
"UDI/Devices Data sets"
"A new UDI-DI shall be required"
"controlled documents offering evidence"