PHI, or protected health information, is any health, care or payment information that identifies a person and is held by a covered entity or its business associate. In software, it spreads well past the patient table. Application logs, error traces, analytics events, URLs, AI prompts and outputs, backups, test data and support tickets all count once they hold a name, a date of service, a record number or anything else that points to the patient. Digital Scientists builds for that under a signed BAA. NeverAlone has handled PHI 24/7 since March 2021.
What makes data PHI?
Two things together: it relates to a person's health, care or payment for care, and it identifies the person or could reasonably be used to. Health information with every identifier removed isn't PHI. An identifier with no health context, such as a name in a newsletter list, isn't PHI either. Put them together inside a covered entity or a business associate and it is.
A covered entity is a health plan, a healthcare clearinghouse or a provider that bills electronically. A business associate is a vendor that handles PHI on its behalf, which is why your software partner signs a business associate agreement (BAA). For the full background, see what HIPAA is and why it matters.
Context matters more than people expect. An appointment reminder is PHI because it ties a person to care, and when it comes from a substance use treatment program, the sender's name alone reveals the condition. An email address on a list of patients in a diabetes program is PHI for the same reason. For how we build around that, see our approach to security and PHI.
What are the 18 HIPAA identifiers?
HIPAA's Safe Harbor method of de-identification lists 18 identifiers that have to be removed, for the individual and for relatives, employers or household members, before health data stops being PHI:
- Names
- Geographic units smaller than a state, including street address, city, county and ZIP code (the first three ZIP digits can stay in some cases)
- All elements of dates except the year, for dates tied to the person (birth, admission, discharge, death), and ages over 89
- Phone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health plan beneficiary numbers
- Account numbers
- Certificate and license numbers
- Vehicle identifiers and serial numbers, including license plates
- Device identifiers and serial numbers
- Web URLs
- IP addresses
- Biometric identifiers, including fingerprints and voiceprints
- Full-face photographs and comparable images
- Any other unique identifying number, characteristic or code
Two items on that list catch software teams off guard. IP addresses are in every request log your servers write, and device identifiers are in most mobile analytics. Dates are in every event timestamp. If those records sit next to anything about care, you're holding PHI. The other route to de-identification, Expert Determination, has a qualified expert certify that the risk of re-identification is very small.
Where does PHI hide in a software system?
It hides in the places nobody designed for patients: the plumbing. The database gets encryption, access control and a BAA. The log pipeline, the analytics tag and the AI prompt often don't.
| Where | How PHI gets in | What to do |
|---|---|---|
| Application logs | A developer logs the full request or the patient object while debugging, and it ships | Log IDs and event types, not payloads. Treat the log store as a PHI system with access control and retention |
| Error tracking | Stack traces capture form values, query parameters and user context | Scrub fields before send, and use a vendor that signs a BAA or keep it in your own environment |
| Product analytics | Event names and properties such as "booked_psychiatry_visit" tied to a user ID or IP address | Keep health context out of event names, or run analytics under a BAA |
| URLs and query strings | Patient names, record numbers or visit types in the path, which land in browser history, server logs and referrer headers | Opaque IDs in URLs. Never put identifiers in a path or query string |
| AI prompts and outputs | Notes, transcripts and record excerpts sent to a model, plus whatever it writes back | Run the model inside an environment covered by a BAA, log every call, and protect the log like the record |
| Backups and test data | Production copies restored to staging or a developer laptop | Synthetic or de-identified data outside production. Backups encrypted and under the same access rules |
| Support tickets and screenshots | A user pastes a chart or screenshots a patient record into a helpdesk tool | Use a support tool under a BAA, and train staff to share record IDs instead |
| Notifications | Email and SMS bodies that name the condition, the clinic or the medication | Say as little as the message needs. Send people into the authenticated app for detail |
Is analytics and tracking data PHI?
Often, yes. Federal regulators have said that tracking code on a logged-in patient portal generally has access to PHI, because the person is identified and the pages they visit reveal their care. A pixel that sends the page URL, the user's IP address and an event such as "scheduled appointment" to an ad platform is a disclosure of PHI to a vendor that hasn't signed a BAA.
The practical rule for a healthcare product: no third-party marketing tags inside authenticated pages, and product analytics only under a BAA or inside your own environment. Measure the public marketing site separately from the product.
Are AI prompts and outputs PHI?
Yes, when the prompt includes patient information, and in clinical work it usually does. A visit transcript sent to a model for a summary is PHI. So is the summary. So is the log entry that records both. The same goes for embeddings and search indexes built from patient records, because they're derived from PHI and sit next to the identifiers that link back to it.
That's why we set four rules for AI on patient data. On new builds, models run through Amazon Bedrock inside the client's own AWS account, covered by the client's BAA with AWS. Your data trains nothing for anyone else, and Bedrock doesn't use your prompts or outputs to train the underlying models. A clinician, coder or reviewer approves each output before it's used. And on every build, we log the input, the source it drew on, the model version and the reviewer's action, so any decision traces back.
That log is PHI too. It gets the same encryption, access control and retention as the record. For de-identification, audit trails and model governance in more depth, read HIPAA-compliant AI on patient data, and see our healthcare AI development work.
What isn't PHI?
Data that's been properly de-identified isn't PHI, and neither is health information that never touches a covered entity or business associate. Employment records you hold as an employer aren't PHI, even when they mention a sick day. A consumer wellness app that isn't working for a provider or plan usually sits outside HIPAA, though other privacy and consumer protection rules still apply.
Two cautions. De-identification is a process, not a column you drop: rare diagnoses, small towns and exact dates re-identify people. And substance use disorder records from federally assisted programs carry an extra layer under 42 CFR Part 2, with consent rules on top of HIPAA. If your platform holds them, design for it from the start. See behavioral health.
How do you keep PHI out of the wrong places?
Decide where PHI is allowed to live, write it down, and build every pipe to match. Most leaks come from defaults nobody changed.
- Map the data flow first. Every system PHI touches, including logging, analytics, AI and support tools, with a BAA for each vendor in the path.
- Host on HIPAA-eligible services. In U.S. regions, encrypted at rest, network-isolated and access-logged. See cloud and HIPAA hosting.
- Separate roles. Developers working on non-PHI components never touch production data. Access runs on roles and MFA, and gets reviewed.
- Tag sensitive records at intake. Tags follow the data into reports, integrations and AI prompts, so every downstream system knows what it's holding.
- Test with synthetic data. Production copies stay in production.
Every engagement where we handle PHI starts with a signed BAA. Our security plan is mapped to NIST CSF 2.0, and each client gets a security addendum for anything specific to its project. We don't hold SOC 2 or HITRUST, and we say so up front. We run NeverAlone, a virtual care platform for 30,000 patients across six states, around the clock since March 2021. If you're mapping where PHI lives in your own product, talk it over with us.
Frequently asked questions
What are examples of PHI?
A patient's name with a diagnosis, a medical record number, an appointment date tied to a person, a lab result, a claim, a visit transcript, or an IP address logged next to a patient portal page. Health information plus anything that identifies the person, held by a covered entity or business associate, is PHI.
Is an IP address PHI?
On its own, no. An IP address is one of HIPAA's 18 identifiers, so when it's logged alongside health or care information by a covered entity or business associate, such as a request to a patient portal, that record is PHI.
Are application logs subject to HIPAA?
Yes, when they contain PHI. Logs that capture request bodies, patient objects, record numbers or IP addresses next to care events need the same access control, encryption and retention rules as the database. The simpler fix is to keep PHI out of logs in the first place.
Can we send PHI to an AI model?
Only inside an environment covered by a BAA, with logging and human review. On new builds, Digital Scientists runs models through Amazon Bedrock in the client's own AWS account, a person approves each output before it's used, and every output is logged.
Is de-identified data PHI?
No. Data de-identified under HIPAA's Safe Harbor method, with all 18 identifiers removed and no actual knowledge that what's left identifies anyone, or under Expert Determination, is not PHI.
Does Digital Scientists sign a BAA?
Yes. We sign a BAA for every engagement that involves PHI, before any data is exchanged or system access is granted. Our security plan is mapped to NIST CSF 2.0. We don't hold SOC 2 or HITRUST.
