Inhaltsverzeichnis
Das Wichtigste vorab
Wann muss ein GxP-System revalidiert werden?
Neue Nachweise sind zu bewerten, wenn Änderungen, neue Verwendungszwecke oder erkannte Probleme die bisherige Eignung infrage stellen. Der Umfang richtet sich nach der Wirkung auf kritische Funktionen und Daten. Nicht jede Änderung verlangt eine vollständige Wiederholung aller Tests. Eine unveränderte Versionsnummer beweist umgekehrt nicht, dass der validierte Zustand unverändert ist.
Einordnung und Geltungsbereich
Der Begriff Revalidierung wird in Unternehmen unterschiedlich verwendet. Entscheidend sind nachvollziehbare Auswirkungsbewertung, erforderliche Prüfungen und Freigabe, nicht die Bezeichnung des Dokumentenpakets.
Quellen: [1]
Anlass und Umfang sollten getrennt entschieden werden
Eine Auswirkungsbewertung beschreibt, welche Annahmen der bisherigen Validierung weiterhin gelten und welche neu geprüft werden müssen. Sie kann vorhandene Nachweise begründet weiterverwenden. Ein pauschales „kein Einfluss“ ohne Bezug zu Funktionen, Daten und Abhängigkeiten ist dagegen schwer überprüfbar.
Der Periodic Review kann Lücken erkennen, ersetzt aber nicht die rechtzeitige Kontrolle einer konkreten Änderung. Umgekehrt führt ein regelmäßiger Review nicht automatisch zu einem vollständigen Neuvalidierungsprojekt. Sein Ergebnis kann auch bestätigen, dass vorhandene Kontrollen und Nachweise weiterhin angemessen sind.
Quellen: [1]
Revalidierung aus Wirkung statt aus einem Schlagwort ableiten
Eine Änderung kann zusätzliche Prüfungen erfordern, ohne eine vollständige Neueinführung auszulösen. Umgekehrt kann eine kleine technische Anpassung erhebliche fachliche Folgen besitzen. Beginnen Sie deshalb mit vorgesehenem Einsatz, betroffenen Daten und möglichen Auswirkungen. Die Bezeichnung „Patch“, „Konfiguration“ oder „Major Release“ ist nur ein Hinweis.
Annex 11 behandelt kontrollierte Änderungen und regelmäßige Bewertung des validierten Zustands. Daraus wird hier kein pauschaler vollständiger jährlicher Revalidierungszyklus abgeleitet. Benötigte Nachweise richten sich nach Änderung, Erkenntnissen und verbleibenden Risiken. Der Begriff Revalidierung sollte im Unternehmen verständlich verwendet werden, statt jede Prüfung gleich zu benennen.
Auch neue Erkenntnisse können Prüfbedarf auslösen: wiederkehrende Fehler, unzureichende Testnachweise, geänderte Nutzung oder ein Befund im Periodic Review. Nicht nur ein neuer Softwarestand verändert die Aussage. Ein unverändertes System, das plötzlich einen anderen Qualitätsprozess steuert, besitzt einen neuen Bewertungsbedarf.
Quellen: [1]
Eine Auslösermatrix mit möglicher Prüfaussage erstellen
Erfassen Sie Anlass, betroffene Funktionen, vorhandene Nachweise und offene Fragen. Entscheiden Sie anschließend, welche Evidenz weiterhin geeignet ist und was ergänzt werden muss. Die Entscheidung sollte erklären, weshalb der gewählte Umfang die Auswirkungen angemessen abdeckt. Eine pauschale Wiederholung aller alten Tests kann relevante neue Risiken trotzdem übersehen.
| Auslöser | Eigene Leitfrage | Möglicher zusätzlicher Nachweis |
|---|---|---|
| Neuer Einsatz | Welche neue Entscheidung wird unterstützt? | Ergänzte Anforderungen und Prozessprüfung |
| Funktionsänderung | Welche kritische Logik verändert sich? | Gezielte Funktions- und Regressionstests |
| Datenmigration | Welche Werte und Beziehungen werden übertragen? | Abgleich und Rekonstruktion |
| Rollenänderung | Welche tatsächlichen Aktionen ändern sich? | Positive und negative Zugriffsfälle |
| Wiederkehrender Fehler | Welche gemeinsame Ursache besteht? | Ursachenbezogene Prüfung und Maßnahmenwirkung |
| Reviewbefund | Welche frühere Aussage ist unzureichend? | Begründete Schließung der konkreten Lücke |
Quellen: [1]
Beispiel: kleine Parameteränderung mit breiter Wirkung
Das Szenario ist konstruiert. Ein gemeinsamer Umrechnungsfaktor wird geändert. Technisch betrifft dies nur eine Konfigurationszeile. Fachlich verwenden mehrere Berichte und Schnittstellen denselben Faktor. Ein Test nur des ersten bekannten Berichts deckt den Einfluss nicht vollständig ab.
Ermitteln Sie abhängige Funktionen und kritische Verwendungen. Verwenden Sie bekannte Werte mit unabhängig hergeleiteten Sollresultaten. Prüfen Sie passende Normal- und Grenzfälle sowie die Empfängerwirkung. Bereits geeignete Nachweise zu unabhängigen Funktionen können weiterverwendet werden. Der Umfang wird über Abhängigkeit begründet, nicht über Zahl der geänderten Zeilen.
Bewerten Sie auch historische Daten, wenn der Änderungsgrund eine Fehlerkorrektur ist. Eine neue richtige Berechnung bestätigt nicht, dass frühere Entscheidungen unbeeinflusst waren. Umfang und notwendige Maßnahmen werden fachlich beurteilt. Eine geplante fachliche Änderung kann anders eingeordnet werden als die Korrektur einer bislang falschen Regel.
| Prüfschritt | Aktion | Erwartete Aussage |
|---|---|---|
| Abhängigkeit | Gemeinsame Verwendung des Faktors erfassen | Betroffener Umfang bekannt |
| Referenzrechnung | Normal- und Grenzwerte berechnen | Unabhängige Sollwerte vorhanden |
| Funktionsprüfung | Betroffene Ausgaben erzeugen | Neue Regel wirkt richtig |
| Regression | Relevante gemeinsame Abläufe prüfen | Keine ungeklärte Nebenwirkung |
| Historie | Frühere Nutzung bewerten | Fehlerkorrektur und geplanter Wechsel unterschieden |
Quellen: [1]
Vorhandene Nachweise begründet weiterverwenden
Prüfen Sie Stand, Umfang und Voraussetzungen alter Tests. Ein Nachweis kann weiterhin passen, wenn Funktion und relevante Umgebung unverändert sind. Eine bloß ähnliche Testbezeichnung genügt nicht. Der Bezug zur aktuellen Anforderung und zum tatsächlichen System muss erkennbar bleiben.
Lieferantennachweise können die Bewertung unterstützen. Prüfen Sie jedoch, ob sie Ihre Version, Konfiguration und Nutzung abdecken. Ein allgemeiner Releasebericht bestätigt nicht jede kundenspezifische Schnittstelle. Fehlende Informationen können zusätzliche eigene Prüfungen oder eine begrenzte Nutzungsentscheidung erforderlich machen.
Dokumentieren Sie bewusst nicht wiederholte Bereiche mit einer passenden Begründung. Das muss keine lange Einzelabhandlung jeder Bildschirmseite sein. Eine verständliche Zuordnung von Änderung, Abhängigkeit und Prüfumfang schafft mehr Nutzen als eine pauschale Formel „keine Auswirkung“ ohne Grundlage.
Quellen: [1]
Regression, Requalifizierung und Prozessprüfung unterscheiden
Ein Infrastrukturwechsel kann geeignete Qualifizierungs- und Betriebsnachweise benötigen. Eine geänderte Fachfunktion kann andere Tests erfordern. Ein Rollenwechsel betrifft Zugriffe. Diese Aufgaben können in einem Projekt zusammenkommen, sollten aber ihre jeweiligen Fragen beantworten. Ein bestandener Serverstart ist keine Bestätigung einer richtigen Ergebnisberechnung.
Wählen Sie kritische End-to-End-Fälle, wenn mehrere Komponenten zusammenspielen. Ergänzen Sie Fehlerwege, sofern Änderungen deren Verhalten beeinflussen können. Eine Regression mit ausschließlich Normaldaten ist möglicherweise schwach, wenn der Eingriff gerade Wiederanlauf oder Ausnahmebehandlung betrifft.
Die Freigabeentscheidung verbindet alle erforderlichen Teilnachweise. Benennen Sie offene Befunde und Nutzungsgrenzen. Ein globaler Status „revalidiert“ ohne bezeichneten Umfang ist wenig aussagekräftig. Die Entscheidung sollte erkennen lassen, welche Verwendung für welchen Stand bestätigt wurde.
Quellen: [1]
Prüfbedarf im laufenden Betrieb erkennen und steuern
Verknüpfen Sie Change Control, Incidentbearbeitung und Periodic Review. Wiederholte Störungen können zeigen, dass eine bisherige Kontrolle nicht ausreicht. Ein Review kann fehlende Nachweise oder veränderte Nutzung erkennen. Die Informationen sollten in einen gemeinsamen Bewertungsweg gelangen, statt isoliert in verschiedenen Listen zu bleiben.
Benennen Sie fachliche und technische Zuständigkeit. Ein Systemverantwortlicher sollte eine Auswirkungsbewertung vorbereiten können und wissen, wann QA oder weitere Expertise benötigt wird. Eine Vorlage kann dabei unterstützen; sie ersetzt nicht die Bewertung. Die Übergabe sollte mit einem konkreten Änderungsfall erprobt werden.
Quellen: [1]
Arbeitsvorlage: zusätzlichen Prüfumfang aus einer Änderung ableiten
Beschreiben Sie zuerst den konkreten Anlass und die betroffene fachliche Wirkung. Im Beispiel ändert sich ein gemeinsam genutzter Faktor. Die Zahl geänderter Zeilen ist nicht der Umfangsmaßstab. Ermitteln Sie abhängige Berechnungen, Berichte und Empfänger sowie mögliche historische Folgen.
Verknüpfen Sie jede benötigte Aussage mit vorhandener oder neuer Evidenz. Ein geeigneter alter Nachweis kann bestehen bleiben, wenn Voraussetzungen und Funktion unverändert sind. Eine neue Abhängigkeit benötigt passende Ergänzung. Die Entscheidung sollte erklären, weshalb der Prüfumfang ausreichend und zugleich auf die tatsächlichen Risiken bezogen ist.
Dokumentieren Sie auch die bewusst nicht wiederholten Bereiche in einer verständlichen Form. Eine pauschale Aussage keine Auswirkung ohne Grundlage ist schwach. Eine vollständige Kopie aller alten Tests kann umgekehrt neue Risiken verfehlen. Die Qualität liegt in der begründeten Zuordnung von Wirkung und Nachweis.
| Bewertungsfeld | Konstruierter Eintrag | Prüfentscheidung |
|---|---|---|
| Anlass | Gemeinsamer Umrechnungsfaktor wird geändert. | Fachliche Wirkung statt technisches Etikett. |
| Abhängigkeit | Zwei Berichte und eine Schnittstelle nutzen den Faktor. | Betroffenen Umfang erfassen. |
| Bestandsevidenz | Unabhängige Funktionen bleiben unverändert. | Geeignete Nachweise begründet weiterverwenden. |
| Neue Prüfung | Referenzwerte und kritische Grenzfälle. | Geänderte Wirkung bestätigen. |
| Regression | Relevante gemeinsame Abläufe. | Ungeklärte Nebenwirkung erkennen. |
| Historie | Änderung ist geplante Vorgabe oder Fehlerkorrektur. | Frühere Nutzung passend bewerten. |
Quellen: [1]
Die nächsten Schritte
- Änderung oder neuen Einsatz konkret beschreiben.
- Bisherige Anforderungen und Nachweise auf Fortgeltung prüfen.
- Zusätzliche Prüfungen nach Auswirkungen festlegen.
- Ergebnisse und Entscheidung zum weiteren Einsatz dokumentieren.
Häufige Fragen zu Revalidierung: Auslöser
Gibt es eine allgemeine jährliche Revalidierungspflicht?
Für computergestützte Systeme lässt sich aus Annex 11 keine pauschale jährliche Komplettwiederholung aller Tests ableiten. Regelmäßige Bewertung und konkrete Änderungsanlässe bleiben zu berücksichtigen.
Quellen: [1]
Kann ein Patch ohne Funktionstest freigegeben werden?
Das hängt von der begründeten Auswirkungsbewertung und verfügbaren Nachweisen ab. Ein pauschaler Verzicht allein wegen der Bezeichnung „Security Patch“ ist nicht belastbar.
Quellen: [1]
Ist ein erfolgreicher Periodic Review eine neue Validierung?
Nicht automatisch. Er bewertet den fortbestehenden Zustand und kann Maßnahmen auslösen, ist aber nicht gleichbedeutend mit der Wiederholung des gesamten Projekts.
Quellen: [1]
Muss ein System jedes Jahr vollständig revalidiert werden?
Eine allgemeine vollständige jährliche Revalidierung wird hier nicht aus Annex 11 abgeleitet. Regelmäßige Bewertung und kontrollierte Änderungen bleiben erforderlich. Zusätzliche Prüfungen richten sich nach Nutzung, Änderungen, Befunden und Risiken. Legen Sie den Umfang nachvollziehbar fest, statt einen Kalendertermin automatisch mit kompletter Testwiederholung gleichzusetzen.
Kann eine Konfigurationsänderung mehr Prüfbedarf auslösen als ein Softwarepatch?
Ja. Entscheidend ist die fachliche Wirkung. Ein einzelner Grenzwert oder gemeinsamer Faktor kann mehrere Qualitätsentscheidungen beeinflussen. Ein Patch kann dagegen einen begrenzten unabhängigen Bereich betreffen. Die Auswirkungsbewertung sollte konkrete Funktionen, Daten und Abhängigkeiten betrachten, nicht nur die technische Bezeichnung der Änderung.
Kann ein Periodic Review zusätzliche Tests auslösen?
Ja, wenn er veränderte Nutzung, unzureichende Evidenz oder relevante Befunde erkennt. Der Umfang wird aus diesen Erkenntnissen abgeleitet. Der Review ist nicht automatisch eine komplette Revalidierung. Er kann gezielte Maßnahmen, ergänzende Nachweise oder eine weitergehende Bewertung erforderlich machen.
Was sollte eine Auswirkungsbewertung ausdrücklich begründen?
Sie sollte betroffene Funktionen, Daten, Abhängigkeiten und mögliche Folgen mit dem gewählten Prüfumfang verbinden. Benennen Sie geeignete vorhandene Evidenz und verbleibende Lücken. Der technische Änderungstitel allein genügt nicht. Ein späterer Reviewer sollte die Entscheidung ohne zusätzliche mündliche Erklärung nachvollziehen können.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)§§ 10 und 11: Änderungen und regelmäßige Bewertung; keine allgemeine vollständige jährliche Testwiederholung. Geltende Fassung laut EudraLex am 14.10.2026; keine universelle Projekt- oder Fristvorgabe.
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Vom offenen Punkt zu einem nachvollziehbaren Vorgehen.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.