Hipaa Compliance Check

---
name: hipaa-compliance-check
enabled: true
description: |
  Use when performing hipaa compliance check — hIPAA compliance review covering
  PHI handling, encryption requirements, access controls, audit logging,
  Business Associate Agreements, and breach notification readiness. Use for
  healthcare application assessments, vendor onboarding, or annual compliance
  reviews.
required_connections:
  - prefix: aws
    label: "AWS (or cloud provider)"
config_fields:
  - key: system_name
    label: "System / Application Name"
    required: true
    placeholder: "e.g., patient-portal"
  - key: phi_types
    label: "PHI Data Types Handled"
    required: true
    placeholder: "e.g., medical records, billing, demographics"
  - key: covered_entity
    label: "Covered Entity or Business Associate"
    required: true
    placeholder: "e.g., covered-entity, business-associate"
features:
  - COMPLIANCE
  - SECURITY
  - HEALTHCARE
---

# HIPAA Compliance Check Skill

Perform a HIPAA compliance review for **{{ system_name }}** handling **{{ phi_types }}** as a **{{ covered_entity }}**.

## Workflow

### Step 1 — PHI Data Mapping

Identify where PHI exists in the system:
1. **Data at rest**: Databases, file storage, backups, archives
2. **Data in transit**: API calls, message queues, email, file transfers
3. **Data in use**: Application memory, caches, logs, analytics
4. **Data derivatives**: Reports, exports, de-identified datasets

Document each PHI touchpoint with data type, location, and classification.

### Step 2 — Administrative Safeguards (§164.308)

```
ADMINISTRATIVE SAFEGUARDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Security Officer designated
[ ] Risk analysis conducted within last 12 months
[ ] Risk management plan documented and active
[ ] Workforce security: background checks for PHI access
[ ] Security awareness training completed by all workforce members
[ ] Sanctions policy for security violations documented
[ ] Information system activity review (audit log review) on schedule
[ ] Contingency plan: data backup, disaster recovery, emergency operations
[ ] Business Associate Agreements (BAAs) in place with all vendors handling PHI
[ ] BAA inventory current and reviewed annually
```

### Step 3 — Physical Safeguards (§164.310)

```
PHYSICAL SAFEGUARDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Facility access controls documented
[ ] Workstation use policies defined
[ ] Workstation security (screen lock, encryption)
[ ] Device and media controls for disposal and re-use
[ ] Cloud provider BAA covers physical security (AWS/GCP/Azure)
```

### Step 4 — Technical Safeguards (§164.312)

```
TECHNICAL SAFEGUARDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ACCESS CONTROL
[ ] Unique user identification for all PHI access
[ ] Emergency access procedure documented
[ ] Automatic session timeout (≤15 min inactivity)
[ ] Encryption of PHI at rest (AES-256 or equivalent)

AUDIT CONTROLS
[ ] Audit logs capture all PHI access (read, write, delete)
[ ] Audit logs are immutable and retained ≥6 years
[ ] Audit log review performed regularly
[ ] Failed login attempts logged and alerted

INTEGRITY CONTROLS
[ ] Data integrity checks on PHI (checksums, validation)
[ ] Mechanism to authenticate electronic PHI

TRANSMISSION SECURITY
[ ] PHI encrypted in transit (TLS 1.2+)
[ ] Email containing PHI encrypted
[ ] API endpoints handling PHI require authentication
[ ] VPN or private connectivity for PHI data flows
```

### Step 5 — Breach Notification Readiness (§164.400)

```
BREACH NOTIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Breach detection mechanisms in place
[ ] Breach risk assessment process documented
[ ] Individual notification procedure (within 60 days)
[ ] HHS notification procedure documented
[ ] Media notification procedure (>500 individuals)
[ ] Breach log maintained
[ ] Annual breach notification drill conducted
```

### Step 6 — Minimum Necessary & De-identification

```
DATA MINIMIZATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Minimum necessary standard applied to PHI access
[ ] Role-based access limits PHI to job function requirements
[ ] De-identification follows Safe Harbor or Expert Determination method
[ ] Analytics and reporting use de-identified data where possible
[ ] Test/staging environments use synthetic data (not production PHI)
```

### Step 7 — Compliance Summary

| Safeguard Area | Items Passed | Items Failed | Compliance Status |
|---------------|-------------|-------------|-------------------|
| Administrative | X/Y | Z | COMPLIANT/GAP |
| Physical | X/Y | Z | COMPLIANT/GAP |
| Technical | X/Y | Z | COMPLIANT/GAP |
| Breach Notification | X/Y | Z | COMPLIANT/GAP |
| Data Minimization | X/Y | Z | COMPLIANT/GAP |

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format

Produce a HIPAA compliance report with:
1. **System overview** (name, PHI types, entity type, data flow diagram)
2. **PHI data map** with all touchpoints identified
3. **Safeguard checklists** with COMPLIANT/GAP per item
4. **BAA status** for all vendors handling PHI
5. **Remediation plan** with prioritized findings, owners, and deadlines