• gmp-publishing.com
  • Login GMP-Datenbanken
  • Warenkorb
GMP-Newsletter: LOGFILE

Lesen Sie GMP-News und informative Beiträge zum Thema GMP in unserem kostenlosen GMP-Newsletter "LOGFILE".

 

>>> Mehr Infos & Anmeldung

NEU: PDE-Gutachten
Seit 1. Juni 2016 müssen für alle Human- und Tierarzneimittel, die in Mehrzweckanlagen hergestellt werden PDE-Werte für enthaltene Wirkstoffe ermittelt werden.

Image

Wir liefern zur Zeit PDE-Gutachten für ca. 850 Wirkstoffe!

Sie erhalten Ihr Gutachten:
...gemäß EMA-Richtlinie
...in Englisch
...ausgestellt auf Ihr Unternehmen
...erstellt durch europ. Toxikologen

>>> Mehr erfahren
GMP-Risikoanalysen

Image

Standardvorlagen für Räume und Ausrüstung im pharmazeutischen Umfeld

Einfach, schnell und günstig zur Risikoanalyse

>>> Jetzt informieren: GMP-Risikoanalysen

Image

31. Januar bis 02. Februar 2017, Messe Stuttgart

Wir freuen uns auf Ihren Besuch an unserem Stand.

>>> mehr Informationen

GMP LOGFILE: Leitartikel

LOGFILE Nr. 39/2013 - GMP-Compliance bei IT-Projekten

GMP-Compliance bei IT-Projekten

von Susanne Sailer

 

Funktionierende IT-Systeme sind Voraussetzung für reibungslose Abläufe in der Pharmabranche. Viele von diesen Prozessen sind GMP-relevant, die Ressourcenplanung, das Fertigungs- oder Dokumentationsmanagement, um nur einige zu nennen. Wie man GMP-Compliance bei der Implementierung und im laufenden Betrieb von elektronischen Systemen sicherstellt, wurde an einer Dialogrunde bei den GMP-BERATER Tagen intensiv diskutiert.

Englisch und Deutsch, das Wechseln von der einen in die andere Sprache ist in der pharmazeutischen Industrie an der Tagesordnung. Undurchsichtiger wird es, wenn sich dazu noch eine weitere „Sprache“ gesellt. IT-Spezialisten und Softwareentwickler verfallen gerne in einen Jargon, der für Außenstehende meist mehr verwirrend als erhellend ist. Häufig kommt es zu Verständigungsproblemen zwischen Computerfachleuten und Pharmaspezialisten. Die GMP-BERATER Tage boten für viele Teilnehmer willkommene Gelegenheit, sich mit Experten zu unterhalten, die sich in beiden Welten gleichermaßen zu Hause fühlen: Thilo Gukelberger von d.velop life sciences, Karl-Heinz Menges vom Regierungspräsidium Darmstadt und Dr. Ralf Weber von gempex.

Zuständigkeiten sind delegierbar

Prinzipiell kann jede Art von IT-Dienst-leistung ausgelagert werden. Für viele Unternehmen ist dies eine verlockende Option, da sie so kaum mehr eigene IT-Infrastruktur, Softwareentwicklung und nur noch wenig eigenes IT-Personal benötigen. Diesen Vorteilen steht aber der mit Outsourcing immer verbundene, wesentlich höhere Managementaufwand entgegen. Erste Hürde bei der Vergabe von IT-Dienst-leistungen bildet meist das sogenannte Service Level Agreement (SLA), das die Zuständigkeiten der beiden Vertragspartner klar abgrenzt. Diese sollten zu einem möglichst frühen Zeitpunkt in einer Projektphase sauber und klar abgesteckt werden. Dabei macht es keinen Unterschied an wen die Aufgaben vergeben werden – betriebsintern an eine Abteilung bzw. einen Bereich, konzernintern an eine Mutter-, Tochter- oder Schwestergesellschaft oder an einen Dritten.

Verantwortlich für die Validität der Systeme ist und bleibt der Betreiber. Dr. Ralf Weber: „Sie können im IT-Bereich Zuständigkeiten outsourcen, aber nicht die Verantwortung für die Validität der Systeme. Mit einem SLA gibt man die Validierungsverantwortung nicht ab, sondern es muss sich eine kontinuierliche Überwachung der Güte der Services anschließen.“ Karl-Heinz Menges ergänzt: „In der Herstellung spricht man bei Outsourcing von einer Verantwortungsabgrenzungsvereinbarung. Nicht von ungefähr verwendet man in der IT-Branche den Ausdruck SLA. Denn der Auftraggeber hat hier immer die Pflicht zur Kontrolle und Aufsicht. Rechtlich gesehen ist die Verantwortliche beziehungsweise die Sachkundige Person Garantenträger.“

„Fertige Software“ gibt es nicht

Eine Frage, die für heftige Diskussion und auch einige Heiterkeit sorgte: Muss „fertige Software“ denn überhaupt noch validiert werden? Auch bei einer Standardsoftware gibt es immer die Möglichkeit, diese zu parametrisieren. „Fertig“ und „Software“ seien daher zwei Begriffe, die nicht zusammengehen. Gemeint war mit dem Ausdruck wohl sogenannte „Commercial-off-the-Shelf-Software“. Darunter versteht man Standardsoftware-Pakete, die nach erfolgter Installation auf einem Rechner nicht mehr geändert oder angepasst, sondern sofort genutzt werden. Im Annex 11 ist der Validierungsansatz dafür definiert: Es braucht eine klar umrissene Anforderungsspezifikation. Im einfachsten Fall genügt dafür ein kurzes Lastenheft mit Verweis auf die Herstellerdokumentation, wie z.B. auf das Bedienhandbuch. Im nächsten Schritt erfolgt die Verifikation, das heißt der dokumentierte Nachweis, dass die Software die Anforderungen erfüllt. GMP-Consultant Dr. Ralf Weber: „Validierung bedeutet die Verifikation von Anforderungen. Deshalb muss vorab genau definiert und dargelegt sein, was man von einer Software erwartet.“

Standardsoftware braucht man in ihrer Grundfunktionalität nicht mehr zu validieren. Thilo Gukelberger plädierte deshalb dafür, sich bei der Validierung von gängigen IT-Systemen auf GMP-relevante Prozesse zu konzentrieren. Die Verbreitung ist aber nicht alleiniges Kriterium. Wichtig ist beispielsweise auch, wie offen Hersteller Fehler kommunizieren. Der Annex 11 fordert die Bewertung von Lieferanten. Das muss nicht immer gleich ein Audit vor Ort bedeuten. Auch das Einholen von Referenzen über Lieferanten gehört dazu.

Einbindung der Lieferanten

Eines wurde während der Diskussion deutlich: Je näher man an einer Standardsoftware bleiben und seine Anforderungen über reine Konfiguration abdecken kann, um so geringer wird der Aufwand. Thilo Gukelberger: „Bei jeder Software gibt es Konfigurationsmöglichkeiten, wie zum Beispiel Schalter zu setzen oder Schwellenwerte vorzugeben. Für den Computer-Laien ist nicht immer ersichtlich, wo die Grenze zur Programmierung liegt. Letztlich ist es entscheidend, das Risiko abzuschätzen, wenn man vom Standard abweicht. Minimale Anpassungen, wie das Ziehen von Stammdaten aus einem anderen System, sind strenggenommen schon Programmierungen, die durch andere Qualitätssicherungsmaßnahmen abgefangen werden müssen.“

Die in GAMP geforderte Lieferanteneinbindung in den Validierungsprozess wird gerne als Einladung verstanden, am Ende alles an diese abzugeben. Irrtümlicherweise, so die Reaktion der Experten. Zwar muss der Betreiber beispielsweise eine Installationsqualifizierung oder die Überprüfung der Basisfunktionalität nicht selbst übernehmen, aber er muss die Testprotokolle in die Validierung einbinden, durch die eigene Qualitätsabteilung prüfen, die Durchführung freigeben, überwachen und das Ergebnis beurteilen. Dr. Ralf Weber: „Als Auftraggeber haben Sie letzten Endes die Pflicht, die Black Box in eine Grey Box zu verwandeln. Der Auftraggeber muss sich ein klares Bild davon machen, wie ein Softwarelieferant arbeitet und abhängig von der Kritikalität, der Komplexität und der Neuartigkeit der Projekte entscheiden, ob dieser geeignet ist. Lieferanten tun gut daran sich entsprechend aufzustellen, die Karten offenzulegen und transparenter zu werden.“

Excel nicht universell einsetzbar

Heftig diskutiert wurde die Verwendung von Excel als „Quasidatenbank“, wodurch sich Fachabteilungen großer Unternehmen gerne unabhängig von der Zentral-IT machen. Dagegen sei per se nichts einzuwenden, so die Experten. Sie warnten aber davor, Excel universell einzusetzen. Karl-Heinz Menges: „Excel hat den Vorteil, dass es leicht zu bedienen ist. Das ist aber auch sein großer Nachteil. Es handelt sich bei den Excel-Tabellen um Qualitätsdokumente. Man verwendet Templates/Vorlagen und diese müssen entsprechend geschützt sein.“

Bei einem Versionswechsel übrigens, muss nicht jedes Excelsheet neu validiert werden. Es kann ausreichen, die Funktionalität für jedes Template beispielhaft zu prüfen. Dr. Ralf Weber: „Bei großen Versionswechseln sollte man risikobasiert nachweisen, dass alles noch funktioniert und dass die Werte richtig übergeben werden.“ Das Problem seien übrigens meist nicht die neuen Funktionalitäten, die neue Versionen mit sich bringen, sondern „alte Zöpfe, die abgeschnitten wurden und nicht mehr funktionieren.“ Thilo Gukelberger: „Eigentlich ist es ein Unding, neue Softwareversionen zu erhalten ohne die Information, welche Altfunktionen obsolet sind oder welche sich anders darstellen. Aber bei großen Anbietern ist das leider oft der Fall. Das Risiko ist beim Anwender. Er muss nachprüfen, ob GxP-relevante Prozesse in irgendeiner Weise betroffen sind.“

Die Experten warnten ausdrücklich davor, komplexe Aufgaben mit Standard-Werkzeugen zu prozessieren. Das trifft nicht nur auf Excel zu, sondern auch zum Beispiel auf das Programm Access von Microsoft. Es wurde für Privatanwender entwickelt und ist weit entfernt von einem voll ausgereiften, professionellen Datenbanksystem.

An den GMP-BERATER Tagen konnten zahlreiche Fragen geklärt werden. Bei vielen handelte es sich um die Definition von Begrifflichkeiten, denn oft rühren Unklarheiten – wie eingangs erwähnt – vom Aufeinanderstoßen verschiedener Disziplinen und Fachsprachen. Dr. Ralf Weber abschließend: „Es braucht gute Berater mit Schnittstellenqualifikation. Als neutrale Moderatoren übersetzen sie wechselweise die Wünsche des Pharmazeuten und die Statements der Programmierer und bringen so beide Welten sukzessive zusammen.“

Autorin:

Susanne Sailer - Maas & Peither AG - GMP-Verlag

Icon Leitartikel als PDF öffnen
Kommentare
Es wurden bisher noch keine Kommentare zu dieser News geschrieben