Patrik Allman ist Leiter Qualitäts- und Compliancemanagement / Datenschutz bei YAVEON und Experte, wenn es um das Thema Computersystemvalidierung geht. Über 50 erfolgreiche Projekte mit Computersystemvalidierung hat er bereits betreut. 
Im Interview erläutert er den Unterschied zwischen Validierung und Qualifizierung, gibt Einblicke in Validierungsprojekte mit YAVEON und wirft einen Blick auf die Frage, was die Cloud für das validierte Umfeld bedeutet.

Patrik, für Pharmazeuten und Medizinproduktehersteller, also Teile der Life Sciences, gehört Computersystemvalidierung zum Alltag. Für alle anderen: Was genau bedeutet das, was sind die Anforderungen und wo liegt der Unterschied zur Qualifizierung? 

„Bei der Validierung im Bereich Computersysteme geht es darum zu belegen, dass ein Prozess vorab definierte Ergebnisse liefert und sich durch den Einsatz eines Computersystems die Qualität zumindest nicht verschlechtert und das Gesamtrisiko des Prozesses nicht steigt. Es ist also nicht die Software an sich, die validiert werden kann. Es geht um den dahinterstehenden Prozess in Verbindung mit der eingesetzten Software – also immer dort, wo computerisierte Systeme als Bestandteil von GMP-pflichtigen Vorgängen eingesetzt werden. Definiert ist das im Eudralex Vol. 4 Annex 11 – ein Teil der Richtlinie zur Herstellung von Arzneimitteln (Good Manufacturing Practice, GMP) in der Europäischen Union. 

Qualifizierung hingegen beschäftigt sich mit der Hardware und der Systemumgebung und ist eigentlich der Schritt vor der Validierung. Sie ist ein Eignungsnachweis, dass Hardware und Infrastruktur, wie zum Beispiel Netzwerke, Server, Scanner, Tablets und Bildschirme, einwandfrei funktionieren. Die Qualifizierung sagt also aus, dass die Ausrüstung das leisten kann, was von ihr gefordert wird.“ 

An welchen Vorgaben wird ein Validierungsprojekt ausgerichtet?  

„Wir orientieren uns bei der Computersystemvalidierung an GAMP5. Diese „Good Automated Manufacturing Practice“ ist das klassische Basiswerk, das alle Voraussetzungen berücksichtigt und festlegt, wie Prozesse mit dem Einsatz computergestützter Systeme grundsätzlich validiert werden müssen. Als Lieferant ist es wichtig, dass wir auf Basis der Best Practice passende Methoden haben, welche die Validierung ressourcenschonend ermöglicht. Rechtliche Grundlage sind dafür GxP-Richtlinien, die eine „gute Arbeitspraxis“ vorgeben. Das „G“ steht dabei für „Good“, „P“ für „Practice” und das x ist die Variable für den Bereich, um den es sich handelt. Zum Beispiel in unseren Projekten sehr häufig „M“ für „Manufacturing“ oder „D“ für „Distribution“. 

Wie läuft das ab? 

Bei ERP-Einführungen beispielsweise sprechen wir zunächst einmal von komplexen, geschlossenen Systemen, die zahlreiche Geschäftsprozesse eines Unternehmens unterstützen. Eine Branchenlösung wie YAVEON ProBatch beinhaltet nahezu 200 solcher Geschäftsprozesse – von der Finanzbuchhaltung bis zu Servicedienstleistungen. Daher muss zunächst definiert werden, welche Prozesse durch das ERP-System unterstützt werden und welche davon wiederum für die Validierung – also GMP- oder GDP-kritisch – relevant sind. Dafür gehen wir mit unseren Kunden eine sogenannten Business Process Master List (BPML) durch, die alle Prozesse umfasst, die unsere Lösungen abbilden können – vom ERP über die Dokumentenlenkung, das Reklamationsmanagement bis hin zum Change Management. Hierin sind alle möglichen Prozesse aufgeführt und werden dann mit „relevant“ oder „nicht relevant“ gekennzeichnet. Es wird also abgewogen, welchen GxP-Einfluss der Prozess im Kontext des Unternehmens hatDies wird auf Grundlage eines risikobasierten Ansatzes entschieden. So haben zum Beispiel Prozesse der Finanzbuchhaltung verständlicherweise keinen Einfluss auf die Medikamentensicherheit. Anders ist das aber beim Herstellungsprozess, der mit Einsatz des ERP-Systems gesteuert wird. Mit der unternehmensspezifischen BPML erhält man unkompliziert und in kurzer Zeit einen guten ÜberblickDamit ist auch der Umfang für die weitere Vorgehensweise festgelegt. Wir tun uns deswegen hier auch deshalb leicht, weil die Grundlagen bei uns bereits in der Produktenwicklung gelegt werden – und schon hier folgen wir der BPMLUnsere gesamte Softwareentwicklung und deren Dokumentation richtet sich nach dem Prozess-Prinzip und folgt in der Methodik bereits GAMP 5.”

Und wenn diese Prozesse dann alle validiert sind, bleibt das auch so? 

Validiert werden die Prozesse des Unternehmens. Wenn sie durch ein IT-System unterstützt werden auch gemeinsam mit dem IT-System. Diese Validierung muss sozusagen immer „am Leben gehalten“ werden. Wenn sich nie etwas ändern würde, wäre es ein eingefrorener Zustand. Aber im Laufe eines „Prozess- oder Softwarelebens ändert sich doch einiges – Arbeitsweisen, Arbeitsinhalte, Prozesse oder die Software an sich. Bei jeder Änderung und bei jedem Update muss daher geprüft werden, welche Auswirkungen sich auf die Dokumentation und die Risiken der Prozesse ergeben und welche Tests risikobasiert erforderlich sind, um die gewünschten Änderungen für den Echtbetrieb frei zu geben. Am besten funktioniert das mit Hilfe von Change Management-Prozessen. Wichtig ist außerdem, von Anfang an festzulegen, was nach der Stilllegung eines ERP-Systems passiert. Denn nichts ist für die Ewigkeit und schließlich müssen viele Informationen dauerhaft oder zumindest über einen längeren Zeitraum zur Verfügung gestellt werden. Wie genau das funktioniert, legt ein Shutdownbeziehungsweise ein Archivierungsplan fest. Darin sind die Anforderungen festgeschrieben, welche Informationen wie lange und wo verfügbar sind. In Summe – von Beginn einer Einführung, bis zur Stilllegung – spricht man vom Software Development Life CycleBei der Verantwortung dafür unterstützen wir unsere Kunden.“ 

 Validierung taucht immer wieder in Kombination mit der „Cloud“ auf. Wie hängt das zusammen? 

„Um das zu verstehen, müssen wir uns zunächst die verschiedenen Möglichkeiten betrachten, wie Sie – nach heutigem Stand – ihr ERP-System betreiben können: 

  1. On Premises 
  2. Infrastructure as a Service/IaaS
  3. Software as a Servie/SaaS – Public Cloud 

Die Art des Systembetriebs hat einen erheblichen Einfluss auf den Software Development Life Cycle.“ 

Was die Unterschiede sind, welche Schlussfolgerungen sich daraus ergeben und was das für Sie bedeutet, lesen Sie im zweiten Interviewteil.