Is your data set actually de-identified?

De-identification is the only exit HIPAA offers

HIPAA does not have a general exemption for research, or for analytics, or for internal reporting, or for machine learning. It has permitted uses and disclosures, it has authorizations, and it has one door that takes information out of the rule's scope altogether. That door is de-identification, and it is defined at 45 CFR 164.514(a): health information that does not identify an individual, and with respect to which there is no reasonable basis to believe the information can be used to identify an individual, is not individually identifiable health information.

The consequence is stated at 45 CFR 164.502(d)(2). Once information meets that standard, it is no longer protected health information, and the Privacy Rule's restrictions on use and disclosure no longer apply to it. You do not need an authorization. You do not need a business associate agreement with the vendor who analyzes it. You do not need a data use agreement. The information has left HIPAA.

That is a large consequence, and the rule guards it with a correspondingly specific test. There are exactly two ways to satisfy the standard, both at 45 CFR 164.514(b): expert determination and Safe Harbor. There is no third method, no reasonable-effort standard, and no defense built on how careful you were. Either you applied one of the two methods or the data is still protected health information.

Method one: Safe Harbor, and why it looks easier than it is

Safe Harbor at 45 CFR 164.514(b)(2) is the method most organizations reach for, because it is mechanical. Remove eighteen categories of identifiers, satisfy one knowledge condition, and you are done. Two people applying it to the same data set should get the same answer, which is exactly what you want when the alternative is hiring a statistician.

The eighteen categories are lettered (A) through (R) in the regulation. Names come first, and the category reaches more than the patient: it covers the names of relatives, employers, and household members appearing in the record. Notably, OCR has confirmed there is no explicit requirement to remove the names of the providers treating the patient, which surprises people in both directions.

Then geography, then dates, and these two are where nearly every real data set fails, because they carry the analytic value people are trying to preserve. Geography strips down to the state. The only exception is the first three digits of a ZIP code, and only when the geographic unit formed by combining all ZIP codes sharing those three digits contains more than 20,000 people according to current publicly available Census data. Prefixes covering 20,000 or fewer people must be changed to 000. OCR published the seventeen three-digit prefixes that failed the threshold under 2000 Census data, listed below, along with an instruction not to rely on that listing once more current data has been published.

Restricted three-digit ZIP prefixes in the OCR listing: 036, 059, 063, 102, 203, 556, 692, 790, 821, 823, 830, 831, 878, 879, 884, 890, 893.

Dates are stricter than people assume. Every element of a date more precise than the year has to go, for any date directly related to an individual: birth, admission, discharge, death, visit, procedure. OCR has stated that dates associated with test measures, such as those derived from a laboratory report, are directly related to a specific individual, so lab dates are covered too. And the same paragraph handles the elderly separately: all ages over 89, and all date elements including the year that indicate such an age, must be aggregated into a single category of 90 or older. OCR illustrates the trap with an example. If a patient's year of birth is 1910 and the year of service is 2010, the year of birth reveals an age above 89 and should be reported as on or before 1920, even though only years are present.

After that the list is more mechanical: telephone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate and license numbers, vehicle identifiers including license plates, device identifiers and serial numbers, web addresses, Internet Protocol addresses, biometric identifiers including finger and voice prints, and full-face photographs and comparable images.

The single most common failure across all of them is the partial form. OCR's guidance is direct: parts or derivatives of any of the listed identifiers cannot be disclosed. A column holding the last four digits of a Social Security number is not a de-identified column. Neither is a set of initials, a truncated medical record number, an area code on its own in a small geography, or a cropped photograph where the face remains recognizable. This is the point at which pipelines that look clean in a schema review turn out not to be.

Identifier (R), the catch-all that does the real work

The eighteenth category is any other unique identifying number, characteristic, or code, and it is not a formality. It is what stops the first seventeen from becoming a checklist you can satisfy while leaving obviously identifying material in place. A rare diagnosis in a small population, an occupation that describes one person, a distinguishing physical feature recorded in a note, a study identifier that nobody thought of as an identifier: all of them sit here.

The catch-all has one carve-out, at 45 CFR 164.514(c). A covered entity may assign a code or other means of record identification to allow de-identified information to be re-identified later, but only under conditions. The code must not be derived from or related to information about the individual and must not otherwise be capable of being translated to identify them. And the covered entity must not use or disclose the code for any other purpose, or disclose the mechanism for re-identification.

This is why a hashed medical record number is a harder question than it looks. A hash is derived from information about the individual, so a hash whose function and salt travel with the data does not satisfy the first condition. OCR's guidance does contemplate disclosing codes derived from protected health information as part of a de-identified data set through cryptographic hash functions, provided the keys associated with those functions are not disclosed to anyone, including the recipients. A randomly generated study code, with the crosswalk held on the identified side of the wall, avoids the argument entirely and is what most well-run programs use.

The condition that is not on the list

Safe Harbor has a second requirement that lives at 45 CFR 164.514(b)(2)(ii), and it is the one most summaries drop: the covered entity must not have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information.

OCR describes actual knowledge as clear and direct knowledge that the remaining information could be used to identify an individual. The guidance draws a line that matters in practice. Knowing that re-identification research exists, and that academics have demonstrated methods for linking de-identified records to external sources, does not by itself give a covered entity actual knowledge that those methods would be used against the data it is disclosing. The condition is about what you actually know, not about what is theoretically possible.

The examples OCR gives are concrete. A record describing a former president of a state university, alongside an age and a state, is identifiable to anyone who reads a newspaper. Clinical details that would let a recipient recognize a relative are actual knowledge. A rare event reported in the media, such as an unusual multiple birth, is actual knowledge. And knowing that a particular recipient already holds the key to fields you left in the data is actual knowledge in the most direct sense. The test asks you to think about a specific data set going to a specific recipient, and to act on anything you already know.

Method two: expert determination, and what makes someone an expert

The other method, at 45 CFR 164.514(b)(1), replaces the list with an analysis. A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable applies those principles, determines that the risk is very small that an anticipated recipient could use the information alone or in combination with other reasonably available information to identify an individual, and documents the methods and results of the analysis that justify that determination.

Two things about that standard are worth stating plainly. First, OCR has said there is no specific professional degree or certification program that designates who is an expert. What OCR reviews is the relevant professional experience and academic or other training of the expert, along with actual experience using de-identification methodologies. Second, there is no universal numeric threshold for very small risk. It depends on the data, the recipient, and what else is reasonably available, which is precisely why the method requires a documented analysis rather than a conclusion.

The Privacy Rule does not require expert determinations to expire, but OCR's guidance observes that experts may apply time-limited certifications, since technology, social conditions, and the availability of external data change. An expired certification does not invalidate data already disseminated. Experts may also design multiple solutions tailored to different recipients, so long as the resulting data sets cannot be combined in a way that compromises the protections.

Expert determination is the right method when the analysis genuinely needs what Safe Harbor forbids: exact dates for a longitudinal study, five-digit ZIP codes for a geographic health analysis, granular ages at the top of the distribution. It costs money and takes time, and organizations that need it usually know they do.

The limited data set: the middle path people forget exists

Between fully identified data and de-identified data sits a third option that solves a large share of real requests: the limited data set at 45 CFR 164.514(e). It removes sixteen direct identifiers rather than eighteen categories. The list it drops is essentially the Safe Harbor list minus dates, minus the geographic detail down to town or city, state, and ZIP code, and minus the catch-all. Street addresses still have to go; town, city, state, and ZIP code may stay.

That difference is exactly the difference most analysts care about. A limited data set keeps full dates and keeps geography at a usable resolution, which makes it viable for epidemiology, outcomes research, and quality measurement in a way Safe Harbor data often is not.

The trade is that a limited data set remains protected health information. It may be used or disclosed for three purposes only, research, public health, and health care operations, and only under a data use agreement satisfying 45 CFR 164.514(e)(4). That agreement has required content: the permitted uses and disclosures, who may use or receive the data, a prohibition on further use or disclosure beyond the agreement or what law requires, a requirement to use appropriate safeguards, a requirement to report any use or disclosure the agreement does not provide for, an obligation to bind agents and subcontractors to the same terms, and a prohibition on identifying the information or contacting the individuals. If the covered entity learns of a pattern of activity that breaches the agreement, it has to take reasonable steps to fix it and, if that fails, to end the disclosure or report the problem.

The failure mode here is linguistic rather than technical. Teams build a perfectly good limited data set, describe it as de-identified in a research protocol or a vendor contract, and then discover during a breach investigation or an audit that the paperwork says something the data does not support. A limited data set can be breached. De-identified data cannot, because it is not protected health information. That distinction decides whether an incident triggers the notification rules at 45 CFR 164.400 through 164.414.

Free text, joins, and the places de-identification quietly fails

OCR's guidance states that the de-identification standard makes no distinction between data entered into standardized fields and information entered as free text. That single sentence accounts for more failed de-identification than every other rule combined.

The pattern is familiar. A team writes a careful extract that drops the identifier columns, reviews the schema, and ships it. What ships alongside it is a discharge summary naming a spouse, a nursing note with a callback number, a scanned referral with a fax header, a PDF whose document properties carry the author's name, an image file whose metadata holds a device serial number and GPS coordinates, and a joined audit table carrying IP addresses because someone needed session context. None of those are in the column list. All of them are identifiers.

Two habits prevent most of this. The first is to run the analysis against the artifact that actually leaves the building rather than against the query that produces it, including attachments, metadata, and every joined table. The second is to re-run the analysis whenever the extract changes. A de-identification determination describes a data set at a moment. It is not a property the pipeline keeps.

Re-identification, and what happens if someone does it

De-identified information that gets re-identified becomes protected health information again in the hands of a covered entity or business associate holding it, with every obligation that follows. This is why 45 CFR 164.514(c) is drafted the way it is: the code and the mechanism are what stand between a de-identified data set and a re-identifiable one, and the rule protects both.

The Privacy Rule also makes de-identification itself a permitted activity. Under 45 CFR 164.502(d)(1), a covered entity may use protected health information to create de-identified information, and may disclose it to a business associate for that purpose. That matters operationally, because it means the vendor doing your de-identification work is a business associate and needs an agreement, even though the output of the work will not be protected health information at all.

Where training fits

The people who decide whether a data set is de-identified are rarely the privacy officer. They are analysts, report writers, data engineers, and researchers, and they are handling protected health information right up until the moment the extract is produced. The Privacy Rule training requirement at 45 CFR 164.530(b) and the security awareness and training program at 45 CFR 164.308(a)(5) reach them like everyone else.

The practical case is stronger than the regulatory one. Almost none of the failures in this area are deliberate. They are a last-four column that looked harmless, a lab date nobody thought of as a date, an audit join added for debugging, a scanned attachment that never got opened. Those are recognition problems, and recognition is what training produces. It is worth being precise about what training proves: completing a course demonstrates that named individuals received instruction on a date, and produces a record you can show. It does not make an organization compliant, no training provider can certify that it is, and the federal government does not accredit or endorse training providers.

Primary sources

• 45 CFR 164.514 , the de-identification standard, Safe Harbor, the re-identification code conditions, and the limited data set.
• HHS Office for Civil Rights, Guidance Regarding Methods for De-identification of Protected Health Information , the source for the actual knowledge examples, the ZIP prefix listing, the free-text position, and the expert qualification discussion.
• 45 CFR 164.502 , which permits creating de-identified information and confirms that de-identified information is not protected health information.
• 45 CFR 160.103 , the definitions of protected health information and individually identifiable health information.