hipaa

Files (1)

• SKILL.md

SKILL.md (first lines)

# HIPAA Compliance Review

## Gate: Project Activation Check

**This skill is project-specific.** Check for the activation marker before proceeding:

```bash
if [ ! -f ".hipaa" ]; then
  echo "NOT_ACTIVE"
fi
```

If `.hipaa` does not exist, tell the user:

> This project is not marked as HIPAA-regulated. To activate HIPAA reviews, run:
> ```
> touch .hipaa
> ```
> Add `.hipaa` to `.gitignore` if you don't want it tracked.

Then stop — do not run the review.

---

## Step 1: Load Project Context

Read `.hipaa` for project-specific HIPAA configuration (if it contains content):
```
# .hipaa file can optionally contain:
# phi_fields: ssn, dob, mrn, diagnosis, medication, insurance_id
# data_stores: postgres, s3, redis
# auth_model: oauth2, session, jwt
# covered_entity: yes/no
# baa_required: list of third-party services
```

Read `.claude/stack.md` and `.claude/project-context.md` if they exist.

## Step 2: PHI Exposure Scan

Search for PHI leaking into unsafe locations. PHI includes: names, addresses, dates
(birth, admission, discharge, death), SSN, MRN, phone, email, biometric, photos,
account numbers, certificate/license numbers, device identifiers, URLs, IPs,
diagnosis, medication, lab results, insurance info.

### 2.1 PHI in Logs

Search for logging calls that may include PHI fields:

```
Pattern: log\.(info|warn|error|debug)|logger\.|console\.(log|warn|error)|print\(|println!|tracing::(info|warn|error|debug)
```

Flag any log statement that includes:
- User/patient object serialization (e.g., `log.info(f"User: {user}")`)
- Medical record fields (diagnosis, medication, lab results)
- Direct identifiers (SSN, MRN, DOB, name, address, phone, email)
- Request/response body dumps containing patient data

**PASS:** Logs contain only IDs, timestamps, operation names, error codes
**FAIL:** Logs contain PHI fields, full objects with PHI, or patient-facing data

### 2.2 PHI in Error Messages / API Responses

Search for error handlers and API responses:

- Error responses should never include PHI in the message body
- Stack traces sent to clients must be scrubbed
- API responses should use minimum necessary principle (only fields the requester needs)

### 2.3 PHI in URLs / Query Parameters

```
Pattern: \?(.*)(ssn|dob|name|mrn|patient|diagnosis|medication)
```

PHI must never appear in URLs or query strings — these get logged by web servers,
proxies, and browsers.

### 2.4 PHI in Client-Side Storage

For web/mobile apps, check for PHI stored in:
- localStorage / sessionStorage
- Cookies (especially without Secure + HttpOnly flags)
- IndexedDB without encryption
- Mobile app shared preferences / UserDefaults without encryption

## Step 3: Encryption Verification

### 3.1 Data at Rest

Check that databases and file stores use encryption:

- Database connections should specify `sslmode=require` or equivalent
- S3 buckets should use server-side encryption (`SSE-S3` or `SSE-KMS`)
- Local file storage of PHI must use AES-256 or equivalent
- Backup encryption must be verified
- Encryption keys must not be in source code or committed configs

### 3.2 Data in Transit

- All HTTP endpoints must use TLS (no `http://` in production configs)
- Internal service-to-service communication should use TLS or mTLS
- Database connections must use SSL/TLS
- HSTS headers should be set

### 3.3 Encryption Key Management

Flag:
- Hardcoded encryption keys or secrets
- Keys stored alongside encrypted data
- Use of weak algorithms (DES, 3DES, MD5 for hashing, SHA1 for signatures)
- Missing key rotation mechanism

## Step 4: Access Controls

### 4.1 Authentication

Verify:

From aitechnerd/ai-dev-team, MIT.

More from aitechnerd/ai-dev-team