The 18 HIPAA Identifiers Hiding in Your Import File

Most health tech teams can name the obvious protected health information in a spreadsheet. Patient name, date of birth, medical record number. The columns that cause trouble are the ones nobody labels: a device serial number, an IP address, a license plate, the last four digits of a Social Security number. HHS lists eighteen identifiers, and several of them routinely arrive in files that were never classified as containing PHI at all.

This matters more if your product receives files from other organizations, because you did not choose the columns and cannot assume the sender classified them correctly. This piece is about what counts as an identifier inside the file. The wider compliance architecture is covered in HIPAA-compliant healthcare data import and in choosing a data importer for sensitive data.

Under the Safe Harbor method in the HIPAA Privacy Rule, data is de-identified only when all eighteen of the following identifiers have been removed, for the individual and for their relatives, employers and household members.

Names. All geographic subdivisions smaller than a state. All elements of dates except year, where the date relates to an individual. Telephone 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 plate numbers. Device identifiers and serial numbers. Web URLs. IP addresses. Biometric identifiers, including finger and voice prints. Full-face photographs and comparable images. And a catch-all: any other unique identifying number, characteristic or code.

There is a second condition attached to Safe Harbor that gets less attention. Even with all eighteen removed, the covered entity must not have actual knowledge that the remaining information could be used, alone or in combination, to identify someone.

Source: HHS guidance on de-identification, 45 CFR 164.514(b)(2), checked 19 August 2026.

Names and Social Security numbers get flagged. These do not.

Device identifiers and serial numbers. Remote monitoring, connected devices and implant tracking all move serial numbers routinely, usually in a column labeled something like device_id. It is an identifier under the rule.

IP addresses. These arrive inside audit exports, session logs and consent records that get attached to a patient file.

Web URLs. A patient portal link or a per-record document URL frequently encodes an identifier in the path.

Vehicle identifiers, including license plates. Common in patient transport, home visit scheduling and fleet-based care.

Certificate and license numbers. Often assumed to be provider data rather than patient data, which is true right up until the record is about the individual.

Account numbers. Billing exports are full of them, and billing exports are frequently treated as finance data rather than health data.

The catch-all matters as much as the list. Any unique code that distinguishes one person from another is an identifier, whatever your schema calls it.

This is the rule that surprises engineering teams most often.

HHS is explicit that parts or derivatives of the listed identifiers may not be disclosed under Safe Harbor. Patient initials do not qualify. The last four digits of a Social Security number do not qualify. Truncating an identifier is not the same as removing it.

Plenty of import pipelines hash, mask or truncate a field and record it as de-identified. Under Safe Harbor that is not what happened.

Only the year survives. Day and month are not permitted for any date related to an individual, which covers birth date, admission, discharge and death. HHS gives the example directly: "January 1, 2009" cannot be reported at that level of detail, but "2009" can.

Ages have a ceiling. Every age over 89 must be aggregated into a single "90 or older" category, and so must any date element that reveals such an age. A file with a birth year of 1931 in it has not cleared Safe Harbor just because the month and day were stripped.

Anything smaller than a state is an identifier: street address, city, county, precinct, ZIP code and their geocodes.

The single exception is the first three digits of a ZIP code, and only when the area formed by all ZIP codes sharing those three digits contains more than 20,000 people. Where it contains 20,000 or fewer, those three digits must be changed to 000.

So "ZIP truncated to three digits" is not automatically safe. It depends on the population behind the prefix.

HHS makes this point with its own worked example. Take a table with no names and no Social Security numbers, holding only age, ZIP code and sex. Each row is unique on that combination. Voter registration data contains names alongside birthdate, ZIP code and sex. The two link.

Nothing in that table looks like PHI column by column. It is PHI because of what it can be joined to.

This is why field-by-field review fails. A validation rule that checks whether a column is named something sensitive will pass a file that identifies every patient in it.

If your product receives spreadsheets from other organizations, you inherit a file whose shape you did not design.

Dromo's healthcare customers are almost all in this position. They are health tech vendors, not hospitals: remote cardiac monitoring, specialty infusion workflows, implant supply chain management, home care coordination, direct primary care health plans, laboratory safety and compliance. In each case the data arrives from a clinic, an agency, a lab or an employer, in whatever format that organization's system produced.

That has three consequences.

The sender's classification cannot be trusted, because the person exporting the file is usually an operations coordinator working from an EHR or a scheduling system, not someone reasoning about 45 CFR 164.514.

The schema drifts between senders. One clinic's DOB is another's birth_date is another's "Patient DOB (mm/dd/yyyy)". Column-name matching that works for one source silently misfires on the next.

And extra columns arrive uninvited. Exports frequently carry more fields than were asked for, which is exactly how device serial numbers and IP addresses enter a file nobody expected to contain them.

The import step is the last point where the file is still a file, before it becomes rows in your database. That makes it the right place to enforce classification.

Classify by content, not by column name. Detect the shape of the value. A column called ref_2 holding nine digits formatted as a Social Security number should be flagged whatever the header says.

Reject unmapped columns rather than ignoring them. An extra column that nobody mapped is the most likely place for unexpected PHI to sit. Silently dropping it is safer than storing it, but neither is as safe as telling the sender it is there.

Check combinations, not just fields. Flag when age, ZIP and sex, or date of birth and ZIP, appear together in a file intended to be de-identified.

Enforce the date and age rules in validation. Year only, and ages over 89 bucketed. These are mechanical checks that a human reviewer will not perform consistently across hundreds of files.

Keep the raw file out of places it does not need to be. Every system that touches the file before classification is another system inside your compliance boundary.

Dromo runs the import in the end user's browser. In Private Mode, the file is parsed, validated and corrected client side, and the raw data is never sent to Dromo's servers.

For PHI that is the structural point, not a feature comparison. A vendor that processes PHI server side becomes a business associate and needs a BAA, and its infrastructure joins the set of systems a breach analysis has to cover. A vendor that never receives the data does not.

Validation rules run against the values themselves, so a misnamed column carrying identifiers can be caught on the shape of its contents rather than its header. Rules are defined once against your schema and applied to every sender, which is what makes the twentieth clinic no harder than the first. Errors come back attached to the row and cell, so the person who exported the file is the person who fixes it, before it moves.

Dromo is SOC 2 Type II certified and HIPAA compliant, on every plan rather than a healthcare tier.

Dromo does not classify PHI for you or make a de-identification determination on your behalf. Safe Harbor is a judgment the covered entity makes. What an importer can do is enforce the rules you set, on every file, before the data lands.

They are the identifiers that must be removed for data to be de-identified under the Safe Harbor method: names, geographic subdivisions smaller than a state, all date elements except year, telephone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate and license numbers, vehicle identifiers, device identifiers and serial numbers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying code.

No. HHS states that parts or derivatives of the listed identifiers do not satisfy Safe Harbor. Patient initials and the last four digits of a Social Security number are both given as examples that fail the test.

Yes. HHS illustrates this with a table containing only age, ZIP code and sex, which can be linked to voter registration data to re-identify individuals. Safe Harbor also requires that the covered entity have no actual knowledge that the remaining data could identify someone alone or in combination.

Only the year. Day and month are not permitted for any date related to an individual, and all ages over 89 must be grouped into a single category of 90 or older.

Only when more than 20,000 people live in the area covered by all ZIP codes sharing those three digits. Where the population is 20,000 or fewer, the prefix must be changed to 000.

It depends on the architecture. A vendor that receives and processes PHI on its own servers is a business associate and needs a BAA. An importer that processes the file entirely in the end user's browser, with no PHI reaching the vendor's infrastructure, does not receive the data in the first place.

The dangerous file is not the one labeled "patient records." It is the export somebody sent you with three more columns than you asked for, one of which holds a device serial number.

Check the values, not the headers, and do it while the file is still a file.

See what Dromo costs. The price is published and the sandbox is free.