An analytics vendor sends your practice manager a data request: "Just export the last 24 months of visits — de-identified, so we don't need a BAA." The proposed extract includes date of service, five-digit ZIP, and the free-text chief complaint field. That file is not de-identified. It is protected health information in a spreadsheet, and sending it without an agreement is an impermissible disclosure.

This is a practical explainer on HIPAA de-identification for the people who sign the vendor contract and answer for it later. It covers the only two methods the Privacy Rule recognizes, the exact fields Safe Harbor makes you strip, why a limited data set is a different animal, and what documentation a regulator will want to see.

The Two Methods HIPAA Recognizes — and Nothing Else

Under 45 CFR 164.514(a)-(b), health information is de-identified only if it does not identify an individual and there is no reasonable basis to believe it can be used to identify one. The rule gives you two paths to get there.

Safe Harbor (164.514(b)(2)): remove 18 categories of identifiers, and confirm you have no actual knowledge that the remaining information could identify a specific person.

Expert determination (164.514(b)(1)): a person with appropriate knowledge of and experience with generally accepted statistical and scientific principles applies those methods, concludes the re-identification risk is very small, and documents the methods and results.

"We removed the names" is not a method. Neither is "the vendor said it was anonymized." If a data flow leaving your practice does not sit squarely in one of those two buckets, it is PHI and every disclosure rule still applies.

What Are the 18 Identifiers Safe Harbor Requires You to Strip?

All of the following must be removed from the record set — for the individual and for their relatives, employers, and household members:

  1. Names
  2. All geographic subdivisions smaller than a state — street address, city, county, precinct, ZIP code (the initial three digits of a ZIP may be kept only if that three-digit area contains more than 20,000 people; the sparsely populated prefixes HHS lists must be reported as 000)
  3. All elements of dates except year, for dates directly related to the individual — birth date, admission date, discharge date, death date — plus all ages over 89 and any date element indicating such an age, aggregated into a single "90 or older" category
  4. Telephone numbers
  5. Fax numbers
  6. Email addresses
  7. Social Security numbers
  8. Medical record numbers
  9. Health plan beneficiary numbers
  10. Account numbers
  11. Certificate and license numbers
  12. Vehicle identifiers and serial numbers, including license plates
  13. Device identifiers and serial numbers
  14. Web URLs
  15. IP addresses
  16. Biometric identifiers, including finger and voice prints
  17. Full-face photographs and comparable images
  18. Any other unique identifying number, characteristic, or code

HHS's official de-identification guidance walks through each category with worked examples. Print it and keep it with your policy set; it is the document OCR itself points to.

Where Safe Harbor Quietly Fails in a Real Practice

Dates are the most common breach of Safe Harbor

Operational reports almost always need dates. Safe Harbor lets you keep the year only. "3/14/2024" fails. "2024" passes. If your quality team needs day-level intervals, you have left Safe Harbor and need an expert determination or a limited data set with an agreement in place.

Free text carries identifiers you did not plan to send

Chief complaint fields, referral notes, and internal comments routinely contain patient names, employer names, phone numbers, and "patient is the mayor's daughter." A structured-field scrub does nothing to a narrative column. Either exclude free text from the extract or budget for a review pass by a human who is authorized to see PHI.

The "actual knowledge" test still binds you after the fields are gone

Safe Harbor has a second half. If you know the remaining data points to someone — a single patient in your county with a rare condition, a professional athlete on your roster, the only 91-year-old in a small program — the file is not de-identified even with all 18 categories removed. Assign that judgment to your privacy officer, not to whoever built the report.

Small denominators re-identify people

A cell showing one patient, three-digit ZIP, and diagnosis category is a name to anyone in the community. Suppress or aggregate small cells before release. NIST's NISTIR 8053, De-Identification of Personal Information, is a readable primer on why these techniques succeed or fail.

Expert Determination: What the File Has to Contain

Expert determination is the path when you need dates, geography, or granular fields Safe Harbor forbids. Research collaborations, payer analytics, and AI model training almost always land here.

The rule does not license or certify "experts." It requires demonstrable knowledge and experience with statistical de-identification. In practice that means a biostatistician, a data scientist with disclosure-control experience, or a specialized consultancy.

Your file should hold, at minimum:

  • The expert's CV or statement of qualifications
  • The exact data set evaluated — field list, date range, row count, source system
  • The methods applied: suppression, generalization, k-anonymity thresholds, perturbation, whatever was used
  • The assumptions about who might attempt re-identification and what outside data they could obtain
  • The risk conclusion, in writing, with the standard stated as "very small"
  • The date, and any expiration or re-review trigger the expert specified

Determinations are not permanent. External data availability changes. If the same recurring extract has been running on a 2021 determination, put re-review on your annual compliance calendar.

A Limited Data Set Is Not De-Identified Data

This is the distinction that trips up most practices. A limited data set under 164.514(e) removes 16 direct identifiers but keeps dates, city, state, and ZIP. That is why researchers ask for it.

An LDS is still PHI. You may disclose it only for research, public health, or health care operations, and only under a data use agreement that limits permitted uses, names who may access the data, prohibits re-identification and contact with individuals, and requires the recipient to report misuse. Minimum necessary applies.

Practical rule for your intake process: if the requester needs a date more precise than a year, or geography more precise than a state, you are negotiating a limited data set and a DUA — not shipping de-identified data.

Who Performs the De-Identification Decides Whether You Need a BAA

Here is the sequencing question that determines your contract obligations.

If your practice de-identifies the data and then hands over the result, the recipient receives no PHI. No business associate agreement is required for that flow. Document what you removed and how.

If the vendor performs the de-identification, the vendor receives identifiable PHI first. De-identification on behalf of a covered entity is a business associate function. You need a signed BAA before a single row moves — and "we'll de-identify it on ingest" does not change that.

That second pattern is extremely common with analytics platforms, registry submissions, AI documentation tools, and marketing agencies. Before you approve one, get the agreement executed. If your practice needs a BAA on paper this week rather than next quarter, you can generate a signature-ready Business Associate Agreement through a six-step wizard with PDF and DOCX export — a one-time purchase, no subscription, which is usually faster than routing a redline through outside counsel for a routine vendor.

The re-identification code, if you need one

Section 164.514(c) lets you assign a code so you can re-link records later. Two conditions: the code cannot be derived from or related to information about the individual and cannot be translated to identify them, and you may not disclose the code's mechanism or use it for any other purpose. A hash of the medical record number fails. A random sequence held in a key table only you control passes.

A Workflow You Can Run Next Week

Assign these steps by name, not by department.

Step 1 — Intake (privacy officer, within 3 business days). Log every external data request: requester, stated purpose, fields sought, cadence. One row per request in a tracked log.

Step 2 — Classify (privacy officer). Decide which of three buckets applies: Safe Harbor de-identified, expert determination, or limited data set under a DUA. Write the reasoning in one paragraph in the log.

Step 3 — Contract (whoever signs). BAA if the vendor touches PHI. DUA if it is a limited data set. Nothing needed if you produce a Safe Harbor extract in-house. Do not release until executed.

Step 4 — Build and verify (IT or reporting analyst, then a second reviewer). Produce the extract, then have a second person check it against the 18 categories, sample the free-text columns, and flag small cells. Two initials on the checklist.

Step 5 — Release and retain (privacy officer). Record the release date, delivery method, recipient, and file hash or row count. Retain the checklist and any expert report for six years, consistent with the Privacy Rule documentation requirement.

Step 6 — Re-review (annual). Recurring extracts get re-verified once a year. Fields drift when the EHR is upgraded and a new column silently joins the report.

What HIPAA De-Identification Does Not Get You Out Of

Once data is properly de-identified, HIPAA no longer restricts its use or disclosure. Other law may.

Several states regulate health data more broadly than HIPAA, including consumer health privacy statutes that reach data HIPAA would treat as de-identified. Check your state before you assume a clean release.

The FTC also polices deceptive claims about anonymization and enforces breach notification duties for certain non-HIPAA health apps and services. Its health privacy business guidance is worth reading if any part of your practice runs consumer-facing digital tools. If your privacy notice or vendor contract says data is "anonymous," make sure the technical reality matches the sentence.

And note the obvious operational risk: de-identified data cannot be recalled. Once released, you have no breach notification hook and no clawback. That asymmetry is why the verification step deserves a second reviewer.

The Evidence That Proves You Did This Right

If OCR or a health system partner audits the flow, they will ask for artifacts, not intentions:

  • A written de-identification policy naming the method used for each recurring data flow
  • The request log with classification decisions
  • A completed 18-identifier checklist per release, with reviewer initials and date
  • Signed expert determination reports, with qualifications attached
  • Executed BAAs for every vendor that touches identifiable data, and DUAs for every limited data set
  • Evidence of annual re-review for standing extracts

Most practices already do the technical work and simply fail to write it down. The write-down is the compliance deliverable.

Two next steps. Pull your vendor list today and mark which vendors de-identify data on your behalf — each of those needs an executed agreement, and you can build a signature-ready BAA in a single sitting if any are missing. Then, if your broader policy set and risk analysis documentation are thinner than your data flows deserve, automated HIPAA risk analysis and policy generation will close that gap faster than starting from a blank template.