Validierung der Safety-Datenbank in der Pharmakovigilanz: Was wirklich erforderlich ist, um ein Audit zu bestehen

Wenn ich die eine Frage nennen müsste, bei der viele PV-Teams während einer Inspektion nervös werden, dann wäre es diese:

„Können Sie mir den Nachweis zeigen, dass Ihre Safety-Datenbank für den vorgesehenen Verwendungszweck validiert ist, dass die Daten integer sind und dass Änderungen unter Kontrolle stehen?“

Der kritische Punkt ist nicht, „eine bekannte Software“ zu haben. Entscheidend ist, nachzuweisen, dass das System korrekte ICSRs erzeugt, die Datenintegrität aufrechterhält und nachvollziehbar macht, wer was wann getan hat – insbesondere dann, wenn das Fallvolumen steigt und der Zeitdruck zunimmt. Im Master Guide wird die Safety-Datenbank als technologisches Herzstück der Pharmakovigilanz beschrieben, und es wird ausdrücklich hervorgehoben, wie entscheidend es ist, dass sie validiert und sicher ist.

Warum die Safety-Datenbank GxP-kritisch ist (auch wenn Sie sie nicht „GxP“ nennen)

In der Pharmakovigilanz ist die Datenbank kein einfaches Archiv: Sie ist ein System, das regulatorische Prozesse mit direktem Einfluss auf Patient:innen und Compliance unterstützen muss. In der Praxis muss sie:

• die End-to-End-Auditierbarkeit sicherstellen (Dateneingabe → Medical Review → Submission),
• strukturierte Outputs (E2B(R3)) ohne Mapping- oder Schnittstellenfehler erzeugen,
• MedDRA-Versionierung und Recoding verwalten, ohne die Rückverfolgbarkeit zu verlieren,
• die Vertraulichkeit schützen (rollenbasierte Zugriffe) und Business Continuity gewährleisten (Backup/Restore).

Der Master Guide weist klar darauf hin, dass die QPPV über den Status des Systems informiert sein muss und dass die Datenbank Datenintegrität und Datensicherheit gewährleisten muss.

Der gefährliche Mythos (contrarian insight): „Der Vendor hat schon validiert, also sind wir abgesichert“

Das ist eine veraltete und riskante Praxis.

Warum es ein Mythos ist:
Die Validierung des Anbieters deckt das Standardprodukt ab. Das Audit – und der gesunde GxP-Menschenverstand – verlangt den Nachweis für Ihren intended use: Konfigurationen, Workflows, Rollen, Schnittstellen, Reporting und vor allem dafür, wie das System im Unternehmen tatsächlich genutzt wird.

Typisches Audit-Risiko: eine „vendor-validierte“ Datenbank, bei der jedoch:

• Konfigurationen „on the fly“ geändert wurden, ohne dokumentierte Tests,
• Benutzerprofile zu weitreichend sind (keine Funktionstrennung),
• ein Audit Trail vorhanden ist, aber nie überprüft wird,
• Patches/Upgrades ohne Regressionstests eingespielt wurden.

Der Ansatz, der in der Inspektion trägt: risikobasierte CSV + Data Integrity (ALCOA+)

Wenn wir in der PV über Computer System Validation (CSV) sprechen, ist der am besten vertretbare Ansatz:

• den intended use definieren (was das System in Ihrem PV-System leisten muss),
• eine risikobasierte Validierung anwenden (nicht „alles testen“, sondern das testen, was Compliance und Patient:innen beeinflusst),
• Data Integrity anhand der ALCOA+-Prinzipien nachweisen.

LSI-Begriffe (neu im Vergleich zu früheren Artikeln): ALCOA+, audit trail review, Computer System Validation (CSV), URS, IQ/OQ/PQ, GAMP 5, Annex 11, 21 CFR Part 11, RBAC, Validation Traceability Matrix.

„Mindest“-Deliverables, die ein Auditor erwartet (und die Sie in 2 Minuten finden sollten)

Die 7 technischen Punkte, die fast immer zu Findings führen

1) Audit Trail: vorhanden, aber nicht genutzt

Ein Audit Trail bringt nichts, wenn:

• niemand weiß, wie man ihn extrahiert,
• es keine SOP für die Audit Trail Review gibt,
• keine Kriterien existieren, um festzulegen, was „auffällig“ ist.

Praxis, die trägt: eine periodische, risikobasierte Überprüfung (z. B. monatlich), fokussiert auf:

• Änderungen bei seriousness/expectedness,
• Änderungen bei suspected/concomitant products,
• Löschungen/Merges,
• Overrides automatischer Regeln.

2) Nicht profilierte Zugriffe und „Super-User-Kultur“

Im Audit ist das häufigste Muster:

• zu viele Benutzer:innen mit erhöhten Rechten,
• gemeinsam genutzte Konten,
• keine regelmäßige Überprüfung der Zugriffsrechte.

Operativer Vorschlag: eine quartalsweise User Access Review mit unterschriebenem Nachweis (PV + QA/IT) vorsehen.

3) Zeitzonen- und Datumslogik (massiv unterschätzt)

Auditoren lieben „stille“ Bugs:

• Empfangsdatum vs. Awareness-Datum,
• Zeitzonen von Affiliates → falsche Fristberechnung,
• Pflichtfelder, die in Wirklichkeit nicht verpflichtend sind.

Reale Auswirkung: verspätetes Reporting „durch das System“, nicht „durch den Menschen“.

4) Schnittstellen und E2B(R3)-Mapping

Wenn Sie Gateways zu EudraVigilance oder Integrationen haben (MI/CRM/E-Mail-Intake), fragt der Auditor häufig nach:

• Mapping-Nachweisen,
• Ergebnissen des Reconcilings,
• Failure-Handling (Retry, Queue, Incident).

5) Datenmigrationen und Rekonstruktion der Historie

Versionswechsel oder Vendorwechsel? Ohne eine Data-Migration-Strategie mit Vollständigkeitskontrollen enden Sie mit:

• Fällen ohne Follow-up-Historie,
• gekürzten Narratives,
• nicht verlinkten Anhängen.

6) MedDRA: Versionsmanagement und kontrolliertes Recoding

Das ist nicht „nur ein medizinisches“ Thema. Es ist Data Governance:

• Wann wechseln Sie die MedDRA-Version?
• Wie steuern Sie Recoding und die Auswirkungen auf Aggregate/Reports?

7) Backup & Disaster Recovery: deklariert, aber nicht getestet

Hier will der Auditor einen konkreten Nachweis: dokumentierter Restore-Test und idealerweise ein periodischer Disaster-Recovery-Test.

Mini-Checkliste „30 Sekunden“ (für QPPV und für QA/IT)

Wenn heute eine Inspektionsankündigung eingehen würde – könnten Sie sofort vorlegen:

• genehmigte URS + Rückverfolgbarkeitsmatrix,
• die letzten Change-Control-Reports und Regressionstests,
• Nachweis der Audit Trail Review,
• Nachweis der Access Review (RBAC),
• Report des letzten Backup-/Restore-Tests,
• Incident-Log und Abweichungen zum PV-System,
• Training Records der Schlüsselanwender:innen (PV/IT/QA).

Merkkasten

Validierung bedeutet nicht, „keine Probleme zu haben“. Validierung bedeutet, ein System zu haben, das:

• Fehler erkennt,
• sie nachverfolgt,
• sie über Change Control korrigiert,
• nachweist, dass die Daten zuverlässig bleiben.

Fazit (und warum es sich lohnt, es richtig zu machen)

Eine gut durchgeführte CSV in der PV ist keine Bürokratie: Sie ist das, was Sie vor systemischen Late Reportings, fehlerhaften E2B-Übermittlungen und vor allem vor kritischen Findings schützt, die sich später in teure und dringende CAPAs verwandeln.