Computer­system­validierung: Ablauf

Computersystemvalidierung (Computer System Validation, CSV) ist ein dokumentierter Prozess, mit dem konsistent und reproduzierbar sichergestellt wird, dass ein Computersystem genau das tut, wofür es entwickelt wurde.

Dieser Artikel ist Teil einer Serie zur Computersystemvalidierung.

Mehr zum Thema Computersystemvalidierung

Ein denkbarer Ansatz, um einen Überblick über die verwendeten Computersysteme zu bekommen und einen ersten Schritt in Richtung Computersystemvalidierung zu gehen, ist die Liste der Verfahren zu prüfen und für jedes Verfahren zu dokumentieren, welche Software dabei zur Anwendung kommt.

Anhand dieser Liste an eingesetzter Software ist dann klar ersichtlich, welches Ausmaß die Computersystemvalidierung annehmen wird. Danach sollte man für jede identifizierte Software die folgenden Schritte durchgehen:

  1. Die Zweckbestimmung und die Anforderungen an die Software werden festgelegt
  2. Es wird entschieden, ob die Software QMS-/GxP-relevant ist
  3. Die Risiken werden identifiziert, bewertet und beherrscht
  4. Die Software wird einer Software-Kategorie zugewiesen
  5. Validierung der Software
  6. Freigabe der Software
  7. Betrieb und Beobachtung der Software
  8. Änderungsmanagement
  9. Software wird außer Betrieb genommen

1. Zweckbestimmung

Die Zweckbestimmung hilft den Kontext der Software zu formulieren.

In welchem Prozess kommt die Software zum Einsatz? Welche Aufgaben übernimmt sie? Gibt es konkrete Anforderungen an die Software aus Gesetzen, Normen, Regularieren, vom Kunden oder aus dem unterstützten Prozess? Welche Anwender gibt es?

2. Relevanz-Prüfung

Aus der Zweckbestimmung ergibt sich dann die QM-relevanz. Falls eine Software nicht QM-relevant ist, muss dies begründet und die Begründung natürlich entsprechend dokumentiert werden. Die Software muss trotzdem in die Liste der Computersysteme aufgenommen, aber nicht validiert werden. Stellt sich heraus, dass Software QM-relevant ist, folgt Punkt 3 - Risiken identifizieren, bewerten und beherrschen.

3. Risikobewertung

Der Einsatz von Risikobewertungen zu frühen Zeitpunkten des Lebenszyklus hilft dabei die Validierungsaufwendungen auf kritische Systeme (hinsichtlich der Patientensicherheit, der Produktqualität oder der Datenintegrität) zu konzentrieren und den Validierungsaufwand zu reduzieren.
In der Risikoanalyse werden die Gefährdungen identifiziert, die Wahrscheinlichkeit und der Schweregrad abgeschätzt und bewertet, sowie Maßnahmen zur Risikominimierung etabliert. Anhand eines Risikomanagementberichts werden die Maßnahmen und das vertretbare Restrisiko dokumentiert.

4. Software-Kategorie

Bei den Software-Kategorien kann es sich um folgende handeln:

  • nicht-konfigurierbare Software: Off-The-Shelf (OTS)-Software, keine Möglichkeit für Konfiguration oder Parametrisierung, frei käuflich und in gleicher Weise bei vielen Nutzern in Anwendung,
  • konfigurierbare Software: Standard-Software, welche durch entsprechende Konfiguration oder Parametrisierung den Anforderungen entsprechend eingeführt wird, wie z. B. Software für Dokumentenlenkung oder Labor-Informations-Management-Systeme
  • eigens erstellte Software / Kunden-Applikationen: Individuelle, neu entwickelte Software entsprechend den definierten Geschäfts-/Benutzeranforderungen. Die Software-Kategorie hat Einfluss auf das Ausmaß der Validierung. Speziell bei eigens erstellter Software muss der ganze Lifecycle der Software dokumentiert werden, was zu einem großen Aufwand führt.

Übrigens: Die angegebenen Software-Kategorien entsprechen den Klassen 3 (nicht-konfigurierbare Software) bis Klasse 5 (eigens erstellte Software) der GAMP5. Die GAMP5 ist das Standardregelwerk für die Validierung computergestützter Systeme in der pharmazeutischen Industrie. Für eine Computersystemvalidierung im Bereich der Medizinprodukte ist es nicht notwendig, sich vollends an die GAMP-Vorgaben zu halten.

5. Validierung

Hierbei spielt die Zweckbestimmung erneut eine große Rolle und definiert den "Scope" der Validierung. Anhand der Software-Kategorie und der Risikobewertung ergibt sich außerdem der Validierungsaufwand und die Funktionen auf die besonderes Augenmerk gelegt werden muss. Im Validierungsplan wird definiert welche Validierungsaktivitäten mit welchen Methoden, von wem, in welchem Zeitraum, wie durchgeführt werden müssen. Hierzu wird eine Testspezifikation erstellt. Deren Ziel ist es eine Grundlage für reproduzierbare Prüfungen zu schaffen. Sie beinhält die Vorgabe für die Dokumentation und die Entscheidungskriterien für die Konformität.

Der Inhalt einer Testspezifikation sollte sein:

  • Testziel
  • Vorbedingungen
  • Durchführung
  • Testdaten
  • erwartete Ergebnisse
  • Pass / Fail Kriterien
  • Dokumentation

6. Freigabe

Nach der Validierung wird ein Validierungsbericht erstellt und die Ergebnisse der Validierung dokumentiert. Bei erfolgreicher Validierung kann die Software freigegeben werden.

7. Betrieb und Beobachtung

Nach der Freigabe der Software muss diese im Betrieb beobachtet werden, Abweichungen müssen festgehalten und analysiert werden.

8. Änderungsmanagement

Neben Abweichungen im Betrieb kann es im Zuge des Änderungsmanagements zu Re-validierungen kommen. Diese können durch Änderungen an der Zweckbestimmung, des Prozesses oder an der Software ausgelöst werden. Dann müssen alle ursprünglichen Betrachtungen revidiert und gegebenenfalls eine neue Bewertung der Software und Re-validierung vorgenommen werden. Unter Änderungen fallen neben den eben erwähnten "großen" Änderungen auch Updates, die Änderung der Betriebsumgebung oder der Konfiguration. Anhand des Change Logs einer Software kann der Aufwand der Re-validierung abgeschätzt und mit einer Rationale argumentiert werden.

9. Außerbetriebnahme

Wenn die Software am Ende ihres Lebenszyklus außer Betrieb genommen wird, muss auf die Speicherung der Daten und etwaige Migrationen geachtet werden. Die Validierungs-Unterlagen müssen entsprechend der normativen Vorgaben archiviert werden.