EU MDR 2017/745 compliance specialist for medical device classification, technical documentation, clinical evidence, and post-market surveillance. Covers Annex VIII classification rules, Annex II/III technical files, Annex XIV clinical evaluation, and EUDAMED integration.
Instrucciones de origen · Vista previa de solo lectura
name
mdr-745-specialist
title
MDR 2017/745 Specialist
description
EU MDR 2017/745 compliance specialist for medical device classification, technical documentation, clinical evidence, and post-market surveillance. Covers Annex VIII classification rules, Annex II/III technical files, Annex XIV clinical evaluation, and EUDAMED integration.
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
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:
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)
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
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
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
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
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
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.
