menü

validierung computergestützter systeme (csv)


In GAMP 5 ist ein Validierungsansatz nach dem V-Modell beschrieben, in dem jeder Spezifikationsphase eine Verifizierungsphase gegenübergestellt wird. Außerdem werden Kategorien für unterschiedliche Softwaresysteme definiert.

Zwischen Theorie und Praxis bestehen aber meist erhebliche Unterschiede. Meist lassen sich die Phasen nicht so klar gegenüberstellen oder voneinander trennen. Insbesondere OQ und PQ verschmelzen in der Praxis oft zu einer UAT (User Acceptance Tests) Phase. Daher ist darauf zu achten, dass die im V-Modell dargestellten Prozesse effektiv miteinander agieren. Auch lassen sich Systeme meist nicht einheitlich einer einzigen Kategorie zuordnen, da sich ein Computersystem meist aus mehreren Hardware- und Softwarekomponenten zusammensetzt, die unterschiedlich zu bewerten sind.

Für ein kommerziell erhältliches System mit Konfigurationsanteil, wie es bei einem CDS der Fall ist, können sich so die unten angegebenen Validierungsphasen ergeben.


CSV cromingo

Ich kann in allen Phasen unterstützen, beratend oder auch durch Übernahme dieser Phasen mit eigenen Dokumenten. Die Form meiner Unterstützung können wir gemeinsam besprechen.


Planung:


Validierungsplan

  • Anlass und Ziel der Validierung
  • Projektorganisation - Planung und Zuständigkeiten
  • Risiko Management: Systemauswahl und Lieferantenbewertung, GxP-Relevanz des System, Einstufung des Systems in eine GAMP5 Kategorie und Festlegung der daraus resultierenden Validierungsmaßnahmen, Funktionale Risikoanalyse nach FMEA
  • Beschreibung der Phasen des Validierungsverlaufs und Kontrollmaßnahmen während der Betriebsphase
  • Festlegung der zu liefernden Ergebnisse

Anforderungsspezifikation (URS)

  • Phase I: Dokument zur Systemauswahl basierend auf grundlegenden Anforderungen für den beabsichtigten Geschäftszweck (Unterstützte Geräte, Grundsätzliche Funktionen, regulatorische Anforderungen, Unterstützung durch den Hersteller).
  • Phase II: Validierungsdokument: Nach der Systemauswahl, Kenntnis des Systems erforderlich (Schulungsmaßnahmen und eigene Erfahrungen mit dem System, Hinzuziehen von externer Expertise (Hersteller, unabhängige Berater), detaillierte Analyse der Kundenanforderungen, auf denen die gesamte Validierung aufbaut. Die Anforderungen müssen über den gesamten Validierungsablauf nachverfolgt werden können. Man sollte darauf achten, das man zwischen Anforderung und Design unterscheidet. Die Formulierung einer Anforderung sollte eigentlich losgelöst von der Kenntnis eines Produktes formuliert werden können. Dann ist dieses Dokument auch für Software-Upgrades gut wieder verwertbar.

Spezifikationsphase

In der Spezifikationsphase wird bezugnehmend auf die Liste der Anforderungen dokumentiert, wie die Anforderungen im System erfüllt oder konkret umgesetzt werden, dabei kann man drei Phasen unterscheiden:


Functional Specification

  • Bei kommerziell erhältlichen Produkten liegt die Produktspezifikation in der Verantwortung des Herstellers und es sollte dabei auf Herstellerdokumentation zurückgegriffen werden können. Sollte es keine geeignete Dokumentation geben, weil sich die Spezifikationen ggf. aus vielen Einzeldokumenten (mehrere Softwarekomponenten, keine akkumulierte Erfassung der Spezifikationen über aufeinanderfolgende Versionen der Software) zusammensetzt, kann es Sinn machen, diese in einem kompakten Kundendokument zusammenzufassen mit jeweiliger Bezugnahme auf die Einzeldokumentation.

Configuration Specification

  • Hier definieren Sie die für Ihre Geschäftszwecke erforderliche Konfiguration der Anwendung in Anlehnung an Ihre Anforderungen (z.B. Audit Trail Einstellungen, Elektronische Unterschrift, Benutzerverwaltung, Berechtigungskonzept)

Design Specification

  • Hier legen Sie das Design der technischen Infrastruktur für Ihr System fest, also Rechnerhardware, Software, Netzwerk, Datensicherungskonzept, aber auch Berechtigungen im Netzwerk. Diese Phase ist letztlich die Grundlage und Vorgabe zur Installation des Systems.

Design Review

  • Abgeschlossen wird diese Phase durch ein Design Review, in dem eine Auflistung und Gegenüberstellung sämtlicher Spezifikationen zusammengetragen und mit dem Projekt Team begutachtet wird.

Nach Abschluss dieser Phasen, sollte das System aufgesetzt und die Testfälle entwickelt werden können (Tal-Punkt im V-Modell). Für den Beginn der Testphase sollte ein Testplan erstellt werden, der Ablauf und Strategie der Testphase aufzeigt. Basierend auf einer Risikoanalyse unter Berücksichtigung der Gefahr für Mensch, Produkt und Daten sollten Maßnahmen in Form von Testfällen, Verfahren, technische Kontrollen oder Mitarbeiterqualifizierung festgelegt werden. Meist wird man dabei auch geschäftsrelevante Risiken berücksichtigen. Sämtliche Testfälle werden im Testplan bereits spezifiziert.


Verifizierungsphase

Installation Qualification

  • Überprüfung ob die technische Infrastruktur des Systems gemäß Plan aufgesetzt wurde. Diese Phase bildet somit das Gegenstück zur Design Specification.

Operational Qualification

  • Überprüfung der Funktionen des Systems. Bei einem Kategorie 3 Produkt kann hier auf Herstellertests zurückgegriffen oder verwiesen werden. Es wird die reine Funktionalität überprüft ohne Berücksichtigung des beabsichtigen regulatorischen und geschäftlichen Anwendungszwecks.

Anmerkung: Der Hersteller bietet für die IQ/OQ-Phase oft standardisierte und automatisierte Verfahren an. Es liegt in der Verantwortung des Kunden, diese zu bewerten und ggf. durch geeignete eigene Tests zu ergänzen, um den vollen Umfang der Anforderungen und Spezifikationen zu überprüfen. Dieses erfolgt in der nächsten Phase, die oft als Performance Qualification bezeichnet wird. Mittlerweile verwendet man auch oft den Begriff UAT für User Acceptance Tests, da bei diesen nur schwer einzelnen Phasen unterschieden werden können.


Performance Qualification /User Acceptance Tests

  • Implementierung/Überprüfung der Configuration Specification als ersten Testfall
  • Überprüfung und/oder Kontrolle der User Requirements durch geeignete Maßnahmen, basierend auf dem identifizierten Risiko für Mensch, Produkt, Daten und ökonomische Aspekte.

Abschluss der Validierung und Freigabe des Systems:


Traceability Matrix

  • Nachverfolgung sämtlicher URS-Punkte über die Spezifikationsphase und Verifizierungsphase. Sicherstellung, dass jede URS während des Validierungsverlaufs beachtet, bewertet, umgesetzt und je nach Risikoeinstufung verifiziert wurde. Angabe von Maßnahmen oder Kontrollen, die getroffen wurden.

Validierungsbericht

  • Zusammenfassung und Bewertung der Validierung. Zusammenstellung sämtlicher zu liefernder Ergebnisse. Angaben zu Abweichungen und Maßnahmen, die diesbezüglich getroffen wurden. Angabe von Folgemaßnahmen. Freigabe des Systems für den operativen Einsatz.