UDI · AUDIT TRAIL · CSV / CSA

UDI-Software: Audit Trail, Datenintegrität und Validierung

Wer hat welche UDI-Daten geändert, wer hat sie freigegeben und was wurde tatsächlich übertragen? Ein belastbarer UDI-Prozess muss diese Fragen nachvollziehbar beantworten können. Ein Audit Trail unterstützt diesen Nachweis — er macht eine Software allein aber nicht automatisch compliant. Entscheidend sind der vorgesehene Einsatz, kontrollierte Abläufe und geeignete Prüfungen im Unternehmen.

Änderung nachvollziehen. Freigabe zuordnen. Nachweise wiederfinden.

Was ist ein Audit Trail für UDI-Daten?

Ein Audit Trail ist eine nachvollziehbare Historie relevanter Systemaktionen und Datenänderungen. Er hilft dabei, Bearbeiter, Zeitpunkt, betroffene Datensätze und Änderungen zuzuordnen. Für die praktische Bewertung ist wichtig, welche Ereignisse tatsächlich erfasst werden, wie die Aufzeichnungen geschützt sind und wie sie überprüft werden können.

SAP Audit Trail App

Bestandsansicht der SAP Audit Trail App: sichtbar sind unter anderem Datum, Uhrzeit, Benutzer, Tabellen-/Feldname sowie alter und neuer Wert. Der Screenshot belegt diese Ansicht, nicht pauschal sämtliche Funktionen jeder aktuellen Version oder jedes GSP-Moduls.

Prüffrage Warum sie wichtig ist
Wer hat geändert? Eindeutige Benutzerzuordnung statt gemeinsamer, nicht unterscheidbarer Konten.
Was hat sich geändert? Datensatz, Feld, alter/neuer Wert beziehungsweise dokumentierter Änderungsumfang.
Wann und in welchem Zusammenhang? Zeitpunkt, Version und Bezug zu Freigabe oder Übertragung.
Ist die Historie geschützt? Berechtigungen, Aufbewahrung und Zugriff auf Aufzeichnungen prüfen.
Wird sie genutzt? Review, Abweichungsbearbeitung und Wiederauffindbarkeit festlegen.

Vier verschiedene Nachweise — nicht ein einziges „grünes Häkchen“

Datenvalidierung

Sind Pflichtfelder, Formate und fachliche Regeln des Datensatzes erfüllt?

Systemvalidierung / Assurance

Funktioniert der konfigurierte Prozess zuverlässig für seinen vorgesehenen Einsatz?

Audit Trail

Welche relevanten Änderungen und Aktionen sind dokumentiert?

Submission-Nachweis

Welche Version wurde eingereicht, und welche Rückmeldung liegt vor?

CSV und Software Assurance risikobasiert planen

Die FDA-Leitlinie Computer Software Assurance for Production and Quality Management System Software, Februar 2026, beschreibt einen risikobasierten Ansatz für Software in Produktion und Qualitätsmanagement. Sie ersetzt die Fassung von September 2025. Ihr konkreter Anwendungsbereich ist zu prüfen; sie ist keine pauschale Pflicht zur gleichen Testdokumentation für jede UDI-Anwendung.

FDA: Software Assurance, February 2026

GAMP 5, zweite Ausgabe, ist ein Leitfaden für einen risikobasierten Lebenszyklusansatz, kein behördliches Produktzertifikat. Das bestehende V-Modell veranschaulicht mögliche Dokumente und Testbezüge; der geeignete Umfang ergibt sich aus Nutzung, Risiken und Änderungen.

ISPE: GAMP 5, second edition

Bestehende V-Modell-Grafik: Orientierung für Anforderungen, Tests und Nachweise
Bestehende V-Modell-Grafik: Orientierung für Anforderungen, Tests und Nachweise. Kein unveränderlicher Pflichtablauf für jedes System.

Wann ist 21 CFR Part 11 relevant?

Die Anwendbarkeit hängt insbesondere von den betroffenen elektronischen Aufzeichnungen und den zugrunde liegenden FDA-Anforderungen ab. Für erfasste geschlossene Systeme nennt § 11.10 unter anderem Validierung, Zugriffskontrollen und geschützte, zeitgestempelte Audit Trails. Part 11 gilt nicht allein deshalb, weil eine Software UDI-Daten verarbeitet.

FDA: Part 11 scope and application · 21 CFR 11.10: controls for closed systems

Ebenso lassen sich DSGVO, HIPAA oder SOX nicht als pauschal identische Audit-Trail-Pflicht für jedes UDI-Projekt aufführen. Rechtsgrundlage, Datenarten und organisatorischer Kontext sind gesondert zu beurteilen.

Softwarefunktion und Unternehmensprozess greifen ineinander

Europe IT / vereinbarter Lieferumfang

Systemfunktionen, Daten- und Übertragungsprozesse sowie projektbezogene technische Informationen anhand des vereinbarten Umfangs bereitstellen. Keine nicht vereinbarte vollständige Validierungsdokumentation unterstellen.

Kunde / Prozessverantwortliche

Vorgesehenen Einsatz, Anforderungen, Rollen, Freigaben, Prüf- und Reviewprozesse im eigenen Qualitätsmanagement festlegen. Datenfehler und erneute Einreichungen bleiben im bestätigten GSP-/GUDI-Prozess beim Kunden.

Behörde

Eingereichte Daten nach den eigenen Regeln verarbeiten und Rückmeldungen bereitstellen. Annahme einer Einreichung ersetzt keinen Nachweis sämtlicher interner Prozesskontrollen.

GUDI und GSP im richtigen Nachweiskontext

GUDI ist die SAP-Lösung für UDI-Datenmanagement und Übertragung an Behörden. GSP unterstützt den portalbasierten Prozess mit Excel-Import, Validierung und vom Kunden ausgelöster Übertragung. Welche Protokolle, Historien, Exportmöglichkeiten und Dokumente für einen konkreten Einsatz verfügbar sind, wird am betreffenden Modul und vereinbarten Umfang geprüft.

Ein guter Projektstart verbindet Datenquelle, Europe-IT-Lösung, technischen Übertragungsweg und Betriebsmodell mit klaren Zuständigkeiten. So lassen sich benötigte Nachweise gezielt planen, ohne Datenprüfung, Systemvalidierung und Behördenannahme zu vermischen.

UDI-Prozess und Nachweise besprechen →

Häufige Fragen

Ist ein Audit Trail automatisch eine elektronische Signatur?

Nein. Änderungsprotokoll und elektronische Signatur sind unterschiedliche Funktionen. Ob Signaturen benötigt werden und welche Anforderungen gelten, muss für den jeweiligen Prozess geprüft werden.

Reicht ein fehlerfreier UDI-Datensatz als Validierungsnachweis?

Nein. Eine erfolgreiche Datenprüfung sagt nicht allein aus, dass Rollen, Freigaben, Schnittstellen, Fehlerbehandlung und Betriebsabläufe für den vorgesehenen Einsatz geprüft sind.

Ist ein Screenshot ein vollständiger Audit-Nachweis?

Nein. Er kann eine Ansicht dokumentieren. Der vollständige Nachweis erfordert den zugehörigen Kontext, Datensatz beziehungsweise Prozess und geeignete, wiederauffindbare Aufzeichnungen.

Quellen und weiterführende Informationen