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.
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.
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.
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.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."analyze_text, analytics,
model training, or transfer on deidentified_text. The key never leaves the
vault during ordinary processing.openmed.reidentify(deidentified_text, mapping). Log that a re-linkage
happened (who, when, why, record id) — but never log the restored plaintext.reviewing-reidentification-risk before
relying on it.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.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.auditing-deid-leakage: scan result.deidentified_text for residual
identifiers before it leaves the boundary — pseudonymization is only as strong
as detection.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.mapping exists anywhere, the data
is personal data under Recital 26. Do not market a keep_mapping=True output
as "anonymous."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.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.