Planung und Durchführung der Validierung von Informationssystemen bei Medizinalgeräteherstellern (Medical Device Manufacturer)

Inhaltsverzeichnis

Executive Summary

Vorwort

Glossar

1 Ausgangslage
1.1 Unternehmen
1.1.1 Über XY
1.1.2 Geschichte der Firma XY
1.1.3 Validierung und Qualitätsmanagement bei XY
1.2 Gesetze, Normen und Standards
1.2.1 Historischer Ursprung
1.2.2 Länderspezifische Gesetze, Normen und Standards
1.2.2.1 Europäische Gesetzgebung
1.2.2.2 US-Amerikanische Gesetzgebung
1.2.3 Schweizer Gesetzgebung
1.3 Validierungsterminologie
1.3.1 Prospektive Validierung
1.3.2 Retrospektive Validierung
1.3.3 Begleitende Validierung / Concurrent Validation

2 Zielsetzung

3 Inhaltliche Abgrenzung

4 Methodische Vorgehensweise

5 Theoretische Grundlagen
5.1 Hilfsmittel und Leitfäden
5.1.1 GAMP Leitfaden zur Validierung automatisierter Systeme
5.1.1.1 Einleitung
5.1.1.2 Ziele
5.1.1.3 Zweck
5.1.1.4 Nutzen
5.1.2 Die APV-Richtlinie „Computergestützte Systeme“ basierend auf dem Annex
5.1.3 ISO Normen und die GHTF
5.1.4 PIC/S
5.2 Literaturdiskussion
5.3 Projektvorgehensmodelle
5.3.1 Das Wasserfallmodell
5.3.1.1 Eignung
5.3.2 Iterative Modelle (Prototyping)
5.3.2.1 Eignung
5.3.3 Das Spiral-Modell
5.3.3.1 Eignung
5.3.4 Das V-Modell
5.3.4.1 Eignung
5.4 Das V-Modell zur prospektiven Validierung
5.4.1 Validierungsübersicht
5.5 Vom prospektiven- zum retrospektiven V-Modell
5.6 Phasen einer retrospektiven Validierung
5.6.1 1 - Initialisierungsphase
5.6.1.1 Validierungsplan
5.6.2 2 - Konzeptphase
5.6.2.1 Überprüfung der bestehenden Prozesse
5.6.2.2 Überprüfung der bestehenden Dokumentation
5.6.2.3 IST/SOLL-Analyse
5.6.2.4 Erfahrungsbericht
5.6.3 3 - Detailphase
5.6.3.1 Standardisierung / Erstellung von SOPs
5.6.3.2 Standardisierung / Erstellung der Dokumentation
5.6.3.3 Durchführung von Lieferanten-Audits
5.6.4 4 - Implementierungsphase
5.6.4.1 Schulung des Personals
5.6.4.2 Implementierung der Systeme
5.6.5 5 - Realisierungsphase
5.6.5.1 Installationsqualifikation (IQ)
5.6.5.2 Operational Qualifikation/Performance Qualification (OQ/PQ)
5.6.5.3 Validierungsbericht
5.6.5.4 Erfahrungsbericht
5.6.6 6 – Betriebs-Phase
5.6.7 7 - Stilllegung

6. Praktische Umsetzung / Leitfaden
6.1. Einleitung
6.1.1. Umfeld
6.1.2. Geltungsbereich
6.1.3. Rollen
6.2 Chronologischer Ablauf der retrospektiven Validierung
6.2.1.1 – Initialisierungsphase
6.2.1.1. Validierungsplan
6.2.2.2 – Konzeptphase
6.2.2.1. Review existierender Prozessbeschreibung
6.2.2.2. Review bestehender Vorgabe- und Nachweisdokumente
6.2.2.3. Vorbereitung Security Audit
6.2.2.4. IST/SOLL-Analyse
6.2.3.3 - Detail-Phase
6.2.3.1. Standardisierung/Erstellung von SOPs
6.2.3.2. Standardisierung/Erstellung der Dokumentation
6.2.3.3. Durchführung von Lieferanten-Audits
6.2.4.4 - Implementierungs-Phase
6.2.4.1. Schulung
6.2.4.2. Einführung der Systeme
6.2.5... 5 - Realisierungs-Phase
6.2.5.1. IQ und OQ
6.2.5.2. Validierungsbericht
6.2.5.3. Erfahrungsbericht
6.2.6.6 - Betriebs-Phase
6.2.6.1. Change Management

7. Kritische Erfolgsfaktoren

8. Nutzen aus der Validierung

9. Schlussfolgerungen / Empfehlungen
9.1. Interviews

10. Anhang
10.1. Quellenverzeichnis
10.1.1. Literaturverzeichnis
10.1.2. Internet
10.1.3. Interviews
10.1.4. Endnotenverzeichnis
10.2. Übrige Verzeichnisse
10.2.1. Abkürzungsverzeichnis
10.2.2. Abbildungsverzeichnis
10.2.3. Tabellenverzeichnis
10.3. Diverse Unterlagen
10.3.1. Review Checklist

Validierung

Abbildung 1: Validierung, Qualität^[1]

Qualität

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 bewegt geschildert, eine Einführung in die 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.

Diese Diplomarbeit ist im Rahmen meines berufsbegleitenden Wirtschaftsinformatik Studiums an der Fachhochschule Zürich entstanden.

Vorwort

Die Bereiche der Qualitätssicherung und des Prozesswesens haben mich als angehenden Wirtschaftsinformatiker seit Beginn fasziniert. Einerseits birgt der sinnvolle Einsatz von Informations- und Kommunikationstechnologien nach wie vor ein grosses Potential, andererseits ist es von grosser Bedeutung, die Dokumentation und 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

Glossar

Abbildung in dieser Leseprobe nicht enthalten

1 Ausgangslage

In diesem Kapitel wird die Ausgangslage für die Arbeit definiert. Das Kapitel ist unterteilt in 1.1 Unternehmen, 1.2 Gesetze, Normen und Standards, sowie 1.3 Validierungsterminologie.

Ziel dieses Kapitels ist es, den Leser in die Validierungsthematik einzuführen und die grundlegenden Rahmenbedingungen zu definieren.

Aufgrund der Aktualität des behandelten Gebiets Validierung ist die Mehrzahl der hier referenzierten Quellen im Internet zu finden. Der besseren Lesbarkeit halber sind die Fuss/Endnoten im Quellenverzeichnis, Unterkapitel Endnotenverzeichnis ersichtlich.

1.1 Unternehmen

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: Umstrukturierung und Verkauf der Aktienmehrheit durch PerkinElmer

2000: Neubau des Hauptfirmensitzes in Männedorf

2005: Abschluss der IT Validierungsarbeiten im Hauptsitz, Gründung einer Ländergesellschaft in China,

Erreichung der ISO 13485:2003 Zertifizierung^[3]

1.1.3 Validierung und Qualitätsmanagement bei XY

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.

1.2 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 werden.

1.2.1 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 Practice).

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]

1.2.2 Länderspezifische Gesetze, Normen und Standards

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 Europäische Gesetzgebung

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.

1.2.2.2 US-Amerikanische Gesetzgebung

Die US-Amerikanische Gesetzgebung hinsichtlich der Sicherstellung von Qualität wird in den GMPs, den Good Maufacturing Practices widergespiegelt. Für die retrospektive Validierung der IT-Infrastruktur insbesondere relevant sind die beiden Bereiche

- 21 CFR Part 11 und
- 21 CFR Part 820.

Dies beiden Regulatorien werden in den folgenden beiden Unterkapiteln genauer erläutert.

Die Benennung GMP wird durch die FDA auf Dauer durch den Begriff Quality System Regulation (QSR) ersetzt. Dies gilt jedoch nur für den Medizinalgerätebereich.

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.

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.

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 Datenbank

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]

1.2.2.2.2 21 CFR Part 820, QSR

Den wohl bedeutendsten Gesetzestext der FDA bezüglich der Validierung computerisierter Systeme bildet die „21 CFR Part 820 Medical Devices; CGMP“ der Quality System Regulation (QSR). Das Regelwerk umfaßt rund 60 DIN A4 Seiten, ist verständlich verfaßt und kann unter der folgenden Internet Adresse frei bezogen werden: http://www.fda.gov/cdrh/fr1007ap.pdf

Die 21CFR Part 820, QSR gibt für die retrospektive IT-Infrastruktur Validierung Richtlinien vor. Die QSR umfaßt die folgenden Bereiche. (Die für die hier beschriebene Validierung releventanten Abschnitte sind markiert):

QSR Requirements

- 820.20 Management responsibility
- 820.22 Quality Audit
- 820.25 Personnel

820.30 Design Controls

820.40 Document Controls

820.50 Purchasing Conrols

820.60 Identification and 820.65 Traceability

Production and Process Controls

- 820.70 Production and Process Controls
- 820.72 Inspections, measuring and test
- 820.75 Process Validation

Acceptance Activities

- 820.80 Receiving, in process and finished device acceptance
- 820.86 Acceptance status

820.90 Nonconfirming Product

820.100 Corrective and preventive Action

Labelling and Packaging

- 820.120 Device Labelling
- 820.130 Device Packaging

820.140 Handling, 820.150 Storage, 820.160 Distribution and 820.170 Installation

Records

- 820.180 General Requirements
- 820.181 Device Master Record
- 820.184 Device History Record
- 820.186 QS Record
- 820.198 Complaint Files

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.

1.2.3 Schweizer Gesetzgebung

Die schweizerische Gesetzgebung im Medizinalgerätebereich wird vorwiegend durch die swissmedic, das Schweizerische Heilmittelinstitut vorgegeben. Die swissmedic hat sämtliche ihrer Vorgaben auf den europäischen und US-amerikanischen Markt ausgerichtet. Dies bedeutet konkret, daß Geräte in der Schweiz zugelassen werden, wenn die anwendbaren ISO Normen eingehalten werden und der Hersteller belegt, daß er die Gute Herstellpraxis der EU und USA einhält. Es wird daher auf die Schweizerische Gesetzgebung nicht näher eingegangen.

Die Homepage der swissmedic ist übersichtlich gestaltet und ist mit zahlreichen Verweisen auf weiterführende Literatur ausgestattet. Die Internet Adresse lautet: http://www.swissmedic.ch^[9]

1.3 Validierungsterminologie

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 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

2 Zielsetzung

Primäres Ziel dieser Diplomarbeit ist es, einen Leitfaden zur retrospektiven Validierung einer IT-Infrastruktur zur Verfügung zu stellen. Der Leser wird in das Gebiet der Validierung eingeführt und erhält einen einen Einblick in die weltweit herrschenden Gesetze, Normen und Standards, welche für die IT-Infrastruktur Validierung relevant sind. Zusätzlich wird auf wertvolle, weiterführende Literaturquellen verwiesen, welche einen vertieften Einblick in die beschriebenen Gebiete geben.

Der Leitfaden beschränkt sich jedoch nicht auf die Planung und Durchführung einer retrospektiven Validierung der IT-Infrastruktur, sondern gibt Hilfestellung zur Durchführung sämtlicher Validierungstätigkeiten von der Projektinitialisierung bis zur Stilllegung des Systems.

Des weiteren gibt der Leitfaden Hilfestellung zur Einführung des Änderungswesens, welches sicherstellt, daß das System auch in Zukunft in validiertem Zustand verbleibt.

Der theoretische Teil schildert detailliert die relevanten Vorgehensmodelle.

Anhand der Firma XY wird die Planung und Durchführung mit Beispielen ergänzend beschrieben.

Die Betrachtung kritischer Erfolgsfaktoren und Interviews mit in den Validierungsprojekten tätigen Mitarbeitenden runden diesen Leitfaden ab.

3 Inhaltliche Abgrenzung

Dieser Leitfaden ist auf die retrospektive Validierung der IT Infrastruktur ausgerichtet. Um den Leser in die Validierung einzuführen werden in der Ausgangslage, sowie im theoretischen Teil benachbarte Validierungsbereiche ebenfalls beleuchtet. Dies soll der besseren Positionierung, sowie der Verknüpfung verschiedener Validierungstätigkeiten dienen.

Um den Begriff „IT Infrastruktur“ klar abzugrenzen sei dieser wie folgt definiert:

„Alle computerisierten Systeme inklusive der damit in Verbindung gebrachten Hardware, Software, den Netzwerkkomponenten sowie der dazugehörigen Dokumentation um das XY Geschäft zu betrieben“ Ausserhalb dieses Bereiches liegen Systeme und Software, welche als Applikationssysteme betrieben werden, sowie auch jegliche Art von Gerätesteuerungssoftware.

Auf die Software Validierung wird in dieser Diplomarbeit nicht eingegangen. Die Validierung von Produkten, Applikationssystem (z.B. ERP Systeme) wird in dieser Arbeit ebenfalls nicht behandelt. Ferner wird auf den Betrieb von nicht validierten Systemen ebenfalls nicht eingegangen.

Der Leitfaden richtet sich nur auf alle den Betrieb unterstützenden Hardware- , Software- und Netzwerksysteme. In welchem Umfang er als Leitfaden für die prospektive Arbeit eingesetzt wird, bleibt der Entscheidung des einzelnen Unternehmens überlassen.

Es sei ferner angemerkt, daß andere akzeptable Modelle als die in diesem Leitfaden beschriebenen existieren, die in der Lage sind, das Ziel einer adäquaten Validierung automatisierter Systeme zu erreichen. Dieser Leitfaden stellt in keinem Fall irgendwelche Beschränkungen für die Entwicklung neuer Konzepte oder neuer Techniken auf, die für die Erreichung dieses Ziels nützlich sein können.

4 Methodische Vorgehensweise

In der Ausgangslage werden die Rahmenbedingungen, in welcher sich die retrospektive Validierung einer IT Infrastruktur befindet, definiert. Die Basis hierfür bildet ein ausgeprägtes Literaturstudium, welches sich aufgrund der Aktualität des Themas vorwiegend auf im Internet veröffentlichte Quellen stützt. Aus den Quellen werden die Rahmenbedingungen skizziert. Diese sind: Beschreibung der Firma XY, weltweit gültige gesetzliche Richtlinien und Einführung in die Validierungsterminologie. Die Ausgangslage ist dabei immer darauf ausgerichtet, den interessierten Lesenden in die Thematik einzuführen und bietet jeweils einen Fundus an weiterführender Literatur zu Vertiefung in spezifische Themengebiete.

Der theoretische Teil befasst sich mit Hilfsmitteln und Leitfäden, welche Ansätze zur Umsetzung der regulatorischen Anforderungen anbieten. In der Literaturdiskussion werden die gängien Quellen, sowie deren Unterschiede und Gemeinsamkeiten erörtert. Des weiteren befasst sich der theoretische Teil mit der Erarbeitung allgemein gültiger Grundsätze zum Projektvorgehen und bildet diese auf die durch die Validierung gestellten Forderungen ab. Daraus wird ein Vorgehensmodell zur Durchführung einer retrospektiven Validierung hergeleitet.

Der praktische Teil befasst sich mit der Durchführung der retrospektiven Validierung am Beispiel der Firma XY. Das im theoretischen Teil erarbeitete Modell wird als integrierender Bestandteil der Validierung somit in der Praxis angewendet. Im praktischen Teil wird somit der eigentliche Leitfaden erarbeitet.

Abschliessend wird die durchgeführte Validierung mit den theoretischen Validierungsgrundlagen verglichen, Vor- und Nachteile werden erörtert und der Validierungsansatz wird kritisch hinterfragt. Wie dies auch in der Validierung der Fall ist, findet in diesem Teil somit die Qualifizierung gegen die erarbeitete Theorie statt.

Ebenfalls in Anlehnung an die Validierungstätigkeiten runden die Schlussfolgerungen und Empfehlungen diese Arbeit ab. Mehrere durchgeführte Interviews werden wiedergegeben und bieten wertvolle Informationen über Vor- und Nachteile, gemachte Erfahrungen, Höhen und Tiefen und Verbesserungsvorschläge anhand der in der Firma XY durchgeführten Validierung.

[...]

---

^[1] Vgl. www.validieren.de (Stand: 2. Januar 2005)

^[2] Vgl. Medienmitteilung der Firma XY vom 15. März 2005

^[3] Vgl. www.XY.com/index/com-ou_gr-entry/com-ou_gr-history.htm (Stand: 2. Februar 2005)

^[4] Interview mit R. S., Mitarbeitender QA, vom 29.03.2005

^[5] Vgl. www.validieren.de (Stand: 1. März 2005)

^[6] Vgl. http://www.vdgh.de/internet/Informationen_und_Publikationen/Ko mpendien/Medizinprodukterecht/mpr.htm (Stand: 1. März 2005)

^[7] Vgl. http://www.gitverlag.com/media/downloads/themen/thema_4091030b 97126.pdf (Stand: 15. Februar 2005)

^[8] Vgl. http://www.fda.gov/cdrh/fr1007ap.pdf (Stand: 15. Februar 2005)

^[9] Vgl. http://www.newapproach.org/Directives/DirectiveList_Print.asp (Stand: 17. Februar 2005) 10 Anhang 86

^[10] Vgl. GAMP4-Leitfaden zur Validierung automatisierter Systeme (2001, S. 22, Anhang 09)