In 2023, OCR settled with a healthcare analytics company for over $1.5 million after the organization shared datasets it believed were de-identified — but which still contained zip codes and dates of service that could be linked back to individual patients. The organization assumed it had stripped enough information. It hadn't. Understanding which is not considered an identifier under the Privacy Rule is not an academic exercise — it's a compliance requirement with real financial consequences.
The 18 Identifiers the Privacy Rule Explicitly Names
Under 45 CFR §164.514(b)(2), the HIPAA Privacy Rule defines exactly 18 categories of information that qualify as identifiers of an individual or of the individual's relatives, employers, or household members. If your organization wants to de-identify protected health information using the Safe Harbor method, every one of these 18 data elements must be removed or generalized.
Here are the 18 identifiers specified in the Privacy Rule:
- Names
- Geographic data smaller than a state (street address, city, county, zip code — though the first three digits of a zip code may be retained under certain conditions)
- All elements of dates (except year) directly related to an individual, including birth date, admission date, discharge date, and date of death
- Telephone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health plan beneficiary numbers
- Account numbers
- Certificate/license numbers
- Vehicle identifiers and serial numbers, including license plate numbers
- Device identifiers and serial numbers
- Web URLs
- IP addresses
- Biometric identifiers (fingerprints, voiceprints)
- Full-face photographs and comparable images
- Any other unique identifying number, characteristic, or code
That last item is the catch-all. It's designed to close loopholes. If your covered entity assigns a proprietary patient code, that code is an identifier unless it meets specific re-identification restrictions under the Safe Harbor method.
Which Is Not Considered an Identifier Under the Privacy Rule: What Falls Outside the 18
So which is not considered an identifier under the Privacy Rule? Any data element that does not fall within those 18 categories. In practice, the most commonly referenced examples include:
- Diagnoses and conditions — A clinical diagnosis like "Type 2 diabetes" is not an identifier. It becomes PHI only when linked to one of the 18 identifiers.
- Lab values and vital signs — Blood pressure readings, cholesterol levels, and A1C results are clinical data, not identifiers.
- Medication names — The fact that a patient takes metformin is not identifying on its own.
- Age (when expressed as an age under 90) — The Privacy Rule treats ages 90 and above as a single category to prevent identification of very elderly individuals, but an age like "47" is not an identifier.
- Gender — Male, female, or nonbinary designations are demographic but not among the 18 identifiers.
- General geographic data at the state level or broader — "California" is not an identifier; "90210" is.
Healthcare organizations consistently confuse clinical data with identifiable data. A spreadsheet of diagnoses and lab values with no names, dates, or other identifiers attached is de-identified under Safe Harbor — assuming no other element could reasonably identify an individual.
Why the Distinction Matters for Your Risk Analysis
If your organization handles health data for research, analytics, quality improvement, or reporting, understanding which data elements are identifiers directly affects your risk analysis obligations under the HIPAA Security Rule. De-identified data is not protected health information and is therefore not subject to HIPAA's administrative, physical, or technical safeguards.
But here's where organizations get into trouble: partial de-identification. If you strip names and Social Security numbers but leave dates of service and five-digit zip codes, you still have PHI. OCR enforcement actions have repeatedly targeted organizations that assumed incomplete de-identification was sufficient.
The Safe Harbor method requires removal of all 18 identifier types — plus the covered entity must have no actual knowledge that the remaining information could identify an individual. There is no "close enough."
Safe Harbor vs. Expert Determination: Two Paths to De-Identification
The Privacy Rule at 45 CFR §164.514(b) provides two methods for de-identification:
Safe Harbor (§164.514(b)(2)): Remove all 18 identifiers and confirm no residual knowledge that could re-identify the data. This is the method most covered entities and business associates use because it provides clear, checklist-based guidance.
Expert Determination (§164.514(b)(1)): A qualified statistical or scientific expert applies accepted methods to determine that the risk of identifying an individual from the dataset is "very small." This method allows retention of more granular data but requires documented expert analysis.
In my work with covered entities, I've found that organizations choosing Expert Determination often lack the documentation OCR expects during an investigation. If you go this route, the expert's methodology and conclusions must be thoroughly documented and retained.
The Minimum Necessary Standard and Data Sharing
Even when working with fully identified PHI, the minimum necessary standard under the Privacy Rule requires your organization to limit the use, disclosure, and request of protected health information to only what is needed for the intended purpose. This standard works hand-in-hand with de-identification.
Before sharing any dataset — whether with a business associate, a research partner, or an internal analytics team — your workforce should ask: Can we accomplish this purpose with de-identified data? If the answer is yes, you're required to take that less risky path.
Your workforce HIPAA compliance program should include specific training on identifying the 18 identifiers and understanding when data qualifies as de-identified. This isn't just for your privacy officer — it's for every analyst, researcher, and administrator who touches health data.
The Workforce Training Requirement Most Organizations Underestimate
Under 45 CFR §164.530(b), covered entities must train all workforce members on PHI policies and procedures. In practice, this means every employee should understand the basics of what constitutes an identifier and what does not. An analyst who doesn't know that a five-digit zip code is an identifier can inadvertently create a reportable breach.
OCR has made clear through its enforcement actions — including settlements and corrective action plans — that ignorance of de-identification requirements is not a defense. Your Notice of Privacy Practices commits your organization to protecting PHI. Your training program is how you operationalize that commitment.
Investing in HIPAA training and certification gives your workforce the knowledge to correctly distinguish identifiers from non-identifiers, apply the Safe Harbor method accurately, and avoid the costly mistakes that lead to HIPAA violations.
Practical Steps to Protect Your Organization
Knowing which is not considered an identifier under the Privacy Rule is the starting point. Here's how to translate that knowledge into compliance:
- Audit your datasets. Review every dataset your organization shares internally or externally. Confirm that any dataset labeled "de-identified" has had all 18 identifiers removed.
- Document your method. Whether you use Safe Harbor or Expert Determination, maintain written documentation of the de-identification process for every dataset.
- Train broadly. Don't limit de-identification training to the privacy office. Analysts, IT staff, researchers, and administrative teams all need this knowledge.
- Re-evaluate regularly. Data that was de-identified five years ago may now be re-identifiable due to advances in data linkage techniques. Revisit your risk analysis annually.
The line between identified and de-identified data is drawn precisely by the Privacy Rule. Your organization's job is to respect that line — every time, with every dataset, across every workforce member who handles health information.