Softwarevalidierung im pharmazeutischen Umfeld – Validierungsansatz gemäß GAMP 5
Nachdem die Entscheidung gefällt ist, eine neue GMP-kritische Software anzuschaffen, ist es Zeit, sich um das Thema Validierung zu kümmern. Die rechtlichen Regelungen enthalten wenig genaue und praxisrelevante Hinweise, wie eine Validierung durchzuführen ist. Daraus ergibt sich, dass eine Validierung grundsätzlich mit verschiedenen Methoden durchgeführt werden kann. Einige technische Richtlinien konkretisieren aber die gesetzlichen Regelungen und helfen Ihnen bei der praktischen Durchführung der Validierungstätigkeiten. Für die Validierung von Computerisierten Systemen im pharmazeutischen Produktionsumfeld wird hierbei häufig auf den pragmatischen Ansatz des GAMP-5-Leitfadens „A Risk-Based Approach to Compliant GxP Computerized Systems“ der ISPE zurückgegriffen. Die grundlegende Vorgehensweise bei der Softwarevalidierung gemäß GAMP-5-Leitfaden wird in diesem Artikel beschrieben.
Grundsätzliche Vorgehensweise – Das V-Modell
Der Leitfaden der Guten Herstellungspraxis Teil I definiert die Begriffe Validierung und Qualifizierung folgendermaßen:
- Validierung
„Beweisführung in Übereinstimmung mit den Grundsätzen der Guten Herstellungspraxis, dass Verfahren, Prozesse, Ausrüstungsgegenstände, Materialien, Arbeitsgänge oder Systeme tatsächlich zu den erwarteten Ergebnissen führen.“ - Qualifizierung
„Beweisführung, dass Ausrüstungsgegenstände einwandfrei arbeiten und tatsächlich zu den erwarteten Ergebnissen führen. Der Begriff Validierung wird manchmal um das Konzept der Qualifizierung erweitert.“
Der hier vorgestellte Ansatz basiert auf dem V-Modell, wie es unter anderem auch im GAMP-5-Leitfaden „A Risk-Based Approach to Compliant GxP Computerized Systems“ beschrieben wird. Grundsätzlich wird bei diesem Validierungsansatz die Spezifikation, die ein- oder mehrstufig sein kann (z. B. Anwenderspezifikation, Funktionelle Spezifikation und Konfigurations-Spezifikation), mit entsprechenden Qualifikationsmaßnahmen überprüft.
Die Validierung soll die Eignung des Systems für den vorgesehenen Einsatzzweck nachweisen und die Einhaltung der anzuwendenden Vorschriften belegen. Durch den Qualifizierungsteil (im rechten Teil des unten abgebildeten Diagramms) wird in diesem Ansatz überprüft, ob die implementierte Software auch wie geplant installiert ist und wie geplant arbeitet.
Das Vorgehen innerhalb des V-Modells lässt sich in verschiedene Phasen unterteilen. Auf der linken Seite des V-Modells finden Sie die Spezifizierungsphase, auf der rechten Seite die Qualifizierungsphase. Die Durchführung aller Validierungsaktivitäten muss im Rahmen eines abgestimmten Validierungsplans im Voraus geplant werden, der auf dem Validierungsmasterplan des Unternehmens basiert.
Validierungsplanung
Die Softwarevalidierung eines Computerisierten Systems beginnt mit der Planung der Validierungsaktivitäten. Diese Planung wird im Validierungsplan festgehalten, er enthält neben der übergeordneten Validierungsstrategie für das neue System in seiner betrieblichen Umgebung auch die verantwortlichen Parteien und deren Aufgaben. Firmenübergreifend sollte die Validierungsplanung zusätzlich auf die Übereinstimmung mit dem übergeordneten Masterdokument (Validierungsmasterplan) geprüft werden. Die Validierungsplanung wird meistens schon vor der Beauftragung eines Softwareherstellers durchgeführt.
Spezifizierungsphase
In der Spezifizierungsphase werden die Anforderungen an die neu zu beschaffende Software definiert. Die Spezifizierungsphase beginnt in den meisten Fällen mit der Erstellung der Anwenderspezifikation (auch Anwender-Lastenheft genannt). Die Anwender-Spezifikation beschreibt die Anforderungen, die das System im produktiven Betrieb erfüllen soll. Im Anschluss an die Anwenderspezifikation wird häufig ein Pflichtenheft, im Regelfall durch den Software-Lieferanten, erstellt. Im Pflichtenheft (auch Funktionelle Spezifikation genannt) werden die durch die Anwenderspezifikation definierten Anforderungen auf funktionaler Ebene präzisiert. Es wird spezifiziert, mit welchen Grundfunktionen die in der Anwenderspezifikation beschriebenen Prozesse abgebildet werden sollen.
Bei individuell programmierter Software wird noch ein weiterer Schritt in das V-Modell eingefügt, die Designspezifikation. In der Designspezifikation werden detaillierte Vorgaben für die Programmierung der Softwarelösung gemacht. Bei vielen Softwarelösungen handelt es sich um Standardsoftware, die schon ohne zusätzliche Softwareentwicklung alle notwendigen Funktionen zur Erfüllung der Anwenderspezifikation enthält. Hier wird nur durch eine Konfiguration eingestellt, welche Funktionen genutzt werden. Bei konfigurierter Software wird im Rahmen der Validierung eine Konfigurations-Spezifikation erstellt, die die zwischen Unternehmen und Softwarelieferanten vereinbarte Konfiguration der Software festgelegt. Ein Beispiel für Standard-Software, die nur konfiguriert werden muss, ist D4InfoNet.
Die Spezifikationen bilden die Grundlage für die späteren Testfälle im Rahmen der Qualifizierung.
Die Spezifizierungsphase vor der Implementierung einer nur durch Konfiguration anzupassenden Software kann in drei Teilbereiche unterteilt werden:
- Anwenderspezifikation
Englisch User Requirement Specification (URS), nachfolgend nur als „URS“ bezeichnet. Spezifikation des Kunden, die die erwarteten Leistungsmerkmale der einzusetzenden Softwarelösung beschreibt. Die URS ist Basis für die Leistungsqualifizierung. - Funktionelle Spezifikation
Beschreibung der notwendigen Funktionen, um die URS des Anwenders zu erfüllen. Die Konfigurations-Spezifikation ist die Basis für die Tests im Rahmen der Funktionsqualifizierung. - Konfigurations-Spezifikation
Beschreibung der Konfiguration der geplanten Softwarelösung. Die Konfigurations-Spezifikation bildet die Grundlage für die durchzuführenden Tests im Rahmen der Installationsqualifizierung.
Implementierungsphase
In der Implementierungsphase wird die Software durch das Unternehmen oder den Softwarehersteller installiert und entsprechend der Konfigurations-Spezifikation konfiguriert. Bei individuell programmierter Software wird diese entsprechend der Designspezifikation realisiert und anschließend installiert. Neben dem spezifizierten Vorgehen nimmt das Änderungsmanagement ab jetzt einen großen Stellenwert ein. Hin und wieder kommt es vor, dass von den festgelegten Spezifikationen abgewichen werden muss oder dass Änderungen an den vorher festgelegten Spezifikationen notwendig sind. Alle Änderungen und Abweichungen von den ursprünglichen Spezifikationen müssen in den Validierungsansatz einfließen sowie dokumentiert und die Auswirkungen bewertet werden.
Qualifizierungsphase
Bei den Qualifizierungsaktivitäten kann man die folgenden drei Teilbereiche unterscheiden:
- Installationsqualifizierung
Englisch Installation Qualification (IQ), nachfolgend nur als „IQ“ bezeichnet.
In diesem Teil der Qualifikation wird die spezifikationskonforme Installation der spezifischen Software überprüft. - Funktionsqualifizierung
Englisch Operational Qualification (OQ), nachfolgend nur als „OQ“ bezeichnet.
Im Rahmen der OQ werden die vorab definierten Funktionen der Software-Lösung mit verschiedenen Testfällen überprüft. Im Rahmen der Tests wird außerdem die Reaktion auf bewusste Fehleingaben überprüft. - Leistungsqualifizierung
Englisch Performance Qualification (PQ), nachfolgend nur als „PQ“ bezeichnet.
Bei der PQ wird überprüft, ob die installierte Version der Software den spezifizierten Anforderungen des Unternehmens entspricht.
Die Planung der Aktivitäten in der Qualifizierungsphase wird meistens in einem Qualifizierungsplan festgehalten. In der Qualifizierungsphase werden mit einem risikobasierten Ansatz die in der Spezifikationsphase aufgestellten Spezifikationen überprüft.
Da es in den meisten Fällen nicht praktikabel ist, jede einzelne Funktion einer Software mit Tests zu überprüfen, ist der normale Ansatz, zuerst eine Risikobewertung der einzelnen Funktionen vorzunehmen. Durch die Risikobewertung werden die kritischen Funktionen identifiziert, die einen Einfluss auf die Arzneimittelqualität haben können. Diese Funktionen werden dann in der Qualifizierungsphase mit darauf abgestimmten Tests überprüft.
- Während der IQ wird dokumentiert, dass die Software gemäß den Vorgaben der Konfigurations-Spezifikation installiert wurde.
- Im Rahmen der OQ werden die Funktionen aus der Funktionellen Spezifikation mit angepassten Testfällen, deren Umfang auf der Risikobewertung basiert, überprüft.
- Durch die PQ wird geprüft, ob die Anforderungen aus der URS im realen Betrieb eingehalten werden.
Falls die Software vom Softwarehersteller oder einem Systemhaus installiert wird, das über ausreichend Erfahrungen mit GMP-Kunden verfügt, können die IQ und die OQ auch auf diese Dienstleister ausgelagert werden.
Am Ende der Qualifizierungsphase werden die Testergebnisse der durchgeführten Tests in einem Qualifizierungsbericht, der sich auf den Qualifizierungsplan bezieht, zusammengefasst und der erfolgreiche Abschluss der Qualifizierungsphase bestätigt.
Validierungsbericht
Nach Abschluss der Spezifizierungs-, Implementierungs- und Qualifizierungsphase werden alle Validierungsaktivitäten in einem Validierungsbericht zusammengefasst. Der Validierungsbericht nimmt Bezug auf die in der Validierungsplanung aufgeführten Kriterien und bewertet deren regelungskonforme Erfüllung. Der Validierungsbericht ist das zentrale Dokument, um den validierten Zustand des Computerisierten Systems zu bestätigen.
Change control – Nach der Validierung ist vor der Validierung
Der validierte Zustand der im regulierten Umfeld eingesetzten Softwarelösung muss im produktiven Betrieb durchgehend aufrecht erhalten werden. Um den regulatorischen Anforderungen gerecht zu werden, muss jede Änderung am validierten Zustand kontrolliert ablaufen. Vom Änderungsantrag über die Risikobewertung bis hin zur Durchführung der Änderung und Ergebniskontrolle ist ein formaler Change-Control-Prozess einzuhalten. Idealerweise wird der Change-Prozess mit einer geeigneten Software, wie beispielsweise D4GenericForms abgebildet, da eine papierbasierte Dokumentation meistens recht aufwendig ist.