Inhaltsverzeichnis
Das Wichtigste vorab
Wann ist ein Review by Exception im GMP-Prozess tragfähig?
Ein Ausnahmereview kann die Bewertung auf relevante Auffälligkeiten konzentrieren, wenn deren zuverlässige Erkennung und vollständige Darstellung nachgewiesen sind. Ein leerer Report ist nur aussagekräftig, wenn Datenzufuhr, Regeln und Ausführung funktionieren. Der Ansatz darf notwendige Datenprüfungen oder eine fachliche Freigabeentscheidung nicht unbemerkt auslassen.
Einordnung und Geltungsbereich
Der Beitrag beschreibt Prüfkriterien für einen solchen Ansatz und keine pauschale behördliche Freigabe. Zulässigkeit und Umfang hängen vom konkreten Prozess, den Daten und den anwendbaren GMP-Anforderungen ab.
Keine Meldung kann auch bedeuten: keine Daten verarbeitet
Prüfen Sie gezielt positive und negative Fälle sowie fehlende Daten. Ein Kontrollbericht sollte zwischen einer erfolgreichen Prüfung ohne Befund und einer nicht ausgeführten beziehungsweise unvollständigen Prüfung unterscheiden können. Sonst erscheinen zwei fachlich gegensätzliche Situationen gleich.
Behandeln Sie Änderungen an Regeln, Datenquellen und Filtern kontrolliert. Schon eine neue Ereigniskategorie kann dazu führen, dass bisher vollständige Ausnahmereports wichtige Vorgänge auslassen. Verantwortliche müssen deshalb wissen, welche Änderungen die Aussage ihres Reviews beeinflussen.
Was eine Ausnahmeliste tatsächlich beweist
Review by Exception konzentriert die Prüfung auf definierte Auffälligkeiten. Ein leerer Report bedeutet nur dann etwas, wenn vollständige relevante Daten ankommen und geeignete Regeln angewandt wurden. Ein ausgefallener Datenfluss, falscher Filter oder nicht berücksichtigter Ereignistyp kann ebenfalls eine leere Liste erzeugen.
Beginnen Sie mit der fachlichen Entscheidung und den dafür relevanten Fehlern. Welche Ereignisse müssen auffallen, welche Normalfälle dürfen zusammengefasst werden und welche Kontrollen bleiben außerhalb des Reports erforderlich? Die Methode ist kein allgemeiner Verzicht auf Review. Ihr Umfang und ihre Grenzen werden risikobasiert beschrieben.
Unterscheiden Sie Regeldefinition, technische Umsetzung und praktische Bewertung. Eine fachlich richtige Regel kann falsch programmiert sein. Ein korrekt erzeugter Report kann von einem Reviewer falsch interpretiert werden. Der Nachweis sollte deshalb alle drei Ebenen angemessen abdecken. Die folgenden Schritte sind eigene methodische Empfehlungen.
Eine Regelmatrix mit Normal- und Fehlerfällen vorbereiten
Beschreiben Sie je Ausnahme ihren Anlass, benötigte Daten, Schwelle und erwartete Aktion. Berücksichtigen Sie fehlende Daten und unbekannte Zustände. Diese sollten nicht automatisch als Normalfall gelten. Ein System, das nur bekannte Fehlercodes meldet, kann neue Ereignistypen unbemerkt auslassen.
Legen Sie fest, welche Vollständigkeitskontrolle die Auswertung begleitet. Das kann etwa erwartete Vorgänge, Datenbereiche oder erfolgreiche Verarbeitungsschritte betreffen. Die passende Methode hängt vom System ab. Der Review sollte erkennen können, ob er eine vollständige Grundlage oder einen technisch leeren Ausschnitt betrachtet.
| Regelbereich | Eigene Ausnahme | Erwartete Reaktion |
|---|---|---|
| Kritischer Wert | Außerhalb definierter Grenze | Fachliche Bewertung vor entsprechender Entscheidung |
| Datenlücke | Erwarteter Vorgang fehlt | Klärung statt Interpretation als Normalfall |
| Änderung | Kritischer Wert nachträglich verändert | Passender Änderungsreview |
| Unbekannter Zustand | Nicht abgebildeter Ereignistyp | Sichtbare Prüfung der Regelabdeckung |
| Auswertungsausfall | Datenzufuhr oder Reportjob scheitert | Kein irreführender Erfolgsstatus |
Beispiel: keine Ausnahmen, weil eine Datenquelle fehlt
Das Szenario ist konstruiert. Ein Report soll auffällige Ergebnisänderungen aus zwei Laborbereichen zeigen. Nach einem Verbindungsfehler liefert Bereich B keine Daten mehr. Der Report zeigt keine Auffälligkeit. Ohne eine Vollständigkeitskontrolle könnte der Reviewer dies als unauffälligen Gesamtbestand interpretieren.
Bereiten Sie bekannte Normal- und Ausnahmeereignisse in beiden Bereichen vor. Prüfen Sie zunächst den vollständigen Lauf. Unterbrechen Sie danach kontrolliert die Zufuhr von B. Die eigene Anforderung verlangt einen erkennbaren unvollständigen Zustand. Der Report darf fehlende Daten nicht stillschweigend als null Ausnahmen bestätigen.
Ergänzen Sie einen neuen Ereignistyp oder einen absichtlich falsch gesetzten Filter. Die Prüfung sollte zeigen, ob die Regelabdeckung eine solche Änderung erkennt. Nach Korrektur werden normale Verarbeitung und Fehlerfälle erneut ausgeführt. Damit wird nicht nur eine leere Liste, sondern die Aussagefähigkeit der Auswertung beurteilt.
| Testfall | Aktion | Erwartete Aussage |
|---|---|---|
| Normalfälle | Bekannte unauffällige Daten verarbeiten | Keine unbegründete Ausnahme |
| Bekannte Ausnahme | Kritische Änderung einbringen | Richtiger Vorgang erscheint |
| Fehlender Bereich | Zufuhr von B unterbrechen | Unvollständigkeit sichtbar |
| Falscher Filter | Kritischen Typ ausschließen | Geeignete Kontrolle erkennt die Lücke |
| Unbekannter Zustand | Neuen Ereignistyp verwenden | Geregelte Klärung statt stiller Ausschluss |
| Wiederanlauf | Quelle wiederherstellen | Vollständiger Bezug und keine ungeklärte Dopplung |
Einführung mit unabhängiger Vergleichsgrundlage
Für die Einführung kann eine begrenzte Vergleichsphase sinnvoll sein. Dabei werden geeignete Fälle sowohl über den bisherigen Reviewweg als auch über die neue Ausnahmelogik betrachtet. Ziel ist, Abdeckung und Fehlalarme zu erkennen. Das ist eine methodische Möglichkeit, keine pauschal vorgeschriebene Dauer oder Anzahl von Parallelreviews.
Wählen Sie die Vergleichsmenge nach relevanten Situationen. Ein Zeitraum ohne kritische Ereignisse sagt wenig über deren Erkennung aus. Ergänzen Sie deshalb kontrollierte Testfälle, die seltene Risiken gezielt abdecken. Dokumentieren Sie, welche Aussage aus realen Daten und welche aus konstruierten Tests folgt.
Prüfen Sie unabhängig hergeleitete Sollausnahmen. Wer denselben Filter in einer zweiten Auswertung kopiert, kann denselben Fehler wiederholen. Eine fachliche Referenzliste oder anders begründete Prüfmethode ist stärker. Die Vergleichsgrundlage sollte zur Komplexität und Kritikalität der Regeln passen.
Reviewer, Befunde und Nachweise organisieren
Eine Ausnahmeliste braucht verständliche Kriterien und einen Untersuchungsweg. Der Reviewer muss betroffenen Vorgang, erforderlichen Kontext und mögliche Folgen erkennen können. Ein roter Code ohne fachliche Bedeutung führt häufig nur zu Weiterleitung oder blindem Bestätigen. Erklären Sie, wann eine Ausnahme akzeptiert, korrigiert oder weiter untersucht wird.
Dokumentieren Sie betrachteten Umfang, Regelstand, Befunde und Entscheidung. Nicht jede Normalzeile braucht eine eigene lange Begründung. Der Review muss jedoch nachvollziehbar zeigen, welche Grundlage betrachtet wurde. Ein pauschaler Vermerk „keine Ausnahmen“ ohne Vollständigkeits- und Regelbezug ist schwach.
Bewerten Sie Fehlalarme und übersehene Fälle. Eine hohe Zahl irrelevanter Meldungen kann praktische Aufmerksamkeit schwächen. Eine Reduktion sollte die kritische Erkennung erhalten. Änderungen an Schwellen oder Filtern benötigen deshalb eine erneute Auswirkungsbewertung und geeignete Prüfungen.
Regeländerungen und laufende Eignung erhalten
Neue Datenfelder, Prozesse oder Systemversionen können die Abdeckung verändern. Verknüpfen Sie solche Änderungen mit dem Ausnahmekatalog. Eine einmal geprüfte Regel bleibt nicht automatisch passend, wenn neue Ereignisse entstehen oder Daten anders interpretiert werden. Verantwortliche für Regelpflege und technische Umsetzung sollten bekannt sein.
Pflegen Sie einen kleinen Referenzbestand mit bekannten Normal-, Fehler- und Ausfallfällen. Er kann die Regression unterstützen. Der Bestand sollte reale Risiken abbilden und bei Bedarf angepasst werden. Ein unveränderter Test nur alter Normalfälle würde neue Lücken möglicherweise nicht erkennen.
Arbeitsvorlage: Ausnahmeregel und Vollständigkeit gemeinsam prüfen
Erstellen Sie eine unabhängige Liste erwarteter Ausnahmen für einen bekannten Testbestand. Enthalten sind Normalfall, kritischer Wert, fehlender Vorgang und unbekannter Zustand. Die Ausnahmelogik wird gegen diese Liste geprüft. Eine zweite Auswertung mit derselben ungeprüften Regel ist keine starke unabhängige Grundlage.
Fügen Sie einen Ausfall der Datenzufuhr hinzu. Dieser sollte als unvollständiger Prüfzustand erkennbar sein, soweit der betrachtete Prozess dies benötigt. Die Aussage keine Ausnahmen darf nicht entstehen, nur weil keine Daten ankamen. Benennen Sie die technische und fachliche Reaktion.
Nach Einführung werden tatsächliche Befunde und übersehene Fälle in die Pflege zurückgeführt. Weniger Meldungen sind nur dann ein Fortschritt, wenn kritische Abdeckung erhalten bleibt. Eine regelbasierte Reduktion braucht daher passende Nachweise und einen zuständigen Änderungsweg.
| Regelfeld | Konstruierter Eintrag | Akzeptanzfrage |
|---|---|---|
| Normalfall | Bekannter unauffälliger Vorgang. | Keine unbegründete Fehlermeldung? |
| Ausnahme | Kritische nachträgliche Wertänderung. | Richtiger Fall erscheint? |
| Datenlücke | Erwarteter Vorgang fehlt. | Fehlende Grundlage wird erkannt? |
| Unbekannt | Neuer relevanter Ereignistyp. | Geregelte Klärung statt stiller Ausschluss? |
| Ausfall | Ein Bereich liefert keine Daten. | Kein irreführender leerer Gesamtbericht? |
| Reviewer | Ausnahme mit benötigtem Kontext. | Passende Untersuchung möglich? |
Negativtest: sechs Wege zu einem scheinbar leeren Report
Prüfen Sie einen leeren Ausnahmereport bewusst in einer kontrollierten Testumgebung. Legen Sie eine bekannte relevante Ausnahme an und verändern Sie anschließend gezielt eine Eingangsbedingung. Ein falscher Zeitraum, fehlende Datenquelle oder unpassender Filter kann ebenfalls zu null Treffern führen. Das Ergebnis darf nicht unbemerkt dieselbe Bedeutung wie ein vollständig geprüfter unauffälliger Bestand erhalten.
Die erwartete Reaktion wird vor der Ausführung festgelegt. Ein fehlender Eingang kann beispielsweise einen erkennbaren Fehlerstatus statt eines gültigen Leerreports verlangen. Diese Regel ist ein methodischer Vorschlag und wird an den eigenen Prozess angepasst. Verändern Sie für solche Tests keine realen Produktionsaufzeichnungen unkontrolliert. Die folgende Matrix hilft, Abdeckung und Betriebsbereitschaft der Prüfung gemeinsam zu bewerten.
| Manipulierter Testeingang | Risiko | Erwartete Prüfaussage |
|---|---|---|
| Quelle fehlt | Keine Daten statt keine Ausnahme | Unvollständiger Lauf erkannt |
| Falscher Zeitraum | Relevantes Ereignis ausgeschlossen | Zeitraumbezug geprüft |
| Filter zu eng | Bekannte Ausnahme verschwindet | Regelabdeckung nachgewiesen |
| Job lief nicht | Alter Report erscheint aktuell | Ausführungsstand erkennbar |
| Berechtigung fehlt | Teilpopulation wird ausgewertet | Zugriffslücke erkannt |
| Format geändert | Ereignis nicht mehr interpretiert | Schemaänderung erkannt |
Positive Kontrollereignisse und Reviewentscheidung verbinden
Ein bekanntes Kontrollereignis kann zeigen, ob ein Prüfweg grundsätzlich funktioniert. Es beweist jedoch nicht automatisch die vollständige Abdeckung aller Regeln und Datenquellen. Kombinieren Sie deshalb Regeltests, Populationabgleich und tatsächliche Reviewerhandlung. Dokumentieren Sie, welche Aussage jeder Nachweis trägt. Ein einzelner erfolgreicher Alarm darf nicht als Beleg für sämtliche möglichen Abweichungen ausgegeben werden.
Der Reviewer unterscheidet gültigen Leerreport, technische Störung, unvollständige Population und fachliche Ausnahme. Jeder Zustand erhält einen klaren Folgeweg. Nach Änderungen an Quelle, Berechtigung, Format oder Regel wird die betroffene Abdeckung erneut bewertet. So wird die Ruhe im Report interpretierbar. Ohne diese Unterscheidung kann gerade ein optisch besonders aufgeräumtes Dashboard einen ungeprüften Zustand verbergen.
Die nächsten Schritte
- Relevante Ausnahmen und Entscheidungszweck definieren.
- Erkennung, Vollständigkeit und Ausfallfälle testen.
- Reviewer, Eskalation und Freigabegrenzen festlegen.
- Regeländerungen kontrollieren und Erkennungsleistung weiter bewerten.
Häufige Fragen zu Review by Exception
Bedeutet ein leerer Report automatisch eine fehlerfreie Charge?
Ist Review by Exception dasselbe wie eine Zufallsstichprobe?
Müssen Reportregeln nach Änderungen geprüft werden?
Kann Review by Exception eine vollständige Datenprüfung ersetzen?
Er kann einen geeigneten Teil des Reviewmodells bilden, wenn Abdeckung, Vollständigkeit und Grenzen nachgewiesen sind. Welche weiteren Prüfungen erforderlich bleiben, richtet sich nach Prozess und Risiken. Ein pauschaler Ersatz sämtlicher fachlicher Bewertung lässt sich daraus nicht ableiten. Beschreiben Sie ausdrücklich, welche Aussage die Ausnahmelogik liefert.
Ist eine Parallelphase immer erforderlich?
Sie kann eine sinnvolle eigene Methode zur Einführung sein, ist aber hier keine universelle Pflicht. Entscheidend ist ein geeigneter Nachweis der Regel- und Datenabdeckung. Kontrollierte Fehlerfälle, unabhängige Vergleiche und passende reale Daten können zusammenwirken. Dauer und Umfang benötigen eine Begründung statt einer beliebigen Standardvorgabe.
Wie vermeiden wir zu viele irrelevante Ausnahmen?
Analysieren Sie deren Ursache und verbessern Sie Regeln oder Darstellung anhand fachlicher Kriterien. Prüfen Sie nach Änderung weiterhin bekannte kritische Fälle. Eine reine Reduktion der Meldungszahl kann wichtige Erkennung verlieren. Ziel ist eine brauchbare Auswahl mit nachgewiesener Abdeckung, nicht eine möglichst kurze Liste.
Welche Informationen braucht ein Reviewer in einer Ausnahmeliste?
Er benötigt betroffenen Vorgang, relevante Daten, Regelgrund und einen geeigneten Zugang zum Kontext. Ein technischer Fehlercode allein kann zu wenig sein. Die Information sollte eine begründete Entscheidung oder Eskalation ermöglichen. Umfang und Schutz richten sich nach Aufgabe und tatsächlichem Prozess.
Wie testen wir, ob ein leerer Report wirklich aussagekräftig ist?
Verwenden Sie kontrollierte Referenzdaten mit bekannten Ausnahmen und prüfen Sie Quelle, Zeitraum, Filter, Jobstand und Berechtigungen. Ein gültiger Leerreport muss von einem unvollständigen oder fehlgeschlagenen Lauf unterscheidbar sein. Führen Sie manipulative Prüffälle in geeigneter Testumgebung durch, nicht unkontrolliert an Produktionsaufzeichnungen.
Belegt ein erkanntes Kontrollereignis die vollständige Reportabdeckung?
Nein. Es zeigt zunächst, dass ein bestimmter Prüfweg funktioniert. Weitere Regeln, Datenquellen und Populationen können andere Fehler enthalten. Verbinden Sie positive Kontrollen mit geeigneten Vollständigkeits- und Regeltests. Die Reviewentscheidung muss den tatsächlich nachgewiesenen Umfang und verbleibende Grenzen erkennen lassen.
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)Geltende Fassung laut EudraLex-Verzeichnis am 14.10.2026. Anwendung, Risiken, Betrieb und Datenlebenszyklus; konkrete Prüfvorschläge sind eigene Ableitungen.
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)Inspektionsleitlinie zur Datenintegrität; insbesondere elektronische Daten, Übertragung, Zugriff und Review.
- FDA: Data Integrity and Compliance With Drug CGMP – Questions and AnswersFinale Guidance, Dezember 2018; keine pauschale Übertragung auf sämtliche GxP-Rechtsbereiche.
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.