Inhaltsverzeichnis
Das Wichtigste vorab
Wie wird aus einem Periodic Review eine belastbare Betriebsentscheidung?
Grenzen Sie System und Zeitraum ab, führen Sie die relevanten Betriebsnachweise zusammen und bewerten Sie den heutigen Einsatz gegenüber dem belegten Zustand. Leiten Sie aus Änderungen, Vorfällen und Lücken konkrete Maßnahmen ab. Begründen Sie Intervall und vorgezogene Bewertungsanlässe risikobasiert; Annex 11 gibt kein pauschales Jahresintervall vor. Dokumentieren Sie die Entscheidung über den weiteren Betrieb und deren Bedingungen.
- Der Review beurteilt den heutigen Einsatz anhand der Betriebserfahrung und vorhandener Nachweise.
- Intervall, Umfang und vorgezogene Bewertung brauchen eine nachvollziehbare Begründung.
- Backup, Restore, Rollen und Lieferanteninformationen werden mit ihrem konkreten Systembezug bewertet.
- Maßnahmen benötigen Verantwortliche, Termine und überprüfbare Abschlusskriterien.
Was der Periodic Review beantworten soll
Der Periodic Review führt die Betriebserfahrung eines abgegrenzten computergestützten Systems zu einer aktuellen Entscheidung zusammen. Die Leitfrage lautet: Tragen die vorhandenen Nachweise und Kontrollen den heutigen vorgesehenen Einsatz noch? Dazu gehören auch veränderte Abläufe, Datenwege und Verantwortlichkeiten. Ein früher freigegebener Stand beantwortet diese Frage nicht automatisch.
Dieser Leitfaden behandelt Systeme im EU-GMP-Umfeld der Humanarzneimittelherstellung. Annex 11 Abschnitt 11 nennt die periodische Bewertung des validierten Zustands und der GMP-Konformität. Die Kommission führt am Quellenstand weiterhin die Revision Januar 2011. Für andere GxP-Bereiche ist die jeweilige Grundlage gesondert festzulegen. Part 11 wird anhand der betroffenen FDA-Aufzeichnungen und ihrer zugrunde liegenden Vorschriften eingeordnet.
Trennen Sie Systembewertung, laufende Audit-Trail-Prüfung, Produktqualitätsbericht und technische Wartung. Diese Tätigkeiten können Informationen liefern, haben aber unterschiedliche Gegenstände. Der Review entscheidet auch, ob zusätzliche Prüfungen erforderlich sind; er bedeutet nicht automatisch eine vollständige Wiederholung der Erstvalidierung.
Den Bewertungsauftrag vor der Datensammlung klären
Legen Sie zuerst Systemgrenze, Betrachtungszeitraum und Stichtag fest. Nennen Sie Version, Konfiguration, Standorte, Schnittstellen und die fachlichen Funktionen im Umfang. Eine reine Produktbezeichnung ist zu ungenau, wenn unterschiedliche Module oder Mandanten verschiedene Prozesse unterstützen. Dokumentieren Sie ausdrücklich, welche gemeinsam genutzten Dienste an anderer Stelle bewertet werden.
Empfohlene Aufgabenteilung: Der Prozessverantwortliche beurteilt den fachlichen Einsatz, der Systemverantwortliche führt die Nachweise zusammen, IT erklärt Betrieb und technische Ereignisse. QA bewertet die Qualität der Schlussfolgerung nach dem betrieblichen Verfahren. Lieferanten liefern vereinbarte Informationen. Die Geschäftsführung wird einbezogen, wenn Ressourcen oder grundsätzliche Betriebsentscheidungen erforderlich sind.
Erstellen Sie vorab eine Unterlagenliste mit Verantwortlichem und Termin. Ein fehlender Bericht erhält den Status „nicht verfügbar“ und eine Konsequenz für die Bewertung. Er wird nicht stillschweigend als unauffälliger Befund behandelt. Für ein KMU ist diese klare Vorbereitung häufig wichtiger als eine umfangreiche neue Berichtsvorlage.
Das Intervall begründen und Ereignisse getrennt behandeln
Annex 11 Abschnitt 11 nennt kein festes Jahresintervall. ICH Q9(R1) Abschnitt 4.6 verbindet die Häufigkeit der Risikobewertung mit dem Risikoniveau und berücksichtigt neue Erkenntnisse sowie geplante und ungeplante Ereignisse. Daraus wird hier eine empfohlene Entscheidungsmethode abgeleitet, kein allgemein verbindlicher Kalender.
Beschreiben Sie, wie kritisch die unterstützten Entscheidungen sind, wie häufig sich das System ändert und wie zuverlässig laufende Kontrollen Probleme erkennen. Berücksichtigen Sie außerdem ungeklärte Vorfälle, offene Maßnahmen, Lieferantenwechsel und die Qualität vorhandener Nachweise. Begründen Sie daraus einen Termin für die nächste Gesamtbewertung und benennen Sie den Genehmiger dieser Festlegung.
Ein wesentlicher Vorfall wartet nicht bis zu diesem Termin. Definieren Sie zusätzlich Auslöser für eine vorgezogene Bewertung, etwa ungeklärten Datenverlust oder eine grundlegend veränderte Nutzung. Nach einem ruhigen Zeitraum kann das bisherige Intervall weiterhin angemessen sein; eine Verlängerung benötigt eine neue Begründung. Ein überfälliger Review wird mit Auswirkung und Nachholplan erfasst, nicht rückdatiert.
Welche Nachweise Sie zusammenführen sollten
Die folgende Arbeitsmatrix übersetzt die Bewertungsfrage in überprüfbare Eingänge. Verweisen Sie auf freigegebene oder anderweitig kontrollierte Aufzeichnungen, statt große Dokumentbestände erneut anzuhängen. Für jede Quelle müssen Zeitraum, Systembezug und relevante Einschränkungen erkennbar sein.
Beurteilen Sie die Qualität der Datengrundlage: Sind beispielsweise alle Supportkanäle erfasst, oder zeigt die Liste nur intern eröffnete Tickets? Ein fehlender Eintrag kann tatsächliche Ereignisfreiheit bedeuten, aber auch eine unvollständige Erfassung. Halten Sie diese Unsicherheit im Ergebnis fest.
| Prüffeld | Geeigneter Eingang | Kommentar zur Bewertung |
|---|---|---|
| Nutzung und Stand | Systembeschreibung, Funktionsumfang, Konfiguration | Aktuellen Einsatz mit dem bisher bewerteten Umfang abgleichen |
| Änderungen | Änderungsregister, Releasebewertungen, Tests | Auch die gemeinsame Wirkung einzelner Änderungen betrachten |
| Vorfälle | Störungen, Abweichungen, Ursachen und Maßnahmen | Wiederkehrende Muster und ungeklärte Auswirkungen suchen |
| Rollen und Zugriff | Rollenmodell, Benutzerprüfungen, Administration | Nachweis und fachliche Angemessenheit getrennt beurteilen |
| Daten und Wiederanlauf | Sicherungsberichte, Restore-Nachweise, Archivzugriff | Ergebnis, Umfang und Aktualität müssen zum heutigen System passen |
| Lieferant und Betrieb | Supportstatus, Vereinbarungen, relevante Berichte | Fehlende Transparenz als Lücke bewerten, nicht als Entwarnung |
| Offene Verpflichtungen | Frühere Reviewmaßnahmen, CAPA, Restabweichungen | Erledigung und nachgewiesene Wirksamkeit unterscheiden |
Einzeländerungen und ihre gemeinsame Wirkung bewerten
Ordnen Sie jede relevante Änderung einer Anforderung, einem Datenweg oder einer Betriebsregel zu. Dazu zählen fachliche Konfiguration, Berechtigungen, Infrastruktur, Schnittstellen und geänderte Arbeitsweisen. Untersuchen Sie auch Änderungen, die als rein technisch eingeordnet wurden, wenn neue Informationen diese Einordnung infrage stellen.
Ein illustratives Beispiel: Eine Schnittstelle erhält ein anderes Feldformat, ein nachgelagerter Bericht eine neue Filterregel und ein Fachbereich einen zusätzlichen Freigabeschritt. Jede Änderung kann einzeln geprüft worden sein. Der Review fragt zusätzlich, ob der gesamte Datenweg mit dem heutigen Ablauf weiterhin nachvollziehbar belegt ist. Ob dafür ein weiterer Test nötig ist, ergibt sich aus der Bewertung des Datenwegs.
Vergleichen Sie genehmigten, getesteten und tatsächlich eingesetzten Stand. Fehlt die Verbindung, benennen Sie genau, welche Entscheidung unsicher bleibt. Ein nachträglich aktualisiertes Dokument beseitigt nicht automatisch eine mögliche Lücke im Betrieb. Entscheiden Sie, ob eine Dokumentkorrektur, eine fachliche Bewertung oder eine gezielte erneute Prüfung erforderlich ist.
Vorfälle, Rollen und Lieferanteninformationen zusammen lesen
Gruppieren Sie Vorfälle nach fachlicher Wirkung statt ausschließlich nach technischer Kategorie. Mehrere kleine Schnittstellenstörungen können dieselbe Lücke im Abgleich offenlegen. Unterscheiden Sie vorübergehende Reparatur, Ursachenbehandlung und den Nachweis, dass die Maßnahme im Alltag wirkt. EU-GMP Kapitel 1 verbindet CAPA mit einer Bewertung ihrer Wirksamkeit.
Prüfen Sie bei Rollenänderungen nicht nur ausgeschiedene Benutzer. Relevant sind auch neue Aufgaben, Vertretungen, privilegierte Konten und administrative Dienstleister. Die Frage ist, ob tatsächlicher Zugriff und fachliche Verantwortung noch zusammenpassen. Verwenden Sie vorhandene kontrollierte Rechteprüfungen als Eingang; begründen Sie zusätzliche Stichproben bei Widersprüchen.
Für den Lieferanten betrachten Sie vereinbarte Leistungen und tatsächlich verfügbare Informationen: unterstützte Version, angekündigte Änderungen, relevante Störungen und Ansprechpartner. Ein allgemeines Zertifikat beantwortet keine offene Frage zu Ihrer Konfiguration. Bei fehlenden Informationen dokumentieren Sie den konkreten Einfluss auf Ihre Bewertung und vereinbaren eine beschaffbare Antwort oder eine andere geeignete Absicherung.
Backup, Restore und Archivzugriff fachlich beurteilen
Annex 11 unterscheidet regelmäßige Sicherung, überprüfte Wiederherstellbarkeit und zugängliche aufbewahrte Daten. Ein grünes Sicherungsprotokoll beantwortet für sich genommen nicht, ob der fachliche Prozess nach einem Ausfall fortgesetzt werden kann.
Prüfen Sie den letzten geeigneten Wiederherstellungsnachweis: Welcher Datenbestand wurde wiederhergestellt, in welcher Umgebung und mit welchem Ergebnis? Passt der Nachweis noch zur Architektur? Gehören benötigte Konfigurationen, Berechtigungen, Schlüssel oder angebundene Dienste zum betrachteten Wiederanlauf? Fehlende Bestandteile müssen bewertet werden; sie lassen sich nicht durch das Alter eines erfolgreichen Einzeltests erklären.
Für Archive prüfen Sie beispielhaft das Auffinden und Verstehen vollständiger Aufzeichnungen einschließlich notwendiger Zusammenhänge. Trennen Sie dabei Rücksicherung für den Betrieb von langfristiger Aufbewahrung. Planen Sie praktische Prüfungen kontrolliert, mit geeigneten Testdaten und Schutz der produktiven Umgebung. Im Review kann auf vorhandene belastbare Prüfungen verwiesen werden; ihre Eignung bleibt zu begründen.
Quellen: [1]
Illustratives Beispiel: Aus Beobachtungen werden Entscheidungen
Beispiel, keine Kundenhistorie: Ein Labor nutzt ein LIMS mit Geräteanbindung und elektronischen Genehmigungen. Seit der letzten Bewertung wurden Rollen und die Übertragung eines Ergebnistyps geändert. Eine Störung wiederholte sich; der letzte Restore-Nachweis stammt von einer früheren Architektur. Die Matrix zeigt Entscheidungsvorschläge für diese angenommenen Befunde.
Sie legt keine allgemeine Kritikalität oder Frist fest. Die zuständigen Personen müssen die Auswirkungen auf Ergebnisse, Aufzeichnungen und bereits getroffene Qualitätsentscheidungen bewerten. Ein Reviewbericht darf Unsicherheit sichtbar lassen, muss aber die weitere Entscheidung und gegebenenfalls den bis dahin zulässigen Betrieb klären.
| Beobachtung im Beispiel | Empfohlene Entscheidung | Woran die Erledigung erkennbar wird |
|---|---|---|
| Neue Ergebnisübertragung ohne eindeutigen Testbezug | Betroffenen Datenweg und bereits übertragene Daten bewerten | Begründete Auswirkungsbewertung und passende ergänzende Prüfung |
| Wiederkehrende Störung trotz geschlossenem Ticket | Ursache und bisherige Maßnahme erneut untersuchen | Nachweisbares Wirksamkeitskriterium über angemessene Beobachtung |
| Nicht mehr benötigtes privilegiertes Konto | Zugriff und mögliche Nutzung unverzüglich prüfen | Kontrollierte Bereinigung und dokumentierte Folgebewertung |
| Restore belegt nur frühere Architektur | Eignung des Altnachweises klären; erforderlichen Test planen | Wiederanlauf mit dem relevanten heutigen Umfang nachvollziehbar |
| Lieferanteninformation zur Version fehlt | Konkrete Information mit Ansprechpartner anfordern | Antwort bewertet oder alternative Absicherung beschlossen |
| Keine relevante Lücke nach belastbarer Prüfung | Begründeten weiteren Betrieb dokumentieren | Freigegebene Schlussfolgerung und begründeter nächster Termin |
Eine belastbare Schlussfolgerung und Maßnahmen festhalten
Formulieren Sie das Ergebnis für den abgegrenzten Einsatz. Benennen Sie die tragenden Nachweise, offene Unsicherheiten und erforderliche Maßnahmen. Ein pauschales „System ist validiert“ ist als Schlussfolgerung wenig hilfreich, wenn Einschränkungen in Anlagen verborgen bleiben. Machen Sie deutlich, ob und unter welchen Bedingungen der betrachtete Prozess weiterbetrieben werden kann.
Jede Maßnahme erhält einen Verantwortlichen, einen begründeten Termin und einen überprüfbaren Abschlussmaßstab. Ordnen Sie außerdem zu, wer das Ergebnis akzeptiert. Bei einer wesentlichen Lücke sind gegebenenfalls sofortige betriebliche Schutzmaßnahmen oder eine Einschränkung der Nutzung zu entscheiden. Die entsprechende fachliche Entscheidung folgt dem Qualitätssystem und darf nicht durch die bloße Freigabe des Reviewdokuments ersetzt werden.
Ein formal abgeschlossener Review kann noch verfolgte Maßnahmen enthalten, sofern deren Bedeutung und Behandlung nachvollziehbar geregelt sind. Übernehmen Sie diese in das zuständige Maßnahmenverfahren und prüfen Sie beim nächsten geeigneten Anlass die Wirksamkeit. Die bloße Wiederholung derselben offenen Liste zeigt keinen Fortschritt.
Checkliste für Vorbereitung, Durchführung und Abschluss
Diese Checkliste eignet sich für den gemeinsamen Termin von Fachbereich, Systemverantwortlichem, IT und QA. Sie soll Entscheidungen sichtbar machen; die Anzahl abgehakter Punkte ist kein Qualitätsmaßstab. Für nicht relevante Prüffelder genügt eine nachvollziehbare Begründung im vereinbarten Verfahren.
Für die laufende Planung empfiehlt sich eine zentrale Übersicht der Systeme mit verantwortlicher Person, nächstem Termin, offenen Maßnahmen und vorgezogenen Bewertungsanlässen. So bleiben auch Systeme sichtbar, bei denen der Review wegen fehlender Unterlagen noch nicht abgeschlossen werden kann.
- Systemgrenze, Betrachtungszeitraum und tatsächlicher Einsatz sind eindeutig benannt.
- Intervall und Auslöser einer vorgezogenen Bewertung sind begründet.
- Änderungen, Vorfälle und frühere Maßnahmen sind vollständig genug für die Entscheidung.
- Rollen, Lieferanteninformationen, Sicherung und Wiederanlauf sind mit passenden Nachweisen bewertet.
- Fehlende Unterlagen und widersprüchliche Ergebnisse bleiben ausdrücklich sichtbar.
- Der weitere Betrieb ist fachlich beurteilt; notwendige Einschränkungen sind entschieden.
- Maßnahmen haben Verantwortliche, Termine und überprüfbare Abschlusskriterien.
- Die Schlussfolgerung und der nächste Termin sind im betrieblichen Verfahren genehmigt.
Häufige Fragen zu Periodic Review
Muss ein Periodic Review jährlich stattfinden?
Annex 11 Abschnitt 11 legt kein allgemeines Jahresintervall fest. Bestimmen und begründen Sie den Termin für Ihr System anhand von Risiko, Änderungen, Vorfällen und der Aussagekraft laufender Kontrollen. Ein intern festgelegtes Jahresintervall bleibt eine betriebliche Vorgabe; es sollte nicht als wörtliche allgemeine Forderung dieses Abschnitts dargestellt werden.
Welche Systeme gehören in den Reviewplan?
Beginnen Sie im hier betrachteten GMP-Bereich mit dem abgegrenzten Systeminventar und den unterstützten GMP-Funktionen. Erfassen Sie auch ausgelagerte Anwendungen und relevante gemeinsame Dienste. Benennen Sie für Überschneidungen einen führenden Nachweis, damit weder Zuständigkeiten verloren gehen noch derselbe Dienst widersprüchlich bewertet wird.
Quellen: [1]
Wer sollte den Review durchführen und genehmigen?
Empfohlen ist eine gemeinsame Bewertung durch Prozessverantwortlichen, Systemverantwortlichen, IT und QA nach den eigenen Zuständigkeiten. Ein Lieferant kann technische Informationen beisteuern. Wer erstellt, bewertet und genehmigt, legt das Qualitätssystem fest. Die fachliche Betriebsentscheidung benötigt Personen mit der passenden Verantwortung, nicht nur Zugang zu einer Berichtsvorlage.
Ersetzt der Review eine erneute Validierung?
Der Review bewertet, welche Nachweise den aktuellen Einsatz tragen und wo neue Arbeit erforderlich ist. Er ersetzt keine tatsächlich benötigte Prüfung. Umgekehrt folgt aus dem Termin allein nicht, dass alle ursprünglichen Tests wiederholt werden müssen. Leiten Sie ergänzende Nachweise aus konkreten Änderungen, Risiken und Erkenntnislücken ab.
Ist eine Audit-Trail-Prüfung dasselbe wie ein Periodic Review?
Nein. Eine Audit-Trail-Prüfung betrachtet einschlägige Aufzeichnungen über Ereignisse und Datenänderungen. Die Systembewertung führt zusätzlich Nutzung, Änderungen, Betriebserfahrung und Nachweisstatus zusammen. Nutzen Sie die Ergebnisse der passenden laufenden Prüfungen als Eingang und bewerten Sie deren Abdeckung, ohne unterschiedliche Prüfaufträge gleichzusetzen.
Quellen: [1]
Was ist bei einem System ohne gemeldete Vorfälle zu tun?
Bewerten Sie zuerst, ob die Erfassung belastbar war. Keine Meldung kann einen stabilen Betrieb zeigen, aber auch fehlende Meldewege. Prüfen Sie anhand geeigneter Quellen, ob Supportfälle, fachliche Abweichungen und relevante technische Ereignisse berücksichtigt wurden. Erst danach lässt sich das Ausbleiben von Vorfällen sinnvoll einordnen.
Muss während jedes Reviews ein Restore ausgeführt werden?
Nicht automatisch. Entscheidend ist, ob die vorhandenen Nachweise die Wiederherstellbarkeit des heutigen Systems ausreichend belegen. Annex 11 behandelt deren Überprüfung und periodische Überwachung. Bewerten Sie Aktualität und Systembezug. Ein zusätzlicher kontrollierter Test kann erforderlich sein, wenn Architekturänderungen oder Lücken die Aussagekraft vorhandener Prüfungen begrenzen.
Quellen: [1]
Genügt bei einer Cloud-Anwendung der Lieferantenbericht?
Der Bericht kann relevante Betriebsinformationen liefern. Prüfen Sie jedoch, welche eigene Konfiguration, Schnittstellen, Rollen und fachlichen Abläufe er tatsächlich abdeckt. Verknüpfen Sie ihn mit Ihren Nachweisen. Eine allgemeine Aussage über die Plattform beantwortet keine ungeklärte Frage zum konkreten vorgesehenen Einsatz.
Quellen: [1]
Darf ein Review mit offenen Maßnahmen abgeschlossen werden?
Das hängt von Bedeutung, Auswirkung und geregelter Behandlung der offenen Punkte ab. Trennen Sie den Abschluss des Berichts von der Entscheidung über den weiteren Betrieb. Eine offene kritische Unsicherheit wird nicht durch einen Termin im Maßnahmenplan unbedenklich. Halten Sie notwendige Schutzmaßnahmen und fachliche Genehmigungen ausdrücklich fest.
Was tun, wenn ein Review überfällig ist?
Erfassen Sie die Abweichung vom eigenen Plan und beurteilen Sie die daraus entstandene Unsicherheit. Priorisieren Sie anhand des aktuellen Systemrisikos, beschaffen Sie die fehlenden Eingänge und vereinbaren Sie einen Nachholplan. Prüfen Sie zusätzlich, ob akute Ereignisse sofortige Maßnahmen erfordern. Rückdatierung schafft keinen Nachweis einer früher erfolgten Bewertung.
Quellen & fachlicher Stand
Quellenstand 6. Oktober 2026. Der Leitfaden betrachtet EU-GMP für Humanarzneimittel. Arbeitsmatrix, Prüffragen und LIMS-Beispiel sind eigene Planungsempfehlungen auf Grundlage der genannten Quellen; sie legen keine allgemeingültigen Fristen oder Freigabeentscheidungen fest.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems
- ICH Q9(R1): Quality Risk Management
- Europäische Kommission: EU-GMP Kapitel 1, Pharmaceutical Quality System
- FDA: Part 11, Electronic Records; Electronic Signatures – Scope and Application
- Europäische Kommission: EudraLex Volume 4 – geltende Dokumente
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Den nächsten Systemreview konkret vorbereiten
Wenn Nachweise, Zuständigkeiten oder offene Maßnahmen nicht zusammenpassen, unterstützt Daniel Herrmann Consulting Sie bei der Abgrenzung und Bewertung. Gemeinsam legen wir fest, welche Informationen für Ihre nächste Entscheidung fehlen.
- IT-GxP-Audit →
Den aktuellen Systemzustand und vorhandene Betriebsnachweise strukturiert untersuchen.
- IT-GxP-Consulting →
Reviewumfang, Maßnahmen und passende ergänzende Nachweise im vereinbarten Umfang bearbeiten.