Kaum ein Thema polarisiert in GMP-Fachkreisen so sehr wie die Validierung von IT-Systemen. Die Einen würden selbst Systeme, die nur einen sehr entfernten und eher theoretischen Einfluss auf die bei GMP im Vordergrund stehende Produktqualität haben, voll umfassend validieren. Andere wiederum unterschätzen die Bedeutung von offensichtlich kritischen Systemen. Allenthalben lassen sich große Unsicherheit und ein stetes Ringen zwischen einem Zuviel und einem Zuwenig bis hin zu einer kompletten Verweigerung und einer Flucht in die gute alte Welt des gedruckten Papiers beobachten. 

Inzwischen weiß es jeder: Bei einer allgegenwärtigen Computerisierung von Geschäfts- und Produktionsprozessen, ist eine ausschließliche Papierdokumentation GMP-relevanter Daten schlicht nicht mehr möglich. Die Papierdokumentation ist in der Regel ein Kartenhaus, das bei näherem Hinsehen sofort in sich zusammen fällt. Woher kommt diese allgemeine Verunsicherung in punkto IT-Validierung? Die Ursachen hierfür sind vielfältig. So ist sie im Gegensatz zur technischen Qualifizierung und Validierung von Herstellprozessen eher abstrakt. Risiken liegen in der Verarbeitung von Daten und damit in Software-Algorithmen, die in der Regel - außer für den Entwickler selbst - für niemanden sichtbar sind. Selbst Hardware ist heute oft nicht mehr „greifbar", da sie ihre Arbeit meist räumlich weit entfernt in unternehmenseigenen Rechenzentren oder bei einem externen Dienstleister verrichtet.
Der rasche technische Wandel in der Informationstechnologie, insbesondere Konzepte wie die Virtualisierung und das Cloud-Computing sowie die damit verbundene zunehmende Verteilung von Daten und Anwendungen, machen es immer schwieriger, Systeme klar abzugrenzen. Dies ist jedoch für eine zielgerichtete Validierung unbedingt erforderlich. Auch der hohe Änderungsdruck, speziell bei Software und eine daraus resultierende enorme Anzahl an Updates, stellen im Vergleich zu anderen GMP-Disziplinen eine große Herausforderung dar.

Probleme über Probleme
Hinzu kommt, dass die IT-Fachsprache überladen ist mit Anglizismen und Akronymen, was einen Zugang für Nicht-ITler extrem erschwert. Selbst als Insider kann man sich des Eindrucks nicht erwehren, dass dieser Zustand auch aufrechterhalten werden soll, wenn immer wieder neue Wortschöpfungen auftauchen und dies teilweise für bereits bekannte und etablierte Konzepte. Ein prominentes Beispiel ist hier der bereits erwähnte Begriff des Cloud-Computing, der im wahrsten Sinn des Wortes die Sicht auf eine ganze Reihe von technischen und organisatorischen Konzepten vernebelt, die in weiten Teilen nicht neu sind. Ein tieferes Verständnis für das Thema der IT-Validierung erfordert letztlich eine Dreifachqualifikation bzgl. IT, Qualitätsmanagement und Produktionsprozessen und in Validierungsprojekten das enge Zusammenwirken von Prozesseignern, IT-Verantwortlichen und der Qualitätssicherung. Häufig gestaltet sich die Kommunikation zwischen diesen Gruppen jedoch schwierig.

Obendrein gilt für die IT-Validierung, was für die anderen GMP-Disziplinen auch gilt: Die Regularien bleiben angesichts der großen Systemvielfalt sehr allgemein, wodurch sich ein extrem großer Raum für Interpretationen ergibt, der gefüllt werden will. Auch der allgemeine Kostendruck macht vor der IT-Validierung nicht halt. Die Zeiten, in denen IT-Systeme im Rahmen der Validierung bis zum letzten Bit durchleuchtet werden konnten, gehören endgültig der Vergangenheit an.
Viele Unternehmen richten angesichts dieser Probleme ihren Blick verstärkt in Richtung von Herstellern und Lieferanten von IT-Systemen. Sollten diese doch das umfassendste Wissen über die mit dem Einsatz ihrer Systeme verbundenen Risiken haben. Der in der Life Science Branche für das Vorgehen zur Validierung computergestützter Systeme etablierte GAMP-Leitfaden der International Society for Pharmaceutical Engineering (ISPE) spricht hier von einer „wirksamen Lieferantenbeteiligung". Soweit die Theorie - in der Praxis zeigt sich leider immer wieder, dass selbst Softwarehersteller, die explizit mit branchenspezifischem Know-how werben, wenig Kenntnisse im Bereich der Validierung haben und die Kunden nicht im gewünschten Maß unterstützen können.

Effizient zur Compliance - ein Traum?
Müssen Unternehmen nun angesichts dieser Problemvielfalt kapitulieren? Müssen sie sich mit nicht enden wollenden und Ressourcen verschlingenden IT-Validierungsprojekten einfach abfinden? Nein, ganz und gar nicht. Der Schlüssel liegt in drei wesentlichen Eigenschaften an denen es in den meisten Projekten mangelt: Pragmatismus, Verständlichkeit und Transparenz.

Pragmatismus bedeutet im Wortsinn die Orientierung auf das Nützliche. Das „Nützliche" ist jedoch im GMP-Umfeld klar definiert. Es ist die Produktqualität und letztlich die Patientensicherheit. Ein pragmatisches Vorgehen in IT-Validierungsprojekten bedeutet also zu aller erst eine Ausrichtung aller Aktivitäten auf diese beiden übergeordneten Ziele. Erreichen lassen sich diese nur durch einen streng risikobasierten Ansatz. Getrieben im Wesentlichen durch die FDA-Initiative für das 21. Jahrhundert und die ICH Leitlinie Q9 Quality Risk Management hebt die aktuelle Version des GAMP-Leitfadens das risikobasierte Vorgehen noch stärker hervor - und ist damit gute Praxis. Risikobetrachtungen sollten somit Grundlage aller Validierungsaktivitäten sein. Entscheidend ist jedoch wie man hierbei vorgeht. So sollte bereits im Rahmen der Validierungsmasterplanung die Möglichkeit genutzt werden, Systeme die weder einen direkten noch einen indirekten Einfluss auf die Produktqualität haben, von einer weiteren Betrachtung auszuschließen. Unter den verbleibenden GMP-relevanten Systemen sollten Unternehmen schließlich die wirklich kritischen von eher nachgeordneten unkritischen Systemen unterscheiden. Ein computergestütztes Überwachungssystem für die Umgebungsbedingungen in einem Reinraum ist hier sicher als kritischer einzustufen als ein SOP-Verwaltungssystem, was sich letztendlich aber auch im Validierungsaufwand widerspiegeln sollte. Die Fortführung dieses Vorgehens bei der Betrachtung eines bestimmten Systems bedeutet dann, z.B. bei einer komplexen Software wie einem ERP-System, zunächst auf übergeordneter Ebene eine Risikoklassifizierung von Modulen und Funktionsbereichen vorzunehmen. Gerade bei solch großen Systemen lassen sich in der Regel von vornherein ganze Teile wie z.B. kaufmännische Module von einer GMP-Validierung ausschließen. Damit kann der Aufwand für Detailrisikoanalysen auf tatsächlich GMP-relevante Softwarekomponenten und Funktionen gerichtet werden. Doch auch hier sollte der Pragmatismus im Vordergrund bleiben. Die Durchführung einer Detailrisikoanalyse mit dem Ziel, möglichst viele potentielle Fehlermöglichkeiten zu identifizieren und davon eine Vielzahl von erforderlichen Maßnahmen abzuleiten, kann schnell das Gegenteil von dem bewirken, was man eigentlich wollte. Jede Fehlermöglichkeit sollte auf ihre tatsächliche GMP-Kritikalität hin geprüft und entsprechend eingestuft werden. Nur so haben Unternehmen die Möglichkeit, z.B. bei der Festlegung geeigneter Tests, die Testtiefe und damit den Testaufwand auf die wirklich kritischen Aspekte zu fokussieren.

Übersetzer zwischen den „Welten"
Entscheidend für ein pragmatisches Vorgehen ist auch die richtige Einbindung von Herstellern und Lieferanten. Abhängig vom jeweiligen Lieferant können Wissensstand und Unterstützungsmöglichkeiten jedoch stark variieren. Die mögliche Zusammenarbeit sollte daher bereits im Rahmen der Lieferantenauswahl und -bewertung eruiert und in der Validierungsplanung festgelegt werden. Grundsätzlich gilt jedoch: Je mehr technisches Wissen für eine Validierungsaktivität erforderlich ist, umso eher lohnt sich eine Lieferanteneinbindung. Klassische Beispiele sind hier die Unterstützung bei der Erstellung von Testprotokollen für IQ und OQ.

Die zweite wesentliche Eigenschaft, an der es in vielen IT-Validierungsprojekten mangelt, ist die Verständlichkeit. Jede Fachdisziplin hat naturgemäß ihre eigene Terminologie. In einer interdisziplinären Zusammenarbeit zwischen Prozesseigner, IT-Fachkräften und der Qualitätssicherung ist ein einheitliches Verständnis für die inhaltlichen Fragestellungen jedoch ein kritischer Erfolgsfaktor. Der versierteste IT-Profi nützt hier letztlich wenig, wenn er technische Risiken bzw. Lösungskonzepte nicht so erläutern kann, dass die Prozessverantwortlichen sie verstehen. Hier kommt der IT-Validierungsexperte ins Spiel. In ihm vereinigen sich Prozesswissen, IT-Fachwissen und Wissen aus dem Bereich der Qualitätssicherung und er bildet somit die ideale Schnittstelle zwischen den einzelnen Gruppen. So kann der IT-Validierungsexperte z.B. beim Thema der regulatorisch geforderten Audit Trail Funktion einerseits beurteilen, welche Daten GMP-relevant sind und andererseits mit einem Software-Entwickler über die konkrete technische Umsetzung sprechen. Mit ihrem neutralen Blick von außen und ihrer Erfahrung können hier speziell externe Fachberater wertvolle Dienste leisten. Dies gilt insbesondere für eine sichere, fallbezogene und sachgerechte Interpretation der regulatorischen Vorgaben.
Als dritte und letzte wichtige Zutat zu einem erfolgreichen und effizient abgewickelten IT-Validierungsprojekt braucht es noch eine gehörige Portion Transparenz. Dies ist ganz entscheidend eine Frage der Projektkultur und des Willens, auch komplexe Aufgabenstellungen in kalkulierbare Arbeitspakete zu zerlegen. Letztlich muss über den gesamten Projektverlauf jeder Schritt klar begründbar sein, entweder auf Basis regulatorischer Vorgaben, auf Basis von Good Practices oder vor dem Hintergrund spezifischer Risikobetrachtungen.

Gute Aussichten
Kein Grund also, den Kopf in den Sand zu stecken. Die moderne Informationstechnologie sollte - wo hilfreich und nützlich - auch zum Einsatz kommen. Keine Arzneimittelüberwachungsbehörde hat ein Interesse daran, technische Innovationen zu behindern. Wer dies behauptet missinterpretiert die regulatorischen Vorgaben. Diese wollen lediglich einen Rahmen für einen verantwortungsvollen Einsatz und einen qualitätsbewussten Umgang mit der Technologie vorgeben. Das meiste dort geforderte ist ohnehin bereits Gute IT-Management-Praxis, auch in anderen Branchen. Was es im Bereich der IT-Validierung braucht ist eine Entmystifizierung und eine neue Projektkultur geprägt von Pragmatismus, Verständlichkeit und Transparenz.