MDR 2017/745 Specialist
EU MDR compliance patterns for medical device classification, technical documentation, and clinical evidence.
Table of Contents
Clarify First
Before classifying the device or analyzing gaps, confirm these inputs. If any is unknown or vague, ASK — do not assume:
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the classification.
Device Classification Workflow
Classify device under MDR Annex VIII:
- Identify device duration (transient, short-term, long-term)
- Determine invasiveness level (non-invasive, body orifice, surgical)
- Assess body system contact (CNS, cardiac, other)
- Check if active device (energy dependent)
- Apply classification rules 1-22
- For software, apply MDCG 2019-11 algorithm
- Document classification rationale
- Validation: Classification confirmed with Notified Body
Classification Matrix
| Factor |
Class I |
Class IIa |
Class IIb |
Class III |
| Duration |
Any |
Short-term |
Long-term |
Long-term |
| Invasiveness |
Non-invasive |
Body orifice |
Surgical |
Implantable |
| System |
Any |
Non-critical |
Critical organs |
CNS/cardiac |
| Risk |
Lowest |
Low-medium |
Medium-high |
Highest |
Software Classification (MDCG 2019-11)
| Information Use |
Condition Severity |
Class |
| Informs decision |
Non-serious |
IIa |
| Informs decision |
Serious |
IIb |
| Drives/treats |
Critical |
III |
Classification Examples
Example 1: Absorbable Surgical Suture
- Rule 8 (implantable, long-term)
- Duration: > 30 days (absorbed)
- Contact: General tissue
- Classification: Class IIb
Example 2: AI Diagnostic Software
- Rule 11 + MDCG 2019-11
- Function: Diagnoses serious condition
- Classification: Class IIb
Example 3: Cardiac Pacemaker
- Rule 8 (implantable)
- Contact: Central circulatory system
- Classification: Class III
Technical Documentation
Prepare technical file per Annex II and III:
- Create device description (variants, accessories, intended purpose)
- Develop labeling (Article 13 requirements, IFU)
- Document design and manufacturing process
- Complete GSPR compliance matrix
- Prepare benefit-risk analysis
- Compile verification and validation evidence
- Integrate risk management file (ISO 14971)
- Validation: Technical file reviewed for completeness
Technical File Structure
ANNEX II TECHNICAL DOCUMENTATION
├── Device description and UDI-DI
├── Label and instructions for use
├── Design and manufacturing info
├── GSPR compliance matrix
├── Benefit-risk analysis
├── Verification and validation
└── Clinical evaluation report
GSPR Compliance Checklist
| Requirement |
Evidence |
Status |
| Safe design (GSPR 1-3) |
Risk management file |
☐ |
| Chemical properties (GSPR 10.1) |
Biocompatibility report |
☐ |
| Infection risk (GSPR 10.2) |
Sterilization validation |
☐ |
| Software requirements (GSPR 17) |
IEC 62304 documentation |
☐ |
| Labeling (GSPR 23) |
Label artwork, IFU |
☐ |
Conformity Assessment Routes
| Class |
Route |
NB Involvement |
| I |
Annex II self-declaration |
None |
| Is/Im |
Annex II + IX/XI |
Sterile/measuring aspects |
| IIa |
Annex II + IX or XI |
Product or QMS |
| IIb |
Annex IX + X or X + XI |
Type exam + production |
| III |
Annex IX + X |
Full QMS + type exam |
Clinical Evidence
Develop clinical evidence strategy per Annex XIV:
- Define clinical claims and endpoints
- Conduct systematic literature search
- Appraise clinical data quality
- Assess equivalence (technical, biological, clinical)
- Identify evidence gaps
- Determine if clinical investigation required
- Prepare Clinical Evaluation Report (CER)
- Validation: CER reviewed by qualified evaluator
Evidence Requirements by Class
| Class |
Minimum Evidence |
Investigation |
| I |
Risk-benefit analysis |
Not typically required |
| IIa |
Literature + post-market |
May be required |
| IIb |
Systematic literature review |
Often required |
| III |
Comprehensive clinical data |
Required (Article 61) |
Clinical Evaluation Report Structure
CER CONTENTS
├── Executive summary
├── Device scope and intended purpose
├── Clinical background (state of the art)
├── Literature search methodology
├── Data appraisal and analysis
├── Safety and performance conclusions
├── Benefit-risk determination
└── PMCF plan summary
Qualified Evaluator Requirements
- Medical degree or equivalent healthcare qualification
- 4+ years clinical experience in relevant field
- Training in clinical evaluation methodology
- Understanding of MDR requirements
Post-Market Surveillance
Establish PMS system per Chapter VII:
- Develop PMS plan (Article 84)
- Define data collection methods
- Establish complaint handling procedures
- Create vigilance reporting process
- Plan Periodic Safety Update Reports (PSUR)
- Integrate with PMCF activities
- Define trend analysis and signal detection
- Validation: PMS system audited annually
PMS System Components
| Component |
Requirement |
Frequency |
| PMS Plan |
Article 84 |
Maintain current |
| PSUR |
Class IIa and higher |
Per class schedule |
| PMCF Plan |
Annex XIV Part B |
Update with CER |
| PMCF Report |
Annex XIV Part B |
Annual (Class III) |
| Vigilance |
Articles 87-92 |
As events occur |
PSUR Schedule
| Class |
Frequency |
| Class III |
Annual |
| Class IIb implantable |
Annual |
| Class IIb |
Every 2 years |
| Class IIa |
When necessary |
Serious Incident Reporting
| Timeline |
Requirement |
| 2 days |
Serious public health threat |
| 10 days |
Death or serious deterioration |
| 15 days |
Other serious incidents |
EUDAMED and UDI
Implement UDI system per Article 27:
- Obtain issuing entity code (GS1, HIBCC, ICCBBA)
- Assign UDI-DI to each device variant
- Assign UDI-PI (production identifier)
- Apply UDI carrier to labels (AIDC + HRI)
- Register actor in EUDAMED
- Register devices in EUDAMED
- Upload certificates when available
- Validation: UDI verified on sample labels
EUDAMED Modules
| Module |
Content |
Actor |
| Actor |
Company registration |
Manufacturer, AR |
| UDI/Device |
Device and variant data |
Manufacturer |
| Certificates |
NB certificates |
Notified Body |
| Clinical Investigation |
Study registration |
Sponsor |
| Vigilance |
Incident reports |
Manufacturer |
| Market Surveillance |
Authority actions |
Competent Authority |
UDI Label Requirements
Required elements per Article 13:
Reference Documentation
MDR Classification Guide
references/mdr-classification-guide.md contains:
- Complete Annex VIII classification rules (Rules 1-22)
- Software classification per MDCG 2019-11
- Worked classification examples
- Conformity assessment route selection
Clinical Evidence Requirements
references/clinical-evidence-requirements.md contains:
- Clinical evidence framework and hierarchy
- Literature search methodology
- Clinical Evaluation Report structure
- PMCF plan and evaluation report guidance
Technical Documentation Templates
references/technical-documentation-templates.md contains:
- Annex II and III content requirements
- Design History File structure
- GSPR compliance matrix template
- Declaration of Conformity template
- Notified Body submission checklist
Tools
MDR Gap Analyzer
# Quick gap analysis
python scripts/mdr_gap_analyzer.py --device "Device Name" --class IIa
# JSON output for integration
python scripts/mdr_gap_analyzer.py --device "Device Name" --class III --output json
# Interactive assessment
python scripts/mdr_gap_analyzer.py --interactive
Analyzes device against MDR requirements, identifies compliance gaps, generates prioritized recommendations.
Output includes:
- Requirements checklist by category
- Gap identification with priorities
- Critical gap highlighting
- Compliance roadmap recommendations
Notified Body Interface
Selection Criteria
| Factor |
Considerations |
| Designation scope |
Covers your device type |
| Capacity |
Timeline for initial audit |
| Geographic reach |
Markets you need to access |
| Technical expertise |
Experience with your technology |
| Fee structure |
Transparency, predictability |
Pre-Submission Checklist
MDCG Guidance Documents Update (2024-2025)
Key MDCG Guidance Documents
| Document |
Title |
Status |
Key Impact |
| MDCG 2024-1 |
Transition provisions under MDR Art. 120 |
Final (2024) |
Extended transition deadlines for legacy devices |
| MDCG 2024-6 |
Clinical evidence needed for medical devices previously CE marked under Directives |
Final (2024) |
Reduced clinical evidence burden for well-established devices |
| MDCG 2023-4 Rev.1 |
Notified Body capacity and availability |
Revised (2024) |
NB capacity monitoring and optimization |
| MDCG 2022-18 Rev.1 |
Software qualification and classification under MDR |
Revised (2024) |
Updated software classification algorithm |
| MDCG 2020-1 Rev.1 |
Clinical evaluation — equivalence |
Revised (2024) |
Refined equivalence demonstration requirements |
| MDCG 2019-16 Rev.1 |
Cybersecurity for medical devices |
Revised (2024) |
Enhanced cybersecurity requirements for connected devices |
| MDCG 2019-11 Rev.1 |
Qualification and classification of software |
Active |
Software as medical device classification |
MDR Transition Timeline (Post-Amendment Regulation 2023/607)
| Device Category |
Transition Deadline |
Conditions |
| Class III and implantable |
26 May 2026 |
Valid MDD/AIMDD certificate + QMS application to NB by 26 May 2024 |
| Class IIb |
31 December 2027 |
Valid certificate + QMS application to NB |
| Class IIa and Class I (sterile/measuring) |
31 December 2028 |
Valid certificate + QMS application to NB |
| Class I (up-classified under MDR) |
31 December 2028 |
Previously exempt from NB involvement |
Conditions for extended deadlines:
- Device continues to comply with MDD/AIMDD
- No significant changes in design or intended purpose
- No unacceptable safety or performance risk
- Manufacturer has applied to Notified Body for MDR conformity assessment before applicable deadline
Software as Medical Device Under MDR (MDCG 2019-11 Rev.1)
Software Qualification Decision
Is the software a medical device?
│
▼
Does the software perform an action on data?
│
Yes─┴─No → NOT a medical device (data storage/communication only)
│
▼
Is the action for the benefit of individual patients?
│
Yes─┴─No → NOT a medical device (population health/admin)
│
▼
Is the action one of: treatment, diagnosis, monitoring, prediction?
│
Yes─┴─No → NOT a medical device (lifestyle/wellness)
│
▼
QUALIFIES AS MEDICAL DEVICE SOFTWARE → Apply classification rules
Software Classification Under MDR
| Decision Factor |
Class IIa |
Class IIb |
Class III |
| Provides information to inform clinical management |
Non-serious conditions |
Serious conditions |
N/A |
| Drives clinical management or diagnoses |
N/A |
Non-serious conditions |
Serious or critical conditions |
| Monitors physiological processes |
Non-vital parameters |
Vital parameters (not immediate danger) |
Vital parameters (immediate danger) |
Software Lifecycle Requirements Under MDR
| MDR Requirement |
IEC 62304 Mapping |
Documentation |
| GSPR 17.1 (repeatability, reliability) |
Software development process |
Software development plan |
| GSPR 17.2 (state of the art) |
Software architecture |
Architecture design document |
| GSPR 17.3 (minimum IT requirements) |
System requirements |
IT environment specification |
| GSPR 17.4 (foreseeable misuse) |
Risk management |
Software risk analysis |
| Annex II §6.5 (software verification) |
Software testing |
Test plans and reports |
| Annex I §23.4 (labeling for software) |
Release documentation |
Software release notes |
AI/ML Medical Devices Under MDR
AI/ML Classification Considerations
| AI/ML Capability |
MDR Classification Impact |
Regulatory Consideration |
| AI-assisted detection |
Typically Class IIa-IIb (Rule 11) |
Must demonstrate clinical performance per intended use |
| AI-driven diagnosis |
Typically Class IIb-III (Rule 11) |
Requires clinical investigation for novel indications |
| AI treatment optimization |
Typically Class IIb-III (Rule 11 + specific rules) |
Benefit-risk analysis must account for AI uncertainty |
| Continuously learning AI |
Classification per highest risk output |
Post-market monitoring must track algorithm evolution |
AI/ML-Specific Technical Documentation
In addition to standard Annex II requirements, AI/ML devices must document:
| Section |
Content |
MDCG Reference |
| Algorithm description |
Architecture, training approach, feature engineering |
MDCG 2019-11, IMDRF SaMD WG |
| Training data |
Sources, demographics, size, labeling methodology, quality |
MDCG 2020-1 (equivalence) |
| Validation methodology |
Test dataset independence, performance metrics, subgroup analysis |
Annex XIV |
| Clinical performance |
Sensitivity, specificity, AUC, PPV, NPV per intended population |
CER requirements |
| Change management |
How algorithm updates are validated and deployed |
GSPR 17 |
| Explainability |
How the AI's output can be understood by intended users |
GSPR 23 (labeling) |
EU AI Act Interaction with MDR
| EU AI Act Requirement |
MDR Equivalent |
Combined Approach |
| High-risk classification (Annex III, Point 10) |
Annex VIII classification rules |
Both classifications apply; meet stricter requirement |
| Conformity assessment (Art. 43) |
Annex IX/X/XI assessment |
MDR conformity assessment satisfies AI Act (Art. 120) |
| Technical documentation (Annex IV) |
Annex II technical documentation |
Extend MDR technical file with AI Act-specific elements |
| Risk management (Art. 9) |
ISO 14971 + GSPR |
ISO 14971 satisfies both when AI risks are included |
| Data governance (Art. 10) |
GSPR 17 + Annex XIV |
Add AI-specific data governance to clinical evaluation |
| Post-market monitoring (Art. 72) |
Chapter VII PMS |
Single PMS system covering both AI Act and MDR |
See also: ../risk-management-specialist/SKILL.md for AI-specific risk management under ISO 14971, and ../fda-consultant-specialist/SKILL.md for FDA's AI/ML SaMD framework and PCCP.
Eudamed Implementation Status and Requirements
Eudamed Module Deployment Status (as of 2025)
| Module |
Status |
Mandatory Date |
Content |
| Actor Registration |
Operational |
Available now |
Economic operator registration |
| UDI/Device Registration |
Operational |
6 months after Eudamed fully functional |
Device and UDI-DI data |
| Notified Body and Certificates |
Operational |
Available now |
Certificate data upload by NBs |
| Clinical Investigations |
Operational |
Available now |
Study registration and reporting |
| Vigilance |
Partially operational |
24 months after fully functional |
Incident reports, FSCAs, trend reports |
| Market Surveillance |
In development |
18 months after fully functional |
CA market surveillance activities |
Key consideration: Until Eudamed is declared fully functional by the European Commission, manufacturers must use existing national systems (e.g., BfArM in Germany, ANSM in France) for vigilance reporting.
Eudamed Registration Requirements for Manufacturers
| Data Element |
Required For |
Update Frequency |
| SRN (Single Registration Number) |
All manufacturers |
On change |
| Authorized representative details |
Non-EU manufacturers |
On change |
| Device identification (UDI-DI) |
All devices placed on market |
Before first placing on market |
| Basic UDI-DI |
Device model/family grouping |
Before first placing on market |
| GMDN code |
Device nomenclature |
On initial registration |
| Risk class |
Classification per Annex VIII |
On initial registration |
| NB certificate reference |
Class IIa and above |
When certificate issued |
| Clinical investigation registration |
Interventional studies |
Before study start |
UDI-DI and UDI-PI Detailed Requirements
UDI-DI (Device Identifier) — Static Information
| Element |
Description |
Example |
| Device identifier |
Unique code for device model/version |
04069876543219 (GS1 GTIN) |
| Issuing entity |
GS1, HIBCC, ICCBBA, or IFA |
Selected by manufacturer |
| Device model |
Specific device configuration |
"CardioMonitor X200" |
| Device version |
Software version (for SaMD) |
"v3.1.0" |
| Applicable regulations |
MDR or IVDR reference |
MDR 2017/745 |
| Risk class |
Per Annex VIII |
Class IIa |
| Basic UDI-DI |
Grouping identifier for device family |
04069876500001 |
UDI-PI (Production Identifier) — Variable Information
| PI Element |
When Required |
Format |
| Lot/batch number |
When tracking by lot |
Lot: ABC123 |
| Serial number |
When individual tracking required (Class III, implantable) |
SN: 2024-00001 |
| Manufacturing date |
When relevant to safety |
Mfg: 2024-06-15 |
| Expiry date |
When device has shelf life |
Exp: 2026-06-15 |
| Software version |
SaMD and software-driven devices |
SW: v3.1.0 |
UDI Carrier Requirements
| Carrier Type |
Format |
Where Applied |
| AIDC (barcode/2D code) |
GS1 DataMatrix, GS1-128, HIBC |
Device label, package label |
| HRI (human-readable) |
Plain text interpretation of AIDC |
Adjacent to AIDC on label |
| RFID |
GS1 EPC/RFID |
Optional, in addition to AIDC |
Labeling placement rules:
- UDI on each level of packaging (unit, intermediate, case)
- For reusable devices requiring sterilization: UDI on device itself (direct marking)
- Class III implantable: UDI on device or packaging that remains with patient record
- UDI must survive device lifecycle (including reprocessing cycles for reusable devices)
UDI Database Submission Timeline
| Device Class |
Submission Deadline |
| Class III and implantable |
Before placing on the market |
| Class IIb |
Before placing on the market |
| Class IIa |
Before placing on the market |
| Class I |
Before placing on the market |
Note: All timelines are contingent on Eudamed being declared fully functional. Until then, manufacturers should pre-register in Eudamed (available modules) and maintain data readiness.
Cross-Reference: NIS2 for Critical Infrastructure (Healthcare)
Healthcare organizations manufacturing or deploying medical devices may be classified as essential entities under NIS2:
| NIS2 Requirement |
MDR Impact |
Action for Manufacturers |
| Art. 21: Cybersecurity risk management |
MDCG 2019-16 cybersecurity guidance |
Align device cybersecurity with organizational NIS2 compliance |
| Art. 23: Incident reporting (24h/72h) |
Art. 87-92 vigilance reporting |
Unified incident reporting covering both device and infrastructure incidents |
| Art. 21(2)(d): Supply chain security |
Art. 11 authorized representatives, supply chain |
Assess cybersecurity of device component suppliers |
| Art. 20: Governance and accountability |
Art. 10 manufacturer obligations |
Senior management oversight of both NIS2 and MDR compliance |
See also: ../information-security-manager-iso27001/SKILL.md for ISO 27001 alignment with NIS2 requirements.
MDR Updates & Cross-Framework Integration
Latest MDCG Guidance Documents
- MDCG 2019-11 Rev.1: Qualification and classification of software — updated algorithm for SaMD
- MDCG 2020-1 Rev.1: Clinical evaluation (Annex XIV) — updated methodologies
- MDCG 2024-8: EU AI Act interaction with MDR for AI-enabled medical devices
- MDCG 2023-4: Legacy devices and Article 120 transition provisions
AI/ML Medical Devices Under MDR
- Classification: AI/ML-based SaMD typically Class IIa or higher (Rule 11)
- Clinical Evidence: Must demonstrate AI algorithm clinical performance (sensitivity, specificity, AUC)
- Continuous Learning: PCCP-equivalent under MDR for adaptive AI devices
- Post-Market: Enhanced PMCF for AI devices monitoring real-world algorithm performance
- EU AI Act Interaction: High-risk AI medical devices subject to BOTH MDR and EU AI Act
- Cross-reference: See
eu-ai-act-specialist for AI Act obligations
NIS2 Impact on Healthcare
- Healthcare entities are "Essential Entities" under NIS2 Directive
- Medical device manufacturers may be "Important Entities"
- NIS2 cybersecurity requirements supplement MDR cybersecurity expectations
- Cross-reference: See
nis2-directive-specialist for NIS2 compliance
EUDAMED Implementation Status
- Actor Registration Module: Operational — all economic operators must register
- UDI/Device Registration Module: Operational — mandatory device registration
- Notified Body Module: Operational — certificate information
- Clinical Investigation Module: Available
- Vigilance Module: Under development
- Market Surveillance Module: Under development
UDI Detailed Requirements
- UDI-DI (Device Identifier): Unique to device model — used for EUDAMED registration
- UDI-PI (Production Identifier): Identifies production unit — lot, serial, expiry, manufacturing date
- Issuing Entities: GS1, HIBCC, ICCBBA, IFA
- Carrier Types: AIDC (barcode/2D) + HRI (human readable)
- Implant Card: Required for Class III implantable devices (UDI + patient information)
Troubleshooting
| Problem |
Possible Cause |
Resolution |
| Device classification unclear -- rules yield different results |
Multiple classification rules apply; highest class must be selected per MDR Article 51(7) |
Apply all applicable rules from Annex VIII (Rules 1-22); use the implementing rule that gives the highest classification; for software, apply MDCG 2019-11 Rev.1 algorithm; document rationale for each rule considered |
| Notified Body rejects technical file for incompleteness |
GSPR compliance matrix gaps, missing clinical evaluation, or insufficient risk management documentation |
Review GSPR checklist in this skill; ensure Annex II technical file structure is complete; verify CER meets Annex XIV requirements; confirm ISO 14971 risk management file is current and comprehensive |
| EUDAMED registration delays blocking market access |
Module not operational or manufacturer SRN not obtained |
Check current EUDAMED module status; obtain SRN via actor registration module (operational); use national systems for vigilance reporting until Eudamed Vigilance module is fully functional |
| Clinical evidence insufficient for Class IIb/III device |
Equivalence route rejected by NB or clinical investigation not planned |
Reassess equivalence per MDCG 2020-1 Rev.1 (technical, biological, clinical equivalence with access to data); if equivalence fails, plan clinical investigation per Article 61; consider MDCG 2024-6 for reduced evidence burden on well-established devices |
| MDR transition deadline approaching with NB application pending |
Limited NB capacity (approximately 40 designated EU-wide as of 2025) |
Verify transition deadline for your device class (Class III: May 2026, Class IIb: Dec 2027, Class IIa: Dec 2028); ensure QMS application was submitted to NB by applicable deadline; maintain MDD/AIMDD compliance during transition |
| UDI labeling rejected by NB or competent authority |
UDI-DI/UDI-PI format incorrect, AIDC carrier unreadable, or missing elements |
Verify all required UDI elements per Article 27; ensure AIDC format (GS1 DataMatrix preferred) is scannable; include HRI adjacent to barcode; for reusable devices, apply direct marking that survives reprocessing |
| AI/ML medical device faces dual regulatory obligations |
Device classified under both MDR and EU AI Act as high-risk |
Assess both MDR Annex VIII classification and EU AI Act Annex III categorization; MDR conformity assessment may satisfy AI Act per Art. 120; extend technical documentation with AI-specific elements per MDCG 2024-8 |
Success Criteria
- Device correctly classified with documented rationale -- classification per Annex VIII with all applicable rules evaluated, highest class selected, and rationale documented for NB review
- Complete technical file per Annex II structure -- device description, labeling/IFU, design and manufacturing info, GSPR compliance matrix, benefit-risk analysis, verification and validation, and clinical evaluation report all present and current
- GSPR compliance matrix fully addressed -- all applicable General Safety and Performance Requirements mapped to evidence with cross-references to risk management file, biocompatibility reports, sterilization validation, software documentation, and labeling
- Clinical evaluation report meets Annex XIV requirements -- literature search methodology documented, data appraised and analyzed, safety and performance conclusions stated, benefit-risk determined, and PMCF plan included
- PMS system operational -- PMS plan per Article 84, complaint handling procedures, vigilance reporting process, PSUR schedule defined by class, and PMCF activities integrated with CER
- UDI system fully implemented -- UDI-DI assigned per device variant, UDI-PI applied (lot/serial/dates), AIDC and HRI carriers on all packaging levels, EUDAMED registration complete (when applicable)
- MDR gap analysis shows zero critical gaps -- as measured by
mdr_gap_analyzer.py, with all requirements addressed or in-progress with documented timeline
Scope & Limitations
In Scope:
- Device classification per MDR Annex VIII (Rules 1-22) including software classification per MDCG 2019-11 Rev.1
- Technical documentation structure and requirements per Annex II and Annex III
- GSPR compliance matrix with evidence mapping
- Clinical evidence strategy including equivalence assessment, CER structure, and PMCF planning
- Post-market surveillance system design including PMS plan, PSUR schedule, and vigilance reporting timelines
- EUDAMED and UDI system implementation guidance
- Conformity assessment route selection by device class
- MDR transition timeline tracking (post-Amendment Regulation 2023/607)
- AI/ML medical device considerations including EU AI Act interaction
Out of Scope:
- Clinical investigation protocol design, execution, or statistical analysis
- Biocompatibility testing per ISO 10993 (beyond evidence mapping in GSPR)
- Sterilization validation per ISO 11135/11137 (beyond evidence mapping)
- Notified Body selection, engagement, or commercial negotiation
- Quality Management System implementation -- use
quality-manager-qms-iso13485 for ISO 13485 QMS
- Risk management process implementation -- use
risk-management-specialist for ISO 14971
Important Notes:
- EUDAMED's first four modules became mandatory from May 28, 2026; manufacturers must have SRN and device registrations ready
- Only approximately 40 Notified Bodies are designated EU-wide as of 2025, creating capacity constraints; early NB engagement is critical
- The European Commission published updated transition timelines in December 2025 extending deadlines for certain device categories
- Manufacturers must adopt recently harmonized standards with no formal transition period (Decision EU 2025/2078)
Integration Points
| Skill |
Integration |
When to Use |
fda-consultant-specialist |
Cross-framework mapping for dual US/EU market; FDA QMSR aligns with ISO 13485 used by MDR |
When device requires both FDA clearance/approval and EU MDR CE marking |
quality-manager-qms-iso13485 |
ISO 13485 QMS is prerequisite for MDR conformity assessment (Annex IX, XI) |
When establishing or auditing QMS for MDR compliance |
risk-management-specialist |
ISO 14971 risk management file is core component of MDR technical documentation |
When developing risk management file, FMEA, and benefit-risk analysis |
eu-ai-act-specialist |
AI medical devices subject to both MDR and EU AI Act; classification and conformity assessment interaction |
When AI-enabled medical device requires dual regulatory compliance |
capa-officer |
CAPA process supports MDR vigilance obligations and FSCA implementation |
When post-market surveillance identifies safety or performance issues requiring corrective action |
infrastructure-compliance-auditor |
Cybersecurity validation per MDCG 2019-16 Rev.1 for connected medical devices |
When connected device requires cybersecurity documentation for technical file |
Tool Reference
mdr_gap_analyzer.py
Analyzes device against MDR requirements, identifies compliance gaps, and generates prioritized recommendations.
| Flag |
Required |
Description |
--device <name> |
Yes (unless --interactive) |
Device name for gap analysis |
--class <class> |
Yes (unless --interactive) |
Device classification: I, Is, Im, IIa, IIb, III |
--output <format> |
No |
Output format: json for machine-readable output; default is human-readable text |
--interactive |
No |
Launch interactive assessment mode with guided questions |
Analysis Categories: Technical documentation (Annex II), GSPR compliance, clinical evidence (Annex XIV), post-market surveillance (Chapter VII), UDI/EUDAMED, labeling (Article 13), quality management system, risk management, and conformity assessment route.
Output: Requirements checklist with per-item status (Not Started/In Progress/Complete/N/A), gap identification with priority (Critical/High/Medium/Low), critical gap highlighting, completion percentage, and compliance roadmap recommendations.
1---
2name: mdr-745-specialist
3description: >
4 EU MDR 2017/745 compliance specialist for medical device classification,
5 technical documentation, clinical evidence, and post-market surveillance. Use for
6 Annex VIII classification, GSPR, clinical evaluation, EUDAMED, and UDI.
7license: MIT + Commons Clause
8metadata:
9 version: 1.0.0
10 author: borghei
11 category: compliance
12 domain: medical-device-regulation
13 updated: 2026-03-31
14 tags: [eu-mdr, medical-device, gspr, eudamed, udi]
15---
16
17# MDR 2017/745 Specialist
18
19EU MDR compliance patterns for medical device classification, technical documentation, and clinical evidence.
20
21---
22
23## Table of Contents
24
25- [Device Classification Workflow](#device-classification-workflow)
26- [Technical Documentation](#technical-documentation)
27- [Clinical Evidence](#clinical-evidence)
28- [Post-Market Surveillance](#post-market-surveillance)
29- [EUDAMED and UDI](#eudamed-and-udi)
30- [Reference Documentation](#reference-documentation)
31- [Tools](#tools)
32
33---
34
35## Clarify First
36
37Before classifying the device or analyzing gaps, confirm these inputs. If any is unknown or vague, ASK — do not assume:
38
39- [ ] **Device characteristics** — duration, invasiveness, body-system contact, and whether it is active/software (drives the Annex VIII classification)
40- [ ] **Intended purpose** — the device's claimed clinical purpose (sets the applicable rule and clinical-evidence level)
41- [ ] **Software/AI nature** — whether it is software as a medical device (MDCG 2019-11) or AI/ML (changes classification and the documentation set)
42
43Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the classification.
44
45## Device Classification Workflow
46
47Classify device under MDR Annex VIII:
48
491. Identify device duration (transient, short-term, long-term)
502. Determine invasiveness level (non-invasive, body orifice, surgical)
513. Assess body system contact (CNS, cardiac, other)
524. Check if active device (energy dependent)
535. Apply classification rules 1-22
546. For software, apply MDCG 2019-11 algorithm
557. Document classification rationale
568. **Validation:** Classification confirmed with Notified Body
57
58### Classification Matrix
59
60| Factor | Class I | Class IIa | Class IIb | Class III |
61|--------|---------|-----------|-----------|-----------|
62| Duration | Any | Short-term | Long-term | Long-term |
63| Invasiveness | Non-invasive | Body orifice | Surgical | Implantable |
64| System | Any | Non-critical | Critical organs | CNS/cardiac |
65| Risk | Lowest | Low-medium | Medium-high | Highest |
66
67### Software Classification (MDCG 2019-11)
68
69| Information Use | Condition Severity | Class |
70|-----------------|-------------------|-------|
71| Informs decision | Non-serious | IIa |
72| Informs decision | Serious | IIb |
73| Drives/treats | Critical | III |
74
75### Classification Examples
76
77**Example 1: Absorbable Surgical Suture**
78- Rule 8 (implantable, long-term)
79- Duration: > 30 days (absorbed)
80- Contact: General tissue
81- Classification: **Class IIb**
82
83**Example 2: AI Diagnostic Software**
84- Rule 11 + MDCG 2019-11
85- Function: Diagnoses serious condition
86- Classification: **Class IIb**
87
88**Example 3: Cardiac Pacemaker**
89- Rule 8 (implantable)
90- Contact: Central circulatory system
91- Classification: **Class III**
92
93---
94
95## Technical Documentation
96
97Prepare technical file per Annex II and III:
98
991. Create device description (variants, accessories, intended purpose)
1002. Develop labeling (Article 13 requirements, IFU)
1013. Document design and manufacturing process
1024. Complete GSPR compliance matrix
1035. Prepare benefit-risk analysis
1046. Compile verification and validation evidence
1057. Integrate risk management file (ISO 14971)
1068. **Validation:** Technical file reviewed for completeness
107
108### Technical File Structure
109
110```
111ANNEX II TECHNICAL DOCUMENTATION
112├── Device description and UDI-DI
113├── Label and instructions for use
114├── Design and manufacturing info
115├── GSPR compliance matrix
116├── Benefit-risk analysis
117├── Verification and validation
118└── Clinical evaluation report
119```
120
121### GSPR Compliance Checklist
122
123| Requirement | Evidence | Status |
124|-------------|----------|--------|
125| Safe design (GSPR 1-3) | Risk management file | ☐ |
126| Chemical properties (GSPR 10.1) | Biocompatibility report | ☐ |
127| Infection risk (GSPR 10.2) | Sterilization validation | ☐ |
128| Software requirements (GSPR 17) | IEC 62304 documentation | ☐ |
129| Labeling (GSPR 23) | Label artwork, IFU | ☐ |
130
131### Conformity Assessment Routes
132
133| Class | Route | NB Involvement |
134|-------|-------|----------------|
135| I | Annex II self-declaration | None |
136| Is/Im | Annex II + IX/XI | Sterile/measuring aspects |
137| IIa | Annex II + IX or XI | Product or QMS |
138| IIb | Annex IX + X or X + XI | Type exam + production |
139| III | Annex IX + X | Full QMS + type exam |
140
141---
142
143## Clinical Evidence
144
145Develop clinical evidence strategy per Annex XIV:
146
1471. Define clinical claims and endpoints
1482. Conduct systematic literature search
1493. Appraise clinical data quality
1504. Assess equivalence (technical, biological, clinical)
1515. Identify evidence gaps
1526. Determine if clinical investigation required
1537. Prepare Clinical Evaluation Report (CER)
1548. **Validation:** CER reviewed by qualified evaluator
155
156### Evidence Requirements by Class
157
158| Class | Minimum Evidence | Investigation |
159|-------|------------------|---------------|
160| I | Risk-benefit analysis | Not typically required |
161| IIa | Literature + post-market | May be required |
162| IIb | Systematic literature review | Often required |
163| III | Comprehensive clinical data | Required (Article 61) |
164
165### Clinical Evaluation Report Structure
166
167```
168CER CONTENTS
169├── Executive summary
170├── Device scope and intended purpose
171├── Clinical background (state of the art)
172├── Literature search methodology
173├── Data appraisal and analysis
174├── Safety and performance conclusions
175├── Benefit-risk determination
176└── PMCF plan summary
177```
178
179### Qualified Evaluator Requirements
180
181- Medical degree or equivalent healthcare qualification
182- 4+ years clinical experience in relevant field
183- Training in clinical evaluation methodology
184- Understanding of MDR requirements
185
186---
187
188## Post-Market Surveillance
189
190Establish PMS system per Chapter VII:
191
1921. Develop PMS plan (Article 84)
1932. Define data collection methods
1943. Establish complaint handling procedures
1954. Create vigilance reporting process
1965. Plan Periodic Safety Update Reports (PSUR)
1976. Integrate with PMCF activities
1987. Define trend analysis and signal detection
1998. **Validation:** PMS system audited annually
200
201### PMS System Components
202
203| Component | Requirement | Frequency |
204|-----------|-------------|-----------|
205| PMS Plan | Article 84 | Maintain current |
206| PSUR | Class IIa and higher | Per class schedule |
207| PMCF Plan | Annex XIV Part B | Update with CER |
208| PMCF Report | Annex XIV Part B | Annual (Class III) |
209| Vigilance | Articles 87-92 | As events occur |
210
211### PSUR Schedule
212
213| Class | Frequency |
214|-------|-----------|
215| Class III | Annual |
216| Class IIb implantable | Annual |
217| Class IIb | Every 2 years |
218| Class IIa | When necessary |
219
220### Serious Incident Reporting
221
222| Timeline | Requirement |
223|----------|-------------|
224| 2 days | Serious public health threat |
225| 10 days | Death or serious deterioration |
226| 15 days | Other serious incidents |
227
228---
229
230## EUDAMED and UDI
231
232Implement UDI system per Article 27:
233
2341. Obtain issuing entity code (GS1, HIBCC, ICCBBA)
2352. Assign UDI-DI to each device variant
2363. Assign UDI-PI (production identifier)
2374. Apply UDI carrier to labels (AIDC + HRI)
2385. Register actor in EUDAMED
2396. Register devices in EUDAMED
2407. Upload certificates when available
2418. **Validation:** UDI verified on sample labels
242
243### EUDAMED Modules
244
245| Module | Content | Actor |
246|--------|---------|-------|
247| Actor | Company registration | Manufacturer, AR |
248| UDI/Device | Device and variant data | Manufacturer |
249| Certificates | NB certificates | Notified Body |
250| Clinical Investigation | Study registration | Sponsor |
251| Vigilance | Incident reports | Manufacturer |
252| Market Surveillance | Authority actions | Competent Authority |
253
254### UDI Label Requirements
255
256Required elements per Article 13:
257
258- [ ] UDI-DI (device identifier)
259- [ ] UDI-PI (production identifier) for Class II+
260- [ ] AIDC format (barcode/RFID)
261- [ ] HRI format (human-readable)
262- [ ] Manufacturer name and address
263- [ ] Lot/serial number
264- [ ] Expiration date (if applicable)
265
266---
267
268## Reference Documentation
269
270### MDR Classification Guide
271
272`references/mdr-classification-guide.md` contains:
273
274- Complete Annex VIII classification rules (Rules 1-22)
275- Software classification per MDCG 2019-11
276- Worked classification examples
277- Conformity assessment route selection
278
279### Clinical Evidence Requirements
280
281`references/clinical-evidence-requirements.md` contains:
282
283- Clinical evidence framework and hierarchy
284- Literature search methodology
285- Clinical Evaluation Report structure
286- PMCF plan and evaluation report guidance
287
288### Technical Documentation Templates
289
290`references/technical-documentation-templates.md` contains:
291
292- Annex II and III content requirements
293- Design History File structure
294- GSPR compliance matrix template
295- Declaration of Conformity template
296- Notified Body submission checklist
297
298---
299
300## Tools
301
302### MDR Gap Analyzer
303
304```bash
305# Quick gap analysis
306python scripts/mdr_gap_analyzer.py --device "Device Name" --class IIa
307
308# JSON output for integration
309python scripts/mdr_gap_analyzer.py --device "Device Name" --class III --output json
310
311# Interactive assessment
312python scripts/mdr_gap_analyzer.py --interactive
313```
314
315Analyzes device against MDR requirements, identifies compliance gaps, generates prioritized recommendations.
316
317**Output includes:**
318- Requirements checklist by category
319- Gap identification with priorities
320- Critical gap highlighting
321- Compliance roadmap recommendations
322
323---
324
325## Notified Body Interface
326
327### Selection Criteria
328
329| Factor | Considerations |
330|--------|----------------|
331| Designation scope | Covers your device type |
332| Capacity | Timeline for initial audit |
333| Geographic reach | Markets you need to access |
334| Technical expertise | Experience with your technology |
335| Fee structure | Transparency, predictability |
336
337### Pre-Submission Checklist
338
339- [ ] Technical documentation complete
340- [ ] GSPR matrix fully addressed
341- [ ] Risk management file current
342- [ ] Clinical evaluation report complete
343- [ ] QMS (ISO 13485) certified
344- [ ] Labeling and IFU finalized
345- [ ] **Validation:** Internal gap assessment complete
346
347---
348
349## MDCG Guidance Documents Update (2024-2025)
350
351### Key MDCG Guidance Documents
352
353| Document | Title | Status | Key Impact |
354|----------|-------|--------|------------|
355| MDCG 2024-1 | Transition provisions under MDR Art. 120 | Final (2024) | Extended transition deadlines for legacy devices |
356| MDCG 2024-6 | Clinical evidence needed for medical devices previously CE marked under Directives | Final (2024) | Reduced clinical evidence burden for well-established devices |
357| MDCG 2023-4 Rev.1 | Notified Body capacity and availability | Revised (2024) | NB capacity monitoring and optimization |
358| MDCG 2022-18 Rev.1 | Software qualification and classification under MDR | Revised (2024) | Updated software classification algorithm |
359| MDCG 2020-1 Rev.1 | Clinical evaluation — equivalence | Revised (2024) | Refined equivalence demonstration requirements |
360| MDCG 2019-16 Rev.1 | Cybersecurity for medical devices | Revised (2024) | Enhanced cybersecurity requirements for connected devices |
361| MDCG 2019-11 Rev.1 | Qualification and classification of software | Active | Software as medical device classification |
362
363### MDR Transition Timeline (Post-Amendment Regulation 2023/607)
364
365| Device Category | Transition Deadline | Conditions |
366|----------------|--------------------|-----------|
367| Class III and implantable | 26 May 2026 | Valid MDD/AIMDD certificate + QMS application to NB by 26 May 2024 |
368| Class IIb | 31 December 2027 | Valid certificate + QMS application to NB |
369| Class IIa and Class I (sterile/measuring) | 31 December 2028 | Valid certificate + QMS application to NB |
370| Class I (up-classified under MDR) | 31 December 2028 | Previously exempt from NB involvement |
371
372**Conditions for extended deadlines:**
373- Device continues to comply with MDD/AIMDD
374- No significant changes in design or intended purpose
375- No unacceptable safety or performance risk
376- Manufacturer has applied to Notified Body for MDR conformity assessment before applicable deadline
377
378---
379
380## Software as Medical Device Under MDR (MDCG 2019-11 Rev.1)
381
382### Software Qualification Decision
383
384```
385Is the software a medical device?
386 │
387 ▼
388Does the software perform an action on data?
389 │
390 Yes─┴─No → NOT a medical device (data storage/communication only)
391 │
392 ▼
393Is the action for the benefit of individual patients?
394 │
395 Yes─┴─No → NOT a medical device (population health/admin)
396 │
397 ▼
398Is the action one of: treatment, diagnosis, monitoring, prediction?
399 │
400 Yes─┴─No → NOT a medical device (lifestyle/wellness)
401 │
402 ▼
403QUALIFIES AS MEDICAL DEVICE SOFTWARE → Apply classification rules
404```
405
406### Software Classification Under MDR
407
408| Decision Factor | Class IIa | Class IIb | Class III |
409|----------------|-----------|-----------|-----------|
410| Provides information to inform clinical management | Non-serious conditions | Serious conditions | N/A |
411| Drives clinical management or diagnoses | N/A | Non-serious conditions | Serious or critical conditions |
412| Monitors physiological processes | Non-vital parameters | Vital parameters (not immediate danger) | Vital parameters (immediate danger) |
413
414### Software Lifecycle Requirements Under MDR
415
416| MDR Requirement | IEC 62304 Mapping | Documentation |
417|----------------|-------------------|---------------|
418| GSPR 17.1 (repeatability, reliability) | Software development process | Software development plan |
419| GSPR 17.2 (state of the art) | Software architecture | Architecture design document |
420| GSPR 17.3 (minimum IT requirements) | System requirements | IT environment specification |
421| GSPR 17.4 (foreseeable misuse) | Risk management | Software risk analysis |
422| Annex II §6.5 (software verification) | Software testing | Test plans and reports |
423| Annex I §23.4 (labeling for software) | Release documentation | Software release notes |
424
425---
426
427## AI/ML Medical Devices Under MDR
428
429### AI/ML Classification Considerations
430
431| AI/ML Capability | MDR Classification Impact | Regulatory Consideration |
432|-----------------|--------------------------|-------------------------|
433| AI-assisted detection | Typically Class IIa-IIb (Rule 11) | Must demonstrate clinical performance per intended use |
434| AI-driven diagnosis | Typically Class IIb-III (Rule 11) | Requires clinical investigation for novel indications |
435| AI treatment optimization | Typically Class IIb-III (Rule 11 + specific rules) | Benefit-risk analysis must account for AI uncertainty |
436| Continuously learning AI | Classification per highest risk output | Post-market monitoring must track algorithm evolution |
437
438### AI/ML-Specific Technical Documentation
439
440In addition to standard Annex II requirements, AI/ML devices must document:
441
442| Section | Content | MDCG Reference |
443|---------|---------|----------------|
444| Algorithm description | Architecture, training approach, feature engineering | MDCG 2019-11, IMDRF SaMD WG |
445| Training data | Sources, demographics, size, labeling methodology, quality | MDCG 2020-1 (equivalence) |
446| Validation methodology | Test dataset independence, performance metrics, subgroup analysis | Annex XIV |
447| Clinical performance | Sensitivity, specificity, AUC, PPV, NPV per intended population | CER requirements |
448| Change management | How algorithm updates are validated and deployed | GSPR 17 |
449| Explainability | How the AI's output can be understood by intended users | GSPR 23 (labeling) |
450
451### EU AI Act Interaction with MDR
452
453| EU AI Act Requirement | MDR Equivalent | Combined Approach |
454|----------------------|----------------|-------------------|
455| High-risk classification (Annex III, Point 10) | Annex VIII classification rules | Both classifications apply; meet stricter requirement |
456| Conformity assessment (Art. 43) | Annex IX/X/XI assessment | MDR conformity assessment satisfies AI Act (Art. 120) |
457| Technical documentation (Annex IV) | Annex II technical documentation | Extend MDR technical file with AI Act-specific elements |
458| Risk management (Art. 9) | ISO 14971 + GSPR | ISO 14971 satisfies both when AI risks are included |
459| Data governance (Art. 10) | GSPR 17 + Annex XIV | Add AI-specific data governance to clinical evaluation |
460| Post-market monitoring (Art. 72) | Chapter VII PMS | Single PMS system covering both AI Act and MDR |
461
462> **See also:** `../risk-management-specialist/SKILL.md` for AI-specific risk management under ISO 14971, and `../fda-consultant-specialist/SKILL.md` for FDA's AI/ML SaMD framework and PCCP.
463
464---
465
466## Eudamed Implementation Status and Requirements
467
468### Eudamed Module Deployment Status (as of 2025)
469
470| Module | Status | Mandatory Date | Content |
471|--------|--------|----------------|---------|
472| Actor Registration | Operational | Available now | Economic operator registration |
473| UDI/Device Registration | Operational | 6 months after Eudamed fully functional | Device and UDI-DI data |
474| Notified Body and Certificates | Operational | Available now | Certificate data upload by NBs |
475| Clinical Investigations | Operational | Available now | Study registration and reporting |
476| Vigilance | Partially operational | 24 months after fully functional | Incident reports, FSCAs, trend reports |
477| Market Surveillance | In development | 18 months after fully functional | CA market surveillance activities |
478
479**Key consideration:** Until Eudamed is declared fully functional by the European Commission, manufacturers must use existing national systems (e.g., BfArM in Germany, ANSM in France) for vigilance reporting.
480
481### Eudamed Registration Requirements for Manufacturers
482
483| Data Element | Required For | Update Frequency |
484|-------------|-------------|-----------------|
485| SRN (Single Registration Number) | All manufacturers | On change |
486| Authorized representative details | Non-EU manufacturers | On change |
487| Device identification (UDI-DI) | All devices placed on market | Before first placing on market |
488| Basic UDI-DI | Device model/family grouping | Before first placing on market |
489| GMDN code | Device nomenclature | On initial registration |
490| Risk class | Classification per Annex VIII | On initial registration |
491| NB certificate reference | Class IIa and above | When certificate issued |
492| Clinical investigation registration | Interventional studies | Before study start |
493
494---
495
496## UDI-DI and UDI-PI Detailed Requirements
497
498### UDI-DI (Device Identifier) — Static Information
499
500| Element | Description | Example |
501|---------|-------------|---------|
502| Device identifier | Unique code for device model/version | 04069876543219 (GS1 GTIN) |
503| Issuing entity | GS1, HIBCC, ICCBBA, or IFA | Selected by manufacturer |
504| Device model | Specific device configuration | "CardioMonitor X200" |
505| Device version | Software version (for SaMD) | "v3.1.0" |
506| Applicable regulations | MDR or IVDR reference | MDR 2017/745 |
507| Risk class | Per Annex VIII | Class IIa |
508| Basic UDI-DI | Grouping identifier for device family | 04069876500001 |
509
510### UDI-PI (Production Identifier) — Variable Information
511
512| PI Element | When Required | Format |
513|-----------|---------------|--------|
514| Lot/batch number | When tracking by lot | Lot: ABC123 |
515| Serial number | When individual tracking required (Class III, implantable) | SN: 2024-00001 |
516| Manufacturing date | When relevant to safety | Mfg: 2024-06-15 |
517| Expiry date | When device has shelf life | Exp: 2026-06-15 |
518| Software version | SaMD and software-driven devices | SW: v3.1.0 |
519
520### UDI Carrier Requirements
521
522| Carrier Type | Format | Where Applied |
523|-------------|--------|---------------|
524| AIDC (barcode/2D code) | GS1 DataMatrix, GS1-128, HIBC | Device label, package label |
525| HRI (human-readable) | Plain text interpretation of AIDC | Adjacent to AIDC on label |
526| RFID | GS1 EPC/RFID | Optional, in addition to AIDC |
527
528**Labeling placement rules:**
529- UDI on each level of packaging (unit, intermediate, case)
530- For reusable devices requiring sterilization: UDI on device itself (direct marking)
531- Class III implantable: UDI on device or packaging that remains with patient record
532- UDI must survive device lifecycle (including reprocessing cycles for reusable devices)
533
534### UDI Database Submission Timeline
535
536| Device Class | Submission Deadline |
537|-------------|-------------------|
538| Class III and implantable | Before placing on the market |
539| Class IIb | Before placing on the market |
540| Class IIa | Before placing on the market |
541| Class I | Before placing on the market |
542
543> **Note:** All timelines are contingent on Eudamed being declared fully functional. Until then, manufacturers should pre-register in Eudamed (available modules) and maintain data readiness.
544
545---
546
547## Cross-Reference: NIS2 for Critical Infrastructure (Healthcare)
548
549Healthcare organizations manufacturing or deploying medical devices may be classified as essential entities under NIS2:
550
551| NIS2 Requirement | MDR Impact | Action for Manufacturers |
552|-----------------|-----------|--------------------------|
553| Art. 21: Cybersecurity risk management | MDCG 2019-16 cybersecurity guidance | Align device cybersecurity with organizational NIS2 compliance |
554| Art. 23: Incident reporting (24h/72h) | Art. 87-92 vigilance reporting | Unified incident reporting covering both device and infrastructure incidents |
555| Art. 21(2)(d): Supply chain security | Art. 11 authorized representatives, supply chain | Assess cybersecurity of device component suppliers |
556| Art. 20: Governance and accountability | Art. 10 manufacturer obligations | Senior management oversight of both NIS2 and MDR compliance |
557
558> **See also:** `../information-security-manager-iso27001/SKILL.md` for ISO 27001 alignment with NIS2 requirements.
559
560---
561
562## MDR Updates & Cross-Framework Integration
563
564### Latest MDCG Guidance Documents
565
566- **MDCG 2019-11 Rev.1:** Qualification and classification of software — updated algorithm for SaMD
567- **MDCG 2020-1 Rev.1:** Clinical evaluation (Annex XIV) — updated methodologies
568- **MDCG 2024-8:** EU AI Act interaction with MDR for AI-enabled medical devices
569- **MDCG 2023-4:** Legacy devices and Article 120 transition provisions
570
571### AI/ML Medical Devices Under MDR
572
573- **Classification:** AI/ML-based SaMD typically Class IIa or higher (Rule 11)
574- **Clinical Evidence:** Must demonstrate AI algorithm clinical performance (sensitivity, specificity, AUC)
575- **Continuous Learning:** PCCP-equivalent under MDR for adaptive AI devices
576- **Post-Market:** Enhanced PMCF for AI devices monitoring real-world algorithm performance
577- **EU AI Act Interaction:** High-risk AI medical devices subject to BOTH MDR and EU AI Act
578- **Cross-reference:** See `eu-ai-act-specialist` for AI Act obligations
579
580### NIS2 Impact on Healthcare
581
582- Healthcare entities are "Essential Entities" under NIS2 Directive
583- Medical device manufacturers may be "Important Entities"
584- NIS2 cybersecurity requirements supplement MDR cybersecurity expectations
585- **Cross-reference:** See `nis2-directive-specialist` for NIS2 compliance
586
587### EUDAMED Implementation Status
588
589- **Actor Registration Module:** Operational — all economic operators must register
590- **UDI/Device Registration Module:** Operational — mandatory device registration
591- **Notified Body Module:** Operational — certificate information
592- **Clinical Investigation Module:** Available
593- **Vigilance Module:** Under development
594- **Market Surveillance Module:** Under development
595
596### UDI Detailed Requirements
597
598- **UDI-DI (Device Identifier):** Unique to device model — used for EUDAMED registration
599- **UDI-PI (Production Identifier):** Identifies production unit — lot, serial, expiry, manufacturing date
600- **Issuing Entities:** GS1, HIBCC, ICCBBA, IFA
601- **Carrier Types:** AIDC (barcode/2D) + HRI (human readable)
602- **Implant Card:** Required for Class III implantable devices (UDI + patient information)
603
604---
605
606## Troubleshooting
607
608| Problem | Possible Cause | Resolution |
609|---------|---------------|------------|
610| Device classification unclear -- rules yield different results | Multiple classification rules apply; highest class must be selected per MDR Article 51(7) | Apply all applicable rules from Annex VIII (Rules 1-22); use the implementing rule that gives the highest classification; for software, apply MDCG 2019-11 Rev.1 algorithm; document rationale for each rule considered |
611| Notified Body rejects technical file for incompleteness | GSPR compliance matrix gaps, missing clinical evaluation, or insufficient risk management documentation | Review GSPR checklist in this skill; ensure Annex II technical file structure is complete; verify CER meets Annex XIV requirements; confirm ISO 14971 risk management file is current and comprehensive |
612| EUDAMED registration delays blocking market access | Module not operational or manufacturer SRN not obtained | Check current EUDAMED module status; obtain SRN via actor registration module (operational); use national systems for vigilance reporting until Eudamed Vigilance module is fully functional |
613| Clinical evidence insufficient for Class IIb/III device | Equivalence route rejected by NB or clinical investigation not planned | Reassess equivalence per MDCG 2020-1 Rev.1 (technical, biological, clinical equivalence with access to data); if equivalence fails, plan clinical investigation per Article 61; consider MDCG 2024-6 for reduced evidence burden on well-established devices |
614| MDR transition deadline approaching with NB application pending | Limited NB capacity (approximately 40 designated EU-wide as of 2025) | Verify transition deadline for your device class (Class III: May 2026, Class IIb: Dec 2027, Class IIa: Dec 2028); ensure QMS application was submitted to NB by applicable deadline; maintain MDD/AIMDD compliance during transition |
615| UDI labeling rejected by NB or competent authority | UDI-DI/UDI-PI format incorrect, AIDC carrier unreadable, or missing elements | Verify all required UDI elements per Article 27; ensure AIDC format (GS1 DataMatrix preferred) is scannable; include HRI adjacent to barcode; for reusable devices, apply direct marking that survives reprocessing |
616| AI/ML medical device faces dual regulatory obligations | Device classified under both MDR and EU AI Act as high-risk | Assess both MDR Annex VIII classification and EU AI Act Annex III categorization; MDR conformity assessment may satisfy AI Act per Art. 120; extend technical documentation with AI-specific elements per MDCG 2024-8 |
617
618---
619
620## Success Criteria
621
622- **Device correctly classified with documented rationale** -- classification per Annex VIII with all applicable rules evaluated, highest class selected, and rationale documented for NB review
623- **Complete technical file per Annex II structure** -- device description, labeling/IFU, design and manufacturing info, GSPR compliance matrix, benefit-risk analysis, verification and validation, and clinical evaluation report all present and current
624- **GSPR compliance matrix fully addressed** -- all applicable General Safety and Performance Requirements mapped to evidence with cross-references to risk management file, biocompatibility reports, sterilization validation, software documentation, and labeling
625- **Clinical evaluation report meets Annex XIV requirements** -- literature search methodology documented, data appraised and analyzed, safety and performance conclusions stated, benefit-risk determined, and PMCF plan included
626- **PMS system operational** -- PMS plan per Article 84, complaint handling procedures, vigilance reporting process, PSUR schedule defined by class, and PMCF activities integrated with CER
627- **UDI system fully implemented** -- UDI-DI assigned per device variant, UDI-PI applied (lot/serial/dates), AIDC and HRI carriers on all packaging levels, EUDAMED registration complete (when applicable)
628- **MDR gap analysis shows zero critical gaps** -- as measured by `mdr_gap_analyzer.py`, with all requirements addressed or in-progress with documented timeline
629
630---
631
632## Scope & Limitations
633
634**In Scope:**
635- Device classification per MDR Annex VIII (Rules 1-22) including software classification per MDCG 2019-11 Rev.1
636- Technical documentation structure and requirements per Annex II and Annex III
637- GSPR compliance matrix with evidence mapping
638- Clinical evidence strategy including equivalence assessment, CER structure, and PMCF planning
639- Post-market surveillance system design including PMS plan, PSUR schedule, and vigilance reporting timelines
640- EUDAMED and UDI system implementation guidance
641- Conformity assessment route selection by device class
642- MDR transition timeline tracking (post-Amendment Regulation 2023/607)
643- AI/ML medical device considerations including EU AI Act interaction
644
645**Out of Scope:**
646- Clinical investigation protocol design, execution, or statistical analysis
647- Biocompatibility testing per ISO 10993 (beyond evidence mapping in GSPR)
648- Sterilization validation per ISO 11135/11137 (beyond evidence mapping)
649- Notified Body selection, engagement, or commercial negotiation
650- Quality Management System implementation -- use `quality-manager-qms-iso13485` for ISO 13485 QMS
651- Risk management process implementation -- use `risk-management-specialist` for ISO 14971
652
653**Important Notes:**
654- EUDAMED's first four modules became mandatory from May 28, 2026; manufacturers must have SRN and device registrations ready
655- Only approximately 40 Notified Bodies are designated EU-wide as of 2025, creating capacity constraints; early NB engagement is critical
656- The European Commission published updated transition timelines in December 2025 extending deadlines for certain device categories
657- Manufacturers must adopt recently harmonized standards with no formal transition period (Decision EU 2025/2078)
658
659---
660
661## Integration Points
662
663| Skill | Integration | When to Use |
664|-------|-------------|-------------|
665| `fda-consultant-specialist` | Cross-framework mapping for dual US/EU market; FDA QMSR aligns with ISO 13485 used by MDR | When device requires both FDA clearance/approval and EU MDR CE marking |
666| `quality-manager-qms-iso13485` | ISO 13485 QMS is prerequisite for MDR conformity assessment (Annex IX, XI) | When establishing or auditing QMS for MDR compliance |
667| `risk-management-specialist` | ISO 14971 risk management file is core component of MDR technical documentation | When developing risk management file, FMEA, and benefit-risk analysis |
668| `eu-ai-act-specialist` | AI medical devices subject to both MDR and EU AI Act; classification and conformity assessment interaction | When AI-enabled medical device requires dual regulatory compliance |
669| `capa-officer` | CAPA process supports MDR vigilance obligations and FSCA implementation | When post-market surveillance identifies safety or performance issues requiring corrective action |
670| `infrastructure-compliance-auditor` | Cybersecurity validation per MDCG 2019-16 Rev.1 for connected medical devices | When connected device requires cybersecurity documentation for technical file |
671
672---
673
674## Tool Reference
675
676### mdr_gap_analyzer.py
677
678Analyzes device against MDR requirements, identifies compliance gaps, and generates prioritized recommendations.
679
680| Flag | Required | Description |
681|------|----------|-------------|
682| `--device <name>` | Yes (unless `--interactive`) | Device name for gap analysis |
683| `--class <class>` | Yes (unless `--interactive`) | Device classification: `I`, `Is`, `Im`, `IIa`, `IIb`, `III` |
684| `--output <format>` | No | Output format: `json` for machine-readable output; default is human-readable text |
685| `--interactive` | No | Launch interactive assessment mode with guided questions |
686
687**Analysis Categories:** Technical documentation (Annex II), GSPR compliance, clinical evidence (Annex XIV), post-market surveillance (Chapter VII), UDI/EUDAMED, labeling (Article 13), quality management system, risk management, and conformity assessment route.
688
689**Output:** Requirements checklist with per-item status (Not Started/In Progress/Complete/N/A), gap identification with priority (Critical/High/Medium/Low), critical gap highlighting, completion percentage, and compliance roadmap recommendations.