Phi Handling

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