The 18-identifier list you find on every HIPAA article is real, and almost every article presents it wrongly. Here is what it is actually for.
Part 3 of 8 in the HIPAA Engineering Series. Previous: Does HIPAA Apply to Your App? And What Applies If It Does Not. Next: HIPAA Technical Safeguards: BAAs, Encryption, Identity and Audit Logs. Full series.
Getting this definition right decides what you encrypt, what you log, what you can put in an analytics pipeline, and what leaves HIPAA scope entirely. Getting it wrong in the usual way, treating a list of identifiers as the definition, makes teams over-protect a marketing database and under-protect a claims file.
What is PHI, and what is it not?
Protected health information is individually identifiable health information that is created, received, maintained or transmitted by a covered entity or business associate.
Three parts of that sentence do real work:
Health information is broader than diagnoses. It includes the fact of an appointment, a billing record, a prescription refill, an insurance claim, and demographic data held alongside any of these. A payment record with no clinical content is still PHI.
Individually identifiable means it identifies the person, or there is a reasonable basis to believe it can be used to identify them. This is a judgement, not a checklist.
Held by a covered entity or business associate. This is the part people miss. The same information in the same format is PHI in a hospital's database and is not PHI in a consumer app's database. Who holds it decides.
When PHI is held electronically, HIPAA calls it ePHI, and the Security Rule governs it. "PHI" in this guide means ePHI unless stated otherwise.
What are the 18 HIPAA identifiers?
You will find an "18 identifiers of PHI" list on almost every blog about this. It is a real list, and it is almost always presented wrongly.
Those 18 items are not a definition of PHI. They are the list you must remove to de-identify data under the Safe Harbor method in §164.514(b)(2). A name on a mailing list is not PHI. A name in a clinic's patient index is.
Here is the list, correctly:
Names. Including relatives, employers and household members.
Geographic subdivisions smaller than a state. Street, city, county, precinct, ZIP. The first three digits of a ZIP may stay if that area holds more than 20,000 people.
All date elements except year. Birth, admission, discharge, death. Ages over 89 and any date implying such an age must be aggregated to "90 or older".
Telephone numbers.
Fax numbers. A separate item from telephone numbers in the regulation.
Email addresses.
Social Security numbers.
Medical record numbers.
Health plan beneficiary numbers.
Account numbers.
Certificate and licence numbers.
Vehicle identifiers and serial numbers. Including licence plate numbers.
Device identifiers and serial numbers. This is where IMEI, advertising IDs and implant serials land.
Web URLs.
IP addresses.
Biometric identifiers. Including finger and voice prints, not just fingerprints.
Full-face photographs and comparable images.
Any other unique identifying number, characteristic or code. The catch-all. It is doing more work than the other seventeen combined.
Two more things to know before you build a "de-identified" analytics pipeline:
Safe Harbor is not the only route, and it is not automatic. Strip all 18 and have no actual knowledge that the remainder could identify someone. The second half is a real condition. A dataset of one rare-disease patient in a small county is identifiable with every listed field removed. The alternative route is Expert Determination (§164.514(b)(1)): a qualified statistician documents that the re-identification risk is very small. Use it when Safe Harbor would destroy the data's value.
A Limited Data Set is a middle option. It keeps dates and coarse geography, removes the direct identifiers, and requires a data use agreement. It is still PHI. It is often the right answer for research and product analytics.
De-identified data is not PHI and falls outside HIPAA. That is a genuine, useful exit. Take it deliberately and document it. Do not drift into claiming it.
Frequently asked questions
Is a patient's name PHI?
On its own, no. A name in a mailing list held by a marketing company is not PHI. The same name in a clinic's patient index is, because PHI is individually identifiable health information held by a covered entity or business associate, and the fact that someone is a patient is itself health information. The 18 identifiers are the list you strip to de-identify data, not a list of things that are each PHI by themselves.
Is de-identified data still PHI?
No. Properly de-identified data falls outside HIPAA, which is a genuine and useful exit. But "properly" is doing work: under Safe Harbor you must remove all 18 identifiers and have no actual knowledge that the remainder could identify someone. A dataset containing one rare-disease patient in a small county can be identifiable with every listed field removed.
What is the difference between Safe Harbor and Expert Determination?
Safe Harbor (§164.514(b)(2)) is the checklist route: remove all 18 identifiers, with no actual knowledge of residual identifiability. Expert Determination (§164.514(b)(1)) is the statistical route: a qualified person documents that the re-identification risk is very small. Use Expert Determination when Safe Harbor would destroy the data's usefulness, such as research or analytics that need real dates and geography.
Where Bitsol fits
We build healthcare software on AWS and do the compliance engineering as part of building it, not as a phase at the end. What we can honestly offer is a read of your codebase and cloud account against the technical safeguards with a file-and-line citation for every control we find and a plain statement of every gap; design and build for web, mobile and AI on a PHI boundary written down before the first table is created; a launch gate verified against the running system before the first real patient record; and the evidence pack a hospital security reviewer will ask for, with the open items named.
What we will not offer is a statement that your application is HIPAA compliant, or a certification. Those do not exist, and a vendor who offers them is telling you something useful about themselves. Get in touch.
The HIPAA Engineering Series
Does HIPAA Apply to Your App? And What Applies If It Does Not
What Is PHI? The 18 HIPAA Identifiers and How De-identification Works (you are here)
HIPAA Technical Safeguards: BAAs, Encryption, Identity and Audit Logs
Where PHI Leaks, and How to Stay Compliant After Launch
HIPAA Compliance for Web Applications
HIPAA Compliance for Mobile Apps
HIPAA Compliance for AI Features: LLMs, RAG and PHI
Sources
This guide describes engineering practice. It is not legal advice, and several of the questions it raises (whether HIPAA applies to your organisation, whether a feature is a regulated medical device, what your state's retention period is, and what any customer-facing document may claim) need a qualified healthcare attorney rather than an engineer.
