
Regulatory Affairs Head
- 789 installs
- 23.5k repo stars
- Updated July 17, 2026
- alirezarezvani/claude-skills
regulatory-affairs-head is a Claude skill that structures EU MDR 2017/745 device classification, conformity assessment routes, and Annex II technical documentation for medical device software or hardware products seeking
About
regulatory-affairs-head is a Claude skill providing an EU MDR 2017/745 submission guide for medical device software and hardware products. It covers MDR classification across Class I self-certification under Annex II, Class IIa notified-body routes under Annex III Module C2 plus Annex V, and Class IIb certification under Annex III Module B plus C or D with type or full quality assurance examination. The skill addresses technical documentation per Annex II, Declaration of Conformity, UDI registration, quality management system assessment, and ongoing surveillance requirements. Developers and regulatory engineers reach for regulatory-affairs-head when structuring SaMD or hardware technical files, selecting conformity paths, or preparing notified-body submissions under EU MDR 2017/745.
- Maps EU MDR Class I through Class III devices to self-certification vs notified-body assessment routes
- Lists Annex II technical documentation elements including risk management and clinical evidence hooks
- Ties quality management expectations to ISO 13485 and integrated design and surveillance controls
- Summarizes clinical evaluation plan requirements under Annex XIV for evidence planning
- Separates conformity pathways by annex modules (e.g., II, III, V) for class-appropriate depth
Regulatory Affairs Head by the numbers
- 789 all-time installs (skills.sh)
- +5 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #428 of 2,203 Security skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Jul 31, 2026 (Skillselion catalog sync)
npx skills add https://github.com/alirezarezvani/claude-skills --skill regulatory-affairs-headAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 789 |
|---|---|
| repo stars | ★ 23.5k |
| Security audit | 2 / 3 scanners passed |
| Last updated | July 17, 2026 |
| Repository | alirezarezvani/claude-skills ↗ |
How do you structure EU MDR Annex II technical files?
Structure EU MDR 2017/745 classification, conformity routes, and Annex II technical documentation for a medical device software or hardware product.
Who is it for?
Developers and regulatory engineers preparing EU MDR 2017/745 submissions for medical device software or hardware requiring CE marking documentation.
Skip if: Non-medical software products, US FDA-only pathways, or teams without regulatory obligation to EU MDR 2017/745 conformity.
When should I use this skill?
A medical device software or hardware product needs EU MDR 2017/745 classification, conformity route selection, or Annex II technical documentation structuring.
What you get
MDR device classification, conformity assessment route selection, Annex II technical documentation outlines, and Declaration of Conformity checklists.
- MDR classification rationale
- Annex II technical documentation outline
- Conformity assessment route plan
By the numbers
- Covers 3 MDR device classes: Class I, Class IIa, and Class IIb conformity routes
- References Annex II technical documentation and Annex III conformity modules
Files
Head of Regulatory Affairs
Regulatory strategy development, submission management, and global market access for medical device organizations.
---
Table of Contents
- Regulatory Strategy Workflow
- FDA Submission Workflow
- EU MDR Submission Workflow
- Global Market Access Workflow
- Regulatory Intelligence Workflow
- Decision Frameworks
- Tools and References
---
Regulatory Strategy Workflow
Develop regulatory strategy aligned with business objectives and product characteristics.
Workflow: New Product Regulatory Strategy
1. Gather product information:
- Intended use and indications
- Device classification (risk level)
- Technology platform
- Target markets and timeline
2. Identify applicable regulations per target market:
- FDA (US): 21 CFR Part 820, 510(k)/PMA/De Novo
- EU: MDR 2017/745, Notified Body requirements
- Other markets: Health Canada, PMDA, NMPA, TGA
3. Determine optimal regulatory pathway:
- Compare submission types (510(k) vs De Novo vs PMA)
- Assess predicate device availability
- Evaluate clinical evidence requirements
4. Develop regulatory timeline with milestones 5. Estimate resource requirements and budget 6. Identify regulatory risks and mitigation strategies 7. Obtain stakeholder alignment and approval 8. Validation: Strategy document approved; timeline accepted; resources allocated
Regulatory Pathway Selection Matrix
| Factor | 510(k) | De Novo | PMA |
|---|---|---|---|
| Predicate Available | Yes | No | N/A |
| Risk Level | Low-Moderate | Low-Moderate | High |
| Clinical Data | Usually not required | May be required | Required |
| Review Time | 90 days (MDUFA) | 150 days | 180 days |
| User Fee | ~$22K (2024) | ~$135K | ~$440K |
| Best For | Me-too devices | Novel low-risk | High-risk, novel |
Regulatory Strategy Document Template
REGULATORY STRATEGY
Product: [Name] Version: [X.X] Date: [Date]
1. PRODUCT OVERVIEW
Intended use: [One-sentence statement of intended patient population, body site, and clinical purpose]
Device classification: [Class I / II / III]
Technology: [Brief description, e.g., "AI-powered wound-imaging software, SaMD"]
2. TARGET MARKETS & TIMELINE
| Market | Pathway | Priority | Target Date |
|--------|----------------|----------|-------------|
| USA | 510(k) / PMA | 1 | Q1 20XX |
| EU | Class [X] MDR | 2 | Q2 20XX |
3. REGULATORY PATHWAY RATIONALE
FDA: [510(k) / De Novo / PMA] — Predicate: [K-number or "none"]
EU: Class [X] via [Annex IX / X / XI] — NB: [Name or TBD]
Rationale: [2–3 sentences on key factors driving pathway choice]
4. CLINICAL EVIDENCE STRATEGY
Requirements: [Summarize what each market needs, e.g., "510(k): bench + usability; EU Class IIb: PMCF study"]
Approach: [Literature review / Prospective study / Combination]
5. RISKS AND MITIGATION
| Risk | Prob | Impact | Mitigation |
|------------------------------|------|--------|-----------------------------------|
| Predicate delisted by FDA | Low | High | Identify secondary predicate now |
| NB audit backlog | Med | Med | Engage NB 6 months before target |
6. RESOURCE REQUIREMENTS
Budget: $[Amount] Personnel: [FTEs] External: [Consultants / CRO]---
FDA Submission Workflow
Prepare and submit FDA regulatory applications.
Workflow: 510(k) Submission
1. Confirm 510(k) pathway suitability:
- Predicate device identified (note K-number, e.g., K213456)
- Substantial equivalence (SE) argument supportable on intended use and technological characteristics
- No new intended use or technology concerns triggering De Novo
2. Schedule and conduct Pre-Submission (Q-Sub) meeting if needed (see Pre-Sub Decision) 3. Compile submission package checklist:
- [ ] Cover letter with device name, product code, and predicate K-number
- [ ] Section 1: Administrative information (applicant, contact, 510(k) type)
- [ ] Section 2: Device description — include photos, dimensions, materials list
- [ ] Section 3: Intended use and indications for use
- [ ] Section 4: Substantial equivalence comparison table (see example below)
- [ ] Section 5: Performance testing — protocols, standards cited, pass/fail results
- [ ] Section 6: Biocompatibility summary (ISO 10993-1 risk assessment, if patient contact)
- [ ] Section 7: Software documentation (IEC 62304 level, cybersecurity per FDA guidance, if applicable)
- [ ] Section 8: Labeling — final draft IFU, device label
- [ ] Section 9: Summary and conclusion
4. Conduct internal review and quality check against FDA RTA checklist 5. Prepare eCopy per FDA format requirements (PDF bookmarked, eCopy cover page) 6. Submit via FDA ESG portal with user fee payment 7. Monitor MDUFA clock and respond to AI/RTA requests within deadlines 8. Validation: Submission accepted; MDUFA date received; tracking system updated
Substantial Equivalence Comparison Example
| Characteristic | Predicate (K213456) | Subject Device | Same? | Notes |
|---|---|---|---|---|
| Intended use | Wound measurement | Wound measurement | ✓ | Identical |
| Technology | 2D camera | 2D + AI analysis | ✗ | New TC; address below |
| Energy type | Non-energized | Non-energized | ✓ | |
| Patient contact | No | No | ✓ | |
| SE conclusion | New TC does not raise new safety/effectiveness questions; bench data demonstrates equivalent accuracy (±2mm vs ±3mm predicate) |
Workflow: PMA Submission
1. Confirm PMA pathway:
- Class III device or no suitable predicate
- Clinical data strategy defined
2. Complete IDE clinical study if required:
- IDE approval
- Clinical protocol execution
- Study report completion
3. Conduct Pre-Submission meeting 4. Compile PMA submission checklist:
- [ ] Volume I: Administrative, device description, manufacturing
- [ ] Volume II: Nonclinical studies (bench, animal, biocompatibility)
- [ ] Volume III: Clinical studies (IDE protocol, data, statistical analysis)
- [ ] Volume IV: Labeling
- [ ] Volume V: Manufacturing information, sterilization
5. Submit original PMA application 6. Address FDA questions and deficiencies 7. Prepare for FDA facility inspection 8. Validation: PMA approved; approval letter received; post-approval requirements documented
FDA Submission Timeline
| Milestone | 510(k) | De Novo | PMA |
|---|---|---|---|
| Pre-Sub Meeting | Day -90 | Day -90 | Day -120 |
| Submission | Day 0 | Day 0 | Day 0 |
| RTA Review | Day 15 | Day 15 | Day 45 |
| Substantive Review | Days 15–90 | Days 15–150 | Days 45–180 |
| Decision | Day 90 | Day 150 | Day 180 |
Common FDA Deficiencies and Prevention
| Category | Common Issues | Prevention |
|---|---|---|
| Substantial Equivalence | Weak predicate comparison; no performance data | Build SE table with data column; cite recognized standards |
| Performance Testing | Incomplete protocols; missing worst-case rationale | Follow FDA-recognized standards; document worst-case justification |
| Biocompatibility | Missing endpoints; no ISO 10993-1 risk assessment | Complete ISO 10993-1 matrix before testing |
| Software | Inadequate hazard analysis; no cybersecurity bill of materials | IEC 62304 compliance + FDA cybersecurity guidance checklist |
| Labeling | Inconsistent claims vs. IFU; missing symbols standard | Cross-check label against IFU; cite ISO 15223-1 for symbols |
See: references/fda-submission-guide.md
---
EU MDR Submission Workflow
Achieve CE marking under EU MDR 2017/745.
Workflow: MDR Technical Documentation
1. Confirm device classification per MDR Annex VIII 2. Select conformity assessment route based on class:
- Class I: Self-declaration
- Class IIa/IIb: Notified Body involvement
- Class III: Full NB assessment
3. Select and engage Notified Body (for Class IIa+) — see selection criteria below 4. Compile Technical Documentation per Annex II checklist:
- [ ] Annex II §1: Device description, intended purpose, UDI
- [ ] Annex II §2: Design and manufacturing information (drawings, BoM, process flows)
- [ ] Annex II §3: GSPR checklist — each requirement mapped to evidence (standard, test report, or justification)
- [ ] Annex II §4: Benefit-risk analysis and risk management file (ISO 14971)
- [ ] Annex II §5: Product verification and validation (test reports)
- [ ] Annex II §6: Post-market surveillance plan
- [ ] Annex XIV: Clinical evaluation report (CER) — literature, clinical data, equivalence justification
5. Establish and document QMS per ISO 13485 6. Submit application to Notified Body 7. Address NB questions and coordinate audit 8. Validation: CE certificate issued; Declaration of Conformity signed; EUDAMED registration complete
GSPR Checklist Row Example
| GSPR Ref | Requirement | Standard / Guidance | Evidence Document | Status |
|---|---|---|---|---|
| Annex I §1 | Safe design and manufacture | ISO 14971:2019 | Risk Management File v2.1 | Complete |
| Annex I §11.1 | Devices with measuring function ±accuracy | EN ISO 15223-1 | Performance Test Report PT-003 | Complete |
| Annex I §17 | Cybersecurity | MDCG 2019-16 | Cybersecurity Assessment CS-001 | In progress |
Clinical Evidence Requirements by Class
| Class | Clinical Requirement | Documentation |
|---|---|---|
| I | Clinical evaluation (CE) | CE report |
| IIa | CE with literature focus | CE report + PMCF plan |
| IIb | CE with clinical data | CE report + PMCF + clinical study (some) |
| III | CE with clinical investigation | CE report + PMCF + clinical investigation |
Notified Body Selection Criteria
- Scope: Designated for your specific device category
- Capacity: Confirmed availability within target timeline
- Experience: Track record with your technology type
- Geography: Proximity for on-site audits
- Cost: Fee structure transparency
- Communication: Responsiveness and query turnaround
See: references/eu-mdr-submission-guide.md
---
Global Market Access Workflow
Coordinate regulatory approvals across international markets.
Workflow: Multi-Market Submission Strategy
1. Define target markets based on business priorities 2. Sequence markets for efficient evidence leverage:
- Phase 1: FDA + EU (reference markets)
- Phase 2: Recognition markets (Canada, Australia)
- Phase 3: Major markets (Japan, China)
- Phase 4: Emerging markets
3. Identify local requirements per market:
- Clinical data acceptability
- Local agent/representative needs
- Language and labeling requirements
4. Develop master technical file with localization plan 5. Establish in-country regulatory support 6. Execute parallel or sequential submissions 7. Track approvals and coordinate launches 8. Validation: All target market approvals obtained; registration database updated
Market Priority Matrix
| Market | Size | Complexity | Recognition | Priority |
|---|---|---|---|---|
| USA | Large | High | N/A | 1 |
| EU | Large | High | N/A | 1–2 |
| Canada | Medium | Medium | MDSAP | 2 |
| Australia | Medium | Low | EU accepted | 2 |
| Japan | Large | High | Local clinical | 3 |
| China | Large | Very High | Local testing | 3 |
| Brazil | Medium | High | GMP inspection | 3–4 |
Documentation Efficiency Strategy
| Document Type | Single Source | Localization Required |
|---|---|---|
| Technical file core | Yes | Format adaptation |
| Risk management | Yes | None |
| Clinical data | Yes | Bridging assessment |
| QMS certificate | Yes (ISO 13485) | Market-specific audit |
| Labeling | Master label | Translation, local requirements |
| IFU | Master content | Translation, local symbols |
See: references/global-regulatory-pathways.md
---
Regulatory Intelligence Workflow
Monitor and respond to regulatory changes affecting product portfolio.
Workflow: Regulatory Change Management
1. Monitor regulatory sources:
- FDA Federal Register, guidance documents
- EU Official Journal, MDCG guidance
- Notified Body communications
- Industry associations (AdvaMed, MedTech Europe)
2. Assess relevance to product portfolio 3. Evaluate impact:
- Timeline to compliance
- Resource requirements
- Product changes needed
4. Develop compliance action plan 5. Communicate to affected stakeholders 6. Implement required changes 7. Document compliance status 8. Validation: Compliance action plan approved; changes implemented on schedule
Regulatory Monitoring Sources
| Source | Type | Frequency |
|---|---|---|
| FDA Federal Register | Regulations, guidance | Daily |
| FDA Device Database | 510(k), PMA, recalls | Weekly |
| EU Official Journal | MDR/IVDR updates | Weekly |
| MDCG Guidance | EU implementation | As published |
| ISO/IEC | Standards updates | Quarterly |
| Notified Body | Audit findings, trends | Per interaction |
Impact Assessment Template
REGULATORY CHANGE IMPACT ASSESSMENT
Change: [Description] Source: [Regulation/Guidance]
Effective Date: [Date] Assessment Date: [Date] Assessed By: [Name]
AFFECTED PRODUCTS
| Product | Impact (H/M/L) | Action Required | Due Date |
|---------|----------------|------------------------|----------|
| [Name] | [H/M/L] | [Specific action] | [Date] |
COMPLIANCE ACTIONS
1. [Action] — Owner: [Name] — Due: [Date]
2. [Action] — Owner: [Name] — Due: [Date]
RESOURCE REQUIREMENTS: Budget $[X] | Personnel [X] hrs
APPROVAL: Regulatory _____________ Date _______ / Management _____________ Date _______---
Decision Frameworks
Pathway Selection and Classification Reference
FDA Pathway Selection
Is predicate device available?
│
Yes─┴─No
│ │
▼ ▼
Is device Is risk level
substantially Low-Moderate?
equivalent? │
│ Yes─┴─No
Yes─┴─No │ │
│ │ ▼ ▼
▼ ▼ De Novo PMA
510(k) Consider required
De Novo
or PMAEU MDR Classification
Is the device active?
│
Yes─┴─No
│ │
▼ ▼
Is it an Does it contact
implant? the body?
│ │
Yes─┴─No Yes─┴─No
│ │ │ │
▼ ▼ ▼ ▼
III IIb Check Class I
contact (measuring/
type sterile if
and applicable)
durationPre-Submission Meeting Decision
| Factor | Schedule Pre-Sub | Skip Pre-Sub |
|---|---|---|
| Novel Technology | ✓ | |
| New Intended Use | ✓ | |
| Complex Testing | ✓ | |
| Uncertain Predicate | ✓ | |
| Clinical Data Needed | ✓ | |
| Well-established | ✓ | |
| Clear Predicate | ✓ | |
| Standard Testing | ✓ |
Regulatory Escalation Criteria
| Situation | Escalation Level | Action |
|---|---|---|
| Submission rejection | VP Regulatory | Root cause analysis, strategy revision |
| Major deficiency | Director | Cross-functional response team |
| Timeline at risk | Management | Resource reallocation review |
| Regulatory change | VP Regulatory | Portfolio impact assessment |
| Safety signal | Executive | Immediate containment and reporting |
---
Tools and References
Scripts
| Tool | Purpose | Usage |
|---|---|---|
| regulatory_tracker.py | Track submission status and timelines | python regulatory_tracker.py |
Regulatory Tracker Features:
- Track multiple submissions across markets
- Monitor status and target dates
- Identify overdue submissions
- Generate status reports
Example usage:
$ python regulatory_tracker.py --report status
Submission Status Report — 2024-11-01
┌──────────────────┬──────────┬────────────┬─────────────┬──────────┐
│ Product │ Market │ Type │ Target Date │ Status │
├──────────────────┼──────────┼────────────┼─────────────┼──────────┤
│ WoundScan Pro │ USA │ 510(k) │ 2024-12-01 │ On Track │
│ WoundScan Pro │ EU │ MDR IIb │ 2025-03-01 │ At Risk │
│ CardioMonitor X1 │ Canada │ Class II │ 2025-01-15 │ On Track │
└──────────────────┴──────────┴────────────┴─────────────┴──────────┘
1 submission at risk: WoundScan Pro EU — NB engagement not confirmed.References
| Document | Content |
|---|---|
| fda-submission-guide.md | FDA pathways, requirements, review process |
| eu-mdr-submission-guide.md | MDR classification, technical documentation, clinical evidence |
| global-regulatory-pathways.md | Canada, Japan, China, Australia, Brazil requirements |
| iso-regulatory-requirements.md | ISO 13485, 14971, 10993, IEC 62304, 62366 requirements |
Key Performance Indicators
| KPI | Target | Calculation |
|---|---|---|
| First-time approval rate | >85% | (Approved without major deficiency / Total submitted) × 100 |
| On-time submission | >90% | (Submitted by target date / Total submissions) × 100 |
| Review cycle compliance | >95% | (Responses within deadline / Total requests) × 100 |
| Regulatory hold time | <20% | (Days on hold / Total review days) × 100 |
---
Related Skills
| Skill | Integration Point |
|---|---|
| mdr-745-specialist | Detailed EU MDR technical requirements |
| fda-consultant-specialist | FDA submission deep expertise |
| quality-manager-qms-iso13485 | QMS for regulatory compliance |
| risk-management-specialist | ISO 14971 risk management |
EU MDR 2017/745 Submission Guide
MDR Classification and Conformity Assessment Routes
Class I Devices
- Self-certification under Annex II
- Technical documentation requirements per Annex II
- Declaration of Conformity mandatory
- UDI registration required
Class IIa Devices
- Notified Body involvement for Annex III Module C2 + Annex V
- Quality management system assessment
- Technical documentation review
- Ongoing surveillance requirements
Class IIb Devices
- Notified Body certification under Annex III Module B + C or D
- Type examination or Full quality assurance route
- Design examination requirements
- Production surveillance obligations
Class III Devices
- Comprehensive Notified Body assessment
- Type examination + production surveillance OR
- Full quality assurance system approach
- Design dossier requirements per Annex II
Key MDR Submission Requirements
1. Technical Documentation (Annex II)
- Device description and intended purpose
- Risk management documentation (ISO 14971)
- Clinical evidence per Annex XIV
- Post-market surveillance plan
- Performance evaluation reports
2. Quality Management System (Annex I, Chapter II)
- ISO 13485 compliant QMS
- Design controls implementation
- Risk management integration
- Clinical evaluation procedures
- Post-market surveillance system
3. Clinical Evidence Requirements
- Clinical evaluation plan per Annex XIV
- Literature review and gap analysis
- Clinical investigation if required
- Post-market clinical follow-up plan
- Clinical evaluation report updating
4. UDI System Implementation
- UDI-DI assignment and registration
- UDI-PI requirements for higher risk devices
- EUDAMED registration obligations
- Labeling compliance with UDI requirements
Submission Timeline Framework
Pre-Submission Phase (6-12 months)
1. Gap analysis against MDR requirements 2. Classification confirmation with regulatory experts 3. Notified Body selection and preliminary discussions 4. Clinical evidence strategy development 5. UDI strategy and EUDAMED preparation
Submission Preparation (3-6 months)
1. Technical documentation compilation 2. QMS documentation review and update 3. Clinical evaluation completion 4. Risk management file finalization 5. Notified Body application submission
Review and Certification (6-18 months)
1. Initial assessment by Notified Body 2. Questions and clarifications response 3. Audit activities coordination 4. Certificate issuance and market access 5. Post-market obligations activation
Critical Success Factors
- Early engagement with chosen Notified Body
- Robust clinical evidence strategy and execution
- Comprehensive risk management throughout lifecycle
- Proactive post-market surveillance system
- Regular monitoring of regulatory updates and guidance
Common Pitfalls to Avoid
- Insufficient clinical evidence planning
- Late Notified Body engagement
- Inadequate post-market surveillance systems
- Poor documentation quality and traceability
- Underestimating timeline and resource requirements
FDA Submission Guide
FDA Medical Device Classification and Pathways
Class I Devices
- 510(k) Exempt - Most Class I devices
- General Controls apply (21 CFR 820)
- FDA registration required
- Device listing mandatory
Class II Devices
- 510(k) Clearance - Premarket notification
- General + Special Controls apply
- Predicate device identification required
- Substantial equivalence demonstration
Class III Devices
- PMA (Premarket Approval) - Full safety and effectiveness review
- IDE (Investigational Device Exemption) for clinical studies
- Clinical data typically required
- Post-market surveillance obligations
De Novo Classification
- Novel devices without predicate
- Low to moderate risk profile
- Creates new device classification
- Special controls development
Submission Pathways and Requirements
1. 510(k) Premarket Notification
Traditional 510(k)
- Predicate device comparison
- Performance testing documentation
- Software documentation (if applicable)
- Labeling and indications for use
Special 510(k)
- Modifications to cleared devices
- Design controls documentation
- Risk analysis of changes
- Performance validation
Abbreviated 510(k)
- Guidance document compliance
- Recognized standards conformance
- Special controls adherence
- Reduced documentation requirements
2. PMA (Premarket Approval)
Clinical Investigation Requirements
- IDE study protocol approval
- GCP compliance documentation
- Clinical study reports
- Statistical analysis plans
Manufacturing Information
- ISO 13485 QMS compliance
- Manufacturing process validation
- Facility inspection readiness
- Supply chain documentation
3. De Novo Classification Request
Risk-based Classification
- Benefit-risk profile analysis
- Predicate device absence justification
- Special controls recommendations
- Clinical evidence strategy
FDA Submission Process
Pre-Submission Activities
1. Q-Sub Meeting - Pre-submission consultation 2. Classification determination confirmation 3. Predicate device identification and analysis 4. Testing strategy development and validation 5. FDA guidance review and compliance assessment
Submission Preparation
1. Technical documentation compilation per FDA format 2. Quality system documentation and readiness 3. Clinical evidence compilation (if required) 4. Labeling and indications for use finalization 5. eCopy submission preparation
FDA Review Process
1. Administrative review (15 days for completeness) 2. Substantive review (90 days for 510(k), 180 days for PMA) 3. Additional information requests and responses 4. FDA questions and clarifications 5. Clearance/approval or denial decision
Special Considerations
Software as Medical Device (SaMD)
- Software documentation per FDA guidance
- Cybersecurity considerations and risk management
- Software lifecycle process documentation
- Change control procedures
Combination Products
- OPDP assignment determination
- Lead center coordination
- Intercenter agreement requirements
- Combination product specific guidance
HIPAA Compliance
- Protected Health Information safeguards
- Business associate agreements
- Risk assessment and management
- Breach notification procedures
Quality System Requirements
21 CFR Part 820 (QMSR — ISO 13485:2016 incorporated by reference)
⚠️ STATUS — QMSR transition (effective 2026-02-02): FDA's QMSR final rule (89 FR 7496) amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference and removed the legacy QSR subsection structure. Cite the ISO 13485 clauses — the legacy 820.x numbers below are historical index only.
- Design and development — ISO 13485 §7.3 (legacy QSR 820.30, historical)
- Document control — ISO 13485 §4.2.4 (legacy QSR 820.40, historical)
- Management responsibility — ISO 13485 §5 (legacy QSR 820.20, historical)
- Corrective and preventive action — ISO 13485 §8.5.2/§8.5.3 (legacy QSR 820.100, historical)
Key Performance Metrics
- Review timeline adherence and predictability
- First-time clearance rates and success factors
- Additional information request frequency
- Post-market compliance effectiveness
- FDA inspection readiness and outcomes
Global Regulatory Pathways
International regulatory requirements for medical devices beyond FDA and EU MDR markets.
---
Table of Contents
---
Canada (Health Canada)
Device Classification
| Class | Risk Level | Examples | Review Type |
|---|---|---|---|
| I | Lowest | Tongue depressors, bandages | Establishment license only |
| II | Low-moderate | Contact lenses, pregnancy tests | Declaration of conformity |
| III | Moderate-high | Orthopedic implants, ventilators | Pre-market review |
| IV | Highest | Pacemakers, HIV tests | In-depth pre-market review |
Medical Device License (MDL) Requirements
Class II-IV Devices: 1. Device license application via MDALL (Medical Devices Active License Listing) 2. Quality management system documentation (ISO 13485) 3. Device safety and effectiveness evidence 4. Canadian labeling requirements (French/English bilingual) 5. Canadian Medical Device Single Audit Program (CMDCAS) certificate
Review Timelines:
| Class | Standard Review | Priority Review |
|---|---|---|
| II | 15 days | N/A |
| III | 60 days | 30 days |
| IV | 75 days | 45 days |
Key Requirements
| Requirement | Details |
|---|---|
| QMS Audit | MDSAP or ISO 13485 audit by recognized body |
| UDI | Canadian UDI-DI required in MDALL |
| Labeling | Bilingual (English/French) mandatory |
| Incident Reporting | Mandatory problem reporting within 10-30 days |
| Post-Market | Annual license maintenance |
---
Japan (PMDA)
Device Classification (Pharmaceutical and Medical Device Act)
| Class | Japanese Term | Examples | Regulatory Path |
|---|---|---|---|
| I | General | Scalpels, X-ray film | Self-certification |
| II | Controlled | MRI, ultrasound | Third-party certification |
| III | Specially Controlled | Pacemaker leads, dialyzers | PMDA Shonin approval |
| IV | Specially Controlled | Pacemakers, artificial hearts | PMDA Shonin approval |
Shonin Approval Process
Pre-Application: 1. Classification consultation with PMDA 2. Pre-submission meeting (recommended for Class III/IV) 3. Japanese clinical data requirements assessment 4. Marketing Authorization Holder (MAH) designation
Application Requirements:
- Technical documentation per MHLW format
- Japanese clinical data (bridging study may be required)
- QMS compliance certificate (ISO 13485)
- GCP compliance for clinical studies
- Japanese labeling and IFU
Review Timelines:
| Application Type | Standard | Priority |
|---|---|---|
| New Shonin | 12 months | 6 months |
| Partial Change | 6-9 months | 3-4 months |
Special Considerations
| Factor | Requirement |
|---|---|
| Clinical Data | Japanese patient data often required |
| MAH | Requires Japanese MAH or Designated MAH (D-MAH) |
| QMS | MHLW Minister certification or ISO 13485 |
| Language | All documents in Japanese |
| Foreign Manufacturer | Accreditation required |
---
China (NMPA)
Device Classification
| Class | Risk Level | Examples | Regulatory Path |
|---|---|---|---|
| I | Low | Surgical instruments | Provincial filing |
| II | Moderate | Diagnostic ultrasound, ECG | Provincial registration |
| III | High | Pacemakers, implants | NMPA registration |
Registration Requirements
Class II/III Registration: 1. Clinical evaluation or trial (China-specific requirements) 2. Product technical requirements document 3. Type testing by NMPA-designated lab 4. Quality management system (ISO 13485 + Chinese requirements) 5. Chinese agent appointment (CSRC holder)
Review Process:
| Stage | Class II | Class III |
|---|---|---|
| Technical Review | 60 working days | 90 working days |
| Administrative Review | 20 working days | 20 working days |
| Registration Certificate | 5 years validity | 5 years validity |
Key Requirements
| Requirement | Details |
|---|---|
| Clinical Trial | Required for most Class III; China-specific data |
| Testing | NMPA-designated testing laboratory |
| Agent | Chinese Service Representative Certificate (CSRC) holder |
| Labeling | Simplified Chinese mandatory |
| QMS | Chinese GMP compliance in addition to ISO 13485 |
China Clinical Trial Requirements
| Device Type | Clinical Requirement |
|---|---|
| First-of-kind | Full clinical trial in China |
| Well-established | Literature + clinical evaluation |
| Equivalent device | Comparative analysis + limited data |
---
Australia (TGA)
Device Classification (TGO 41)
| Class | Risk Level | Examples | Conformity Route |
|---|---|---|---|
| I | Lowest | Surgical retractors | Manufacturer declaration |
| I (measuring) | Low | Clinical thermometers | EU/MDSAP certificate |
| I (sterile) | Low | Sterile gloves | EU/MDSAP certificate |
| IIa | Low-moderate | Hearing aids, ultrasound | EU/MDSAP certificate |
| IIb | Moderate-high | Ventilators, X-ray | EU/MDSAP certificate |
| III | High | Pacemakers, implants | EU/MDSAP certificate |
| AIMD | Active implants | Cochlear implants | EU/MDSAP certificate |
Australian Register of Therapeutic Goods (ARTG)
Registration Requirements: 1. Australian sponsor (manufacturer or importer) 2. Conformity assessment evidence (EU certificate or MDSAP) 3. Australian labeling compliance 4. Adverse event reporting system 5. ARTG application and fees
Pathways:
| Pathway | Applicable Devices | Documentation |
|---|---|---|
| Conformity Assessment | All classes | EU/MDSAP certificates accepted |
| Comparable Overseas Regulator | Established devices | Recognition of FDA/EU approval |
| TGA Audit | No overseas certificate | TGA conducts assessment |
Key Requirements
| Requirement | Details |
|---|---|
| Sponsor | Australian-based sponsor mandatory |
| Conformity | EU MDR/IVDR or MDSAP certificate |
| Labeling | English, Australian-specific requirements |
| Incident Reporting | Mandatory within 48 hours (serious) |
| Annual Charges | Based on ARTG listing |
---
Brazil (ANVISA)
Device Classification (RDC 185/2001)
| Class | Risk Level | Examples | Registration |
|---|---|---|---|
| I | Low | Tongue depressors | Notification (cadastro) |
| II | Low-moderate | Wheelchairs, syringes | Notification (cadastro) |
| III | Moderate-high | Hemodialysis, implants | Registration (registro) |
| IV | High | Pacemakers, stents | Registration (registro) |
Registration Process
Cadastro (Class I/II):
- Brazilian Registration Holder (BRH) application
- Technical documentation
- Good Manufacturing Practice (GMP) certificate
- Free sale certificate from country of origin
Registro (Class III/IV):
- Full technical dossier submission
- ANVISA GMP inspection (if not MDSAP)
- Clinical data requirements
- Brazilian labeling and IFU
- Registration validity: 5 years (Class III) or 10 years (Class IV)
Key Requirements
| Requirement | Details |
|---|---|
| BRH | Brazilian Registration Holder mandatory |
| GMP | ANVISA inspection or MDSAP certificate |
| INMETRO | Certification for specific device categories |
| Language | Portuguese labeling and IFU |
| Clinical | Brazilian clinical data may be required |
Review Timelines:
| Type | Standard | Priority |
|---|---|---|
| Cadastro | 30-60 days | N/A |
| Registro | 180-365 days | 90-180 days |
---
Market Entry Strategy
Prioritization Framework
| Factor | Weight | Considerations |
|---|---|---|
| Market Size | 25% | Revenue potential, growth rate |
| Regulatory Complexity | 25% | Timeline, cost, local requirements |
| Competitive Landscape | 20% | Existing players, differentiation |
| Reimbursement | 20% | Payer coverage, pricing |
| Strategic Value | 10% | Reference market, regional hub |
Recommended Entry Sequence
Phase 1: Priority Markets (Year 1)
- United States (FDA)
- European Union (MDR)
- Leverage for downstream approvals
Phase 2: Recognition Markets (Year 1-2)
- Australia (TGA) - accepts EU/MDSAP
- Canada (Health Canada) - MDSAP pathway
- Faster approval using existing evidence
Phase 3: Major Markets (Year 2-3)
- Japan (PMDA) - may require local clinical
- China (NMPA) - local testing and clinical
Phase 4: Emerging Markets (Year 3+)
- Brazil (ANVISA)
- Other Latin America
- Middle East, Southeast Asia
Documentation Efficiency
| Document Type | Create Once | Localize Per Market |
|---|---|---|
| Technical file | Core technical documentation | Specific format requirements |
| Clinical data | Global clinical study | Local bridging studies |
| QMS certificate | ISO 13485 / MDSAP | Market-specific audits |
| Labeling | Master label content | Language, local requirements |
Common Pitfalls
| Pitfall | Impact | Prevention |
|---|---|---|
| Underestimating local clinical requirements | 12-24 month delay | Early regulatory intelligence |
| Inadequate in-country representation | Registration rejection | Qualified local partner |
| Language/labeling non-compliance | Market rejection | Professional translation review |
| Ignoring post-market requirements | License suspension | Establish vigilance system |
| Sequential vs. parallel submissions | Extended timeline | Plan parallel submissions where possible |
ISO Regulatory Requirements for Medical Devices
Key ISO standards applicable to medical device development, quality management, and regulatory compliance.
---
Table of Contents
- ISO 13485 Quality Management
- ISO 14971 Risk Management
- ISO 10993 Biocompatibility
- IEC 62304 Software Lifecycle
- IEC 62366 Usability Engineering
- ISO 11607 Packaging Validation
- Sterilization Standards
- Standards Cross-Reference
---
ISO 13485 Quality Management
ISO 13485:2016 Overview
| Aspect | Requirement |
|---|---|
| Scope | QMS for design, development, production, installation, and servicing |
| Certification | Third-party certification required for most markets |
| Regulatory Status | Harmonized under EU MDR; recognized by FDA QSIT |
| Validity | 3-year certification cycle with annual surveillance |
Key Clause Requirements
| Clause | Title | Regulatory Focus |
|---|---|---|
| 4.1 | General Requirements | Process-based QMS, outsourcing control |
| 4.2 | Documentation | Quality Manual, procedures, records |
| 5.1-5.6 | Management Responsibility | Policy, planning, review |
| 6.1-6.4 | Resource Management | Competence, infrastructure, environment |
| 7.1 | Planning | Risk management integration |
| 7.2 | Customer-Related | Requirements determination and review |
| 7.3 | Design and Development | Design controls (critical for FDA) |
| 7.4 | Purchasing | Supplier controls |
| 7.5 | Production | Process validation, identification, traceability |
| 7.6 | Monitoring Equipment | Calibration |
| 8.2 | Monitoring | Feedback, complaints, audits |
| 8.3 | Nonconforming Product | Control and disposition |
| 8.5 | Improvement | CAPA |
Design Control Requirements (Clause 7.3)
| Stage | Clause | Deliverables |
|---|---|---|
| Planning | 7.3.2 | Design plan, stages, responsibilities |
| Inputs | 7.3.3 | Requirements specification |
| Outputs | 7.3.4 | Design specifications, acceptance criteria |
| Review | 7.3.5 | Design review records |
| Verification | 7.3.6 | Verification testing reports |
| Validation | 7.3.7 | Validation protocols and reports |
| Transfer | 7.3.8 | Transfer verification records |
| Changes | 7.3.9 | Change control records |
Regulatory Mapping
| Regulation | ISO 13485 Recognition |
|---|---|
| EU MDR 2017/745 | Harmonized standard (presumption of conformity) |
| FDA 21 CFR 820 | Substantially equivalent; QSIT alignment |
| Health Canada | MDSAP or direct recognition |
| PMDA Japan | Recognized with MHLW certification |
| TGA Australia | Accepted as conformity evidence |
| ANVISA Brazil | Required for GMP compliance |
---
ISO 14971 Risk Management
ISO 14971:2019 Overview
| Aspect | Requirement |
|---|---|
| Scope | Risk management throughout medical device lifecycle |
| Regulatory Status | Harmonized under EU MDR; referenced by FDA |
| Key Change (2019) | Enhanced benefit-risk analysis emphasis |
| Documentation | Risk management file required |
Risk Management Process
| Stage | Activities | Outputs |
|---|---|---|
| Planning | Define scope, responsibilities, criteria | Risk management plan |
| Risk Analysis | Identify hazards, estimate risk | Hazard analysis, risk estimation |
| Risk Evaluation | Compare against acceptability criteria | Risk evaluation records |
| Risk Control | Select and implement controls | Risk control measures |
| Residual Risk | Evaluate remaining risk | Residual risk evaluation |
| Risk-Benefit | Assess overall benefit-risk | Benefit-risk analysis |
| Review | Periodic risk management review | Risk management report |
Risk Analysis Methods
| Method | Application | Standard Reference |
|---|---|---|
| FMEA | Component/process failure modes | IEC 60812 |
| FTA | System-level failure analysis | IEC 61025 |
| HAZOP | Process hazard identification | IEC 61882 |
| PHA | Preliminary hazard assessment | - |
Risk Acceptability Matrix
| Severity | Probability | Risk Level | Action |
|---|---|---|---|
| Catastrophic | Frequent | Unacceptable | Design change required |
| Critical | Probable | ALARP | Risk reduction required |
| Serious | Occasional | ALARP | Risk reduction if practicable |
| Minor | Remote | Acceptable | Monitor |
| Negligible | Improbable | Acceptable | Document |
Post-Production Risk Management
| Activity | Frequency | Sources |
|---|---|---|
| Complaint Analysis | Continuous | Customer complaints |
| Vigilance Review | Continuous | Adverse event reports |
| Literature Review | Annual | Scientific publications |
| Standards Review | Annual | Updated standards |
| Risk File Update | As needed | New information |
---
ISO 10993 Biocompatibility
ISO 10993-1:2018 Biological Evaluation Framework
| Contact Type | Duration | Required Tests |
|---|---|---|
| Surface - Skin | Limited (<24h) | Cytotoxicity, sensitization, irritation |
| Surface - Mucosal | Prolonged (24h-30d) | + Acute systemic toxicity |
| Surface - Breached | Permanent (>30d) | + Subchronic toxicity, genotoxicity |
| External Communicating | Limited | Cytotoxicity, sensitization, irritation, hemolysis |
| External Communicating | Prolonged | + Subchronic toxicity, implantation |
| External Communicating | Permanent | + Chronic toxicity, carcinogenicity |
| Implant | Limited | Full biological evaluation |
| Implant | Prolonged/Permanent | Comprehensive testing including implantation |
Key Test Standards
| Standard | Test |
|---|---|
| ISO 10993-3 | Genotoxicity, carcinogenicity, reproductive toxicity |
| ISO 10993-4 | Hemocompatibility |
| ISO 10993-5 | Cytotoxicity (in vitro) |
| ISO 10993-6 | Local effects after implantation |
| ISO 10993-10 | Irritation and skin sensitization |
| ISO 10993-11 | Systemic toxicity |
| ISO 10993-12 | Sample preparation and reference materials |
| ISO 10993-18 | Chemical characterization |
Biocompatibility Evaluation Workflow
1. Define device contact nature and duration 2. Identify materials in contact with body 3. Perform chemical characterization (ISO 10993-18) 4. Conduct gap analysis against required endpoints 5. Plan and execute required testing 6. Document biological evaluation report 7. Update for material or design changes 8. Validation: All endpoints addressed; testing per GLP; BE report complete
---
IEC 62304 Software Lifecycle
IEC 62304:2006/AMD1:2015 Overview
| Aspect | Requirement |
|---|---|
| Scope | Medical device software development lifecycle |
| Regulatory Status | Harmonized under EU MDR; FDA guidance reference |
| Key Concept | Safety classification drives rigor |
| Documentation | Software development plan, architecture, testing |
Software Safety Classification
| Class | Definition | Documentation Rigor |
|---|---|---|
| A | No injury or damage possible | Basic |
| B | Non-serious injury possible | Moderate |
| C | Death or serious injury possible | High |
Required Processes by Class
| Process | Class A | Class B | Class C |
|---|---|---|---|
| Software Development Planning | Required | Required | Required |
| Software Requirements Analysis | Required | Required | Required |
| Software Architecture Design | - | Required | Required |
| Software Detailed Design | - | - | Required |
| Software Unit Implementation | Required | Required | Required |
| Software Unit Verification | - | Required | Required |
| Software Integration Testing | Required | Required | Required |
| Software System Testing | Required | Required | Required |
| Software Release | Required | Required | Required |
| Software Maintenance | Required | Required | Required |
| Software Risk Management | Required | Required | Required |
| Software Configuration Management | Required | Required | Required |
| Software Problem Resolution | Required | Required | Required |
Documentation Requirements
| Document | Class A | Class B | Class C |
|---|---|---|---|
| Software Development Plan | ✓ | ✓ | ✓ |
| Software Requirements Specification | ✓ | ✓ | ✓ |
| Software Architecture Document | - | ✓ | ✓ |
| Software Detailed Design | - | - | ✓ |
| Software Unit Test Records | - | ✓ | ✓ |
| Integration Test Records | ✓ | ✓ | ✓ |
| System Test Records | ✓ | ✓ | ✓ |
| Traceability Matrix | - | ✓ | ✓ |
---
IEC 62366 Usability Engineering
IEC 62366-1:2015 Overview
| Aspect | Requirement |
|---|---|
| Scope | Usability engineering process for medical devices |
| Regulatory Status | Harmonized under EU MDR; FDA HFE guidance |
| Key Concept | Use-related risk identification and mitigation |
| Documentation | Usability engineering file |
Usability Engineering Process
| Stage | Activities | Outputs |
|---|---|---|
| Use Specification | Define users, use environments, user interface | Use specification document |
| User Interface Design | Design UI with task analysis input | UI specifications |
| Hazard Analysis | Identify use-related hazards | Use-related risk analysis |
| Formative Evaluation | Iterative design testing | Formative evaluation reports |
| Summative Evaluation | Final design validation | Summative evaluation report |
| Documentation | Compile usability engineering file | UEF |
Usability Testing Requirements
| Test Type | Purpose | Participants |
|---|---|---|
| Formative | Identify usability issues during design | Representative users (5-8 per iteration) |
| Summative | Validate final design | Representative users (15+ per user group) |
| Simulated Use | Test under realistic conditions | Trained users in simulated environment |
| Actual Use | Validate in clinical setting | Actual users in actual environment |
Usability Engineering File Contents
| Section | Content |
|---|---|
| Use Specification | User profiles, use environments, user interface |
| Use-Related Risk Analysis | Hazard identification, risk evaluation |
| UI Design Specifications | Design requirements, rationale |
| Formative Evaluation | Test protocols, results, design changes |
| Summative Evaluation | Validation protocol, results, conclusions |
| Residual Risk | Remaining use-related risks |
---
ISO 11607 Packaging Validation
ISO 11607-1:2019 and ISO 11607-2:2019
| Part | Scope |
|---|---|
| Part 1 | Requirements for materials, sterile barrier systems, packaging systems |
| Part 2 | Validation requirements for forming, sealing, and assembly processes |
Packaging Validation Stages
| Stage | Activities | Documentation |
|---|---|---|
| IQ | Equipment installation verification | Installation records |
| OQ | Process parameter verification | OQ protocol and report |
| PQ | Performance under production conditions | PQ protocol and report |
Required Testing
| Test | Standard | Purpose |
|---|---|---|
| Seal Strength | ASTM F88 | Peel strength measurement |
| Seal Integrity | ASTM F2095 | Bubble leak test |
| Visual Inspection | ISO 11607-1 | Defect identification |
| Package Integrity | ASTM D4169 | Distribution simulation |
| Accelerated Aging | ASTM F1980 | Shelf life validation |
| Real-Time Aging | - | Stability confirmation |
Shelf Life Validation
| Method | Approach | Considerations |
|---|---|---|
| Accelerated Aging | Q10 = 2 (typically) | Per ASTM F1980 |
| Real-Time Aging | Concurrent with accelerated | Required for final claim |
| Worst-Case Testing | Post-aging integrity testing | Distribution + storage conditions |
---
Sterilization Standards
Common Sterilization Methods
| Method | Standard | Applications |
|---|---|---|
| EO (Ethylene Oxide) | ISO 11135:2014 | Heat/moisture sensitive |
| Steam | ISO 17665-1:2006 | Heat/moisture tolerant |
| Radiation | ISO 11137:2017 | Heat sensitive, high volume |
| Dry Heat | ISO 20857:2010 | Moisture sensitive |
| Aseptic Processing | ISO 13408 | Prefilled syringes |
Sterilization Validation Requirements
| Phase | Activities | Documentation |
|---|---|---|
| IQ | Equipment installation | Installation records |
| OQ | Process parameter qualification | OQ protocol and report |
| PQ | Microbiological performance | Bioburden, SAL demonstration |
| Routine Control | Process monitoring | Batch records, BI results |
Sterility Assurance Level (SAL)
| SAL | Probability of Non-Sterile | Application |
|---|---|---|
| 10⁻⁶ | 1 in 1 million | Most medical devices |
| 10⁻³ | 1 in 1,000 | Aseptically processed |
---
Standards Cross-Reference
Regulatory Alignment
| Standard | EU MDR | FDA | Health Canada | TGA |
|---|---|---|---|---|
| ISO 13485 | Harmonized | Recognized | Required | Accepted |
| ISO 14971 | Harmonized | Referenced | Required | Accepted |
| ISO 10993 | Harmonized | Referenced | Required | Accepted |
| IEC 62304 | Harmonized | Referenced | Required | Accepted |
| IEC 62366 | Harmonized | Referenced | Required | Accepted |
Version Requirements
| Standard | Current Version | Transition Deadline |
|---|---|---|
| ISO 13485 | 2016 | Active |
| ISO 14971 | 2019 | Active |
| ISO 10993-1 | 2018 | Active |
| IEC 62304 | 2006/Amd1:2015 | Active |
| IEC 62366-1 | 2015/Amd1:2020 | Active |
Certification Bodies
| Region | Certification Body Type |
|---|---|
| EU | Notified Bodies (per MDR) |
| USA | FDA-recognized accreditation bodies |
| MDSAP | Authorized auditing organizations |
| Global | ISO certification bodies (IATF, DNV, BSI, TÜV) |
#!/usr/bin/env python3
"""
Regulatory Pathway Analyzer - Determines optimal regulatory pathway for medical devices.
Analyzes device characteristics and recommends the most efficient regulatory pathway
across multiple markets (FDA, EU MDR, UK UKCA, Health Canada, TGA, PMDA).
Supports:
- FDA: 510(k), De Novo, PMA, Breakthrough Device
- EU MDR: Class I, IIa, IIb, III, AIMDD
- UK: UKCA marking
- Health Canada: Class I-IV
- TGA: Class I, IIa, IIb, III
- Japan PMDA: Class I-IV
Usage:
python regulatory_pathway_analyzer.py --device-class II --predicate yes --market all
python regulatory_pathway_analyzer.py --interactive
python regulatory_pathway_analyzer.py --data device_profile.json --output json
"""
import argparse
import json
import sys
from dataclasses import dataclass, field, asdict
from typing import List, Dict, Optional, Tuple
from enum import Enum
class RiskClass(Enum):
CLASS_I = "I"
CLASS_IIA = "IIa"
CLASS_IIB = "IIb"
CLASS_III = "III"
CLASS_IV = "IV"
class MarketRegion(Enum):
US_FDA = "US-FDA"
EU_MDR = "EU-MDR"
UK_UKCA = "UK-UKCA"
HEALTH_CANADA = "Health-Canada"
AUSTRALIA_TGA = "Australia-TGA"
JAPAN_PMDA = "Japan-PMDA"
@dataclass
class DeviceProfile:
"""Medical device profile for pathway analysis."""
device_name: str
intended_use: str
device_class: str # I, IIa, IIb, III
novel_technology: bool = False
predicate_available: bool = True
implantable: bool = False
life_sustaining: bool = False
software_component: bool = False
ai_ml_component: bool = False
sterile: bool = False
measuring_function: bool = False
target_markets: List[str] = field(default_factory=lambda: ["US-FDA", "EU-MDR"])
@dataclass
class PathwayOption:
"""A regulatory pathway option."""
pathway_name: str
market: str
estimated_timeline_months: Tuple[int, int]
estimated_cost_usd: Tuple[int, int]
key_requirements: List[str]
advantages: List[str]
risks: List[str]
recommendation_level: str # "Recommended", "Alternative", "Not Recommended"
@dataclass
class PathwayAnalysis:
"""Complete pathway analysis result."""
device: DeviceProfile
recommended_pathways: List[PathwayOption]
optimal_sequence: List[str] # Recommended submission order
total_timeline_months: Tuple[int, int]
total_estimated_cost: Tuple[int, int]
critical_success_factors: List[str]
warnings: List[str]
class RegulatoryPathwayAnalyzer:
"""Analyzes and recommends regulatory pathways for medical devices."""
# FDA pathway decision matrix
FDA_PATHWAYS = {
"I": {
"pathway": "510(k) Exempt / Registration & Listing",
"timeline": (1, 3),
"cost": (5000, 15000),
"requirements": ["Establishment registration", "Device listing", "GMP compliance (if non-exempt)"]
},
"II": {
"pathway": "510(k)",
"timeline": (6, 12),
"cost": (50000, 250000),
"requirements": ["Predicate device identification", "Substantial equivalence demonstration", "Performance testing", "Biocompatibility (if applicable)", "Software documentation (if applicable)"]
},
"II-novel": {
"pathway": "De Novo",
"timeline": (12, 18),
"cost": (150000, 400000),
"requirements": ["Risk-based classification request", "Special controls development", "Performance testing", "Clinical data (potentially)"]
},
"III": {
"pathway": "PMA",
"timeline": (18, 36),
"cost": (500000, 2000000),
"requirements": ["Clinical investigations", "Manufacturing information", "Performance testing", "Risk-benefit analysis", "Post-approval studies"]
},
"III-breakthrough": {
"pathway": "Breakthrough Device Program + PMA",
"timeline": (12, 24),
"cost": (500000, 2000000),
"requirements": ["Breakthrough designation request", "More flexible clinical evidence", "Iterative FDA engagement", "Post-market data collection"]
}
}
# EU MDR pathway decision matrix
EU_MDR_PATHWAYS = {
"I": {
"pathway": "Self-declaration (Class I)",
"timeline": (2, 4),
"cost": (10000, 30000),
"requirements": ["Technical documentation", "EU Declaration of Conformity", "UDI assignment", "EUDAMED registration", "Authorized Representative (if non-EU)"]
},
"IIa": {
"pathway": "Notified Body assessment (Class IIa)",
"timeline": (12, 18),
"cost": (80000, 200000),
"requirements": ["QMS certification (ISO 13485)", "Technical documentation", "Clinical evaluation", "Notified Body audit", "Post-market surveillance plan"]
},
"IIb": {
"pathway": "Notified Body assessment (Class IIb)",
"timeline": (15, 24),
"cost": (150000, 400000),
"requirements": ["Full QMS certification", "Comprehensive technical documentation", "Clinical evaluation (may need clinical investigation)", "Type examination or product verification", "Notified Body scrutiny"]
},
"III": {
"pathway": "Notified Body assessment (Class III)",
"timeline": (18, 30),
"cost": (300000, 800000),
"requirements": ["Full QMS certification", "Complete technical documentation", "Clinical investigation (typically required)", "Notified Body clinical evaluation review", "Scrutiny procedure (possible)", "PMCF plan"]
}
}
def __init__(self):
self.analysis_warnings = []
def analyze_fda_pathway(self, device: DeviceProfile) -> PathwayOption:
"""Determine optimal FDA pathway."""
device_class = device.device_class.upper().replace("IIA", "II").replace("IIB", "II")
if device_class == "I":
pathway_data = self.FDA_PATHWAYS["I"]
return PathwayOption(
pathway_name=pathway_data["pathway"],
market="US-FDA",
estimated_timeline_months=pathway_data["timeline"],
estimated_cost_usd=pathway_data["cost"],
key_requirements=pathway_data["requirements"],
advantages=["Fastest path to market", "Minimal regulatory burden", "No premarket submission required (if exempt)"],
risks=["Limited to exempt product codes", "Still requires GMP compliance"],
recommendation_level="Recommended"
)
elif device_class == "III" or device.implantable or device.life_sustaining:
if device.novel_technology:
pathway_data = self.FDA_PATHWAYS["III-breakthrough"]
rec_level = "Recommended" if device.novel_technology else "Alternative"
else:
pathway_data = self.FDA_PATHWAYS["III"]
rec_level = "Recommended"
else: # Class II
if device.predicate_available and not device.novel_technology:
pathway_data = self.FDA_PATHWAYS["II"]
rec_level = "Recommended"
else:
pathway_data = self.FDA_PATHWAYS["II-novel"]
rec_level = "Recommended"
return PathwayOption(
pathway_name=pathway_data["pathway"],
market="US-FDA",
estimated_timeline_months=pathway_data["timeline"],
estimated_cost_usd=pathway_data["cost"],
key_requirements=pathway_data["requirements"],
advantages=self._get_fda_advantages(pathway_data["pathway"], device),
risks=self._get_fda_risks(pathway_data["pathway"], device),
recommendation_level=rec_level
)
def analyze_eu_mdr_pathway(self, device: DeviceProfile) -> PathwayOption:
"""Determine optimal EU MDR pathway."""
device_class = device.device_class.lower().replace("iia", "IIa").replace("iib", "IIb")
if device_class in ["i", "1"]:
pathway_data = self.EU_MDR_PATHWAYS["I"]
class_key = "I"
elif device_class in ["iia", "2a"]:
pathway_data = self.EU_MDR_PATHWAYS["IIa"]
class_key = "IIa"
elif device_class in ["iib", "2b"]:
pathway_data = self.EU_MDR_PATHWAYS["IIb"]
class_key = "IIb"
else:
pathway_data = self.EU_MDR_PATHWAYS["III"]
class_key = "III"
# Adjust for implantables
if device.implantable and class_key in ["IIa", "IIb"]:
pathway_data = self.EU_MDR_PATHWAYS["III"]
self.analysis_warnings.append(
f"Implantable devices are typically upclassified to Class III under EU MDR"
)
return PathwayOption(
pathway_name=pathway_data["pathway"],
market="EU-MDR",
estimated_timeline_months=pathway_data["timeline"],
estimated_cost_usd=pathway_data["cost"],
key_requirements=pathway_data["requirements"],
advantages=self._get_eu_advantages(pathway_data["pathway"], device),
risks=self._get_eu_risks(pathway_data["pathway"], device),
recommendation_level="Recommended"
)
def _get_fda_advantages(self, pathway: str, device: DeviceProfile) -> List[str]:
advantages = []
if "510(k)" in pathway:
advantages.extend([
"Well-established pathway with clear guidance",
"Predictable review timeline",
"Lower clinical evidence requirements vs PMA"
])
if device.predicate_available:
advantages.append("Predicate device identified - streamlined review")
elif "De Novo" in pathway:
advantages.extend([
"Creates new predicate for future 510(k) submissions",
"Appropriate for novel low-moderate risk devices",
"Can result in Class I or II classification"
])
elif "PMA" in pathway:
advantages.extend([
"Strongest FDA approval - highest market credibility",
"Difficult for competitors to challenge",
"May qualify for breakthrough device benefits"
])
elif "Breakthrough" in pathway:
advantages.extend([
"Priority review and interactive FDA engagement",
"Flexible clinical evidence requirements",
"Faster iterative development with FDA feedback"
])
return advantages
def _get_fda_risks(self, pathway: str, device: DeviceProfile) -> List[str]:
risks = []
if "510(k)" in pathway:
risks.extend([
"Predicate device may be challenged",
"SE determination can be subjective"
])
if device.software_component:
risks.append("Software documentation requirements increasing (Cybersecurity, AI/ML)")
elif "De Novo" in pathway:
risks.extend([
"Less predictable than 510(k)",
"May require more clinical data than expected",
"New special controls may be imposed"
])
elif "PMA" in pathway:
risks.extend([
"Very expensive and time-consuming",
"Clinical trial risks and delays",
"Post-approval study requirements"
])
if device.ai_ml_component:
risks.append("AI/ML components face evolving regulatory requirements")
return risks
def _get_eu_advantages(self, pathway: str, device: DeviceProfile) -> List[str]:
advantages = ["Access to entire EU/EEA market (27+ countries)"]
if "Self-declaration" in pathway:
advantages.extend([
"No Notified Body involvement required",
"Fastest path to EU market",
"Lowest cost option"
])
elif "IIa" in pathway:
advantages.append("Moderate regulatory burden with broad market access")
elif "IIb" in pathway or "III" in pathway:
advantages.extend([
"Strong market credibility with NB certification",
"Recognized globally for regulatory quality"
])
return advantages
def _get_eu_risks(self, pathway: str, device: DeviceProfile) -> List[str]:
risks = []
if "Self-declaration" not in pathway:
risks.extend([
"Limited Notified Body capacity - long wait times",
"Notified Body costs increasing under MDR"
])
risks.append("MDR transition still creating uncertainty")
if device.software_component:
risks.append("EU AI Act may apply to AI/ML medical devices")
return risks
def determine_optimal_sequence(self, pathways: List[PathwayOption], device: DeviceProfile) -> List[str]:
"""Determine optimal submission sequence across markets."""
# General principle: Start with fastest/cheapest, use data for subsequent submissions
sequence = []
# Sort by timeline (fastest first)
sorted_pathways = sorted(pathways, key=lambda p: p.estimated_timeline_months[0])
# FDA first if 510(k) - well recognized globally
fda_pathway = next((p for p in pathways if p.market == "US-FDA"), None)
eu_pathway = next((p for p in pathways if p.market == "EU-MDR"), None)
if fda_pathway and "510(k)" in fda_pathway.pathway_name:
sequence.append("1. US-FDA 510(k) first - clearance recognized globally, data reusable")
if eu_pathway:
sequence.append("2. EU-MDR - use FDA data in clinical evaluation")
elif eu_pathway and "Self-declaration" in eu_pathway.pathway_name:
sequence.append("1. EU-MDR (Class I self-declaration) - fastest market entry")
if fda_pathway:
sequence.append("2. US-FDA - use EU experience and data")
else:
for i, p in enumerate(sorted_pathways, 1):
sequence.append(f"{i}. {p.market} ({p.pathway_name})")
return sequence
def analyze(self, device: DeviceProfile) -> PathwayAnalysis:
"""Perform complete pathway analysis."""
self.analysis_warnings = []
pathways = []
for market in device.target_markets:
if "FDA" in market or "US" in market:
pathways.append(self.analyze_fda_pathway(device))
elif "MDR" in market or "EU" in market:
pathways.append(self.analyze_eu_mdr_pathway(device))
# Additional markets can be added here
sequence = self.determine_optimal_sequence(pathways, device)
total_timeline_min = sum(p.estimated_timeline_months[0] for p in pathways)
total_timeline_max = sum(p.estimated_timeline_months[1] for p in pathways)
total_cost_min = sum(p.estimated_cost_usd[0] for p in pathways)
total_cost_max = sum(p.estimated_cost_usd[1] for p in pathways)
csf = [
"Early engagement with regulators (Pre-Sub/Scientific Advice)",
"Robust QMS (ISO 13485) in place before submissions",
"Clinical evidence strategy aligned with target markets",
"Cybersecurity and software documentation (if applicable)"
]
if device.ai_ml_component:
csf.append("AI/ML transparency and bias documentation")
return PathwayAnalysis(
device=device,
recommended_pathways=pathways,
optimal_sequence=sequence,
total_timeline_months=(total_timeline_min, total_timeline_max),
total_estimated_cost=(total_cost_min, total_cost_max),
critical_success_factors=csf,
warnings=self.analysis_warnings
)
def format_analysis_text(analysis: PathwayAnalysis) -> str:
"""Format analysis as readable text report."""
lines = [
"=" * 70,
"REGULATORY PATHWAY ANALYSIS REPORT",
"=" * 70,
f"Device: {analysis.device.device_name}",
f"Intended Use: {analysis.device.intended_use}",
f"Device Class: {analysis.device.device_class}",
f"Target Markets: {', '.join(analysis.device.target_markets)}",
"",
"DEVICE CHARACTERISTICS",
"-" * 40,
f" Novel Technology: {'Yes' if analysis.device.novel_technology else 'No'}",
f" Predicate Available: {'Yes' if analysis.device.predicate_available else 'No'}",
f" Implantable: {'Yes' if analysis.device.implantable else 'No'}",
f" Life-Sustaining: {'Yes' if analysis.device.life_sustaining else 'No'}",
f" Software/AI Component: {'Yes' if analysis.device.software_component or analysis.device.ai_ml_component else 'No'}",
f" Sterile: {'Yes' if analysis.device.sterile else 'No'}",
"",
"RECOMMENDED PATHWAYS",
"-" * 40,
]
for pathway in analysis.recommended_pathways:
lines.extend([
"",
f" [{pathway.market}] {pathway.pathway_name}",
f" Recommendation: {pathway.recommendation_level}",
f" Timeline: {pathway.estimated_timeline_months[0]}-{pathway.estimated_timeline_months[1]} months",
f" Estimated Cost: ${pathway.estimated_cost_usd[0]:,} - ${pathway.estimated_cost_usd[1]:,}",
f" Key Requirements:",
])
for req in pathway.key_requirements:
lines.append(f" • {req}")
lines.append(f" Advantages:")
for adv in pathway.advantages:
lines.append(f" + {adv}")
lines.append(f" Risks:")
for risk in pathway.risks:
lines.append(f" ! {risk}")
lines.extend([
"",
"OPTIMAL SUBMISSION SEQUENCE",
"-" * 40,
])
for step in analysis.optimal_sequence:
lines.append(f" {step}")
lines.extend([
"",
"TOTAL ESTIMATES",
"-" * 40,
f" Combined Timeline: {analysis.total_timeline_months[0]}-{analysis.total_timeline_months[1]} months",
f" Combined Cost: ${analysis.total_estimated_cost[0]:,} - ${analysis.total_estimated_cost[1]:,}",
"",
"CRITICAL SUCCESS FACTORS",
"-" * 40,
])
for i, factor in enumerate(analysis.critical_success_factors, 1):
lines.append(f" {i}. {factor}")
if analysis.warnings:
lines.extend([
"",
"WARNINGS",
"-" * 40,
])
for warning in analysis.warnings:
lines.append(f" ⚠ {warning}")
lines.append("=" * 70)
return "\n".join(lines)
def interactive_mode():
"""Interactive device profiling."""
print("=" * 60)
print("Regulatory Pathway Analyzer - Interactive Mode")
print("=" * 60)
device = DeviceProfile(
device_name=input("\nDevice Name: ").strip(),
intended_use=input("Intended Use: ").strip(),
device_class=input("Device Class (I/IIa/IIb/III): ").strip(),
novel_technology=input("Novel technology? (y/n): ").strip().lower() == 'y',
predicate_available=input("Predicate device available? (y/n): ").strip().lower() == 'y',
implantable=input("Implantable? (y/n): ").strip().lower() == 'y',
life_sustaining=input("Life-sustaining? (y/n): ").strip().lower() == 'y',
software_component=input("Software component? (y/n): ").strip().lower() == 'y',
ai_ml_component=input("AI/ML component? (y/n): ").strip().lower() == 'y',
)
markets = input("Target markets (comma-separated, e.g., US-FDA,EU-MDR): ").strip()
if markets:
device.target_markets = [m.strip() for m in markets.split(",")]
analyzer = RegulatoryPathwayAnalyzer()
analysis = analyzer.analyze(device)
print("\n" + format_analysis_text(analysis))
def main():
parser = argparse.ArgumentParser(description="Regulatory Pathway Analyzer for Medical Devices")
parser.add_argument("--device-name", type=str, help="Device name")
parser.add_argument("--device-class", type=str, choices=["I", "IIa", "IIb", "III"], help="Device classification")
parser.add_argument("--predicate", type=str, choices=["yes", "no"], help="Predicate device available")
parser.add_argument("--novel", action="store_true", help="Novel technology")
parser.add_argument("--implantable", action="store_true", help="Implantable device")
parser.add_argument("--software", action="store_true", help="Software component")
parser.add_argument("--ai-ml", action="store_true", help="AI/ML component")
parser.add_argument("--market", type=str, default="all", help="Target market(s)")
parser.add_argument("--data", type=str, help="JSON file with device profile")
parser.add_argument("--output", choices=["text", "json"], default="text", help="Output format")
parser.add_argument("--interactive", action="store_true", help="Interactive mode")
args = parser.parse_args()
if args.interactive:
interactive_mode()
return
if args.data:
with open(args.data) as f:
data = json.load(f)
device = DeviceProfile(**data)
elif args.device_class:
device = DeviceProfile(
device_name=args.device_name or "Unnamed Device",
intended_use="Medical device",
device_class=args.device_class,
novel_technology=args.novel,
predicate_available=args.predicate == "yes" if args.predicate else True,
implantable=args.implantable,
software_component=args.software,
ai_ml_component=args.ai_ml,
)
if args.market != "all":
device.target_markets = [m.strip() for m in args.market.split(",")]
else:
# Demo mode
device = DeviceProfile(
device_name="SmartGlucose Monitor Pro",
intended_use="Continuous glucose monitoring for diabetes management",
device_class="II",
novel_technology=False,
predicate_available=True,
software_component=True,
ai_ml_component=True,
target_markets=["US-FDA", "EU-MDR"]
)
analyzer = RegulatoryPathwayAnalyzer()
analysis = analyzer.analyze(device)
if args.output == "json":
result = {
"device": asdict(analysis.device),
"pathways": [asdict(p) for p in analysis.recommended_pathways],
"optimal_sequence": analysis.optimal_sequence,
"total_timeline_months": list(analysis.total_timeline_months),
"total_estimated_cost": list(analysis.total_estimated_cost),
"critical_success_factors": analysis.critical_success_factors,
"warnings": analysis.warnings
}
print(json.dumps(result, indent=2))
else:
print(format_analysis_text(analysis))
if __name__ == "__main__":
main()
#!/usr/bin/env python3
"""
Regulatory Submission Tracking System
Automates monitoring and reporting of regulatory submission status
"""
import json
import datetime
from typing import Dict, List, Optional
from dataclasses import dataclass, asdict
from enum import Enum
class SubmissionType(Enum):
FDA_510K = "FDA_510K"
FDA_PMA = "FDA_PMA"
FDA_DE_NOVO = "FDA_DE_NOVO"
EU_MDR_CE = "EU_MDR_CE"
ISO_CERTIFICATION = "ISO_CERTIFICATION"
GLOBAL_REGULATORY = "GLOBAL_REGULATORY"
class SubmissionStatus(Enum):
PLANNING = "PLANNING"
IN_PREPARATION = "IN_PREPARATION"
SUBMITTED = "SUBMITTED"
UNDER_REVIEW = "UNDER_REVIEW"
ADDITIONAL_INFO_REQUESTED = "ADDITIONAL_INFO_REQUESTED"
APPROVED = "APPROVED"
REJECTED = "REJECTED"
WITHDRAWN = "WITHDRAWN"
@dataclass
class RegulatorySubmission:
submission_id: str
product_name: str
submission_type: SubmissionType
submission_status: SubmissionStatus
target_market: str
submission_date: Optional[datetime.date] = None
target_approval_date: Optional[datetime.date] = None
actual_approval_date: Optional[datetime.date] = None
regulatory_authority: str = ""
responsible_person: str = ""
notes: str = ""
last_updated: datetime.date = datetime.date.today()
class RegulatoryTracker:
def __init__(self, data_file: str = "regulatory_submissions.json"):
self.data_file = data_file
self.submissions: Dict[str, RegulatorySubmission] = {}
self.load_data()
def load_data(self):
"""Load existing submission data from JSON file"""
try:
with open(self.data_file, 'r') as f:
data = json.load(f)
for sub_id, sub_data in data.items():
# Convert date strings back to date objects
for date_field in ['submission_date', 'target_approval_date',
'actual_approval_date', 'last_updated']:
if sub_data.get(date_field):
sub_data[date_field] = datetime.datetime.strptime(
sub_data[date_field], '%Y-%m-%d').date()
# Convert enums
sub_data['submission_type'] = SubmissionType(sub_data['submission_type'])
sub_data['submission_status'] = SubmissionStatus(sub_data['submission_status'])
self.submissions[sub_id] = RegulatorySubmission(**sub_data)
except FileNotFoundError:
print(f"No existing data file found. Starting fresh.")
except Exception as e:
print(f"Error loading data: {e}")
def save_data(self):
"""Save submission data to JSON file"""
data = {}
for sub_id, submission in self.submissions.items():
sub_dict = asdict(submission)
# Convert date objects to strings
for date_field in ['submission_date', 'target_approval_date',
'actual_approval_date', 'last_updated']:
if sub_dict.get(date_field):
sub_dict[date_field] = sub_dict[date_field].strftime('%Y-%m-%d')
# Convert enums to strings
sub_dict['submission_type'] = sub_dict['submission_type'].value
sub_dict['submission_status'] = sub_dict['submission_status'].value
data[sub_id] = sub_dict
with open(self.data_file, 'w') as f:
json.dump(data, f, indent=2)
def add_submission(self, submission: RegulatorySubmission):
"""Add new regulatory submission"""
self.submissions[submission.submission_id] = submission
self.save_data()
print(f"Added submission: {submission.submission_id}")
def update_submission_status(self, submission_id: str,
new_status: SubmissionStatus,
notes: str = ""):
"""Update submission status"""
if submission_id in self.submissions:
self.submissions[submission_id].submission_status = new_status
self.submissions[submission_id].notes = notes
self.submissions[submission_id].last_updated = datetime.date.today()
self.save_data()
print(f"Updated {submission_id} status to {new_status.value}")
else:
print(f"Submission {submission_id} not found")
def get_submissions_by_status(self, status: SubmissionStatus) -> List[RegulatorySubmission]:
"""Get all submissions with specific status"""
return [sub for sub in self.submissions.values() if sub.submission_status == status]
def get_overdue_submissions(self) -> List[RegulatorySubmission]:
"""Get submissions that are overdue"""
today = datetime.date.today()
overdue = []
for submission in self.submissions.values():
if (submission.target_approval_date and
submission.target_approval_date < today and
submission.submission_status not in [SubmissionStatus.APPROVED,
SubmissionStatus.REJECTED,
SubmissionStatus.WITHDRAWN]):
overdue.append(submission)
return overdue
def generate_status_report(self) -> str:
"""Generate comprehensive status report"""
report = []
report.append("REGULATORY SUBMISSION STATUS REPORT")
report.append("=" * 50)
report.append(f"Generated: {datetime.date.today()}")
report.append("")
# Summary by status
status_counts = {}
for status in SubmissionStatus:
count = len(self.get_submissions_by_status(status))
if count > 0:
status_counts[status] = count
report.append("SUBMISSION STATUS SUMMARY:")
for status, count in status_counts.items():
report.append(f" {status.value}: {count}")
report.append("")
# Overdue submissions
overdue = self.get_overdue_submissions()
if overdue:
report.append("OVERDUE SUBMISSIONS:")
for submission in overdue:
days_overdue = (datetime.date.today() - submission.target_approval_date).days
report.append(f" {submission.submission_id} - {days_overdue} days overdue")
report.append("")
# Active submissions requiring attention
active_statuses = [SubmissionStatus.SUBMITTED, SubmissionStatus.UNDER_REVIEW,
SubmissionStatus.ADDITIONAL_INFO_REQUESTED]
active_submissions = []
for status in active_statuses:
active_submissions.extend(self.get_submissions_by_status(status))
if active_submissions:
report.append("ACTIVE SUBMISSIONS REQUIRING ATTENTION:")
for submission in active_submissions:
report.append(f" {submission.submission_id} - {submission.product_name}")
report.append(f" Status: {submission.submission_status.value}")
report.append(f" Target Date: {submission.target_approval_date}")
report.append(f" Authority: {submission.regulatory_authority}")
report.append("")
return "\n".join(report)
def main():
"""Main function for command-line usage"""
tracker = RegulatoryTracker()
# Generate and print status report
print(tracker.generate_status_report())
# Example: Add a new submission
# new_submission = RegulatorySubmission(
# submission_id="SUB-2024-001",
# product_name="HealthTech Device X",
# submission_type=SubmissionType.FDA_510K,
# submission_status=SubmissionStatus.PLANNING,
# target_market="United States",
# target_approval_date=datetime.date(2024, 12, 31),
# regulatory_authority="FDA",
# responsible_person="John Doe"
# )
# tracker.add_submission(new_submission)
if __name__ == "__main__":
main()
Related skills
How it compares
Pick regulatory-affairs-head over generic documentation skills when submissions must follow EU MDR 2017/745 medical device conformity paths.
FAQ
Which EU regulation does regulatory-affairs-head cover?
regulatory-affairs-head addresses EU MDR 2017/745 for medical device software and hardware. It structures classification, conformity assessment routes, Annex II technical documentation, Declaration of Conformity, and UDI registration requirements.
What device classes does regulatory-affairs-head address?
regulatory-affairs-head covers Class I self-certification under Annex II, Class IIa notified-body routes under Annex III Module C2 plus Annex V, and Class IIb routes under Annex III Module B plus C or D with type or full quality assurance.
Is Regulatory Affairs Head safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.