ISPE vollzieht Kehrtwende bei Computervalidierung. Seit März 2008 ist die Version 5 des GAMP-Guides veröffentlicht. Wie bei den Vorgängerversionen war zu erwarten, dass die Anforderungen an die Computervalidierung (CSV) weiter steigen, wurden doch die Restriktionen an das Entwicklungsmodell (V-Modell) von Version zu Version verschärft. Diesmal jedoch hat es die ISPE geschafft, uns zu überraschen, denn der GAMP 5 vollzieht bei vielen bisherigen Anforderungen eine Kehrtwende. Nahezu jede Seite des 360-seitigen Werkes spricht von wirtschaftlicher Validierung, von der Fokussierung auf das Wesentliche.

Beim Durchblättern des GAMP 5 suggerieren uns der Umfang und neue Kapitel wie „Daten-Migration“, „Stilllegung von Systemen“ sowie eine Reihe zusätzlicher Systembetriebs-Themen (O-Anhänge) zunächst ein Mehr an Validierungstätigkeiten. Der Inhalt eines jeden Kapitels fokussiert jedoch konsequent auf die Risiken für die Patientensicherheit, die von dem computerisierten System ausgehen könnten, sowie auf die Nutzung der qualitätssichernden Tätigkeiten des Lieferanten, wie z. B. dessen Systemtests und dessen Dokumentationspflichten.

Betrachten wir im Folgenden die einzelnen Hauptänderungen von GAMP 4 zu GAMP 5:

Risikomanagement vollständig integriert in Entwicklung und Systembetrieb

Der Gedanke, die Validierung ausschließlich auf das Patientenrisiko zu konzentrieren, klang bereits im GAMP 4 an, doch stand dort das Risikokapitel eher separat und war kaum integriert in den gesamten Life-Cycle des Systems. In die Ausgestaltung der Tätigkeiten während des Systembetriebs war die Risikobeobachtung nicht eingeflossen. Im GAMP 5 ist das Risikomanagement nun vollständig integriert – von der Erstellung des Lastenheftes (URS) bis zur Stilllegung des Systems. Risikomanagement reduziert sich nicht mehr allein auf die Risikoanalyse während der Projektierungsphase, es umfasst die Beobachtung möglicher Risiken während der gesamten Nutzungsphase. Werden Risiken während des Systembetriebs erkannt, so sollte das System so verändert werden, dass diese Risiken reduziert werden. Dieses Vorgehen wurde bereits 2001 in der ISO 14971 „Anwendung des Risikomanagements auf Medizinprodukte“ beschrieben, die für die medizintechnische Industrie gilt. Dieser Ansatz wurde mit der ICH Q9 auch für die Pharmaindustrie aufgegriffen.

Aufgaben auf Lieferanten verlagern

Galt bis GAMP 4 der Lieferant / die Entwicklerfirma von Software-Produkten eher als „Auszubildende(r)“, so möchte der GAMP 5 dem Lieferanten soviel wie möglich an Qualifizierungs-/ Validierungstätigkeiten überlassen. Zitat: „Maximieren Sie den Lieferanteneinfluss, nutzen Sie Lieferantendokumente, vermeiden Sie Doppelarbeit“.

Natürlich muss das regulierte Unternehmen weiterhin qualitätssichernde Tätigkeiten durchführen. Diese sollten jedoch ein striktes Lieferanten-Management inklusive Lieferantenbeurteilung und Auditierung in den Vordergrund stellen und weniger die Durchführung der Test- und Dokumentationstätigkeiten für das einzelne System im eigenen Unternehmen. Das Kundenunternehmen darf sich bei qualifizierten, freigegebenen Lieferanten aus der Kontrolle des Entwicklungsprozesses und auch aus den Tests zurückziehen. Baut das regulierte Unternehmen intensiv auf den Qualifizierungstätigkeiten seiner Lieferanten auf, so bedeutet das zwingend die Beobachtung dieser Lieferanten über den gesamten Lebenszyklus der Produkte. Lediglich ein Lieferantenaudit zu Projektbeginn durchzuführen, wie es derzeit oft vorkommt, genügt dazu nicht!

Selbst das Kapitel „Daten-Migration“ ordnet GAMP 5 den Tätigkeiten zu, die auf Lieferanten übertragbar sind. Ein Kapitel zu diesem Thema war im Übrigen dringend nötig, denn fehlerhafte Migrationsprogramme, unvollständige Prüfungen der Daten nach Datenübertragung auf das neue System, sowie unzureichende Dokumentation kennzeichnen in aktuellen Projekten – immer noch – diese qualitätskritische Phase.

Zulässigkeit vieler Entwicklungsmodelle

Galt das V-Modell bisher als Standard für die Entwicklung von computerisierten Systemen für die regulierte Industrie, so ist es im GAMP 5 nur noch ein Modell unter vielen. Nun ist jedes Life-Cycle-Modell zulässig, mit dem Qualität in das System hinein entwickelt wird (Quality by Design). Damit sind agile Software-Entwicklungsmodelle erlaubt. Agil bedeutet, es muss nicht zuerst eine URS fertig gestellt und unterschrieben sein, bevor die Funktionale Spezifikation (FS) und dann die Design Spezifikation (DS) erstellt wird. Es ist zulässig, eine URS rudimentär zu erstellen und diese später zu verfeinern, währenddessen bereits mit der Entwicklung des Systems begonnen werden kann. GAMP 5 empfiehlt uns sogar, Dokumente lange im Draft-Status, d.h. leicht änderbar zu halten. Im V-Modell war es nicht zulässig, eine FS zu erstellen geschweige denn freizugeben, bevor nicht die URS freigegeben war.

GAMP 5 ist damit bei aktuellen Software-Entwicklungsmodellen angekommen, die sich in den letzten Jahren verbreitet haben und durch die Objektorientierung beeinflusst wurden. Das Entwicklungsmodell ist nun zweitrangig, wenn der Lieferant und die Qualität des Ergebnisses ausreichend kontrolliert werden. Aufwand zugeschnitten Die Software-Kategorien existierten auch in den Vorgängerversionen des GAMP 5, doch war nie so ganz klar, wie denn der Aufwand damit maßgeschneidert werden kann. Im Grunde lief die Validierung dann doch eher auf den Gesamtumfang, also auf Kategorie 5 hinaus. GAMP 5 trägt nun der Tatsache Rechnung, dass ein Großteil der im GxP-Umfeld eingesetzten Systeme eher einer der Kategorien 3 (Standard) oder 4 (Customizing) entsprechen und heute nur selten Individualentwicklungen der Kategorie 5 benötigt werden. Wenn Individualentwicklungen nötig sind, so sind dies eher Ergänzungen zu Kat. 4-Systemen (z. B. bei SAP), als komplette Neuentwicklungen. GAMP 5 gibt uns damit exakter vor, was wir im Einzelnen per Kategorie an Dokumentation (Spezifikation bis Test) erstellen sollten, oder beim Lieferanten einfordern müssen. Die Kategorie 2 wurde gestrichen und in Kategorie 1 befinden sich jetzt auch Infrastruktur- Werkzeuge, wie z. B. Monitoring-Tools oder Viren- Scanner. Werkzeuge der ITInfrastruktur werden als weit entfernt von Patientenrisiken eingestuft.

Eingebettete Systeme

Ist die Computertechnik z. B. in Produktionsanlagen oder Laborsysteme integriert, d.h. handelt es sich um Systeme, die ohne Programmierung kaum funktionsfähig sind, so sollte Computervalidierung nicht eigens, sondern in die Qualifizierung dieser Anlagen integriert durchgeführt werden.

Offenheit gegenüber Open-Source

Heute ist eine Vielzahl von Open-Source-Produkten verfügbar. Beispielsweise sorgen die 20.000 Entwickler, die an dem weitverbreiteten Open-Source-Content-Management-System TYPO3 beteiligt sind, für eine bessere Qualitätssicherung als viele Lieferanten, die für die regulierte Industrie Software entwickeln. Regulierte Unternehmen können diese Produkte einsetzen, wenn sie sich vom Qualitätsvorgehen überzeugt haben. Das bedeutet intensive Lieferantenbeobachtung.

Testen

Hieß es im GAMP 4, dass „Hardcopies“ zur Demonstration der Testergebnisse genutzt werden sollten und falls diese nicht erstellt werden, so sollten ein Tester und ein Zeuge das Ergebnis dokumentieren, so empfiehlt GAMP 5, Hardcopies nur bei hoch risikobehafteten Funktionen zu erstellen. Wird auf Hardcopies verzichtet, so seien keine zwei Unterschriften nötig, da dies unwirtschaftlich sei. Tests sollen nicht unnötig dupliziert werden, insbesondere dann nicht, wenn der Lieferant ein gutes Testmanagement nachweist.

Aufgewertet wurde der Inhalt des Teststrategie-Dokuments, in dem unter Beachtung der Ergebnisse der Risikobewertung beschrieben werden soll, warum bestimmte Tests nur rudimentär, andere detailliert durchgeführt werden. Es soll begründet werden, warum bestimmte Funktionen so und nicht anders getestet werden. Damit wird der Testphilosophie / -strategie / -planung höhere Bedeutung zugemessen als den eigenen Tests, die ja vom Lieferanten durchgeführt werden können. Das Testphilosophie- Dokument liegt in der Verantwortung des regulierten Unternehmens. Es ist von seinem Strategiegedanken her dem Validierungsplan vergleichbar.

Fazit

GAMP 5 geht in der Reduktion einiger Validierungstätigkeiten so weit, dass es einem klassischen QA-Verantwortlichen, einem Inspektor oder einem Auditor für computergestützte Systeme bei Lohn- und Wirkstoffherstellern schwer fallen könnte, diesen geänderten CSV-Ansatz mitzutragen. Da aber Vertreter der FDA und der Inspektionsbehörden weiterer Länder am GAMP 5 mitgearbeitet haben, ist die Sorge hinsichtlich der Verteidigbarkeit unbegründet.

GAMP 5 geht einen großen Schritt in die pragmatische Richtung, die Unternehmen anderer Industrien bereits seit längerem favorisieren. Werden Risikomanagement und die qualitätssichernden Tätigkeiten des Lieferanten gezielt genutzt, so muss Auslagerung keinen Qualitätsverlust für das Endprodukt bedeuten. Vielfältige Erfahrungen aus anderen Branchen, z. B. aus der Automobilindustrie zeigen, dass mit steigendem Anteil von Outsourcing die Lieferanten immer enger überwacht werden müssen. Fassen wir zusammen: Wenn Qualifizierungstätigkeiten der Lieferanten stärker genutzt werden sollen, so kann das regulierte Unternehmen das Entwicklungsmodell (früher VModell) einem Lieferanten nicht vorschreiben. Ein nachhaltiges Lieferantenmanagement kann dem regulierten Unternehmen eine Menge Detailarbeit ersparen, es muss aber stärker in Strategiethemen wie Risikomanagement und Testphilosophie investieren. Das regulierte Unternehmen sollte sich nicht mehr im Einzeltest „verlieren“, da dies der Lieferant übernehmen kann. Werden neben diesen Aktivitäten auch die Software-Kategorien stärker einbezogen, so kann das regulierte Unternehmen den eigenen Aufwand für die Qualifizierung / Validierung auf Wesentliches konzentrieren.

Kontakt:
Friederike Gottschalk
Chemgineering GmbH, Stuttgart
Tel.: 0711/781943-40
Fax: 0711/781943-50
friederike.gottschalk@chemgineering.com
www.chemgineering.com