PHI is not just a compliance checkbox. It is the most targeted data category in cybersecurity, and mishandling even a single identifier can cost your organization $7.42 million on average. If you manage IT systems, SaaS applications, or access controls in a healthcare-adjacent environment, understanding exactly what qualifies as protected health information, where it lives in your stack, and how to lock it down is non-negotiable.
This article covers the definitive list of PHI identifiers, real-world examples, the line between PHI and non-PHI, breach consequences, and how SaaS and identity governance protect it at scale.
Protected health information (PHI) is information, including demographic information, that relates to an individual's past, present, or future physical or mental health or condition; the provision of health care to the individual; or the past, present, or future payment for the provision of health care to an individual, and that identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual.
The word "protected" carries legal weight. PHI under HIPAA is individually identifiable health information collected or maintained by an organization that qualifies as a HIPAA-covered entity or business associate. (What is Considered PHI under HIPAA?) Strip one of those conditions, the health context, the identifiability, or the covered-entity relationship, and the information may fall outside HIPAA's jurisdiction entirely.
The U.S. Department of Health and Human Services issued the Privacy Rule to implement HIPAA requirements. The Privacy Rule standards address the use and disclosure of individuals' health information by organizations subject to the Privacy Rule, called "covered entities", as well as standards for individuals' privacy rights to understand and control how their health information is used.
HIPAA requires removing 18 specific identifiers to de-identify PHI and protect patient privacy. These identifiers include anything that could reveal a person's identity when handling healthcare data. (18 HIPAA Identifiers for PHI De-Identification | Censinet, Inc.) Knowing all 18 is the foundation of compliance, not an advanced topic.
A patient's full name, first, last, or combined, is PHI the moment it appears alongside health data. A spreadsheet column labeled "Patient" that holds "Jane Smith" next to a diagnosis code is a PHI record, full stop.
All geographic subdivisions smaller than a state, including street address, city, county, precinct, zip code, and their equivalent geocodes (List of HIPAA Identifiers - DHCS - CA.gov), qualify as PHI identifiers. Even a zip code attached to a medical record creates protected data.
Dates related to the health or identity of an individual, including birthdates, date of admission, date of discharge, date of death, and exact age of a patient older than 89 (What Are the 18 HIPAA PHI Identifiers | HHS HIPAA Identifiers List), are all identifiers. A discharge date tied to a name is PHI. Aggregate calendar years are not.
Any telephone number, mobile, landline, or VoIP, linked to a patient's health record constitutes PHI. This includes numbers stored in appointment reminders or contact logs inside SaaS platforms.
Fax numbers are explicitly listed as PHI identifiers. Fax transmissions carrying medical records remain one of the most common vectors for unintentional PHI disclosure in healthcare operations.
A patient's email address tied to a health record is PHI. Secure email tools exist precisely because standard email transmission does not meet HIPAA's minimum security requirements.
Social Security Numbers are among the highest-risk identifiers; they enable identity theft when combined with any health data. Treat every SSN in your systems as a five-alarm data asset.
A medical record number (MRN) uniquely links a patient to their health history. MRNs are PHI even when appearing without a name, because the number alone points directly to an individual record.
Insurance member IDs and beneficiary numbers connect individuals to their coverage history. These numbers appear in billing files, EHR exports, and claims data, all high-risk surfaces.
Patient account numbers, used for billing and payment tracking, are PHI identifiers. They surface frequently in billing SaaS platforms and require the same protection as clinical identifiers.
Driver's license numbers, professional license numbers, and certificate identifiers that appear in patient records qualify. Healthcare organizations collect these during patient intake more often than they realize.
Vehicle identification numbers (VINs) and license plate numbers are identifiers under HIPAA, though context matters. If a hospital captures vehicle license plate numbers and credit card numbers used to pay for parking, and both data elements are stored in a separate database, they are not considered PHI because they do not relate to a patient's health, treatment, or payment. (What is Considered PHI under HIPAA? Updated for 2026)
Serial numbers for medical devices, pacemakers, infusion pumps, and wearables are PHI identifiers when associated with health information. The IoT surface area in modern hospitals makes this identifier increasingly consequential.
A patient-specific URL, such as a link to a personal health portal profile or a care plan document, is a PHI identifier if it can resolve to identifiable health information.
An IP address logged during a patient's telehealth session or patient portal login is a PHI identifier. Many IT teams underestimate this one. Log files from web applications in healthcare environments must be treated as PHI.
Biometric identifiers, including finger and voice prints, (HIPAA PHI: Definition of PHI and List of 18 Identifiers) are PHI. Fingerprint authentication systems and voice-based patient engagement platforms generate biometric data that must be handled under HIPAA's security framework.
Full face photographic images and any comparable images (HIPAA PHI: Definition of PHI and List of 18 Identifiers) are PHI. Patient photos in EHR systems, telehealth screenshots, and imaging files all qualify.
Any other unique identifying number, characteristic, or code, not including a unique code assigned by an investigator to code data, also constitutes a PHI identifier. (HIPAA PHI: Definition of PHI and List of 18 Identifiers) This catch-all clause exists to future-proof HIPAA against emerging data types.
A physician's progress note that references a patient's name, date of visit, and diagnosis is PHI. The same note stripped of all 18 identifiers is de-identified data and falls outside HIPAA's scope.
An Explanation of Benefits (EOB) sent to a patient, containing their name, account number, treatment date, and procedure codes, is PHI. It combines financial identifiers with health context, making it doubly sensitive.
Smartwatch heart rate data is not automatically PHI. It becomes PHI the moment a covered entity ingests it into a patient record or uses it to make treatment decisions. A fitness app operating independently of a healthcare provider does not qualify as a covered entity and therefore does not create PHI under HIPAA in most circumstances.
Health information by itself, without the 18 identifiers, is not considered PHI. For example, a dataset of vital signs by itself does not constitute protected health information. (HIPAA PHI: Definition of PHI and List of 18 Identifiers) De-identification methods, Safe Harbor (remove all 18 identifiers) and Expert Determination (statistical analysis confirming re-identification risk is very low), are the two HIPAA-approved pathways to research-safe datasets.
PHI, PII (personally identifiable information), and ePHI are related but distinct categories. PII includes any data that identifies a person's name, SSN, and address without requiring a health context. PHI is the subset of PII that involves health conditions, treatment, or payment within a covered-entity relationship.
The Privacy Rule establishes the rules governing the use and disclosure of identifiable health information in either paper or electronic format, otherwise known as PHI, by covered entities. The Security Rule establishes the security safeguards to be adopted to protect electronically identifiable health information, otherwise known as ePHI.
While PHI includes all forms of protected health data, ePHI focuses on the electronic data that covered entities create, receive, maintain, or transmit. The distinction is important because ePHI is subject to specific cybersecurity and privacy requirements under HIPAA to prevent unauthorized access, breaches, or disclosures.
The practical implication: your EHR database is ePHI. Handwritten patient intake forms are PHI but not ePHI. Both require protection; only ePHI triggers HIPAA's Security Rule controls.
Data stops being PHI under two conditions: when it is de-identified, or when it exits the covered-entity relationship entirely.
Some research studies may use health-related information that is personally identifiable because it includes personal identifiers such as name or address, but it is not considered PHI because the data are not associated with or derived from a healthcare service event, treatment, payment, operations, or medical records, and the data are not entered into medical records. (HIPAA PHI: Definition of PHI and List of 18 Identifiers)
Proper de-identification methods, such as the Safe Harbor method (removing all identifiers) or the Expert Determination method (statistical analysis to ensure low re-identification risk), are essential for HIPAA compliance. Remove all 18 identifiers using Safe Harbor, and you can share the data freely for research or analytics. Retain even one identifier alongside health data, and the full dataset reverts to PHI status. If a vital signs dataset includes medical record numbers, then the entire dataset is considered PHI and must be protected since it contains an identifier.
HIPAA is not an absolute prohibition on PHI disclosure. A covered entity is permitted, but not required, to use and disclose PHI without an individual's authorization for specific purposes, including treatment, payment, and health care operations.
A hospital may share a patient's records with a referring specialist without the patient's authorization. The treatment purpose overrides the consent requirement, but "treatment" has a defined scope and does not extend to unrelated disclosures.
A physician's office can transmit billing data, including diagnosis codes and patient identifiers, to an insurance carrier for claims adjudication. Payment operations are explicitly excluded from the authorization requirement.
Quality assurance reviews, staff training, compliance audits, and business planning activities conducted by the covered entity are all permitted uses of PHI. Third-party vendors involved in these activities must sign a Business Associate Agreement (BAA), the legal instrument that extends HIPAA obligations downstream.
The financial exposure from a PHI breach is not theoretical. HIPAA violations fall into a four-tier penalty system, determined by the level of knowledge and intent behind the breach. The OCR evaluates whether the organization was aware of the violation and how it responded after discovery. (HIPAA Breach Notification: Legal Risks and Penalties | Censinet, Inc.)
The minimum penalty for each violation increases to $141 for a covered entity or business associate that did not know, and could not have known by exercising reasonable diligence. The maximum penalty for most violations increases to $71,162. For willful neglect that is not timely corrected, the maximum increases to $2,134,831.
In 2024 alone, 22 investigations led to penalties or settlements, marking a busy enforcement year. (HIPAA Breach Notification: Legal Risks and Penalties | Censinet, Inc.) In fact, 2024 and 2025 had some of the highest-cost HIPAA violations recorded, with one state attorney general's fine exceeding $6 million. (HIPAA Violation Fines: The Top-10 Penalties for Compliance Issues | ChartRequest)
Criminal exposure is real, too. Penalties scale with intent: up to $50,000 and 1 year for simple wrongful disclosure; up to $100,000 and 5 years if under false pretenses; and up to $250,000 and 10 years when for commercial advantage, personal gain, or malicious harm. (Maximum Fine for HIPAA Violation: Comprehensive Compliance Guide and Requirements)
HIPAA requires healthcare organizations to notify affected individuals, the Department of Health and Human Services, and, sometimes, the media within 60 days of discovering a PHI breach. Delay that notification, and the fine increases. Delays or incomplete notifications can lead to steep fines, reputational damage, and even criminal charges.
PHI no longer resides only in EHR systems behind hospital firewalls. It now flows through dozens of SaaS applications, scheduling platforms, communication tools, billing software, and telemedicine apps that your IT team may not fully control. That dispersion is the core problem.
Encryption is the minimum viable technical safeguard for ePHI. HHS has proposed to require encryption of ePHI at rest and in transit, meaning all PHI stored in SaaS databases must be encrypted at rest using AES-256 or equivalent, and all data in transit must route through TLS 1.2 or higher. An unencrypted laptop stolen from a clinician is an automatic breach. An encrypted one is not, because the data is rendered unreadable to the thief.
PHI that is transmitted or maintained must be accessed only by those who need it to perform job functions. Least privilege means every user account, not just administrators, receives only the permissions required to do their job, and nothing beyond that. Quarterly access reviews are the mechanism. Manual reviews are slow and error-prone; automated reviews close the gap.
Shadow IT is the category of applications that employees adopt independently, outside of IT's formal approval process. In healthcare environments, shadow IT, reported by 86% of health system IT executives, is a direct PHI risk: a clinician syncing patient notes to a personal cloud storage account, or a billing coordinator using an unsanctioned productivity tool to store insurance information. You cannot protect data you cannot see.
Rehab for JAPAN, a healthcare company driving digital transformation in nursing care, confronted exactly this problem. Their rapid expansion created a tangle of unsanctioned SaaS applications and manually managed accounts. After implementing Josys, the IT team gained direct visibility into all SaaS applications linked to each employee account, enabling them to identify and contain shadow IT before it created compliance exposure.
Manual access management does not scale in healthcare IT. When a nurse changes roles, when a vendor contract ends, when a contractor's engagement concludes, the window between that event and the revocation of PHI access is where breaches incubate. AI-driven workflows close that window systematically.
Josys enables IT teams to run continuous, policy-driven access reviews across every connected SaaS application, automatically surfacing accounts with excessive permissions, dormant credentials, or mismatched roles. What previously took an IT administrator hours of spreadsheet reconciliation now resolves in minutes. Rehab for JAPAN reported that account issuance and termination tasks that previously took hours were completed in a fraction of the time after automating with Josys.
Provisioning based on role definitions, rather than individual requests, eliminates the accumulation of excess permissions over time. When a new nurse joins a health system, their access profile is generated automatically from a template tied to their job function. No manual entry means fewer errors, and fewer errors mean fewer unintended PHI exposures. Manual account issuance is documented as a source of misspellings and incorrect access permissions, both of which create security vulnerabilities in environments where PHI is at stake.
Unused licenses are not just a cost problem; they are a security surface. Every active account in a SaaS platform with PHI is a potential vector for unauthorized access, whether through credential theft or lateral movement. Josys identifies underutilized licenses across your SaaS portfolio, allowing IT teams to deactivate dormant accounts and reduce your exposure. Quantum Brilliance, operating across a globally dispersed team, used Josys to achieve a 30–50% reduction in SaaS spend by eliminating redundant licenses, while simultaneously tightening its security posture through automated offboarding and shadow IT detection.
PHI protection is not a documentation exercise; it is an operational discipline that spans every SaaS application, user account, and access policy in your environment. From correctly identifying all 18 HIPAA identifiers to automating access governance, the organizations that avoid breach fines and reputational damage are the ones that treat PHI security as a continuous process, not a one-time audit.
Josys gives IT and compliance teams the visibility, automation, and control to manage PHI-adjacent SaaS access at scale, from enforcing least privilege to detecting shadow IT to streamlining offboarding before dormant accounts become breach vectors. Book a demo with Josys to see how your team can build a defensible, audit-ready access governance framework – without the manual overhead.
Yes. A subject's initials cannot be used to code their data because the initials are derived from their name. (HIPAA PHI: Definition of PHI and List of 18 Identifiers) Initials are a derived identifier. When attached to health information, they constitute PHI and cannot serve as a de-identification code.
HIPAA does not explicitly prohibit storing PHI on servers located outside the U.S. However, covered entities and business associates remain fully liable for HIPAA compliance regardless of where data is physically stored. Any cloud vendor storing PHI internationally must sign a BAA and demonstrate equivalent technical safeguards. Most healthcare legal teams treat offshore PHI storage as high-risk without airtight contractual controls.
HIPAA's Privacy Rule requires covered entities to retain the documentation required by the Privacy Rule, not necessarily the PHI itself, for 6 years from the date of creation or the date it was last in effect, whichever is later. Medical record retention requirements vary by state and may exceed 6 years. Some states mandate retention of up to 10 years for adult records and longer for minors.
