Startseite / Fachartikel / Risikomanagement in der IT-Praxis - was bedeutet das in einem CVS-Projekt?

Risikomanagement in der IT-Praxis - was bedeutet das in einem CVS-Projekt?

Blind auf beiden Augen, was IT-Risikomangement betrifft?
Blind auf beiden Augen, was IT-Risikomangement betrifft?

Mit dem GAMP5© wurde erstmalig ein Konzept für ein Risikomanagement im Life-Cycle eines Computersystems in der regulierten Industrie vorgestellt. Die Kenntnis der möglichen, systemischen Risiken für Produktqualität oder Patienten ist der Schlüssel zur Skalierung der Massnahmen im Validierungsprojekt und im regulären Betrieb eines Systems. Die Bausteine R1 bis R7 des GAMP5©-Risikomanagements (s. Grafik) bieten die Ansatzpunkte für eine effiziente Vorgehensweise, welche auf die notwendigen, also risikobehafteten Punkte fokussiert. Die Umsetzung ist oftmals mangelhaft und Nutzenpotentiale, wie z.B. im Anhang M3 des GAMP5© formuliert, werden häufig nicht ausgeschöpft. Methoden und Hilfsmittel der CSV sollten daher gezielt und gepaart mit einem bewussten Umgang mit dem Risiko eingesetzt werden. Über Periodic Reviews der validierungspflichtigen Systeme können regelmässig Erfahrungen gesammelt und das Risikomanagement im IT-Umfeld weiterentwickelt werden.

 

Rahmenbedingungen
Die Pharma-Industrie ist nicht erst seit dem GAMP5© (2008) mit dem Begriff „risk-based approach“ konfrontiert. Die ICH Guideline Q9 Quality Risk Management wurde drei Jahre zuvor veröffentlicht. Bereits im GAMP3© (Annex 18 „Risk Assessment“) und GAMP4© (Anhang M3 „Guideline for Risk Assessment“) gab es Ansätze zur Risikobeurteilung und -steuerung bezüglich eines systemischen Risikos für Produktsicherheit und -qualität. Erst in der Version 5 wurde es zu einem Risikomanagement über den gesamten Lebenszyklus. Auch der EU-GMP-Leitfaden greift in der Neufassung des Annex 11 und des Annex 15 das Thema auf. Die Medizinprodukteindustrie kennt Risikomanagement schon seit den 90er Jahren als Bestandteil des Qualitätssicherungssystems gemäss gültiger EG-Richtlinien.

 

 

Einfluss auf die Projektarbeit in einem CSV-Projekt
Die regulierte Industrie muss diese Forderungen erfüllen. Anhang M3 des GAMP5© begründet zusätzlich den Nutzen des Risikomanagements:

  • Erkennung und Behandlung von Risiken für Patientensicherheit, Produktqualität und Datensicherheit
  • Anpassung der Lebenszyklusaktivitäten und der zugeordneten Dokumentation nach Systemauswirkung und Risiken
  • Begründung des Einsatzes von Lieferantendokumentation
  • Bessere Kenntnis potenzieller Risiken und möglicher Kontrollen
  • Erkennen von Bereiche, für die Detail-Informationen benötigt werden
  • Verbesserung der Geschäftsprozesskenntnis

Risikomanagement ist aber mehr als nur Risikobewertung, -entscheidung und Festlegung der risikominimierenden Massnahmen. Es beinhaltet folgende Teilprozesse:

  1. Risikobeurteilung: Identifikation von Risiken, deren Beurteilung und Bewertung
  2. Risikosteuerung: Festlegung von Massnahmen zur Risikominimierung, einschliesslich Akzeptanz des verbleibenden Restrisikos
  3. Risikoüberwachung: Revision der Risikobeurteilung und -steuerung, ausgehend von der Beobachtung des tatsächlichen Risikoniveaus

Meistens werden Risikobeurteilung (R1, R3 – s. Grafik) und Risikosteuerung (besser Risikominimierung, R2, R4, R5 – s. Grafik) eines softwaregestützten Geschäftsprozesses im Einführungsprojekt noch ausführlich durchgeführt, während der Implementierung eines vollständigen Risikomanagement-Regelkreises meist weniger Aufmerksamkeit gewidmet wird. Gerade letzteres ist wichtig und muss in den Change-Management-Prozess (R6 – s. Grafik) sowie in den Betriebsalltag der Administration und Benutzer des Systems integriert werden.

 

Betrachtungsebenen in der Risikobeurteilung und –steuerung in der CSV
Neben den Zeitpunkten der Risikobetrachtung im Life-Cycle eines computergestützten Systems (s. Grafik R1 - R7) sind in der Praxis drei Systemebenen für die Risikoanalyse von Interesse:

Zeitpunkt R1: Basis Risikobewertung zu Beginn eines Projekts (auch High Level Risk Assessment, Initiale Risikoanalyse, oder Risikoanalyse 1 (RAI))
Sie stellt mit Hilfe der „predicate rules“ fest, ob ein System oder ein mit Hilfe eines Computersystems ausgeführter Prozess potentiell GxP-kritisch ist. Auf diese Weise werden kritische Bereiche identifiziert und andere ausgeschlossen.

Zeitpunkt R3 (1): Funktionale Risikobewertung in der Spezifikationsphase (auch Funktionale Risikoanalyse oder Risikoanalyse 2 (RAII))
Sie stellt methodisch fest, welche Hardware-, Daten- oder Prozesselemente wirklich in der Prozessdurchführung GxP-kritisch sind, welches die Abhilfe (risikominimierende Massnahme) ist und welche Nachweise dafür im Verifikationstest erbracht werden müssen.

Zeitpunkt R3 (2): Funktionale Risikobewertung in der Konfigurations- / Kodierungsphase (oder Risikoanalyse 3 (RAIII))
Sie stellt methodisch fest, welche Risiken in einer individuell entwickelten Komponente zu einem Computersystem stecken könnten und wie bereits auf der Entwicklungsebene risikominimierende Massnahmen greifen und welche Nachweise im Entwicklungsprozess gefordert werden.

Bei komplexen Systemen (z.B. ERP, MES, LIMS) ist die Basis-Risikobewertung (RAI) das Mittel der Wahl, um herauszufinden, welche Systemkomponenten im Fokus sind. Für einfache Systeme reicht im Allgemeinen die Gesamteinstufung GMP-kritisch oder nicht auf Systemebene aus. Anschliessend ergeben in beiden Fällen die funktionalen Risikobewertungen (RAII und/oder RAIII) der als kritisch eingestuften Komponenten oder Systeme die Testtiefe und die geforderten Testnachweise gegen die jeweilige Design-Spezifikation als Basis für die Entscheidungen zum Zeitpunkt R4 und R5 (s. Grafik) aufgrund der Testergebnisse.

 

Vollständige Implementierung eines Risikomanagement-Prozesses

Der erste Teil des Risikomanagements ist getan, das Projekt mit dem Validierungsbericht abgeschlossen und das computerisierte System in Betrieb. Dies ist aber nur die halbe Miete. In jedem Change Request sind die erfolgten Risikobewertungen aus den Vorphasen zu überprüfen und zu dokumentieren (R6, s. Grafik) – bis hin zur Stilllegung eines Systems, bei welcher das mit dem Abschalten des Systems verbundene Risiko zu beurteilen ist  (R7, s. Grafik).

Werden nur die beiden Teilprozesse Risikobeurteilung und -steuerung ausgeführt, fehlt der 3. Teilprozess: die Risikoüberwachung (vgl. Aufzählung oben). Die Vorgaben hierzu sind nicht sehr ausgeprägt. Wie erwähnt, sollte ein Überprüfungsverfahren für eine erfolgreiche Umsetzung der risikominimierenden Massnahmen etabliert werden, um die Prozessqualität des Risikomanagements zu prüfen und ggfls. verbessernde Aktionen einzuleiten.

Ein erfolgreiches Risikomanagement im IT-Umfeld ist ein Steuerungsinstrument, um systemische Risiken für Produktqualität und Patientensicherheit zu minimieren und den Erfolg der Massnahmen sicherzustellen. Im Rahmen des Periodic Review eines Systems sollte daher geprüft werden:

  • Sind die einmal gemachten Aussagen noch gültig?
  • Treffen die Bewertungen noch zu?
  • Sind die Massnahmen heutzutage immer noch die richtigen und waren sie erfolgreich?

 

Ausblick
Leider weichen Theorie und Praxis noch voneinander ab. Ein Hinterfragen der bisherigen Risikoeinschätzungen im Rahmen der Risikoüberwachung würde den Weg in beide Richtungen öffnen:

  • weniger Kontrollen und schlankere Abläufe bei weniger strenger neuer Beurteilung, oder
  • zusätzliche Massnahmen bei strengerer neuer Beurteilung unter neuen Gesichtspunkten.

 

Der Artikel „Risikomanagement nach GAMP5“ von „Sieghard Wagner, Pharm. Ind. 77, Nr.7, 1012-1022 (2015)“ widmet dem Thema eine ausführlichere Diskussion.

 

Dr. Thomas Karlewski und Sieghard Wagner|Consultants Efficient IT|The Business Designers

 

Kommentare

Zu diesem Artikel gibt es keine Kommentare

Chemgineering Holding AG | Binningerstrasse 2 | 4142 Münchenstein | T +41 61 467 54 00 | F +41 61 467 54 01 | www.chemgineering.com | info@chemgineering.com