Veeva RIM validieren: Den richtigen Marktstand bis zur Einreichung nachvollziehen

1. RIM nach dem konkreten Zulassungsprozess abgrenzen

Veeva RIM verbindet auf einer Cloudplattform Anwendungen für Zulassungen, Einreichungsinhalte, Publishing und Archive. Damit ist es von Veeva Safety und klinischer Datenerfassung zu unterscheiden. Ein Studienbericht im Zulassungsdossier macht RIM nicht zum System, in dem die ursprünglichen Studiendaten erhoben wurden. Ebenso ist eine Zulassungsänderung kein einzelner Nebenwirkungsfall.

Für die Eignungsbewertung interessiert, welche Entscheidung auf welchen Informationen beruht. Soll RIM zeigen, welcher Dokumentstand in einem Markt maßgeblich ist? Wird dort eine Änderung geplant, ein Dossier zusammengestellt oder eine Behördenantwort nachverfolgt? Grenzen Sie diese Aufgaben einschließlich ihrer Schnittstellen ab. Die bloße Zugehörigkeit zur pharmazeutischen Branche bestimmt den Nachweisumfang noch nicht.

Annex 11 ist im passenden Humanarzneimittel-GMP-Zusammenhang zu berücksichtigen, etwa wenn eine regulatorische Information einen geregelten Betriebsprozess unterstützt. Daraus folgt keine pauschale GMP-Anwendung auf jede RIM-Funktion. FDA-Anforderungen an elektronische Aufzeichnungen sind ebenfalls anhand des tatsächlichen Scopes zu beurteilen. Herstellerkonfiguration, technische Einreichungsprüfung und fachlicher Zulassungsentscheid bleiben unterschiedliche Gegenstände. Kein Produktname liefert dafür automatisch eine GAMP-Kategorie, Signaturpflicht oder behördliche Anerkennung.

Quellen: [1] [12] [11]

2. Den tatsächlich lizenzierten RIM-Umfang beschreiben

Die Veeva-Übersicht unterscheidet Registrations, Submissions, Submissions Publishing und Submissions Archive. Sie teilen ein Datenmodell, erfüllen aber unterschiedliche Aufgaben. Ein Registrations-Einsatz beweist nicht, dass Publishing lizenziert und passend konfiguriert ist. Erfassen Sie die Anwendungen, aktivierten Funktionen, Datenverbindungen und Zuständigkeiten Ihres Vaults.

Als konkreter Releaseanker dienen hier die veröffentlichten Angaben zu 26R2 mit Auslieferungsterminen am 31. Juli und 7. August 2026. Hinzu kommt die am 6. Oktober 2026 verfügbare General-Release-Hilfe. Das ist kein bestätigter Versionsstand Ihres Tenants. Funktionen aus einem Limited Release werden nicht ungeprüft als allgemeine Verfügbarkeit übernommen.

Die folgende Tabelle verbindet Anwendungen mit einem fiktiven Einsatzgegenstand. Sie ist eine eigene Planungshilfe, keine vollständige Lizenz- oder Datenmodellbeschreibung. Halten Sie besonders fest, ob eine Aufgabe in Veeva, in einer externen Lösung oder manuell erledigt wird. Diese Übergänge bestimmen häufig mehr Prüfarbeit als die Anzahl der sichtbaren Module.

Quellen: [1] [7] [3] [6]

3. Objektbeziehungen als fachliche Entscheidung behandeln

Application, Regulatory Objective und Submission sind keine austauschbaren Etiketten. Veevas Submission Wizard unterstützt die Auswahl von Beziehungen aus der Application und ihre Übernahme in Submission beziehungsweise Regulatory Objective. Für bestimmte Aktualisierungen sind zudem die passenden Registrations-Verknüpfungen wichtig. Die Software kann jedoch nur mit dem ausgewählten und gepflegten Kontext arbeiten.

Definieren Sie deshalb, welches Produkt, welcher Markt und welcher Änderungsgegenstand zusammengehören. Ein kopierter Datensatz kann formal vollständig sein und trotzdem eine nicht betroffene Zulassung einschließen oder eine betroffene übersehen. Prüfen Sie einen richtigen Bezug, einen absichtlich fremden Markt und eine fehlende Beziehung. Das Soll wird aus dem fachlich festgelegten Änderungsumfang abgeleitet, nicht aus dem bereits erzeugten Systemergebnis.

Für bestehende Daten ist zusätzlich zu klären, welche Quelle maßgeblich ist und wer Inkonsistenzen entscheidet. Werden Beziehungen aus einem anderen System übernommen, muss ihre Bedeutung erhalten bleiben. Ein technischer Import mit der erwarteten Zeilenzahl genügt nicht, wenn dieselben Zeilen auf die falsche Application zeigen. Halten Sie die beabsichtigte Zuordnung verständlich fest, damit Regulatory Affairs und IT denselben Fehler erkennen können.

Quellen: [2] [1]

4. Content Plan, Dokumentversion und Publishing-Ausgabe verbinden

In Submissions Publishing verbindet der Content Plan Dokumente mit der Einreichung. Veeva beschreibt außerdem Continuous Publishing, das relevante Änderungen an Quelldokumenten oder Links in der Ausgabe berücksichtigen kann. Welcher Inhalt tatsächlich publiziert wird, hängt unter anderem von den gewählten Quell- beziehungsweise Renditioneinstellungen und der Konfiguration ab.

Für den Nachweis sollten Sie eine freigegebene Quelle und den erwarteten Output unabhängig bestimmen. Prüfen Sie, ob die richtige Version am richtigen Platz erscheint und ob die benötigten Verweise funktionieren. Ein neuerer Entwurf mit ähnlichem Namen darf nicht unbemerkt an die Stelle des zur Einreichung bestimmten Dokuments treten. Ist eine bearbeitbare Quelldatei statt ihrer Ansicht erforderlich, muss auch diese Wahl eindeutig sein.

Untersuchen Sie außerdem, was bei einer Änderung während der Vorbereitung passiert. Bleibt der bereits geprüfte Paketstand erkennbar? Wird die Ausgabe erneut erzeugt und muss der Review aktualisiert werden? Die Produktfunktion, Änderungen zu verfolgen, beantwortet diese fachlichen Abschlussfragen nicht automatisch. Legen Sie fest, welcher Stand schließlich geprüft, übermittelt und später als eingereicht nachgewiesen wird. Für externe Quellen gehört deren Versions- und Metadatenübergang in dieselbe Betrachtung.

Quellen: [3] [8]

5. Illustratives Sollbeispiel: Zwei Märkte, zwei zulässige Versionsstände

Dieses Modell ist frei konstruiert und kein ausgeführter Veeva- oder Kundentest. Ein fiktives Produkt besitzt in Markt A und Markt B jeweils die Dokumentstände S1, B1 und P1. Für die Änderung von S1 zu S2 gilt ausdrücklich die Beispielannahme: Der neue Stand wird im jeweiligen Markt erst nach der dafür erforderlichen positiven Entscheidung maßgeblich. Das ist keine Regel für alle Änderungsverfahren. S2 wurde in beiden Märkten eingereicht; nur für A liegt die erforderliche Entscheidung vor. Für B bleibt S1 maßgeblich.

Das vorab bestimmte Soll enthält weiterhin sechs Markt-Dokument-Zuordnungen: drei für A und drei für B. Davon zeigen fünf auf Version 1 und eine auf Version 2. Zwei Einreichungen ergeben also nicht zwei freigegebene neue Marktstände. Auch eine reine Anzahl von sechs Datensätzen würde den Fehler nicht erkennen, wenn B fälschlich ebenfalls S2 zugeordnet würde.

Veevas Active Dossier ist konfigurations- und metadatenabhängig. Das Feld Latest for Authoring folgt der Dokumenthierarchie innerhalb eines definierten Application-, Country- und Product-Kontexts. Es wird deshalb hier nicht als Beweis einer behördlichen Entscheidung verwendet. Prüfen Sie im eigenen Aufbau, welche Information die fachliche Frage tatsächlich beantwortet. Vor jedem Fehlerfall werden dieselben Beziehungen, Dokumentversionen und Entscheidungsbelege hergestellt; danach wird gezielt ein Marktbezug oder Entscheidungsstand verändert.

Quellen: [5] [2]

6. Technische Ergebnisse einschließlich nicht ausgeführter Prüfungen bewerten

Veeva unterscheidet bei Submission Validation Results unter anderem Pass, Failure, Not Executed und Internal Error. Diese Zustände sind nicht gleichbedeutend. Eine nicht ausgeführte Prüfung darf nicht unbemerkt wie ein bestandener Check in Ihre Abschlussbewertung eingehen. Legen Sie fest, welche Regeln für die konkrete Einreichung relevant sind und wie offene oder fehlerhafte Ausführungen behandelt werden.

Der Kriterienstand muss zu Region und Format passen. Die EU-eCTD-Guidance trennt technische Prüfung von Inhaltsbewertung und begrenzt, was technische Kriterien über richtige Metadaten aussagen können. Ein fehlerfreier Bericht kann daher eine falsche Marktzuordnung aus dem eigenen Beispiel nicht ersetzen. Ergänzen Sie den fachlichen Abgleich gegen den genehmigten Umfang.

Ein konkreter 26R2-Hinweis ist wichtig für die Änderungsprüfung: Wird die Validation Criteria Version geändert und gespeichert, beschreibt Veeva eine automatische On-Demand-Prüfung bei eingeschaltetem Continuous Publishing. Prüfen Sie diese Voraussetzung im eigenen Aufbau. Ein anderer Schalterzustand oder ein Bericht vor der Änderung ist nicht derselbe Nachweis. Bewahren Sie den Zusammenhang zwischen Kriterien, geprüftem Output und der daraus abgeleiteten Entscheidung verständlich auf.

Quellen: [4] [3] [7] [8]

7. Versand, technische Antwort und Entscheidung auseinanderhalten

Veeva beschreibt Gatewayprofile für bestimmte US- und EU-Übermittlungen. Profile müssen passend eingerichtet und aktiviert werden; dazu gehören entsprechende Behördenzugänge und Konfigurationsdaten. Die EMA-eCTD-Anbindung wird im dokumentierten zentralisierten Verfahrensscope beschrieben. Daraus entsteht keine pauschale Unterstützung sämtlicher Einreichungswege, Konten oder regionaler Verfahren.

Prüfen Sie mit geeigneten Testmöglichkeiten, dass Paket, Empfänger und Antwort zusammengehören. Ein ausgegebener Datensatz darf nicht versehentlich an einen anderen Markt oder eine falsche Application gekoppelt sein. Definieren Sie außerdem den Umgang mit fehlender, negativer oder verspäteter Rückmeldung. Ein erneuter technischer Versuch darf den ursprünglichen Vorgang nicht so verdecken, dass später unklar bleibt, was tatsächlich übermittelt wurde.

Die EMA bezeichnet die automatische Rückmeldung als technische Validierungsrückmeldung. Sie ist kein allgemeiner inhaltlicher Zulassungsbescheid. Halten Sie im RIM-Prozess daher klar auseinander, ob etwas vorbereitet, versendet, technisch angenommen oder fachlich entschieden wurde. Das eigene Zwei-Märkte-Beispiel benötigt für S2 in Markt B weiterhin den einschlägigen Entscheidungsbeleg. Ein erfolgreicher Versand allein ändert dieses Soll nicht.

Quellen: [6] [10] [8]

8. Rechte und spätere Lesbarkeit am benötigten Nachweis ausrichten

Verantwortliche müssen entscheiden können, wer fachliche Beziehungen, Dokumentzuordnungen oder Statusinformationen ändern darf. Prüfen Sie dabei nicht nur die normale Bearbeitung, sondern auch administrative Möglichkeiten und den kontrollierten Korrekturweg. Eine falsche Länderzuordnung soll berichtigt werden können, ohne den zuvor maßgeblichen Stand und dessen Begründung unverständlich zu machen.

Die Hilfe zu Submission Validation Results beschreibt einen eigenen Archivjob: Unter den dort genannten Bedingungen werden Ergebnisse in ein Paket mit XML und weiteren Dateien überführt; erfolgreich archivierte Ergebnisdatensätze werden anschließend entfernt. Diese Produktmechanik ist keine gesetzliche Aufbewahrungsfrist. Prüfen Sie, ob die für Ihre Entscheidung benötigten Berichte später im Zusammenhang mit Einreichung, Version und Kriterien verständlich verfügbar bleiben.

Für GMP-relevante Aufzeichnungen sind Schutz, Beziehungen und kontrollierte Korrekturen im zutreffenden Dokumentationsscope zu betrachten. Bei FDA-Aufzeichnungen folgt die Beurteilung den einschlägigen Grundanforderungen und dem konkreten elektronischen Gebrauch. Der Artikel behauptet weder unbegrenzte Aufbewahrung noch automatische Unveränderbarkeit. Ebenso wird eine interne Freigabeaktion nicht ohne Prüfung als jede erforderliche elektronische Signatur bezeichnet.

Quellen: [4] [13] [12] [11]

9. Release, Kriterienwechsel und Migration auf den eigenen Ablauf beziehen

Eine Cloudplattform entbindet den Anwender nicht davon, relevante Änderungen zu verstehen. Beginnen Sie mit dem betroffenen Ablauf: Ändert sich ein Datenbezug, eine Publishingregel, die Ergebnisdarstellung oder eine Verbindung zu einer anderen Anwendung? Die 26R2-Releaseinformationen enthalten beispielsweise RIM- und Connection-Änderungen. Nicht jede beschriebene Neuerung ist in jedem Vault aktiv oder für jeden Prozess gleich wichtig.

Bewerten Sie Herstellerunterlagen und vorhandene Nachweise nach ihrem tatsächlichen Umfang, Version, Konfiguration und Umgebung. Ein Lieferpaket kann mehr oder weniger von Ihrem Einsatz abdecken; pauschale Annahmen über ausschließlich Standardfunktionen helfen nicht. Leiten Sie verbleibende Prüfungen aus den konkreten Lücken und Risiken ab. Ein vollständiger Neuaufbau aller Tests ist ebenso wenig automatisch erforderlich wie ein ungeprüfter Verzicht.

Bei einer Migration sind Objektbeziehungen, Versionen und fachliche Statusbedeutungen besonders wichtig. Prüfen Sie bekannte Marktstände gegen eine unabhängige Quelle, einschließlich eines offenen und eines abgeschlossenen Verfahrens. Für einen Wechsel zu eCTD 4.0 müssen technische Produktunterstützung und behördliche Verfahrensreife zusammenpassen. Der in der EU beschriebene Übergang unterscheidet neue Anträge von bestehenden Lebenszyklen; eine bloße Formatoption im Werkzeug entscheidet nicht über die Zulässigkeit.

Quellen: [7] [5] [9] [12]

10. Mit einem verständlichen Soll und verfügbaren Ansprechpartnern starten

Vor dem Start sollte ein repräsentativer Produktänderungsfall mit den betroffenen Märkten und maßgeblichen Belegen vorliegen. Regulatory Affairs legt die Bedeutung von Entscheidungen und Statusinformationen fest. Dokumentverantwortliche erklären den freigegebenen Inhalt, die Vault-Administration Datenmodell und Konfiguration, IT die Verbindungen und Betriebsgrenzen. QA wird entsprechend dem tatsächlich betroffenen Qualitätsscope einbezogen.

Der Aufwand hängt vor allem von Datenqualität, Zahl unterschiedlicher Verfahren, historischen Beständen, Konfiguration und externen Übergängen ab. Viele gleichartige Einreichungen können weniger Klärung benötigen als wenige Sonderfälle mit unklaren Beziehungen. Bei einer Einführung wird das Soll vor der Konfiguration festgelegt; im Bestand muss zuerst die tatsächliche Arbeitsweise mit vorhandenen Regeln und Daten verglichen werden.

Die Checkliste hilft, einen konkreten Arbeitsauftrag statt einer allgemeinen Produktprüfung zu formulieren. Offene Lizenz-, Versions- oder Lieferbelegfragen werden ausdrücklich festgehalten. Ohne passende Testmöglichkeiten bleiben Wirkungsbehauptungen offen; sie werden nicht durch eine Funktionsbeschreibung ersetzt.

• Genutzte RIM-Anwendungen, Konfigurationsstand und Verantwortlichkeiten benennen.
• Produkt, Application, Märkte und regulatorischen Änderungsumfang festlegen.
• Freigegebene Dokumentversionen und erwartete Länderstände bereitstellen.
• Content Plan, Format, Kriterienversion und Outputzuordnung erfassen.
• Testprofile und echte Übermittlung klar voneinander trennen.
• Offene, technisch angenommene und fachlich entschiedene Fälle vorbereiten.
• Anbieterbelege, Migrationsdaten und Aufbewahrungszwecke nachvollziehbar zuordnen.

Quellen: [1] [2] [3]