Healthcare Teams: PHI Deidentification, 18 Identifiers, QA & On Device

PHI can be de-identified under HIPAA using either the Safe Harbor checklist or an Expert Determination. Once one of those standards is satisfied, the resulting dataset is no longer PHI under the Privacy Rule, and it can be shared, analyzed, or published without the usual authorization requirements. That said, meeting the HIPAA bar doesn’t automatically clear state privacy law or contract terms, so a second check is often still necessary before data leaves your walls.

TL;DR:

• Safe Harbor de-identifies data by removing 18 specific identifiers, with ZIP code and age exceptions that depend on population thresholds and age thresholds, respectively.
• Expert Determination uses a qualified reviewer to statistically assess and document that re-identification risk is very small, often preserving more data usefulness than Safe Harbor.
• On-device de-identification processes data locally before transmission, reducing data movement risks, simplifying audits, and minimizing workflow disruptions for clinicians.
• De-identified data removes HIPAA Privacy Rule obligations but may still be restricted under state laws, contracts, or international regulations like GDPR; legal review is essential before sharing.
• A structured workflow, including inventory, tagging, transformation, QA, and documentation, is crucial to ensure compliance and maintain an audit trail throughout the de-identification process.

Table of Contents

• What Counts as PHI, and When Should You De-Identify It?
• What Are the 18 Safe Harbor Identifiers?
• How Does Expert Determination Work?
• Which Technical Techniques Actually Reduce Re-Identification Risk?
• How Do You Assess Re-Identification Risk Before Release?
• How Should Teams Structure the De-Identification Workflow?
• What Documentation Do You Need to Keep?
• How Does On-Device De-Identification Work in Real Clinical Settings?
• Does De-Identified Data Escape All Other Legal Obligations?
• How Do You De-Identify a Dataset Step by Step?
• What Actually Matters When You’re Choosing a Method
• A Faster Path to HIPAA-Compliant De-Identification
• Where to Verify the Legal and Technical Details
• Sources
• FAQ

What Counts as PHI, and When Should You De-Identify It?

Protected Health Information is any individually identifiable health data created, received, or maintained by a covered entity or its business associates, as defined under 45 CFR §160.103. That covers everything from a hospital’s EHR records to a billing vendor’s claims files, and it applies whether the data lives in a structured database field or a scanned PDF of a discharge summary.

Covered entities include health plans, healthcare clearinghouses, and providers who transmit health information electronically. Business associates, think billing companies, cloud hosting vendors, or analytics contractors, inherit the same obligations through their agreements with covered entities. If your organization touches PHI on behalf of a provider or plan, HIPAA’s de-identification rules apply to you too.

De-identification makes sense in a specific set of situations, not every situation. It’s the right call when you’re:

• Sharing data with external researchers who don’t need a treatment relationship with the patient
• Publishing aggregate statistics or building public-facing dashboards
• Training or validating machine learning models where individual identity adds no analytic value
• Feeding data into quality improvement programs that operate outside the direct care team

It is not always the right tool, though. If a downstream partner genuinely needs some identifiers, say, a research collaborator who needs treatment dates to track outcomes, full de-identification might strip away exactly what makes the data useful. That’s where a limited data set comes in: it removes direct identifiers like names and Social Security numbers but keeps dates and geographic detail, and it moves under a data use agreement (DUA) rather than full de-identification. A limited data set is still technically PHI under HIPAA, just governed by contract instead of the Privacy Rule’s authorization requirements.

The practical distinction matters for compliance sign off. Full de-identification (Safe Harbor or Expert Determination) exits HIPAA’s Privacy Rule entirely. A limited data set stays inside HIPAA but swaps individual authorization for a signed DUA restricting use, disclosure, and re-identification attempts. Knowing which lane you’re in before you start scrubbing fields saves a lot of rework later.

What Are the 18 Safe Harbor Identifiers?

Safe Harbor is the checklist method: remove 18 specific categories of identifiers, and as long as you have no actual knowledge that the remaining data could still identify someone, the dataset meets the HIPAA de-identification standard under 45 CFR §164.514(b)(2). No statistician required, no formal report needed, just disciplined field-by-field removal.

Here’s the full list you’re working against:

1. Names
2. Geographic subdivisions smaller than a state (with the ZIP code exception below)
3. All elements of dates directly related to an individual, except the year (with the age-90 exception below)
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 or 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 fingerprints and voiceprints
17. Full-face photographs and comparable images
18. Any other unique identifying number, characteristic, or code

Two of these deserve special attention because teams get them wrong constantly.

ZIP codes aren’t a flat prohibition. You can keep the first three digits of a ZIP code as long as the geographic unit formed by combining all ZIP codes with that same prefix contains more than 20,000 people, based on the most recent census data. If the population falls below that threshold, the three-digit prefix has to be changed to “000.” This trips up teams working with rural populations or small metro areas more often than you’d expect. A single hospital system serving a sparsely populated county might have to zero out ZIP prefixes it assumed were safe.

Dates work similarly. You can’t keep any date element more granular than the year, no birth dates, admission dates, or discharge dates, unless you’re dealing with age. For patients under 90, age itself can stay as a number. For anyone 90 or older, ages have to be aggregated into a single category like “90 or older,” because that older-age population is small enough that an exact age becomes a near-identifier on its own.

Safe Harbor by the numbers: 18 identifier categories, one ZIP code population threshold (20,000), and one age cutoff (90) define the entire checklist. Get those three numbers right and you’ve covered most of the method.

The last practical reminder: Safe Harbor doesn’t stop at structured database columns. If any of these 18 identifier types show up in free-text fields, physician notes, discharge summaries, nursing narratives, they have to be scrubbed there too. A dataset with a clean structured schema and an unredacted “Notes” column full of patient names hasn’t met Safe Harbor at all. This is where most real-world de-identification failures actually happen, not in the spreadsheet columns everyone remembers to check, but in the narrative text nobody double-checks.

How Does Expert Determination Work?

Expert Determination takes a different approach: instead of a fixed checklist, a qualified expert applies statistical and scientific methods to assess and document that re-identification risk is “very small,” per the standard described in HHS’s Expert Determination guidance. This method costs more time and expertise up front, but it often preserves far more analytic value than Safe Harbor’s blunt removals.

The expert doesn’t need a specific license or certification, but does need documented, applicable knowledge of statistical and scientific methods for rendering data not individually identifiable. In practice, this tends to be a biostatistician, an epidemiologist, or a data privacy specialist with a track record of risk assessments the organization can point to if questioned later.

A rigorous Expert Determination generally works through these steps:

1. Map the external data landscape. What public or commercial datasets exist that a bad actor could use to cross-reference your data? Voter rolls, court records, and social media are common linkage vectors.
2. Assess uniqueness within the dataset. Are there patients whose combination of attributes, age, rare diagnosis, small ZIP area, makes them identifiable even without a name attached?
3. Estimate linkage likelihood. Given the external landscape and internal uniqueness, how probable is it that someone could actually connect a record back to a person?
4. Apply transformation techniques as needed. This might mean generalizing a field, suppressing a rare value, or adding statistical noise, whatever brings the estimated risk down to “very small.”
5. Document the full analysis. Methods used, assumptions made, results obtained, and the final determination all need to be written down in a form that would hold up to scrutiny.

That documentation isn’t optional paperwork, it’s the deliverable. HHS guidance is explicit that the expert’s report should describe the methods and results of the analysis, along with a clear statement that the risk of identification is very small. If your expert hands you a clean dataset with no written report behind it, you don’t actually have Expert Determination. You have a dataset someone modified without proof it meets the standard.

Pro Tip: Choose Expert Determination over Safe Harbor when your downstream use genuinely needs granularity Safe Harbor would destroy, exact ages for a geriatric outcomes study, or precise dates for a readmission timing analysis. Paying for a qualified expert once is usually cheaper than losing the ability to answer your research question at all.

Which Technical Techniques Actually Reduce Re-Identification Risk?

Removing identifiers is only half the job. The other half is deciding how to transform what’s left so the data stays useful without staying identifiable, and that’s where generalization, suppression, perturbation, and pseudonymization come in.

Generalization trades precision for safety. Instead of an exact age, use a five- or ten-year band. Instead of a specific county, use a broader region. This is the same logic behind the ZIP code and age-90 rules in Safe Harbor, just applied more flexibly across other fields when you’re doing Expert Determination.

Suppression means removing a value entirely rather than generalizing it, usually reserved for outliers that generalization can’t adequately protect. A patient with an extremely rare diagnosis in a small geographic area might need that diagnosis field suppressed altogether, even if the rest of the record stays intact.

Perturbation, often called adding “jitter,” introduces small amounts of random noise into numeric fields. Practical recommendations published in PLOS Computational Biology describe rounding exact values, replacing precise numbers with ranges, and injecting controlled random variation as ways to reduce identifiability while keeping aggregate statistics roughly intact. A lab value shifted by a small random amount still supports population-level trend analysis; it just stops being a fingerprint for one specific patient.

Hashing and salting create pseudonyms for patient identifiers that let you track a single patient across multiple records or visits without exposing who they are. The key detail: a proper cryptographic hash with a strong salt shouldn’t be reversible by anyone without the salt value, and that salt has to be stored separately from the de-identified dataset itself.

Free text is its own category of problem, and it’s the one that trips up the most teams:

• Named entity recognition (NER) models can flag likely names, dates, and locations embedded in clinical notes
• Automated redaction tools apply pattern matching for structured formats like phone numbers, SSNs, and medical record numbers within narrative text
• Manual QA review remains necessary because NER models miss context-dependent identifiers, a nickname, a rare occupation, a specific employer mentioned in passing

Pro Tip: Run automated free-text redaction first to catch the obvious cases, then have a human reviewer sample at least 5 to 10 percent of the redacted notes before release. Automated tools catch phone numbers reliably; they miss the physician who wrote “the patient’s daughter, a nurse at St. Mary’s” in a progress note.

How Do You Assess Re-Identification Risk Before Release?

The core danger in any de-identification effort is a linkage attack, where someone combines your “de-identified” dataset with an outside source to re-attach identity. The more variables a record carries, age, ZIP prefix, admission month, rare condition, comorbidity count, the more that record starts to function like a fingerprint, even with no name attached. High-dimensional datasets are inherently riskier than narrow ones, because each additional field multiplies the combinations that can isolate one person.

The EDPB’s anonymization framework offers a useful lens here even outside GDPR contexts: it tests data against three criteria, no record isolation, no linkage, and no inference. If an attacker can isolate a single record, link it to another dataset, or infer attributes about someone with confidence, the anonymization has failed on at least one axis. All three have to hold for data to count as genuinely anonymous.

A few practical checks translate this into something you can actually run before release:

• Uniqueness counts: for each combination of quasi-identifiers (age band, ZIP prefix, sex, admission month), count how many records share that exact combination
• k-anonymity heuristics: flag any combination where fewer than a set threshold, often 5 or 10, records share the same quasi-identifier profile
• Prosecutor and journalist scenario testing: model both an attacker who already knows a specific target is in the dataset (prosecutor scenario) and one fishing for any identifiable record at all (journalist scenario)

Common pitfalls show up in predictable places. Timestamps down to the minute on an admission record can, combined with a hospital’s public census, narrow a record to one person. Granular geolocation, even something as seemingly innocuous as GPS coordinates from a wearable device, does the same. Free-text leakage remains the most underestimated risk, since a redaction pass can miss context clues that don’t look like identifiers on their own. And rare attribute combinations, a specific procedure done at a specific facility in a specific month, can isolate a record even when every individual field looks generic.

For small subgroups, practitioner guidance on anonymizing health datasets recommends combining Safe Harbor removals with additional suppression or aggregation, and considering Expert Determination outright when a rare-disease cohort is simply too small for checklist removal to work on its own.

How Should Teams Structure the De-Identification Workflow?

A defensible de-identification process looks the same whether you’re a two-person compliance team or a hospital system’s data governance office: it’s a sequence, not a single action, and each step needs an owner.

1. Ingest and inventory. Pull the source data and catalog every field, structured and unstructured, that might contain an identifier.
2. Map identifiers to categories. Tag each field against the Safe Harbor list or against your Expert Determination risk criteria.
3. Remove or transform. Apply removals, generalization, suppression, or perturbation according to your chosen method.
4. QA the output. Run automated scanners for leftover identifiers, then re-identify a random sample manually to see if anyone with outside knowledge could still make a match.
5. Document everything. Write down what was removed, what was transformed, and why, before the data goes anywhere.
6. Release under appropriate controls. Attach a DUA if any residual restrictions apply, or release freely if the de-identification standard is fully met.

QA deserves more attention than most teams give it. Automated scanners are good at catching patterns, phone number formats, email structures, but they miss context. UCSF’s guidance on de-identifying PHI recommends pairing automated detection with manual sample re-identification testing, essentially trying to break your own de-identification before someone else does.

Sign-off matters too. Someone with actual compliance authority, not just the analyst who ran the scripts, should approve release. And if the dataset touches a rare condition, a vulnerable population, or a dataset destined for external publication, that’s the trigger point to commission a formal Expert Determination rather than relying on Safe Harbor alone.

Pro Tip: If your downstream partner needs even a sliver of date or geographic precision that full de-identification would strip away, stop and ask whether a limited data set under a signed DUA solves the problem instead. It’s often faster than building an Expert Determination case for data that was going to stay contractually restricted anyway.

What Documentation Do You Need to Keep?

Every de-identification effort needs a paper trail that would survive an audit, and that trail has four components worth keeping separately and permanently.

• Transformation logs: exactly which fields were removed, generalized, suppressed, or perturbed, and the parameters used for each transformation
• Scripts and code: the actual de-identification code or tool configuration, versioned and stored so the process can be reproduced or reviewed later
• Expert reports: for Expert Determination, the full written analysis with methods, assumptions, and the “very small risk” determination
• QA outputs: results of automated scans and manual re-identification testing, including any issues found and how they were resolved

Re-identification codes deserve their own handling rules. If you’re using hashed or pseudonymous patient identifiers to preserve linkage across records, that mapping key has to live in separate, access-restricted storage, not bundled with the de-identified dataset. A common failure mode is generating a solid pseudonymization scheme and then undermining it by giving the recipient both the de-identified data and the key. That defeats the entire purpose of pseudonymizing in the first place.

For any dataset going to an outside recipient, a DUA or equivalent contractual clause should explicitly prohibit re-identification attempts, restrict further disclosure, and specify what happens if the recipient’s use case changes. And don’t treat de-identification as a one-time event. Reassess periodically, especially if new external datasets become public that could increase linkage risk, or if the de-identified data itself gets combined with new internal fields down the line.

How Does On-Device De-Identification Work in Real Clinical Settings?

Most de-identification guidance assumes a batch process: pull data, transform it, ship it somewhere else for analysis. On-device de-identification flips that model by processing PHI locally, on the clinician’s own machine, before anything leaves for analysis or AI-assisted summarization.

Medscrub’s eSpiral case study illustrates what that looks like in practice: patient data gets de-identified locally before any AI processing happens, so PHI never actually transits to a cloud service in the first place. That architecture maps directly onto the HIPAA controls this guide has walked through, the identifiers get stripped or transformed before the data crosses any network boundary, rather than after.

The operational upside shows up in a few concrete ways:

• Less data movement means fewer points where a breach or misconfiguration could expose PHI in transit
• Simpler audit trails, since the de-identification step happens at a single, well-defined point rather than across multiple systems and vendors
• Fewer workflow interruptions for clinicians, who get chart summaries and documentation support without waiting on a separate data-transfer or approval process

None of this replaces the underlying legal analysis. Whether a given implementation satisfies Safe Harbor or Expert Determination still depends on which identifiers get removed and how the transformation is documented, not on where the processing physically happens. But an architecture that keeps PHI local by default gives compliance teams a smaller surface to audit, which is a meaningfully easier starting point than trying to retrofit de-identification onto data that’s already scattered across five different cloud systems.

Does De-Identified Data Escape All Other Legal Obligations?

Meeting HIPAA’s de-identification standard removes Privacy Rule obligations specifically, but it doesn’t automatically clear every other legal requirement that might apply to the same dataset. This distinction trips up teams that treat “HIPAA compliant” and “legally unrestricted” as synonyms, and background guidance on the topic makes clear they frequently are not.

State privacy laws sometimes define personal health information more broadly than HIPAA does, or impose separate consent requirements that survive HIPAA de-identification. Contractual terms, licensing agreements, institutional data-sharing policies, can also impose restrictions independent of HIPAA’s Privacy Rule entirely. A dataset that’s clean under Safe Harbor might still be off-limits for a specific use because of a contract clause nobody checked.

Cross-border sharing adds another layer. The EDPB’s anonymization framework, built for GDPR, uses different criteria than HIPAA’s Safe Harbor or Expert Determination and doesn’t automatically treat HIPAA-compliant de-identified data as GDPR-anonymous. The two frameworks overlap conceptually but aren’t interchangeable.

Before sharing de-identified health data across jurisdictions or with international partners:

• Get legal review specific to the destination jurisdiction, not just a HIPAA sign-off
• Apply additional safeguards where GDPR’s stricter anonymization criteria might apply
• Minimize the dataset further if the destination has narrower rules than HIPAA’s Safe Harbor list

How Do You De-Identify a Dataset Step by Step?

Here’s the condensed operational sequence for turning a raw, PHI-laden dataset into something that meets the HIPAA de-identification standard.

1. Classify and tag PHI fields. Inventory every structured column and free-text field, then map each one against the 18 Safe Harbor identifiers or your Expert Determination risk criteria.
2. Choose and apply your method. Remove Safe Harbor identifiers directly, or, if you need Expert Determination, engage a qualified expert to begin the risk analysis.
3. Transform and redact. Apply generalization, suppression, or perturbation to structured fields, and run automated redaction followed by manual QA on free text.
4. Assess residual risk. Run uniqueness checks and sample re-identification tests; commission a formal expert report if the data touches small or rare subgroups.
5. Document and release. Log every transformation, attach a DUA if any restrictions remain, and get sign-off before the dataset leaves your environment.

What Actually Matters When You’re Choosing a Method

Most teams default to Safe Harbor because it’s mechanical, follow the 18-item list, done. That instinct makes sense for low-stakes releases, but it quietly destroys analytic value in situations where precise dates or ages carry the whole research question. If you’re studying readmission timing or age-related outcomes in a narrow cohort, Safe Harbor’s date suppression and age-90 aggregation can gut the exact variables your analysis depends on. Expert Determination costs more up front but often saves the project.

The mistake I see most often isn’t picking the wrong method, it’s assuming de-identified data stops being anyone’s responsibility once it clears HIPAA. It doesn’t. De-identified isn’t unregulated. Governance, access controls, and periodic reassessment still matter, especially as external datasets that enable linkage keep growing every year.

If you’re releasing anything touching a rare condition, a small geographic area, or a vulnerable population, run a pilot first and get a second set of eyes, ideally a qualified expert, before you commit to a release strategy at scale.

— Clint

A Faster Path to HIPAA-Compliant De-Identification

Building a defensible de-identification pipeline from scratch means stitching together detection scripts, redaction tools, QA review, and a documentation process, and keeping all of it current as your EHR data changes. Some products handle the on-device piece of that puzzle directly: syncing with EHR systems like Epic and Oracle Health, then de-identifying patient data locally before any summary, note, or AI-assisted output gets generated.

Because the processing happens on the clinician’s own machine, PHI doesn’t have to travel to a third-party server just to get summarized or analyzed, which simplifies the audit trail this guide has walked through step by step. Clinicians get chart prep, SOAP note drafting, and care-gap tracking without adding a new data-exposure risk to sign off on. Developers building on top of patient data can work through Medscrub’s reversible de-identification API instead of managing raw PHI in their own infrastructure.

If your team is evaluating this kind of on-device approach, start with a pilot. Review the clinician-focused feature set, loop in your compliance or legal reviewer early, and test it against a real workflow before deciding whether it fits your de-identification strategy.

Where to Verify the Legal and Technical Details

The claims in this guide trace back to primary regulatory text and peer-reviewed technical literature, worth bookmarking directly rather than taking secondhand.

For the regulatory foundation, start with HHS’s own de-identification guidance, which walks through both methods under §164.514(a) through ©. The 18 identifiers themselves are laid out clearly with the ZIP code and age exceptions spelled out. For Expert Determination specifics, the UNC handout on HHS de-identification guidance breaks down documentation expectations in plain language.

For cross-jurisdictional work, the EDPB’s anonymization guidelines explain the GDPR framework in detail. And for hands-on technical methods, PLOS Computational Biology’s perturbation recommendations offer peer-reviewed guidance on noise injection, rounding, and aggregation techniques.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Sources

• Hhs
• The 18 HIPAA identifiers (Loyola University Chicago page)
• Handout – HHS De-Identification Guidance (UNC)
• EDPB guidelines on anonymisation (2026)
• Ten quick tips for protecting health data using de-identification and perturbation of structured datasets | PLOS Computational Biology

FAQ

Can PHI Be De-Identified Under HIPAA?

Yes. HIPAA recognizes two methods, Safe Harbor and Expert Determination, and data meeting either standard is no longer considered PHI under the Privacy Rule.

What Are the 18 Identifiers of PHI?

The 18 identifiers include names, geographic data smaller than a state, dates related to the individual, phone and fax numbers, email addresses, Social Security numbers, medical record and account numbers, device and vehicle identifiers, URLs, IP addresses, biometric data, full-face photos, and any other unique identifying code, as defined by the Safe Harbor standard.

How Do You De-Identify Patient Data?

You either remove all 18 Safe Harbor identifiers from structured and free-text fields, or engage a qualified expert to run a statistical risk analysis and document that re-identification risk is very small under Expert Determination. Tools that perform on-device de-identification, like Medscrub, can apply these transformations locally before data ever leaves a clinician’s machine.

What Are Five Examples of PHI?

Common examples include a patient’s full name paired with a diagnosis, a medical record number, a home address, an exact date of birth, and a photograph taken during treatment, each falling under one of the 18 Safe Harbor identifier categories.

Is De-Identified Data Still Subject to Any Regulation?

Meeting HIPAA’s de-identification standard removes Privacy Rule obligations, but state privacy laws, contractual data use agreements, and frameworks like GDPR’s anonymization criteria can still impose separate restrictions on the same dataset.

Recommended

• For Developers
• eSpiral Case Study
• For Clinicians
• Monarch Health Case Study