Executive Summary

Zielsetzung dieser Diplomarbeit ist es, einen Leitfaden zur retrospektiven Validierung einer IT Infrastruktur anzubieten. Ausserdem soll der Lesende in die Validierungsthematik eingeführt und durch wertvolle Hinweise auf weiterführende Literatur ein vertieftes Verständnis der Thematik erlangen.

Die Arbeit gliedert sich in vier Hauptteile. Im ersten Teil, der Ausgangslage, wird das gesetzliche Umfeld in welchem sich die Validierung

Validierungsterminologie findet statt und die Firma anhand welcher die retrospektive Validierung an einem praktische Beispiel durchgeführt wurde wird vorgestellt.

Die Ziele der Arbeit, die inhaltliche Abgrenzung sowie die methodische Vorgehensweise werden nach dem ersten Teil erläutert.

Im zweiten Hauptteil, den theoretischen Grundlagen, wird die Basis für die Validierung erschaffen. International anerkannte Hilfsmittel und Leitfäden werden vorgestellt. Diese werden in einer Literaturdiskussion verglichen. Allgemeine Projektvorgehensmodelle werden geschildert und bezüglich der Validierung miteinander verglichen. Abgeleitet aus dem bereits bestehenden V-Modell zu prospektiven Validierung wird ein V-Modell zur retrospektiven Validierung einer IT-Infrastruktur eingeführt und beschrieben. Diese dient als Basis für die praktische Umsetzung, welche im dritten Hauptteil, „Praktische Umsetzung am Beispiel der Firma XY“, beschrieben wird.

Im dritten Hauptteil werden anhand des erarbeiteten V-Modells zur retrospektiven Validierung werden die einzelnen, durchgeführten Validierungstätigkeiten am Beispiel der Firma XY chronologisch beschrieben und erörtert.

Im vierten Hauptteil werden aufgrund der gemachten Erfahrungen wertvolle, kritische Erfolgsfaktoren erörtert, der Nutzen einer Validierung näher erörtert und Schlussfolgerungen gezogen. Diese werden ergänzt durch vier Interviews, welche im Rahmen dieser Arbeit mit in der Validierung tätigen Personen durchgeführt wurden. Die Interviews reflektieren über die gemachten Erfahrungen.

Bezüglich der prospektiven Validierung ist bereits sehr viel Literatur vorhanden. Im Bereiche der hier beschriebenen retrospektiven Validierung hält sich das Volumen in Grenzen. Die vorliegende Arbeit soll einen Beitrag dazu leisten diesen Bereich der Validierung besser auszuleuchten. Der rote Faden bildet dabei immer die praktische Ausrichtung auf die Thematik der retrospektiven Validierung einer IT Infrastruktur. Der Lesende wird somit in allen beschriebenen Bereichen konsequent mit wertvollen Informationen versorgt und soll ein ganzheitliches Bild von der Planung der Validierung über deren Umsetzung bis zum Erhalt des validierten Zustandes erhalten.

I

Inhaltsverzeichnis

Inhaltsverzeichnis

Executive  Summary.  I

Inhaltsverzeichnis   III

Vorwort................................................................................................   VII

Glossar.   VIII

1  Ausgangslage  1

1.1  Unternehmen  2

1.1.1  Über XY  2

1.1.2  Geschichte der Firma XY  2

1.1.3  Validierung und Qualitätsmanagement bei XY  3

1.2  Gesetze, Normen und Standards  4

1.2.1  Historischer Ursprung  4

1.2.2  Länderspezifische Gesetze, Normen und Standards.  5

1.2.2.1  Europäische Gesetzgebung.  5

1.2.2.2  US-Amerikanische Gesetzgebung.  6

1.2.3  Schweizer Gesetzgebung.  10

1.3  Validierungsterminologie.  11

1.3.1  Prospektive Validierung.  11

1.3.2  Retrospektive Validierung.  11

1.3.3  Begleitende Validierung / Concurrent Validation.  11

2  Zielsetzung.  13

3  Inhaltliche Abgrenzung.  15

4  Methodische Vorgehensweise.  17

5  Theoretische Grundlagen  19

5.1  Hilfsmittel und Leitfäden.  21

5.1.1  GAMP Leitfaden zur Validierung automatisierter Systeme  21

5.1.1.1  Einleitung  21

5.1.1.2  Ziele.  21

5.1.1.3  Zweck  21

5.1.1.4  Nutzen  22

5.1.2  Die APV-Richtlinie „Computergestützte Systeme“ basierend  

auf  dem Annex 11  23

5.1.3  ISO Normen und die GHTF  23

5.1.4  PIC/S  23

5.2  Literaturdiskussion  25

5.3  Projektvorgehensmodelle  26

5.3.1  Das Wasserfallmodell.  26

5.3.1.1  Eignung.  27

5.3.2  Iterative Modelle (Prototyping)  28

5.3.2.1  Eignung.  29

5.3.3  Das Spiral-Modell  30

IV

Inhaltsverzeichnis

5.3.3.1  Eignung  30

5.3.4  Das V-Modell.  31

5.3.4.1  Eignung  31

5.4  Das V-Modell zur prospektiven Validierung  32

5.4.1  Validierungsübersicht.  32

5.5  Vom prospektiven- zum retrospektiven V-Modell.  35

5.6  Phasen einer retrospektiven Validierung.  37

5.6.1  1 - Initialisierungsphase  37

5.6.1.1  Validierungsplan  37

5.6.2  2 - Konzeptphase  38

5.6.2.1  Überprüfung der bestehenden Prozesse  38

5.6.2.2  Überprüfung der bestehenden Dokumentation.  43

5.6.2.3  IST/SOLL-Analyse.  44

5.6.2.4  Erfahrungsbericht  44

5.6.3  3 - Detailphase.  44

5.6.3.1  Standardisierung / Erstellung von SOPs  44

5.6.3.2  Standardisierung / Erstellung der Dokumentation  45

5.6.3.3  Durchführung von Lieferanten-Audits  46

5.6.4  4 - Implementierungsphase.  47

5.6.4.1  Schulung des Personals.  47

5.6.4.2  Implementierung der Systeme.  48

5.6.5  5 - Realisierungsphase  48

5.6.5.1  Installationsqualifikation (IQ)  48

5.6.5.2  Operational Qualifikation/Performance Qualification (OQ/PQ)  

   48

5.6.5.3  Validierungsbericht  49

5.6.5.4  Erfahrungsbericht  49

5.6.6  6 - Betriebs-Phase.  49

5.6.7  7 - Stilllegung.  50

6  Praktische Umsetzung / Leitfaden  51

6.1  Einleitung  52

6.1.1  Umfeld  52

6.1.2  Geltungsbereich  52

6.1.3  Rollen.  52

6.2  Chronologischer Ablauf der retrospektiven Validierung  

   54

6.2.1  1 - Initialisierungsphase.  54

6.2.1.1  Validierungsplan  55

6.2.2  2 - Konzeptphase.  58

6.2.2.1  Review existierender Prozessbeschreibung.  58

6.2.2.2  Review bestehender Vorgabe- und Nachweisdokumente  60

6.2.2.3  Vorbereitung Security Audit.  60

6.2.2.4  IST/SOLL-Analyse.  60

6.2.3  3 - Detail-Phase.  61

V

6.2.3.1  Standardisierung/Erstellung von SOPs  61

Inhaltsverzeichnis

6.2.3.2  Standardisierung/Erstellung der Dokumentation  61

6.2.3.3  Durchführung von Lieferanten-Audits  63

6.2.4  4 - Implementierungs-Phase  64

6.2.4.1  Schulung  64

6.2.4.2  Einführung der Systeme.  64

6.2.5  5 - Realisierungs-Phase.  65

6.2.5.1  IQ und OQ  65

6.2.5.2  Validierungsbericht  65

6.2.5.3  Erfahrungsbericht  65

6.2.6  6 - Betriebs-Phase  66

6.2.6.1  Change Management  67

7  Kritische Erfolgsfaktoren  71

8  Nutzen aus der Validierung.  73

9  Schlussfolgerungen / Empfehlungen.  77

9.1  Interviews  78

10  Anhang  83

10.1  Quellenverzeichnis  84

10.1.1  Literaturverzeichnis  84

10.1.2  Internet.  84

10.1.3  Interviews  85

10.1.4  Endnotenverzeichnis  85

10.2  Übrige Verzeichnisse.  88

10.2.1  Abkürzungsverzeichnis.  88

10.2.2  Abbildungsverzeichnis.  89

10.2.3  Tabellenverzeichnis.  89

10.3  Diverse Unterlagen.  90

10.3.1  Review Checklist  90

VI

Vorwort

Sicherstellung der Betreuung dieser Systeme ebenfalls zu gewährleisten.

Die Technologie, sowie deren Dokumentation und Verwaltung gehören meines Erachtens für einen erfolgreichen, langfristigen und stabilen Einsatz der Systeme immer zusammen. Mit diesem Leitfaden zur retrospektiven Validierung will ich einen Beitrag zu dieser Thematik leisten.

Mein Dank gilt allen Gesprächspartnern, welche mit ihren Meinungen, Ideen und Statements einen Beitrag zum Gelingen meiner Arbeit geleistet haben. Ein besonderer Dank geht an meinen Referenten Till Jostes, der es verstanden hat, mich mit seinem gezielten Feedback und seiner kritischen Würdigung meiner Arbeit und Ideen immer noch einen Schritt vorwärts zu bringen. Danken möchte ich auch XY, XY, XY, XY, XY und XY die mich als Interview- und Gesprächspartner tatkräftig unterstützt haben. Besonderer Dank gilt meiner Freundin, die mit Verständnis und Motivation während der Zeit, an der ich an dieser Diplomarbeit arbeitete, eine tolle Stütze war.

Schliesslich weise ich daraufhin, dass die vorliegende Arbeit zur besseren Leserlichkeit in der männlichen Form verfasst wurde. Alle Ausdrücke beziehen sich jedoch auch auf die weibliche Form.

Zürich, 11. April 2005 XY

VII

Glossar

VIII

1  Ausgangslage  

1  Ausgangslage  

1

1.1.1 Über XY

XY ist eine führende Anbieterin von Lösungen innerhalb der Life-Science-Zulieferindustrie. Die Gesellschaft ist auf die Entwicklung, Herstellung und den Vertrieb von Lösungen für die Erforschung pharmazeutischer Wirksubstanzen sowie für die Bereiche Genomics, Proteomics und Diagnostics spezialisiert. Die Kunden von XY sind führende Pharma- und Biotechnologieunternehmen, Forschungsabteilungen von Universitäten und diagnostische Laboratorien auf der ganzen Welt. [2]

1.1.2 Geschichte der Firma XY

Nachfolgend die abgekürzte, chronologisch geordnete Firmengeschichte von XY:

1980: Gründung der Firma XY

1982-1986: Eintritt auf dem amerikanischen und asiatischen Markt

1986: „Schweizer Unternehmen des Jahres“

1987: Kotierung an der Schweizer Börse

1992: Gründung einer Tochterfirma in Japan

1997: Übernahme der Aktienmehrheit durch PerkinElmer

1999:

2000: Neubau des Hauptfirmensitzes in Männedorf

1.1.3

Bis Dezember 2003 hat XY Ihre Geräte verifiziert. Die Steuerung der Verifikation fand über den Product Innovation Process (PIP) statt. Für die Validierung von XY’s Laborgeräten im laufenden Betrieb waren die Kunden selbst verantwortlich. Die bis zu diesem Zeitpunkt durchgeführten Verifikationen der Geräte haben bereits einen grossen Teil der Validierungsanforderungen abgedeckt.

Im Rahmen der Erreichung der Compliance zur IVDD wurde eine Validierung der XY Produkte, sowie der zugrunde liegenden unterstützenden Prozesse unumgänglich. Im Dezember 2003 wurde in Zusammenarbeit mit TÜV Rheinland resultierend aus den IVDD Compliance-Bestrebungen die Grundlagen für eine weltweite Validierung der XY Produkte, deren unterstützender Systeme sowie der XY Prozesse gelegt. [4]

In der Folge der genannten Validierungsbestrebungen wurde eine Standardarbeitsanweisung (SOP) für die Validierung der IT erstellt und freigegeben, die SOP „Validation of IS/IT“. Danach wurde ein Master Validation Plan (MVP) „Newton Compliance“ erstellt, der auch Validierungstätigkeiten der IT-Infrastruktur festlegte. Ausgehend von diesem Dokument wurde die retrospektive Validierung der XY IT-Infrastruktur , gelenkt vom Validation Plan (VP) „IS/IT Infrastructure“ durchgeführt, welche im praktischen Teil dieser Diplomarbeit skizziert und erläutert wird.

Die im Hauptsitz gestarteten IT Validierungsaktivitäten sind zum jetzigen Zeitpunkt grösstenteils abgeschlossen und werden derzeit auf alle Länderorganisationen appliziert. Die Schilderung dieser Applizierung bezüglich der IT-Infrastruktur, sowie deren zugrunde liegender Dokumentation, Policies, Prozesse und SOPs wird im praktischen Teil erläutert.

3

Gesetze, Normen und Standards

Die in diesem Kapitel beschriebenen Gesetze, Normen und Standards beziehen sich auf die an XY weltweit gestellten Qualitäts- und Validierungsanforderung Da XY mit seinen Produkten weltweit präsent ist, müssen auch die entsprechenden länderspezifischen Standards erfüllt

Historischer Ursprung

Ursprünglich aus den USA, nämlich von der FDA (Food & Drug Administration) stammen Gesetze, welche grundsätzliche Anforderungen an Produktionsanlagen festlegen (cGMP, current Good Manufacturing

Weltweite Bedeutung erlangten entsprechende Anforderungen erstmals durch ein Papier aus dem Jahre 1968, welches dann nach verschiedenen Überarbeitungen im Jahre 1975 von der 28.

Weltgesundheitsversammlung unter der Bezeichnung "Good Practices in the Manufacture and Quality Control of Drugs" als Resolution WHA 28.65 angenommen wurde.

Aus dem Jahre 1970 stammt ein Übereinkommen, demzufolge zehn europäische Länder gegenseitig Inspektionen betreffend der Herstellung pharmazeutischer Produkte anerkennen. Die Inspektionen werden hierbei auf Basis der PIC-Richtlinien (Pharmaceutical Inspection Convention) durchgeführt (1983 hat die PIC ihre Richtlinien weitgehend mit dem WHO-GMP-Regeln abgeglichen).

Auf europäischer Ebene verdient zunächst die Richtlinie 91/356/EWG besonderer Erwähnung. Darin sind die Grundsätze und Leitlinien der Guten Herstellungspraxis festgelegt, allerdings in sehr allgemeiner Form. Detailliertere Angaben sind im Band IV des EG-Regelungswerkes "Die Regelung der Arzneimittel in der Europäischen Gemeinschaft" enthalten. Mit der "Betriebsverordnung für Pharmazeutische Unternehmer" in der Fassung vom August 1994 wurde die Rechtsgrundlage zur umfassenden Durchsetzung des EU-GMP-Leitfadens in der Schweiz geschaffen. Eine der wesentlichen Forderungen des EU-GMP-Leitfadens ist die sogenannte "Validierung" von Computersystemen. Im EU-GMP-Leitfaden gibt es zu diesem Begriff eine Definition:

„Beweisführung in Übereinstimmung mit den Grundsätzen der Guten Herstellungspraxis (WIE DOKUMENTIERT), daß Verfahren, Prozesse (SOPs), Ausrüstungsgegenstände, Materialien, Arbeitsgänge oder Systeme tatsächlich zu den erwarteten Ergebnissen (LAUFEN INNERHALB DER KOSTEN RETROSPEKTIV) führen.“

Im Wesentlichen geht es also um die Art und Weise, wie ein entsprechendes Produkt erzeugt wird, insbesondere um die dabei zu erstellende Dokumentation.

Das Mutual Recognition Agreement (MRA): Ziel der Vereinbarung zwischen den U.S.A., Kanada und Europa ist die gegenseitige Anerkennung durchgeführter Inspektionen und der entsprechenden Reports. 1:Betroffene Produkte, Ausnahmen und 2. Übergangsphase (transition period). [5]

4

1.2.2

Aus dem vorhergehenden Abschnitt ersichtlich präsentiert sich eine sehr grosse Vielfalt von Gesetzen und Normen, welche sich jedoch zu einem grossen Teil überschneiden. Aufgrund dieser Vielfalt haben sich Arbeitsgemeinschaften gebildet, welche die legalen Anforderungen aufgreifen, abgleichen und den Unternehmen Leitfäden als Hilfsmittel zur Durchführung ihrer Validierungstätgkeiten zur Verfügung stellen. Die für die retrospektive Validierung einer IT-Infrastruktur relevanten Leitfäden werden im Kapitel 5.1 Hilfsmittel und Leitfäden beschrieben.

1.2.2.1

Computergestützte Systeme nehmen hinsichtlich der Validierung eine besondere Stellung ein. Dies rührt nicht zuletzt daher, daß man Software nicht mit ihren Eigenschaften (Form, Farbe, Zusammensetzung, etc.) beschreiben kann.

1.2.2.1.1 EU-GMP

Das EU-GMP Regelwerk beschreibt die allgemeine, gute Herstellpraxis in Bezug auf die Produktion jeglicher Art von Anlagen. Die relevanten GMP Bereiche des Regelwerks werden im Folgekapitel 1.2.2.2 US-Amerikanische Gesetzgebung“ detaillierter geschildert, da sich diese an die GMP-Forderungen der USA anlehnen, respektive aus diesen entstanden sind.

1.2.2.1.2 IVDD 98/79/EC

Definitionsgemäß gilt die IVD-Richtlinie für in-vitro-Diagnostica und Zubehör, definiert als Reagenzien, einschließlich Kalibratoren und Kontrollmaterialien, die von ihrem Hersteller vorgesehen sind, um zum Vergleich von Messdaten oder zur Prüfung der Leistungsmerkmale eines In-vitro-Diagnosticums im Hinblick auf die bestimmungsgemäße Anwendung zu dienen, Geräte und Systeme, die vom Hersteller zum Zwecke der "In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben" in den Verkehr gebracht werden, das erforderliche Zubehör sowie primäre Probenbehältnisse. [6]

Die IVDD ist für die XY Geräte relevant, jedoch nicht für die retrospektive Validierung der IT-Infrastruktur. Es wird daher nicht näher darauf eingegangen.

5

1.2.2.2.1 21CFR Part 11

Der 21 CFR Part 11 der FDA Quality System Regulation ist relevant für die Validierung computerisierter Systeme, speziell für ERP Anwendungen. Kaum eine Vorschrift der letzten Jahre hat in den Laboren von Forschung, Entwicklung und Produktion für so viel Unruhe gesorgt, wie die 21 CFR Part 11 der FDA. Und das nicht nur im Bereich der pharmazeutischen Qualitätskontrolle. Dennoch ist es erstaunlich, daß in vielen Bereichen über eine Umsetzung des Regelwerkes nicht konsequent nachgedacht wird. Hier will ich aufzeigen, wie die Regularien der FDA im Bereich der Datenerfassung und Steuerung am Beispiel von Lesegeräten umgesetzt werden.

Die 21 CFR Part 11 erschien bereits im März 1997. Das Regelwerk beschreibt exakt, unter welchen Bedingungen die amerikanische Überwachungsbehörde elektronische Datenaufzeichnungen akzeptiert. Zuvor wurden ausschliesslich klassische Papieraufzeichnungen mit handschriftlicher Unterschrift akzeptiert, um die Zulassung

pharmazeutischer Produkte zu erreichen. Inzwischen ist die 21 CFR Part 11 für den gesamten amerikanischen Pharmaziemarkt sowie in einer Vielzahl medizinischer Industriezweige verbindlich und gilt weltweit auch für Unternehmen, die ihre Produkte in die USA exportieren wollen. Auch innerhalb der europäischen Gemeinschaft und der Schweiz faßt die 21 CFR Part 11 mehr und mehr Fuß oder es wird an ähnlichen Vorschriften gearbeitet.

Wozu dient die 21 CFR Part 11?

Die 21 CFR Part 11 soll eine unbeabsichtigte Veränderung von aufgezeichneten Daten oder die absichtliche Manipulation von Meßwerten verhindern bzw. erschweren. Um Unregelmäßigkeiten bei der Datenerfassung zu erkennen, müssen dazu - möglichst ohne den routinemäßigen Ablauf der Datenerfassung zu stören - im Hintergrund sämtliche Schritte der Datenerfassung und damit natürlich auch jede Veränderung der Daten protokolliert werden. Dies nennt sich „Audit Trail“. Diese Audit Trails sollen dem Anwender und den Prüforganen schnell und übersichtlich darstellen, ob es bei der Datenerfassung zu Unregelmäßigkeiten gekommen ist. Es gibt - dessen sind sich auch Prüforganisationen wie die FDA bewußt - keinen hundertprozentigen Schutz vor Datenmanipulationen. Allerdings sollten diese zumindest mit den heute vorhandenen technischen Möglichkeiten erschwert werden. Damit pharmazeutische Unternehmen regelkonform zur der 21 CFR Part 11 arbeiten können, müssen neben den erforderlichen

Schulungsmaßnahmen des Personals auch Softwareprodukte eingesetzt werden, die ebenfalls diesen Regularien entsprechen.

6

Die Softwareprodukte unterstützen die Nutzer bei der Umsetzung der

Konformität mit den entsprechenden Funktionen, die eigentliche Verantwortung liegt aber stets in der Umsetzung der Regularien durch den Anwender.

Automatische Datenerfassung - Electronic Records Wie oben beschrieben sollen durch die Umsetzung der 21 CFR Part 11 unter anderem drei Aspekte beachtet werden: Elektronische Aufzeichnungen, elektronsiche Unterschriften und der Schutz vor unberechtigten oder unbeabsichtigten Zugriffen. Jedes System, das elektronische Daten erfaßt und daraus Berichte erstellt, muß den Anforderungen von Part 11 genügen. Bevor jedoch die Erfüllung der Anforderungen eines Systems geprüft wird, sollten die Nutzer dieses Systems fundamentale GxP Prinzipien kennen und verstehen und über entsprechende Vorkenntnisse verfügen. So sollte eine SOP (Standard Operation Procedure) zur Prüfung des Systems erstellt werden. Diese Überprüfung muß beschreiben, daß die Aufzeichnungen genau, zuverlässig und vor ungewollten Änderungen geschützt sind. Diese Überprüfung sollten durch entsprechende Zertifikate des Herstellers unterstützt werden.

Des weiteren müssen die Anwender regelmäßig trainiert werden, damit die eingesetzten System (Geräte unklusive Software) richtig genutzt werden. Diese Trainingsmaßnahmen können sowohl durch interne Hausschulungen erfolgen, als auch von den Geräteherstellern durchgeführt werden. Letztendlich ist der Nutzer des Systems für die korrekte Datenerfassung und den daraus resultierenden Bericht verantwortlich. Durch die „elektronische Signatur“ wird diese Verantwortlichkeit dokumentiert. Welche grundlegenden Funktionen sollte nun ein System, bestehend aus Software und Hardware besitzen, um diese Forderung zu erfüllen?

1 - Schutz vor unberechtigtem Zugriff (Systemadministrator / Multi User Zugriff)

Ein Systemadministrator erzeugt und pflegt eine Liste mit Personen, die besondere Zugriffsrechte haben. Er definiert so genannte Standardnutzer und Nutzer mit erweiterten Rechten und spezifiziert, welche Funktionen vor dem Zugriff eines Standardnutzers geschützt werden müssen. Der Administrator vergibt auch spezielle Paßworte und Login-Eigenschften, die den Mißbrauch von Paßwörtern vermeiden sollen. Medet sich versehentlich ein Nutzer mit einem falschen Paßwort an, erscheint einen Fehlermeldung.

2 - Nutzung der Software durch verschiedene Benutzer (Multi User Zugriff)

Jeder Nutzer ist durch eine einmalige Kombination aus User ID und verschlüsseltem Paßwort definiert. Beim Start der Software werden diese Parameter abgefragt und erlauben so den Zugriff eines definierten Nutzers mit definierten Rechten. Diese Rechte dürfen ausschliesslich durch den Systemadministrator vergeben werden.

3- Audit Trail Funktionen mit Zeitstempel

Die Software verfügt über drei verschiedenen Audit Trail Funktionen. Jegliche Aktivitäten am System wie das An- und Abmelden von Nutzern (System Audit Trail), Veränderungen an Protokollen (Protocol Audit Trail), Erzeugung von Dateien, aber auch die Veränderung von Daten (Data Audit Trail) werden permanent protokolliert. Diese Protokolle sind fester Bestandteil der Software, können nicht verändert werden und sind in einer sicheren Datenbank gespeichert.

7

4-Eingebettete elektronische Signaturen

Vom Systemadministrator autorisierte Nutzer können Protokoll- und Datendateiein signieren lassen. Diese elektronischen Signaturen sind dauerhaft und verbleiben als fester Bestandteil der Datei. Diese Signaturen bestehen aus zwei eindeutigen Teilen: Einem, ID-Code (Paßwort und Namen) sowie einer Begründung der Signatur

5-Sichere Speicherung aller relevanten Daten in einer geschützten

Alle Software eigenen Dateien werden in einer sicheren Datenbank mit geteilten Zugriffsrechten (Netzwerknutzung) gespeichert. Jegliche Veränderung an Dateien, die Bestandteil dieser Datenbank sind, werden protokolliert und sind Bestandteil des System Audit Trails. Durch den Einsatz der Signatur im Zusammenspiel mit der Datenerfassung werden die 21 CFR Part 11 Anforderungen vollständig erfüllt. Ein wesentlicher Vorteil der Signatur ist der Einsatz auf einem handelsüblichen PC mit minimalen Rechneranforderungen. So sind auch der Nutzer, sein PC und seine Daten „CFR compliant“ [7]

8

820.50 Purchasing Conrols 820.60 Identification and 820.65 Traceability Production and Process Controls

Acceptance Activities

820.90 Nonconfirming Product

820.100 Corrective and preventive Action Labelling and Packaging

820.140 Handling, 820.150 Storage, 820.160 Distribution and 820.170 Installation

820.200 Servicing

820.250 Statistical Techniques [8]

Jeder der oben erwähnten Bereiche definiert exakt die regulatorischen Anforderungen, welche im entsprechenden Bereich von Herstellern abgedeckt werden müssen.

Um sich nicht durch alle Gesetzestexte durchzuarbeiten und für die Durchführung der Validierung das Rad neu zu erfinden, empfehle ich das Studium der in Kapitel 5.1 definierten Leitfäden.

9

1.3

Validierung bedeutet generell:

Die dokumentierte Beweisführung in Übereinstimmung mit der Guten Herstellpraxis, dass Verfahren, Prozesse, Ausrüstungsgegenstände, Materialien, Arbeitsgänge oder Systeme tatsächlich zu den erwarteten Ergebnissen führen und dies auch in Zukunft mit hoher Wahrscheinlichkeit tun werden. [10]

Der Term umfaßt die Begriffe Verifizierung, Qualifizierung und Validierung.

1.3.1

Prospektive Validierung bedeutet generell: Die dokumentierte Beweisführung in Übereinstimmung mit der Guten Herstellpraxis, dass Verfahren, Prozesse, Ausrüstungsgegenstände, Materialien, Arbeitsgänge oder Systeme tatsächlich zu den erwarteten Ergebnissen führen und dies auch in Zukunft mit hoher Wahrscheinlichkeit tun werden. [10]

Bei der prospektiven Validierung wird das zu validierende System erstellt, mit der Herstellung validiert und danach freigegeben.

1.3.2 Retrospektive Validierung

Retrospektive Validierung bedeutet generell: Die dokumentierte Beweisführung in Übereinstimmung mit den Grundsätzen der Guten Herstellpraxis, daß Verfahren, Prozesse, Ausrüstungsgegenstände, Materialien, Arbeitsgänge oder Systeme tatsächlich zu den erwarteten Ergebnissen geführt haben, führen und diesen in Zukunft mit großer Wahrscheinlichkeit auch entsprechen werden. [10]

Interpretation und Umsetzung:

Für die retrospektive Validierung der IT Infrastruktur heist dies, dass die Dokumentation der Vergangenheit aufbereitet und mit den Grundsätzen der guten Herstellpraxis verglichen werden muß. Der Erfahrungsbericht beschreibt die Zustände und Entwicklungen der vergangenen Jahre. Der Validierungsplan fast das gesamte Validierungsprojekt zusammen und legt die Masse für den Erfolg und Kriterien für die abschliessende Akzeptanz fest

1.3.3 Begleitende Validierung / Concurrent Validation

Die begleitende Validierung, auch „Concurrent Validation“ genannt, ist eine retrospektive Validierung in der die laufenden

Änderungsanforderungen ebenfalls validiert werden. Dies macht die begleitende Validierung zur teuersten Validierung, da sich das Ziel ständig ändert und somit die Lenkungsdokumente kontinuierlich angepasst werden müssen

11