← 返回 Skills 市场
alirezarezvani

Fda Consultant Specialist

作者 Alireza Rezvani · GitHub ↗ · v2.1.1 · MIT-0
cross-platform ⚠ suspicious
1626
总下载
0
收藏
6
当前安装
2
版本数
在 OpenClaw 中安装
/install fda-consultant-specialist
功能描述
FDA regulatory consultant for medical device companies. Provides 510(k)/PMA/De Novo pathway guidance, QSR (21 CFR 820) compliance, HIPAA assessments, and dev...
使用说明 (SKILL.md)

FDA Consultant Specialist

FDA regulatory consulting for medical device manufacturers covering submission pathways, Quality System Regulation (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

Pathway When to Use Timeline Cost
510(k) Traditional Predicate exists, design changes 90 days $21,760
510(k) Special Manufacturing changes only 30 days $21,760
510(k) Abbreviated Guidance/standard conformance 30 days $21,760
De Novo Novel, low-moderate risk 150 days $134,676
PMA Class III, no predicate 180+ days $425,000+

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)

Section Content
Cover Letter Submission type, device ID, contact info
Form 3514 CDRH premarket review cover sheet
Device Description Physical description, principles of operation
Indications for Use Form 3881, patient population, use environment
SE Comparison Side-by-side comparison with predicate
Performance Testing Bench, biocompatibility, electrical safety
Software Documentation Level of concern, hazard analysis (IEC 62304)
Labeling IFU, package labels, warnings
510(k) Summary Public summary of submission

Common RTA Issues

Issue Prevention
Missing user fee Verify payment before submission
Incomplete Form 3514 Review all fields, ensure signature
No predicate identified Confirm K-number in FDA database
Inadequate SE comparison Address all technological characteristics

QSR Compliance

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

Key Subsystems

Section Title Focus
820.20 Management Responsibility Quality policy, org structure, management review
820.30 Design Controls Input, output, review, verification, validation
820.40 Document Controls Approval, distribution, change control
820.50 Purchasing Controls Supplier qualification, purchasing data
820.70 Production Controls Process validation, environmental controls
820.100 CAPA Root cause analysis, corrective actions
820.181 Device Master Record Specifications, procedures, acceptance criteria

Design Controls Workflow (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 (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 detailed QSR implementation guidance.


HIPAA for Medical Devices

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

Applicability

Device Type HIPAA Applies
Standalone diagnostic (no data transmission) No
Connected device transmitting patient data Yes
Device with EHR integration Yes
SaMD storing patient information Yes
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

Element Description
Threat Model STRIDE analysis, attack trees, trust boundaries
Security Controls Authentication, encryption, access control
SBOM Software Bill of Materials (CycloneDX or SPDX)
Security Testing Penetration testing, vulnerability scanning
Vulnerability Plan Disclosure 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/

Script Purpose
fda_submission_tracker.py Track 510(k)/PMA/De Novo submission milestones and timelines
qsr_compliance_checker.py Assess 21 CFR 820 compliance against project documentation
hipaa_risk_assessment.py Evaluate HIPAA safeguards in medical device software

references/

File Content
fda_submission_guide.md 510(k), De Novo, PMA submission requirements and checklists
qsr_compliance_requirements.md 21 CFR 820 implementation guide with templates
hipaa_compliance_framework.md HIPAA Security Rule safeguards and BAA requirements
device_cybersecurity_guidance.md FDA cybersecurity requirements, SBOM, threat modeling
fda_capa_requirements.md CAPA process, root cause analysis, effectiveness verification

Usage Examples

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

# Assess QSR compliance
python scripts/qsr_compliance_checker.py /path/to/project --section 820.30

# Run HIPAA risk assessment
python scripts/hipaa_risk_assessment.py /path/to/project --category technical
安全使用建议
The human-readable guidance and reference docs are consistent with an FDA consultant skill, but you should NOT install or enable this skill without first inspecting the three bundled Python scripts. Specifically: 1) Open scripts/fda_submission_tracker.py, scripts/hipaa_risk_assessment.py, and scripts/qsr_compliance_checker.py and search for: network calls (requests, urllib, http, socket), subprocess usage, os.environ access, file system paths (e.g., /etc, ~/, /var), hardcoded URLs or credentials, or obfuscated/encoded strings. 2) If you lack the ability to audit code, request the source from the publisher and ask for provenance (who authored it, version control URL, license). 3) Run the scripts in an isolated sandbox/container with network disabled to observe behavior before granting the agent access to any environment containing PHI or secrets. 4) If you plan to allow autonomous invocation, be extra cautious: autonomous execution + unknown scripts increases blast radius. If the scripts are benign (only produce templates/checklists and local reports) the skill is likely safe; if they contact external endpoints or read environment variables/PHI, consider rejecting or requiring code changes. Because the actual script contents were not provided in the SKILL.md excerpt, my assessment is medium-confidence — reviewing the three Python files is the key next step.
功能分析
Type: OpenClaw Skill Name: fda-consultant-specialist Version: 2.1.1 The fda-consultant-specialist skill bundle is a legitimate regulatory compliance tool for medical device manufacturers. The included Python scripts (fda_submission_tracker.py, hipaa_risk_assessment.py, and qsr_compliance_checker.py) perform local file system analysis to track milestones and identify compliance gaps based on predefined patterns. No evidence of data exfiltration, network activity, or malicious execution was found; the scripts use standard libraries and operate strictly on the provided project directory.
能力评估
Purpose & Capability
The name, description, and included reference documents align with an FDA regulatory consultant skill. There are no declared environment variables, binaries, or config paths that are unrelated to the stated purpose. The included guidance and references (510(k), QSR, HIPAA, cybersecurity) are appropriate for the described function.
Instruction Scope
The SKILL.md content (the runtime instructions) appears narrowly scoped to providing regulatory guidance and checklists and does not direct the agent to read system files, environment variables, or external endpoints. However, the skill bundle contains three Python scripts (fda_submission_tracker.py, hipaa_risk_assessment.py, qsr_compliance_checker.py). The SKILL.md does not explicitly describe how/when these scripts will be executed or what data they access, which is a gap between instructions and included code.
Install Mechanism
No install spec is provided (instruction-only install), so nothing additional is automatically downloaded or written to disk during install. This lowers risk compared with skills that fetch remote archives or install packages at runtime.
Credentials
The skill does not request environment variables, credentials, or config paths. That is proportionate to a consulting/advisory skill. The only potential concern is if the included scripts attempt to access secrets or PHI at runtime — that behavior is not observable from the manifest and must be audited in the script code.
Persistence & Privilege
always is false and the skill does not request any elevated or persistent system privileges. Autonomous invocation is allowed (the platform default), which is normal for skills; this by itself is not a red flag.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install fda-consultant-specialist
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /fda-consultant-specialist 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v2.1.1
v2.1.1: optimization, reference splits
v1.0.0
FDA Consultant Specialist v1.0.0 - Initial release providing FDA regulatory consulting for medical device companies. - Offers guidance on 510(k), PMA, and De Novo submission pathways, including decision frameworks and comparison tables. - Includes step-by-step processes for 510(k) submissions and outlines required documentation. - Covers Quality System Regulation (21 CFR 820) compliance, including subsystems and design control workflows. - Provides overviews and checklists for HIPAA compliance specific to medical devices. - Addresses FDA device cybersecurity requirements, including threat modeling, SBOM, and security controls.
元数据
Slug fda-consultant-specialist
版本 2.1.1
许可证 MIT-0
累计安装 6
当前安装数 6
历史版本数 2
常见问题

Fda Consultant Specialist 是什么?

FDA regulatory consultant for medical device companies. Provides 510(k)/PMA/De Novo pathway guidance, QSR (21 CFR 820) compliance, HIPAA assessments, and dev... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 1626 次。

如何安装 Fda Consultant Specialist?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install fda-consultant-specialist」即可一键安装,无需额外配置。

Fda Consultant Specialist 是免费的吗?

是的,Fda Consultant Specialist 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

Fda Consultant Specialist 支持哪些平台?

Fda Consultant Specialist 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 Fda Consultant Specialist?

由 Alireza Rezvani(@alirezarezvani)开发并维护,当前版本 v2.1.1。

💬 留言讨论