OpenMed: Klinische NER und PII-Bereinigung lokal auf eigener Hardware

OpenMed als lokale Laufzeit für klinische Texte

OpenMed versteht sich als lokal arbeitendes KI-Paket für das Gesundheitswesen. Das README beschreibt die Kernlaufzeit als Komponente, die Extraktion und Desidentifizierung übernimmt, sobald die nötigen Modell-Artefakte verfügbar sind. Damit bleiben die eigentliche Verarbeitung auf der eigenen Hardware, während optionale Netzwerkpfade nur für Modell-Downloads, entfernte Adapter, Telemetrie und benutzerkonfigurierte Integrationen vorgesehen sind. Wer unterschiedliche Modelle und Datensätze einsetzt, soll deren Bedingungen prüfen.

Das SDK läuft mit Python 3.10 und höher, ist als PyPI-Paket openmed erhältlich und steht unter Apache-2.0. Die GitHub-Beschreibung zählt über 2.200 medizinische Modelle und 21 Sprachen auf; das README selbst verweist auf einen kuratierten Katalog und nennt 33 sprachgestützte PII-Laufzeiten, macht aber keine vergleichbare Gesamtzahl im Fließtext. Das Repository verzeichnet 5174 Sterne und 651 Forks, die aktuelle Veröffentlichung ist v2.2.0 vom August 2026.

Schnellstart mit analyze_text

Das README zeigt einen Einstieg in 30 Sekunden per Python. Der Aufruf analyze_text aus dem Paket openmed nimmt einen klinischen Satz entgegen, etwa zu einer Therapie mit Imatinib bei chronischer myeloischer Leukämie, und liefert mit dem Modellnamen disease_detection_superclinical eine Liste von Entitäten. Die Ausgabe enthält je Eintrag das Label, den gefundenen Text und einen Konfidenzwert, im Beispiel die Krankheit mit 0.98 und das Medikament mit 0.95.

Diese Schnittstelle bildet den Kern des SDK: klinischer Text hinein, strukturierte Entitäten heraus. Für Detailfragen verweist das README auf die Agenten-Dokumentation unter docs/agent-usage.md, auf den MCP-Server unter docs/mcp-clients.md und auf einen Befehlszeilenzugang. Ein Index der Dokumentation liegt als llms.txt auf openmed.life/docs bereit. Damit sind sowohl menschliche Nutzer als auch automatisierte Werkzeuge ansprechbar.

Der kuratierte Modellkatalog im Überblick

OpenMed führt laut README ein Register spezialisierter medizinischer NER-Modelle. Fünf Beispiele sind dort genannt: disease_detection_superclinical erkennt Krankheiten und Diagnosen, pharma_detection_superclinical Medikamente und Behandlungen, pii_superclinical_large personenbezogene Felder wie Name, Datum, SSN, Telefon, E-Mail und Adresse, anatomy_detection_electramed Anatomie und Körperteile, und gene_detection_genecorpus Gene und Proteine. Die Größen reichen von 434M Parametern bei den großen klinischen Modellen bis 109M bei den kompakteren Varianten.

Den vollständigen Katalog führt das README über openmed.life/docs weiter. Entscheidend für den Einsatz ist der Hinweis, dass Modell- und Datensatzbedingungen variieren und jedes Modell für den eigenen Anwendungsfall zu prüfen ist. Wer also ein Modell in einer Klinik einsetzen will, sollte Herkunft, Lizenz und Trainingsdaten je Modell separat validieren, statt sich auf die Sammelbeschreibung zu verlassen. Die genauen Bedingungen stehen in den Modellkarten der Quellen.

PII-Erkennung und Desidentifizierung im Detail

Für die Bereinigung personenbezogener Daten stellt die Funktion extract_pii die Erkennung bereit, während deidentify vier Methoden anbietet: mask, replace, hash und shift_dates. Das Beispiel im README führt NAME, DATE und SSN durch alle vier Verfahren, sodass maskierte, ersetzte, gehashte und um Datumsverschiebungen korrigierte Ausgaben entstehen. Ein Smart-Merging hält zusammengesetzte Werte wie ganze Datumsangaben zusammen, statt sie zu zerlegen.

Richtlinienbewusste Pipelines ergänzen Profile für HIPAA, GDPR und Forschung, kalibrierte Schwellenwerte und signierte Audit-Berichte. Eine Faker-basierte Verschleierung unterstützt eigene Anbieter für klinische Kennungen wie CPF, CNPJ, BSN, NIR, Codice Fiscale, NIE, Aadhaar, Steuer-ID und NPI. Das README betont, dass die Safe-Harbor-Kategorien nur Hilfen zur Umsetzung sind; eine fachkundige Prüfung der Bereitstellung bleibt verpflichtend, und die bloße Nutzung des SDK begründet keine HIPAA-Konformität.

Mehrsprachige PII-Unterstützung

Die Extraktion und Desidentifizierung deckt eine breite Sprachpalette ab. Das README listet 34 Sprachcodes, darunter en, de, fr, es, ar, hi, ja, ko, zh und weitere. Für das Russische greift die Routing laut Dokumentation auf einen mehrsprachigen Standard-Modellwert zurück, während Bengalisch, Chinesisch und Tamil eigene Registereinträge besitzen. Eine optionale Indic-NER-Familie nimmt vier zusätzliche Routen auf und bedient über die Variable OPENMED_INDIC_NER_MODEL auch Assamesisch, Hindi, Marathi, Odia, Tamil und Telugu.

Ergänzend nennt das README validatorenbasierte Prüfungen nationaler IDs für weitere Lokalisierungen wie Polnisch, Lettisch, Slowakisch, Malaiisch, Filipino und Finnisch. In den Unterlagen finden sich Beispiele unter anderem für Portugiesisch, Niederländisch, Hindi, Arabisch, Japanisch und Türkisch. Wer also mehrsprachige Dokumente verarbeitet, findet für die wichtigsten Sprachräume Routen, muss aber die regionalen ID-Formate mit den eigenen Daten abgleichen.

Plattformen: Apple, Android und Browser

Auf unterstützter Apple-Hardware nutzt OpenMed MLX und das Swift-Paket OpenMedKit. Die Installation läuft per Swift Package Manager ab Version 2.2.0. Das README berichtet, dass MLX für den Privacy Filter 24 bis 33 mal schneller arbeitet als CPU-PyTorch, gemessen an der mittleren Latenz je Inferenzschritt. Ein CoreML-Pfad dient als Rückfallebene für unterstützte Token-Klassifikations-Artefakte. Auf Apple Silicon lässt sich zudem die Python-Variante über pip install --upgrade openmed[mlx] nachrüsten.

Auf Android liefert OpenMedKit eine native Kotlin-Bibliothek für Dokumenterfassung, OCR-Übergabe, PII-Schwärzung und Inferenz über ONNX Runtime Mobile. Die Einbindung erfolgt über die JitPack-Repository-Erweiterung mit der unveränderlichen Version com.github.maziyarpanahi:openmed:v2.2.0. Dasselbe ONNX-Modell kann nach README-Angabe auch in Python auf CPU und im Browser über Transformers.js laufen. Ein FastAPI-basierter Dienst mit Endpunkten wie /analyze, /pii/extract und /health rundet die Dienst-Szenarien ab.

Fazit: Einsatzbedingungen und Grenzen von OpenMed

OpenMed eignet sich für Teams, die klinische Texte und PII lokal verarbeiten wollen, ohne Patientendaten an externe Dienste zu geben. Der Einstieg über analyze_text und die Desidentifizierung mit mask, replace, hash und shift_dates sind dokumentiert, ebenso die Pfade über MLX, OpenMedKit, Android und Transformers.js. Die Apache-2.0-Lizenz erlaubt freie Nutzung des SDK, während Modell- und Datensatzbedingungen je Quelle zu prüfen sind.

Nicht geeignet ist OpenMed für Umgebungen, die ohne die nötigen Modell-Artefakte arbeiten wollen, und die README macht die HIPAA-Grenze explizit: Die SDK-Nutzung allein schafft keine Compliance. Sicherheitslücken insbesondere bei Schwärzungsumgehungen sollen laut README privat über das Security-Advisory gemeldet werden, nicht als öffentliches Issue. Die erste Konfiguration sollte daher immer mit synthetischen Daten erfolgen; einen echten Patientenbestand verarbeitet man erst nach der Prüfung des jeweiligen Modells gegen die eigene Dokumentation.

Redaktionelles Fazit

OpenMed eignet sich für Anwender, die klinische Texte lokal verarbeiten wollen, sodass Patientendaten das eigene Netz nicht verlassen. Kernlaufzeit, Modellkatalog und Desidentifizierungsmethoden sind dokumentiert, doch die README stellt klar, dass die alleinige Nutzung des SDK keine HIPAA-Konformität begründet und die Bereitstellungsprüfung in der Verantwortung des Betreibers bleibt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes