本文へ移動
cccskills
無料GitHub で公開

fda-consultant-specialist

FDA regulatory consultant for medical device companies. Provides 510(k)/PMA/De Novo pathway guidance, QMSR (21 CFR 820, which incorporates ISO 13485:2016 by reference since 2026-02-02; formerly QSR) compliance, HIPAA assessments, and device cybersecurity. Use when user mentions FDA submission, 510(k), PMA, De Novo, QMSR, QSR, ISO 13485 for FDA, premarket, predicate device, substantial equivalence, HIPAA medical device, or FDA cybersecurity.

インストール方法を見る

含まれるファイル(9)

  • SKILL.md11.8 KB
  • references/device_cybersecurity_guidance.md17.9 KB
  • references/fda_capa_requirements.md21.9 KB
  • references/fda_submission_guide.md11.5 KB
  • references/hipaa_compliance_framework.md18.8 KB
  • references/qsr_compliance_requirements.md21.3 KB
  • scripts/fda_submission_tracker.py19.2 KB
  • scripts/hipaa_risk_assessment.py22.6 KB
  • scripts/qsr_compliance_checker.py26.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

FDA Consultant Specialist

FDA regulatory consulting for medical device manufacturers covering submission pathways, the Quality Management System Regulation (QMSR, 21 CFR Part 820 — formerly the QSR), HIPAA compliance, and device cybersecurity requirements.

Table of Contents


FDA Pathway Selection

Determine the appropriate FDA regulatory pathway based on device classification and predicate availability.

Decision Framework

Predicate device exists?
├── YES → Substantially equivalent?
│   ├── YES → 510(k) Pathway
│   │   ├── No design changes → Abbreviated 510(k)
│   │   ├── Manufacturing only → Special 510(k)
│   │   └── Design/performance → Traditional 510(k)
│   └── NO → PMA or De Novo
└── NO → Novel device?
    ├── Low-to-moderate risk → De Novo
    └── High risk (Class III) → PMA

Pathway Comparison

PathwayWhen to UseTimelineUser Fee (FY2024)
510(k) TraditionalPredicate exists, design changes90 days$21,760 (FY2024)
510(k) SpecialManufacturing changes only30 days$21,760 (FY2024)
510(k) AbbreviatedGuidance/standard conformance30 days$21,760 (FY2024)
De NovoNovel, low-moderate risk150 days$134,676 (FY2024)
PMAClass III, no predicate180+ days$425,000+ (FY2024)

User fees are set annually under MDUFA. Verify current-fiscal-year fees at fda.gov (MDUFA user fee schedule) before budgeting; small-business rates differ.

Pre-Submission Strategy

  1. Identify product code and classification
  2. Search 510(k) database for predicates
  3. Assess substantial equivalence feasibility
  4. Prepare Q-Sub questions for FDA
  5. Schedule Pre-Sub meeting if needed

Reference: See fda_submission_guide.md for pathway decision matrices and submission requirements.


510(k) Submission Process

Workflow

Phase 1: Planning
├── Step 1: Identify predicate device(s)
├── Step 2: Compare intended use and technology
├── Step 3: Determine testing requirements
└── Checkpoint: SE argument feasible?

Phase 2: Preparation
├── Step 4: Complete performance testing
├── Step 5: Prepare device description
├── Step 6: Document SE comparison
├── Step 7: Finalize labeling
└── Checkpoint: All required sections complete?

Phase 3: Submission
├── Step 8: Assemble submission package
├── Step 9: Submit via eSTAR
├── Step 10: Track acknowledgment
└── Checkpoint: Submission accepted?

Phase 4: Review
├── Step 11: Monitor review status
├── Step 12: Respond to AI requests
├── Step 13: Receive decision
└── Verification: SE letter received?

Required Sections (21 CFR 807.87)

SectionContent
Cover LetterSubmission type, device ID, contact info
Form 3514CDRH premarket review cover sheet
Device DescriptionPhysical description, principles of operation
Indications for UseForm 3881, patient population, use environment
SE ComparisonSide-by-side comparison with predicate
Performance TestingBench, biocompatibility, electrical safety
Software DocumentationLevel of concern, hazard analysis (IEC 62304)
LabelingIFU, package labels, warnings
510(k) SummaryPublic summary of submission

Common RTA Issues

IssuePrevention
Missing user feeVerify payment before submission
Incomplete Form 3514Review all fields, ensure signature
No predicate identifiedConfirm K-number in FDA database
Inadequate SE comparisonAddress all technological characteristics

QMSR Compliance (formerly QSR)

Quality Management System Regulation (QMSR) requirements for medical device manufacturers under 21 CFR Part 820.

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 (820.20–820.198). Those subsection numbers are historical and no longer exist in the CFR; the corresponding requirements now flow from ISO 13485:2016 clauses plus the retained/renumbered sections 820.10 (requirements, incl. the ISO 13485 incorporation), 820.35 (records), and 820.45 (device labeling and packaging controls). 21 CFR Parts 801, 803, 806, and 830 are unchanged. Legacy QSR numbers below are kept only as a familiar index, each mapped to its current ISO 13485 clause.

Key Quality Subsystems (legacy QSR index → current ISO 13485:2016 clause)

Legacy QSR Section (historical, pre-2026)TitleCurrent authority under QMSRFocus
820.20Management ResponsibilityISO 13485 §5.1, 5.5, 5.6Quality policy, org structure, management review
820.30Design ControlsISO 13485 §7.3Input, output, review, verification, validation
820.40Document ControlsISO 13485 §4.2.4Approval, distribution, change control
820.50Purchasing ControlsISO 13485 §7.4Supplier qualification, purchasing data
820.70Production ControlsISO 13485 §6.3, 6.4, 7.5Process validation, environmental controls
820.100CAPAISO 13485 §8.5.2, 8.5.3Root cause analysis, corrective actions
820.181Device Master RecordISO 13485 §4.2.3 (medical device file) + 21 CFR 820.35Specifications, procedures, acceptance criteria

Design Controls Workflow (ISO 13485 §7.3; legacy QSR 820.30)

Step 1: Design Input
└── Capture user needs, intended use, regulatory requirements
    Verification: Inputs reviewed and approved?

Step 2: Design Output
└── Create specifications, drawings, software architecture
    Verification: Outputs traceable to inputs?

Step 3: Design Review
└── Conduct reviews at each phase milestone
    Verification: Review records with signatures?

Step 4: Design Verification
└── Perform testing against specifications
    Verification: All tests pass acceptance criteria?

Step 5: Design Validation
└── Confirm device meets user needs in actual use conditions
    Verification: Validation report approved?

Step 6: Design Transfer
└── Release to production with DMR complete
    Verification: Transfer checklist complete?

CAPA Process (ISO 13485 §8.5.2/8.5.3; legacy QSR 820.100)

  1. Identify: Document nonconformity or potential problem
  2. Investigate: Perform root cause analysis (5 Whys, Fishbone)
  3. Plan: Define corrective/preventive actions
  4. Implement: Execute actions, update documentation
  5. Verify: Confirm implementation complete
  6. Effectiveness: Monitor for recurrence (30-90 days)
  7. Close: Management approval and closure

Reference: See qsr_compliance_requirements.md for the historical QSR structure with full QMSR/ISO 13485:2016 clause mapping.


HIPAA for Medical Devices

HIPAA requirements for devices that create, store, transmit, or access Protected Health Information (PHI).

Applicability

Device TypeHIPAA Applies
Standalone diagnostic (no data transmission)No
Connected device transmitting patient dataYes
Device with EHR integrationYes
SaMD storing patient informationYes
Wellness app (no diagnosis)Only if stores PHI

Required Safeguards

Administrative (§164.308)
├── Security officer designation
├── Risk analysis and management
├── Workforce training
├── Incident response procedures
└── Business associate agreements

Physical (§164.310)
├── Facility access controls
├── Workstation security
└── Device disposal procedures

Technical (§164.312)
├── Access control (unique IDs, auto-logoff)
├── Audit controls (logging)
├── Integrity controls (checksums, hashes)
├── Authentication (MFA recommended)
└── Transmission security (TLS 1.2+)

Risk Assessment Steps

  1. Inventory all systems handling ePHI
  2. Document data flows (collection, storage, transmission)
  3. Identify threats and vulnerabilities
  4. Assess likelihood and impact
  5. Determine risk levels
  6. Implement controls
  7. Document residual risk

Reference: See hipaa_compliance_framework.md for implementation checklists and BAA templates.


Device Cybersecurity

FDA cybersecurity requirements for connected medical devices.

Premarket Requirements

ElementDescription
Threat ModelSTRIDE analysis, attack trees, trust boundaries
Security ControlsAuthentication, encryption, access control
SBOMSoftware Bill of Materials (CycloneDX or SPDX)
Security TestingPenetration testing, vulnerability scanning
Vulnerability PlanDisclosure process, patch management

Device Tier Classification

Tier 1 (Higher Risk):

  • Connects to network/internet
  • Cybersecurity incident could cause patient harm

Tier 2 (Standard Risk):

  • All other connected devices

Postmarket Obligations

  1. Monitor NVD and ICS-CERT for vulnerabilities
  2. Assess applicability to device components
  3. Develop and test patches
  4. Communicate with customers
  5. Report to FDA per guidance

Coordinated Vulnerability Disclosure

Researcher Report
    ↓
Acknowledgment (48 hours)
    ↓
Initial Assessment (5 days)
    ↓
Fix Development
    ↓
Coordinated Public Disclosure

Reference: See device_cybersecurity_guidance.md for SBOM format examples and threat modeling templates.


Resources

scripts/

ScriptPurpose
fda_submission_tracker.pyTrack 510(k)/PMA/De Novo submission milestones and timelines
qsr_compliance_checker.pyAssess QMS documentation against the legacy-QSR checklist mapped to ISO 13485:2016 (QMSR)
hipaa_risk_assessment.pyEvaluate HIPAA safeguards in medical device software

references/

FileContent
fda_submission_guide.md510(k), De Novo, PMA submission requirements and checklists
qsr_compliance_requirements.mdHistorical QSR structure with QMSR/ISO 13485:2016 mapping, implementation templates
hipaa_compliance_framework.mdHIPAA Security Rule safeguards and BAA requirements
device_cybersecurity_guidance.mdFDA cybersecurity requirements, SBOM, threat modeling
fda_capa_requirements.mdCAPA process, root cause analysis, effectiveness verification

Usage Examples

# Track FDA submission status
python scripts/fda_submission_tracker.py /path/to/project --type 510k

# Assess QMS documentation (legacy QSR section keys, mapped to ISO 13485 under QMSR)
python scripts/qsr_compliance_checker.py /path/to/project --section 820.30  # legacy checklist key = ISO 13485 §7.3 (design & development)

# Run HIPAA risk assessment
python scripts/hipaa_risk_assessment.py /path/to/project --category technical

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Accessibility audit skill for scanning, fixing, and verifying WCAG 2.2 Level A and AA compliance across React, Next.js, Vue, Angular, Svelte, and plain HTML codebases. Use when auditing accessibility, fixing a11y violations, checking color contrast, generating compliance reports, or integrating accessibility checks into CI/CD pipelines.

日本語の概要は準備中です。原文の説明を表示しています。

alirezarezvani/claude-skills2.8万2026年8月30日 更新

When the user wants to plan, design, or implement an A/B test or experiment. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "conversion experiment," "statistical significance," or "test this." For tracking implementation, see analytics-tracking.

日本語の概要は準備中です。原文の説明を表示しています。

alirezarezvani/claude-skills2.8万2026年8月30日 更新

When the user needs to generate, iterate, or scale ad creative for paid advertising. Use when they say 'write ad copy,' 'generate headlines,' 'create ad variations,' 'bulk creative,' 'iterate on ads,' 'ad copy validation,' 'RSA headlines,' 'Meta ad copy,' 'LinkedIn ad,' or 'creative testing.' This is pure creative production — distinct from paid-ads (campaign strategy). Use ad-creative when you need the copy, not the campaign plan.

日本語の概要は準備中です。原文の説明を表示しています。

alirezarezvani/claude-skills2.8万2026年8月30日 更新

Adversarial code review that breaks the self-review monoculture. Use when you want a genuinely critical review of recent changes, before merging a PR, or when you suspect Claude is being too agreeable about code quality. Forces perspective shifts through hostile reviewer personas that catch blind spots the author's mental model shares with the reviewer.

日本語の概要は準備中です。原文の説明を表示しています。

alirezarezvani/claude-skills2.8万2026年8月30日 更新

aeo

無料

Answer Engine Optimization (AEO) skill — optimize content to be cited by AI language models (ChatGPT, Perplexity, Claude, Gemini, Mistral) as authoritative sources. Distinct from SEO — AEO optimizes for citation in LLM-generated responses, not search rankings. Use when planning content for AI-first search audiences, auditing existing content for E-E-A-T signals, tracking which pages get cited by which LLMs, or building a citation-friendly content strategy. Triggers — 'AEO audit', 'optimize for ChatGPT', 'get cited by Perplexity', 'LLM citation strategy', 'answer engine optimization', 'content for AI search', 'E-E-A-T audit'. Output is a markdown audit report (default) or JSON for pipeline integration. Stdlib-only Python tools.

日本語の概要は準備中です。原文の説明を表示しています。

alirezarezvani/claude-skills2.8万2026年8月30日 更新

Mint a tamper-evident, post-quantum-signed receipt for a consequential agent action (deploy, delete, pay, grant-access, model decision) so it can be verified later from the certificate alone. Use when an autonomous agent takes a side-effecting action that may need to be proven later, or when satisfying EU AI Act Article 12 record-keeping. Three decisions: whether an action needs a receipt, minting it, verifying it. Signing is delegated to the open-source OpenAgentOntology package. Not after-the-fact log analysis; not a hosted notary; not a legal opinion.

日本語の概要は準備中です。原文の説明を表示しています。

alirezarezvani/claude-skills2.8万2026年8月30日 更新

alirezarezvani のスキルをすべて見る

このスキルの問題を報告する