Protecting PHI on Websites

Protected health information is any information that identifies an individual and relates to their health condition, care, or payment. On a healthcare website, PHI can appear in expected and unexpected places:

• Patient portals: Medical records, lab results, visit summaries, prescription history
• Appointment systems: Appointment type often reveals condition; confirmation emails typically contain PHI
• Web forms: Any form field where patients enter health information
• URL parameters: Some systems include patient IDs, appointment types, or diagnostic codes in URLs — these appear in server logs, browser history, and referrer headers
• Page titles and metadata: A page titled with a patient's appointment type creates PHI in browser history and analytics pageview data
• Chat transcripts: Live chat sessions where patients discuss health concerns

One of the most overlooked PHI risks is PHI embedded in URLs. When a URL contains a patient ID, diagnosis code, medication name, or appointment type, that URL becomes PHI. It is then logged by:

• Your web server access logs
• Any reverse proxies or CDN providers in your infrastructure
• Browser history on patient devices
• Third-party analytics tools via referrer URLs
• Google Search Console and similar tools if they are enabled

Design your URL structure to avoid PHI. Use opaque session tokens rather than meaningful patient identifiers in URLs. Use POST requests rather than GET requests for sensitive operations so data is not embedded in the URL.

The HIPAA Security Rule requires encryption as an addressable specification for PHI at rest and as an effectively required control for PHI in transit. For websites, this means:

In transit: All pages, and especially pages that display or accept PHI, must use HTTPS with modern TLS. This is non-negotiable. Mixed content (HTTP resources on HTTPS pages) undermines this protection.

At rest: Databases storing PHI should use encrypted storage volumes (at minimum) and ideally column-level encryption for the most sensitive fields. Files containing PHI in object storage (S3, GCS, Azure Blob) should use server-side encryption with managed keys. Backup files must also be encrypted.

HIPAA Guard checks your transmission security configuration as part of every scan, flagging SSL misconfigurations and mixed content that could expose PHI in transit.

The Privacy Rule's minimum necessary standard requires that PHI access be limited to those who need it to do their jobs. For websites, this translates into access control architecture:

• Patient portal users should only be able to access their own records
• Staff roles should be granular — a front desk employee should not have access to clinical notes
• Administrative access to website backends (CMS, database management tools) should be restricted to named individuals with documented business need
• API keys and service accounts should have minimum-necessary permissions — a read-only integration should not have write permissions
• All access should be logged, and logs should be reviewed regularly for anomalies

Every third-party integration your website uses is a potential PHI disclosure point. Conduct a data flow mapping exercise for each integration:

• What PHI (if any) does this integration receive?
• Is the integration covered by a BAA?
• Where does the integration store the data it receives?
• Can you configure the integration to minimize PHI transmission?
• Does the integration vendor have appropriate security certifications?

Common integration types that warrant PHI scrutiny: CRM systems, marketing email platforms, scheduling tools, telehealth platforms, payment processors (if procedure codes are included in payment data), and customer support platforms.