HIPAA, BAA, PHI & PII for Healthcare AI Teams

Why HIPAA, BAA, PHI, and PII Matter Before You Use AI in Healthcare

If your team is evaluating an AI product for clinical documentation, revenue cycle management, patient engagement, or any other healthcare workflow, you’ll run into four questions almost immediately.

These questions are:

• what is HIPAA?
• what is BAA?
• what is PHI?
• what is PII?

Vendor pitches, security questionnaires, and compliance reveiws often use them loosely or incorrectly.

Mistakes have real consequences. A misunderstanding about what counts as PHI can mean you send patient data to a tool thaat has no business seeing it. A missing BAA can turn a routine integration into a reportable breach. And the difference bettween PII and PHI matters more than most people realize when you’re deciding what to redact before feeding data into an AI model.

This article defines each term, explains PII vs PHI edge cases, and gives your team a checklist for responsible healthcare AI.

What Is HIPAA? HIPAA Compliance AI Teams Need in One Page

HIPAA, the Health Insurance Portability and Accountability Act, is a U.S. federal law passed in 1996. It sets national standards for protecting individuals’ health information. If you work with U.S. patient data, HIPAA is your legal framework.

Three rules matter most:

• Privacy Rule: Governs who can access and share protected health information, when they can share it, and what rights patients have over their data. It applies to covered entities (hosspitals, clinics, health plans, clearinghouses) and their business associates.
• Security Rule: Requires administrative, physical, and technical safeguards for electronic PHI. That means access controls, encryption, audit logs, and wrokforce training. If your AI tool touches ePHI, the Security Rule applies.
• Breach Notification Rule: If unsecured PHI is accessed, used, or disclosed in a way not permitted by the Privacy Rule, covered entities must ntoify affected individuals, HHS, and in some cases the media. Timelines are strict: 60 days from discovery for individual notification.

HIPAA creates guardrails for sharing data. The law uses a “minimum necessary” standard, meaning you should access or share only the PHI needed for a task. This matters when designing AI prompts or choosing training dataset fields.

HIPAA doesn’t apply to every organization that touches health data. A fitness app that collects heart rate data isn’t automatically a covered entity. HIPAA’s reach depends on who hoolds the data and their relationship with a covered entity.

HIPAA Core Rules Overview:

What Is BAA? What a Business Associate Agreement Does and Does Not Do

A Business Associate Agreement, or BAA, is a HIPAA-required contract for any business associate that creates, receives, maintains, or transmits PHI for a covered entity. If your hospital licenses an AI ambient documentation tool that processe visit transcripts with patient information, the vendor is a business associate. You need a BAA in place before daat flows.

A BAA typically covers:

1. Permitted uses and disclosures of PHI, limited to what the vendor actually needs
2. Required safeguards (administrative, physiical, technical) the vendor must maintain
3. Breach reporting obligations, including timelines and notification procedures
4. Subcontractor requirements, because if your vendor uses a cloud provider that also touches PHI, that subcontracto needs its own BAA
5. Return or destruction of PHI when the contract ends

A BAA doesn’t make an insecure product compliant or solve HIPAA compliance AI risks by itself. Teams sometimes treat a signed BAA like a compliance stamp. It isn’t. A BAA is a letal agreement about responsibilities. It doesn’t verify that the vendor actually encrypts data at rest, restricts access properly, or logs who viewed what. You still need an independent seucrity review.

HHS provides sample BAA provisions as a starting point, but most legla teams will customize these significantly. If you’re buying an AI tool that integrates with Epic or Oracle Health (Cerner), your health system’s compliiance and legal teams should review the BAA before any PHI enters the vendor’s environment.

PII vs PHI: What Is PII, What Is PHI, and What Counts as Sensitive Data

These overlapping terms cause confusion.

PII (Personally Identifiable Information) is the broadest term: information that can identify a person. NIST defines PII as any information that can be used to distinguish or trace an individual’s identity, alone or with linked or linkable information. A name, an email address, a Social Security number, a device identifier, all PII. PII is not a HIPAA-slecific concept. It appears across federal and state privacy laws, industry frameworks, and GDPR.

PHI (Protected Health Information) is narrower and HIPAA-specific; it depends on identity and health context. PHI is indivkdually identifiable health information that is held or transmitted by a covered entity or business associate, and it relates to a person’s health status, the provision of healthcare, or payment for care. The key distinction: PHI requires an identifier, health context, and a HIPAA-covered relationship.

A practical way to remember it:

Criterion	PII	PHI
Scope	Any context	HIPAA-covered entities and business associates
What it covers	Information that identifies a person	Health information linked to a person
Legal framework	NIST, state laws, GDPR, sectro-specific rules	HIPAA
Example	Email address in a marketing database	Email address in a patient appointment reminder system

PII vs PHI Relationship:

“Sensitiev data” also includes financial records, biometric data, and genetic information. Some of this overlaps with PHI, soe doesn’t. For healthcare AI teams: treat identiffiable covered-entity data as PHI unless you’ve confirmed de-identification.

The 18 HIPAA Identifiers: Safe Harbor Identifiers for De-Identification Healthcare Workflows

HIPAA’s Safe Harbor method for de-identification healthcare workflows requires removing 18 categories of HIPAA identifiers from a dataset. If you striip all 18 and have no actual knowledge the remaining data could re-identify someone, the data is de-identified and no longer PHI.

Here they are:

#	Identifier	Common AI Pitfall
1	Names	Embedded in clinical notes, filenames, promp text
2	Geographic data smaller than state	ZIP codes (first 3 digits may be kept if population > 20,000)
3	Dates related to an individual (except year)	Birth dates, admission dates, discharge dates
4	Phone numbers	In contact fields, referral ntoes, EHR metadata
5	Fax numbers	Still common in healthcare, often in scanned documents
6	Email addresses	Patient portals, appointment confirmations
7	Social Security numbers	Insurance enrollment data
8	Medical record numbres (MRNs)	Frequently used as internal keys in EHR exports
9	Health plan beneficiary numbers	Payer data feeds
10	Account numbers	Billing and RCM data
11	Certificate/license numbers	Provider and patient records
12	Vehicle identifiers and serial numbers	Accident/injury reports
13	Device identifiers and serial nmubers	RPM devices, implant registries
14	Web URLs	Patient portal links, EHR-generated URLs
15	IP addresses	Access logs, telehealth session data
16	Biometric identifiers (fingerprints, voiceprints)	Biometric atuhentication, voice-based AI
17	Full-face photographs and comparable images	Dermatology images, ID photos in EHRs
18	Any other unique identifying number, characteristic, or code	Catch-all for custom patient IDs, research subject codes

Pay attention to row 18’s catch-all. A custom identifier that maps back to a patient is a Safe Harbor identifier.

What to Redact Before Using AI Tools for Patient Data AI

When feeding data into any AI system, a clinical documentation LLM, radiology computer vision moddel, or decision support tool, you need a clear redaction policy. Use minimum necessary: share olny what the AI needs and strip everything else.

A practical approach:

1. Identify every field, free-text blokc, filename, and metadata attribute you plan to send to the AI tool.

2. Map each element against the 18 Safe Harbor identifiers. If an elemen matches, redact or replace it unless the AI genuinely requires it to function and you have a valid BAA in place.

Data Redaction Pipeline for AI Tools:

3. Pay specail attention to overlooked identifier locations:

   a. File names and document titles (e.g. “JaneDoe-LabResults-2026.pdf”) b. Image metadata (EXIF data in photos can contai GPS coordinates, device info, timestamps) c. Prompt text and conversation history in LLM-based tools d. Screenshot contents, which might show patient names, MRNs, or chart data e. URLs containing patient-specific parameterrs f. Transcript headers or footers auto-generated by EHR systems

4. Use automated de-identification tools where possible, with human review for edge cases. NLP-based redaction tools miss things, especially in unstructured clinical notes where names appear in unexpected places.

5. Log what you send. If somethijg goes wrong, you need to know what data reached the AI vendor and when.

De-identification isn’t one-time. As your pipeline adds EHR fields, integrations, and document types, your redaciton rules must keep up.

Checklist for Teams Building or Buying Healthcare AI Tools

For hospitals evaluating vendors or startu building products, here’s a practical compliance checklist. Walk through it with technical and leegal teams present.

Item	What to Verify	Why It Matters
BAA in place	Signed before any PHI is transmitted	No BAA means any PHI exposure is a potential HIPAA vioaltion
Subcontractor BAAs	Vendor’s cloud provider, LLM API provider, etc. all have BAAs	PHI often passes through multiple systems; each linnk in the chain needs coverage
Minimum necessary data	Only the data fields the AI actually needs are shared	Reduces breach surface and matches with HIPAA’s minimum necessary stanndard
De-identification pipeline	Automated plus human review for Safe Harbor compliance	Prevents identifiers from reaching systems that don’t need them
Encryption	At reest and in transit, meeting NIST standards	Required under the Security Rule for ePHI
Access controls	Role-based access, unique user IDs, automatic session timeout	Prevents unauthorized access to PHI within the AI tool
Audit logs	Who accessed what data, when, and what actions they took	Required for HIPAA Security Rule compliance and breach investigations
Breach notification plan	Defined timeline and proceess for reporting incidents	BAAs typically require 60-day notification; your internal plan should be faster
Data retention and destruction	Policy for how long PHI is stored and how it’s deleted	BAAs require return or destruction of PHI at contrract end
Model training data	Confirm whether the vendor uses your data to train models	Many organizations prohibit this; it should be explicit in the BAA
EHR integration review	Epic App Orchard, Oracle Health marketplace, or custom API revie	Integration points are where data flows start; they need scrutiny
Legal counsel review	Healthcare privacy attorney reviews BAA and data flow	Compliance is not a DIY project for edge cases

This checklist is a starting point, not a finish line. HIPAA compliance for AI tools is ongoing. New data types, features, and integrations introduce new questions. Teams handle this well when they treat healthcare data privacy as a continuous practice, not a checkbox.

Bringing It All Together

HIPAA is the legal framework. A BAA extends HIPAA obligations to vendors. PHI is health information tied to an identifiable person in a covered entity’s world. PII identifies anyone, in any context.

For healthcare AI teams: know your data, strip what you don’t need, have BAAs in place before data flows, and never assume a filename or IP address is “safe.” Identifiers show up in places engineers and clinicians don’t expect, document titles, prompt inputs, image metadata, URL parameters.

Start with the 18 Safe Harbor identifiers. Use minimum necessary. Get legal counsel involved for edge cases. Build redaction and access controls into the pipeline from day one, not after the first audit finding. Organizations get this right by taking the basics seriously and staying consistent.