"We replaced all the MRNs with SHA-256 hashes," the analyst said. "The data is de-identified now."
The mapping table — MRN-12345 → a8f9d2c1... — was still sitting in a folder on the same server.
Under HIPAA, that fact means the data is identifiable. Not to the research partner receiving the file. But to the organization holding the key.
Pseudonymization and de-identification are not the same thing. The difference is not technical. It is legal. And which category your data falls into determines whether HIPAA's authorization requirements apply to what you do with it.
TL;DR
Pseudonymization replaces direct identifiers (MRNs, patient IDs, SSNs) with codes or hashes while retaining a mapping that allows re-identification. Under HIPAA, pseudonymized data is still PHI for any party that holds the mapping key — because that party can re-identify individuals. Safe Harbor §164.514(b)(2)(i)(R) covers any other unique identifying code; the exception for coded records in a de-identified dataset is at §164.514(c), which requires: (1) the code was not derived from or related to information about the individual (§164.514(c)(1) — the derivation test), (2) the covered entity does not use or disclose the code for any other purpose, and (3) the mechanism for re-identification is not disclosed to the recipient (§164.514(c)(2) — the security conditions). If you hold the key, the data is PHI for you, regardless of what the recipient sees.
Methodology note (May 2026): Pseudonymization and coded-record rules follow 45 CFR §164.514(b)(2)(i)(R) (the identifier category) and §164.514(c)(1)–(c)(2) (the coded-record exception conditions), per HHS guidance. GDPR uses "pseudonymisation" with a different legal definition — this guide addresses HIPAA only.
For the complete Safe Harbor workflow across all 18 identifiers, see our full 18-identifier Safe Harbor de-identification guide.
⚖️ NOT LEGAL ADVICE — This post covers HIPAA Safe Harbor pseudonymization and coded-record de-identification for informational purposes only. Whether your specific data and process satisfy Safe Harbor depends on your data, use case, and organizational context. Consult qualified legal and compliance counsel before making de-identification or sharing decisions for regulated data.
Table of Contents
- Pseudonymization vs De-Identification: The Core Distinction
- When the Key Exists, the Data Is Identifiable
- The Two Pseudonymization Use Cases
- Safe Harbor's Coded Record Exception: §164.514(b)(2)(i)(R) and §164.514(c)
- Common MRN Replacement Approaches and Their Compliance Status
- Step-by-Step: Pseudonymize Patient IDs in SplitForge
- Limitations
- FAQ
- Conclusion
Pseudonymization vs De-Identification: The Core Distinction
De-identification (under HIPAA): The data has been processed such that it can no longer be used to identify an individual. Either all 18 Safe Harbor identifiers have been removed (Safe Harbor method), or a qualified statistician has certified that re-identification risk is very small (Expert Determination). No party should be able to re-identify individuals from the data.
Pseudonymization: Direct identifiers are replaced with codes, hashes, or tokens. A mapping exists that links the code back to the original identifier. Anyone with access to the mapping can re-identify the individuals.
The distinction is the mapping. A hashed MRN with no mapping anywhere in existence approaches de-identification. A hashed MRN with a retained mapping is pseudonymous data — PHI for any party holding that mapping.
When the Key Exists, the Data Is Identifiable
HIPAA defines individually identifiable health information as information that "identifies the individual or with respect to which there is a reasonable basis to believe the information can be used to identify the individual."
If your organization holds a table mapping a8f9d2c1... → MRN-12345 → Jane Doe, then:
- You can re-identify Jane Doe from the pseudonymized dataset
- The pseudonymized dataset is PHI for your organization
- HIPAA's minimum necessary standards, authorization requirements, and BAA obligations apply to how your organization uses and shares it
The recipient of the pseudonymized file who does not have the mapping is in a different position — they cannot re-identify individuals, so the file is de-identified relative to them. But this is not the same as the data being de-identified in a general regulatory sense.
A dataset is not "de-identified" simply because the current recipient lacks the key.
The Two Pseudonymization Use Cases
Use Case 1: Internal Longitudinal Linkage
A research team needs to track the same patient across multiple encounters over time. They replace MRNs with consistent hashes so that encounters belonging to the same patient link together in the analysis dataset. The mapping table is retained internally.
Regulatory status: The dataset remains PHI for the organization. The research team is operating with identifiable data. Standard HIPAA protections apply. If the dataset is shared with external collaborators, those collaborators are business associates and a BAA is required.
When this is appropriate: Internal research with IRB oversight, or data shared with external parties under a valid BAA.
Use Case 2: External Release Under Safe Harbor
A covered entity wants to release a dataset to an external research institution with no BAA — i.e., as de-identified data. Patient IDs must be replaced with codes. The Safe Harbor coded-record exception at §164.514(c) permits this if the conditions in §164.514(c)(1) (derivation test) and §164.514(c)(2) (security conditions) are met.
Regulatory status: If the conditions are satisfied, the coded dataset qualifies as de-identified for Safe Harbor purposes. The recipient receives de-identified data. The covered entity retains a mapping key but is restricted in how it can use or disclose that key.
Safe Harbor's Coded Record Exception: §164.514(b)(2)(i)(R) and §164.514(c)
The final element in the Safe Harbor identifier list, §164.514(b)(2)(i)(R), covers "any other unique identifying number, characteristic, or code" — but explicitly states the exception: "except as permitted by paragraph (c) of this section."
§164.514(c) is where the coded-record exception conditions are defined. HHS guidance confirms that covered entities may assign a code to allow re-identification of a de-identified dataset, provided the following conditions in §164.514(c) are met:
-
§164.514(c)(1) — Derivation test: the code is not derived from or related to information about the individual. A hash of the patient's SSN does not satisfy this condition because it is derived from PHI. A randomly generated UUID does.
-
§164.514(c)(2) — Security conditions: the covered entity does not use or disclose the code or mechanism for any other purpose, and does not disclose the mechanism for re-identification to the recipient of the de-identified data. If the recipient gets the key, the Safe Harbor exception is void.
Common MRN Replacement Approaches and Their Compliance Status
| Approach | Method | Key Retained? | §164.514(c) Compliant? | Notes |
|---|---|---|---|---|
| Deterministic hash of MRN | SHA-256(MRN) | No (but reproducible) | No — derived from PHI (the MRN) | Same MRN always produces same hash; not truly non-derivable |
| Deterministic hash of SSN | SHA-256(SSN) | No | No — derived from PHI | |
| Random UUID per patient | Generate fresh UUID | Yes (mapping stored) | Yes — if conditions 2 & 3 met | Mapping must not be shared with recipient |
| Sequential integer | 1, 2, 3... | Yes | Yes — if conditions 2 & 3 met | Appears arbitrary; not derived from individual info |
| HMAC with secret key | HMAC-SHA256(key, MRN) | Key stored separately | Partial — derived from MRN; key required to re-identify | Risk: key compromise allows re-identification |
| Encryption with retention | AES-encrypt(MRN, key) | Yes (key) | No — technically derived; reversible with key | Reversibility undermines de-identification claim |
The safest approach for Safe Harbor release: randomly generated identifiers with no mathematical relationship to the original PHI, with the mapping stored securely and not disclosed to recipients.
Step-by-Step: Pseudonymize Patient IDs in SplitForge
1. Identify which use case applies
Before processing: determine whether this is internal longitudinal linkage (retain the key, accept PHI status) or external release under Safe Harbor (key must not be derived from PHI, must not be disclosed to recipient).
2. Load the patient CSV
Open SplitForge Data Masking. Processing is local — patient IDs and MRNs never leave your browser during this step.
3. Select patient ID columns for replacement
Identify all columns containing direct patient identifiers: patient_id, mrn, medical_record_number, account_number, encounter_id (if encounter IDs are patient-linked).
4. Configure replacement type
For internal linkage: consistent hash or sequential ID — retaining a mapping table is acceptable; document PHI status internally.
For external Safe Harbor release: random identifier per patient — record the mapping securely, ensure the code is not mathematically derived from the original identifier, and confirm the mapping will not be shared with the recipient.
5. Remove or replace the remaining 17 Safe Harbor identifiers
Pseudonymizing the patient ID alone does not produce a Safe Harbor-compliant output. All 18 identifier types must be addressed. See the full Safe Harbor checklist.
6. Store and protect the mapping
For both use cases:
- Store the mapping table separately from the de-identified dataset
- Apply appropriate access controls
- For Safe Harbor release: document that the mapping will not be disclosed to the data recipient
Limitations
Satisfying Safe Harbor removes data from HIPAA's definition of PHI; it does not make the data anonymous. De-identified ≠ anonymized — residual re-identification risk can remain, and "actual knowledge" that the remaining data could identify someone re-activates HIPAA obligations.
Pseudonymization is not de-identification for the key-holder. This point is worth repeating: if your organization retains the mapping, the pseudonymized data is PHI for your organization, regardless of how it appears to anyone else.
Deterministic hashing of PHI fails the §164.514(c)(1) derivation test. SHA-256(MRN) is derived from the MRN, which is itself PHI. This approach does not meet the "not derived from or related to information about the individual" condition in §164.514(c)(1).
GDPR pseudonymisation is a different legal concept. Under GDPR, pseudonymisation has a specific definition that reduces some data subject rights obligations — but pseudonymised data is still personal data under GDPR. Do not conflate GDPR pseudonymisation with HIPAA de-identification. They are not equivalent.
Re-identification via linkage attacks remains possible. Even with MRNs replaced, if the dataset retains quasi-identifiers (age, diagnosis, ZIP, sex), re-identification via external linkage may still be feasible. See Validate PHI Removal for quasi-identifier risk assessment.
FAQ
Conclusion
The analyst who said "we replaced all the MRNs with hashes — it's de-identified" had the technical operation right. The legal conclusion was wrong.
The mapping table is the difference between pseudonymization and de-identification. As long as the mapping exists, the data is identifiable to the key-holder. HIPAA's protections apply.
Safe Harbor permits coded records in a de-identified release — but only with a replacement code that is not derived from the individual's information, used only for re-identification, and never disclosed to the recipient. A hash of the MRN fails the first condition. A mapping shared with the recipient fails the third.
For internal longitudinal research, retain the mapping, acknowledge the PHI status, and apply standard HIPAA safeguards. For external release under Safe Harbor, use randomly generated codes, protect the mapping, and confirm all 18 identifier elements have been addressed.
Next: Pre-Sharing PHI CSV Checklist → | De-Identify Patient Data for Research →