MDR 745 Expert

A specialized skill for EU Medical Device Regulation 2017/745 (MDR) compliance — covering device classification, technical documentation, clinical evaluation, post-market surveillance, EUDAMED registration, and Notified Body submission preparation.

When to Use This Skill

Choose MDR 745 Expert when you need to:

• Classify a medical device under MDR Annex VIII rules
• Prepare technical documentation per MDR Annex II/III
• Conduct or update clinical evaluations per MDR Article 61
• Design post-market surveillance systems per MDR Article 83-86
• Prepare for Notified Body conformity assessment
• Understand MDR transition timelines and requirements

Consider alternatives when:

• You need FDA regulatory guidance (use an FDA skill)
• You need in-vitro diagnostic (IVD) regulation (use IVDR skill)
• You need quality system setup (use ISO 13485 skill)

Quick Start

Copy
# Classify a device and determine MDR pathway
claude "Classify a software application that analyzes MRI brain scans to detect tumors using AI. Determine the MDR classification, conformity assessment route, and key documentation requirements."

Copy
# MDR Classification: AI MRI Analysis Software

## Device Classification
- **Type**: Software as Medical Device (SaMD)
- **Intended Purpose**: Aid diagnosis of brain tumors
  from MRI scans using artificial intelligence
- **MDR Classification**: Class IIb
  - Rule 11 (software intended to provide diagnostic
    information): "serious" condition → Class IIb
- **Risk Class Justification**: Tumor detection directly
  influences clinical diagnosis of a serious condition

## Conformity Assessment Route
- **Annex IX** (QMS) + **Annex X** (Type Examination)
  OR
- **Annex IX** (QMS) with technical documentation
  assessment for each device

## Required Technical Documentation (Annex II)

### 1. Device Description
- Software architecture (AI model, data flow)
- Intended purpose and indications
- Contraindications and limitations

### 2. Design and Manufacturing Information
- Software development lifecycle (IEC 62304)
- AI/ML model training methodology
- Verification and validation protocols

### 3. Clinical Evaluation (Article 61)
- Clinical investigation or equivalence justification
- Performance data for AI algorithm
- Clinical evidence summary

### 4. Risk Management (ISO 14971)
- Risk analysis for AI-specific failure modes
- Residual risk assessment
- Benefit-risk determination

Core Concepts

MDR Classification Rules (Annex VIII)

Rule	Applies To	Class Outcome
Rule 1	Non-invasive devices	I
Rule 5	Invasive (body orifice, short-term)	IIa
Rule 8	Implantable devices	IIb or III
Rule 11	Software with diagnostic/therapeutic purpose	I, IIa, IIb, or III
Rule 14	Devices with biological substances	III
Rule 22	Devices with nanomaterials	III (up-classified)

Technical Documentation Structure (Annex II)

Copy
## Annex II Technical Documentation Sections

### Section 1: Device Description and Specification
- General description, intended purpose
- Variants and accessories
- Reference to previous/similar generations

### Section 2: Information Supplied by Manufacturer
- Label text and symbols (ISO 15223-1)
- Instructions for use (IFU)
- Marketing materials (if any)

### Section 3: Design and Manufacturing
- Design stages with verification at each stage
- Manufacturing process description
- Suppliers and subcontractors
- IEC 62304 software lifecycle (if applicable)

### Section 4: General Safety and Performance
- Compliance with GSPR (Annex I)
- Applied harmonised standards
- Common specifications (if applicable)
- Solutions chosen for each GSPR

### Section 5: Benefit-Risk Analysis (ISO 14971)
- Known and foreseeable hazards
- Estimation and evaluation of risks
- Risk control measures
- Overall residual risk acceptability

### Section 6: Product Verification and Validation
- Pre-clinical testing results
- Software verification/validation
- Biocompatibility (ISO 10993 if applicable)
- EMC/electrical safety (IEC 60601 if applicable)

Post-Market Surveillance (PMS) System

Copy
## PMS Requirements Under MDR

### PMS Plan (Article 84)
- Systematic process to collect and analyze data
- Methods for collecting: complaints, FSCA, literature
- Indicators and thresholds for trend analysis
- Communication procedures for safety issues

### Periodic Safety Update Report (PSUR)
- Class IIa: every 2 years
- Class IIb/III: annually
- Submitted to Notified Body

### Post-Market Clinical Follow-up (PMCF)
- Plan: methods for clinical data collection
- Evaluation: ongoing clinical performance analysis
- Report: updated findings integrated into CER

### Vigilance (Articles 87-92)
- Serious incident reporting to authority: 15 days
  (2 days for imminent risk, 10 for death)
- Field Safety Corrective Actions (FSCA)
- Trend reporting when frequency/severity increases

Configuration

Parameter	Description	Example
device_type	Type of medical device	"SaMD" / "implant"
classification	MDR classification	"IIb"
intended_purpose	Device intended purpose	"diagnostic imaging"
has_software	Device contains software component	true
conformity_route	Annex for conformity assessment	"IX" / "IX+X"
output_format	Documentation format	"markdown" / "docx"

Best Practices

1. Classify early and get Notified Body alignment — Device classification under MDR determines everything downstream: conformity assessment route, documentation depth, clinical evidence requirements, and PMS obligations. Engage your Notified Body early for classification agreement before investing in documentation.

2. Build your General Safety and Performance Requirements checklist first — GSPR compliance (Annex I) is the backbone of MDR technical documentation. Create a requirements traceability matrix mapping each applicable GSPR to your evidence before writing detailed documentation.

3. Treat clinical evaluation as a living document — The Clinical Evaluation Report (CER) is not a one-time exercise. MDR requires ongoing PMCF to feed updated clinical data back into the CER. Set up literature search protocols that run at least annually and update the CER with new evidence.

4. Document your AI/ML model lifecycle comprehensively — For SaMD with AI, document training data provenance, model architecture decisions, performance metrics across demographic subgroups, and your approach to algorithmic bias. Notified Bodies increasingly scrutinize AI-specific documentation.

5. Plan for EUDAMED registration and UDI requirements — MDR requires Unique Device Identification (UDI) and EUDAMED database registration. Start UDI planning during design phase, not as an afterthought before market placement. UDI-DI and UDI-PI requirements affect labeling and packaging design.

Common Issues

Equivalence claims for clinical evaluation are rejected — MDR has stricter equivalence requirements than the previous MDD. Demonstrating clinical, technical, and biological equivalence requires documented access to the equivalent device's technical documentation, which competitors rarely provide. Plan for your own clinical investigation if equivalence is questionable.

Legacy devices miss MDR transition deadlines — Devices legally placed on the market under MDD/AIMDD certificates must transition to MDR certification. The extended timelines still require a QMS audit, PMS system, and PSUR submission. Starting transition late risks market discontinuity.

Post-market surveillance is treated as a checkbox exercise — MDR PMS requirements are significantly more detailed than MDD requirements. A generic PMS plan that doesn't specify data sources, analysis methods, thresholds for action, and reporting timelines will be flagged by Notified Bodies. Each device must have a device-specific PMS plan.