Veeva Vault Safety validieren: Konfiguration, Fallverbindungen und Releases prüfen

1. Veeva Safety und Ihren konkreten PV-Einsatz abgrenzen

Die aktuelle Herstellerbezeichnung lautet Veeva Safety. Der weiterhin verbreitete Suchbegriff Veeva Vault Safety benennt dieselbe Produktlinie auf der Vault-Plattform. Das Produktblatt vom April 2026 trennt die ICSR-Fallbearbeitung von SafetyDocs, Safety Workbench, Safety Signal und AI for Safety. Aus einer gemeinsamen Plattform folgt nicht, dass jede Anwendung zu Ihrem Vertrag oder Betriebsumfang gehört.

Dieser Leitfaden behandelt die Pharmakovigilanz für zugelassene Humanarzneimittel in der EU. Klinische Studien, Medizinprodukte und weitere Märkte benötigen gesonderte Anforderungen. Auch wenn die Produktfamilie mehrere Bereiche unterstützt, darf ein für einen Bereich gültiger Prüfansatz nicht ungeprüft auf alle übrigen übertragen werden.

Die EMA weist im Oktober 2026 auf aktuelle Änderungen der PV-Durchführungsverordnung und auf die Berücksichtigung neuer ICH-Leitlinien hin. Halten Sie daher neben dem Softwarestand auch die zugrunde gelegte fachliche Regelbasis fest. Eine Case Validation innerhalb der Anwendung prüft einen Fall; sie ist nicht gleichbedeutend mit dem Nachweis der Eignung Ihres gesamten computergestützten Prozesses.

Quellen: [1] [8] [12] [9]

2. Eine prüfbare Karte des tatsächlichen Vault-Umfangs erstellen

Erfassen Sie die produktive Umgebung und die verwendete Testumgebung getrennt. Welche Anwendungen sind lizenziert, welche Funktionen aktiviert, welche Konfigurationen kundenspezifisch? Eine allgemeine Beschreibung der Safety Suite beantwortet diese Fragen nicht. Für einen reproduzierbaren Test benötigen Sie außerdem die relevanten Rollen und Ausgangsdaten.

Die folgende eigene Planungshilfe grenzt den Umfang anhand konkreter Fragen ab. Ergänzen Sie je Zeile den Systemverantwortlichen, den Konfigurationsbeleg und die betroffenen Prozesse. Sie müssen dafür nicht sämtliche Funktionen der Plattform dokumentieren: Entscheidend sind die eingesetzten und für Ihre Nutzung relevanten Bestandteile einschließlich ihrer Abhängigkeiten.

Quellen: [1] [5] [2] [9]

3. Einen strukturierten Eingang bis zum richtigen Fall verfolgen

Veeva beschreibt für 26R2 konfigurierbare Web Intake Forms, deren eingereichte Angaben als Inbox Items zur Bearbeitung gelangen. Die Einrichtungshilfe nennt eine aktive Safety-Form-Verbindung, einen dafür vorgesehenen Benutzer und passende Berechtigungen. Eine verfügbare Funktion ist somit noch kein vollständig eingerichteter und geprüfter Eingangskanal.

Prüfen Sie einen genutzten Kanal vom sichtbaren Formular bis zum Datensatz, den ein Fallbearbeiter tatsächlich sieht. Stimmen Bezeichnungen, Auswahlwerte und eingereichte Inhalte überein? Bleibt eine unvollständige Angabe als solche erkennbar? Bei mehreren Sprachen muss insbesondere die Bedeutung des Feldes stimmen; eine lesbare Oberfläche allein reicht nicht.

Für eigene Prüfdaten legen Sie vorab fest, wie ein bekannter Fall, ein neuer Eingang und eine nicht eindeutig zuordenbare Information behandelt werden sollen. Die Annahme durch ein Webformular bedeutet nicht automatisch, dass ein fachlich gültiger und abschließend bewerteter ICSR entstanden ist. Eine ausdrückliche Zuordnungsentscheidung muss dort nachvollziehbar sein, wo sie Ihr Prozess benötigt.

Quellen: [7] [10] [13]

4. Datenverbindungen anhand ihrer fachlichen Bedeutung prüfen

Die Releaseunterlagen 26R2 beschreiben für die Quality-Safety Connection zusätzliche Rückmeldungen zum Fortschritt übergebener Datensätze. Dabei wird unter anderem erkennbar, ob ein aus einer QMS-Beschwerde entstandenes Inbox Item zu einem Safety Case weiterbearbeitet wurde. Diese Statusinformation beschreibt einen konkreten Übergang zwischen Anwendungen.

Für Ihren Prozess ist zu klären, was die empfangende Seite daraus ableiten darf. Die Meldung, dass ein Case entstanden ist, ist keine pauschale Bestätigung abgeschlossener medizinischer Bewertung. Ebenso ist die Bearbeitung einer Qualitätsbeschwerde nicht automatisch der Abschluss des PV-Falls. Die Verantwortung für beide Entscheidungen kann zusammenarbeiten, muss aber inhaltlich erkennbar bleiben.

Prüfen Sie bei genutzter Verbindung die ursprüngliche Kennung, den Zielbezug und die zurückgemeldete Bedeutung. Ergänzen Sie einen Fehlerfall: Die Quelle wurde gespeichert, die Weitergabe ist aber noch nicht abgeschlossen. Das Team muss diesen Zustand von einer bewussten Nichtübernahme unterscheiden können. Welche technische Wiederholung oder fachliche Klärung folgt, legen Sie anhand Ihrer tatsächlichen Verbindung fest.

Quellen: [2] [10]

5. Lokalisierte Fälle gezielt aktualisieren und abgleichen

Die offizielle Hilfe zu Local Case Resync erläutert eine ab 26R2 konfigurierbare Aktualisierung vorhandener fremdsprachiger beziehungsweise ausländischer Localized Cases mit Informationen aus dem globalen Fall. Die Aktion kann passend zum Prozess als Benutzer-, Eintritts- oder Workflowaktion eingerichtet werden. Sie ist daher anhand Ihrer aktivierten Konfiguration zu beurteilen.

Die Anwenderhilfe nennt eine entscheidende Grenze: Die Aktion aktualisiert bestehende lokale Fälle, legt aber keine neuen Localized Cases an. Außerdem beschreibt sie das Übernehmen neuer und geänderter Datensätze sowie das Entfernen bestimmter nicht mehr im globalen Fall vorhandener Datensätze und Felder. Prüfen Sie deshalb Hinzufügen, Ändern und Entfernen ausdrücklich getrennt.

Beschreiben Sie vor einem Test, welche Inhalte global geführt werden und welche lokale Bearbeitung benötigen. Kontrollieren Sie nicht nur, ob der lokale Datensatz erreichbar ist, sondern ob der benötigte Inhalt nach der Aktion richtig vorliegt. Für lokale Textregeln, Übersetzungen und bereits erzeugte Berichte ist die jeweils passende Funktionsbeschreibung erforderlich. Die allgemeine Aussage synchronisiert ersetzt diesen Vergleich nicht.

Quellen: [5] [6]

6. Prüfbeispiel: Follow-up, lokaler Fall und QMS-Rückmeldung

Illustratives Szenario, kein Kundenfall und kein ausgeführter Veeva-Test: Das Testsystem enthält den globalen Fall G-073, den vorhandenen lokalen Fall L-073 und den zugeordneten QMS-Datensatz Q-088. Eine weitere Lokalisierung L-099 wurde absichtlich nicht angelegt. G-073 und L-073 enthalten zunächst die fiktiven Ereignisse E1 und E2.

Die geprüfte Nachmeldung bestätigt E1, korrigiert dessen Beschreibung und ergänzt E3. E2 bleibt ausdrücklich unverändert. Der fachlich bearbeitete globale Sollstand enthält danach genau drei Ereignisse: E1, E2 und E3. Für diese kontrollierte Testkonfiguration ist festgelegt, dass die betreffenden strukturierten Ereignisdaten nach der konfigurierten Resync-Aktion in L-073 übereinstimmen müssen. Es wird keine allgemeine Überschreibregel für sämtliche lokalen Felder unterstellt.

Eine bereits erzeugte Testberichtsfassung B-01 ist separat gesichert. Für die neue Bearbeitung wird B-02 nur nach dem vorgesehenen Review erzeugt. Das Beispiel verlangt, dass die Erklärung des früheren Versands erhalten bleibt. Welche konkrete Funktion diesen Nachweis liefert, muss die Implementierung zeigen. Ein aktualisierter lokaler Datensatz allein beweist keine richtige historische Berichtsfassung.

Quellen: [6] [2] [10]

7. Medizinischen Review und technische Übermittlung separat prüfen

Ein Safety-System kann Daten übernehmen, auf formale Kriterien prüfen und Berichte erzeugen. Die medizinische Bedeutung der Information muss trotzdem fachlich beurteilt werden. Halten Sie in der Anforderung fest, welcher Fallstand beurteilt wird, wer fehlende Angaben klärt und wie die Entscheidung mit der verwendeten Quelle verbunden bleibt.

ICH E2D(R1) behandelt medizinische Fallbewertung, Follow-up und Dublettenmanagement als unterschiedliche Aufgaben. Nutzen Sie diese Trennung für Ihre Prüffälle. Ein unveränderter Datensatz kann beispielsweise weiterhin eine offene fachliche Frage enthalten; ein geänderter Datensatz kann dagegen eine gezielte neue Beurteilung benötigen. Der technische Status allein beschreibt diese Situation nicht ausreichend.

Für Übermittlungen kommt eine weitere Ebene hinzu. Ein technisches ACK muss dem richtigen Bericht und Austauschvorgang zugeordnet sein. Es belegt keine medizinische Zustimmung des Empfängers. Prüfen Sie außerdem, wie Ihr Team eine fehlende oder negative Antwort erkennt und weiterbearbeitet. Eine neue Information kann trotz zuvor angenommener Meldung weitere Arbeit am Fall auslösen.

Quellen: [13] [10] [11]

8. Safety-Release und Plattformstand getrennt berücksichtigen

Die Veeva-Wartungsübersicht erläutert, dass Plattformkorrekturen für Safety zeitversetzt zusammen mit Safety-Korrekturen bereitgestellt werden können. Deshalb reicht die allgemeine Vault-Releasebezeichnung für einen konkreten Nachweis nicht aus. Erfassen Sie den tatsächlichen Safety-Build, den Plattformstand und relevante Konfigurationen Ihrer Umgebung.

Am Quellenstichtag 6. Oktober 2026 ist 26R2.0.14 unter dem 30. September dokumentiert. Die Einträge .15 und .16 sind für den Folgetag angekündigt; sie werden hier nicht als bereits ausgeliefert behandelt. Diese Datumsangaben beschreiben den dokumentierten Stand. Maßgeblich für Ihre Prüfung bleibt der nachgewiesene Stand des eigenen Vaults.

Ordnen Sie jede relevante Änderung einem Datenweg zu. Betrifft sie ein Eingangsmapping, eine lokale Aktualisierung oder nur eine ungenutzte Funktion? Welche bisherige Evidenz gilt weiter, und welcher Prüffall zeigt den geänderten Ablauf? Der veröffentlichte Kalender nennt auch ein Hersteller-Validierungspaket. Dessen konkrete Abdeckung muss anhand des tatsächlich verfügbaren Inhalts beurteilt werden; ein Veröffentlichungstermin beantwortet diese Frage nicht.

Quellen: [4] [3] [9]

9. Rechte, historische Informationen und Ausfallbearbeitung einbeziehen

Prüfen Sie mit den tatsächlich vorgesehenen Rollen. Ein Fallbearbeiter, Administrator und Integrationskonto benötigen nicht automatisch denselben Zugriff. Besonders bei verbundenen Anwendungen muss klar sein, ob eine Änderung durch eine Person, einen automatischen Prozess oder eine externe Übernahme entstand. Testen Sie auch einen bewusst fehlenden Zugriff, soweit er für den Prozess relevant ist.

Bei einer Datenmigration legen Sie fest, welche historischen Informationen im neuen Vault benötigt werden und welche kontrolliert an anderer Stelle verbleiben dürfen. Entscheidend ist die nachvollziehbare Nutzung: Können die zuständigen Personen eine frühere Bewertung mit Quelle und Bericht erklären? Ein Zähler mit der richtigen Anzahl übertragener Fälle beantwortet diese Frage nicht.

Für einen Ausfall stimmen Sie die Arbeitsfähigkeit von PV, IT und Dienstleister ab. Wie werden Eingänge weiter angenommen, zwischengespeicherte Informationen zugeordnet und nach Wiederanlauf abgeglichen? Testen Sie einen passenden Wiederanlauf anhand Ihres vorgesehenen Verfahrens. Technische Verfügbarkeit, Vollständigkeit der Fallbearbeitung und historische Zugänglichkeit sind verbundene, aber unterschiedliche Prüfergebnisse.

Quellen: [9] [10] [7]

10. Checkliste für Umfang, Mitwirkung und Nutzungsentscheidung

Für ein KMU entstehen Aufwände häufig an organisatorischen Übergängen: internationale Partner, unterschiedliche lokale Datenstände, externe Fallbearbeitung und mehrere Vault-Verantwortliche. Klären Sie zuerst diese Varianten. Die Anzahl lizenzierter Anwendungen allein ist kein brauchbarer Aufwandsschätzer.

PV bestimmt fachliche Erwartungen und geeignete Prüfdaten. Administratoren und IT stellen Konfiguration, Testzugang und Verbindungen bereit. QA begleitet das vereinbarte Vorgehen für Nachweise und offene Befunde. Legen Sie fest, wer Änderungen beobachtet und eine Auswirkungsbewertung anstößt; diese Aufgabe darf zwischen Anbieter und Anwender nicht unbeabsichtigt offenbleiben.

• Produktiver Vault, Testumgebung, Safety-Build und Plattformstand identifiziert.
• Aktivierte Anwendungen, Funktionen, Verbindungen und relevante Rollen dokumentiert.
• Globale, lokale und externe Datenverantwortung für den Fall beschrieben.
• Unabhängige Erwartungen für Eingänge, Ergänzungen, Korrekturen und fehlende Datensätze festgelegt.
• Fachlicher Review, Fortschrittsmeldung und technisches ACK eindeutig unterschieden.
• Vorhandene Lieferantenbelege zugeordnet und ergänzende Prüfungen begründet.
• Historische Zugänglichkeit, Fehlerbearbeitung und Wiederanlauf praktisch geklärt.
• Offene Befunde, verbleibende Einschränkungen und die Nutzungsentscheidung nachvollziehbar festgehalten.

Quellen: [9] [10] [4]