Lilian Hamilton von der schwedischen Überwachungsbehörde gab zunächst einen Überblick über die existierenden GMP-Anforderungen an Computergestützte Systeme. In Europa definiert die 11. Ergänzende Leitlinie zum EG-GMP-Leitfaden Anforderungen an computergestützte Systeme. Außerdem sind Anforderungen in Kapitel 4.9., Anforderungen an die Dokumentation, aufgeführt. Im September 1998 wurde der PIC/S Draft "Recomandations on Implementation, Validation and Operation of Computerised Systems" publiziert. Dieser Draft referiert wiederum auf :

References for Relevant Standards and GMP Guides/Codes

• GAMP Guide Version 3.0 1998
• PDA Technical Report No 18
• Relevant CFR sections
• ISO Standards
• IEEE Publications

Bei der Vorlage des Draft im Dezember 1998 wurde der Draft, der zur Kommentierung an die Industrie gehen sollte, zurückgezogen. Derzeit ist,  durch einen Wechsel in der Leitung der PIC Arbeitsgruppe, Tony Trill von der MCA verantwortlich für die Vorlage eines neuen Drafts. Frau Hamilton stellt dar, daß der neue PIC-Draft zusätzliche Anforderungen an Electronic Signature und Electronic Records enthalten wird.

Als Beispiel für kritische EDV-Systeme nannte Frau Hamilton:

• batch documentation systems
• LIMS
• process applications
• material status control systems

Zwei Forderungen an Computer-Systeme stellte sie besonders in den Mittelpunkt " Sicherheit", d.h. u.a. physikalische Sicherheit, Zugriffskontrolle usw. sowie" Handhabung und Instandhaltung" insbesondere (Change Control, Configurations Management, Systembeschreibungen etc.).Im folgenden führte Sie die bei MPA - Inspektionen am häufigsten gefundenen Abweichungen auf:

Inspection findings

• No validation performed
• No system description
• System description not complete or updated
• Irrelevant software installed
• Temperature in computer room too high
• Cables not labelled
• Passwords not changed regularly
• No self inspections
• Diskettes not stored or handled properly
• Emergency plan eight years old and not updated
• QC/QA not involved in validation
• Not testet if data can be restored
• Routines in computer room not strict enough
• Protection against fire not sufficient

Den zweiten Beitrag hielt J.A. Norder von der holländischen GMP - Überwachung. Dabei stellte er nochmals die vorhandenen Guides und Guidelines dar. Ausdrücklich erwähnte er GAMP und den PDA-Technical Report No. 18. Diese beiden Industriepapiere sind zwar keine rechtlich zwingenden Vorgaben, aber als Industriestandard anzusehen, da die Papiere ja von Vertretern der pharmazeutischen Industrie erstellt wurden. Außerdem nannte er den britischen " TickIT - Scheme and Guide", der sowohl für Anwender als auch für Lieferanten von EDV-Systemen interessant ist.

Anschließend stellte er dar, welche Dokumente zur Computervalidierung ein Inspektor erwartet. Als erstes Dokument nannte er den Validierungsmasterplan mit allgemeinen Angaben u.a. zu Zeitplan, Verantwortlichkeiten, Verweisen zu SOP`s, Format der Validierungspläne und Protokolle sowie Akzeptanzkriterien. Als spezielle Anforderungen nannte er die fünf GAMP Kategorien, die definieren, wie umfangreich ein spezifisches System zu validieren ist. Dabei werden die Computersysteme in Abhängigkeit von dem Nutzungsgrad und dem Entwicklungsstand des Systems bewertet.

Zum Beispiel erfordert Kategorie 5 "kundenspezifische Systeme", d.h. Systeme, die speziell für einen Kunden geschrieben werden, daß diese Systeme umfassend zu validieren sind und der Softwarehersteller zu auditieren ist.

Nach den zwei Sichtweisen der Inspektoren stellte Herr Dr. Schumacher von der Firma Asta Medica die Industriestatements zu den internationalen Computervalidierungsguidelines vor. Er ging ebenfalls auf den GAMP-Guide ein, der gem. der o.g. Kategorien für die Software der Stufen 4 und 5 ein Audit des Softwarelieferanten fordert. Die Notwendigkeit dieses Audits wurde anschließend ausgiebig von den anwesenden Teilnehmern aus Industrie und Behörden diskutiert. Share Audits , d.h. Gemeinschaftsaudits mehrerer Firmen, können hier sicherlich einen Ausweg darstellen. Herr Dr. Schumacher ging anschließend auf Altsysteme ein. Der PIC/S/-Draft von 1998 fordert hier die nachträgliche Erarbeitung von User Requirements. Herr Dr. Schumacher stellte in Frage, ob diese Forderung einen Nutzen darstellt. Er plädierte daher dafür, daß bei der Überarbeitung des Drafts dieser Punkt entfallen sollte

Aus den GMP-Trends und dem Gold Sheet zitierte er Findings von MCA und FDA-Inspektoren die im folgenden genannt sind:

Observations of FDA and MCA during Inspections

• Missing system specification
• Responsibilities not defined
• User training not documented
• No systematic data backup
• Charts of data flow not existing
• No internal audits of the system by QA unit
• No documentation of deviations

Den letzten Vortrag des ersten Tages hielt Dr. J. Gill von Tanvec, UK, der sich bereits seit 1990 mit Computervalidierung, u.a. als Mitarbeiter von Zeneca und Novo Nordisk, beschäftigt hat. Er stellte die wichtigsten Dokumente aus dem Life Cycle Concept vor:

• System Register
• Vendor - Audit Report
• User System Requirements
• Functional specification
• System Test specification (Test der belegt, daß die Software die functional specification erfüllt)
• Validation Report

Er betonte die Notwendigkeit detaillierter und sehr ausführlicher User System Requirements, da diese die Grundlage für die weiteren Validierungsaktivitäten sind und nur so überprüft werden kann, ob das System auch wirklich das tut, was es soll. Herr Dr. Gill wies darauf hin, daß bei Altsystemen das Life Cycle Concept nur bedingt anzuwenden ist. Ebenfalls stellte er in Frage, ob nachträglich erarbeitete User-Requirements wirklich Nutzen bringen.

Den ersten Vortrag am zweiten Tag hielt Herr Nehls von der Firma Novartis. Er stellte die Techniken, Kriterien und Vorteile von Risikoanalysen dar.

Zum Thema Techniken der Risikoanalyse stellte er dar, daß die Risikogebiete vier Bereiche umfassen:

• Sicherheit
• Umweltbedingungen
• Schutz der EDV Systeme (z.B. Zugriffsschutz, Datenintegrität) und natürlich
• Qualität

Er empfahl bei der Risikoanalyse neben der EDV-Abteilung, den Nutzer (Prozeßexperten), die QA - Abteilung und wenn möglich den Lieferanten des Systems einzubinden. Jedoch ist darauf zu achten, daß das Team nicht mehr als fünf Personen umfaßt. Bei den Kriterien der Risikoanalyse führte er aus, daß zunächst die regulatorischen Anforderungen erfaßt werden müssen, die für eine Funktion existieren z.B. Electronic Signature oder Zugriffsschutz. Zusätzlich muß die Häufigkeit des Gebrauches ( 100 mal am Tag oder 1 mal pro Monat) erfaßt werden. Die "Technischen Risiken" umfassen z. B. Schnittstellen und evtl. ausgeführte Kalkulationen durch das System.

Anschließend müssen die "Anwenderrisiken" (z.B. manuelle Dateneingabe notwendig?) erfaßt werden. Nicht zu vergessen sind die beiden letzten Kriterien für die Risikoanalyse:

1. Konsequenz des Fehlers (Fehlerauswirkung im Sinne der Arzneimittelsicherheit)
2. Buisiness-Risiken, d.h. welche Kosten verursacht ein möglicher Fehler?

Ein weiteres z.Zt. sehr stark diskutiertes Thema wurde von Herrn Dr. Werling von der Firma Propack data vorgetragen:"Elektronic Signature and Electronic Records"

Nach 21 CFR Part 11 gibt es lt. Dr. Werling die im folgenden genannten Anforderungen an Elektronische "Batch-Protokolle". Er stellte diese Anforderungen dar, indem er die GMP-Anforderungen einer möglichen Umsetzung gegenüberstellte:

Requirements of a Batch Protocol According to FDA and EU/PIC