Mdr 745 Specialist

MDR 2017/745 Specialist

EU MDR compliance patterns for medical device classification, technical documentation, and clinical evidence.

Table of Contents

• Device Classification Workflow
• Technical Documentation
• Clinical Evidence
• Post-Market Surveillance
• EUDAMED and UDI
• Reference Documentation
• Tools

Clarify First

Before classifying the device or analyzing gaps, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Device characteristics — duration, invasiveness, body-system contact, and whether it is active/software (drives the Annex VIII classification)
• Intended purpose — the device's claimed clinical purpose (sets the applicable rule and clinical-evidence level)
• Software/AI nature — whether it is software as a medical device (MDCG 2019-11) or AI/ML (changes classification and the documentation set)

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:

1. Identify device duration (transient, short-term, long-term)
2. Determine invasiveness level (non-invasive, body orifice, surgical)
3. Assess body system contact (CNS, cardiac, other)
4. Check if active device (energy dependent)
5. Apply classification rules 1-22
6. For software, apply MDCG 2019-11 algorithm
7. Document classification rationale
8. Validation: Classification confirmed with Notified Body

Classification Matrix

Software Classification (MDCG 2019-11)

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:

1. Create device description (variants, accessories, intended purpose)
2. Develop labeling (Article 13 requirements, IFU)
3. Document design and manufacturing process
4. Complete GSPR compliance matrix
5. Prepare benefit-risk analysis
6. Compile verification and validation evidence
7. Integrate risk management file (ISO 14971)
8. 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

Conformity Assessment Routes

Clinical Evidence

Develop clinical evidence strategy per Annex XIV:

1. Define clinical claims and endpoints
2. Conduct systematic literature search
3. Appraise clinical data quality
4. Assess equivalence (technical, biological, clinical)
5. Identify evidence gaps
6. Determine if clinical investigation required
7. Prepare Clinical Evaluation Report (CER)
8. Validation: CER reviewed by qualified evaluator

Evidence Requirements by Class

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:

1. Develop PMS plan (Article 84)
2. Define data collection methods
3. Establish complaint handling procedures
4. Create vigilance reporting process
5. Plan Periodic Safety Update Reports (PSUR)
6. Integrate with PMCF activities
7. Define trend analysis and signal detection
8. Validation: PMS system audited annually

PMS System Components

PSUR Schedule

Serious Incident Reporting

EUDAMED and UDI

Implement UDI system per Article 27:

1. Obtain issuing entity code (GS1, HIBCC, ICCBBA)
2. Assign UDI-DI to each device variant
3. Assign UDI-PI (production identifier)
4. Apply UDI carrier to labels (AIDC + HRI)
5. Register actor in EUDAMED
6. Register devices in EUDAMED
7. Upload certificates when available
8. Validation: UDI verified on sample labels

EUDAMED Modules

UDI Label Requirements

Required elements per Article 13:

• UDI-DI (device identifier)
• UDI-PI (production identifier) for Class II+
• AIDC format (barcode/RFID)
• HRI format (human-readable)
• Manufacturer name and address
• Lot/serial number
• Expiration date (if applicable)

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

Pre-Submission Checklist

• Technical documentation complete
• GSPR matrix fully addressed
• Risk management file current
• Clinical evaluation report complete
• QMS (ISO 13485) certified
• Labeling and IFU finalized
• Validation: Internal gap assessment complete

MDCG Guidance Documents Update (2024-2025)

Key MDCG Guidance Documents

MDR Transition Timeline (Post-Amendment Regulation 2023/607)

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

Software Lifecycle Requirements Under MDR

AI/ML Medical Devices Under MDR

AI/ML Classification Considerations

AI/ML-Specific Technical Documentation

In addition to standard Annex II requirements, AI/ML devices must document:

EU AI Act Interaction with 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)

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

UDI-DI and UDI-PI Detailed Requirements

UDI-DI (Device Identifier) — Static Information

UDI-PI (Production Identifier) — Variable Information

UDI Carrier Requirements

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)