Inhaltsverzeichnis
Das Wichtigste vorab
Wann wird ein IT-Incident zu einer GxP-Abweichung oder CAPA?
Ein IT-Incident beschreibt zunächst eine Störung. Ob daraus eine GxP-Abweichung oder CAPA entsteht, hängt von Wirkung, Ursache und dem geltenden Qualitätssystem ab. Prüfen Sie mögliche Folgen für Produkte, Daten und regulierte Abläufe. Die technische Wiederherstellung beendet nicht automatisch die fachliche Bewertung oder die Suche nach wiederkehrenden Ursachen.
Einordnung und Geltungsbereich
Begriffe und Eskalationswege können unternehmensspezifisch sein. Der Beitrag schlägt eine verständliche Trennung der Aufgaben vor; er verlangt nicht, für jede kleine Störung automatisch ein vollständiges CAPA-Verfahren zu eröffnen.
Wieder online ist nicht dasselbe wie fachlich geklärt
Die Ursachenanalyse soll über den unmittelbaren technischen Auslöser hinausgehen, wenn dies für die Fehlerfolge nötig ist. Ein voller Speicher kann beispielsweise durch fehlende Überwachung, ungeklärte Zuständigkeit oder ungeeignete Aufbewahrungskonfiguration begünstigt worden sein. Nur Speicher freizugeben beseitigt nicht zwangsläufig diese Ursachen.
CAPA-Maßnahmen benötigen einen überprüfbaren Zweck. Eine neue SOP oder Schulung ist nicht automatisch wirksam. Legen Sie fest, woran erkannt wird, dass die Ursache beherrscht und ein relevantes Wiederauftreten verhindert oder früher erkannt wird. Verbinden Sie technische Tickets und Qualitätsnachweise über stabile Referenzen.
Drei verbundene, aber unterschiedliche Aufgaben verstehen
Ein IT-Incident behandelt eine technische Störung und die Wiederherstellung eines Dienstes. Eine GxP-Abweichungsbewertung betrachtet mögliche Folgen für Daten, Prozesse und Qualität. CAPA behandelt bewertete Ursachen und geeignete Maßnahmen gegen Wiederholung. Diese Aufgaben können denselben Vorfall betreffen, sind jedoch nicht durch einen einzigen technischen Abschlussstatus erledigt.
Annex 11 behandelt Incidentmanagement einschließlich Bewertung relevanter Vorfälle. Chapter 1 und ICH Q10 liefern den Qualitätsrahmen für Ursachen und Maßnahmen. Die konkrete Umsetzung wird im eigenen QMS festgelegt. Dieser Beitrag schreibt nicht vor, dass jedes kleine technische Ticket zwingend drei separate Dokumente erzeugen muss.
Benennen Sie einen Übergabepunkt zwischen IT und Fachbereich. Der technische Bearbeiter sollte erkennen, wann eine mögliche GxP-Wirkung weitergegeben werden muss. Der Fachbereich benötigt Informationen über betroffene Systeme, Zeitraum und Daten. Unklare Zuständigkeit führt sonst dazu, dass ein wiederhergestellter Dienst als vollständig geklärter Vorfall gilt.
Eine gemeinsame Vorfallakte mit klaren Fragen führen
Verknüpfen Sie technische und fachliche Informationen über eine eindeutige Referenz. Das kann in einem Werkzeug oder über passende Verweise erfolgen. Entscheidend ist, dass die benötigten Aufgaben nicht auseinanderfallen. Ein geschlossenes IT-Ticket kann auf eine noch offene Datenuntersuchung verweisen, statt deren Abschluss zu behaupten.
Dokumentieren Sie Annahmen ausdrücklich. Wenn der genaue Beginn eines Fehlers noch unbekannt ist, beeinflusst dies den Untersuchungsumfang. Eine erfolgreiche Wiederherstellung um 14 Uhr beweist nicht, dass vor 13 Uhr alles korrekt war. Nutzen Sie verfügbare Protokolle und Daten, um die Grenze begründet einzugrenzen.
| Ebene | Leitfrage | Eigenes Arbeitsergebnis |
|---|---|---|
| Technische Störung | Was ist ausgefallen und wie wurde es wiederhergestellt? | Zeitablauf, Ursache soweit bekannt und Betriebsnachweis |
| Datenwirkung | Welche Aufzeichnungen können fehlen oder falsch sein? | Begründete Umfangs- und Inhaltsbewertung |
| Qualitätswirkung | Welche Entscheidungen oder Prozesse sind betroffen? | Zuständige fachliche Beurteilung |
| Ursachenmaßnahme | Weshalb konnte der Vorfall entstehen oder unentdeckt bleiben? | Geeignete Korrektur und Vorbeugung |
| Wirksamkeit | Trägt die Maßnahme im vorgesehenen Betrieb? | Passender Prüf- oder Beobachtungsnachweis |
Beispiel: Schnittstelle wieder online, Ergebnisse fehlen weiterhin
Das Szenario ist konstruiert. Eine Verbindung zwischen LIMS und ERP fällt aus. IT stellt sie nach zwei Stunden wieder her und schließt den technischen Incident. Einige Nachrichten wurden jedoch nicht erneut übertragen. Das ERP besitzt deshalb unvollständige Ergebnisse, obwohl die Verbindung wieder funktioniert.
Die fachliche Untersuchung vergleicht erwartete Vorgänge mit tatsächlicher Übernahme im betroffenen Zeitraum. Fehlende Nachrichten werden über einen geregelten Weg behandelt. Prüfen Sie dabei Wiederholungs- und Doppelverarbeitungsrisiken. Eine pauschale erneute Sendung aller Nachrichten kann neue Fehler erzeugen, wenn einige bereits angekommen waren.
Die Ursachenbewertung untersucht zusätzlich, weshalb der Ausfall oder die fehlende Wiederholung unbemerkt blieb. Eine Maßnahme kann Monitoring, Fehlerbearbeitung oder Wiederanlauflogik betreffen. Der Abschluss sollte technische Wiederherstellung, geklärten Datenumfang und Maßnahmenstatus unterscheiden. Ein einzelner grüner Verbindungstest beendet nicht alle Ebenen.
| Prüffall | Aktion | Erwartete Aussage |
|---|---|---|
| Verbindung | Technischen Kanal prüfen | Dienst erreichbar |
| Vollständigkeit | Erwartete und übernommene Vorgänge vergleichen | Fehlende Daten erkannt |
| Wiederholung | Geregelten Wiederanlauf durchführen | Keine ungeklärte Dopplung |
| Fachliche Verwendung | Betroffenen ERP-Vorgang prüfen | Richtiger Ergebnisstand verwendet |
| Erkennung | Kontrollierten ähnlichen Ausfall testen | Verbesserte Kontrolle reagiert |
Ursachenanalyse über den letzten Bedienfehler hinausführen
Der unmittelbar sichtbare Fehler ist nicht immer die ausreichende Ursache. Eine falsche Eingabe kann durch unklare Maske, fehlende Prüfung oder widersprüchliche Anleitung begünstigt worden sein. Untersuchen Sie die tatsächlichen Bedingungen. Eine pauschale Nachschulung kann ungeeignet sein, wenn das Verfahren selbst praktisch nicht ausführbar ist.
Nutzen Sie geeignete Methoden, deren Tiefe zum Vorfall passt. Eine kleine klar eingegrenzte Störung braucht nicht dieselbe Analyse wie ein systematischer Datenintegritätsbefund. Dokumentieren Sie, welche Hypothesen geprüft wurden und welche Evidenz die Schlussfolgerung trägt. Ein Methodenname allein beweist keine gute Analyse.
Bewerten Sie weitere betroffene Systeme oder Zeiträume, wenn eine gemeinsame Ursache möglich ist. Derselbe fehlerhafte Mappingbaustein kann mehrere Schnittstellen beeinflussen. Eine einzelne reparierte Nachricht beantwortet diese übergreifende Frage nicht. Der Umfang wird aus der Ursache begründet, nicht pauschal maximal oder minimal gesetzt.
Maßnahmen und Wirksamkeitsprüfung auf die Ursache beziehen
Eine Korrektur behandelt den konkreten Fehler. Eine vorbeugende Maßnahme verändert die Bedingung, die Wiederholung ermöglicht hat. Benennen Sie für jede Maßnahme erwartete Wirkung und Nachweis. „SOP aktualisiert“ bestätigt zunächst ein Dokument, nicht die tatsächliche Verbesserung des Datenflusses.
Die Wirksamkeitsprüfung kann geeignete Tests, reale Folgefälle oder eine Kombination verwenden. Ein kontrollierter Fehler zeigt Erkennungsfähigkeit; reale Anwendung zeigt praktische Nutzung. Zeitraum und Umfang richten sich nach Risiko und Ereignishäufigkeit. Eine universelle Beobachtungsdauer wird hier nicht vorgegeben.
Prüfen Sie Nebenwirkungen. Eine neue automatische Wiederholung kann fehlende Daten verhindern, aber doppelte Vorgänge erzeugen. Die Maßnahme muss deshalb im vollständigen relevanten Ablauf betrachtet werden. Gute CAPA schließt eine Ursache, ohne unbemerkt eine neue kritische Lücke zu schaffen.
Betrieb, Trend und Strategie angemessen verbinden
Wiederkehrende Vorfälle können Hinweise für strukturelle Verbesserung liefern. Eine geplante Systemablösung kann Teil der nachhaltigen Lösung sein. Sie ersetzt jedoch nicht die aktuelle Risikobegrenzung und notwendige Datenbewertung. Führen Sie unmittelbare Bearbeitung und langfristige Verbesserung als verbundene, unterscheidbare Ebenen.
Übergeben Sie technische und fachliche Kriterien an die zuständigen Teams. Ein IT-Mitarbeiter sollte wissen, welche Information QA benötigt; QA sollte den technischen Zustand nicht allein aus einem Ticketstatus ableiten. Eine gemeinsame Übung mit einem Schnittstellenfehler kann diese Übergabe praktisch erproben.
Arbeitsvorlage: technische Wiederherstellung und Datenklärung getrennt abschließen
Wählen Sie einen Vorfall mit möglichem Datenverlust. Im Beispiel war eine Schnittstelle zwei Stunden nicht verfügbar. IT kann den Dienst wiederherstellen, während der Fachbereich noch fehlende Ergebnisse untersucht. Beide Aufgaben werden über dieselbe Referenz verbunden, besitzen aber jeweils einen eigenen klaren Abschlussumfang.
Erfassen Sie erwartete und tatsächlich bearbeitete Vorgänge. Vor einer Wiederholung wird geklärt, welche Daten bereits im Ziel liegen. Eine technische Sammelwiederholung kann sonst Dopplungen erzeugen. Der Wiederanlauf sollte den fachlichen Endzustand bestätigen und nicht nur einen grünen Kanalstatus herstellen.
Ein einzelner Vorfall muss nicht automatisch ein großes Transformationsprojekt auslösen. Wiederkehrende oder gemeinsame Ursachen können jedoch strukturelle Verbesserung erfordern. Die Entscheidung sollte unmittelbare Risikobegrenzung und nachhaltigen Betrieb verbinden, ohne notwendige aktuelle Maßnahmen zu verzögern.
| Vorfallfeld | Konstruierter Eintrag | Nachweiszweck |
|---|---|---|
| Technik | Verbindung im bezeichneten Zeitraum ausgefallen. | Betriebszustand und Wiederherstellung. |
| Daten | Erwartete Ergebnisnachrichten im Zeitraum. | Vollständigkeit und Inhalt. |
| Qualität | Bezeichnete Entscheidungen verwenden die Daten. | Mögliche fachliche Wirkung. |
| Ursache | Erkennung oder Wiederanlauf war unzureichend. | Maßnahme trifft tatsächliche Bedingung. |
| Korrektur | Fehlende Vorgänge kontrolliert nachbearbeitet. | Keine ungeklärte Doppelverarbeitung. |
| Wirksamkeit | Ähnlicher Fehlerfall wird geeignet erkannt. | Verbesserung ist praktisch nachgewiesen. |
Die nächsten Schritte
- Störung stabilisieren und betroffenen Umfang sichern.
- GxP-Auswirkungen mit Fachbereich und QA bewerten.
- Ursachen und notwendige Korrektur- oder Vorbeugemaßnahmen festlegen.
- Wirksamkeit prüfen und zusammengehörige Nachweise verknüpfen.
Häufige Fragen zu Incident, Abweichung und CAPA
Kann IT die Produktwirkung allein beurteilen?
Ist eine Schulung immer eine geeignete CAPA?
Muss jeder IT-Incident eine CAPA auslösen?
Nicht pauschal. Bewerten Sie mögliche GxP-Wirkung, Ursache, Wiederholung und vorhandene Verfahren. Eine klar begrenzte Störung kann angemessen ohne umfangreiche CAPA behandelt werden. Ein systematischer oder kritischer Befund kann weitergehende Maßnahmen benötigen. Die Entscheidung sollte nachvollziehbar sein und nicht allein vom Tickettyp abhängen.
Darf IT den Incident schließen, obwohl die Datenuntersuchung noch läuft?
Der technische Abschluss kann getrennt dokumentiert werden, wenn sein Umfang klar ist und die offene fachliche Aufgabe zuverlässig weitergeführt wird. Verknüpfen Sie beide Referenzen und Verantwortliche. Ein geschlossener technischer Status darf nicht den Eindruck erwecken, alle Qualitäts- und Datenfragen seien ebenfalls geklärt.
Warum reicht Nachschulung nicht bei jeder Ursache?
Ein Fehler kann aus unklarer Maske, fehlender Funktion, widersprüchlichem Verfahren oder unzureichender Kapazität entstehen. Schulung behandelt nicht jede dieser Bedingungen. Prüfen Sie die tatsächliche Ursache und erwartete Wirkung der Maßnahme. Ein Seminarabschluss allein bestätigt keine verbesserte Datenverarbeitung.
Wie unterscheiden wir Korrektur und Wirksamkeitsprüfung?
Die Korrektur behebt den konkreten Fehler oder Zustand. Die Wirksamkeitsprüfung betrachtet, ob die bewertete Ursache angemessen beherrscht wird und die Maßnahme im vorgesehenen Betrieb trägt. Beide können unterschiedliche Nachweise und Zeitpunkte besitzen. Ein technisch reparierter Einzelfall bestätigt nicht automatisch die nachhaltige Wirkung.
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)§ 13: Vorfälle und Bewertung; Verknüpfung mit CAPA nach Q10 und Chapter 1. Geltende Fassung laut EudraLex am 14.10.2026; keine universelle Projekt- oder Fristvorgabe.
- Europäische Kommission: EU-GMP Chapter 1, Pharmaceutical Quality SystemQualitätssystem, Ursachenanalyse, CAPA und kontinuierliche Verbesserung.
- EMA / ICH: Q10 Pharmaceutical Quality System, Step 5 (2008)Abschnitt 3.2.2: Ursachenanalyse, CAPA und Bewertung der Wirksamkeit. Konkrete Maßnahmenpläne und Übungen im Beitrag sind eigene methodische Arbeitshilfen.
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)Inspektionsleitlinie zur Datenintegrität; insbesondere elektronische Daten, Übertragung, Zugriff und Review.
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.