Claude-Skills mdr-745-specialist

install
source · Clone the upstream repo
git clone https://github.com/borghei/Claude-Skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/borghei/Claude-Skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/ra-qm-team/mdr-745-specialist" ~/.claude/skills/borghei-claude-skills-mdr-745-specialist && rm -rf "$T"
manifest: ra-qm-team/mdr-745-specialist/SKILL.md
source content

MDR 2017/745 Specialist

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


Table of Contents


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

FactorClass IClass IIaClass IIbClass III
DurationAnyShort-termLong-termLong-term
InvasivenessNon-invasiveBody orificeSurgicalImplantable
SystemAnyNon-criticalCritical organsCNS/cardiac
RiskLowestLow-mediumMedium-highHighest

Software Classification (MDCG 2019-11)

Information UseCondition SeverityClass
Informs decisionNon-seriousIIa
Informs decisionSeriousIIb
Drives/treatsCriticalIII

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

RequirementEvidenceStatus
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

ClassRouteNB Involvement
IAnnex II self-declarationNone
Is/ImAnnex II + IX/XISterile/measuring aspects
IIaAnnex II + IX or XIProduct or QMS
IIbAnnex IX + X or X + XIType exam + production
IIIAnnex IX + XFull 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

ClassMinimum EvidenceInvestigation
IRisk-benefit analysisNot typically required
IIaLiterature + post-marketMay be required
IIbSystematic literature reviewOften required
IIIComprehensive clinical dataRequired (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

ComponentRequirementFrequency
PMS PlanArticle 84Maintain current
PSURClass IIa and higherPer class schedule
PMCF PlanAnnex XIV Part BUpdate with CER
PMCF ReportAnnex XIV Part BAnnual (Class III)
VigilanceArticles 87-92As events occur

PSUR Schedule

ClassFrequency
Class IIIAnnual
Class IIb implantableAnnual
Class IIbEvery 2 years
Class IIaWhen necessary

Serious Incident Reporting

TimelineRequirement
2 daysSerious public health threat
10 daysDeath or serious deterioration
15 daysOther 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

ModuleContentActor
ActorCompany registrationManufacturer, AR
UDI/DeviceDevice and variant dataManufacturer
CertificatesNB certificatesNotified Body
Clinical InvestigationStudy registrationSponsor
VigilanceIncident reportsManufacturer
Market SurveillanceAuthority actionsCompetent 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

# 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

FactorConsiderations
Designation scopeCovers your device type
CapacityTimeline for initial audit
Geographic reachMarkets you need to access
Technical expertiseExperience with your technology
Fee structureTransparency, 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

DocumentTitleStatusKey Impact
MDCG 2024-1Transition provisions under MDR Art. 120Final (2024)Extended transition deadlines for legacy devices
MDCG 2024-6Clinical evidence needed for medical devices previously CE marked under DirectivesFinal (2024)Reduced clinical evidence burden for well-established devices
MDCG 2023-4 Rev.1Notified Body capacity and availabilityRevised (2024)NB capacity monitoring and optimization
MDCG 2022-18 Rev.1Software qualification and classification under MDRRevised (2024)Updated software classification algorithm
MDCG 2020-1 Rev.1Clinical evaluation — equivalenceRevised (2024)Refined equivalence demonstration requirements
MDCG 2019-16 Rev.1Cybersecurity for medical devicesRevised (2024)Enhanced cybersecurity requirements for connected devices
MDCG 2019-11 Rev.1Qualification and classification of softwareActiveSoftware as medical device classification

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

Device CategoryTransition DeadlineConditions
Class III and implantable26 May 2026Valid MDD/AIMDD certificate + QMS application to NB by 26 May 2024
Class IIb31 December 2027Valid certificate + QMS application to NB
Class IIa and Class I (sterile/measuring)31 December 2028Valid certificate + QMS application to NB
Class I (up-classified under MDR)31 December 2028Previously 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 FactorClass IIaClass IIbClass III
Provides information to inform clinical managementNon-serious conditionsSerious conditionsN/A
Drives clinical management or diagnosesN/ANon-serious conditionsSerious or critical conditions
Monitors physiological processesNon-vital parametersVital parameters (not immediate danger)Vital parameters (immediate danger)

Software Lifecycle Requirements Under MDR

MDR RequirementIEC 62304 MappingDocumentation
GSPR 17.1 (repeatability, reliability)Software development processSoftware development plan
GSPR 17.2 (state of the art)Software architectureArchitecture design document
GSPR 17.3 (minimum IT requirements)System requirementsIT environment specification
GSPR 17.4 (foreseeable misuse)Risk managementSoftware risk analysis
Annex II §6.5 (software verification)Software testingTest plans and reports
Annex I §23.4 (labeling for software)Release documentationSoftware release notes

AI/ML Medical Devices Under MDR

AI/ML Classification Considerations

AI/ML CapabilityMDR Classification ImpactRegulatory Consideration
AI-assisted detectionTypically Class IIa-IIb (Rule 11)Must demonstrate clinical performance per intended use
AI-driven diagnosisTypically Class IIb-III (Rule 11)Requires clinical investigation for novel indications
AI treatment optimizationTypically Class IIb-III (Rule 11 + specific rules)Benefit-risk analysis must account for AI uncertainty
Continuously learning AIClassification per highest risk outputPost-market monitoring must track algorithm evolution

AI/ML-Specific Technical Documentation

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

SectionContentMDCG Reference
Algorithm descriptionArchitecture, training approach, feature engineeringMDCG 2019-11, IMDRF SaMD WG
Training dataSources, demographics, size, labeling methodology, qualityMDCG 2020-1 (equivalence)
Validation methodologyTest dataset independence, performance metrics, subgroup analysisAnnex XIV
Clinical performanceSensitivity, specificity, AUC, PPV, NPV per intended populationCER requirements
Change managementHow algorithm updates are validated and deployedGSPR 17
ExplainabilityHow the AI's output can be understood by intended usersGSPR 23 (labeling)

EU AI Act Interaction with MDR

EU AI Act RequirementMDR EquivalentCombined Approach
High-risk classification (Annex III, Point 10)Annex VIII classification rulesBoth classifications apply; meet stricter requirement
Conformity assessment (Art. 43)Annex IX/X/XI assessmentMDR conformity assessment satisfies AI Act (Art. 120)
Technical documentation (Annex IV)Annex II technical documentationExtend MDR technical file with AI Act-specific elements
Risk management (Art. 9)ISO 14971 + GSPRISO 14971 satisfies both when AI risks are included
Data governance (Art. 10)GSPR 17 + Annex XIVAdd AI-specific data governance to clinical evaluation
Post-market monitoring (Art. 72)Chapter VII PMSSingle 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)

ModuleStatusMandatory DateContent
Actor RegistrationOperationalAvailable nowEconomic operator registration
UDI/Device RegistrationOperational6 months after Eudamed fully functionalDevice and UDI-DI data
Notified Body and CertificatesOperationalAvailable nowCertificate data upload by NBs
Clinical InvestigationsOperationalAvailable nowStudy registration and reporting
VigilancePartially operational24 months after fully functionalIncident reports, FSCAs, trend reports
Market SurveillanceIn development18 months after fully functionalCA 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 ElementRequired ForUpdate Frequency
SRN (Single Registration Number)All manufacturersOn change
Authorized representative detailsNon-EU manufacturersOn change
Device identification (UDI-DI)All devices placed on marketBefore first placing on market
Basic UDI-DIDevice model/family groupingBefore first placing on market
GMDN codeDevice nomenclatureOn initial registration
Risk classClassification per Annex VIIIOn initial registration
NB certificate referenceClass IIa and aboveWhen certificate issued
Clinical investigation registrationInterventional studiesBefore study start

UDI-DI and UDI-PI Detailed Requirements

UDI-DI (Device Identifier) — Static Information

ElementDescriptionExample
Device identifierUnique code for device model/version04069876543219 (GS1 GTIN)
Issuing entityGS1, HIBCC, ICCBBA, or IFASelected by manufacturer
Device modelSpecific device configuration"CardioMonitor X200"
Device versionSoftware version (for SaMD)"v3.1.0"
Applicable regulationsMDR or IVDR referenceMDR 2017/745
Risk classPer Annex VIIIClass IIa
Basic UDI-DIGrouping identifier for device family04069876500001

UDI-PI (Production Identifier) — Variable Information

PI ElementWhen RequiredFormat
Lot/batch numberWhen tracking by lotLot: ABC123
Serial numberWhen individual tracking required (Class III, implantable)SN: 2024-00001
Manufacturing dateWhen relevant to safetyMfg: 2024-06-15
Expiry dateWhen device has shelf lifeExp: 2026-06-15
Software versionSaMD and software-driven devicesSW: v3.1.0

UDI Carrier Requirements

Carrier TypeFormatWhere Applied
AIDC (barcode/2D code)GS1 DataMatrix, GS1-128, HIBCDevice label, package label
HRI (human-readable)Plain text interpretation of AIDCAdjacent to AIDC on label
RFIDGS1 EPC/RFIDOptional, 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 ClassSubmission Deadline
Class III and implantableBefore placing on the market
Class IIbBefore placing on the market
Class IIaBefore placing on the market
Class IBefore 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 RequirementMDR ImpactAction for Manufacturers
Art. 21: Cybersecurity risk managementMDCG 2019-16 cybersecurity guidanceAlign device cybersecurity with organizational NIS2 compliance
Art. 23: Incident reporting (24h/72h)Art. 87-92 vigilance reportingUnified incident reporting covering both device and infrastructure incidents
Art. 21(2)(d): Supply chain securityArt. 11 authorized representatives, supply chainAssess cybersecurity of device component suppliers
Art. 20: Governance and accountabilityArt. 10 manufacturer obligationsSenior 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

ProblemPossible CauseResolution
Device classification unclear -- rules yield different resultsMultiple 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 incompletenessGSPR compliance matrix gaps, missing clinical evaluation, or insufficient risk management documentationReview 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 accessModule not operational or manufacturer SRN not obtainedCheck 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 deviceEquivalence route rejected by NB or clinical investigation not plannedReassess 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 pendingLimited 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 authorityUDI-DI/UDI-PI format incorrect, AIDC carrier unreadable, or missing elementsVerify 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 obligationsDevice classified under both MDR and EU AI Act as high-riskAssess 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

SkillIntegrationWhen to Use
fda-consultant-specialist
Cross-framework mapping for dual US/EU market; FDA QMSR aligns with ISO 13485 used by MDRWhen 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 documentationWhen 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 interactionWhen AI-enabled medical device requires dual regulatory compliance
capa-officer
CAPA process supports MDR vigilance obligations and FSCA implementationWhen 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 devicesWhen 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.

FlagRequiredDescription
--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>
NoOutput format:
json
for machine-readable output; default is human-readable text
--interactive
NoLaunch 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.