A Practical Guide to Understanding PHI Protected Health

This guide explains Understanding PHI Protected Health in practical terms, with a focus on privacy-first analytics decisions.

Protected Health Information, or PHI, is health information that identifies a person or could reasonably be used to identify them when it is created, received, maintained, or transmitted by a HIPAA covered entity or business associate. That definition matters because healthcare websites, patient portals, and analytics tools can create PHI in places teams do not expect.

This article is not legal advice, but it gives product, marketing, and analytics teams a practical way to think about HIPAA risk.

Who HIPAA Applies To

HIPAA applies to covered entities and business associates. Covered entities include health plans, healthcare clearinghouses, and healthcare providers that conduct certain electronic transactions. Business associates are vendors or partners that create, receive, maintain, or transmit PHI on behalf of covered entities.

A general wellness blog may not be a covered entity. A hospital, clinic, telehealth provider, insurer, or vendor handling patient data for one of those organizations likely has HIPAA obligations.

What Makes Information PHI

Information becomes PHI when three elements come together:

1. It relates to health, healthcare provision, or payment for healthcare
2. It identifies the person or could reasonably identify them
3. It is held or transmitted by a covered entity or business associate

A diagnosis code in a hospital record is PHI. An email address submitted through a clinic appointment form can be PHI. An IP address combined with authenticated portal activity may be PHI. Context matters.

The 18 HIPAA Identifiers

HIPAA's de-identification safe harbor requires removal of 18 identifiers, including names, smaller-than-state geographic details, dates related to an individual, phone numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate or license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number or characteristic.

Removing obvious names is not enough. URLs, IP addresses, device identifiers, and account numbers are especially relevant to analytics teams.

Online Tracking Technologies

HHS OCR has issued guidance on online tracking technologies used by HIPAA-regulated entities. The current HHS page notes that a federal court vacated part of the guidance to the extent it said HIPAA obligations are triggered when an online technology connects an IP address with a visit to an unauthenticated public webpage about health conditions or providers. HHS says it is evaluating next steps, while the bulletin continues to highlight HIPAA obligations for regulated entities using tracking technologies (HHS OCR tracking technologies guidance).

The nuance matters. Do not oversimplify the rule as "every health page view is always PHI." But do not assume analytics is safe either, especially on authenticated pages, appointment flows, patient portals, or pages where users provide health-related information.

Analytics Risk Scenarios

High-risk analytics patterns include:

• Tracking patient portal pages with third-party analytics
• Sending appointment form fields to analytics events
• Recording session replay on intake forms
• Using ad pixels on condition or treatment pages
• Sending full URLs with patient IDs, tokens, or search queries
• Retargeting visitors who viewed sensitive health content
• Sharing conversion events with ad platforms without a compliant agreement

Even if a vendor signs a standard data processing agreement, HIPAA may require a Business Associate Agreement. Many advertising and analytics vendors will not sign BAAs for certain products.

Safer Measurement For Healthcare Sites

Healthcare organizations should separate public education analytics from patient data systems. For public pages, use privacy-first, aggregate analytics with no persistent identifiers where possible. For authenticated portals, be extremely conservative: log operational events internally, limit access, avoid third-party scripts, and involve privacy and security teams before adding any tracking.

Do not send PHI to analytics tools unless the vendor is authorized, the use is permitted, and the right agreements and safeguards are in place.

Practical Checklist

Before deploying analytics on a healthcare site, ask:

• Are we a covered entity or business associate?
• Is the page authenticated or unauthenticated?
• Could the page URL, title, search query, or event reveal health information?
• Are identifiers such as IP address, cookie ID, account ID, or device ID collected?
• Does the vendor sign a BAA for this exact product and use?
• Are ad features, remarketing, and data sharing disabled?
• Are forms, portals, and appointment flows excluded from third-party scripts?
• Are retention and access controls appropriate?

Healthcare Analytics Review Checklist

Separate public education measurement from appointment, portal, intake, payment, condition-specific, and authenticated workflows. The HHS tracking guidance remains nuanced after litigation, so do not claim every public health page view is automatically PHI; assess the page context, identifiers, user actions, and the organization's HIPAA role.

Before a healthcare tag ships, confirm whether the vendor may receive PHI, whether it signs a BAA for that exact product and use, which identifiers are collected, how long raw data is retained, and who can access it. Keep analytics payloads free of names, emails, patient or record numbers, appointment details, form text, sensitive query strings, and identifiers that can link a visitor to care.

The Bottom Line

PHI is not limited to medical charts. In digital systems, identifiers and health context can combine quickly. Analytics teams should treat healthcare measurement as a high-sensitivity use case and default to data minimization.

For many healthcare websites, the safest analytics approach is aggregate, cookieless, first-party measurement for public content and no third-party tracking on authenticated or transactional health workflows.

De-Identification Is Not A Shortcut For Raw Analytics

HIPAA allows de-identification through safe harbor or expert determination, but raw web analytics rarely starts de-identified. IP addresses, URLs, device IDs, timestamps, and account identifiers may all be present before any aggregation. If a healthcare organization wants analytics reports that are no longer PHI, de-identification should happen before broad sharing, not as an assumption after collection.

For practical reporting, aggregate early. Report counts by page category, campaign, or device type rather than exposing event-level data. Keep small-cell suppression in mind when a report could identify a patient by uniqueness.

Do Not Forget Security Rule Duties

If analytics data is electronic PHI, the HIPAA Security Rule becomes relevant. That means access controls, audit controls, integrity safeguards, transmission security, and risk analysis. Marketing teams should not be the only owners of healthcare analytics decisions; security and compliance teams need visibility before tools go live.