CSV nach GAMP 5 (2. Ausgabe): Weniger Dokumentation, mehr Datenintegrität

Die Computer System Validation hat einen schlechten Ruf: Zu oft steht sie für Stapel von Testskripten, die niemand liest. Die zweite Ausgabe von GAMP 5 räumt damit auf und rückt den eigentlichen Zweck in den Vordergrund, nämlich belastbare Datenintegrität bei angemessenem Aufwand. Der Rahmen ist nicht neu, aber er wird konsequenter zu Ende gedacht.

Risiko steuert den Aufwand

Der Kern bleibt der risikobasierte Ansatz. Massgeblich sind drei Fragen: Was bedeutet ein Fehler für den Patienten, was für die Produktqualität, was für die Integrität der Daten? Fällt die Antwort harmlos aus, wird schlank gearbeitet. Fällt sie es nicht, wird gründlich geprüft. Der typische Fehler in Projekten ist nicht zu wenig Aufwand, sondern gleichmässig verteilter Aufwand.

Kategorisierung und Lieferanten-Leverage

Die Zuordnung in die GAMP-Softwarekategorien entscheidet über den Weg: Infrastruktur (1), nicht konfigurierte Standardsoftware (3), konfigurierte Produkte (4) und kundenspezifische Entwicklung (5). Je weiter oben, desto mehr lässt sich auf die Arbeit des Lieferanten stützen, sofern ein qualifiziertes Assessment das trägt.

• Kategorie bestimmen, bevor getestet wird, nicht danach.
• Lieferantendokumentation bewerten und nutzen, statt sie nachzubauen.
• Testen, was Risiko trägt, nicht, was leicht zu testen ist.

Was die zweite Ausgabe wirklich verändert

Drei Punkte sind neu gewichtet. Iterative und agile Entwicklung wird als Normalfall behandelt statt als Sonderweg. Cloud- und Service-Modelle bekommen eigenen Raum, samt der Frage, was der Anbieter liefert und was in der eigenen Verantwortung bleibt. Und Datenintegrität ist kein Kapitel am Rand mehr, sondern eine Anforderung an das Design. Die FDA verfolgt mit Computer Software Assurance dieselbe Stossrichtung.

Critical Thinking statt Vorlagen

Die wichtigste Neuerung ist kulturell. Verlangt sind mitdenkende Ingenieure, keine Formularausfüller. Ein Testfall, der nur existiert, weil die Vorlage eine Zeile dafür vorsieht, kostet Zeit und belegt nichts. Umgekehrt ist eine knappe, gut begründete Prüfung mehr wert als zwanzig Seiten Nachweis über eine unkritische Funktion. Gefordert ist die Begründung, nicht das Volumen.

Weniger Dokumentation, mehr Datenintegrität: das ist kein Widerspruch, sondern das Ziel.

Nach dem Go-live beginnt der Lebenszyklus

Die Validierung endet nicht mit der PQ. Änderungen laufen über Change Control, der Periodic Review prüft, ob die Annahmen noch stimmen, und Datensicherung samt Wiederherstellung muss nicht behauptet, sondern getestet sein. Auch das Ende gehört dazu: Wird ein System abgelöst, muss geklärt sein, wie die Daten über die Aufbewahrungsfrist lesbar bleiben. Daran scheitern Ablösungen häufiger als an der Migration selbst.