Pseudonymizing For Gdpr
Apply GDPR-grade pseudonymization to clinical or personal text with OpenMed, keeping a...
Install
npx skills add maziyarpanahi/openmed --skill pseudonymizing-for-gdpr -g -a claude-code -y- Repository
- maziyarpanahi/openmed5.8k
- Category
- Engineering
- Updated
- 4d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 1,764 tokens
- Runs scripts
- No, instructions only
What it does
Apply GDPR-grade pseudonymization to clinical or personal text with OpenMed, keeping a separately-held re-linkage key so the data can be controlled-re-linked later. Use when the user must process EU personal/health data under GDPR, asks for pseudonymization vs anonymization, needs Art. 4(5) / Art. 9 / Recital 26 alignment, wants a reversible mapping/key vault held apart from the data, or needs controlled re-linkage. Covers openmed.deidentify(policy=\"gdpr_pseudonymization\", keep_mapping=True), storing the mapping in a separate key vault, reidentify() for authorized re-linkage, and retention. Pairs after extracting-pii-entities and configuring-privacy-policies.
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."
