Skip to main content

PHI Handling Policy

Protected Health Information (PHI) Handling Policy

Purpose: Define controls and procedures for handling Protected Health Information in Bounded Health.

Scope

This policy applies to all individuals and systems that collect, access, use, or transmit Protected Health Information through the Bounded Health platform.

Definitions

Protected Health Information (PHI): Individually identifiable health information transmitted or maintained in any form or medium that relates to:

  • Past, present, or future physical or mental health condition
  • Provision of health care
  • Payment for health care

Minimum Necessary: The minimum amount of PHI needed to accomplish the intended purpose.

PHI Identification

Data Classified as PHI

The following data elements in Bounded Health are classified as PHI:

  1. Direct Identifiers:

    • Patient name (User.firstName, User.lastName)
    • Email address (User.email)
    • Phone number (PatientProfile.phone)
    • Medical Record Number (User.id internal)
  2. Health Information:

    • Height, weight, BMI (PatientProfile)
    • Medications and dosages (PatientProfile.currentMedications)
    • Medical conditions (PatientProfile.existingConditions)
    • Glucose levels and predictions (MealLog, TaperingLog)
    • Laboratory results (LabReport)
    • Medical images (MedicalImage)
    • Side effects and symptoms (TaperingLog.sideEffects)
  3. Dates:

    • Date of birth (PatientProfile.dateOfBirth)
    • Appointment dates
    • Test dates
    • Log timestamps
  4. Metadata:

    • IP addresses in logs (when associated with patient ID)
    • Device information (when associated with patient ID)

De-Identified Data

Data is considered de-identified when:

  • All 18 HIPAA identifiers are removed
  • Expert determination confirms no reasonable basis for re-identification

Access Controls

Authorization Requirements

Patient Access:

  • Patients can access only their own PHI

Employer Access:

  • Employers can access PHI only for patients referred by their organization
  • Limited to patients with sourceType: EMPLOYER_REFERRED
  • Must match EmployerProfile.organizationId

Admin Access:

  • Full PHI access for system administration and support
  • All access logged in audit trail
  • Requires role: ADMIN

Implementation References:

Minimum Necessary Standard

API Design:

  • APIs return only requested data fields
  • No "dump all PHI" endpoints
  • Pagination limits overfetch
  • Selective field inclusion via Prisma select and include

Example:

Data Transmission

Encryption in Transit

HTTPS Enforcement:

  • All HTTP traffic redirected to HTTPS
  • HSTS header enforces HTTPS: Strict-Transport-Security: max-age=31536000
  • TLS 1.2 or higher required

API Security:

  • All API endpoints require authentication
  • Session tokens transmitted via secure cookies
  • No PHI in URL parameters (use POST request body)

File Uploads:

  • Medical images and documents uploaded via multipart/form-data

  • Size limits prevent DoS attacks

Encryption at Rest

Database:

  • PostgreSQL encryption at rest (hosting provider responsibility)
  • Connection strings stored in environment variables only
  • Never commit credentials to source control

File Storage:

  • Google Cloud Storage with default encryption
  • Access via signed URLs with time-limited tokens

Data Retention and Disposal

See: docs/compliance/DATA_RETENTION_POLICY.md

Retention Period:

  • PHI retained as required by applicable law (typically 6-7 years)
  • Configurable per organizational policy

Disposal:

  • Secure deletion from all storage systems
  • Cascade deletion via database foreign keys
  • File deletion from cloud storage
  • Audit log retention per policy

Breach Notification

See: docs/compliance/BREACH_NOTIFICATION.md

Immediate Actions:

  1. Contain the breach
  2. Assess scope and risk
  3. Document the incident
  4. Notify appropriate parties per policy

Audit and Monitoring

Audit Logging

All PHI Access Logged:

  • Read operations

  • Create/update/delete operations

  • Failed authorization attempts

  • Administrative actions

  • Retention: Per data retention policy

Audit Log Review:

  • Regular review by security team (organizational responsibility)
  • Automated alerts for suspicious patterns (future enhancement)
  • Available via admin dashboard

Monitoring

Security Monitoring:

  • Error tracking via Sentry
  • Failed authentication attempts logged

Performance Monitoring:

  • API endpoint monitoring
  • Database query performance
  • File upload monitoring

Third-Party Vendors

Business Associate Agreements (BAA)

Required for vendors processing PHI:

  • Cloud hosting provider (AWS/Vercel/GCP)
  • Email service (SendPulse)
  • SMS service (Africa's Talking)
  • Payment processor (Paystack)
  • Error tracking (Sentry)
  • Authentication (Clerk)

Template: docs/compliance/BAA_TEMPLATE.md

Vendor Security Requirements

All vendors processing PHI must:

  • Execute BAA with covered entity
  • Maintain SOC 2 Type II or equivalent certification
  • Provide encryption at rest and in transit
  • Report breaches within 24-48 hours
  • Support data deletion requests

Developer Responsibilities

Code Review Requirements

PHI Access:

  • All PHI access must include authorization check
  • Use requireClerkUser() + authorizePatientAccess()
  • Never bypass authorization for convenience

Logging:

  • Do not log PHI in application logs

  • Audit logs are separate from application logs

Testing:

  • Use synthetic test data only
  • Never use production PHI in development/test environments
  • Sanitize data exports for testing

Secure Coding Practices

Input Validation:

  • Validate all user input

SQL Injection Prevention:

  • Use Prisma ORM exclusively
  • Never construct raw SQL with user input
  • Parameterized queries only

XSS Prevention:

  • React escapes output by default
  • CSP headers prevent inline scripts
  • Validate HTML input via DOMPurify (if accepting rich text)

Incident Response

PHI Breach Response

  1. Immediate Containment:

    • Disable compromised accounts
    • Revoke leaked credentials
    • Block unauthorized IP addresses
  2. Assessment:

    • Identify affected patients and data elements
    • Determine breach cause and scope
    • Document timeline and actions taken
  3. Notification:

    • Follow docs/compliance/BREACH_NOTIFICATION.md
    • Notify affected individuals
    • Report to HHS if required (500+ individuals)
    • Notify media if required (local jurisdiction)
  4. Remediation:

    • Fix vulnerability
    • Deploy patches
    • Update security controls
    • Conduct post-incident review

Training Requirements

All Personnel Must Complete:

  • HIPAA Privacy and Security training (annually)
  • Role-specific training (at hire and annually)
  • System access training before PHI access granted

Topics:

  • PHI definition and identification
  • Minimum necessary standard
  • Access controls and authorization
  • Breach reporting procedures
  • Secure disposal practices

Sanctions

Violations of this policy may result in:

  • Access revocation
  • Disciplinary action
  • Termination of employment/contract
  • Legal action as warranted

Examples of Violations:

  • Accessing PHI without authorization
  • Sharing credentials
  • Bypassing access controls
  • Failing to report suspected breaches
  • Logging PHI in application logs