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.

1. 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."

1. 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.

1. 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.

1. 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.

Hand-off to / from OpenMed

• From extracting-pii-entities / configuring-privacy-policies: confirm

the detector recall and the active policy profile before pseudonymizing, since
any identifier the detector misses leaks into deidentified_text.

• OpenMed call: Python from openmed import deidentify, reidentify; the same

capability is exposed as MCP tool openmed_deidentify and REST /deidentify.
Pass policy="gdpr_pseudonymization", keep_mapping=True.

• To auditing-deid-leakage: scan result.deidentified_text for residual

identifiers before it leaves the boundary — pseudonymization is only as strong
as detection.

• To reviewing-reidentification-risk: quasi-identifier (age, ZIP, dates)

re-identification still applies to pseudonymized data; score k-anonymity on the
output and document residual risk.

Edge cases & gotchas

• Pseudonymized ≠ anonymized. As long as mapping exists anywhere, the data

is personal data under Recital 26. Do not market a keep_mapping=True output
as "anonymous."

• The mapping is the crown jewel. A leaked mapping re-identifies everything

at once. Treat it as the highest-sensitivity secret: encrypt at rest, restrict
access, audit reads.

• Surrogates can still carry quasi-identifiers. method="replace" swaps the

identifier text, but free-text age, rare diagnosis, ZIP, or admission dates
remain. Pseudonymization does not address singling-out; pair with QI risk
scoring.

• Reproducibility cuts both ways. A fixed seed makes surrogates stable

across runs (good for linkage) but means an attacker who learns the seed and
algorithm can reproduce surrogates — keep the seed with the key, not the data.

• Special-category data (Art. 9). Health data needs a lawful basis before

processing; pseudonymization is a safeguard, not a lawful basis on its own.

• Local-first. Run entirely on-device. Do not send EU personal data to a

cloud de-identification service to satisfy GDPR — that may itself be a transfer.

Standards & references

• GDPR Art. 4(5) — definition of pseudonymization:

https://gdpr-info.eu/art-4-gdpr/

• GDPR Art. 9 — processing of special categories (health) data:

https://gdpr-info.eu/art-9-gdpr/

• GDPR Recital 26 — pseudonymous data is personal data; anonymization test:

https://gdpr-info.eu/recitals/no-26/

• ENISA, Pseudonymisation techniques and best practices (2019):

https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices

• EDPB Guidelines on pseudonymisation (01/2025):

https://www.edpb.europa.eu/