Im Rahmen der Validierung computergestützter Systeme sind in den
letzten Jahren eine Vielzahl von Regularien und Guidelines veröffentlicht
worden. Die letzten aktuellen Dokumente wurden von der amerikanischen FDA
zum Thema "Elektronische Aufzeichnungen / Elektronische
Unterschriften" bzw. von der Industrie mit dem GAMP 4
veröffentlicht. Ebenso wie die FDA, die mit den "Guides for
Inspection" ihren Inspektoren Interpretationsrichtlinien an die Hand
gibt, gibt auch die PIC/S (Pharmaceutical Inspection Co-operation Scheme)
den Inspektoren der Mitglieder in Form von PIC/S Guidances solche
Interpretationsrichtlinien an die Hand. Die Interpretationsgrundlagen sind
hier der EU-GMP-Leitfaden und insbesondere der Annex 11 "Computerised
Systems".
Im September 2003 ist die PIC/S Guidance "Good Practices for
computerised Systems in regulated "GXP" Environments" in
Kraft getreten, welche sich primär zwar an die Behördeninspektoren
wendet, natürlich aber auch der Pharmaindustrie und ihren Lieferanten den
Stand von Wissen und Technik aufzeigt. Deutlich ist zu erkennen, dass man
mit dieser Guidance das Rad nicht erneut erfinden wollte, sondern auch
durch Referenzierung auf aktuelle Dokumente, z.B. den GAMP 4 und den 21
CFR Part 11, den aktuellen Stand von Wissen und Technik hat einfliesen
lassen.
Die Guidance ist in die 3 Abschnitte
- Preamble
- Implementation of Systems
- System Operations / Inspection / References
aufgegliedert, wobei insbesondere der 3. Teil interessant ist, enthält
er doch für die Inspektoren Checklisten und Aide Memoires, die im Rahmen
von Inspektionen verwendet werden können.
Im Rahmen der Computervalidierungskonferenz 2004 war der PIC/S Guidance
und dessen Interpretationen durch Vertreter der deutschen
Überwachungsbehörden auch das maßgebende Dokument. Mitglieder der
deutschen Expertenfachgruppe "computergestützte Systeme"
zeigten die Anwendbarkeit dieses Dokuments an verschiedensten Teilaspekten
der Validierung computergestützter Systeme. Vertreter aus der
Pharmaindustrie kommentierte die Guidance und ihre Anwendbarkeit aus
Industriesicht. Deutlich wurde dabei, dass insbesondere die Themen
Risikoanalyse / Risikomanagement bzw. Änderungsmanagement (Change
management) mittlerweile in den Regularien, aber auch in der täglichen
Praxis, eine dominierende Stellung eingenommen haben.
Während die großen Linien bei der Validierung computergestützter
Systeme mittlerweile industrieweit bekannt sind und auch gelebt werden
(als Standard sein hier insbesondere der GAMP 4 genannt), ergeben sich
doch bei einer Vielzahl von Detailaspekten nach wie vor Unsicherheiten bei
der Anwendung der Regularien. Im Rahmen der Konferenz fand zusätzlich
eine Podiumsdiskussion statt, wo eine Vielzahl solcher Fragestellungen
diskutiert wurden.
Nachfolgende deshalb hier einige der aufgeworfenen Fragen und die
Antworten der Behörden- und Industrievertreter:
In welchen Abständen müssen Systeme revalidiert werden?
Generell sind konkrete Abstände regulatorisch nicht definiert, wobei
ein Zeitraum von 5 Jahren als definitiv zu lange betrachtet wird. Die
Festlegung sollte in unternehmerischer Eigenverantwortung erfolgen,
insbesondere unter Berücksichtigung des Änderungsmanagements
(Change-Managements). Hier empfiehlt sich ein jährliches Assessment, z.B.
im Rahmen der durchzuführenden Selbstinspektionen, bei dem die
Änderungen nochmals bewertet werden (viele kleine Änderungen, die pro
einzelner Änderung keinen Revalidierungsbedarf ergeben, können in Summe
doch zu einer Revalidierungsnotwendigkeit führen). Im Falle von
größeren Änderungen (genannt wurden hier z.B. SAP-Releasewechsel), ist
eine Revalidierung aber auf jeden Fall durchzuführen.
Muss ein Software-Lieferant in jedem Fall auditiert werden oder würde
in Einzelfällen auch eine Bewertung des Lieferanten mit Fragebogen und
Auswertung durch die Qualitätssicherung ausreichen?
Auf jeden Fall muss ein Software-Lieferant bewertet werden
(Assessment). Dies kann durch ein Audit erfolgen, zwingend erforderlich
ist dies aber nicht. Ob ein Fragebogen ausreichend ist, sollte der
Pharmazeutische Unternehmer von der Kritikalität der Software aber auch
von Erfahrungen mit dem Lieferanten abhängig machen. Wenn Lieferanten
"nur" Personal stellen, welches nach SOPs des Kunden arbeitet,
erübrigt sich ein Audit; ein Schulungsnachweis der eingesetzten Personen
ist aber erforderlich.
Ist es erforderlich, Hard- und Softwarelieferanten formal frei zu
geben?
Eine formale Freigabe des Hard- und Softwarelieferanten ist nicht
notwendig. Es muss aber sichergestellt sein, dass nur bei zuvor bewerteten
und akzeptierten Lieferanten bestellt wird
Welche Detailtiefe wird bei Spezifikationen verlangt?
Spezifikationen definieren immer die gewünschte Qualität. Deshalb
müssen Spezifikationen die Anforderungen so beschreiben, dass diese als
Grundlage der Tests dienen können. Sie müssen somit prüfbar sein, d.h.
dem Kunden sollte es möglich sein zu prüfen, ob er auch erhalten hat,
was er bestellt hat. Auch schon aus kaufmännischen Gründen wird der
Auftraggeber ausreichend genau beschreiben, was er erwartet / bestellt.
Was ist Standardsoftware? Muss Standardsoftware validiert werden?
GAMP 4 definiert Standard-Software als Kategorie 3 und fordert dafür:
Aufzeichnen der Version (und der Konfiguration der Umgebung) und
verifizieren des Verhaltens gegen die Anwenderanforderungen. Dabei ist zu
überprüfen, ob die vom Softwarehersteller geschriebenen Anforderungen
auch mit den eigenen Anforderungen übereinstimmen. Letztendlich muss in
einer Risikobewertung festgehalten werden, welcher Validierungsumfang, der
sicher deutlich geringer als bei Kategorie 4 Software ausfallen wird,
erforderlich ist.
Traceability Matrix – was ist notwendig? Muss ein Endanwender eine
Traceability Matrix besitzen, pflegen und validieren?
Der Anwender muss in der Lage sein zu zeigen, dass seine
Benutzeranforderungen in der Validierung überprüft wurden. Eine
Traceability Matrix ist ein Instrument dieses nachzuvollziehen. Wesentlich
ist hier immer die Nachvollziehbarkeit von Spezifikation – zu
Risikoanalyse – zu Test. Sie sollte wie eine Checkliste angesehen
werden, die prüft, ob die spezifizierten Anforderungen auch umgesetzt
wurden und wo der Beweis zu finden ist.
Welche Bedeutung haben die Guidances der PIC/S?
Die PIC (Pharmaceutical Inspection Convention) wurde 1970 zwischen den
EFTA-Staaten als Abkommen zur gegenseitigen Anerkennung von Inspektionen
der Herstellung pharmazeutischer Produkte gegründet. Nach und nach traten
diesem Abkommen auch weitere europäische und außereuropäische Länder
bei. Aufgrund der europäischen Rechtsauslegung war es seit Beginn der
90er Jahre europäischen Ländern nicht mehr möglich, Mitglied zu werden.
Aus diesem Grund wurde dann 1995 die PIC zur PIC/S (Pharmaceutical
Inspection Co-operation Scheme) weiterentwickelt. Die PIC/S ist jetzt kein
Abkommen zwischen Staaten mehr, sondern ein informeller Zusammenschluss
zwischen Inspektionsbehörden zum Zwecke des Informations- und
Erfahrungsaustauschs. Basis der Behördeninspektion ist im wesentlichen
der EG-GMP-Leitfaden und für den Bereich "Computergestützter
Systeme" der Annex 11. Beide sind im wesentlichen Wortgleich mit den
entsprechenden PIC-Dokumenten. Mit der "Good Practice Guidance"
will man den Inspektoren Hintergrundinformation und Empfehlungen für die
Inspektion computergestützter Systeme geben. Es soll den aktuellen Stand
von Wissen und Technik wiederspiegeln und den technischen Fortschritt auch
nicht hemmen. Die Guidence ist für die Pharmaindustrie nicht
verpflichtend, die Erfüllung dieser Forderungen wird aber in der Regel
als ausreichend angesehen. Es ist zu erwarten, dass sich europäische
Inspektoren bei Fragestellungen zur Inspektion computergestützer Systeme
zukünftig sehr eng an die Vorgaben der Guidance halten werden.
