Fda Consultant Specialist

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
• 510(k) Submission Process
• QMSR Compliance (formerly QSR)
• 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

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)

Common RTA Issues

---

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)

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

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

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/

references/

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

Medical Device Cybersecurity Guidance

Complete framework for FDA cybersecurity requirements based on FDA guidance documents and recognized consensus standards.

---

Table of Contents

• Regulatory Framework
• Premarket Cybersecurity
• Postmarket Cybersecurity
• Threat Modeling
• Security Controls
• Software Bill of Materials
• Vulnerability Management
• Documentation Requirements

---

Regulatory Framework

FDA Guidance Documents

PATCH Act Requirements (2023)

Cyber Device Definition:

• Contains software
• Can connect to internet
• May be vulnerable to cybersecurity threats

Manufacturer Obligations: 1. Submit plan to monitor, identify, and address vulnerabilities 2. Design, develop, and maintain processes to ensure device security 3. Provide software bill of materials (SBOM) 4. Comply with other requirements under section 524B

Recognized Consensus Standards

---

Premarket Cybersecurity

Cybersecurity Documentation Requirements

Cybersecurity Documentation Package:
├── 1. Security Risk Assessment
│   ├── Threat model
│   ├── Vulnerability assessment
│   ├── Risk analysis
│   └── Risk mitigation
├── 2. Security Architecture
│   ├── System diagram
│   ├── Data flow diagram
│   ├── Trust boundaries
│   └── Security controls
├── 3. Cybersecurity Testing
│   ├── Penetration testing
│   ├── Vulnerability scanning
│   ├── Fuzz testing
│   └── Security code review
├── 4. SBOM
│   ├── Software components
│   ├── Versions
│   └── Known vulnerabilities
├── 5. Vulnerability Management Plan
│   ├── Monitoring process
│   ├── Disclosure process
│   └── Patch management
└── 6. Labeling
    ├── Security instructions
    └── End-of-life plan

Device Tier Classification

Tier 1 - Higher Cybersecurity Risk:

• Device can connect to another product or network
• A cybersecurity incident could directly result in patient harm

Tier 2 - Standard Cybersecurity Risk:

• Device NOT a Tier 1 device
• Still requires cybersecurity documentation

Documentation Depth by Tier:

Security by Design Principles

## Secure Product Development Framework (SPDF)

### 1. Security Risk Management
- Integrate security into QMS
- Apply throughout product lifecycle
- Document security decisions

### 2. Security Architecture
- Defense in depth
- Least privilege
- Secure defaults
- Fail securely

### 3. Cybersecurity Testing
- Verify security controls
- Test for known vulnerabilities
- Validate threat mitigations

### 4. Cybersecurity Transparency
- SBOM provision
- Vulnerability disclosure
- Coordinated vulnerability disclosure

### 5. Cybersecurity Maintenance
- Monitor for vulnerabilities
- Provide timely updates
- Support throughout lifecycle

---

Postmarket Cybersecurity

Vulnerability Monitoring

Sources to Monitor:

• National Vulnerability Database (NVD)
• ICS-CERT advisories
• Third-party component vendors
• Security researcher reports
• Customer/user reports

Monitoring Process:

Daily/Weekly Monitoring:
├── NVD feed check
├── Vendor security bulletins
├── Security mailing lists
└── ISAC notifications

Monthly Review:
├── Component vulnerability analysis
├── Risk re-assessment
├── Patch status review
└── Trending threat analysis

Quarterly Assessment:
├── Comprehensive vulnerability scan
├── Third-party security audit
├── Update threat model
└── Security metrics review

Vulnerability Assessment and Response

CVSS-Based Triage:

Exploitability Assessment:

## Vulnerability Exploitation Assessment

### Device-Specific Factors
- [ ] Is the vulnerability reachable in device configuration?
- [ ] Are mitigating controls in place?
- [ ] What is the attack surface exposure?
- [ ] What is the potential patient harm?

### Environment Factors
- [ ] Is exploit code publicly available?
- [ ] Is the vulnerability being actively exploited?
- [ ] What is the typical deployment environment?

### Risk Determination
Uncontrolled Risk = Exploitability × Impact × Exposure

| Risk Level | Action |
|------------|--------|
| Unacceptable | Immediate remediation |
| Elevated | Prioritized remediation |
| Acceptable | Monitor, routine update |

Patch and Update Management

Update Classification:

FDA's Cybersecurity Policies:

1. Routine Updates: Generally do not require premarket review 2. Remediation of Vulnerabilities: No premarket review if:

• No new risks introduced
• No changes to intended use
• Adequate design controls followed

---

Threat Modeling

STRIDE Methodology

Threat Model Template

## Device Threat Model

### 1. System Description
Device Name: _____________________
Device Type: _____________________
Intended Use: ____________________

### 2. Architecture Diagram
[Include system diagram with trust boundaries]

### 3. Data Flow Diagram
[Document data flows and data types]

### 4. Entry Points
| Entry Point | Protocol | Authentication | Data Type |
|-------------|----------|----------------|-----------|
| USB port | USB HID | None | Config data |
| Network | HTTPS | Certificate | PHI |
| Bluetooth | BLE | Pairing | Commands |

### 5. Assets
| Asset | Sensitivity | Integrity | Availability |
|-------|-------------|-----------|--------------|
| Patient data | High | High | Medium |
| Device firmware | High | Critical | High |
| Configuration | Medium | High | Medium |

### 6. Threat Analysis
| Threat ID | STRIDE | Entry Point | Asset | Mitigation |
|-----------|--------|-------------|-------|------------|
| T-001 | Spoofing | Network | Auth | Mutual TLS |
| T-002 | Tampering | USB | Firmware | Secure boot |
| T-003 | Information | Network | PHI | Encryption |

### 7. Risk Assessment
| Threat | Likelihood | Impact | Risk | Accept/Mitigate |
|--------|------------|--------|------|-----------------|
| T-001 | Medium | High | High | Mitigate |
| T-002 | Low | Critical | High | Mitigate |
| T-003 | Medium | High | High | Mitigate |

Attack Trees

Example: Unauthorized Access to Device

Goal: Gain Unauthorized Access
├── 1. Physical Access Attack
│   ├── 1.1 Steal device
│   ├── 1.2 Access debug port
│   └── 1.3 Extract storage media
├── 2. Network Attack
│   ├── 2.1 Exploit unpatched vulnerability
│   ├── 2.2 Man-in-the-middle attack
│   └── 2.3 Credential theft
├── 3. Social Engineering
│   ├── 3.1 Phishing for credentials
│   └── 3.2 Insider threat
└── 4. Supply Chain Attack
    ├── 4.1 Compromised component
    └── 4.2 Malicious update

---

Security Controls

Authentication and Access Control

Authentication Requirements:

Password Requirements:

• Minimum 8 characters (12+ recommended)
• Complexity requirements
• Secure storage (hashed, salted)
• Account lockout after failed attempts
• Forced change on first use

Encryption Requirements

Data at Rest:

• AES-256 for sensitive data
• Secure key storage (TPM, secure enclave)
• Key rotation procedures

Data in Transit:

• TLS 1.2 or higher
• Strong cipher suites
• Certificate validation
• Perfect forward secrecy

Encryption Implementation Checklist:

## Encryption Controls

### Key Management
- [ ] Keys stored in hardware security module or equivalent
- [ ] Key generation uses cryptographically secure RNG
- [ ] Key rotation procedures documented
- [ ] Key revocation procedures documented
- [ ] Key escrow/recovery procedures (if applicable)

### Algorithm Selection
- [ ] AES-256 for symmetric encryption
- [ ] RSA-2048+ or ECDSA P-256+ for asymmetric
- [ ] SHA-256 or better for hashing
- [ ] No deprecated algorithms (MD5, SHA-1, DES)

### Implementation
- [ ] Using well-vetted cryptographic libraries
- [ ] Proper initialization vector handling
- [ ] Protection against timing attacks
- [ ] Secure key zeroing after use

Secure Communications

Network Security Controls:

Code Integrity

Secure Boot Chain:

Root of Trust (Hardware)
    ↓
Bootloader (Signed)
    ↓
Operating System (Verified)
    ↓
Application (Authenticated)
    ↓
Configuration (Integrity-checked)

Software Integrity Controls:

• Code signing for all software
• Signature verification before execution
• Anti-rollback protection
• Secure update mechanism

---

Software Bill of Materials

SBOM Requirements

NTIA Minimum Elements: 1. Supplier name 2. Component name 3. Version of component 4. Other unique identifiers (PURL, CPE) 5. Dependency relationship 6. Author of SBOM data 7. Timestamp

SBOM Formats

SBOM Template (CycloneDX)

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.4">
  <metadata>
    <timestamp>2024-01-15T00:00:00Z</timestamp>
    <tools>
      <tool>
        <vendor>Manufacturer</vendor>
        <name>SBOM Generator</name>
        <version>1.0.0</version>
      </tool>
    </tools>
    <component type="device">
      <name>Medical Device XYZ</name>
      <version>2.0.0</version>
      <supplier>
        <name>Device Manufacturer</name>
      </supplier>
    </component>
  </metadata>
  <components>
    <component type="library">
      <name>openssl</name>
      <version>1.1.1k</version>
      <purl>pkg:generic/openssl@1.1.1k</purl>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
    </component>
    <!-- Additional components -->
  </components>
  <dependencies>
    <dependency ref="device-xyz">
      <dependency ref="openssl"/>
    </dependency>
  </dependencies>
</bom>

SBOM Management Process

1. Initial SBOM Creation
   └── During development, before submission

2. Vulnerability Monitoring
   └── Continuous monitoring against NVD

3. SBOM Updates
   └── With each software release

4. Customer Communication
   └── SBOM provided on request

5. FDA Submission
   └── Included in premarket submission

---

Vulnerability Management

Vulnerability Disclosure

Coordinated Vulnerability Disclosure (CVD):

## Vulnerability Disclosure Policy

### Reporting
- Security contact: security@manufacturer.com
- PGP key available at: [URL]
- Bug bounty program: [if applicable]

### Response Timeline
- Acknowledgment: Within 48 hours
- Initial assessment: Within 5 business days
- Status updates: Every 30 days
- Target remediation: Per severity

### Public Disclosure
- Coordinated with reporter
- After remediation available
- Include mitigations if patch delayed

### Safe Harbor
[Statement on not pursuing legal action against good-faith reporters]

Vulnerability Response Process

Discovery
    ↓
Triage (CVSS + Exploitability)
    ↓
Risk Assessment
    ↓
Remediation Development
    ↓
Testing and Validation
    ↓
Deployment/Communication
    ↓
Verification
    ↓
Closure

Customer Communication

Security Advisory Template:

## Security Advisory

### Advisory ID: [ID]
### Published: [Date]
### Severity: [Critical/High/Medium/Low]

### Affected Products
- Product A, versions 1.0-2.0
- Product B, versions 3.0-3.5

### Description
[Description of vulnerability without exploitation details]

### Impact
[What could happen if exploited]

### Mitigation
[Steps to reduce risk before patch available]

### Remediation
- Patch version: X.X.X
- Download: [URL]
- Installation instructions: [Link]

### Credits
[Acknowledge reporter if agreed]

### References
- CVE-XXXX-XXXX
- Manufacturer reference: [ID]

---

Documentation Requirements

Premarket Submission Checklist

## Cybersecurity Documentation for Premarket Submission

### Device Description (Tier 1 and 2)
- [ ] Cybersecurity risk level justification
- [ ] Global system diagram
- [ ] Data flow diagram

### Security Risk Management (Tier 1 and 2)
- [ ] Threat model
- [ ] Security risk assessment
- [ ] Traceability matrix

### Security Architecture (Tier 1 and 2)
- [ ] Defense-in-depth description
- [ ] Security controls list
- [ ] Trust boundaries identified

### Testing Documentation
#### Tier 1
- [ ] Penetration test report
- [ ] Vulnerability scan results
- [ ] Fuzz testing results
- [ ] Static code analysis
- [ ] Third-party component testing

#### Tier 2
- [ ] Security testing summary
- [ ] Known vulnerability analysis

### SBOM (Tier 1 and 2)
- [ ] Complete component inventory
- [ ] Known vulnerability assessment
- [ ] Support and update plan

### Vulnerability Management (Tier 1 and 2)
- [ ] Vulnerability handling policy
- [ ] Coordinated disclosure process
- [ ] Security update plan

### Labeling (Tier 1 and 2)
- [ ] User security instructions
- [ ] End-of-support date
- [ ] Security contact information

Recommended File Structure

Cybersecurity_Documentation/
├── 01_Executive_Summary.pdf
├── 02_Device_Description/
│   ├── System_Diagram.pdf
│   └── Data_Flow_Diagram.pdf
├── 03_Security_Risk_Assessment/
│   ├── Threat_Model.pdf
│   ├── Risk_Assessment.pdf
│   └── Traceability_Matrix.xlsx
├── 04_Security_Architecture/
│   ├── Architecture_Description.pdf
│   ├── Security_Controls.pdf
│   └── Trust_Boundary_Analysis.pdf
├── 05_Security_Testing/
│   ├── Penetration_Test_Report.pdf
│   ├── Vulnerability_Scan_Results.pdf
│   ├── Fuzz_Testing_Report.pdf
│   └── Code_Analysis_Report.pdf
├── 06_SBOM/
│   ├── SBOM.xml (CycloneDX)
│   └── Vulnerability_Analysis.pdf
├── 07_Vulnerability_Management/
│   ├── Vulnerability_Policy.pdf
│   └── Disclosure_Process.pdf
└── 08_Labeling/
    └── Security_Instructions.pdf

---

Quick Reference

Common Cybersecurity Deficiencies

Security Testing Requirements

Recognized Standards Mapping

FDA CAPA Requirements

Complete guide to Corrective and Preventive Action requirements per 21 CFR 820.100.

---

Table of Contents

• CAPA Regulation Overview
• CAPA Sources
• CAPA Process
• Root Cause Analysis
• Action Implementation
• Effectiveness Verification
• Documentation Requirements
• FDA Inspection Focus Areas

---

CAPA Regulation Overview

21 CFR 820.100 Requirements

§820.100 Corrective and preventive action

(a) Each manufacturer shall establish and maintain procedures for
implementing corrective and preventive action. The procedures shall
include requirements for:

(1) Analyzing processes, work operations, concessions, quality audit
    reports, quality records, service records, complaints, returned
    product, and other sources of quality data to identify existing
    and potential causes of nonconforming product, or other quality
    problems.

(2) Investigating the cause of nonconformities relating to product,
    processes, and the quality system.

(3) Identifying the action(s) needed to correct and prevent recurrence
    of nonconforming product and other quality problems.

(4) Verifying or validating the corrective and preventive action to
    ensure that such action is effective and does not adversely affect
    the finished device.

(5) Implementing and recording changes in methods and procedures needed
    to correct and prevent identified quality problems.

(6) Ensuring that information related to quality problems or nonconforming
    product is disseminated to those directly responsible for assuring
    the quality of such product or the prevention of such problems.

(7) Submitting relevant information on identified quality problems, as
    well as corrective and preventive actions, for management review.

Definitions

CAPA vs. Correction

Problem Detected
    ├── Correction (Immediate)
    │   └── Fix the immediate issue
    │       Example: Replace defective part
    │
    └── CAPA (Systemic)
        └── Address root cause
            Example: Fix process that caused defect

---

CAPA Sources

Data Sources for CAPA Input

Internal Sources:

• Nonconforming product reports (NCRs)
• Internal audit findings
• Process deviations
• Manufacturing data trends
• Equipment failures
• Employee observations
• Training deficiencies

External Sources:

• Customer complaints
• Service records
• Returned product
• Regulatory feedback (483s, warning letters)
• Adverse event reports (MDRs)
• Field safety corrective actions

CAPA Threshold Criteria

Mandatory CAPA Triggers:

Discretionary CAPA Evaluation:

Trend Analysis

Statistical Process Control:

## Monthly CAPA Trend Review

### Complaint Trending
- [ ] Complaints by product
- [ ] Complaints by failure mode
- [ ] Geographic distribution
- [ ] Customer type analysis

### NCR Trending
- [ ] NCRs by product/process
- [ ] NCRs by cause code
- [ ] NCRs by supplier
- [ ] Scrap/rework rates

### Threshold Monitoring
| Metric | Threshold | Current | Status |
|--------|-----------|---------|--------|
| Complaints/month | <10 | | |
| NCR rate | <2% | | |
| Recurring issues | 0 | | |

---

CAPA Process

CAPA Workflow

1. Initiation
   ├── Problem identification
   ├── Initial assessment
   └── CAPA determination

2. Investigation
   ├── Data collection
   ├── Root cause analysis
   └── Impact assessment

3. Action Planning
   ├── Correction (if applicable)
   ├── Corrective action
   └── Preventive action

4. Implementation
   ├── Execute actions
   ├── Document changes
   └── Train affected personnel

5. Verification
   ├── Verify implementation
   ├── Validate effectiveness
   └── Monitor for recurrence

6. Closure
   ├── Management approval
   ├── Final documentation
   └── Trend data update

CAPA Form Template

## CAPA Record

### Section 1: Identification
CAPA Number: ________________
Initiated By: ________________
Date Initiated: ______________
Priority: ☐ Critical ☐ Major ☐ Minor

Source:
☐ Audit Finding     ☐ Complaint        ☐ NCR
☐ Service Record    ☐ MDR              ☐ Trend Data
☐ Regulatory        ☐ Other: ____________

### Section 2: Problem Description
Products Affected: _______________________
Processes Affected: _____________________
Quantity/Scope: _________________________

Problem Statement:
[Clear, specific description of the nonconformity or potential problem]

### Section 3: Immediate Correction
Correction Taken: _______________________
Date Completed: _________________________
Verified By: ____________________________

### Section 4: Investigation
Investigation Lead: _____________________
Investigation Start Date: _______________

Data Collected:
☐ Complaint records      ☐ Production records
☐ Test data              ☐ Training records
☐ Process documentation  ☐ Supplier data

Root Cause Analysis Method:
☐ 5 Whys    ☐ Fishbone    ☐ Fault Tree    ☐ Other

Root Cause Statement:
[Specific, factual statement of the root cause]

Contributing Factors:
1. _____________________________________
2. _____________________________________

### Section 5: Action Plan

#### Corrective Actions
| Action | Owner | Target Date | Status |
|--------|-------|-------------|--------|
|        |       |             |        |

#### Preventive Actions
| Action | Owner | Target Date | Status |
|--------|-------|-------------|--------|
|        |       |             |        |

### Section 6: Verification
Verification Method: ____________________
Verification Criteria: __________________
Verification Date: _____________________
Verified By: ___________________________

Verification Results:
☐ Actions implemented as planned
☐ No adverse effects identified
☐ Documentation updated

### Section 7: Effectiveness Review
Effectiveness Review Date: ______________
Review Period: ________________________
Reviewer: _____________________________

Effectiveness Criteria:
[Specific, measurable criteria for success]

Results:
☐ Effective - problem has not recurred
☐ Not Effective - additional action required

Evidence:
[Reference to data showing effectiveness]

### Section 8: Closure
Closure Date: _________________________
Approved By: __________________________

Management Review Submitted: ☐ Yes ☐ No
Date: ________________________________

---

Root Cause Analysis

5 Whys Technique

Example: Device Fails Final Test

Problem: 5% of devices fail functional test at final inspection

Why 1: Component X is out of tolerance
Why 2: Component X was accepted at incoming inspection
Why 3: Incoming inspection sampling missed defective lot
Why 4: Sampling plan inadequate for component criticality
Why 5: Risk classification of component not updated after design change

Root Cause: Risk classification process did not include design change trigger

5 Whys Template:

## 5 Whys Analysis

Problem Statement: _________________________________

Why 1: _____________________________________________
Evidence: __________________________________________

Why 2: _____________________________________________
Evidence: __________________________________________

Why 3: _____________________________________________
Evidence: __________________________________________

Why 4: _____________________________________________
Evidence: __________________________________________

Why 5: _____________________________________________
Evidence: __________________________________________

Root Cause: ________________________________________

Verification: How do we know this is the root cause?
________________________________________________

Fishbone (Ishikawa) Diagram

Categories for Medical Device Manufacturing:

                    ┌─────────────────────────────────────────┐
                    │              PROBLEM                     │
                    └─────────────────────────────────────────┘
                                       ▲
           ┌───────────────────────────┼───────────────────────────┐
           │                           │                           │
    ┌──────┴──────┐             ┌──────┴──────┐             ┌──────┴──────┐
    │  PERSONNEL  │             │   METHODS   │             │  MATERIALS  │
    │             │             │             │             │             │
    │ • Training  │             │ • SOP gaps  │             │ • Supplier  │
    │ • Skills    │             │ • Process   │             │ • Specs     │
    │ • Attention │             │ • Sequence  │             │ • Storage   │
    └─────────────┘             └─────────────┘             └─────────────┘
           │                           │                           │
           └───────────────────────────┼───────────────────────────┘
                                       │
    ┌──────────────┐            ┌──────┴──────┐            ┌──────────────┐
    │  MEASUREMENT │            │  EQUIPMENT  │            │ ENVIRONMENT  │
    │              │            │             │            │              │
    │ • Calibration│            │ • Maintenance│           │ • Temperature│
    │ • Method     │            │ • Capability │           │ • Humidity   │
    │ • Accuracy   │            │ • Tooling   │            │ • Cleanliness│
    └──────────────┘            └─────────────┘            └──────────────┘

Fault Tree Analysis

For Complex Failures:

                    Top Event: Device Failure
                              │
              ┌───────────────┼───────────────┐
              │               │               │
           AND/OR          AND/OR          AND/OR
              │               │               │
        ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
        │ Component │   │  Software │   │   User    │
        │  Failure  │   │  Failure  │   │   Error   │
        └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
              │               │               │
         Basic Events    Basic Events    Basic Events

Root Cause Categories

---

Action Implementation

Corrective Action Requirements

Effective Corrective Actions: 1. Address identified root cause 2. Are specific and measurable 3. Have assigned ownership 4. Have realistic target dates 5. Consider impact on other processes 6. Include verification method

Action Types:

Change Control Integration

CAPA Action Identified
        │
        ▼
Change Request Initiated
        │
        ▼
Impact Assessment
├── Regulatory impact
├── Product impact
├── Process impact
└── Documentation impact
        │
        ▼
Change Approved
        │
        ▼
Implementation
├── Document updates
├── Training
├── Validation (if required)
└── Effective date
        │
        ▼
CAPA Verification

Training Requirements

When Training is Required:

• New or revised procedures
• New equipment or tools
• Process changes
• Findings related to personnel performance

Training Documentation:

## CAPA-Related Training Record

CAPA Number: _______________
Training Subject: ___________
Training Date: ______________
Trainer: ___________________

Attendees:
| Name | Signature | Date |
|------|-----------|------|
|      |           |      |

Training Content:
- [ ] Root cause explanation
- [ ] Process/procedure changes
- [ ] New requirements
- [ ] Competency verification

Competency Verified By: _______________
Date: _______________

---

Effectiveness Verification

Verification vs. Validation

Effectiveness Criteria

SMART Criteria:

• Specific: Clearly defined outcome
• Measurable: Quantifiable metrics
• Achievable: Realistic expectations
• Relevant: Related to root cause
• Time-bound: Defined monitoring period

Examples:

Effectiveness Review Template

## CAPA Effectiveness Review

CAPA Number: _______________
Review Date: _______________
Reviewer: __________________

### Review Criteria
Original Problem: _________________
Effectiveness Metric: ______________
Success Threshold: ________________
Review Period: ____________________

### Data Analysis
| Period | Metric Value | Threshold | Pass/Fail |
|--------|--------------|-----------|-----------|
| Month 1 |             |           |           |
| Month 2 |             |           |           |
| Month 3 |             |           |           |

### Conclusion
☐ Effective - Criteria met, CAPA may be closed
☐ Partially Effective - Additional monitoring required
☐ Not Effective - Additional actions required

### Evidence
[Reference to supporting data: complaint logs, NCR reports, audit results, etc.]

### Next Steps (if not effective)
___________________________________
___________________________________

### Approval
Reviewer Signature: _______________ Date: _______
Quality Approval: _________________ Date: _______

Monitoring Period Guidelines

---

Documentation Requirements

CAPA File Contents

CAPA File Structure:
├── CAPA Form (all sections completed)
├── Investigation Records
│   ├── Data collected
│   ├── Root cause analysis worksheets
│   └── Impact assessment
├── Action Documentation
│   ├── Action plans
│   ├── Change requests (if applicable)
│   └── Training records
├── Verification Evidence
│   ├── Implementation verification
│   ├── Effectiveness data
│   └── Trend analysis
└── Closure Documentation
    ├── Closure approval
    └── Management review submission

Record Retention

Per 21 CFR 820.180:

• Records shall be retained for the design and expected life of the device
• Minimum of 2 years from date of release for commercial distribution

CAPA Record Retention:

• Retain for lifetime of product + 2 years
• Include all supporting documentation
• Maintain audit trail for changes

Traceability

Required Traceability:

• CAPA to source (complaint, NCR, audit finding)
• CAPA to affected products/lots
• CAPA to corrective actions taken
• CAPA to verification evidence
• CAPA to management review

---

FDA Inspection Focus Areas

Common 483 Observations

Inspection Preparation

CAPA Readiness Checklist:

## FDA Inspection CAPA Preparation

### Documentation Review
- [ ] All CAPAs have complete documentation
- [ ] No overdue CAPAs
- [ ] Root cause documented with evidence
- [ ] Effectiveness verified and documented
- [ ] All open CAPAs have current status

### Metrics Available
- [ ] CAPA by source
- [ ] CAPA cycle time
- [ ] Overdue CAPA trend
- [ ] Effectiveness rate
- [ ] Recurring issues

### Process Evidence
- [ ] CAPA procedure current
- [ ] Training records complete
- [ ] Trend analysis documented
- [ ] Management review records show CAPA input

### Common Questions Prepared
- How do you initiate a CAPA?
- How do you determine root cause?
- How do you verify effectiveness?
- Show me your overdue CAPAs
- Show me CAPAs from complaints

CAPA Metrics Dashboard

---

Quick Reference

CAPA Decision Tree

Quality Issue Identified
        │
        ▼
Is it an isolated incident?
├── YES → Correction only (document, may not need CAPA)
│         Evaluate for trend
│
└── NO → Is it a systemic issue?
         ├── YES → Initiate CAPA
         │         Determine if Corrective or Preventive
         │
         └── MAYBE → Investigate further
                     Monitor for recurrence
                     May escalate to CAPA

Root Cause vs. Symptom

Action Effectiveness Verification

Integration with Other Systems

FDA Submission Guide

Complete framework for 510(k), De Novo, and PMA submissions to the FDA.

---

Table of Contents

• Submission Pathway Selection
• 510(k) Premarket Notification
• De Novo Classification
• PMA Premarket Approval
• Pre-Submission Program
• FDA Review Timeline

---

Submission Pathway Selection

Decision Matrix

Is there a legally marketed predicate device?
├── YES → Is your device substantially equivalent?
│   ├── YES → 510(k) Pathway
│   │   ├── No changes from predicate → Abbreviated 510(k)
│   │   ├── Manufacturing changes only → Special 510(k)
│   │   └── Design/performance changes → Traditional 510(k)
│   └── NO → PMA or De Novo
└── NO → Is it a novel low-to-moderate risk device?
    ├── YES → De Novo Classification Request
    └── NO → PMA Pathway (Class III)

Classification Determination

Predicate Device Search

Database Sources: 1. FDA 510(k) Database: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpmn/pmn.cfm 2. FDA Product Classification Database 3. FDA PMA Database 4. FDA De Novo Database

Search Criteria:

• Product code (3-letter code)
• Device name keywords
• Intended use similarity
• Technological characteristics

---

510(k) Premarket Notification

Required Sections (21 CFR 807.87)

1. Administrative Information

Cover Letter
├── Submission type (Traditional/Special/Abbreviated)
├── Device name and classification
├── Predicate device(s) identification
├── Contact information
└── Signature of authorized representative

CDRH Premarket Review Submission Cover Sheet (FDA Form 3514)
├── Section A: Applicant Information
├── Section B: Device Information
├── Section C: Submission Information
└── Section D: Truth and Accuracy Statement

2. Device Description

3. Substantial Equivalence Comparison

Comparison Table Format:
┌────────────────────┬─────────────────┬─────────────────┐
│ Characteristic     │ Subject Device  │ Predicate       │
├────────────────────┼─────────────────┼─────────────────┤
│ Intended Use       │ [Your device]   │ [Predicate]     │
│ Technological      │                 │                 │
│ Characteristics    │                 │                 │
│ Performance        │                 │                 │
│ Safety             │                 │                 │
└────────────────────┴─────────────────┴─────────────────┘

Substantial Equivalence Argument:
1. Same intended use? YES/NO
2. Same technological characteristics? YES/NO
3. If different technology, does it raise new safety/effectiveness questions? YES/NO
4. Performance data demonstrates equivalence? YES/NO

4. Performance Testing

Bench Testing:

• Mechanical/structural testing
• Electrical safety (IEC 60601-1 if applicable)
• Biocompatibility (ISO 10993 series)
• Sterilization validation
• Shelf life/stability testing
• Software verification (IEC 62304 if applicable)

Clinical Data (if required):

• Clinical study summaries
• Literature review
• Adverse event data

5. Labeling

Required Elements:

• Instructions for Use (IFU)
• Device labeling (package, carton)
• Indications for Use statement
• Contraindications, warnings, precautions
• Advertising materials (if applicable)

510(k) Acceptance Checklist

## Pre-Submission Verification

- [ ] FDA Form 3514 complete and signed
- [ ] User fee payment ($21,760 for FY2024, small business exemptions available)
- [ ] Device description complete
- [ ] Predicate device identified with 510(k) number
- [ ] Substantial equivalence comparison table
- [ ] Indications for Use statement (FDA Form 3881)
- [ ] Performance data summary
- [ ] Labeling (IFU, device labels)
- [ ] 510(k) summary or statement
- [ ] Truthful and Accuracy statement signed
- [ ] Environmental assessment or categorical exclusion

---

De Novo Classification

Eligibility Criteria

1. Novel device with no legally marketed predicate 2. Low-to-moderate risk (would be Class I or II if predicate existed) 3. General controls alone (Class I) or with special controls (Class II) provide reasonable assurance of safety and effectiveness

Required Content

Risk Assessment

Risk Analysis Requirements:
├── Hazard Identification
│   ├── Biological hazards
│   ├── Mechanical hazards
│   ├── Electrical hazards
│   ├── Use-related hazards
│   └── Cybersecurity hazards (if applicable)
├── Risk Estimation
│   ├── Probability of occurrence
│   ├── Severity of harm
│   └── Risk level (High/Medium/Low)
├── Risk Evaluation
│   ├── Acceptability criteria
│   └── Benefit-risk analysis
└── Risk Control Measures
    ├── Design controls
    ├── Protective measures
    └── Information for safety

Proposed Classification

Special Controls (for Class II)

Define specific controls such as:

• Performance testing requirements
• Labeling requirements
• Post-market surveillance
• Patient registry
• Design specifications

---

PMA Premarket Approval

PMA Application Contents

Technical Sections

1. Device Description and Intended Use

• Detailed design specifications
• Operating principles
• Complete indications for use

2. Manufacturing Information

• Manufacturing process description
• Quality system information
• Facility registration

3. Nonclinical Laboratory Studies

• Bench testing results
• Animal studies (if applicable)
• Biocompatibility testing

4. Clinical Investigation

• IDE number and approval date
• Clinical protocol
• Clinical study results
• Statistical analysis
• Adverse events

5. Labeling

• Complete labeling
• Patient labeling (if applicable)

Clinical Data Requirements

Clinical Study Design:
├── Study Objectives
│   ├── Primary endpoint(s)
│   └── Secondary endpoint(s)
├── Study Population
│   ├── Inclusion criteria
│   ├── Exclusion criteria
│   └── Sample size justification
├── Study Design
│   ├── Randomized controlled trial
│   ├── Single-arm study with OPC
│   └── Other design with justification
├── Statistical Analysis Plan
│   ├── Analysis populations
│   ├── Statistical methods
│   └── Handling of missing data
└── Safety Monitoring
    ├── Adverse event definitions
    ├── Stopping rules
    └── DSMB oversight

IDE (Investigational Device Exemption)

When Required:

• Significant risk device clinical studies
• Studies not exempt under 21 CFR 812.2

IDE Application Content:

• Investigational plan
• Manufacturing information
• Investigator agreements
• IRB approvals
• Informed consent forms
• Labeling
• Risk analysis

---

Pre-Submission Program

Q-Submission Types

Pre-Sub Meeting Preparation

Pre-Submission Package:
1. Cover letter with meeting request
2. Device description
3. Regulatory history (if any)
4. Proposed submission pathway
5. Specific questions (maximum 5-6)
6. Supporting data/information

Meeting Types:
- Written response only (default)
- Teleconference (90 minutes)
- In-person meeting (90 minutes)

Effective Question Formulation

Good Question Format:

Question: Does FDA agree that [specific proposal] is acceptable for [specific purpose]?

Background: [Brief context - 1-2 paragraphs]

Proposal: [Your specific proposal - detailed but concise]

Rationale: [Why you believe this is appropriate]

Avoid:

• Open-ended questions ("What should we do?")
• Multiple questions combined
• Questions already answered in guidance

---

FDA Review Timeline

Standard Review Times

Review Process Stages

510(k) Review Timeline:
Day 0: Submission received
Day 1-15: Acceptance review
├── Accept → Substantive review begins
└── Refuse to Accept (RTA) → 180 days to respond

Day 15-90: Substantive review
├── Additional Information (AI) request stops clock
├── Interactive review may occur
└── Decision by Day 90 goal

Decision:
├── Substantially Equivalent (SE) → Clearance letter
├── Not Substantially Equivalent (NSE) → Appeal or new submission
└── Withdrawn

Additional Information Requests

Response Best Practices:

• Respond within 30-60 days
• Use FDA's question numbering
• Provide complete responses
• Include amended sections clearly marked
• Reference specific guidance documents

---

Submission Best Practices

Document Formatting

• Use PDF format (PDF/A preferred)
• Bookmarks for each section
• Hyperlinks to cross-references
• Table of contents with page numbers
• Consistent headers/footers

eSTAR (Electronic Submission Template)

FDA's recommended electronic submission format for 510(k):

• Structured data entry
• Built-in validation
• Automatic formatting
• Reduced RTA rate

Common Refuse to Accept (RTA) Issues

HIPAA Compliance Framework for Medical Devices

Complete guide to HIPAA requirements for medical device manufacturers and software developers.

---

Table of Contents

• HIPAA Overview
• Privacy Rule Requirements
• Security Rule Requirements
• Medical Device Considerations
• Risk Assessment
• Implementation Specifications
• Business Associate Agreements
• Breach Notification

---

HIPAA Overview

Applicability to Medical Devices

Protected Health Information (PHI)

PHI Definition: Individually identifiable health information transmitted or maintained in any form.

18 HIPAA Identifiers:

1. Names
2. Geographic data (smaller than state)
3. Dates (except year) related to individual
4. Phone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers
13. Device identifiers and serial numbers
14. Web URLs
15. IP addresses
16. Biometric identifiers
17. Full face photos
18. Any other unique identifying number

Electronic PHI (ePHI)

PHI that is created, stored, transmitted, or received in electronic form. Most relevant for:

• Connected medical devices
• Medical device software (SaMD)
• Mobile health applications
• Cloud-based healthcare systems

---

Privacy Rule Requirements

Minimum Necessary Standard

Principle: Limit PHI access, use, and disclosure to the minimum necessary to accomplish the intended purpose.

Implementation:

• Role-based access controls
• Access audit logging
• Data segmentation
• Need-to-know policies

Patient Rights

Use and Disclosure

Permitted Uses:

• Treatment, Payment, Healthcare Operations (TPO)
• With patient authorization
• Public health activities
• Required by law
• Health oversight activities

Medical Device Context:

• Device data for treatment: Permitted
• Data analytics by manufacturer: Requires BAA or de-identification
• Research use: Requires authorization or IRB waiver

---

Security Rule Requirements

Administrative Safeguards

Security Management Process (§164.308(a)(1))

Required Specifications:

## Security Management Process

### Risk Analysis
- [ ] Identify systems with ePHI
- [ ] Document potential threats and vulnerabilities
- [ ] Assess likelihood and impact
- [ ] Document current controls
- [ ] Determine risk levels

### Risk Management
- [ ] Implement security measures
- [ ] Document residual risk
- [ ] Management approval

### Sanction Policy
- [ ] Define workforce sanctions
- [ ] Document enforcement procedures

### Information System Activity Review
- [ ] Define audit procedures
- [ ] Review logs regularly
- [ ] Document findings

Workforce Security (§164.308(a)(3))

Information Access Management (§164.308(a)(4))

Access Control Elements:

• Access authorization
• Access establishment and modification
• Unique user identification
• Automatic logoff

Security Awareness and Training (§164.308(a)(5))

Training Topics:

• Security reminders
• Protection from malicious software
• Login monitoring
• Password management

Security Incident Procedures (§164.308(a)(6))

Incident Response Requirements: 1. Identify and document incidents 2. Report security incidents 3. Respond to mitigate harmful effects 4. Document outcomes

Contingency Plan (§164.308(a)(7))

## Contingency Plan Components

### Data Backup Plan (Required)
- Backup frequency: _____
- Backup verification: _____
- Off-site storage: _____

### Disaster Recovery Plan (Required)
- Recovery time objective: _____
- Recovery point objective: _____
- Recovery procedures: _____

### Emergency Mode Operation (Required)
- Critical functions: _____
- Manual procedures: _____
- Communication plan: _____

### Testing and Revision (Addressable)
- Test frequency: _____
- Last test date: _____
- Revision history: _____

### Applications and Data Criticality (Addressable)
- Critical systems: _____
- Priority recovery order: _____

Physical Safeguards

Facility Access Controls (§164.310(a)(1))

Workstation Use (§164.310(b))

Requirements:

• Policies for workstation use
• Physical environment considerations
• Secure positioning
• Screen privacy

Workstation Security (§164.310(c))

Physical Safeguards:

• Cable locks
• Restricted areas
• Surveillance
• Clean desk policy

Device and Media Controls (§164.310(d)(1))

Critical for Medical Devices:

## Device and Media Controls

### Disposal (Required)
- [ ] Wipe procedures for devices with ePHI
- [ ] Certificate of destruction
- [ ] Media sanitization per NIST 800-88

### Media Re-use (Required)
- [ ] Sanitization before re-use
- [ ] Verification of removal
- [ ] Documentation

### Accountability (Addressable)
- [ ] Hardware inventory
- [ ] Movement tracking
- [ ] Responsibility assignment

### Data Backup and Storage (Addressable)
- [ ] Retrievable copies
- [ ] Secure storage location
- [ ] Access controls on backup media

Technical Safeguards

Access Control (§164.312(a)(1))

Audit Controls (§164.312(b))

Audit Log Contents:

• User identification
• Event type
• Date and time
• Success/failure
• Affected data

Medical Device Considerations:

• Log all access to patient data
• Protect logs from tampering
• Retain logs per policy (minimum 6 years)
• Real-time alerting for critical events

Integrity (§164.312(c)(1))

ePHI Integrity Controls:

• Hash verification
• Digital signatures
• Version control
• Change detection

Person or Entity Authentication (§164.312(d))

Authentication Methods:

• Passwords (strong requirements)
• Biometrics
• Hardware tokens
• Multi-factor authentication (recommended)

Transmission Security (§164.312(e)(1))

---

Medical Device Considerations

Connected Medical Device Security

Data Flow Analysis:

Device → Local Network → Internet → Cloud → EHR
  │           │            │         │       │
  └─ ePHI at rest    ePHI in transit    ePHI at rest
     Encrypt          Encrypt TLS       Encrypt + Access Control

SaMD (Software as a Medical Device)

HIPAA Requirements for SaMD: 1. Encryption of stored patient data 2. Secure authentication 3. Audit logging 4. Access controls 5. Secure communication protocols 6. Backup and recovery 7. Incident response

Mobile Medical Applications

Additional Considerations:

• Device loss/theft protection
• Remote wipe capability
• App sandboxing
• Secure data storage
• API security

Cloud-Based Devices

Cloud Provider Requirements:

• BAA with cloud provider
• Data residency (US only for HIPAA)
• Encryption key management
• Audit log access
• Incident notification

---

Risk Assessment

HIPAA Risk Assessment Process

Step 1: Scope Definition
├── Identify systems with ePHI
├── Document data flows
└── Identify business associates

Step 2: Threat Identification
├── Natural threats (fire, flood)
├── Human threats (hackers, insiders)
├── Environmental threats (power, HVAC)
└── Technical threats (malware, system failure)

Step 3: Vulnerability Assessment
├── Administrative controls
├── Physical controls
├── Technical controls
└── Gap analysis

Step 4: Risk Analysis
├── Likelihood assessment
├── Impact assessment
├── Risk level determination
└── Risk prioritization

Step 5: Risk Treatment
├── Accept
├── Mitigate
├── Transfer
└── Avoid

Step 6: Documentation
├── Risk register
├── Risk management plan
└── Remediation tracking

Risk Assessment Template

## HIPAA Risk Assessment

### System Information
System Name: _____________________
System Owner: ____________________
Date: ___________________________

### Asset Inventory
| Asset | ePHI Type | Location | Classification |
|-------|-----------|----------|----------------|
|       |           |          |                |

### Threat Analysis
| Threat | Likelihood (1-5) | Impact (1-5) | Risk Score |
|--------|------------------|--------------|------------|
|        |                  |              |            |

### Vulnerability Assessment
| Safeguard Category | Gap Identified | Severity | Remediation |
|--------------------|----------------|----------|-------------|
| Administrative     |                |          |             |
| Physical           |                |          |             |
| Technical          |                |          |             |

### Risk Treatment Plan
| Risk | Treatment | Owner | Timeline | Status |
|------|-----------|-------|----------|--------|
|      |           |       |          |        |

### Approval
Risk Assessment Approved: _______________ Date: _______
Next Assessment Due: _______________

---

Implementation Specifications

Required vs. Addressable

Required: Must be implemented as specified

Addressable: 1. Implement as specified, OR 2. Implement alternative measure, OR 3. Not implement if not reasonable and appropriate (document rationale)

Implementation Status Matrix

---

Business Associate Agreements

When Required

BAA required when business associate:

• Creates, receives, maintains, or transmits PHI
• Provides services involving PHI use/disclosure

BAA Requirements

Required Provisions: 1. Permitted and required uses of PHI 2. Subcontractor requirements 3. Appropriate safeguards 4. Breach notification 5. Termination provisions 6. Return or destruction of PHI

Medical Device Manufacturer BAA Template

## Business Associate Agreement

This Agreement is entered into as of [Date] between:

COVERED ENTITY: [Healthcare Provider/Plan Name]
BUSINESS ASSOCIATE: [Device Manufacturer Name]

### 1. Definitions
[Standard HIPAA definitions]

### 2. Obligations of Business Associate

Business Associate agrees to:

a) Not use or disclose PHI other than as permitted
b) Use appropriate safeguards to prevent improper use/disclosure
c) Report any security incident or breach
d) Ensure subcontractors agree to same restrictions
e) Make PHI available for individual access
f) Make PHI available for amendment
g) Document and make available disclosures
h) Make internal practices available to HHS
i) Return or destroy PHI at termination

### 3. Permitted Uses and Disclosures

Business Associate may:
a) Use PHI for device operation and maintenance
b) Use PHI for quality improvement
c) De-identify PHI per HIPAA standards
d) Create aggregate data
e) Report to FDA as required

### 4. Security Requirements

Business Associate shall implement:
a) Administrative safeguards per §164.308
b) Physical safeguards per §164.310
c) Technical safeguards per §164.312

### 5. Breach Notification

Business Associate shall:
a) Report breaches within [60 days/contractual period]
b) Provide information for breach notification
c) Mitigate harmful effects

### 6. Term and Termination
[Standard termination provisions]

### Signatures

COVERED ENTITY: _________________ Date: _______
BUSINESS ASSOCIATE: _____________ Date: _______

---

Breach Notification

Breach Definition

Breach: Acquisition, access, use, or disclosure of unsecured PHI in a manner not permitted that compromises security or privacy.

Exceptions: 1. Unintentional acquisition by workforce member acting in good faith 2. Inadvertent disclosure between authorized persons 3. Good faith belief that unauthorized person couldn't retain information

Risk Assessment for Breach

Factors to Consider: 1. Nature and extent of PHI involved 2. Unauthorized person who received PHI 3. Whether PHI was actually acquired/viewed 4. Extent to which risk has been mitigated

Notification Requirements

Breach Response Procedure

## Breach Response Procedure

### Phase 1: Detection and Containment (Immediate)
- [ ] Identify scope of breach
- [ ] Contain breach (stop ongoing access)
- [ ] Preserve evidence
- [ ] Notify incident response team
- [ ] Document timeline

### Phase 2: Investigation (1-14 days)
- [ ] Determine what PHI was involved
- [ ] Identify affected individuals
- [ ] Assess risk of harm
- [ ] Document investigation findings

### Phase 3: Risk Assessment (15-30 days)
- [ ] Apply four-factor risk assessment
- [ ] Determine if notification required
- [ ] Document decision rationale

### Phase 4: Notification (Within 60 days)
- [ ] Prepare individual notification letters
- [ ] Submit to HHS (if required)
- [ ] Media notification (if required)
- [ ] Retain copies of notifications

### Phase 5: Remediation (Ongoing)
- [ ] Implement corrective actions
- [ ] Update policies and procedures
- [ ] Train workforce
- [ ] Monitor for additional impact

Breach Notification Content

Individual Notification Must Include: 1. Description of what happened 2. Types of PHI involved 3. Steps individuals should take 4. What entity is doing to investigate 5. What entity is doing to prevent future breaches 6. Contact information for questions

---

Compliance Checklist

Administrative Safeguards Checklist

## Administrative Safeguards

- [ ] Security Management Process
  - [ ] Risk analysis completed and documented
  - [ ] Risk management plan in place
  - [ ] Sanction policy documented
  - [ ] Information system activity review conducted

- [ ] Assigned Security Responsibility
  - [ ] Security Officer designated
  - [ ] Contact information documented

- [ ] Workforce Security
  - [ ] Authorization procedures
  - [ ] Background checks (if applicable)
  - [ ] Termination procedures

- [ ] Information Access Management
  - [ ] Access authorization policies
  - [ ] Access establishment procedures
  - [ ] Access modification procedures

- [ ] Security Awareness and Training
  - [ ] Training program established
  - [ ] Security reminders distributed
  - [ ] Protection from malicious software training
  - [ ] Password management training

- [ ] Security Incident Procedures
  - [ ] Incident response plan
  - [ ] Incident documentation procedures
  - [ ] Reporting mechanisms

- [ ] Contingency Plan
  - [ ] Data backup plan
  - [ ] Disaster recovery plan
  - [ ] Emergency mode operation plan
  - [ ] Testing and revision procedures

Technical Safeguards Checklist

## Technical Safeguards

- [ ] Access Control
  - [ ] Unique user identification
  - [ ] Emergency access procedure
  - [ ] Automatic logoff
  - [ ] Encryption (at rest)

- [ ] Audit Controls
  - [ ] Audit logging implemented
  - [ ] Log review procedures
  - [ ] Log retention policy

- [ ] Integrity
  - [ ] Mechanism to authenticate ePHI
  - [ ] Integrity controls in place

- [ ] Authentication
  - [ ] Person/entity authentication
  - [ ] Strong password policy

- [ ] Transmission Security
  - [ ] Integrity controls (in transit)
  - [ ] Encryption (TLS 1.2+)

---

Quick Reference

Common HIPAA Violations

Penalty Structure

FDA-HIPAA Intersection

Quality System Regulation (QSR) — Historical Structure with QMSR/ISO 13485:2016 Mapping

## ⚠️ STATUS: QMSR transition — the QSR structure below is HISTORICAL

>

FDA's Quality Management System Regulation (QMSR) final rule (89 FR 7496) took effect February 2, 2026, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference and removing the QSR subsection structure documented in this guide. The section numbers used below (820.20–820.250) no longer exist in the CFR; they are retained here only as a familiar index into requirements that now flow from ISO 13485:2016 clauses.

>

What remains in 21 CFR 820 under the QMSR: 820.10 (requirements, incl. the ISO 13485:2016 incorporation by reference and Part 830 UDI linkage), 820.35 (records — complaint and servicing-record additions to ISO 13485), 820.45 (device labeling and packaging controls).

Unchanged: 21 CFR Parts 801 (labeling), 803 (MDR), 806 (corrections and removals), 830 (UDI).

>

Use the Regulatory Cross-References table at the end of this guide to map every historical QSR section to its current QMSR/ISO 13485:2016 authority. The implementation guidance and templates below remain useful — quality system expectations are substantially the same under ISO 13485 — but cite ISO 13485 clauses (or retained 820.10/.35/.45), not the historical subsection numbers, in current compliance documentation.

Implementation guide to the historical 21 CFR Part 820 (QSR) structure for medical device manufacturers, mapped to the QMSR/ISO 13485:2016 requirements now in force.

---

Table of Contents

• QSR Overview
• Management Responsibility (820.20)
• Design Controls (820.30)
• Document Controls (820.40)
• Purchasing Controls (820.50)
• Production and Process Controls (820.70-75)
• CAPA (820.100)
• Device Master Record (820.181)
• FDA Inspection Readiness

---

QSR Overview

Applicability

The QSR applies to:

• Finished device manufacturers
• Specification developers
• Initial distributors of imported devices
• Contract manufacturers
• Repackagers and relabelers

Exemptions

QSR Structure (historical, pre-2026-02-02)

21 CFR Part 820 Subparts (removed by the QMSR; historical reference only):
├── A - General Provisions (820.1-5)
├── B - Quality System Requirements (820.20-25)
├── C - Design Controls (820.30)
├── D - Document Controls (820.40)
├── E - Purchasing Controls (820.50)
├── F - Identification and Traceability (820.60-65)
├── G - Production and Process Controls (820.70-75)
├── H - Acceptance Activities (820.80-86)
├── I - Nonconforming Product (820.90)
├── J - Corrective and Preventive Action (820.100)
├── K - Labeling and Packaging Control (820.120-130)
├── L - Handling, Storage, Distribution, Installation (820.140-170)
├── M - Records (820.180-198)
├── N - Servicing (820.200)
└── O - Statistical Techniques (820.250)

---

Management Responsibility (820.20)

Quality Policy

Requirements:

• Documented quality policy
• Objectives for quality
• Commitment to meeting requirements
• Communicated throughout organization

Quality Policy Template:

## Quality Policy Statement

[Company Name] is committed to designing, manufacturing, and distributing
medical devices that meet customer requirements and applicable regulatory
standards. We achieve this through:

1. Maintaining an effective Quality Management System
2. Continuous improvement of our processes
3. Compliance with 21 CFR Part 820 and applicable standards
4. Training and empowering employees
5. Supplier quality management

Approved by: _______________  Date: _______________
Management Representative

Organization

Management Review

Frequency: At least annually (more frequently recommended)

Required Inputs: 1. Audit results (internal and external) 2. Customer feedback and complaints 3. Process performance metrics 4. Product conformity data 5. CAPA status 6. Changes affecting QMS 7. Recommendations for improvement

Required Outputs:

• Decisions on improvement actions
• Resource needs
• Quality objectives updates

Management Review Agenda Template:

## Management Review Meeting

Date: _______________
Attendees: _______________

### Agenda Items

1. Review of previous action items
2. Quality objectives and metrics
3. Internal audit results
4. Customer complaints summary
5. CAPA status report
6. Supplier quality performance
7. Regulatory updates
8. Resource requirements
9. Improvement opportunities

### Decisions and Actions
| Item | Decision | Owner | Due Date |
|------|----------|-------|----------|
|      |          |       |          |

### Next Review Date: _______________

---

Design Controls (820.30)

When Required

Design controls are required for:

• Class II devices (most)
• Class III devices (all)
• Class I devices with software
• Class I devices on exemption list exceptions

Design Control Process Flow

Design Input (820.30c)
    ↓
Design Output (820.30d)
    ↓
Design Review (820.30e)
    ↓
Design Verification (820.30f)
    ↓
Design Validation (820.30g)
    ↓
Design Transfer (820.30h)
    ↓
Design Changes (820.30i)
    ↓
Design History File (820.30j)

Design Input Requirements

Must Include:

• Intended use and user requirements
• Patient population
• Performance requirements
• Safety requirements
• Regulatory requirements
• Risk management requirements

Verification Criteria:

• Complete (all requirements captured)
• Unambiguous (clear interpretation)
• Not conflicting
• Verifiable or validatable

Design Output Requirements

Essential Requirements:

• Traceable to design inputs
• Contains acceptance criteria
• Identifies critical characteristics

Design Review

Review Stages: 1. Concept review (feasibility) 2. Design input review (requirements complete) 3. Preliminary design review (architecture) 4. Critical design review (detailed design) 5. Final design review (transfer readiness)

Participants:

• Representative of each design function
• Other specialists as needed
• Independent reviewers (no direct design responsibility)

Documentation:

• Meeting minutes
• Issues identified
• Resolution actions
• Approval signatures

Design Verification

Methods:

• Inspections and measurements
• Bench testing
• Analysis and calculations
• Simulations
• Comparisons to similar designs

Verification Matrix Template:

| Req ID | Requirement | Verification Method | Pass Criteria | Result |
|--------|-------------|---------------------|---------------|--------|
| REQ-001 | Dimension tolerance | Measurement | ±0.5mm | |
| REQ-002 | Tensile strength | Testing per ASTM | >500 MPa | |
| REQ-003 | Software function | Unit testing | 100% pass | |

Design Validation

Definition: Confirmation that device meets user needs and intended uses

Validation Requirements:

• Use initial production units (or equivalent)
• Simulated or actual use conditions
• Includes software validation

Validation Types: 1. Bench validation - Laboratory simulated use 2. Clinical validation - Human subjects (may require IDE) 3. Usability validation - Human factors testing

Design Transfer

Transfer Checklist:

## Design Transfer Verification

- [ ] DMR complete and approved
- [ ] Manufacturing processes validated
- [ ] Training completed
- [ ] Inspection procedures established
- [ ] Supplier qualifications complete
- [ ] Labeling approved
- [ ] Risk analysis updated
- [ ] Regulatory clearance/approval obtained

Design History File (DHF)

Contents:

• Design and development plan
• Design input records
• Design output records
• Design review records
• Design verification records
• Design validation records
• Design transfer records
• Design change records
• Risk management file

---

Document Controls (820.40)

Document Approval and Distribution

Requirements:

• Documents reviewed and approved before use
• Approved documents available at point of use
• Obsolete documents removed or marked
• Changes reviewed and approved

Document Control Matrix

Change Control

Change Request Process:

1. Initiate Change Request
   └── Description, justification, impact assessment

2. Technical Review
   └── Engineering, quality, regulatory assessment

3. Change Classification
   ├── Minor: No regulatory impact
   ├── Moderate: May affect compliance
   └── Major: Regulatory submission required

4. Approval
   └── Change Control Board (CCB) or designated authority

5. Implementation
   └── Training, document updates, inventory actions

6. Verification
   └── Confirm change implemented correctly

7. Close Change Request
   └── Documentation complete

---

Purchasing Controls (820.50)

Supplier Qualification

Qualification Criteria:

• Quality system capability
• Product/service quality history
• Financial stability
• Regulatory compliance history

Qualification Methods:

Approved Supplier List (ASL)

ASL Requirements:

• Supplier name and contact
• Products/services approved
• Qualification date and method
• Qualification status
• Re-evaluation schedule

Purchasing Data

Purchase Order Requirements:

• Complete product specifications
• Quality requirements
• Applicable standards
• Inspection/acceptance requirements
• Right of access for verification

---

Production and Process Controls (820.70-75)

Process Validation (820.75)

When Required:

• Process output cannot be fully verified
• Deficiencies would only appear after use
• Examples: sterilization, welding, molding

Validation Protocol Elements:

## Process Validation Protocol

### 1. Protocol Approval
Prepared by: _______________  Date: _______________
Approved by: _______________  Date: _______________

### 2. Process Description
[Describe process, equipment, materials, parameters]

### 3. Acceptance Criteria
| Parameter | Specification | Test Method |
|-----------|---------------|-------------|
|           |               |             |

### 4. Equipment Qualification
- IQ (Installation Qualification): _______________
- OQ (Operational Qualification): _______________
- PQ (Performance Qualification): _______________

### 5. Validation Runs
Number of runs: _____ (minimum 3)
Lot sizes: _____

### 6. Results Summary
| Run | Date | Parameters | Results | Pass/Fail |
|-----|------|------------|---------|-----------|
| 1   |      |            |         |           |
| 2   |      |            |         |           |
| 3   |      |            |         |           |

### 7. Conclusion
Process validated: Yes / No
Revalidation triggers: _____

Environmental Controls (820.70(c))

Controlled Conditions:

• Temperature and humidity
• Particulate contamination (cleanrooms)
• ESD (electrostatic discharge)
• Lighting levels

Monitoring Requirements:

• Continuous or periodic monitoring
• Documented limits
• Out-of-specification procedures
• Calibrated equipment

Personnel (820.70(d))

Training Requirements:

• Job-specific training
• Competency verification
• Retraining for significant changes
• Training records maintained

Training Record Template:

## Training Record

Employee: _______________ ID: _______________
Position: _______________

| Training Topic | Trainer | Date | Method | Competency Verified |
|----------------|---------|------|--------|---------------------|
|                |         |      |        | Signature: ________ |

Equipment (820.70(g))

Requirements:

• Maintenance schedule
• Calibration program
• Adjustment limits documented
• Inspection before use

Calibration (820.72)

Calibration Program Elements: 1. Equipment identification 2. Calibration frequency 3. Calibration procedures 4. Accuracy requirements 5. Traceability to NIST standards 6. Out-of-tolerance actions

---

CAPA (820.100)

CAPA Sources

• Customer complaints
• Nonconforming product
• Audit findings
• Process monitoring
• Returned products
• MDR/Vigilance reports
• Trend analysis

CAPA Process

1. Identification
   └── Problem statement, data collection

2. Investigation
   └── Root cause analysis (5 Whys, Fishbone, etc.)

3. Action Determination
   ├── Correction: Immediate fix
   └── Corrective/Preventive: Address root cause

4. Implementation
   └── Action execution, documentation

5. Verification
   └── Confirm actions completed

6. Effectiveness Review
   └── Problem recurrence check (30-90 days)

7. Closure
   └── Management approval

Root Cause Analysis Tools

5 Whys Example:

Problem: Device failed during use

Why 1: Component failed
Why 2: Component was out of specification
Why 3: Incoming inspection did not detect
Why 4: Inspection procedure inadequate
Why 5: Procedure not updated for new component

Root Cause: Document control failure - procedure not updated

Fishbone Categories:

• Man (People)
• Machine (Equipment)
• Method (Process)
• Material
• Measurement
• Environment

CAPA Metrics

---

Device Master Record (820.181)

DMR Contents

Device Master Record
├── Device specifications
│   ├── Drawings
│   ├── Composition/formulation
│   └── Component specifications
├── Production process specifications
│   ├── Manufacturing procedures
│   ├── Assembly instructions
│   └── Process parameters
├── Quality assurance procedures
│   ├── Acceptance criteria
│   ├── Inspection procedures
│   └── Test methods
├── Packaging and labeling specifications
│   ├── Package drawings
│   ├── Label content
│   └── IFU content
├── Installation, maintenance, servicing procedures
└── Environmental requirements

Device History Record (DHR) - 820.184

DHR Contents:

• Dates of manufacture
• Quantity manufactured
• Quantity released for distribution
• Acceptance records
• Primary identification label
• Device identification and control numbers

Quality System Record (QSR) - 820.186

QSR Contents:

• Procedures and changes
• Calibration records
• Distribution records
• Complaint files
• CAPA records
• Audit reports

---

FDA Inspection Readiness

Pre-Inspection Preparation

30-Day Readiness Checklist:

## FDA Inspection Readiness

### Documentation Review
- [ ] Quality manual current
- [ ] SOPs reviewed and approved
- [ ] Training records complete
- [ ] CAPA files complete
- [ ] Complaint files organized
- [ ] DMR/DHR accessible
- [ ] Management review records current

### Facility Review
- [ ] Controlled areas properly identified
- [ ] Equipment calibration current
- [ ] Environmental monitoring records available
- [ ] Storage conditions appropriate
- [ ] Quarantine areas clearly marked

### Personnel Preparation
- [ ] Escort team identified
- [ ] Subject matter experts briefed
- [ ] Front desk/reception notified
- [ ] Conference room reserved
- [ ] FDA credentials verification process

### Record Accessibility
- [ ] Electronic records accessible
- [ ] Backup copies available
- [ ] Audit trail functional
- [ ] Archive records retrievable

During Inspection

Escort Guidelines: 1. One designated escort with investigator at all times 2. Answer questions truthfully and concisely 3. Don't volunteer information not requested 4. Request clarification if question unclear 5. Get help from SME for technical questions 6. Document all requests and commitments

Record Request Tracking:

Post-Inspection

FDA 483 Response:

• Due within 15 business days
• Address each observation specifically
• Include corrective actions and timeline
• Provide evidence of completion where possible

Response Format:

## Observation [Number]

### FDA Observation:
[Copy verbatim from Form 483]

### Company Response:

#### Understanding of Observation:
[Demonstrate understanding of the concern]

#### Immediate Correction:
[Actions already taken]

#### Root Cause Analysis:
[Investigation findings]

#### Corrective Actions:
| Action | Responsible | Target Date | Status |
|--------|-------------|-------------|--------|
|        |             |             |        |

#### Preventive Actions:
[Systemic improvements]

#### Verification:
[How effectiveness will be verified]

---

Compliance Metrics Dashboard

Key Performance Indicators

Trend Analysis

Monthly Review Items:

• Complaint trends by product/failure mode
• NCR trends by cause code
• CAPA effectiveness
• Supplier quality
• Production yields
• Customer feedback

---

Quick Reference

Common 483 Observations

Regulatory Cross-References

Historical QSR sections (removed effective 2026-02-02) mapped to their current QMSR/ISO 13485:2016 authority:

Retained/renumbered under QMSR: 820.10 (requirements; incorporates ISO 13485:2016 by reference), 820.35 (records), 820.45 (device labeling and packaging controls). Unchanged: 21 CFR 801, 803, 806, 830.