What Is PHI (Protected Health Information)?

Protected health information (PHI) is individually identifiable health information that a HIPAA covered entity or business associate creates, receives, maintains or transmits, in electronic, paper or oral form. The definition sits in 45 CFR 160.103, and it covers far more than diagnoses: a name next to an appointment date, a billing record or an IP address logged by a patient portal can all be PHI.

Two things decide whether data is PHI. The first is the content: it relates to someone's health, health care or payment for health care, and it identifies the person or could reasonably be used to identify them. The second is the holder: under their applicability provisions, the HIPAA Privacy and Security Rules apply to health plans, health care clearinghouses, most health care providers and the vendors that handle PHI on their behalf. The same blood pressure reading is PHI in a hospital's EHR, while HHS guidance says that, unless an app is provided by a covered entity or its business associate, HIPAA generally does not protect data a person enters into a mobile app for personal use.

What Is Protected Health Information?

PHI is individually identifiable health information, in any form or medium, held or transmitted by a covered entity or its business associate. The regulation builds the term in three layers, all defined in 45 CFR 160.103.

1. Health information is any information, including genetic information, oral or recorded in any form, that is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse, and that relates to a person's past, present or future physical or mental health, the provision of health care to them, or payment for that care.
2. Individually identifiable health information is the subset of health information, including demographic information, that identifies the individual or where there is a reasonable basis to believe it can be used to identify them.
3. Protected health information is individually identifiable health information that is transmitted or maintained in electronic media or in any other form or medium.

The definition has four explicit exclusions: education records covered by FERPA, the student treatment records described at 20 U.S.C. 1232g(a)(4)(B)(iv), employment records a covered entity holds in its role as employer, and information about a person who has been deceased for more than 50 years.

Electronic protected health information (ePHI) is the part of PHI that is transmitted by or maintained in electronic media. The Privacy Rule protects all PHI. The Security Rule, with its administrative, physical and technical safeguards, applies to ePHI only, which in practice means almost every data platform, warehouse and AI pipeline in a modern health system.

Some examples make the boundary concrete.

Who Must Protect PHI?

HIPAA obligations attach to covered entities and their business associates. A covered entity is a health plan, a health care clearinghouse, or a health care provider who transmits health information electronically in connection with a HIPAA standard transaction, such as a claim.

Under 45 CFR 160.103, a business associate is a person or organization that creates, receives, maintains or transmits PHI on behalf of a covered entity for a regulated function, or that provides services such as legal, consulting, data aggregation, management or administrative work involving PHI. The definition names data analysis, processing or administration among the covered functions, which is why analytics vendors, cloud platforms and AI providers handling PHI usually fall under it. HHS guidance on cloud computing states that a cloud service provider that stores or processes ePHI is a business associate even if it cannot view the data because it is encrypted and it holds no decryption key.

Covered entities must have a business associate agreement (BAA) in place before a vendor handles PHI, and a business associate must pass the same obligations down to its own subcontractors. Our blog post on what HIPAA compliance for AI requires you to document covers what that means for AI vendors.

What Are the 18 HIPAA Identifiers?

The 18 HIPAA identifiers are the data elements that must be removed, for the individual and for their relatives, employers and household members, to de-identify data under the Safe Harbor method of 45 CFR 164.514(b)(2). They are often quoted as "the list of PHI", but the list defines what de-identification removes. Health information held by a covered entity or business associate and combined with any one of them is very likely PHI.

Removing the 18 identifiers is not quite enough on its own. Safe Harbor also requires that the covered entity has no actual knowledge that the remaining information could identify an individual, alone or combined with other information. A rare diagnosis combined with a distinctive occupation or a widely reported event mentioned in a note, for example, can identify a person even after every listed identifier is gone.

Free text counts. HHS de-identification guidance states that the standard makes no distinction between structured fields and free text: an identifier must be removed wherever it appears in a record, including discharge summaries, progress notes and lab interpretations. This matters for AI, because clinical notes are exactly the unstructured text that language models and retrieval pipelines consume.

How Does HIPAA De-identification Work?

HIPAA recognizes two methods of de-identification: Safe Harbor and Expert Determination. Health information that meets either one is not individually identifiable, so it is no longer PHI and the Privacy Rule no longer restricts its use. A covered entity may use PHI to create de-identified data, or give it to a business associate for that purpose.

Three details from the rule and from HHS guidance are often missed.

• Re-identification codes are allowed. Under 164.514(c), a covered entity may assign a code so it can re-link de-identified records, provided the code is not derived from or related to information about the individual, cannot be translated to identify them, is not used or disclosed for any other purpose, and the re-identification mechanism is not disclosed.
• Expert determinations can expire. HHS notes that some practitioners issue time-limited certifications, because computing power and available data change the risk over time.
• A limited data set is still PHI. Under 164.514(e), a covered entity can strip 16 direct identifiers while keeping dates, town or city, state and ZIP code. That limited data set may be used only for research, public health or health care operations, and only under a data use agreement. It is not de-identified.

PHI vs PII

PHI is a defined term in one US regulation, while PII is a broad description of any information that can identify a person. Most PHI is also PII, but much PII, such as a customer's email address in a retailer's CRM, has nothing to do with HIPAA.

For a governance program, the practical consequence is that a column can carry several labels at once. A patient email address in a hospital's portal database is PII, PHI and, where GDPR applies, personal data that may also count as data concerning health. Classification schemes that allow only one label per asset tend to lose exactly this information. For the wider privacy picture, see data privacy.

What Is the Minimum Necessary Standard?

The minimum necessary standard requires covered entities and business associates to make reasonable efforts to limit the PHI they use, disclose or request to the minimum necessary to accomplish the intended purpose (45 CFR 164.502(b)).

The standard does not apply to every flow. The exceptions listed in 164.502(b)(2) include disclosures to or requests by a health care provider for treatment, uses or disclosures to the individual, uses or disclosures under the individual's authorization, disclosures to HHS for enforcement, and uses or disclosures required by law.

For internal use, 164.514(d) turns the principle into concrete obligations. A covered entity must identify the persons or classes of persons in its workforce who need access to PHI, the categories of PHI each of them needs, and any conditions on that access, and then make reasonable efforts to limit access accordingly. Routine, recurring disclosures need policies and procedures, which may be standard protocols. That is a role-to-data-category mapping, which is the same structure that data access management and data masking policies implement in a data platform.

Is PHI Used in AI Still PHI?

Yes. PHI does not lose its status because it is copied into a training set, an embedding index or a prompt. The HIPAA Rules in force today do not mention artificial intelligence, so they apply to AI the same way they apply to any other information system that creates, receives, maintains or transmits PHI.

HHS took the same position in the preamble to its proposed HIPAA Security Rule update, published on January 6, 2025: ePHI, including ePHI in AI training data, prediction models and algorithm data maintained by a regulated entity for covered functions, is protected by the HIPAA Rules. As of November 2026 the update remains a proposal, and no final rule has been published. The interpretation in the preamble is not a new requirement; it describes how HHS reads the rules that already apply.

Three governance questions follow for every AI use of PHI.

• Is the input PHI, a limited data set or de-identified data? Each has different rules, and only properly de-identified data leaves HIPAA's scope.
• Is the AI vendor a business associate? A provider that processes PHI on the covered entity's behalf generally is, and needs a BAA before the first record is sent.
• Can the organization show where the PHI went? Training sets, retrieval indexes and model outputs can be new copies of PHI that need the same classification, access control and audit trail as the source.

Our blog post on HIPAA compliance for AI walks through the records each of these questions requires. Privacy-preserving training approaches such as federated learning and synthetic data can reduce how much PHI moves, but they do not remove the need to document what data the models were built from.

How to Govern PHI in a Data Catalog

Governing PHI starts with an inventory of where it lives, and a data catalog is where that inventory is maintained. The catalog holds metadata about PHI, such as which tables, columns, documents and reports contain it, rather than the patient records themselves.

1. Classify. Mark the assets that contain PHI, at column level where possible, and include unstructured sources such as clinical notes and scanned documents. See data classification and unstructured data governance.
2. Trace. Record data lineage from the EHR or claims system through every copy, extract, feature table and AI index, so that the organization can show where PHI went and assess the impact of a change. Column-level lineage shows which downstream fields inherit an identifier.
3. Assign owners. Give every PHI-bearing asset an accountable owner who decides on access requests and answers for the data in a risk analysis or audit.
4. Connect access to purpose. Grant access to PHI by role and purpose, with masked access as the default for people who do not need identities, in line with the minimum necessary standard.
5. Keep the record. HIPAA requires Security Rule documentation to be retained for six years from its creation or last effective date (45 CFR 164.316(b)(2)(i)). An access decision with its reason, kept next to the asset it concerns, is easier to produce later than one buried in email.

In Dawiso, assets carry a PII and confidentiality classification that is aggregated into a badge on each port of a data product, so a requester sees how sensitive a product is before asking for access. Access requests in the Data Market state a use case, a level of access and a duration, with masked access to personal data as the default where the source supports masking, and Dawiso records the grant and the reason behind it. Metadata is ingested without reading row values when sources connect through the Dawiso Integration Runtime. Classifications are set by people or, through the MCP server, by AI assistants that classify and label objects on a user's behalf. Dawiso is a governance platform. It does not de-identify, block or encrypt patient data, and using it does not make an organization HIPAA compliant.

Sources

This article is for general information and is not legal advice.

Regulations are cited from the Electronic Code of Federal Regulations (eCFR), the official, continuously updated edition maintained by the Office of the Federal Register.

• eCFR, 45 CFR 160.103, Definitions (health information, individually identifiable health information, protected health information, electronic PHI, covered entity, business associate).
• eCFR, 45 CFR 164.502, Uses and disclosures of PHI, general rules (minimum necessary standard and its exceptions, use of PHI to create de-identified data).
• eCFR, 45 CFR 164.514, Other requirements relating to uses and disclosures of PHI (de-identification standard, the 18 Safe Harbor identifiers, re-identification codes, minimum necessary implementation, limited data set).
• eCFR, 45 CFR Part 164 Subpart C, Security Standards for the Protection of ePHI (documentation retention, 164.316).
• US Department of Health and Human Services, Guidance Regarding Methods for De-identification of PHI (no numerical risk threshold, time-limited certifications, identifiers in free text).
• US Department of Health and Human Services, Guidance on HIPAA and Cloud Computing (cloud providers storing encrypted ePHI are business associates).
• Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule, 90 FR 898, January 6, 2025 (ePHI in AI training data and models).
• US Department of Health and Human Services, HIPAA Security Rule NPRM (status of the proposed rule).
• Dawiso Help, Data Product Catalog, Requesting access to a data product and Dawiso Integration Runtime security overview.