ADR-Meldungen in der Pharmakovigilanz mit KI beschleunigen

Das echte Ausmaß des Problems

In der Europäischen Union wurden 2024 rund 1,76 Millionen ICSRs (Individual Case Safety Reports) in der EudraVigilance-Datenbank der EMA verarbeitet — laut EMA-Jahresbericht 2025 ein leichter Anstieg gegenüber dem Vorjahr. Global ist das Volumen noch weitaus größer: In Indien und den Philippinen wurden 2023 zusammen über 2,4 Millionen ICSRs verarbeitet.

Für jedes Pharmaunternehmen mit Marktzulassung in der EU gilt: Schwerwiegende Verdachtsfälle unerwünschter Reaktionen müssen binnen 15 Kalendertagen an die zuständige Behörde (EMA/EudraVigilance oder nationales PV-Zentrum) gemeldet werden. Nichteinhalten der Fristen zieht regulatorische Maßnahmen nach sich, bis hin zu Bußgeldern und — im Extremfall — Marktzulassungsentzug.

Das strukturelle Problem dahinter: Das Meldeaufkommen steigt, das Fachpersonal wächst nicht proportional mit.

Laut DIA-Umfragen und Branchenberichten bindet die ICSR-Bearbeitung in einer typischen PV-Abteilung zwischen 60 und 80 Prozent der gesamten Arbeitszeit — für reine Erfassungs-, Kodierungs- und Dokumentationsschritte, nicht für die eigentliche medizinische Beurteilung. Besonders kritisch:

• Freitexterfassung aus heterogenen Quellen (E-Mail, Fax, Patientenportal, Literatur, Social Media): Kein gemeinsames Format, keine standardisierten Felder
• MedDRA-Kodierung: Ein versierter Case Processor braucht 20–45 Minuten allein für die Termsuche und Hierarchie-Navigation je Fall
• Narrative Writing: Der Freitext im ICSR muss regulatorisch konform, konsistent und vollständig sein — eine Aufgabe, die medizinisches Fachwissen und sprachliche Präzision erfordert
• E2B(R3)-Strukturierung: Seit der verpflichtenden Umstellung auf ISO ICSR / ICH E2B(R3) in der EU (2022) und dem für April 2026 anvisierten FDA-Pflichttermin steigen die technischen Anforderungen an Feldkomplexität und Datenqualität weiter

Hinzu kommt ein systemisches Problem: Die mediane Underreporting-Rate von ADRs liegt in Studien bei bis zu 94 Prozent — die meisten unerwünschten Ereignisse erreichen das PV-System nie, weil sie weder von Patienten noch von Ärzten gemeldet werden. Das bedeutet: Jede Meldung, die das System erreicht, hat hohen Wert — und muss zuverlässig verarbeitet werden.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Branchenerfahrungswerte aus PV-Plattform-Implementierungen; keine unabhängig publizierte Studie, aber konsistente Beobachtungen über mehrere Rollouts hinweg. Der Wert von 60–80 % Automatisierung bezieht sich auf nicht-schwerwiegende Spontanmeldungen mit vollständigen Mindestdaten.

Ein konkretes Beispiel aus der Praxis: AbbVie hat bei der Einführung von Veeva Vault Safety innerhalb von 15 Monaten rund 6 Millionen historische Cases migriert und danach mehr als 80 Prozent des Case-Volumens touchless verarbeitet — was der Erreichung von fünf bis acht Vollzeit-Stellen entsprach, die nicht aufgestockt werden mussten (Quelle: Veeva, „From Volume to Value”, 2024). Dabei handelt es sich um Vendor-Angaben, die nicht unabhängig auditiert wurden — aber sie spiegeln ein Muster wider, das sich in ähnlicher Dimension in anderen Enterprise-PV-Rollouts zeigt.

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) ADR-Case-Processing ist unter den verglichenen Pharma-Anwendungsfällen die zeitintensivste manuelle Aufgabe mit dem höchsten Anteil an standardisierbaren Teilschritten. Die 50–70 Prozent Zeitreduktion je Fall sind bei ausreichendem Volumen der deutlichste Produktivitätshebel in der gesamten PV-Abteilung. Kein anderer Anwendungsfall in der Kategorie bietet diese direkte Skalierung: Mehr Fälle bedeuten mehr Einsparung — ohne lineare Personalaufstockung.

Kosteneinsparung — mittel (3/5) Die Einsparungen sind real und messbar — Personalkosten je Case Processor liegen bei 60.000–100.000 Euro brutto pro Jahr, und mit KI-Unterstützung kann dieselbe Abteilung deutlich mehr Volumen abarbeiten. Gegengerechnet werden muss allerdings der erhebliche Einrichtungsaufwand: GxP-Validierung, Systemintegration, Schulung und laufende Change-Control-Prozesse summieren sich auf 40.000–120.000 Euro Einmalkosten, dazu Lizenzkosten im sechs- bis siebenstelligen Bereich bei Enterprise-Plattformen. Für kleinere Abteilungen ist der ROI erst ab einem bestimmten Fallvolumen positiv.

Schnelle Umsetzung — niedrig (2/5) Das ist der wichtigste Unterschied zu anderen Branchen: Weil der ICSR-Prozess unter GxP fällt, muss jedes KI-System, das in diesen Workflow eingreift, Computer System Validation (CSV) nach GAMP5 durchlaufen. Das dauert — auch im günstigen Fall — vier bis acht Monate bis zum validen Produktivbetrieb. Wer in sechs Wochen live sein will, scheitert nicht an der KI, sondern an der Regulatorik.

ROI-Sicherheit — hoch (4/5) Anders als bei indirekten Effizienz-Use-Cases lässt sich der Nutzen direkt messen: Cases pro FTE und Monat vor und nach Einführung, Bearbeitungszeit je Case-Typ, Anteil touchless verarbeiteter Fälle. Die regulatorische Compliance-Dimension fügt eine zweite ROI-Spur hinzu: Weniger Meldungen, die die Frist überschreiten — ein Risiko, das mit Bußgeldern und Reputationsschaden verbunden ist.

Skalierbarkeit — hoch (4/5) ADR-Volumina wachsen mit der Marktpräsenz eines Produkts, mit Post-Marketing Surveillance-Verpflichtungen und mit Lifecycle-Ereignissen wie PSUR-Zyklen. Ein KI-System skaliert dieses Volumen ohne proportionalen Personalaufwand — es braucht keine zehn Mitarbeitenden, wo vorher drei waren, sondern dieselben drei, die jetzt zehnmal so viele Fälle durchsetzen. Nicht höchste Skalierbarkeit (5/5), weil Quality-Check-Aktivitäten und Serious-Cases weiterhin mehr menschliches Urteil erfordern und die Plattformkosten nicht vollständig fixiert sind.

Richtwerte — stark abhängig von ICSR-Volumen, Produktportfolio und vorhandener PV-Infrastruktur.

Was das System konkret macht

KI im ADR-Processing arbeitet in vier Stufen — nicht als Blackbox, sondern als strukturierter Assistenzprozess, bei dem Menschen die Validierung behalten.

Schritt 1: Automatische Triage eingehender Meldungen

NLP-Modelle scannen eingehende Kommunikation — E-Mails, Formulare, Social-Media-Posts, Literaturabstract — nach den vier ICSR-Mindestkriterien: erkennbarer Patient, Verdachts-Arzneimittel, vermuteter Nebenwirkung, identifizierbarer Melder. Meldungen, die alle vier Kriterien erfüllen, werden automatisch priorisiert und als potenzielle ICSRs markiert. Meldungen, die kein Adverse Event enthalten (Produktanfragen, administrative E-Mails, Lob), werden aussortiert oder in andere Queues verschoben. Dieser Schritt allein spart 15–30 Minuten je eingehende Kommunikation — unabhängig davon, ob daraus ein ICSR wird.

Schritt 2: Extraktion und MedDRA-Kodierung

Aus dem Freitext extrahiert das Modell strukturiert: Patientendaten (Alter, Geschlecht, Gewicht, Vorerkrankungen), Produktinformationen (Batch, Dosis, Therapiedauer), beschriebene Ereignisse. Für jedes Ereignis schlägt es MedDRA Preferred Terms (PT) und Lowest Level Terms (LLT) vor — mit Konfidenzscoring. Der Case Processor sieht den Vorschlag, prüft und bestätigt oder korrigiert. Reale Implementierungen berichten, dass Reviewer weniger als drei Mal pro Session ein abweichendes Urteil von der KI hatten — und in jedem Fall bestätigten, dass die Zeitersparnis trotzdem über 50 Prozent lag (Applied Clinical Trials, 2024).

Schritt 3: Narrative Writing

Aus den extrahierten Daten generiert ein Generative KI-Modul einen ICSR-konformen Narrative-Entwurf. Der Text folgt der vorgeschriebenen Struktur (Suspect Drug, Adverse Event, Medical History, Action Taken, Outcome) und ist direkt in das Datenbankfeld des PV-Systems einbettbar. Der Case Processor liest, ergänzt medizinisches Urteil und gibt frei. Typische Zeitersparnis bei der Narrative: 20–40 Minuten je schwerwiegendem Case.

Schritt 4: E2B(R3)-Strukturvalidierung und Signaldetektion

Das System prüft automatisch die Vollständigkeit und formale Korrektheit der ausgefüllten Felder nach ICH E2B(R3)-Standard — fehlende Pflichtfelder, Inkonsistenzen zwischen Altersangabe und Wertungscode, ungültige Kodierungen. Separate Signal-Detection-Module analysieren kumulative Case-Patterns (Disproportionalitätsanalysen, PRR/ROR-Statistiken) und liefern Hinweise auf neu entstehende Sicherheitssignale — eine Funktion, die in Standalone-PV-Datenbanken traditionell manuell und quartalsweise passiert.

Konkrete Werkzeuge — was wann passt

Drei Ebenen, je nach Unternehmensgröße, Validierungsbereitschaft und Budget:

Veeva Vault Safety — für mittelgroße bis große Pharmaunternehmen Das seit 2022 vollständig cloudbasierte Safety-Modul der Veeva-Plattform ist heute in vielen großen Pharmaorganisationen der Standard. Es deckt ICSR-Intake, MedDRA-Kodierung, Narrative, E2B(R3)-Submission und Signal Management ab. GxP-validiert, FDA 21 CFR Part 11 und EMA Annex 11 konform. Seit Dezember 2025 bietet Veeva AI-Agenten für Dokumentenklassifikation und Case-Processing-Unterstützung. Realistisches Einrichtungsbudget: 6–18 Monate Implementierung, Lizenz ab ca. 25.000 EUR/Jahr für Entry-Module, Enterprise-Setups im sechs- bis siebenstelligen Bereich. Passt, wenn: Ihr bereits Vault nutzt oder eine Suite-Konsolidierung plant.

ArisGlobal LifeSphere Safety — PV-Tiefe mit agentischer KI Historisch der stärkste Spezialist für Drug Safety — direkter Wettbewerber zu Oracle Argus. Die NavaX-Engine automatisiert MedDRA-Coding, Duplikatserkennung, Literaturrecherche und Signal Detection mit agentischer KI. Laut Hersteller bis zu 50 Prozent Effizienzgewinn auf zentralen PV-Workflows — Branchenberichte aus Pilotprojekten bestätigen 30–40 Prozent Realwert. Implementierung dauert typisch 4–9 Monate, Lizenz im sechs- bis siebenstelligen Bereich. Passt, wenn: Ihr hohes ICSR-Volumen habt (ab ca. 2.000 Fälle/Jahr) und eine PV-Speziallösung gegenüber einer Suite bevorzugt.

Oracle Argus (kein Tool-Stub verfügbar, Erwähnung in Prosa) — der Legacy-Marktführer mit starker On-Premise-Tradition. Technologisch älter, aber in vielen Großkonzernen tief verankert. Oracle hat KI-Funktionen hinzugefügt, die jedoch weniger integriert sind als bei ArisGlobal oder Veeva. Sinnvoll, wenn ihr bereits Oracle Argus einsetzt und eine In-Place-Erweiterung sucht, statt zu migrieren.

Erster Schritt ohne vollständiges PV-System — für kleinere Strukturen: Wer noch keine Enterprise-PV-Plattform betreibt, kann mit KI-gestützter Narrative-Unterstützung starten: Ein validierter Workflow, in dem Claude oder ein vergleichbares LLM den Narrativ-Entwurf auf Basis eines strukturierten Templates erstellt, das der Case Processor dann in die bestehende PV-Datenbank einpflegt. Dieser Ansatz ist nicht GxP-validiert und damit nicht regulatory-compliant als Primärsystem — aber er senkt den manuellen Aufwand für den Schreibprozess, solange die Endergebnisse vollständig menschlich geprüft und verantwortet werden. Für Teams mit unter 500 Fällen/Jahr kann das ein realistischer Einstieg sein, bevor eine Full-Platform-Investition gerechtfertigt ist.

Zusammenfassung: Wann welcher Ansatz

• Hohes ICSR-Volumen, Suite-Konsolidierung, bestehender Veeva-Footprint → Veeva Vault Safety
• Hohes ICSR-Volumen, PV-Spezialist gesucht, stärker KI-fokussiert → ArisGlobal LifeSphere
• Oracle Argus bereits im Einsatz → Oracle-native KI-Erweiterungen prüfen
• Niedriges Volumen, erster Schritt → Narrativ-Drafting mit validierbarem LLM-Workflow, manuell geprüft

GxP-Validierungspflicht und regulatorische Verantwortung

Das ist der entscheidende Unterschied zu fast jedem anderen KI-Use-Case auf dieser Website: Ein System, das in den ICSR-Prozess eingreift, fällt unter GxP und muss entsprechend validiert sein.

Die EMA hat das in ihrem Reflection Paper „Use of Artificial Intelligence in the Lifecycle of Medicines” (September 2024) explizit klargestellt: KI-Anwendungen, die in Pharmacovigilance-Workflows eingesetzt werden, müssen im Pharmacovigilance System Master File (PSMF) beschrieben sein. Das PSMF ist Gegenstand von EMA-Inspektionen — eine nicht dokumentierte KI-Komponente im ICSR-Prozess ist damit ein Inspektionsbefund.

Was das konkret bedeutet:

• Jedes KI-Tool, das automatisch MedDRA-Terme vorschlägt, Felder befüllt oder Narrative generiert, muss nach GAMP5 (Computer System Validation) qualifiziert werden: User Requirements Specification (URS), Installation Qualification (IQ), Operational Qualification (OQ), Performance Qualification (PQ)
• Audit Trail ist Pflicht: Wer hat welchen KI-Vorschlag wann akzeptiert oder abgelehnt? Das System muss das nachvollziehbar dokumentieren
• Change Control: Jede Änderung am KI-Modell (Update, Retraining, Parameteranpassung) ist eine geplante Änderung und muss durch den Change-Control-Prozess
• Der QPPV haftet persönlich: GVP Modul VI und die EU-Arzneimittelgesetzgebung machen klar — die Verantwortung für die Meldung liegt bei der Qualified Person for Pharmacovigilance, nicht beim Softwareanbieter. KI kann Arbeit vorbereiten; entscheiden und freigeben muss ein qualifizierter Mensch

Die häufigste Falle: Teams kaufen eine KI-Lösung, die im Marketing als “GxP-validiert” beschrieben wird — und vergessen, dass GxP-Validation keine Produkteigenschaft ist, sondern ein Prozess, den sie selbst durchführen müssen (Vendor-Validierungsdokumentation ist nur die Basis, nicht das Ergebnis). Der Vendor liefert die IQ-Dokumentation; die OQ und PQ führt ihr selbst durch, angepasst an eure spezifische Systemkonfiguration und Use Cases.

Wer ein nicht-validiertes System für die ICSR-Erstellung verwendet und dann einen Fall falsch klassifiziert oder eine Frist überschreitet, hat das Problem nicht gelöst — er hat es dokumentiert.

Datenschutz und Datenhaltung

ICSRs enthalten die sensibelsten personenbezogenen Daten, die ein Pharmaunternehmen verarbeitet: Krankheitsdiagnosen, Therapieverläufe, Nebenwirkungsbilder — also besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO. Selbst wenn Patient Initials statt Vollnamen verwendet werden, ist Pseudonymisierung nach ICSR-Standard nicht dasselbe wie Anonymisierung im DSGVO-Sinn: Bei seltenen Erkrankungen oder spezifischen Therapiekombinationen bleibt Reidentifizierung möglich.

Das bedeutet für KI im ICSR-Prozess:

• Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist bei automatisierter Verarbeitung besonderer Datenkategorien in der Regel verpflichtend — vor dem Produktivbetrieb, nicht danach
• Auftragsverarbeitungsvertrag (AVV) mit jedem Anbieter, der ICSR-Daten verarbeitet. Für Enterprise-PV-Plattformen (Veeva, ArisGlobal) ist das Standard — aber frag explizit nach der Subprozessor-Liste und der Hosting-Region
• EU-Datenresidenz: Bei Veeva Vault Safety ist EU-Hosting verfügbar und für deutsche MAHs zu bevorzugen. ArisGlobal hat EU-Rechenzentren, die aber explizit im Vertrag verankert sein müssen — nicht der Default
• Generische LLM-APIs (OpenAI, Claude.ai Consumer) dürfen ohne gesonderte DSGVO-Vereinbarung keine echten ICSR-Daten verarbeiten. Wer Narrativ-Drafting über einen Consumer-LLM betreibt und echte Patienteninitials, Altersangaben oder Diagnosen einfügt, hat ein DSGVO-Problem. Lösung: Entweder ein EU-gehostetes Enterprise-Modell (z.B. Claude über AWS Bedrock Frankfurt, Azure OpenAI EU-Region) — oder konsequente Pseudonymisierung, bevor Daten das System verlassen

Im Gegensatz zu anderen Branchen ist hier der regulatorische Druck bidirektional: EMA/GVP auf der einen Seite, DSGVO auf der anderen. Beide Anforderungen müssen vor Go-Live vollständig adressiert sein.

Was es kostet — realistisch gerechnet

Die Kosten variieren dramatisch je nach Ansatz. Drei realistische Szenarien:

Szenario A: Enterprise-Plattform (Veeva Vault Safety oder ArisGlobal)

• Einrichtung inkl. GxP-Validierung, Systemintegration, Training: 80.000–200.000 EUR einmalig (stark abhängig von Migrationsumfang und Komplexität der Quelldaten)
• Jahreslizenz: ab 100.000 EUR/Jahr, Enterprise-Setups 300.000–500.000 EUR+
• Break-even: Ab ca. 2.000–3.000 ICSRs/Jahr bei voller Nutzung der Automatisierungsfunktionen; darunter ist der ROI rechnerisch negativ
• Nutzen: AbbVie hat bei >6 Mio. historischen Cases und hohem laufenden Volumen 5–8 FTE-Äquivalente eingespart — bei Personalkosten von 80.000–100.000 EUR je Senior Case Processor sind das 400.000–800.000 EUR/Jahr Einsparung auf Brutto-Basis

Szenario B: PV-Datenbank-Add-on (NLP-Modul in bestehender Datenbank)

• Einrichtung und Validierung des Add-on-Moduls: 30.000–60.000 EUR einmalig
• Modulkosten: 20.000–60.000 EUR/Jahr
• Typischer Anwendungsfall: Bestehende Oracle Argus-Installation, bei der ein NLP-Coding-Modul hinzugekauft wird
• Zeitersparnis: 30–50 % beim MedDRA-Coding, weniger Effekt auf Intake und Narrative

Szenario C: Assistiertes Narrativ-Drafting (LLM, nicht GxP-validiert)

• Setup: < 5.000 EUR (Prompt-Entwicklung, interne Prozessvalidierung)
• Laufende Kosten: < 500 EUR/Monat für API-Zugang
• Nutzen: 20–40 Minuten weniger Schreibarbeit je Narrative; Prozess bleibt vollständig human-driven
• Einschränkung: Ausschließlich für Unternehmen geeignet, die das LLM-Ergebnis vollständig menschlich prüfen, keine echten Patientendaten an Consumer-APIs senden, und diesen Ansatz im PSMF als manuell unterstützten Prozess dokumentieren — nicht als KI-gestützten automatisierten Workflow

Was du gegenstellen kannst: Ein Case Processor mit vollständigem ICSR-Workload verarbeitet realistisch 100–200 Non-serious Cases/Monat und 30–60 Serious Cases/Monat. Bei Bruttopersonalkosten von 80.000–100.000 EUR/Jahr und einer Zeitersparnis von 50 Prozent entspricht das einer jährlichen Entlastung von 40.000–50.000 EUR je Vollzeitstelle — ohne dass die Stelle wegfällt, aber mit der Kapazität, das doppelte Volumen zu stemmen.

Drei typische Einstiegsfehler

1. Das KI-System „ist validiert” — die Validierung aber trotzdem fehlt. Viele Anbieter behaupten, ihre Plattform sei „GxP-validiert” — und meinen damit, dass die Herstellerdokumentation (IQ-Pakete, technische Spezifikationen) vorhanden ist. Das ist die notwendige Basis, nicht das Ergebnis. Die Operational Qualification (OQ) und Performance Qualification (PQ) müssen ihr selbst durchführen: mit euren Use Cases, euren Daten, eurer Systemkonfiguration. Wer diesen Schritt überspringt oder delegiert, hat beim nächsten EMA-Audit ein dokumentiertes Problem.

2. Alle Falltypen von Anfang an automatisieren. Der Reflex: Wenn die KI gut ist, soll sie alle Cases bearbeiten — auch Pediatric Cases, schwerwiegende Ereignisse, Cases mit Fehlgeburt oder Tod. Das führt schnell zu Konflikten zwischen Automatisierungsrate und medizinischem Urteil. Realistisch ist: Non-serious Cases mit vollständigen Mindestdaten eignen sich für Automatisierungsgrade von 70–80 Prozent. Schwerwiegende Cases, seltene Ereignisse, pädiatrische Fälle und Cases mit möglicher Kausalität brauchen mehr menschliche Aufmerksamkeit — und das System muss das erkennen und entsprechend priorisieren, nicht nivellieren.

3. Kein Review der KI-Kodierungsvorschläge nach dem ersten Jahr. Der gefährlichste Fehler passiert still. In den ersten sechs Monaten wird geprüft und angepasst. Dann stabilisiert sich die Akzeptanzrate, Review-Prozesse werden oberflächlicher — bis ein MedDRA-Versions-Update neue Terme einführt oder ein Produktionsstandort wechselt und das Modell plötzlich auf Termini trifft, die es nicht ausreichend kennt. Pharmaunternehmen, die NLP-Coding ohne regelmäßiges Model-Performance-Monitoring betreiben, haben nach 12–18 Monaten oft eine Drift, die sie erst beim nächsten Audit entdecken. Lösung: Monatliche Stichproben (min. 5 Prozent der automatisch kodierten Cases) durch einen erfahrenen Case Processor, dokumentiert als Quality-Check im QMS.

Was mit der Einführung wirklich passiert — und was nicht

Widerstand des PV-Teams: Case Processors, die seit Jahren an manueller Kodierung arbeiten, haben Erfahrung im System — und berechtigte Zweifel, ob die KI ihre medizinische Expertise ersetzen kann. Das Argument, das wirklich funktioniert, ist kein Effizienz-Pitch: “KI nimmt euch die Tipparbeit ab, damit ihr euch auf medizinische Beurteilung konzentrieren könnt.” Das ist kein Marketing — es ist die Wahrheit. Wer MedDRA-Browsing und E2B-Feldausfüllung automatisiert, gewinnt Zeit für Signaldetektion, Medikationsgeschichte und klinische Kausalitätsbewertung — die Aufgaben, für die medizinisches Fachwissen wirklich gebraucht wird.

Was wirklich unterschätzt wird: Die Transition-Zeit zwischen “Pilot” und “valider Produktivbetrieb” ist länger als geplant. Zwischen dem ersten Live-Test und dem GxP-validierten Go-Live liegen oft drei bis sechs Monate zusätzlich — für Abnahmetests, Abweichungsdokumentation, Schulungen, Change-Control-Durchläufe. Wer das nicht in der Projektplanung hat, startet mit gebundener Kapazität in zwei Betrieben gleichzeitig: dem alten manuellen und dem neuen zu validierenden.

Was konkret hilft:

• Frühzeitig einen Senior Case Processor oder den QPPV ins Projektteam einbinden — nicht nur als Reviewer, sondern als Anforderungsdefinierer
• Abnahmekriterien für die OQ/PQ vor dem Piloten festlegen, nicht währenddessen
• Einen 90-Tage-Evaluationszeitraum mit klaren Metriken kommunizieren (Durchsatz, Fehlerrate, MedDRA-Diskordanzrate)
• Beim ersten Audit nach Go-Live vorbereitet sein: Der Inspektor fragt nach der PSMF-Dokumentation des KI-Systems — dieser Teil der Vorbereitung passiert parallel zur technischen Einführung, nicht danach

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„KI kann das medizinische Urteil nicht ersetzen — das ist zu riskant.” Stimmt vollständig. Aber das ist auch nicht das Ziel. Kein valides PV-System macht Meldungen ohne menschliche Freigabe. Die Frage ist nicht: “Darf KI entscheiden?” — sondern: “Darf KI vorarbeiten?” Das darf sie, und das tut sie bereits bei AbbVie, Roche, Boehringer Ingelheim. Die Entscheidung, ob ein Fall als Serious einzustufen ist, ob Kausalität vorliegt und ob die Meldung korrekt ist, bleibt beim Case Processor und beim QPPV. Die KI nimmt die Feldauffüllung, die MedDRA-Suche und die Narrativ-Grundstruktur weg — nicht die Verantwortung.

„Wir haben zu wenige Fälle, um das zu rechtfertigen.” Das ist oft das ehrlichste Argument. Bei unter 500 ICSRs/Jahr kann der ROI einer Enterprise-Plattform rechnerisch nicht positiv sein. Die Antwort ist nicht, ein Vollsystem einzuführen, sondern zu prüfen, welche Teilschritte schon mit einfacheren Mitteln entlastet werden können — assistiertes Narrative Writing, bessere Triage-Templates. Erst wenn das Volumen wächst oder ein neues Produkt den Aufwand sprunghaft erhöht, ist die Vollplattform gerechtfertigt.

„Die Validierung dauert zu lange.” Das stimmt — und das ist keine Ausrede, den Prozess zu umgehen. Es ist ein Argument, früher zu beginnen. Wer erst dann mit der Systemauswahl startet, wenn der Druck akut ist, hat den Zug bereits verpasst. Eine GxP-Validierung braucht Zeit, und daran ändert auch keine Vendor-Aussage etwas. Der Hebel ist Planung: Wenn ihr 2026 live sein wollt, müsst ihr 2025 mit dem URS beginnen.

Woran du merkst, dass das zu dir passt

• Dein Team verarbeitet mehr als 500 ICSRs pro Jahr, davon ein erheblicher Anteil Spontanmeldungen aus Freitextquellen
• MedDRA-Kodierung frisst messbar mehr Zeit als medizinische Beurteilung — ein Zeichen, dass die standardisierbare Arbeitsschicht dominiert
• Ihr habt regelmäßige Fristen-Engpässe: Cases, die nah an der 15-Tage-Deadline ankommen, obwohl das Team voll besetzt ist
• Euer ICSR-Volumen wächst — durch neue Produkte, neue Märkte, erweiterte Post-Marketing-Surveillance-Verpflichtungen
• Ihr habt eine etablierte PV-Infrastruktur: validierten QPPV, funktionierendes PSMF, GxP-Prozesse im QMS — die Basis, auf der eine KI-Erweiterung aufsetzen kann

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter 500 ICSRs/Jahr. Die Fixkosten für GxP-Validierung (40.000–120.000 EUR einmalig), laufende Lizenzkosten und Systempflege amortisieren sich bei niedrigem Volumen nicht. Für kleine MAHs mit wenigen Produkten und überschaubarem Meldeaufkommen ist eine PV-Serviceprovider-Lösung (CRO-Outsourcing) wirtschaftlich sinnvoller als eine eigene KI-Plattform.

2. Kein valides PSMF und kein QPPV im Haus. KI-Einführung setzt voraus, dass der regulatorische Rahmen bereits steht. Ein Unternehmen, das noch dabei ist, seine GxP-Basisinfrastruktur aufzubauen, sollte das zuerst abschließen. Eine KI, die einen nicht regulatorisch verankerten Prozess beschleunigt, ist ein Compliance-Risiko, keine Verbesserung.

3. Keine strukturierten Quelldaten. Wenn eingehende Meldungen ausschließlich als Papierformulare, nicht-durchsuchbare Scans oder ad-hoc E-Mails ohne definierte Eingabestruktur kommen — und es keinen Prozess gibt, das zu ändern —, hat die KI keinen definierten Eingangspunkt. Automatisierung beginnt beim Intake: Wer keine maschinenlesbare Eingangskommunikation hat, muss diesen Schritt zuerst digitalisieren.

Das kannst du heute noch tun

Auch ohne Enterprise-Plattform kannst du sofort testen, wie viel KI im Narrativ-Prozess abnimmt. Öffne Claude (Pro-Plan, über aws.amazon.com/bedrock für DSGVO-konformen Zugriff) und verwende diesen Prompt mit einem realen — aber vollständig pseudonymisierten — Case:

Hinweis: Dieser Workflow ist ein Einstiegspunkt, keine vollständige Lösung. Für den Produktivbetrieb gilt: Keine echten Patientendaten an nicht-validierte Consumer-APIs senden, den Prozess im PSMF als manuell unterstützten Workflow dokumentieren, und jeden Entwurf vollständig durch einen qualifizierten Case Processor prüfen lassen.

Quellen & Methodik

• EMA EudraVigilance Annual Report 2025: Rund 1,76 Millionen ICSRs in 2024 verwaltet; EMA, 2025 Annual Report on EudraVigilance. Vorjahresvergleich: 1,9 Mio. in 2023 (Rückgang durch weniger COVID-19-Meldungen).
• AbbVie/Veeva Vault Safety Case: >80 % Automatisierung des Case-Volumens, 5–8 FTE-Äquivalente eingespart. Veeva Systems, „From Volume to Value” (2024). Vendor-Angabe, nicht unabhängig auditiert.
• MedDRA-Coding mit KI — Zeitersparnis: Applied Clinical Trials Online, „Real-World Use of an Artificial Intelligence-Supported Solution for Coding of Adverse Events in Clinical Trials” (2024): Jeder Teilnehmende schätzte > 50 % Zeitersparnis beim manuellen Coding; Diskordanzrate unter drei Ausnahmen pro Session.
• AI-Signaldetektion — Risikohinweis: Frontiers in Drug Safety and Regulation, „Rethinking drug safety signal detection and causality assessment in the age of AI: the risks of incomplete data and biased insights” (2025): Fehlende Eingangsdaten können zu False Negatives oder Spurious Signals führen — systematische Validierung ist Pflicht.
• EMA Reflection Paper AI: EMA, „Reflection Paper on the use of Artificial Intelligence in the lifecycle of medicines” (September 2024). Kernaussagen: KI in GVP-Workflows muss im PSMF dokumentiert sein; menschlicher Oversight ist regulatorisch verpflichtend.
• E2B(R3)-Pflicht EU: ISO ICSR / ICH E2B(R3) für EudraVigilance seit 30. Juni 2022 verpflichtend. FDA-Pflichttermin: 1. April 2026.
• ICSR-Underreporting: Median-Rate von 94 % aus Metaanalysen; Referenz: Hazell & Shakir, „Under-Reporting of Adverse Drug Reactions” (2006); bestätigt durch aktuelle Systemmodellierungen.
• Kostenangaben PV-Plattformen: Erfahrungswerte aus Branchenberichten, Implementierungsprojekten und eigenen Recherchen (Stand Mai 2026). Veeva und ArisGlobal nennen keine öffentlichen Listenpreise — die genannten Spannweiten spiegeln verbreitete Benchmark-Erfahrungen wider.

Willst du prüfen, ob und wie KI euren ICSR-Prozess entlasten kann — und wie das regulatorisch korrekt abgesichert wird? Meld dich für ein kurzes Gespräch. Wir helfen euch, die richtige Einstiegsstufe für euer Volumen und eure Infrastruktur zu finden.