---
name: mdr-745-specialist
description: >
  EU MDR 2017/745 compliance specialist for medical device classification,
  technical documentation, clinical evidence, and post-market surveillance. Use for
  Annex VIII classification, GSPR, clinical evaluation, EUDAMED, and UDI.
license: MIT + Commons Clause
metadata:
  version: 1.0.0
  author: borghei
  category: compliance
  domain: medical-device-regulation
  updated: 2026-03-31
  tags: [eu-mdr, medical-device, gspr, eudamed, udi]
---
# MDR 2017/745 Specialist

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

---

## Table of Contents

- [Device Classification Workflow](#device-classification-workflow)
- [Technical Documentation](#technical-documentation)
- [Clinical Evidence](#clinical-evidence)
- [Post-Market Surveillance](#post-market-surveillance)
- [EUDAMED and UDI](#eudamed-and-udi)
- [Reference Documentation](#reference-documentation)
- [Tools](#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

| 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:

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

| 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:

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

| 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:

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

| 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:

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

| 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:

- [ ] 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

```bash
# 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

- [ ] 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

| 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 |
|-------------|--------|------------