Definition of PHI

PHI, which stands for Protected Health Information, is any individually identifiable health information that is created, received, maintained, or transmitted by a HIPAA-covered entity or its business associates. It is the single most regulated category of data in the U.S. healthcare system.

PHI includes any information that relates to a patient’s past, present, or future physical or mental health condition, the provision of healthcare, or payment for healthcare — and that can identify the individual or could reasonably be used to identify them.

HIPAA defines 18 specific identifiers that make health data PHI:

Names
Geographic data smaller than a state
Dates (except year) related to an individual — birth date, admission date, discharge date, date of death
Phone numbers
Fax numbers
Email addresses
Social Security numbers
Medical record numbers
Health plan beneficiary numbers
Account numbers
Certificate/license numbers
Vehicle identifiers and serial numbers
Device identifiers and serial numbers
Web URLs
IP addresses
Biometric identifiers (fingerprints, voiceprints)
Full-face photographs and comparable images
Any other unique identifying number, characteristic, or code

If health data includes any one of these 18 identifiers, it is PHI and is subject to HIPAA’s full protection requirements.

PHI exists in multiple forms — electronic PHI (ePHI) stored in EHR systems and databases, paper PHI in printed records and faxes, and oral PHI communicated verbally between providers. The HIPAA Security Rule specifically governs ePHI, while the Privacy Rule covers PHI in all forms.

In simple terms: PHI is health data plus identity. Remove the identity, and it’s just health data. Keep it attached, and you’re holding the most regulated information in healthcare.

How PHI Works in Healthcare

PHI flows through nearly every system in a healthcare organization. Understanding where it lives, how it moves, and who touches it is the foundation of HIPAA compliance.

PHI creation. Every clinical encounter generates PHI — from the moment a patient registers with their name and insurance information to the provider documenting a diagnosis and prescribing medication. Lab results, imaging reports, billing records, and referral letters all contain PHI the instant they’re linked to a patient identity.

PHI storage. PHI is stored across multiple systems — EHR/EMR platforms, practice management software, lab information systems, radiology information systems, billing platforms, and patient portals. It also lives in less obvious places: email inboxes, backup tapes, cloud storage buckets, developer staging environments, and even analytics databases if de-identification wasn’t performed properly.

PHI transmission. PHI moves between systems and organizations constantly — HL7 messages carrying lab results, FHIR API calls serving patient data to mobile apps, C-CDA documents shared through health information exchanges, EDI claims submitted to payers, and secure messages sent between providers. Every transmission channel must be encrypted and access-controlled.

PHI access and authorization. HIPAA’s “minimum necessary” standard requires that workforce members access only the PHI they need to perform their specific job function. Role-based access controls (RBAC) in healthcare systems enforce this — a billing clerk shouldn’t see clinical notes, and a nurse shouldn’t see payment history. Every access event must be logged and auditable.

PHI de-identification. When organizations want to use health data for research, analytics, or AI model training without HIPAA restrictions, they must de-identify it. HIPAA defines two methods: the Expert Determination method (a statistical expert certifies the risk of identification is very small) and the Safe Harbor method (all 18 identifiers are removed). De-identified data is no longer PHI and is not subject to HIPAA rules.

Key PHI Standards and Specifications

PHI is governed primarily by HIPAA, but the regulatory landscape extends further:

HIPAA Privacy Rule

The Privacy Rule establishes national standards for when and how PHI can be used and disclosed. It defines permitted uses (treatment, payment, healthcare operations) and requires patient authorization for most other disclosures. It also gives patients the right to access their own PHI, request corrections, and receive an accounting of disclosures.

HIPAA Security Rule

The Security Rule specifically covers ePHI and requires covered entities and business associates to implement administrative, physical, and technical safeguards. Key requirements include access controls, audit controls, integrity controls, transmission security (encryption), and contingency planning. For a detailed technical breakdown, see our guide on HIPAA-compliant cloud architecture.

HIPAA Breach Notification Rule

When unsecured PHI is accessed, used, or disclosed in a way not permitted by the Privacy Rule, it triggers a breach. Covered entities must notify affected individuals, the HHS Secretary, and (for breaches affecting 500+ individuals) the media. The penalties are severe — see HIPAA violation penalties explained.

HIPAA Business Associate Agreements (BAAs)

Any third party that creates, receives, maintains, or transmits PHI on behalf of a covered entity must sign a Business Associate Agreement. This includes cloud providers, software vendors, billing companies, consultants, and shredding services. No BAA means no legal authority to handle PHI.

State-Level Health Data Privacy Laws

HIPAA sets the federal floor, but many states have enacted stricter health data privacy laws. Washington’s My Health My Data Act, Connecticut’s health data provisions, and California’s CCPA/CPRA all impose additional obligations on organizations handling health-related data — sometimes extending beyond HIPAA-covered entities to consumer health apps and wearables.

42 CFR Part 2

Substance use disorder treatment records receive additional federal protection under 42 CFR Part 2, which imposes stricter consent requirements than HIPAA for sharing this category of PHI. Healthcare systems that handle behavioral health data must implement separate consent management workflows.

Implementation Considerations

Any healthcare software system that touches PHI must be designed with HIPAA compliance as a foundational architectural requirement — not a checkbox at the end.

Encryption is non-negotiable. ePHI must be encrypted at rest (AES-256) and in transit (TLS 1.2+). This applies to databases, file storage, API calls, message queues, backups, and log files. Unencrypted PHI is considered “unsecured” under HIPAA, and any unauthorized access to it automatically triggers breach notification requirements.

Access controls must be granular. Implement role-based access controls that enforce the minimum necessary standard. Every user role should have explicitly defined permissions for what PHI they can view, create, modify, and export. Privileged access (database admins, DevOps) requires additional controls and monitoring.

Audit logging must be comprehensive. Every access to PHI — read, write, update, delete, export — must be logged with user identity, timestamp, data accessed, and action taken. Logs must be tamper-resistant and retained for a minimum of six years under HIPAA. Organizations building on cloud infrastructure should leverage healthcare data governance frameworks to manage this.

De-identification requires rigor. If you’re building analytics, machine learning, or AI-powered healthcare tools, you need a robust de-identification pipeline. The Safe Harbor method is more straightforward but removes more data. Expert Determination preserves more analytical value but requires qualified statistical analysis. Getting de-identification wrong means your “anonymous” dataset is still PHI — and still regulated.

Cloud deployments need BAAs and compliant infrastructure. AWS, Azure, and GCP all offer HIPAA-eligible services — but not all services within those platforms are covered. Your architecture must use only BAA-covered services, and you must configure them according to the provider’s shared responsibility model.

Development and testing environments matter. PHI must never appear in non-production environments without the same security controls as production. Use synthetic data or properly de-identified datasets for development, QA, and staging. This is one of the most common compliance gaps in healthcare software development.

Mobile and telehealth apps create additional PHI exposure. When PHI leaves the controlled environment of a hospital network and lives on a patient’s phone or flows through a video call, additional safeguards are required — device-level encryption, secure session management, remote wipe capabilities, and HIPAA-compliant app architecture.

How Taction Helps with PHI

At Taction, every healthcare system we build is designed around PHI protection from day one. Our engineering team understands not just the technical requirements, but the regulatory context that drives them.

What we do:

HIPAA-compliant software architecture — We design systems with PHI protection built into the foundation — encryption, access controls, audit logging, and secure data flows — not retrofitted after development. See our HIPAA compliance consulting services for a full overview.
PHI security assessments — We audit existing healthcare applications for PHI exposure risks, identifying gaps in encryption, access controls, logging, and data handling practices.
De-identification pipelines — We build automated de-identification workflows for organizations that need to leverage health data for research, analytics, or AI without triggering HIPAA obligations.
Secure cloud infrastructure — We architect and deploy HIPAA-compliant cloud environments on AWS, Azure, and GCP with proper BAA coverage, service selection, and security configuration.
Breach readiness — We help organizations build incident response and risk management capabilities so that when security events occur, the response is fast, compliant, and well-documented.

Whether you’re building a new healthcare application that handles PHI, auditing an existing system for compliance gaps, or preparing for a SOC 2 or HITRUST certification, our team brings the domain expertise to keep patient data protected and your organization compliant.

Related Terms and Resources

Explore related glossary terms:

What is Information Blocking? — ONC rules on when PHI must be shared, not withheld
What is HITRUST? — Security framework commonly used to validate PHI protection
What is SDoH? — Social Determinants of Health data increasingly captured alongside PHI
What is Blockchain in Healthcare? — Distributed ledger approaches to securing PHI
What is mHealth? — Mobile health apps that create and transmit PHI outside hospital walls

Helpful resources:

SOC 2 vs HIPAA for Healthcare Software — Understanding which compliance framework applies

What is PHI? (Protected Health Information)

Tell Us Your Requirements