# Pseudonymizing For Gdpr

Apply GDPR-grade pseudonymization to clinical or personal text with OpenMed, keeping a...

- Repository: https://github.com/maziyarpanahi/openmed (5755 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add maziyarpanahi/openmed --skill pseudonymizing-for-gdpr -g -a claude-code -y`
Codex: `npx skills add maziyarpanahi/openmed --skill pseudonymizing-for-gdpr -g -a codex -y`
Cursor: `npx skills add maziyarpanahi/openmed --skill pseudonymizing-for-gdpr -g -a cursor -y`
Gemini CLI: `npx skills add maziyarpanahi/openmed --skill pseudonymizing-for-gdpr -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add maziyarpanahi/openmed`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

```python
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."

The rest: https://github.com/maziyarpanahi/openmed/blob/HEAD/skills/pseudonymizing-for-gdpr/SKILL.md