Protected Health Information Handling

Purpose

Identify and handle PHI in software to enforce minimum necessary use, encryption, access control, and retention/deletion policies.

When to Apply

• •Any feature storing/transmitting patient data.
• •Logs, telemetry, backups, analytics, and interoperability.

Requirements (testable)

1. •PHI Identification: Classify data elements; mark PHI/PII; document flows. Rationale: scope controls.
2. •Minimum Necessary: Limit fields collected/stored/transmitted; justify PHI fields. Rationale: privacy by design.
3. •Encryption: Encrypt PHI in transit (TLS 1.3) and at rest; keys protected. Rationale: confidentiality.
4. •Access Control: Enforce authz for PHI access; role/need-to-know; audit accesses. Rationale: accountability.
5. •Logging/Sanitization: Avoid PHI in logs; if required, mask or tokenize. Rationale: reduce leakage.
6. •Retention/Deletion: Define retention; implement deletion or de-ID on expiry; verify. Rationale: compliance.
7. •Data Export/Interoperability: Apply same controls to exports; ensure standards-based fields are properly scoped. Rationale: consistent protection.

Recommended Practices

• •Use data flow diagrams marking PHI.
• •Apply structured logging with explicit allowlists.
• •Tokenize identifiers where possible; separate identity from clinical data.
• •Encrypt backups and ensure access controls on storage buckets.

Patterns

Sanitized logging:

// REQ-PHI-LOG-01; TEST-PHI-04
log_info("evt=device_connect id=%s", anonymized_id(dev_id));

Retention check (pseudo):

# REQ-PHI-RET-02; TEST-PHI-06
delete_records_older_than(days=365)

Data classification entry:

field: patient_name
phi: true
justification: required for clinician display

Anti-Patterns (risks)

• •Dumping raw PHI to logs -> risk: breach.
• •Transmitting PHI over plaintext or weak TLS -> risk: exposure.
• •No retention/deletion -> risk: excessive data and regulatory noncompliance.
• •Broad access without RBAC -> risk: unauthorized disclosure.

Verification Checklist

• • PHI fields identified and documented in data flows.
• • Minimum necessary enforced; unnecessary fields removed.
• • PHI encrypted in transit and at rest; keys protected.
• • Access control and auditing applied to PHI access.
• • Logs/telemetry sanitized; no raw PHI unless justified and protected.
• • Retention/deletion implemented and verified; backups included.
• • Exports/interoperability apply same protections.

Traceability

• •REQ-PHI-### to tests TEST-PHI-###; link to security requirements and privacy policies.

References

• •HIPAA Security/Privacy Rules (US).
• •EU GDPR principles; data minimization/retention.
• •FDA cybersecurity guidance (PHI protection).

Changelog

• •1.0.0 (2026-01-04): Initial PHI handling skill with classification, minimization, encryption, and retention.

Audit History

• •2026-01-04: Audit performed. Verified:
  • •HIPAA Security/Privacy Rule references appropriate
  • •EU GDPR data minimization/retention principles correctly noted
  • •PHI handling patterns align with industry best practices