Die Validierung von Computersystemen ist eine Sammlung von Maßnahmen mit dem Ziel der Lieferung eines dokumentierten Nachweises dafür, dass das System tatsächlich zu den geplanten Ergebnissen führt und nach den vorherigen Vorgaben arbeitet. Wie kann das getan werden?
Nachfolgend werden die 6 zu durchlaufenden Schritte beschrieben:
1. Welche Anforderungen werden dem System gestellt?
Die Implementierung eines IT-Systems soll zur Unterstützung, Automatisierung oder Optimierung bei der Realisierung eines Geschäftsprozesses beitragen. In der Regel weiß die Organisation daher, welcher Prozess unterstützt werden soll und hat entsprechende Ansichten zu diesem Thema. Der erste Schritt besteht daher in der Erstellung einer Liste der Anforderungen. Die Anforderungen des Anwenders (User Requirements) umfassen sowohl funktionelle Anforderungen, die direkt mit dem unterstützten Geschäftsprozess verbunden sind, wie auch nicht funktionelle, die sich unter anderem auf Sicherheit, Leistung und Schnittstellen des Systems beziehen. Bei der Erstellung der Liste der Anforderungen für Systeme zur Unterstützung der Pharmaziebranche muss zudem an die rechtlichen Anforderungen gedacht werden.
2. Validieren? Wie?
Wenn bekannt ist, was das System unterstützen soll, muss seine Kritizität durchdacht werden. In dieser Phase muss eingeschätzt werden können, ob das System vom Gesichtspunkt GxP kritisch ist und daher validiert werden muss. Worum geht es dabei? Der Schlüssel liegt in der Bewertung, ob das System Elemente des Geschäftsprozesses unterstützt, welche Einfluss auf folgende Fragen haben können:
- die Gesundheit des Patienten
- die Qualität des Medizinprodukts
- die Integrität der Daten
Wenn ein Zusammenhang sichtbar ist, dann ist die Antwort einfach – es muss validiert werden!
3. Wir soll das System funktionieren?
Die einzelnen Funktionen des Systems oder Elemente der Konfiguration unterstützen die entsprechenden Anforderungen. In der nächsten Etappe sind die Funktionen und Konfigurationselemente des Systems sowie die Erweiterungen aufzulisten und mit den ihnen entsprechenden Anforderungen zu verbinden. Ziel ist die Lieferung eines Systems, das die Anforderungen des Anwenders erfüllt. Angesichts dessen muss die klare Festlegung möglich sein, welche Funktionen den einzelnen Anforderungen entsprechen und wie sicherzustellen ist, dass alle Anforderungen vom System gedeckt und realisiert werden.
Selbstverständlich ist neben der typischen funktionellen Spezifikation des Systems eine technische Spezifikation vorzubereiten.
4. Risiko? Wir kann es verhindert werden?
Mit den einzelnen Systemfunktionen ist ein gewisses Risiko verbunden. Dieses Risiko muss identifiziert und bewertet werden. Jedes Risiko ist nach seinem Einfluss auf Gesundheit des Patienten, Qualität des Medizinprodukts, Datenintegrität, Wahrscheinlichkeit des Auftretens sowie Möglichkeit der Feststellung zu bewerten. Anschließend ist abzuwägen, welche Risiken akzeptiert werden können und welche die Einführung von Gegenmaßnahmen erfordern. Es gibt viele Verfahren der Risikoanalyse – oftmals verfügen reife Organisationen über selbst erstellte und bewährte Schemata. Zu den populärsten gehören die Verfahren der Risikoanalyse nach GAMP 5 sowie das FMEA-Verfahren.
Zu den Gegenmaßnahmen gehören meist zusätzliche Tests, Prozeduren, Anleitungen der Anwender, Schulungen sowie der sogenannte Umbau von Funktionen – manchmal können „Sicherungen“ in die gegebene Systemfunktion „eingebaut“ werden.
Es ist daran zu denken, dass nach der Einführung der Gegenmaßnahmen die Risikoanalyse zu verifizieren ist!
5. Tests!
Ist das System bereit, muss geprüft werden, ob es tatsächlich so funktioniert, wie es sollte. Zu Beginn werden Tests auf dem Level des Codes durchgeführt, z.B. Integrationstests oder Code Reviews. Danach ist zu prüfen, ob alle Bestandteile korrekt installiert sind („IQ“) und ob das System korrekt funktioniert („OQ“, gemäß der funktionellen Anforderungen). Wenn die Tests positive Resultate liefern, können die letztendlichen “PQ“-Tests durchgeführt werden. Diese werden in der Regel von den Endanwendern durchgeführt, die überprüfen, ob das System den entsprechenden Geschäftsprozess unterstützt, und bestätigen, dass das angestrebte Ziel erreicht wurde – das System also das vorgegebene Ziel erfüllt (eng. Intended use). Wenn in irgendeiner Phase Funktionsfehler des Systems festgestellt werden, sind diese zu analysieren, zu korrigieren und die Tests anschließend zu wiederholen (d.h. diejenigen, in denen der Fehler festgestellt wurde, sowie diejenigen, auf die er Einfluss haben könnte).
Selbstverständlich sind alle Tests auf formelle Weise durchzuführen und zu dokumentieren, wobei Beweise für den korrekten Verlauf der Tests zu sammeln sind. Schließlich ist nachzuweisen, dass das System korrekt arbeitet.
6. Zusammenfassung
Ist das System bereit, sind die Anwender zu schulen und entsprechende Arbeitsplatzanleitungen noch vor dem offiziellen Start vorzubereiten. Die Erfüllung der oben genannten Vorgaben und eine korrekte Installation des Systems in der Produktionsumgebung ermöglichen eine Zusammenfassung der gesamten Maßnahmen und die Freigabe der Nutzung des Systems.
Vom formellen Gesichtspunkt wird ein Validierungsbericht erstellt, der die Zusammenfassung aller durchgeführten Maßnahmen enthält. Im Bericht müssen zudem alle Abweichungen vom ursprünglichen Plan beschrieben und begründet werden. Werden Aktionen identifiziert, die nicht zeitgerecht durchgeführt wurden, die aber nicht kritisch vom Gesichtspunkt der Validierung des Systems sind, müssen diese genannt werden. Zudem ist zu beschreiben, wie ihre Realisierung überwacht werden soll.
Selbstverständlich ist während der Betriebsphase die ganze Zeit daran zu denken, dass der validierte Status des Systems aufrechterhalten werden muss und solche Aspekte, wie Änderungsmanagement, Ereignis- und Problemmanagement, Anwender- und Zugangsmanagement, Backup-Prozeduren, Prozeduren der Datenrückgewinnung und viele andere mehr, entsprechend zu realisieren und zu kontrollieren sind. Darüber jedoch mehr in einem anderen Teil.
