Pseudonymizing For Gdpr

Pseudonymizing for GDPR

Pseudonymization under the GDPR (Art. 4(5)) means processing personal data so it "can no longer be attributed to a specific data subject without the use of additional information" — provided that additional information (the re-linkage key) is "kept separately and is subject to technical and organisational measures." Crucially, pseudonymized data is still personal data (Recital 26): re-linkage is possible, so GDPR still applies. This is the opposite of anonymization, where re-identification is irreversibly prevented and the data falls outside the GDPR.

OpenMed implements this with a single reversible de-identification pass plus a mapping you store away from the data. This skill covers producing that mapping, vaulting the key separately, and re-linking under authorization.

When to use

• You process EU residents' personal or special-category health data (Art. 9) and need a lawful, reversible safeguard rather than full anonymization.
• You need to keep a record-linkage capability (e.g. to recontact a patient, reconcile longitudinal records, or honor a Subject Access Request) but must separate the linkage key from the working dataset.
• A reviewer asks for the pseudonymization-vs-anonymization distinction in writing, or for the ENISA-style "additional information kept separately" control to be demonstrable.

Do not use this when the goal is irreversible anonymization for open release — there, drop the mapping entirely and gate residual risk with reviewing-reidentification-risk. Pseudonymization keeps a key; anonymization must not.

Quick start

import openmed

# Synthetic record — never run this skill's examples on real PHI.
note = "Patient Maria Schmidt (ID 4471) seen 2024-03-02; contact maria@example.de."

result = openmed.deidentify(
    note,
    method="replace",                 # realistic surrogates, not [LABEL] holes
    policy="gdpr_pseudonymization",   # bundled GDPR profile
    keep_mapping=True,                # produce the reversible re-linkage map
    consistent=True,                  # same input -> same surrogate in the doc
    seed=20240302,                    # cross-run reproducibility of surrogates
)

pseudonymized_text = result.deidentified_text   # safe to process / analyze
relink_key = result.mapping                      # surrogate -> original; SECRET

result.deidentified_text is the pseudonymized payload. result.mapping is the "additional information" GDPR Art. 4(5) requires be kept separately — it is the key that makes re-linkage possible, and therefore the most sensitive artifact in the whole flow.

Workflow

1. Choose reversible pseudonymization, not masking. Use method="replace" with policy="gdpr_pseudonymization" and keep_mapping=True. Replacement surrogates keep the text usable for downstream NLP while remaining non-identifying. consistent=True (optionally with seed=) makes repeated mentions resolve to one stable surrogate so intra-document linkage survives.
2. Split the data from the key immediately. The moment deidentify returns, route result.deidentified_text to your working store and result.mapping to a separate, access-controlled key vault — different system, different credentials, different backups. Never persist them in the same row, file, bucket, or log line. This separation is the technical-and-organisational measure that makes the data pseudonymized rather than just "personal data with PII in it."
3. Process the pseudonymized text freely. Run analyze_text, analytics, model training, or transfer on deidentified_text. The key never leaves the vault during ordinary processing.
4. Re-link only under authorization. When a lawful basis exists (e.g. an authorized SAR or recontact), fetch the mapping from the vault and call openmed.reidentify(deidentified_text, mapping). Log that a re-linkage happened (who, when, why, record id) — but never log the restored plaintext.
5. Apply retention to the key. The mapping has its own retention clock. When the lawful basis for re-linkage ends, destroy the mapping. Once the key is irreversibly gone and no other re-identification path remains, the remaining text approaches anonymization and GDPR obligations shrink accordingly. Verify that claim with reviewing-reidentification-risk before relying on it.