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...

Security Scan

The skill's documentation and declared requirements are coherent for an FDA regulatory consultant, but the bundled Python scripts (not shown in the SKILL.md) create uncertainty — they need review because they could perform network I/O or access data outside the expected scope.

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.

What to consider before installing

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.

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
• 510(k) Submission Process
• QSR Compliance
• HIPAA for Medical Devices
• Device Cybersecurity
• Resources

---

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