EU MDR 2017/745 Compliance Checker
The EU Medical Device Regulation (MDR) 2017/745 establishes a comprehensive regulatory framework for medical devices placed on the European market, including Software as a Medical Device (SaMD). This tool evaluates your quality management system, clinical evaluation processes, technical documentation, post-market surveillance, and Unique Device Identification (UDI) registration to determine your readiness for CE marking and notified body assessment.
Progress: 0/22
Quality Management System
0/5Clinical Evaluation
0/5Technical Documentation
0/5Post-Market Surveillance
0/5UDI & Registration
0/2Quality Management System
Evaluation of your QMS and its alignment with EU MDR and ISO 13485 requirements.
Q1
Do you have a Quality Management System (QMS) certified to ISO 13485:2016 that covers the entire lifecycle of your medical device, including design, development, production, and post-market activities?
Q2
Have you implemented a risk management process compliant with ISO 14971, covering hazard identification, risk estimation, risk evaluation, and risk control throughout the device lifecycle?
Q3
If your product is Software as a Medical Device (SaMD), have you classified it according to MDR Annex VIII Rule 11 and validated it using IEC 62304 software lifecycle processes?
Q4
Do you have a documented design and development process with defined design inputs, outputs, verification, and validation activities, including traceability to user needs and regulatory requirements?
Q5
Do you conduct management reviews of your QMS at planned intervals (at least annually) that include analysis of post-market data, CAPA effectiveness, and regulatory changes?
VertiComply
Build HIPAA-compliant healthcare applications with AI-powered code generation.
Product
Features
Pricing
Tools
Company
About
Blog
Contact
Legal
Privacy
Terms
Compliance
© 2026 VertiComply. All rights reserved.
Built for HIPAA + SOC 2 Type II
About the EU MDR Compliance Checker
This checker scores software against Regulation (EU) 2017/745, which has applied since 26 May 2021 and replaced the old Medical Device Directive. The questions follow the order a Notified Body reviews a file: classification first, then the General Safety and Performance Requirements in Annex I, then technical documentation under Annexes II and III, clinical evaluation under Annex XIV, and post-market surveillance. Classification carries the heaviest weight because it determines everything downstream — Rule 11 in Annex VIII pushed most Medical Device Software from Class I under the old directive to Class IIa or higher under MDR, which means a Notified Body is now involved where previously self-declaration was enough. Teams that get Rule 11 wrong do not have a documentation gap; they have built the wrong compliance programme entirely.
What this EU MDR assessment covers
The 22-question assessment scores 100 points across 5 weighted categories. Each category reflects a distinct EU MDR control domain.
Quality Management System · 22 pts · 5 questions
Evaluation of your QMS and its alignment with EU MDR and ISO 13485 requirements.
Clinical Evaluation · 22 pts · 5 questions
Assessment of clinical evidence generation and evaluation practices.
Technical Documentation · 20 pts · 5 questions
Evaluation of technical file completeness as required for conformity assessment.
Post-Market Surveillance · 20 pts · 5 questions
Assessment of post-market surveillance, vigilance, and PMCF activities.
UDI & Registration · 16 pts · 2 questions
Evaluation of Unique Device Identification and EUDAMED registration compliance.
Common EU MDR compliance gaps
The patterns we see most frequently in EU MDR self-assessments and remediation work. Each is the kind of finding an auditor flags first.
Rule 11 was read optimistically. Software intended to provide information used for diagnostic or therapeutic decisions is Class IIa at minimum, and IIb or III where the decision could cause death or irreversible deterioration. Teams routinely self-classify as Class I on the basis that the clinician makes the final call — that argument does not survive Notified Body review.
No PRRC appointed. Article 15 requires a Person Responsible for Regulatory Compliance with defined qualifications. Micro and small enterprises may contract the role rather than employ it, but they cannot skip it. This is a documentation-level finding that is trivially avoidable and still shows up constantly.
Clinical evaluation treated as a literature summary. Annex XIV expects a clinical evaluation plan, an appraisal of the data against the intended purpose, and a demonstrated benefit-risk profile. A bibliography of adjacent studies is not a clinical evaluation, and for Class IIb and III the bar is materially higher.
Post-market surveillance exists on paper only. Annex III requires a PMS plan, and for Class IIa and above a Periodic Safety Update Report. PMCF is where most software manufacturers are weakest, because they have no structured mechanism for feeding real-world performance back into the risk file.
EUDAMED and UDI treated as launch-day tasks. UDI assignment affects labelling, the technical file, and traceability obligations. Retrofitting it after design freeze is expensive and often forces a documentation rework.
The QMS is ISO 13485 in name only. Article 10(9) requires a quality management system covering the specific items it lists. A certificate without the software-specific procedures — change control tied to risk, SOUP management, cybersecurity handling — leaves visible gaps in an audit.
Cybersecurity is handled as an IT concern rather than a GSPR. Annex I section 17 covers electronic programmable systems and software explicitly, including IT security measures. MDCG 2019-16 sets the expectation, and it belongs in the technical file, not the infrastructure runbook.
What to do with your EU MDR results
Your score is a starting point — these are the steps that convert the assessment into actionable remediation.
Settle classification in writing before anything else. Document the Rule 11 reasoning against your intended purpose statement, and have someone outside the product team challenge it. Every other decision depends on this one being right.
Write the intended purpose statement precisely. It defines scope for classification, clinical evaluation, and the GSPR checklist. Vague intended purpose is the root cause of most downstream disagreement with a Notified Body.
Build the GSPR checklist as a live matrix. Every applicable requirement in Annex I mapped to the evidence that satisfies it, with gaps visible. This is the document reviewers open first.
Start Notified Body conversations early for Class IIa and above. Capacity is constrained across the EU and lead times are measured in quarters, not weeks. The regulation does not care that you were ready late because of a queue.
Align the risk file with ISO 14971 and connect it to PMS. Risk management is meant to be a closed loop — post-market data must be capable of changing the risk assessment, and an auditor will look for evidence that it has.
EU MDR compliance FAQ
Is my healthcare app a medical device under EU MDR?
It depends entirely on intended purpose, not technology. If the software is intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, it is a medical device under Article 2(1). Wellness, fitness and pure administrative software generally fall outside. The line is narrower than most teams assume — a symptom checker that suggests possible conditions is typically in scope, while an appointment scheduler is not.
What class is my medical device software under Rule 11?
Software intended to provide information used for diagnostic or therapeutic decisions is Class IIa. It rises to Class III where the decision could cause death or an irreversible deterioration of health, and Class IIb where it could cause serious deterioration or surgical intervention. Software intended to monitor physiological processes is Class IIa, or IIb where the parameters monitored are vital and variation could result in immediate danger. Only software that does none of these stays Class I.
Do I need a Notified Body for medical device software?
For Class IIa, IIb and III, yes. Only Class I devices that are non-sterile and without a measuring function can be self-declared. Because Rule 11 moved most clinical software to IIa or above, the practical answer for healthcare software is usually yes — which is the single largest cost and timeline difference between MDR and the old directive.
How does EU MDR interact with the EU AI Act?
If your AI is part of a device requiring Notified Body assessment, the AI Act's high-risk requirements are folded into the existing MDR conformity assessment rather than run as a separate process. That is why AI in Annex I regulated products received a longer runway — to 2 August 2028 — under the Digital Omnibus. See our EU AI Act guide for what still applies today.
Does MDR apply to a US company selling into Europe?
Yes. Placing a device on the EU market triggers MDR regardless of where you are established. A non-EU manufacturer must also designate an Authorised Representative in the Union under Article 11, whose details appear on the labelling and who shares certain regulatory responsibilities.
Is ISO 13485 certification mandatory under MDR?
Not literally — Article 10(9) requires a quality management system, and ISO 13485 is the harmonised standard that demonstrates conformity with it. In practice a Notified Body will expect ISO 13485 or an equivalent that meets every element of Article 10(9), so most manufacturers certify.
Build it instead of buying it
Generate a EU MDR-compliant healthcare app with the controls built in
VertiComply generates production-ready healthcare applications with EU MDR controls scaffolded from the first commit — no add-on tier, no platform lock-in, code exported to your GitHub.
Start free