Pseudonymization

Pseudonymization targets direct identifiers—fields that uniquely pinpoint an individual without additional context:

• Direct identifiers: Name, email address, social security number, patient ID, phone number
• Indirect identifiers (quasi-identifiers): Date of birth, ZIP code, gender, diagnosis codes

The technique replaces direct identifiers with pseudonyms while leaving quasi-identifiers intact, which is why pseudonymized data remains personal data under GDPR and requires continued safeguards against re-identification through linkage attacks.

The defining characteristic separating pseudonymization from anonymization is reversibility. A separately stored mapping table or cryptographic key can relink pseudonyms to original identities.

• Key custody: The mapping must be held by a distinct, authorized party with strict access controls
• Technical separation: Keys stored in hardware security modules (HSMs) or separate encrypted databases
• Operational separation: Different teams manage pseudonymized data and the re-identification keys

This reversibility enables clinical trial unblinding, longitudinal patient tracking, and regulatory audits while maintaining pseudonymity during routine processing.

Modern pseudonymization employs cryptographic functions to generate pseudonyms deterministically or randomly:

• Hash-based pseudonyms: One-way hash functions (SHA-256) with a secret salt produce consistent pseudonyms across datasets without storing a mapping table
• Encryption-based pseudonyms: Symmetric encryption (AES-256) of identifiers using a securely stored key, enabling reversible pseudonym generation
• Tokenization: Random token generation with a secure token vault mapping tokens to original values, common in payment processing

Deterministic methods allow consistent pseudonyms across distributed datasets, critical for federated learning where the same patient must be pseudonymized identically at every institution.

In healthcare federated learning, pseudonymization serves as a pre-processing privacy layer before data enters the training pipeline:

• Patient identifiers are pseudonymized locally at each hospital before model training begins
• Consistent pseudonyms across sites enable record linkage for longitudinal analysis without revealing identity
• Combined with secure aggregation, pseudonymization prevents the central server from associating model updates with specific individuals

However, pseudonymization alone is insufficient for strong privacy guarantees—gradient leakage attacks can still reconstruct training data features, necessitating additional protections like differential privacy.

Pseudonymized data remains personal data under GDPR Article 4(5), unlike anonymized data which falls outside the regulation's scope entirely:

• Still subject to GDPR: Data protection principles, purpose limitation, and storage limitation still apply
• Risk-based approach: Pseudonymization is explicitly listed as an appropriate technical measure for data protection by design (Article 25)
• Breach mitigation: If pseudonymized data is breached, notification obligations may be reduced since the data is unintelligible without the key
• Processing flexibility: Pseudonymization can enable processing for compatible purposes beyond the original collection purpose (Article 6(4))

Pseudonymized datasets remain vulnerable to linkage attacks when quasi-identifiers are present:

• Record linkage: Matching pseudonymized records to external identified datasets using shared quasi-identifiers (e.g., ZIP code + DOB + gender uniquely identifies 87% of the US population)
• Attribute disclosure: Inferring sensitive attributes from the combination of quasi-identifiers without necessarily re-identifying the individual
• Singling out: Isolating an individual's records within a dataset even without knowing their identity

Mitigations include k-anonymity enforcement, controlled data release, and legal contracts prohibiting re-identification attempts by data recipients.