OpenMed is local-first healthcare AI software that extracts clinical information and removes personally identifying details from clinical text on hardware controlled by the user. Healthcare developers use its Python runtime, Apple Silicon and mobile SDKs, and browser support for on-device clinical NER and PII de-identification.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add maziyarpanahi/openmed --skill pseudonymizing-for-gdprgit clone --depth 1 https://github.com/maziyarpanahi/openmedWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/maziyarpanahi/openmed/pseudonymizing-for-gdpr)<a href="https://agentmods.dev/skills/maziyarpanahi/openmed/pseudonymizing-for-gdpr"><img src="https://agentmods.dev/badge/skills/maziyarpanahi/openmed/pseudonymizing-for-gdpr/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/maziyarpanahi/openmed/pseudonymizing-for-gdpr"><img src="https://agentmods.dev/badge/skills/maziyarpanahi/openmed/pseudonymizing-for-gdpr.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00158 | $0.01884 |
| Opus 5 | $0.00079 | $0.00942 |
| Sonnet 5 | $0.00032 | $0.00377 |
| Haiku 4.5 | $0.00016 | $0.00188 |
Grade A, and why
pseudonymizing-for-gdpr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 144 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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 [email protected]."
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
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 144 lines · 158 tokens per session scan A a4df912d7860
pseudonymizing-for-gdpr is a skill published in the GitHub repository maziyarpanahi/openmed (5,282 stars, last pushed today), licensed Apache-2.0. It adds 158 tokens to every session and 1,884 once invoked, about $0.0008 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
benchmarking
Use this skill when the user wants to benchmark an MLX-VLM change and present the numbers in a PR — fork-vs-main A/B comparisons, isolated-module micro-benchmarks, median-of-N timing with warmup, peak-memory reporting, correctness checks, parameter sweeps, and self-contained reproducible bench scripts to paste into a…
cli-inference
Use this skill when the user wants to run or debug MLX-VLM inference from the command line, including uv run mlxvlm.generate, image/audio/video inputs, local model paths, Hugging Face model IDs, deterministic repro commands, and CLI errors around processors, prompts, model loading, or missing weights.
convert-quantize
Use this skill when the user wants to convert a Hugging Face model to MLX or quantize/dequantize one with mlxvlm.convert, including bits and group size, quant modes (affine, mxfp4, nvfp4, mxfp8), RTN vs AWQ, mixed-bit recipes, dtype casts, calibration (text or multimodal), local vs Hub paths, revisions, uploading to…
server-inference
Use this skill when the user wants to run or debug MLX-VLM server inference, including uv run mlxvlm.server, /v1/models, /v1/chat/completions, /v1/responses, streaming, OpenAI-compatible clients, health checks, metrics, model unload/reload, adapters, trust-remote-code, and server request/response failures.
fda-database
Query openFDA API for drugs, devices, adverse events, recalls, regulatory submissions (510k, PMA), substance identification (UNII), for FDA regulatory data analysis and safety research.
meta-compliance-audit-bundle
Auditable compliance bundle: deep-research with citations → signable .docx report → read-only PDF archive → memory note of audit findings.