Seit Februar 2008 existiert nun mit GAMP5 der neue Leitfaden zur Validierung computergestützter Systeme. Entwickelt und veröffentlicht wurde dieses Werk unter dem Dach der ISPE (International Society of Pharmaceutical Engineers) von der GAMP (Good Automated Manufacturing Practice)-Organisation. Bereits der Vorgänger GAMP4 hatte sich als weltweiter Quasi-Standard etabliert. Nun trägt GAMP5 einigen Entwicklungen der internationalen Behörden und Organisationen der regulierten Industrien Rechnung. Er findet insbesondere in der pharmazeutischen Industrie Anwendung, dürfte aber auch für andere Industrien ein hilfreicher Ratgeber sein.

Änderungen von GAMP4 nach GAMP5

Um Innovationen und Prozessoptimierungen nicht zu behindern, wurde in den vergangenen Jahren ein deutlich stärkerer Fokus auf Know-how und auf eine risikobasierte Vorgehensweise gelegt. Das Ziel ist kontrollierbare Innovation mit effektiven Mitteln bei der Validierung, ohne dabei Qualitätsrisiken einzugehen.
Auch wenn manche Empfehlungen in GAMP4 gar nicht so streng formuliert waren wie sie interpretiert wurden, so ergeben sich durch GAMP5 deutlich höhere Freiheitsgrade bei der Entwicklung und der Validierung von Computersystemen. Unterschiede von GAMP4 zu GAMP5 werden sowohl im grundlegenden Neuaufbau des Dokuments sichtbar, als auch in der sprachlichen Darstellung und in einigen Details der Ausarbeitung.
Die wesentlichen Neuerungen in GAMP5 sind
• Erweiterte Betrachtung des Lebenszyklus sowie Flexibilität und Skalierbarkeit in seiner Auslegung
• Risikobasierte Vorgehensweise über den gesamten Lebenszyklus
• Stärkere Einbindung der Lieferanten (Dokumentation, durchgeführte Tests, Know-how)
• Heutige Systeme sind überwiegend konfigurierbar -> Darstellung mehrerer Lebenszyklusbeispiele

Vorteile eines flexibleren Lebenszyklusmodells

Die flexible und skalierbare Handhabung eines Lebenszyklus-Modells eröffnet die Chance, die Lebenszyklus-Aktivitäten an die tatsächlichen Gegebenheiten anzupassen. Nicht zuletzt zählt dazu auch die Berücksichtigung des einzusetzenden Systems hinsichtlich „Neuheit", Kritikalität und Programmier-/Konfigurationsaufwand.
Sowohl durch skalierbare Lebenszyklus-Aktivitäten als auch generell durch risikobasierte Entscheidungen sowie durch die nachfolgend erwähnte stärkere Einbindung von Lieferanten können Arbeitsaufwand und Aufmerksamkeit genau dort erhöht werden, wo eher Risiken zu erwarten sind. Das reduziert „rein formale" Aktivitäten, wie sie vielleicht mancherorts in der Vergangenheit wegen einer sehr strikten Interpretation des GAMP4 und anderen Veröffentlichungen vorgenommen wurden. So müssen eben z. B. keine bereits durchgeführten Tests wiederholt werden, nur um sie als „IQ-/OQ-Test" zu definieren, sofern dies nicht aufgrund der Testumgebung oder aus anderen Gründen notwendig erscheint.

Vorteile einer durchgehenden Risikobetrachtung

Die Risikobewertung wurde in GAMP4 bereits als eine wichtige Komponente zur Validierung eines computergestützten Systems gesehen. Allerdings herrschte teilweise Unsicherheit, in welcher Form und von wem diese durchzuführen sei. In GAMP5 gewinnt sie zusätzliche Bedeutung als Risikomanagement-Prozess, der über den gesamten Lebenszyklus hinweg betrachtet werden soll. Bei dem nun „Quality Risk Management" genannten Prozess steht keine Methode im Fokus der Darstellung, sondern in erster Linie Produkt- und Prozessverständnis als Basis für risikobasierte Entscheidungen. Die Gesamtverantwortlichkeit dieses Prozesses liegt beim Geschäftsprozesseigner, der Lieferant kann in geeigneter Weise mit technischen Informationen und möglichen Fehlfunktionen bei der Risikobewertung des Systems mitwirken.

Stärkere Einbindung der Lieferantenaktivitäten

Insbesondere die stärkere Einbindung der Lieferantenaktivitäten eröffnet für beide Seiten Einsparungspotentiale. Bereits vom Lieferanten durchgeführte und natürlich ordentlich dokumentierte Tests können vom Anlagenbetreiber als ausreichende „Verifizierung", wie GAMP5 es nennt, akzeptiert werden. Hierbei kann der Lieferant seine gewohnte Dokumentationsmethodik einsetzen. Die Bestimmung des Testumfangs sollte allerdings von beiden Seiten gemeinsam erfolgen, unter Berücksichtigung von technischen sowie qualitätskritischen Aspekten. Auch bei der Inbetriebnahme und späteren Änderungen während des Betriebs kann der Lieferant ein hilfreicher Ansprechpartner sein, da er das Systemverhalten und den Änderungsaufwand meist technisch besser beurteilen kann.

Verschiedene Systemausprägungen

Die Entwicklung eines Computersystems soll auch weiterhin einem definierten Lebenszyklus folgen. GAMP5 zeigt nach wie vor ein V-Modell unterschiedlicher Ausprägung als ein Modell der Guten Praxis, welches für viele Anwendungen anwendbar sein dürfte (vgl. Grafik). Gleichermaßen seien aber auch andere definierte Lebenszyklusmodelle neben dem V-Modell akzeptabel.
Neben Lebenszyklusbeispielen für Systeme verschiedener Softwarekategorien trägt GAMP5 auch der Entwicklung Rechnung, dass Computersysteme heutzutage überwiegend konfigurierbar sind. Ging GAMP4 noch mehr davon aus, dass ein Computersystem sehr stark für den jeweiligen Anwendungsfall programmiert wird, so existieren heute für die meisten Anwendungen vorgefertigte, konfigurierbare Lösungen.
Was rein kundenspezifisch entwickelte Software anbelangt, so spricht GAMP5 im entsprechenden Beispiel von einer Kategorie5-Applikation, also einer kundenspezifisch zugeschnittenen Funktion, die sich in die gesamte zu entwickelnde oder bereits vorhandene Softwareumgebung über entsprechende Schnittstellen integriert. Für diese einzelne Applikation ist ein erhöhter Aufwand für Spezifikation und Test erforderlich, dadurch aber nicht gleichermaßen für das Gesamtsystem. Die Integration in das Gesamtsystem und die Gesamtfunktionalität muss natürlich sichergestellt sein.

Entwicklungsmethoden der Lieferanten

Auch wird in GAMP5 ein Unterschied deutlich zwischen der Entwicklung von Computersystemen einerseits und der Verifizierung von computergestützten Systemen andererseits. Für die Systementwicklung ist der Lieferant verantwortlich, der ein entsprechendes Qualitätssystem etabliert haben muss und vom Anlagenbetreiber entsprechend bewertet werden sollte. Für die Entwicklung seiner Software muss der Lieferant in seiner eigenen Verantwortung eine definierte Methode einsetzen, die am besten zu seiner Arbeitsumgebung passt. Diese Entwicklungsmethode muss nicht unbedingt einem V-Modell folgen, sollte jedoch kontrollierbar und nachvollziehbar sein sowie entsprechende Qualitätskriterien erfüllen. Damit sind sowohl agile (inkrementelle) Entwicklungsmethoden als auch Open-Source-Produkte nicht generell ausgeschlossen. Allerdings kommen Codierungsrichtlinien und Code Reviews je nach Entwicklungsmethode eine noch größere Bedeutung zu.
Der Lebenszyklus computergestützter Systeme hingegen umfasst alle Aktivitäten vom Anfangskonzept bis zur Stilllegung, einschließlich einer eventuell notwendigen Migration der archivierten Daten. Die Validierungsdokumentation für das gesamte computergestützte System kann das Computersystem beinhalten oder losgelöst voneinander durchgeführt werden.

Zusammenfassung - Chance oder Bürde?

In GAMP5 wird sowohl von Industrie-, Lieferanten- als auch Behördenseite eine Chance zu einer effektiveren Entwicklung und Validierung von computergestützten Systemen gesehen. GAMP5 zeigt Möglichkeiten und Empfehlungen auf, ohne dabei Anspruch auf den einzig „wahren" Weg zu erheben. Mit einer definierten Methodik und unter Nutzung des Sachverstandes auf Betreiber- und Lieferantenseite soll eine möglichst effektive Systemerrichtung inklusive Validierung möglich sein, ohne dabei an Qualität und Patientensicherheit einzubüßen.