At some point almost every billing team needs to move data outside its normal circle: into a spreadsheet for a consultant, a staging environment for a software migration, a vendor who wants to demo against real claim volumes, or an analytics tool your IT department runs. The moment patient names, dates of service, and insurance IDs leave your practice management system, HIPAA applies, and you need a plan for how to handle them.
The two HIPAA de-identification methods
HIPAA's Privacy Rule permits you to share de-identified data without restriction. It gives you two paths to get there.
- Safe Harbor. Remove (or obscure) all 18 categories of identifiers listed in the rule. If none remain, HIPAA treats the data as de-identified. This is the method most billing operations use because it is checklist-driven: strip the list, review the output, done.
- Expert Determination. A qualified statistical expert certifies that the risk of identifying an individual from the remaining data is very small. You can keep some fields that Safe Harbor would require you to remove, but you need an expert to sign off. This is more common in research settings than in billing operations.
For routine billing work, Safe Harbor is the practical choice. It takes more preparation than most teams expect, especially around dates.
The 18 Safe Harbor identifiers
The rule lists the identifier categories in 45 CFR 164.514(b)(2). In a billing context, the ones that trip teams up most often are highlighted below. The full list:
- Names (patient, guarantor, employer)
- Geographic data smaller than a state: full street address, city, county, precinct, and any zip code. Three-digit zip codes are permitted only if the three-digit code covers more than 20,000 people; otherwise the zip must also be removed or collapsed.
- All date elements smaller than year that are directly related to an individual: date of service, admission date, discharge date, date of birth, date of death. Year of birth and year of service are generally acceptable; month and day are not.
- Phone numbers
- Fax numbers
- Email addresses
- Social security numbers
- Medical record numbers
- Health plan beneficiary numbers (member IDs)
- Account numbers
- Certificate and license numbers
- Vehicle identifiers and serial numbers including license plates
- Device identifiers and serial numbers
- URLs
- IP addresses
- Biometric identifiers such as fingerprints or voiceprints
- Full-face photographs and comparable images
- Any other unique identifying number, characteristic, or code not otherwise permitted
The Limited Data Set: a useful middle path
If removing dates would make the data useless for your purpose (aging analysis, time-series audits, episode-of-care work), HIPAA provides a middle option: the Limited Data Set. A Limited Data Set allows you to keep dates and three-digit zip codes, but you must strip names, street addresses, phone numbers, SSNs, member IDs, and medical record numbers. The key requirement is a written Data Use Agreement (DUA) with the recipient that restricts how they may use the data.
A Limited Data Set is not the same as de-identified data. It is still PHI; the DUA is what makes sharing it permissible. If the recipient loses the data or uses it beyond the DUA's scope, your practice may bear responsibility. Use this path when dates are essential and the recipient is trustworthy, not as a shortcut around full de-identification.
BAA vs. de-identification: pick the right tool
Before going through the work of de-identifying a billing export, ask whether de-identification is even the right answer. If the recipient is a vendor that handles PHI as a normal part of their service (a clearinghouse, an analytics platform, a billing consultant), they may already qualify as a Business Associate. In that case, a Business Associate Agreement (BAA) covers the disclosure without requiring you to strip the data at all. The data stays fully usable and you have contractual protections.
De-identification makes sense when the recipient will not sign a BAA, when you want to use data in a context where BAA coverage is not available (public benchmarking, internal analytics shared broadly, open testing environments), or when you want to reduce your exposure even with a recipient who would accept a BAA.
Practical steps for billing data
- Map every column before you export. Pull a sample row from your claim file and classify each field as direct identifier, quasi-identifier, or safe. Treat the 18-identifier list as the floor, not the ceiling.
- Truncate dates to year. Replace date of service, date of birth, and admission/discharge dates with the year only, or with a relative value such as days from an anchor date if you need temporal relationships to survive.
- Replace or hash record identifiers. Swap member IDs, medical record numbers, and account numbers with a surrogate key if you need to link records across the file. Keep the mapping table secured separately; the export itself should carry only the surrogate.
- Check zip-code populations. Any three-digit zip code that covers fewer than 20,000 people must be generalized further or removed. HHS published a reference list of qualifying three-digit codes when the rule took effect.
- Review procedure and diagnosis codes in context. CPT and ICD-10 codes alone are not identifiers, but a rare procedure code combined with a geographic region and a year can re-identify a patient in a small practice. If your data involves rare specialties or low-volume codes, consider whether an expert review is warranted even if Safe Harbor is technically satisfied.
- Document what you did. Write a short note covering which fields were removed or transformed and the date the export was run. If HHS ever asks how a data set was de-identified, documentation is your answer.
Why this matters for denial management work
The practical trigger for most billing teams is outsourced denial analysis or a new vendor demo. Sharing a raw claim write-off report or an aging export with a consultant who has not signed a BAA is a PHI disclosure without a permissible basis. De-identification or a DUA (for a Limited Data Set) is what makes it permissible. The same applies to using real claim data in a test environment when evaluating software like an athenaOne aging export or a Tebra billing integration. Scrubbing the file before it leaves your system is not bureaucratic overhead; it is the step that keeps the analysis legal.
The short version
Safe Harbor de-identification requires removing 18 categories of identifiers, and dates are the field most billing teams get wrong. If dates must survive, a Limited Data Set plus a Data Use Agreement is the correct path. If the recipient will sign a BAA, skip de-identification entirely. Whatever path you choose, document it. See the revenue-leakage guide for more on what billing data analysis can surface once you have a clean, legally usable export.