Inhaltsverzeichnis
Das Wichtigste vorab
Wie wird Veeva CDMS für den klinischen Datenprozess validiert?
Definieren Sie die tatsächlich eingesetzten Veeva-Anwendungen, Studienstände, Rollen und Datenübergänge. Bewerten Sie Herstellerbelege und prüfen Sie die studienspezifische Konfiguration einschließlich Fehlerfällen. Besonders wichtig sind vollständiger Abgleich nach Teilfehlern, kontrollierte Aktivierung von Änderungen und nachvollziehbarer Review. Ein erfolgreicher Deployment- oder API-Status beweist weder fachliche Vollständigkeit noch ausreichende Prüferkontrolle. Release, Lizenz und aktivierte Funktionen müssen zum geprüften Ablauf passen.
- Veeva EDC, DQS und eCOA haben unterschiedliche Aufgaben und Aktivierungsgrenzen.
- Bei bestimmten API-Aufrufen kann ein Teil erfolgreich sein, während andere Teilnehmer unverändert bleiben.
- Deployment, aktive Site-Version und Amendment bestehender Casebooks sind getrennte Prüfpunkte.
- Signaturmöglichkeit und fachlich ausreichender Datenreview sind nicht gleichbedeutend.
1. CDMS als konkreten klinischen Datenprozess beschreiben
Unter dem bekannten Suchbegriff Veeva CDMS stehen heute mehrere Anwendungen von Veeva Clinical Data. Veeva EDC unterstützt Studiendesign, Datenerfassung und Review. DQS führt Daten aus mehreren Quellen zusammen; eCOA erfasst beispielsweise Fragebogenantworten. Der gemeinsame Anbieter macht diese Funktionen nicht zu einem automatisch vollständig lizenzierten oder validierten Gesamtprozess.
Dieser Leitfaden betrachtet klinische Prüfungen von Humanarzneimitteln im EU-GCP-Kontext. Dafür werden die EMA-Leitlinie zu computerisierten Systemen von 2023 und ICH E6(R3), Principles und Annex 1, herangezogen. Letztere sind seit 23. Juli 2025 in der EU wirksam. Annex 2 wird erst am 15. Januar 2027 wirksam. Ein GMP-Systemleitfaden oder eine pauschale FDA-Konformitätsaussage ersetzt diese Einordnung nicht.
Beschreiben Sie, welche Daten die Prüfstelle erhebt, welche Daten von außen kommen und welche Entscheidungen darauf aufbauen. Veeva Safety ist ein gesonderter Anwendungsbereich. Eine Schnittstelle für sicherheitsbezogene Angaben bedeutet noch keine vollständige Safety-Fallbearbeitung oder medizinische Bewertung innerhalb von EDC.
2. Release, Datenmodell und aktivierte Funktionen erfassen
Die öffentliche Dokumentation nennt für 26R2 die Freigabetermine 31. Juli und 7. August 2026. Mit dieser Ausgabe wird CDB in DQS umbenannt; DQS erfordert eine eigene Lizenz. Prüfen Sie deshalb den tatsächlichen Vertrags- und Funktionsumfang, wenn ältere Projektdokumente noch CDB oder allgemein CDMS nennen.
Einige Änderungen werden phasenweise aktiviert. Das betrifft insbesondere EDC Audit 2.0 und Live Capture. Ein Vault mit dem Release-Namen 26R2 muss daher nicht jede beschriebene Funktion bereits verwenden. Halten Sie neben Release und Wartungsstand auch Datenmodell, relevante Featureaktivierungen, Umgebungen und API-Versionen fest.
Die Wartungsübersicht nennt am Quellenstand 6. Oktober 2026 unter anderem 26R2.0.27 vom 30. September. Der Eintrag 26R2.0.29 für den 7. Oktober liegt noch in der Zukunft. Eine angekündigte Fehlerbehebung ist kein Nachweis, dass Ihr System sie bereits enthält. Für die Änderungsbewertung sind der bestätigte Kundenstand und die tatsächlich betroffenen Abläufe maßgeblich.
3. Den Datenweg mit konkreten Ergebnissen und Zuständigkeiten planen
Die folgende eigene Arbeitsmatrix beschreibt einen begrenzten Einsatz: EDC erfasst Studiendaten, eine Integration aktualisiert ausgewählte Ereignisse und ein geregelter Review bewertet Vollständigkeit. DQS wird nur dann Teil des Nachweisumfangs, wenn es tatsächlich eingesetzt wird. Jede Zeile braucht eine verantwortliche Stelle und einen zugänglichen Nachweis.
Für ein kleines Team ist besonders hilfreich, die Entscheidung nach einem Fehler vorab festzulegen. Wer unterscheidet ein falsches Mapping von einer unzulässigen Quelldatenänderung? Wer darf korrigieren, wer muss die Prüfstelle einbeziehen und wer entscheidet über die weitere Verarbeitung? Diese Fragen sollten vor der ersten produktiven Übertragung beantwortet sein.
| Bereich | Konkrete Abgrenzung | Erwarteter Nachweis |
|---|---|---|
| EDC-Studienaufbau | Formulare, Ereignisse, Regeln und Casebook-Version | Geprüfte Studienvorgabe passt zum aktivierten Stand |
| Externe Datenquelle | Festgelegte Quelle und Befugnis für Ereignisänderungen | Herkunft, Teilnehmerbezug und zulässige Änderung sind nachvollziehbar |
| EDC API | Identifizierter Endpunkt, Version und Live-Capture-Status | Innere Ergebnisse werden ausgewertet und mit Zielbestand abgeglichen |
| DQS, falls genutzt | Eigene Lizenz, Datenquellen und Transformationsregeln | Quellenabgleich und Bedeutung abgeleiteter Daten sind geprüft |
| Site-Aktivierung | Freigegebene Bedingungen und aktive Version | Neue Casebooks verwenden den vorgesehenen Stand |
| Review und Abschluss | Rollen, Verblindung, Bestätigung und benötigter Export | Entscheidung und Datenkontext bleiben nachvollziehbar |
4. Deployment und Amendment bestehender Casebooks unterscheiden
Veeva dokumentiert, dass die aktive Version einer Site die anschließend neu angelegten Casebooks bestimmt. Daraus folgt nicht, dass jede vorhandene Teilnehmerakte durch diesen einen Schritt bereits angepasst ist. Planen Sie bestehende und neue Casebooks getrennt und beschreiben Sie die Behandlung früher erfasster Daten.
Prüfen Sie zunächst die Ausgangskonfiguration, danach das Deployment und anschließend den verwendeten Studienstand. Ein technischer Übertragungsnachweis beantwortet eine andere Frage als die fachliche Freigabe einer neuen Protokollregel. Nach ICH E6(R3) sind studienspezifische Änderungen an den einzelnen Prüfstellen erst nach den notwendigen relevanten Genehmigungen zu aktivieren.
Auch der Deployment-Status verlangt eine genaue Lesart. Veeva unterscheidet Completed von Completed with Documentation Errors. Im zweiten Fall war die technische Bereitstellung erfolgreich, während die Erzeugung von SDS oder Vergleichsbericht Fehler enthielt. Bewerten Sie die fehlenden Unterlagen und verbleibende Nachweislücke ausdrücklich. Ein grüner technischer Schritt ist keine Abkürzung für eine begründete Nutzungsentscheidung.
Quellen: [7] [6] [11] [9] [12]
5. Innere API-Ergebnisse statt nur den Gesamtstatus auswerten
Die EDC-API-Referenz unterscheidet äußere und innere Antwortstatus. Der äußere Erfolg kann lediglich anzeigen, dass ein Aufruf verarbeitet wurde, während einzelne Aktionen scheiterten. Ihre Integration muss deshalb die Ergebnisse innerhalb der Antwort auswerten und eindeutig den angeforderten Änderungen zuordnen.
Bei aktivem Audit 2.0 Live Capture beschreibt Veeva für bestimmte Bulk-Endpunkte, darunter Update Event, Erfolg oder Rücknahme pro Teilnehmer. Scheitert ein Objekt eines Teilnehmers, bleiben dessen Änderungen ungespeichert; Änderungen anderer Teilnehmer können bestehen bleiben. Diese Mechanik gilt unter der genannten Aktivierungsbedingung über API-Versionen hinweg. Sie ist keine allgemeine Regel für sämtliche Endpunkte.
Legen Sie als eigene Kontrollmaßnahme einen erwarteten Änderungsbestand an: Teilnehmer, Ereignis, Ausgangswert, Zielwert und Bearbeitungsstatus. Ein erneuter Aufruf darf nicht blind die gesamte ursprüngliche Lieferung wiederholen. Prüfen Sie zuvor, was gespeichert wurde und welche Fehlerursache vorliegt. Die Herstellerhinweise zu Data Not Saved dürfen insbesondere nicht als automatische Wiederholungsregel für fachliche Validierungsfehler gelesen werden.
6. Illustrativer Sollfall: Vier Änderungen gespeichert, zwei zurückgerollt
Das Beispiel ist vollständig konstruiert und wurde nicht gegen ein Veeva-System ausgeführt. Voraussetzung sind aktives Live Capture und ein betroffener Update-Event-Aufruf. Drei synthetische Teilnehmer besitzen jeweils zwei Ereignisse. Anfangs tragen E1 und E2 bei allen die Datumswerte 01.09.2026 und 08.09.2026. Der berechtigte Änderungsauftrag sieht 02.09.2026 und 09.09.2026 vor.
Für S02 wird absichtlich ein Fehler eingebracht: E2 erhält den ungültigen 31.09.2026. Die Sollannahme ist eine entsprechende Fehlerantwort des konkret geprüften Endpunkts. Dabei sind beide Änderungen für S02 zurückzurollen. Ob die reale Fehlerantwort genau dieser Erwartung entspricht, muss der Produkttest zeigen. Alle Daten sind künstlich; die Termine begründen keinen medizinischen Besuchsplan.
| Teilnehmer / Schritt | Angeforderte Änderung | Erwarteter Zielbestand und Bewertung |
|---|---|---|
| S01, erster Aufruf | E1: 01.→02.09.; E2: 08.→09.09. | Beide Änderungen gespeichert: 2 von 2 |
| S02, erster Aufruf | E1: 01.→02.09.; E2: 08.→31.09. | Fehler für S02: beide bleiben beim Ausgangsdatum; 0 von 2 gespeichert |
| S03, erster Aufruf | E1: 01.→02.09.; E2: 08.→09.09. | Beide Änderungen gespeichert: 2 von 2 |
| Abgleich erster Aufruf | 6 angeforderte Änderungen | 2 + 0 + 2 = 4 gespeichert; 2 unverändert; Bearbeitung bleibt offen |
| Korrektur S02 | Ursache klären; E2 auf 09.09. korrigieren; die 2 fehlgeschlagenen Änderungen gezielt erneut senden | Nach Erfolg insgesamt 4 + 2 = 6 erwartete Änderungen im Ziel |
| Abschlussprüfung | Alle 6 Ereignisse anhand Teilnehmer- und Ereigniskennung vergleichen | Keine fehlende Änderung; keine unbeabsichtigte erneute Ausführung der 4 erfolgreichen Aktionen |
7. Rollen und Verblindung bis in technische Nachweise prüfen
Benutzerrechte sollten aus den Aufgaben und Datenbedürfnissen der Studie entstehen. Ein Integrationskonto braucht einen beschriebenen Zweck und einen begrenzten Datenzugriff. Die Fähigkeit, Ereignisse technisch zu ändern, beantwortet nicht, ob eine Änderung an Daten der Prüfstelle fachlich autorisiert ist. Klären Sie diese Befugnisse mit den beteiligten Stellen.
Prüfen Sie außerdem mögliche Informationswege außerhalb des sichtbaren Formulars. Ein Export, eine API-Antwort oder ein Audit-Trail-Eintrag kann Informationen enthalten, die ein verblindeter Benutzer nicht erhalten darf. Dazu gehören auch Bezüge, aus denen sich eine Zuordnung indirekt ableiten lässt. Testen Sie die konkret verwendeten Rollen und Ausgabewege mit geeigneten synthetischen Daten.
Veeva beschreibt gesonderte Berechtigungen für eingeschränkte Daten. Nutzen Sie diese Angaben als Ausgangspunkt für die tatsächliche Konfigurationsprüfung. Der eigene Negativtest sollte zeigen, dass eine nicht berechtigte Rolle die geschützte Information weder über die vorgesehene Oberfläche noch über die im Prozess genutzten Ausgaben erhält.
8. Review, offene Queries und Signaturen zusammenhängend bewerten
Veeva EDC unterstützt Signaturen auf Form-, Event- oder Casebook-Ebene. Dafür sind passende Definitionen und Berechtigungen erforderlich. Bestimmte Änderungen können Signaturen aufheben. Zugleich kann bei Data Model 2 die aktivierte Option Enable Sign with Open Queries Signaturen trotz offener Queries ermöglichen. Eine pauschale Aussage, jede offene Query verhindere jede Signatur, wäre deshalb falsch.
Definieren Sie die fachliche Bedeutung Ihrer Bestätigung und prüfen Sie die tatsächlich eingeschlossenen Daten. Ein technisch signierbarer Zustand sagt nicht, ob die offenen Fragen für die jeweilige Entscheidung ausreichend geklärt sind. Auch eine Sammelsignatur belegt für sich allein keinen angemessenen vorausgehenden Review.
Der Review muss zur Studie, zum Risiko und zum Zeitpunkt passen. Legen Sie relevante Datenänderungen und Audit-Trail-Ereignisse fest, die gesondert bewertet werden. Nach einer Änderung ist zu prüfen, ob die frühere Bestätigung ihre Bedeutung behält oder eine erneute Bewertung benötigt wird. Die konkrete Signaturkonfiguration ist dabei nur ein Teil des fachlichen Kontrollkonzepts.
9. Betrieb, Abschluss und KMU-Aufwand konkret vorbereiten
Für kleine Sponsor- und CRO-Teams entstehen hohe Aufwände oft an ungeklärten Übergaben: Ein Datenmanager erwartet eine Korrektur durch IT, während IT auf eine fachliche Freigabe wartet. Vereinbaren Sie für Schnittstellenfehler deshalb Eskalationsweg, Informationsbedarf und Entscheidungsbefugnis. Der offene Bestand muss erkennbar bleiben, auch wenn ein Übertragungsauftrag technisch beendet ist.
Anbieterbelege können geeignete Standardnachweise liefern. Ergänzend brauchen Sie geprüfte Studienregeln, Mappings, Rollen, relevante Ausgaben und betriebliche Abläufe. Umfangreiche Sonderlogik, viele Quellen oder häufige Amendments erhöhen die nötige Abstimmung. Eine frühe Klärung dieser Punkte ermöglicht eine belastbarere Aufwandplanung als eine pauschale Schätzung allein nach Benutzerzahl.
Planen Sie den Studienabschluss schon während der Einrichtung: Welche Daten und Metadaten werden benötigt, wer erhält sie, in welcher Form bleiben sie interpretierbar und wie wird der Zugriff gesichert? Ein Tabellenexport kann für einen Auswertungszweck genügen und für einen anderen Nachweis unzureichend sein. Aufbewahrung, Vertragsende und spätere Lesbarkeit werden je Datenbestand bestimmt, nicht mit einer pauschalen Frist für alle Informationen.
10. Checkliste für den nachweisbaren Veeva-Datenfluss
Die folgende eigene Checkliste verbindet Konfiguration, Verarbeitung und fachliche Entscheidung. Verwenden Sie sie vor der Nutzung eines neuen Datenwegs und nach Änderungen, die seine Aussage beeinflussen können. Verantwortliche sollten für jeden offenen Punkt sagen können, welcher Nachweis fehlt und wie bis zur Klärung verfahren wird.
Im illustrativen Beispiel wäre nach dem ersten Aufruf keine vollständige Erledigung zulässig: Zwei Änderungen bleiben offen. Erst die korrigierte Verarbeitung mit anschließendem vollständigem Abgleich schließt diesen Arbeitsauftrag. Die Studienfreigabe und der weitere fachliche Review bleiben davon getrennte Entscheidungen.
- Sind EDC, DQS und weitere Anwendungen samt Lizenzen ausdrücklich abgegrenzt?
- Sind Release, Wartungsstand, Datenmodell und Featureaktivierungen bestätigt?
- Passen Protokollvorgabe, Studienkonfiguration und eingesetzte Datenquellen zusammen?
- Sind neue und bestehende Casebooks bei Änderungen getrennt berücksichtigt?
- Sind notwendige Site-Genehmigungen und Aktivierungsbedingungen dokumentiert?
- Werden innere API-Ergebnisse ausgewertet und fehlgeschlagene Änderungen sichtbar gehalten?
- Sind Fehlerursache, Korrektur und gezielter Wiederanlauf geprüft?
- Sind Rollen und Verblindung auch für Logs, Metadaten und Exporte wirksam?
- Sind Signaturumfang, offene Queries und fachlicher Review abgestimmt?
- Bleiben Abschlussdaten mit relevantem Kontext für die erforderliche Zeit verfügbar?
Häufige Fragen zu Veeva CDMS
Sind Veeva CDMS, EDC und DQS dasselbe?
CDMS wird häufig als Sammelbegriff verwendet. Die aktuelle Herstellerübersicht unterscheidet Veeva EDC für Studiendesign, Erfassung und Review sowie DQS für die Zusammenführung und Bearbeitung mehrerer Datenquellen. CDB heißt seit 26R2 DQS und benötigt eine eigene Lizenz. Beschreiben Sie im Nachweis deshalb die tatsächlich eingesetzten Anwendungen, Funktionen und Übergänge statt nur einen allgemeinen Suite-Namen.
Beweist 26R2, dass Live Capture in unserem Vault aktiv ist?
Nein. Veeva beschreibt Audit 2.0 und Live Capture als phasenweise Bereitstellung. Neben der Releasebezeichnung benötigen Sie den tatsächlichen Aktivierungsstand. Dieser kann das Verhalten betroffener Bulk-Aufrufe verändern. Halten Sie die Konfiguration der Test- und Produktivumgebung fest und bewerten Sie Unterschiede. Eine ältere API-Version verhindert die beschriebene Änderung bei aktivem Live Capture nicht automatisch.
Warum kann eine erfolgreiche API-Antwort trotzdem unvollständig sein?
Die Referenz unterscheidet äußere und innere Statusangaben. Ein äußerer Erfolg bedeutet nicht zwingend, dass jede Aktion gespeichert wurde. Werten Sie deshalb die Ergebnisse der einzelnen Einträge aus und gleichen Sie sie mit dem angeforderten und tatsächlich vorhandenen Zielbestand ab. Im eigenen Sollfall sind nach dem ersten Aufruf vier von sechs Änderungen gespeichert; zwei bleiben ausdrücklich offen.
Quellen: [4]
Dürfen wir nach einem Teilfehler einfach den ganzen Aufruf wiederholen?
Nicht ungeprüft. Bereits erfolgreiche Aktionen könnten erneut ausgeführt werden. Bestimmen Sie zuerst gespeicherte und fehlgeschlagene Änderungen, klären Sie die Ursache und wählen Sie den passenden Wiederanlauf. Bei einem fachlichen Validierungsfehler muss die fehlerhafte Vorgabe korrigiert werden. Die Herstellerempfehlung für Data Not Saved ist keine allgemeine Wiederholungsregel für jeden Fehler und keine Idempotenzgarantie.
Aktualisiert eine neue aktive Site-Version alle vorhandenen Casebooks?
Die Dokumentation beschreibt, dass anschließend neu angelegte Casebooks die zugewiesene aktive Version verwenden. Bestehende Casebooks benötigen eine gesonderte Betrachtung ihres Amendments. Legen Sie fest, welche Teilnehmer und bisherigen Daten betroffen sind. Prüfen Sie den Übergang mit Alt- und Neudaten; setzen Sie eine technische Site-Einstellung nicht mit einer bereits vollständig umgesetzten Studienänderung gleich.
Wie behandeln wir Completed with Documentation Errors beim Deployment?
Veeva beschreibt damit eine erfolgreiche technische Bereitstellung bei Fehlern der SDS- oder Vergleichsbericht-Erzeugung. Untersuchen Sie, welche Dokumentation fehlt und ob der vorgesehene Nachweis damit unvollständig ist. Der Status erlaubt keine automatische fachliche Freigabe. Dokumentieren Sie Bewertung, Korrektur und gegebenenfalls Einschränkungen, bevor Sie sich für die Nutzung des geänderten Studienstands auf diese Unterlagen stützen.
Sind offene Queries immer eine technische Signatursperre?
Das hängt von Ebene, Datenmodell und aktivierter Konfiguration ab. Die Veeva-Hilfe beschreibt für Data Model 2 eine Option zum Signieren mit offenen Queries. Die fachliche Zulässigkeit Ihrer Bestätigung muss deshalb separat festgelegt sein. Prüfen Sie, welche Daten eine Signatur umfasst, welche Fragen noch offen sind und wie relevante spätere Änderungen die Signatur oder den erforderlichen Review beeinflussen.
Reicht eine eingeschränkte Benutzeroberfläche für die Verblindung?
Sie ist nur ein Teil der Kontrolle. Berücksichtigen Sie auch genutzte Exporte, API-Antworten, Fehlermeldungen und relevante Metadaten. Eine Rolle könnte sonst außerhalb des Formulars eine unerlaubte Zuordnung erkennen. Prüfen Sie die konkreten Ausgabewege mit synthetischen Daten und dokumentieren Sie die erwarteten Zugriffsbeschränkungen. Die geeignete Ausgestaltung richtet sich nach dem Studiendesign und den tatsächlichen Aufgaben.
Müssen wir alle Herstellerfunktionen erneut selbst testen?
Nein, nicht pauschal. Bewerten Sie vorhandene Anbieterbelege hinsichtlich Version, beabsichtigtem Einsatz und Abdeckung. Die eigene Nachweisarbeit konzentriert sich auf verbleibende Lücken und Ihre Studienkonfiguration, Integrationen und Abläufe. Das kann gezielte Bestätigung vorhandener Nachweise ebenso wie zusätzliche Tests bedeuten. Dokumentieren Sie diese Entscheidung; ein allgemeines Anbieterpaket ersetzt die Bewertung des konkreten Einsatzes nicht.
Welche Vorbereitung hilft einem kleinen Team am meisten?
Bereiten Sie einen abgegrenzten Datenweg mit Quelle, Mapping, Studienversion, Rollen und erwarteten Ergebnissen vor. Benennen Sie die Verantwortlichen für fachliche Rückfragen und technische Fehlerbearbeitung. Ein vollständig ausgefüllter Sollfall mit Teilfehler und Wiederanlauf macht fehlende Entscheidungen früh sichtbar. Ergänzen Sie danach weitere Risiken und Datenwege. Daraus lässt sich der Aufwand nachvollziehbar ableiten, ohne feste Zeit- oder Preisversprechen.
Quellen & fachlicher Stand
Quellenstand: 6. Oktober 2026. Herstellerbezug: Veeva Clinical Data 26R2, EDC API 26.2 und aktuelle General-Release-Hilfe. Live Capture, Datenmodell und Lizenzumfang sind kundenbezogen zu bestätigen. Für den 7. Oktober angekündigte Wartungsstände werden nicht als bereits installiert behandelt. EU-GCP ist der regulatorische Beispielrahmen. Tabellen und Zahlen sind eigene Sollhilfen ohne ausgeführten Produkttest.
- Veeva: Clinical Data Applications Overview
- Veeva: About the 26R2 Release
- Veeva: What's New in 26R2
- Veeva EDC API Reference 26.2
- Veeva: Providing Signatures
- Veeva: Deploying a Study
- Veeva: Managing Sites
- Veeva: 26R2 Maintenance Releases
- EMA: Guideline on computerised systems and electronic data in clinical trials
- EMA: ICH E6 Good Clinical Practice – Status
- ICH E6(R3): Principles and Annex1 – EU Step5
- Veeva: Managing Casebook Versions & Amendments
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Veeva-Datenflüsse mit klaren Nachweisen betreiben
Wir helfen Ihnen, Herstellerbelege, Studienkonfiguration und Schnittstellenkontrollen auf den tatsächlichen Einsatz auszurichten.
- IT-GxP-Audit →
Nachweise zu Datenfluss, Änderungen, Rollen und Abschluss auf konkrete Lücken prüfen.
- IT-GxP-Consulting →
Anforderungen, Fehlerbehandlung und nachvollziehbare Sollfälle mit Ihrem Team ausarbeiten.