Turn MDR obligations into owners, evidence, and release gates.
Use this checklist per device family to build an audit-ready MDR operating system (technical documentation, clinical evaluation, PMS/vigilance, UDI/EUDAMED).
Structured answer sets in this page tree.
Cited legal and guidance references.
This MDR compliance checklist is designed for execution, not awareness. Use it to assign ownership, define evidence outputs, and create must be true release gates before placing a device on the market or shipping a software update. Treat it as a living control set that evolves with intended purpose, claims, design changes, suppliers, and post-market signals.
Run this checklist per device family. For each line item, record: owner, artifact link, last updated date, review/approval, and acceptance criteria.
If you use a notified body route, this structure also helps you package an application that's coherent and reviewable.
Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.
Start from EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints.
Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist.
Lock down the decisions that drive everything else: intended purpose, software qualification, economic operator role, and Annex VIII classification.
Output: scope memo + classification memo + conformity assessment route decision.
MDR expects an operating system: documented processes, competent roles, change control, and post-market feedback loops. For software, your QMS must support frequent updates without losing traceability.
Output: procedures + training + audit plan + management review inputs tied to PMS.
Technical documentation is your evidence backbone. Build an index that stays consistent across variants, accessories, and changes.
Output: Annex II/III technical file + a traceable GSPR checklist (Annex I) linked to evidence.
Clinical evaluation is the structured justification that your device is safe and performs as intended for the target population, with risks acceptable relative to benefits.
Output: clinical evaluation plan + CER + PMCF plan/evaluation where required.
PMS and vigilance are operational capabilities. They connect real-world signals back into design, labeling, risk management, and CAPA.
Output: PMS plan, PMS report/PSUR, signal/trend reporting, and FSCA/recall readiness.
UDI and EUDAMED impact traceability, labeling, and device data management. Plan these as operations, not as end-of-project paperwork.
Output: actor registration, device/UDI records, submission and update governance, and periodic data quality checks.