Ein Modellfall: Die Unternehmensführung entscheidet die Anwendung eines Produktes zu erweitern. Das Produkt ist schon lange eingeführt, aber die neue Anwendung würde den Markt auf Medizinprodukte erweitern. Als Folge sieht sich das Unternehmen den Regularien der FDA, der EU und des GAMP4 unterworfen. Seit Jahren erfolgreich am Markt, Merger und Demerger-Aktivitäten und verschiedene IT-Projekte hinter sich, wurden produktionsnahe EDV-Systeme, die eigene Software-Entwicklung, die IT-Prozesse ohne Rücksichtnahme auf diese Vorschriften entwickelt. Und nun muss eine kleine Unternehmenseinheit, welche den neuen Markt mit dem neuen Produkt bedienen soll, »compliant« werden.

Was wird jetzt noch geprüft?
ISO-9000-2000ff zertifiziert ist man, interne QS-Standards, Entwicklungs- und IT-Richtlinien sind gegeben und vielfältig, da man auch international agiert. Aber: was ist für die neue Marktsituation zu beachten? Was verlangen eine ISO 13485, das MPG-Medizin Produkte Gesetz (FRG), die Directive 93/42/EEC, die Directive 98/79/EEC, der 21 CFR Part 11 803/820, oder eine Validierung nach GAMP4? Welche Schritte und Anpassungen sind notwendig, um die FDA-Zulassung für das Produkt zu erhalten? Was wird wohl geprüft werden? Wie soll man vorgehen?

Ist dieses Szenario eine Fiktion?
Nein, alle Unternehmen wollen immer wieder ihre Märkte ausdehnen. Sie betreten mit eingeführten Produkten neue Märkte oder erweitern bestehende Produkte um neue Eigenschaften. Ein Unternehmen hat gewöhnlich die technische und kaufmännische Expertise für dieses Projekt, aber häufig nicht das Wissen in den regulatorischen Anforderungen. Ähnlich verhält es sich, wenn Behörden in Neufassungen der Vorschriften neue Produktgruppen und Hersteller in den Gültigkeitskreis aufnehmen (vgl. die neue AMWHV Arzneimittel- und Wirkstoff- Herstellungs-Verordnung, das 14. AMG Änd. G).

Chemgineering als langjähriger CSV-/ Compliance-Beratungspartner füllt genau diese Lücke. Seit über 10 Jahren berät Chemgineering ihre Kunden in genau diesen Situationen, wie natürlich auch bei Neu-Einführungen von Produkten, Prozessen und IT-Systemen.

Ausschnitt der Prozess-Aktivitäten Matrix (PAM): SAP R/3 ist viel zu komplex, um es als Ganzes zu validieren. Um die cGMP-/Part 11 kritischen Prozesse und Aktivitäten zu identifizieren, wurden in einer Prozess-Aktivitäten-Matrix die Geschäftsprozesse und ihre zugehörigen Aktivitäten über eine Risiko- und Wichtigkeitsbetrachtung sortiert. Basis dieser Aussagen waren das Benutzerrollen- und Berechtigungskonzept und eine RBE-Plus-System-Analyse durch die IBIS-Prof.Thomé AG. Auf diese Weise wurden ca. 75 Prozesse und ca. 110 Aktivitäten identifiziert. Dabei enthält ein Prozess mindestens eine oder mehrere Aktivitäten und eine Aktivität mindestens eine oder mehrere SAP-Transaktionen/-Programme. Gemäss des V-Modells und der definierten Dokumentationsstrukturen wurden die Prozess- (als URS – User Requirement Specification), die Aktivitäten- (als FS – Functional Specification) und die Customizing- und Programmierbeschreibungen (als DS – Software Design Specification) erstellt. Notwendige, in Betrieb befindliche Add-Ons (auch von Drittanbietern) wurden, sofern als GMP-kritisch eingestuft, in die Betrachtungen mit einbezogen.

Angepasstes V-Modell für eine retrospective Validierung: Die Hardware-Specification, der aktuelle Softwarezustand und die wichtigen Veränderungen der Vergangenheit seit der Installation wurden im Erfahrungsbericht dargestellt. Um die Design-Phase mit dem Design-Phase-Exit Report abzuschliessen, wurde für die OQ/PQ-Phase ein Testplan definiert. In diesem wurden Testwerkzeuge, -strategien, -abläufe usw. auf einem generischen Level beschrieben. Die Testdurchführung wurde in einer Test-SOP beschrieben. In einzelnen Testcases wurden die auszuführenden Einzeltests verbindlich mit Input-/Outputdaten, Enter-Click-Beschreibungen festgelegt.

Modellfall und Realität
Was im konkreten Fall geschah: Zunächst wurde Chemgineering beauftragt eine Gap-Analyse zu erstellen. Arbeitsprozesse, das QM-System, die SOP-Strukturen, der Dokumentationsstatus usw. wurden gemäss ISO 13485, 21CFR Part11 820 detailliert überprüft. Als Ergebnis ergab sich eine umfangreiche Liste von »non-compliant« Punkten. D.h. nicht, dass das Unternehmen nicht in der Lage war, qualitativ hochwertige Produkte zu fertigen, sondern, dass die Abläufe nicht dem entsprachen, was ein Auditor erwarten würde: mangelnde oder nicht aktuelle Dokumentation, unsichere Lieferantenqualifizierung, Einsatz nicht validierter Computersysteme und Arbeitsprozesse, nicht konforme Freigabe-Verfahren, Medienbrüche mit »offenen, veränderbaren« Daten u. a. m.

Validierungsprozess bis zum Abschluss der Design-Phase (DQ): Die für die Funktions- (Aktivitätenlevel) und Akzeptanztests (Prozesslevel) notwendigen Daten wurden auf Basis eines definierten Satzes von Testdaten (Material mit Stückliste, Kunden und Lieferanten, Bewegungsdatensituation usw.) auf dem Qualitätssicherungssystem angelegt. Der Fokus lag dabei auf den Bereichen, welche gemäss der Risikoanalyse als cGMP-kritisch eingestuft wurden. Natürlicherweise werden dabei auch andere Bereiche durchgetestet. Da es sich um ein seit Jahren im Echtbetrieb befindliches System handelte, wurde die Testphase in einer OQ/PQ-Testphase zusammengefasst und von unabhängigen Testern ausgeführt. Die Testergebnisse wurden anschliessend von den Key-Usern und/oder Process-Ownern geprüft und freigegeben.

Ordnung schaffen
Nachfolgend wurden die Punkte den Herstellprozessen und IT-Aufgaben zugeordnet. Die Zuordnung zu den Herstellprozessen zielte darauf ab, dass die Arbeits- und Beschaffungsprozesse, die Entwicklung neuer Eigenschaften und das Zulassungsdossier, die notwendigen klinischen Versuche usw. definiert, dokumentiert und die Zulassung beantragt werden konnten. Die IT-Aufgaben sollten eine nachträgliche Validierung der cGMP/ 21 CFR Part 11 relevanten Computersysteme liefern mit Aufbau einer Dokumentationsstruktur mit Validation Master Plan, Validation Projektplan usw., SOPs und Template-Strukturen für die geforderten Dokumente, einer Dokumentationsverwaltung mit digitaler Signatur und des notwendigen Change Managements.

Validierungsprozess bis zum Abschluss des Validierungsabschlussberichts: Die anfängliche Gap-Analyse hatte auch Punkte ergeben, welche Nachbesserungen am SAP R/3-System notwendig machten. Diese Entwicklungen wurden zunächst gemäss des SDLC- und V-Modells getrennt dokumentiert, entwickelt und während OQ-/PQ-Testphase in das Gesamtsystem integriert. Am Ende entsteht so ein valides Gesamtsystem und notwendige Ergänzungen müssen nicht nachträglich eingebracht werden. Um den weiteren, validen Systembetrieb zu garantieren, wurden parallel die notwendigen Betriebs-SOPs entwickelt und in Kraft gesetzt.

SOP-Struktur zum Betrieb eines validen IT-Systems: Wie für ein System im Routine-Betrieb erwartet, ergaben sich aus der Testphase für den Validierungsabschlussbericht keine kritischen und offenen Punkte. Das System konnte so ohne Einschränkungen freigegeben werden. Die Methodik kann mit wenigen Modifikationen auch auf andere IT-Systeme, die beim Kunden im Einsatz sind, adaptiert werden und wurde auch bereits erfolgreich eingesetzt.

System ohne Einschränkungen freigegeben
Wie für ein System im Routine-Betrieb erwartet, ergaben sich aus der Testphase für den Validierungsabschlussbericht keine kritischen und offenen Punkte. Alle während der Tests aufgetretenen Störungen waren sofort begründ- und behebbar. Das System konnte so ohne Einschränkungen freigegeben werden.

Die Methodik kann mit wenigen Modifikationen auch auf andere IT-Systeme, die beim Kunden im Einsatz sind, adaptiert werden und wurde auch bereits erfolgreich eingesetzt. In einem parallelen Projekt wurde auch die IT-Infrastruktur (Rechenzentrum-Betrieb, Server, Netzwerk, Desktop-Services, Operating, Administration, Backup etc.) des Unternehmens einer Qualifizierung unterzogen.

Dr. Thomas Karlewski