Experten aus Überwachungsbehörden beantworten Fragen zur Validierung computergestützter Systeme
Melden Sie sich jetzt an für
den kostenlosen GMP-Newsletter
Im Rahmen der Computervalidierungskonferenz 2008 wurden von Behördenvertretern der "Expertenfachgruppe computergestützte Syteme" und Industrievertretern aktuelle Entwicklungen diskutiert. Neben dem Schwerpunkt GAMP 5 wurden auch weitergehende Fragen diskutiert und beantwortet - im Folgenden finden Sie eine Zusammenstellung von Fragen und Antworten von Antworten von Klaus Eichmüller und Karl-Heinz Menges.
Ist es zulässig, mit einer (elektronischen) Unterschrift mehrere elektronische Dokumente zu unterschreiben - z.B. fünf Analysenergebnisse - und diese dann als Gesamtheit mit einer elektronischen Unterschrift zu signieren?
Die AMWHV macht zu dieser Frage keine klare Aussage. "Wird ein System zur automatischen Datenverarbeitung oder -übertragung eingesetzt, so genügt statt der eigenhändigen Unterschrift der jeweils verantwortlichen Personen deren Namenswiedergabe, wenn in geeigneter Weise sichergestellt ist, dass nur befugte Personen die Bestätigung über die ordnungsgemäße Ausführung der jeweiligen Tätigkeiten vornehmen können." (§ 10 Abs. 2) Da es hierzu noch keine Rechtsprechung gibt, bleibt das Restrisiko einer negativen Beweiswürdigung beim Anwender.
Was gehört in eine Systembeschreibung?
Was ist mit dieser Systembeschreibung gemeint (bspw.: Annex 11 [4.1]: Eine ausführliche Beschreibung des Systems sollte erstellt (gegebenenfalls mit Diagrammen) und ständig aktualisiert werden. [4.2] Diese Beschreibung sollte Grundsätze, Zielsetzungen, Sicherheitsmaßnahmen und Einsatzbereich des Systems umfassen und aufzeigen, wie der Computer eingesetzt wird und ob Wechselwirkungen mit anderen Systemen und Verfahren bestehen.).
Wie wäre die Systembeschreibung in die GAMP Nomenklatur einzuordnen (Funktional- und Designspezifikation, URS, etc.)?
Annex 11 4.2 macht eigentlich eine klare Aussage, welche Angaben in einer Systembeschreibung zu machen sind. Es spricht jedoch nichts dagegen, durch weitere Angaben das Dokument zu einem Designdokument zu erweitern, sofern die in Annex 11 geforderten Mindestinformationen enthalten sind. Welche Detaillierungstiefe erforderlich ist, kann nur im Einzelfall entschieden werden.
Ist es zulässig, IQ und OQ in einer Testphase abzuhandeln?
Aus zeitlichen Gründen finden IQ und OQ oftmals an einem Tag statt, bspw. wenn sie durch einen externen Mitarbeiter des Lieferanten durchgeführt werden. In diesen Fällen ist es oft schwer, einen expliziten Abschluss der IQ vorzunehmen.
Ist es dann zulässig, den Erfolg der IQ und OQ zusammen zu bewerten und nicht auf einer klaren Phasentrennung zu bestehen?
Das hängt sehr stark von der Komplexizität des Systems ab. Bei einfacheren Systemen ist es durchaus denkbar, IQ und OQ zu kombinieren. Nur sollte man dann konsequenterweise auch nur ein Dokument und einen Abschlussbericht erstellen.
Muss die URS aktuell gehalten werden? Die spezifizierten Anforderungen werden in der Validierung als die Referenz für die Eignung eines Systems herangezogen. Ist es folglich notwendig, die Anforderungsspezifikation des Systems über den gesamten Lebenszyklus stets aktuell zu halten?
Eine Forderung, stets eine aktuelle, fortgeschriebene Version der URS zur Verfügung stellen zu können, wird nur schwer praktisch umsetzbar sein. Die Frage an die Qualitätssicherung wird eher lauten, ob und wie weit es möglich ist, aus der ursprünglichen URS zusammen mit den Dokumenten des Änderungsmanagements den aktuellen Stand zu ermitteln; es ist sicher empfehlenswert, dies vor einer Inspektion zu evaluieren und gegebenenfalls eine aktuelle Version aus "Ur-URS" und den zwischenzeitlichen Änderungen zu erstellen.
Grenzwertige Systeme: Wie definiere ich grenzwertige Systeme; welche Konsequenzen hat das für die Validierung. Muss ich grenzwertige Systeme nicht validieren bzw. abgespeckt validieren – wie kann man sich eine abgespeckte Validierung vorstellen?
Eine Definition grenzwertiger Systems gibt es naturgemäß nicht. In dem Vortrag wurde versucht darzustellen, dass die GMP-Grenzen und damit die GMP-Pflichtigkeit von betroffenen computergestützten Systemen in der Praxis tatsächlich anders liegen können als manchmal vermutet. Daher ergibt sich für viele Systeme, die in der Praxis bei der Validierung gerne „übersehen“ werden, doch eine Validierungspflicht. Die Validierungsanforderungen „abzuspecken“ ist ein gefährlicher Weg; zielführender ist es zunächst, die GMP-Pflichtigkeit eines Systems zu bewerten und die GMP-pflichtigen Systeme oder Module dann einer Validierung zu unterziehen. Dabei kann durch Einsatz von Risikomanagementmethoden unter Berücksichtigung des Einsatzzweckes des jeweiligen Systems der Umfang der Validierung reduziert werden.
Zusammengestellt von:
Dr. Andreas Mangel
CONCEPT HEIDELBERG