FAQ - Computergestützte Systeme

Wie sieht die Herangehensweise an ein IT-System oder an einen Computergestützten Prozess bei ei-ner Inspektion aus?

Die Inspektion kann systemorientiert oder prozessorientiert sein.  Bei Einstieg in die Validierung eines CGS wird üblicherweise mit dem Validierungsplan und/oder dem Validierungsbericht begonnen.  Eine prozessorientierte Inspektion zielt auf jene Teile des Herstellprozesses, der von einem CS gestützt wird. So kann ausgehend vom Prozess die Validierung aufgerollt werden und überprüft werden, ob das CGS eine GMP Regeln verletzt bzw. ob der Prozess als vertrauenswürdig zu beurteilen ist.

Was sind die relevanten gesetzlichen Anforderungen und welche Verbindlichkeit hat der GAMP Guide? Woran kann man sich bei der Validierung eines Computergestützten Systems orientieren?

Grundsätzlich ist gemäß nationaler Gesetze die Validierung der Computergestützten Systeme vorgeschrieben (AMG, AMBO), ohne dass nähere Vorgaben über konkrete Anforderungen gestellt sind. Etwas konkreter, aber immer noch sehr grob, sind Anforderungen an Computergestützte Systeme im EU GMP Guide Annex 11 formuliert.  Wesentlich konkreter sind die Erwartungen eines Inspektors an ein Computergestütztes System im PIC/S Guide über “Computerized Systems in GxP” beschrieben (www.picscheme.org).  Diese Leitlinie kann daher für den Inspizierten als gute Orientierung empfohlen werden. Die GAMP-Leitlinie ist eine Leitlinie, wie eine Validierung im GxP-Umfeld durchgeführt werden kann, sie ist jedoch nicht verbindlich; nach GAMP wird daher auch nicht inspiziert. Die GAMP Leitlinie wurde allerdings von Industrievertretern unter Mitarbeit europäischer und amerikanischer Behörden erstellt, sodass sie als Leitlinie zur Umsetzung einer Validierung empfehlenswert ist.

Was ist der PIC/S Guide und wo kann ich ihn erhalten?

Der PIC/S Guide beinhaltet u.a. konkrete Forderungen an eine Validierung aus Inspektionssicht. Der Guide beinhaltet auch Vorgaben an die Inspektorate, wie eine Inspektion durchgeführt werden soll und welche Schwerpunkte gesetzt werden können. Das Dokument kann unter www.picscheme.org gratis bezogen werden.

Wie sollen wir unser System validieren?

Eine Antwort darauf kann und darf ein Inspektorat nicht geben.  Ein Inspektor darf nicht als Berater auftreten.  Rechtsunterworfene müssen sich das Wissen für eine Validierung selber beschaffen.  Aufgabe eines Inspektors ist es, die Situation in einem Betrieb gegen die rechtlichen Vorgaben zu prüfen.

Wie sollen wir unser altes Computergestütztes System (legacy system) handhaben?

Für das System sollte eine Basislinie geschaffen werden. Dazu muss das System nachdokumentiert werden. Das heißt, es sollten ein Erfahrungsbericht mit dem System und Anwender­spezifi­kationen - zumindest grob - erstellt werden. Auf Grundlage der Nachdokumentation sollte die Evaluierung des Systems erfolgen (von Validierung kann man retrospektiv genau genommen nicht sprechen). Nach Abschluss der Evaluierung sollte das Change Management etabliert werden, um das System valide zu halten. Ein Shut Down eines Altsystems ist bei entsprechender Kenntnis des Risikos von vornherein nicht erforderlich.  Ein System, das jedoch mangels Dokumentation und Risikoeinschätzung als Black Box zu betrachten ist, ist im Regelfall nicht als vertrauenswürdig und daher nicht als validierbar zu beurteilen.

Wie sollen wir unseren Prozess validieren, wenn wir ein fremdes Datensystems für GMP-relevante Tätigkeiten verwenden?

GMP Relevanz eines Systems und Validierungs­pflicht ist dann gegeben, wenn ein Herstellungsschritt mittels Computersystem gestützt wird und wenn eine GMP-Regel betroffen ist.  Dies ist unabhängig davon, wer für das Computersystem / die Software zuständig ist.

Der Prozess sollte analysiert und die GMP-relevanten Bereiche sollten identifiziert werden. Schnittstellen sollten bekannt und definiert sein, eine Risikobe­trachtung sollte durchführt werden. Die Prozess­schritte sollten validiert werden, auch dann, wenn ein außerhalb der eigenen Organisationseinheit liegendes (Krankenhaus-)system oder SAP-System im Prozess Verwendung findet. Krankenhaussysteme oder SAP-Systeme sollten daher nicht als Black Box betrachtet werden. Die Validierungstiefe ist dem Risiko und der Komplexität der Arbeitsschritte anzupassen (z.B. werden einfache Gewichtsbe­rechnungen mittels SAP keiner besonders tief­gründigen Validierung bedürfen).

Welche Anforderungen sollen wir an einen Softwarelieferanten stellen?

Er sollte zumindest ein dokumentiertes Qualitäts­sicherungssystem haben, das seine Beurteilung bei einem Lieferantenaudit zulässt (siehe dazu den PIC/S Guide). Eine Life Cycle Dokumentation darf erwartet werden. Eventuell können einschlägige Normen, die im PIC/S Guide angeführt sind oder z.B. ISO 15504 von Bedeutung sein.

Wie oft ist ein Softwarelieferant zu auditieren?

Zumindest zu Beginn einer Kooperation sollte sich der Auftraggeber Klarheit darüber verschaffen, ob der Zulieferer die Anforderungen des GxP-Umfeldes kennt/versteht bzw ggf in der Lage ist, sein Qualitäts­sicherungssystem danach auszurichten. Bei einer bestehenden Kooperation sollten Lieferantenaudits anlassbezogen durchgeführt werden; ein starrer Zeitraum, zB jährlich, erscheint nicht zweckmäßig. Bedeutend ist auch die einschlägige Qualifikation des Lieferantenauditors.

Wann spricht man von einer COT-Software und was sind die Anforderungen?

Software von der Stange ist eine COT Software. Bei entsprechend weiter Verbreitung kann man unterstellen, dass ihr Anwendungsrisiko kalkulierbarer ist, als eine bespoken Software. Wenn die COT Software wie gekauft, ohne Customizing (durch Konfiguration oder Mitimplementierung von Makros) eingesetzt wird, ist ein deutlich geringerer Validierungsaufwand zu erwarten.  Der Validierungs­auf­wand hängt jedoch vom Einsatzgebiet und vom Ergebnis einer Risikoeinschätzung ab.  Siehe GAMP4 bezüglich Software-Kategorisierung.

Wo sollte die LC-Dokumentation aufbewahrt werden?

Sie muss bei einer Inspektion greifbar sein; ob sie vor Ort lagert oder sich beim Zulieferer befindet ist dem Anwender überlassen.  Bei Auslagerung sind vertragliche Regelungen empfehlenswert. Deren Existenz muss dem pharmazeutischen Hersteller bekannt sein und sollte bei der Validierung Berücksichtigung finden.

Wo liegen die Zuständigkeiten bei der Durchführung einer Risikoanalyse? Wie sollte man diese Tätigkeit abgrenzen?

Die Risikoanalyse sollte immer vom Anwender durchgeführt werden. Bei Übertragung der Durchführung einer Risikoanalyse an den Zulieferer muss dieser alle nötigen Informationen bereitgestellt bekommen. Die Form der Zusammenarbeit muss schriftlich definiert sein. Die Plausibilität der Dienstleistung muss gegeben sein.

Wann sollte eine qualifizierte elektronische Signatur angewendet werden, wann ist Zugangskontrolle durch Verwendung von Username/Passwort ausreichend?

Prüfen ob eine handschriftliche Signatur gemäß einer GMP-Regel erforderlich ist; wenn ja, sicherstellen, dass dort, wo Rechtsverbindlichkeit gefordert ist, diese auch erreicht werden kann; ist lediglich die Abbildung/ Nachvollziehbarkeit eines prozessualen Geschehens gefragt, reicht in der Regel die Zugangskontrolle mittels Username/Passwort aus.

Ist die Notwendigkeit der Verwendung FDA-zertifizierter Software gegeben?

Die Zertifizierung einer Software ist keine Forderung der GxP.  Von Bedeutung ist lediglich, ob eine Software / ein computergestütztes System einen Prozess so stützt, dass dies vertrauenswürdig (valide) geschieht.  Die verwendete Software muss qualifiziert sein.
„FDA-zertifizierte Software“ gibt es nicht, da seitens der FDA, wie von jeder anderen Behörde auch, keine Zertifizierungen durchgeführt werden.
Ebensowenig gibt es Software, die von vornherein als „Part 11 Compliant“ bewertet werden kann.
Beide Attribute sind weit verbreitete Irrtümer.

keyboard_arrow_up nach oben