Pharmakovigilanz und Erkennung unerwünschter Ereignisse

Zulassungsinhaber müssen für jedes vertriebene Produkt vermutete Nebenwirkungen erfassen, bewerten und melden, meist aus unstrukturiertem Text in vielen Sprachen. Die KI liest eingehende Meldungen und Literatur, extrahiert die vier Mindestkriterien und die klinischen Details, schlägt MedDRA-Codes und den Schweregrad vor, markiert Doppelfälle und hilft Statistikern, Signale zu finden. Die Verantwortung bleibt beim Arzt der Arzneimittelsicherheit; der Gewinn liegt in weniger manueller Dateneingabe und einer schnelleren, einheitlicheren Fallbearbeitung.

Problem & Nutzen

• Heute: Sicherheitsteams (intern oder bei CROs) erhalten Meldungen per E-Mail, Telefon, Webformular, von Partnern und aus der Literatur. Mitarbeitende tippen sie in eine Sicherheitsdatenbank (Argus, ArisGlobal, Veeva) ab, kodieren Begriffe in MedDRA, prüfen Doppelfälle, bewerten den Schweregrad und entscheiden über beschleunigte Meldungen. Das Literatur-Screening von Tausenden Datensätzen für wenige relevante Fälle ist ein großer, wiederkehrender Arbeitsaufwand. Meldefristen sind gesetzliche Fristen (z. B. 15 Tage für schwerwiegende, 90 Tage für nicht schwerwiegende Fälle) nach EU-Recht [1][2].
• KI-Nutzen: automatisierte Erfassung und Triage, vorbefüllte ICSRs, Kodiervorschläge, Übersetzung fremdsprachiger Meldungen, Vorab-Screening der Literatur, schnellere Erkennung von Sicherheitssignalen. Anbieter und Arbeitsgruppen der Branche berichten von spürbaren Effizienzgewinnen bei Erfassung und Kodierung, doch veröffentlichte Zahlen schwanken je nach Umfeld stark und sind nicht vergleichbar; messen Sie Ihre eigene Ausgangslage [3].
• Behördenseite: Die EMA betreibt EudraVigilance, das ICSRs aus der EU empfängt; das Signalmanagement nutzt statistische Disproportionalität; nationale Behörden (BfArM, PEI) und das WHO Programme for International Drug Monitoring (VigiBase, Uppsala Monitoring Centre) betreiben ähnliche Werkzeuge [4][5].

Varianten

• Zulassungsinhaber / Arzneimittelsicherheit in der Pharmaindustrie: ICSR-Erfassung, Kodierung, Erstellung von Fallnarrativen, Sammelberichte (PSUR/PBRER).
• CRO / PV-Dienstleister: Fallbearbeitung für mehrere Kunden in großem Umfang, mit kundenspezifischen Regeln.
• Vigilanz bei Medizinprodukten (MDR): Meldung von Vorkommnissen und Trends nach MDR; ähnliches NLP, andere Formulare.
• Krankenhaus / regionales PV-Zentrum: Erkennung unerwünschter Arzneimittelereignisse in EHR-Notizen und Laborwerten (Trigger).
• Behörde / öffentlicher Sektor: Signal-Screening in Spontanmeldungs-Datenbanken.
• Soziale Medien und Patientenforen: Auswertung von Produktnennungen; viel Rauschen und hohe DSGVO-Sensibilität, oft beschränkt auf aggregiertes Monitoring statt Fallanlage.

So funktioniert es

1. Eingang (E-Mail / Formular / Scan / Literaturfeed / Partner-E2B)
2. OCR + Spracherkennung + Übersetzung
3. Prüfung der Fallgültigkeit (4 Kriterien: identifizierbare meldende Person, Patient, verdächtiges Produkt, Ereignis)
4. Informationsextraktion (Patient, Arzneimittel, Dosen, Daten, Ereignisse, Ausgang, Vorgeschichte)
5. MedDRA-Kodierung von Ereignissen/Indikationen + WHODrug-Kodierung der Produkte
6. Duplikaterkennung gegen bestehende Fälle
7. Vorschlag zu Schweregrad / Erwartetheit (gegenüber SmPC) / Kausalität + Entwurf der Fallbeschreibung
8. menschliche Prüfung und medizinische Bewertung (verpflichtend)
9. E2B(R3)-Übermittlung an EudraVigilance / Behörden
10. Signalerkennung auf der aggregierten Datenbank

• Extraktion: LLM mit strukturierter Ausgabe oder ein feingetuntes Encoder-NER-Modell für Entitäten wie Arzneimittel, Dosis, Ereignis, Beginn; beide werden gegen Wörterbücher geprüft.
• Kodierung: Retrieval über MedDRA-Begriffe (Embeddings plus Reranker), dann wählt ein LLM oder Klassifikator den Lowest Level Term; die Kodierung bleibt bis zur Validierung ein reiner Vorschlag.
• Signalerkennung: Klassische Disproportionalität (PRR, ROR, empirisch-bayessche Verfahren) bleibt das Rückgrat; ML ergänzt Clustering und die Triage von Fallserien.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine geschulte Fachkraft der Arzneimittelsicherheit bestätigt jeden Fall; die qualifizierte Person für Pharmakovigilanz (QPPV) verantwortet das System.

Datenaufbereitung

Eingangsdaten sind Einzelfallberichte (ICSRs; E2B, E-Mail, Fax, Notizen aus dem Callcenter, PDFs), Literatur und in manchen Konstellationen soziale Medien. Sie liegen in der Sicherheitsdatenbank, in gemeinsamen Postfächern, im DMS sowie in Papier- oder Scanformularen. Typische Lücken: gescannte oder gefaxte Meldungen ohne OCR, Doppelfälle desselben Falls von mehreren Meldern, Freitext in mehreren Sprachen, fehlende MedDRA-Codes, uneinheitliche Produktnamen und kein Referenzstandard dafür, was als gültiger Fall gilt.

Schritte der Aufbereitung: (1) Eingangskanäle und Verantwortliche erfassen (PREP-001, PREP-004); (2) Papier- und Fax-Eingänge digitalisieren und per OCR erfassen (PREP-006); (3) E-Mail-Archive und Altformate konvertieren (PREP-007); (4) Glossar für Produkte, Wirkstoffe und Abkürzungen (PREP-015) sowie ein Kategorienschema für Schweregrad und Kausalität aufbauen (PREP-019); (5) Labels aus bereits bearbeiteten Fällen gewinnen (PREP-020); (6) mit erfahrenen Ärzten der Arzneimittelsicherheit ein Testset erstellen (PREP-018); (7) Trainings- und Testkopien pseudonymisieren (PREP-022). Werkzeuge: OCR-Engines, Paperless-ngx für Eingangsarchive, die Importwerkzeuge des Anbieters der Sicherheitsdatenbank.

Der Aufwandsanteil ist mäßig, oft ein Viertel bis ein Drittel des Projekts, weil die Sicherheitsdatenbank bereits strukturierte, kodierte Historie enthält. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• Enterprise (Zulassungsinhaber, CROs): Weg A, weil validierte Suiten für Sicherheitsdatenbanken mit KI-Erfassung existieren und der Prozess regulierter Standard ist.
• Entwickler: Weg B, weil Extraktion, MedDRA-Kodierung und Triage mit Cloud-LLM-APIs und strukturierter Ausgabe schnell aufgebaut werden können.
• Öffentlicher Sektor (Behörden, öffentliche Institute): Weg C auf souveräner Infrastruktur, weil Falldaten sensibel sind und Vergaberegeln Kontrolle und Nachprüfbarkeit begünstigen.

Weg A — Kaufen (empfohlen)

• Sicherheitsplattformen mit integrierter KI: Oracle Argus Safety und Oracle Life Sciences Safety One, ArisGlobal LifeSphere (mit den NavaX-/KI-Erfassungsfunktionen), Veeva Vault Safety (inkl. Automatisierung der Erfassung), IQVIA Vigilance Platform und Technology-Enabled Services, Genpact, Accenture und andere PV-Outsourcer, Lorenz (Deutschland/EU, z. B. Lorenz-Pharmakovigilanz-Produkte), Sarjen, Ennov (Frankreich, EU). Prüfen Sie den aktuellen KI-Funktionsumfang bei jedem Anbieter; er ändert sich schnell.
• Literaturüberwachung: Embase/Elsevier, Clarivate und PV-spezifische Screening-Werkzeuge der Anbieter von Sicherheitssoftware.
• A wählen, wenn: Sie bereits eine validierte Sicherheitsdatenbank betreiben; das Anbietermodul fügt sich in eine validierte GxP-Umgebung ein und erspart Ihnen die eigene Validierung computergestützter Systeme.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Extraktion und Narrative: führende LLM-APIs (Claude, Gemini, GPT) oder Mistral (EU) in einer EU-Region unter einem Auftragsverarbeitungsvertrag, mit strukturierten JSON-Ausgaben; Azure OpenAI oder Amazon-Bedrock-EU- Regionen für Unternehmensverträge.
• Dokumentenerfassung: Azure AI Document Intelligence, Google Document AI, AWS Textract für gescannte Formulare.
• Wörterbücher: MedDRA (lizenziert über MSSO/ICH) und WHODrug (UMC) sind lizenzpflichtig, daher werden Retrieval-Indizes innerhalb Ihres Tenants aufgebaut.
• Integration: Entwürfe über die API oder den E2B-Import in die Sicherheitsdatenbank übergeben, nie direkt an die Behörde.
• B wählen, wenn: Sie auf einer bestehenden Sicherheitsdatenbank eine eigene Erfassung für ungewöhnliche Quellen (Patientenprogramme, lokale Sprachen) benötigen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-LLMs wie die Familien Llama, Qwen, Mistral und Gemma für die Extraktion; biomedizinische Encoder (BioBERT, PubMedBERT, BioLORD) für NER und Begriffs-Retrieval; Übersetzung mit NLLB oder einem LLM.
• Stack: Betrieb mit vLLM oder Ollama, ein OpenSearch-/pgvector-Index von MedDRA, n8n oder Camunda für Workflows. OHDSI-Werkzeuge (OMOP CDM, HADES und offene Disproportionalitätsmethoden) für Signalarbeit auf EHR-/Abrechnungsdaten [6].
• Hardware: HW3 für Modelle mit 30-120 Mrd. Parametern bei langen Fallnarrativen; HW2 genügt nur für NER und Kodierung.
• Wann: Wenn Daten auf Patientenebene das Haus nicht verlassen dürfen, oder im Maßstab von Krankenhäusern und Behörden.

Weg D — Eigenes Training

Ein NER- und Kodiermodell auf den eigenen historischen kodierten ICSRs feintunen (typischerweise Tausende Fälle, Korrekturen der Prüfer als laufende Trainingsdaten). Lohnt sich bei hohem Volumen, nicht englischsprachigen Quellen oder wenn die Genauigkeit der Wörterbuchkodierung geschäftskritisch ist. Erfordert eine sorgfältige Holdout-Evaluation nach Wirkstoffklasse und Sprache.

Stand der Technik (2026)

• LLM-basierte Erfassung ist bei großen Zulassungsinhabern und CROs im Produktivbetrieb, meist nach dem Prinzip „entwerfen und prüfen“: Die Extraktion von Fallelementen ist bei sauberem Text stark; die Genauigkeit sinkt bei handschriftlichen Formularen, Narrativen mit mehreren Arzneimitteln, zeitlicher Schlussfolgerung (Beginn vs. Expositionsdatum) und Verneinung („kein Ausschlag“).
• MedDRA-Kodierung mit Retrieval-plus-LLM-Ansätzen ist bei häufigen Begriffen mit geschulten Kodierern konkurrenzfähig und bei seltenen oder mehrdeutigen Begriffen schwächer; Kodierer prüfen die Vorschläge.
• Leitlinien: Das EMA-Reflection-Paper zu KI im Lebenszyklus von Arzneimitteln fordert risikobasierte Validierung, menschliche Aufsicht und Nachvollziehbarkeit; die CIOMS Working Group XIV behandelt KI in der Pharmakovigilanz und deckt Human-in-the-Loop, Erklärbarkeit und Validierung ab [7][8].
• Signalerkennung: Disproportionalität plus ML auf EHR- und Real-World-Daten nimmt zu; kausale Aussagen aus Spontandaten bleiben ohne medizinische Prüfung unsicher.
• Grenzen: erfundene Daten oder Dosierungen, Verzerrung durch Untermeldung in den Quelldaten, unzuverlässige Kausalitäts- vorschläge und Melderverzerrung in sozialen Medien. Ein übersehener schwerwiegender Fall ist ein Compliance-Befund, daher wiegt der Recall beim Schweregrad schwerer als die Precision.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + llm-general + text-classifier): DOC-014 Dokumentenanalyse, HLTH-005 Kodier- automatisierung, HLTH-028 Terminologie-Mapping (MedDRA, SNOMED CT, FHIR).
• Vor- und nachgelagert: HLTH-009 Studien-Matching (gemeinsame Sicherheitsdaten), HLTH-017 Zulassungsdokumente (PSUR, RMP), HLTH-029 GMP-Abweichungen und CAPA (Qualitätsbeschwerden, die zugleich unerwünschte Ereignisse sind), HLTH-004 für Wechselwirkungsprüfungen für Ärzte, ANOM-007 für das Werkzeugset zur Anomalieerkennung.
• Gemeinsame Infrastruktur: Ein GxP-validiertes LLM-Gateway und ein MedDRA-Retrieval-Index können mehrere Pharma-Anwendungsfälle bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Quartale, getrieben durch Validierung, Datenmigration und Änderungskontrolle des Anbieters.
• Weg B: 3-6 Monate für eine validierte Ergänzung einer bestehenden Sicherheitsdatenbank.
• Weg C/D: 6-12 Monate inkl. Validierung computergestützter Systeme und einem eigenen ML-Team.
• Kostentreiber: Validierung (nach GAMP 5), Lizenzen (MedDRA, WHODrug), Zeit für die menschliche Prüfung, Übersetzung.
• Kennzahlen: Zeit bis zur Falleingabe, Einhaltung der 15-/90-Tage-Fristen, Recall bei schwerwiegenden Fällen, Genauigkeit der Extraktion je Feld, Übereinstimmung der MedDRA-Kodierung mit den Kodierern, Erkennungsrate von Doppelfällen, Recall und Entlastung beim Literatur-Screening, Übersteuerungsquote der Prüfer.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsführung und der Leitung der Arzneimittelsicherheit (Prozessverantwortliche und qualifizierte Person für Pharmakovigilanz), dann mit Recht und Compliance für die Pflichten nach GVP und Validierung, IT und IT-Sicherheit für Integration und Hosting sowie frühzeitig der bzw. dem Datenschutzbeauftragten. Fallbearbeiter und medizinische Prüfer sind die Endnutzer; beziehen Sie sie in die Festlegung des Testsets und der Prüfregeln ein.

Betriebsrat: abhängig vom Einzelfall. Das Werkzeug verarbeitet Fälle, nicht Beschäftigte, doch Durchsatz-Dashboards oder Qualitätskennzahlen je Person machen es geeignet, die Leistung zu überwachen, und lösen § 87 Abs. 1 Nr. 6 BetrVG aus; § 90 Abs. 1 Nr. 3 verlangt die Unterrichtung über geplante KI-gestützte Arbeitsprozesse. Vereinbaren Sie eine Betriebsvereinbarung, die individuelle Leistungsbewertung aus KI-Ausgaben ausschließt (GUIDE-004).

Datenschutz: Meldungen enthalten Gesundheitsdaten, führen Sie daher eine Datenschutz-Folgenabschätzung (DSFA) durch, schließen Sie mit Anbietern einen AVV und dokumentieren Sie die Rechtsgrundlage (GUIDE-005).

KI-Kompetenz: Unterstützen Sie Fallbearbeiter mit Schulungen zu typischen Fehlern wie übersehenen Verneinungen oder falschen MedDRA-Begriffen (GUIDE-006). Pilotieren Sie mit einem Produkt oder einem Eingangskanal, laufen Sie im Schattenbetrieb neben der manuellen Bearbeitung und halten Sie die medizinische Prüfung bei Schweregrad und Kausalität verbindlich. Begegnen Sie der Sorge vor Arbeitsplatzverlust, indem Sie zeigen, dass Mengenwachstum aufgefangen und kein Personal abgebaut wird (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Ein typisches PV-Werkzeug ist kein Anwendungsfall nach Anhang III und selbst kein Medizinprodukt, daher gilt minimales Risiko mit der Pflicht zur KI-Kompetenz (Art. 4). Stufen Sie neu ein, wenn das Werkzeug individuelle Diagnose- oder Behandlungsentscheidungen liefert (Medizinprodukte-Software nach MDR, dann hochriskant nach Art. 6 Abs. 1).
• DSGVO: Meldungen enthalten Gesundheitsdaten (Art. 9); Rechtsgrundlage sind eine rechtliche Verpflichtung und das öffentliche Interesse im Bereich der öffentlichen Gesundheit (Art. 6 Abs. 1 Buchst. c, Art. 9 Abs. 2 Buchst. i); Identifikatoren minimieren, EU-Hosting beibehalten, DSFA empfohlen, strenge Regeln für Daten aus sozialen Medien.
• Pharmakovigilanz-Recht: Richtlinie 2001/83/EG, Verordnung (EG) Nr. 726/2004, Durchführungsverordnung (EU) Nr. 520/2012 und die Module der EMA-Leitlinien zur guten Pharmakovigilanz-Praxis (GVP), insbesondere Modul VI (ICSR- Management) und Modul IX (Signale) [1][2]. Computergestützte Systeme unterliegen den Erwartungen von GxP und EU-GMP-Anhang 11, Audit Trails und Inspektionsbereitschaft.
• Gegenmaßnahmen: dokumentierte Validierung mit einem repräsentativen Testset, menschliche Freigabe jedes Falls, Drift-Überwachung, Auditprotokoll der KI-Vorschläge im Vergleich zu den endgültigen Einträgen, Anbieteraufsicht im PV-System Master File (PSMF).

Erste Schritte

1. Ausgangslage: Fallvolumen nach Quelle, Sprachen, Durchlaufzeit, Fristeinhaltung und Abweichungen zwischen Kodierern.
2. Fragen Sie den Anbieter Ihrer Sicherheitsdatenbank, welche KI-Module validiert sind, und pilotieren Sie diese zuerst.
3. Bauen Sie ein Referenzset („Gold Set“) aus 300-500 historischen Fällen (geschwärzt) auf, um Extraktion und Kodierung zu bewerten.
4. Laufen Sie im Schattenbetrieb: Die KI entwirft, Menschen erfassen unabhängig; vergleichen Sie Feld für Feld.
5. Stimmen Sie sich vor dem Produktivstart mit QPPV und QA zu Validierung, SOP-Änderungen und Inspektionsdokumentation ab.

Quellen

1. EMA — Good pharmacovigilance practices (GVP), incl. Module VI — https://www.ema.europa.eu/en/human-regulatory-overview/post-authorisation/pharmacovigilance-post-authorisation/good-pharmacovigilance-practices
2. EMA — EudraVigilance — https://www.ema.europa.eu/en/human-regulatory-overview/research-development/pharmacovigilance-research-development/eudravigilance
3. CIOMS Working Group XIV — Artificial Intelligence in Pharmacovigilance — https://cioms.ch/working_groups/working-group-xiv/
4. Uppsala Monitoring Centre — VigiBase — https://who-umc.org/vigibase/
5. FDA — Adverse Event Monitoring System (AEMS, formerly FAERS) public dashboard — https://www.fda.gov/drugs/fda-adverse-event-monitoring-system-aems/fda-adverse-event-monitoring-system-aems-public-dashboard
6. OHDSI — Observational Health Data Sciences and Informatics — https://www.ohdsi.org/
7. EMA — Reflection paper on the use of AI in the medicinal product lifecycle — https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline
8. ICH — E2B(R3) Individual case safety reports — https://www.ich.org/page/efficacy-guidelines
9. MedDRA — Medical Dictionary for Regulatory Activities — https://www.meddra.org/
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj