Kann die Cloud eine GxP-konforme Lösung für die Pharmaindustrie sein?

Experteninterview

Einleitung

Bereits in den letzten Ausgaben der PM QM ging es um die Einbindung Cloud-basierter Lösungen im Pharmaumfeld. Gerade für diese sehr stark regulierte Industrie stellen sich viele Fragen, wie geeignet und konform ein Cloud-basierter Ansatz ist bzw. sein kann. Gängige Cloud-Modelle wurden kurz und übersichtlich präsentiert und besondere Anwendungsfälle vorgestellt. Das folgende Experteninterview liefert kurz und kompakt Einblicke in die Sicht- und Denkweisen eines XaaS Dienstleisters (X as a Service, wobei das X hier gemäss dem letzten Beitrag für eines der verschiedenen Cloud-Modelle steht), eines Pharmaunternehmens als Kunden, eines Cloud-Providers als Dienstleister, eines Vertreters einer deutschen Behörde und eines Anwendungsproviders.

Zum besseren Verständnis dieser Cloud-Modelle werden nachfolgend drei Kernbegriffe nochmals erklärt:

• Cloud-Provider: Hierbei handelt es sich um einen Anbieter von Cloud-Lösungen, wie z. B. Amazon, Microsoft, Google etc., der die Cloud-Infrastruktur (Hardware bzw. Software) zur Verfügung stellt.

• Anwendungsprovider: Dies ist diejenige Organisation, z. B. ein Unternehmen oder eine Contract Research Organization (CRO), die dem Endkunden eine Cloud-Lösung für eine Applikationsanwendung zur Verfügung stellt oder diese im Auftrag des Kunden betreibt. Der Anwendungsprovider nutzt dafür die Dienste eines Cloud-Providers. Beispiel: Kunden, die eine Reise planen, nutzen dazu z. B. das Online-Reiseportal Expedia. Expedia ist hierbei der Anwendungsprovider, der dem Reisenden seine Dienstleistungen anbietet. Expedia selbst nutzt für seine Kunden den Cloud-Provider Amazon Web Services.

• Kunde: Der Kunde nutzt die Cloud-Lösung für sich oder sein Unternehmen.

Das folgende Experteninterview gibt Antworten auf allgemeine Fragen, die alle Beteiligten gleichermassen beschäftigen. Der hier abgebildete Fragenkatalog ist selbstverständlich nicht allumfassend, und die Antworten der jeweiligen Parteien spiegeln deren persönliche Meinung, ihre beruflichen Erfahrungen und Praxis wider und sollten daher nicht als allgemeingültiger Standard angesehen werden. Dieser Beitrag schafft vielmehr eine Grundlage, auf der alle in einen Cloud-Implementierungsprozess eingebundenen Parteien aufbauen können. Die ausgewählten Fragen bilden den Konsens der fünf Autoren und sind ihrer Einschätzung nach die wichtigsten, die gestellt werden müssen.

Die grundlegende Idee

In diesem Artikel geht es um die Speicherung von Daten auf Servern externer Supplier, wobei zwei grundsätzliche Aspekte unterschieden werden müssen.

Einerseits ist die Speicherung von Daten auf Servern diverser Provider selbst bereits gängige Praxis. Der nachfolgende Artikel geht jedoch nicht auf die Frage ein, um welche Daten es sich konkret handelt, sondern bleibt angesichts der Komplexität des Themas eher allgemein. Die Verwendung des Begriffs "GMP Daten" würde die Sache verkomplizieren, und ein solcher Artikel würde den Rahmen der Zeitschrift sprengen. Die wenigsten Unternehmen würden ihre Batch Reports extern ablegen. Mit Dokumenten wie SOPs oder Guidance Dokumenten sind wir heutzutage jedoch bereits ein Stück weiter.

Der zweite Aspekt, und vermutlich der interessantere, ist die Speicherung von Daten durch Dritte. Zweckdienlich und transparent ist es vermutlich, die Thematik anhand eines Beispiels zu beleuchten. Somit wird das Thema an folgender Fragestellung erläutert: Datenlogger-Leasing – was passiert mit diesen Daten?

Hierauf basierend sind die Fragen einfacher zu verstehen bzw. zu beantworten, sollten aber nicht auf alle anderen Bereiche übertragen werden.

Die «Cloud» ist uns allen vertraut. Sie ist vielerorts aus unserem Alltag nicht mehr wegzudenken und erleichtert uns das persönliche Leben. Die Zeiten, in denen wir uns Gedanken machen mussten, wie wir Daten von A nach B bekommen, damit auch jemand anderes auf diese zugreifen kann, gehören der Vergangenheit an. Wie bereits im vorherigen Artikel erläutert, wird die Cloud zunehmend in industriellen Anwendungen eingesetzt. Was auch gut ist, denn in Zeiten von Klimawandel, Lean Management und Globalisierung braucht es auch hier ein Umdenken. Schneller, effizienter und klimafreundlich sind somit nur einige der wichtigen Stichwörter. Dennoch gestaltet sich die Einführung und Anwendung von Cloud-basierten Lösungen in vielen Bereichen potenziell schwierig. Gründe dafür gibt es viele, vor allem aber sind es Bedenken hinsichtlich der Einhaltung von Vorgaben in Richtlinien, Gesetzen und Verordnungen, der Wahrung der Datenintegrität, Datensicherheit, Rückverfolgbarkeit, Ausfallsicherheit etc. Aus diesem Grund haben sich alle Parteien der Lieferkette bis hin zur Behörde zusammengetan, um Antworten auf die wichtigsten Fragen als Grundbaustein für die Entscheidung zu liefern: Cloud, ja oder nein? Allenfalls muss an dieser Stelle der Begriff Cloud «vermieden» werden, da es sich technisch gesehen um einen Server und die dazugehörige Kunden-Schnittstelle handelt.

Wem gehören die Daten in der Cloud und auf was muss ich als Kunde in den Verträgen mit dem Anwendungsprovider beachten?

AT: Ich möchte in diesem Zusammenhang den Begriff RU («regulated user», entspricht dem Lizenzinhabers HE, IE, ...) verwenden. Gemäss § 10 Absatz 2 der Arzneimittel- und Wirkstoffherstellungsverordnung (AMWHV) ist der RU dafür verantwortlich, dass bei Aufzeichnungen mittels elektronischer, fotographischer oder sonstiger Daten-Verarbeitungssystemen das System ausreichend validiert werden muss. Es muss mindestens sichergestellt sein, dass die Daten für die Dauer der Aufbewahrungsfrist zur Verfügung stehen und innerhalb einer angemessenen Frist lesbar gemacht werden können. Die gespeicherten Daten müssen vor Verlust und Beschädigung geschützt werden. Zudem muss der RU die europäische Datenschutz-Grundverordnung (DSGVO) einhalten. Kritisch sind vor allem nicht vertrauliche und/oder personenbezogene Daten. Dieses ist z. B. für klinische Plattformen oder Blutbanksoftware relevant, die als SaaS über ein Cloud-basiertes Modell bereitgestellt werden. Aus technischer Sicht sind territoriale Grenzen im Cloud Computing natürlich unerheblich. Für das geltende Recht ist jedoch der Ort der Verarbeitung relevant.

Bei der Gestaltung von Verträgen (SLA) mit dem Cloud Service Provider (CSP) sollten folgende Aspekte beachtet werden:

• Serviceumfang, Responsezeiten, Verfügbarkeit

• Server-/Datenstandorte

• Subunternehmer, Dienstleister des CSP

• Zertifizierung, Nachweis der Erfüllung von Sicherheitsstandards 

• Kommunikations- und Ansprechpartner

• Möglichkeit und Tools für das Monitoring des Service

• Umgang mit Sicherheitsereignissen

• Regelungen zum Vorgehen bei Änderungen

• Escape-Strategien, Business Continuity

• Vertragsstrafen bei Nichteinhaltung der Vereinbarungen

PO: Die Data Ownership, also die Frage, wem die Daten gehören, muss in jedem Fall vertraglich geklärt werden. Geht es um Monitoring-Daten, ist es meiner Meinung nach klar, dass diese dem Kunden gehören. Allerdings könnten sich in Zukunft weitere Fragestellungen ergeben. Beispielsweise ob der Kunde als Dateneigner dem Anwendungsprovider ein anonymisiertes Nutzungsrecht einräumen möchte, damit dieser auf Basis der Daten vieler Kunden eine Heat Map der Problempunkte im globalen Transportnetzwerk aggregieren kann. Dies würde dem Kunden einen Vorteil im Hinblick auf die bessere Planung seiner Transportwege verschaffen. Wichtig ist, wie gesagt, eine klare vertragliche Regelung.

Welche Bedeutung hat der geographische Standort, d.h. der Standort der Server?

AT: Die Wahl des geographischen Speicherortes ist relevant, wenn Sie sicherstellen möchten, dass Dritte auf Grund bestehender nationaler Gesetze nicht auf Daten des RU zugreifen können sollen (Beispiel USA) und der RU dadurch vermeiden kann, gegen die DSGVO zu verstossen. Eine andere Motivation besteht darin, dass der RU sein geistiges Eigentum schützt, indem er den Speicherort spezifiziert. Die Tatsache, dass der physische Speicherort der einzige Ort ist, an dem die Daten gespeichert werden und keine weiteren Backups oder IaaS bei, beispielsweise, Subunternehmen in anderen geographischen Regionen existieren, sollte im SLA fixiert und im Rahmen der CSP-Qualifizierung verifiziert werden.

PO: Der geographische Speicherort ist aus Gründen des Datenschutzes und weitere rechtlichen Gründen entscheidend, um den Zugriff durch unerwünschte «Autoritäten» zu verhindern. Demgegenüber sollte angesichts des zunehmenden Einsatzes von Datenbank-Clustern auch für On-Premise-Lösungen die Frage nach dem genauen Server bzw. der exakten Festplatte keine Rolle mehr spielen.

Macht es aus regulatorischer Sicht einen Unterschied, ob ich eine private Instanz der in der Cloud betriebenen Anwendung nutze oder eine geteilte Instanz?

AT: Basierend auf den Ergebnissen des Data Assessments, des Assessment der Kritikalität der Applikation und des Assessments zur Business Continuity sollte die Entscheidung getroffen werden, ob ein Outsourcing und insbesondere die Nutzung eines CSP möglich ist, ohne die Patienten und/oder die Qualität des Arzneimittels zu gefährden. Wird ein Outsourcing beschlossen, sollte das Bereitstellungsmodell auf Grundlage der Kritikalität gewählt werden. Private- und Community-Cloud-Modelle sind für vertrauliche Daten der Public Cloud vorzuziehen. Die Art und Weise, wie unterschiedliche Mieter abgegrenzt und voneinander getrennt werden, hängt vom Bereitstellungsmodell ab und ist in einer Private Cloud besser als in einer Public Cloud.

PO: Solche Entscheidungen müssen selbstverständlich immer risikobasiert getroffen werden. Aus technischer Sicht liesse sich argumentieren, dass für GxP-Anwendungen eine sichere Steuerung der Zugriffe auf Benutzerebene gewährleistet sein muss, also auf einer granulareren Ebene als zwischen unterschiedlichen Organisationen, die sich eine Instanz einer Cloud-Anwendung teilen. So gesehen sollte aus Sicht der Datensicherheit und Datenintegrität die Frage nach Public oder Private Cloud keine Rolle spielen. Allerdings wird es i. d. R. Unterschiede bei anderen wichtigen Aspekten geben, bspw. bei der Bestimmung von Zeitpunkten für das Einspielen von Updates. Hier bieten private Instanzen durchaus Vorteile.

Welche Dokumentation seitens des Cloud-Providers muss mindestens vorliegen? Ist ein aktueller SOC 2-Bericht ausreichend?

AT: Gemäss Annex 11 sind Kompetenz und Zuverlässigkeit des Lieferanten Schlüsselfaktoren bei der Auswahl eines Produktes oder eines Dienstleisters. Die Notwendigkeit eines Audits sollte auf einer Risikobewertung basieren. Mit anderen Worten: Je höher die Anforderungen an den Service und das Bereitstellungsmodell sind, desto wichtiger ist die Qualifizierung und das fortlaufende Monitoring eines CSP. Eine mangelhafte Konfiguration der Infrastruktur kann zum Ausfall des Service oder zum Verlust oder Kompromittierung der Daten führen. Auf Basis einer Risikobewertung muss entschieden werden, ob ein Audit vor Ort erforderlich ist. Eine Zertifizierung kann die Compliance mit Sicherheitsstandards bescheinigen. Vorzuziehen sind internationale Normen, die die spezielle Thematik des Service adressieren: ISO/IEC 27001 Information technology – Security techniques – Information security management systems – Requirements, ISO/IEC 27017: Cloud Computing Security and Privacy Management System-Security Controls, ISO/IEC 27036-4: Guidelines for security of cloud services. In jedem Fall sollte der Scope des Zertifikates bewertet werden.

Wie auditiere ich einen Cloud-Provider, wenn dieser keine Audits zulässt?

AT: Wenn das Ergebnis der Bewertung zeigt, dass ein Audit vor Ort erforderlich ist, ist ein CSP, der dieses nicht zulässt, nicht geeignet. An dieser Stelle sollte auf die Möglichkeit von Joint Audits oder Shared Audits hingewiesen werden.

BN: Es besteht auch immer die Möglichkeit, bei einem Cloud-Provider ein Joint Audit anzufragen. Das bedeutet, dass sich mehrerer Unternehmen/Kunden zusammenschliessen und gemeinsam ein für alle gültiges und anwendbares Audit durchführen. Das reduziert den Aufwand bei allen Seiten, liefert aber gleichzeitig einen guten Nachweis der Einhaltung rechtlicher und kundenseitiger Vorgaben. Ein solches wird bspw. gerade bei Amazon Cloud Services in München geplant.

Wie kann eine Cloud validiert werden? Welche Ansätze sind unbedingt notwendig?

AT: Die Applikation muss validiert und die Infrastruktur qualifiziert werden. Die Validierung der Applikation entspricht im Wesentlichen der einer On-Premise-Applikation. Annex 11 und GAMP®5 liefern hier entsprechenden Hinweise. Die Herausforderung ist die Trias aus CSP, RU und Softwareanbieter. Hier sind gute Kommunikation und gutes Projektmanagement gefragt.

Die Qualifizierung einer dynamischen Infrastruktur, die zudem einer sehr dynamischen Weiterentwicklung unterliegt, ist die eigentliche Herausforderung. Hier bestehen häufig Schwächen auf Seiten des CSP, dem RU gegenüber die sogenannten „documented evidence“ zur Verfügung zu stellen, die es dem RU ermöglicht, von einer qualifizierten Infrastruktur auszugehen.

PO: Bei der Validierung von GxP-relevanten Anwendungen, wie sie ELPRO bereitstellt, gibt es keine Unterschiede zwischen Cloud-basierten und On-Premise-Lösungen.

Wie können die Eigentümerrechte von Daten geschützt werden?

PO: Da die Eigentümerrechte von Daten mit denen von anderen Sachgegenständen identisch sind, können aus unserer Sicht die gleichen Schutzmechanismen analog angewendet werden:

• Datenzugriff auf die Kundendaten durch den Cloud-Provider muss sehr klar definieren und vertraglich festhalten werden.

• Datenzugriff des Anwendungsproviders auf Kundendaten muss strikt begrenzt sein (Zugriff auf den Root-Server haben nur sehr wenige, ausgewählte Mitarbeiter des Anwendungsproviders).

• Zugriffe auf Kundendaten durch den Anwendungsprovider über den Root-Server werden in einem Audit-Trail protokolliert und erfasst.

• Zugriffe von Dritten werden durch klar definierte Sicherheitsmechanismen so weit wie möglich unterbunden. Die Infrastruktur wird kontinuierlich auf Hackerangriffe überwacht. Erfolgreiche Hacking-Angriffe werden analysiert und dokumentiert. Gehackte Zugriffsdaten (Passwörter etc.) müssen umgehend vom Cloud-Provider oder Anwendungsprovider durch neue ersetzt werden. Der Kunde wird über den Datenangriff informiert, und die neuen Zugriffsdaten werden übermittelt. Die Sicherheitslücke wird schnellstmöglich durch geeignete Massnahmen abgestellt und geschlossen. Falls möglich wird der Hackerangriff zurückverfolgt.

• Auf Wunsch des Kunden müssen die Daten durch den Anwendungsprovider sicher und unwiderruflich vernichtet werden, z. B. nach Vertragsende.

• Sämtliche oben genannten Punkte, und sicherlich noch viele weitere, sollten im SLA klar benannt und definiert sein. Der Anwendungsprovider sollte entsprechende Klauseln in den SLA mit dem Cloud-Provider aufnehmen, und der Kunde sollte entsprechende SLA-Vereinbarung mit dem Anwendungsprovider haben.

Wie kann ich Datenintegrität in der Cloud gewährleisten, wenn ich nicht selbst der Eigner der Cloud bin?

AT: Gemäss Annex 11 sollten physikalische und elektronische Massnahmen getroffen werden, um Daten vor Beschädigung zu schützen. Die Verfügbarkeit, Lesbarkeit und Richtigkeit der gespeicherten Daten sollten geprüft werden. Der Zugriff auf Daten sollte während des gesamten Aufbewahrungszeitraums gewährleistet sein. Nach Ansicht des Bundesamtes für Sicherheit in der Informationstechnik (BSI) kann dieses nur durch kryptographische Verfahren gewährleistet werden. Diese Ansicht teile ich.

PO: Verschlüsselungen bilden den logischen ersten Ansatzpunkt. Um Manipulationen wirksam auszuschliessen, sind auch Blockchain-basierte Lösungen eine Option. Allerdings stehen der zusätzlichen Sicherheit hohe Rechenaufwände und letztlich auch die verteilte Datenhaltung in Blockchains gegenüber. Dennoch werden wir zukünftig neue Lösungen in diesem Bereich sehen.

Kenne ich immer die Speicherorte meiner Daten? Und kann ich darauf Einfluss nehmen?

AT: Sofern der Speicherort kritisch ist, muss dieser im Rahmen des SLA festgelegt und im Rahmen der Qualifizierung verifiziert werden. Dies ist nicht nur GxP kritisch, sondern auch für das Business von größter Bedeutung.

Wie werden Cloud-Server vor externen Zugriffen geschützt? Wer ist für diese Sicherung verantwortlich und letztlich haftbar? Werden sensible Daten (Patientendaten, Studienergebnisse etc.) anders behandelt als nicht sensible Daten? Können Cloud-Daten gelöscht werden?

AT: Es muss für den RU gewährleistet sein, dass seine Daten auf allen Speichermedien und –orten sowie in allen Versionen (z. B. verschiedene Backup-Versionen) bei Beendigung der Geschäftsbeziehung oder auf Wunsch des RU gelöscht werden. Dies sollte Bestandteil des SLA und der Qualifizierung sein.

Gibt es so etwas wie einen Audit Trail in der Cloud (Nachvollziehbarkeit, wer wann welche Änderungen in der Cloud gemacht hat)?

AT: Ja, zumindest sollte eine Log-Datei verfügbar sein.

Wie kann ich während des Audits eines Cloud-Providers sicherstellen, dass es sich genau um diese Server handelt, die meine Daten hosten? Wie trainiert sind Cloud-Provider auf regulatorische Vorgaben wie GAMP®5 und 21CFR Part 11?

AT: CSP müssen nicht nach GAMP®5 oder 21CFR Part 11 arbeiten. Sie müssen jedoch über ein geeignetes Framework verfügen, welches äquivalenten Prinzipien folgt. Wenn sich dieses Framework an den Grundsätzen des EU-GMP-Leitfadens und/oder GAMP®5 orientiert, ist dies für die Pharmaindustrie von Nutzen.

Ist es notwendig und technisch möglich, die Speicherung von Daten sowie deren Attribute über einen regelmässigen Report zu verifizieren?

AT: Gemäss Annex 11 ist die IT-Infrastruktur (IaaS, PaaS) zu qualifizieren und die Anwendung (SaaS) zu validierten. Explizit auf die Datenspeicherung bezogen muss gewährleistet sein, dass Daten durch physikalische und elektronische Massnahmen vor Beschädigung geschützt werden und dass Verfügbarkeit, Lesbarkeit und Richtigkeit der gespeicherten Daten geprüft werden. Der Zugriff auf Daten sollte während des gesamten Aufbewahrungszeitraums gewährleistet sein. Im Folgenden sind Anforderungen an die Qualität des CSP und die Datenintegrität (für Daten in Bewegung und in Ruhe) formuliert, die sich so explizit nicht im EU-GMP-Leitfaden wiederfinden, jedoch aus Sicht der EFG 11 als sinnvoll erachtet werden:

• Übertragung von Daten nur in verschlüsselter Form und in einer Art und Weise, die sicherstellt, dass die Daten vollständig und unverändert übertragen wurden.

• Die Art der Speicherung kritischer Daten ist risikobasiert festzulegen (z. B. Nutzung geeigneter kryptographischer Verfahren).

Welche Dokumentation seitens des Providers muss mindestens zur Verfügung stehen? Welchen Umfang muss die Qualifizierung des Systems ausweisen?

AT: Grundsätzlich gelten die gleichen Anforderungen an einen CSP wie an einen regulierten Nutzer. In der Praxis werden häufig folgende Defizite beobachtet:

• Die Qualifizierung der Infrastruktur ist nicht dokumentiert.

• Änderungen an der Hard- und Middleware sowie den sicherheitsrelevanten Komponenten erfolgen ohne Zustimmung des Lizenzinhabers. Eine Benachrichtigung über Änderungen erfolgt kurzfristig oder gar nicht.

• Das QM-System des CSP entspricht nicht den EU-GMP-Standards.

• Ohne vorherige Zustimmung des Lizenzinhabers werden Subunternehmer/Dienstleister vom CSP eingesetzt, um die Infrastruktur (Rechenleistung, Storage) zu erweitern. Datenschutzrechtliche Bestimmungen bleiben unberührt.

Fazit

Fragen und Bedenken gibt es viele. Wahrscheinlich nahezu unendlich viele. Nichtsdestotrotz haben wir die aus unserer Sicht wichtigsten Fragen mit den entsprechenden Antworten aus verschiedener Perspektive zusammengefasst. Letztlich liegt die Verantwortung aber beim Kunden und damit beim Anwender der Cloud. Der Kunde allein entscheidet, ob, wie und welchen Weg er gehen möchte, um diesem Thema gut vorbereitet zu begegnen. Die Patientensicherheit ist und bleibt das wertvollste Gut, das es im Pharmabereich zu schützen gilt. Software muss funktionieren, Daten müssen verfügbar, manipulationsgeschützt, rückverfolgbar und integer sein. Unterschriften und Authentizität sind ebenso wichtig. Daten sind das, was unseren digitalen Alltag heute ausmacht: unser virtuelles Lebenselixier. Jeder von uns muss selbst entscheiden, wem er sie anvertrauen kann. Die gelieferten Antworten sollen und können hoffentlich bei einer solchen Entscheidung helfen. Wohlwissend, dass diese nicht abschliessend sind und es auch nie sein können.

LADEN SIE HIER DEN ORIGINALEN BEITRAG HERUNTER

Veröffentlicht in PM QM Ausgabe 11/2020

Autoren

Dr. Arno Terhechte, Bez. Reg. Münster Regierungspharmaziedirektor, Bezirksregierung Münster, war nach dem Studium der Pharmazie und anschließender Promotion fünf Jahre in der Pharmazeutischen Industrie in den Geschäftsbereichen nationale Zulassung, internationale Zulassung und Qualitätskontrolle, zuletzt in der Funktion als stellv. Kontrollleiter, tätig. Seit 1998 war er bei der Bezirksregierung Düsseldorf in der Überwachung von Arzneimittelherstellern, seit 2003 ist er bei der Bezirksregierung in Münster im Pharmaziereferat tätig. Hier führt er neben der Überwachung von Arzneimittelherstellern Begehungen von Medizinprodukteherstellern und -betreibern durch. Er ist Leiter der Expertenfachgruppe 11 Computergestützte Systeme und Mitglied der Arbeitsgemeinschaft für Pharmazeutische Verfahrenstechnik e.V. (APV) Fachgruppe „Informationstechnologie“.

Patrick Pichler, Director, Head of Global Distribution, Artwork & Product Security Quality, ist studierter Biotechnologe und hat acht Jahre für die Österreichische Agentur für Gesundheit und Ernährungssicherheit (AGES) als Inspektor gearbeitet. Vorher war er elf Jahre unter anderem als Leiter Qualitätskontrolllabor in mehreren Firmen tätig. Seit 2019 ist er bei Merck beschäftigt und seit 2014 in der Rolle Head of Distribution Quality im Bereich Good Distribution Practice
(GDP) zuständig.

Dr. Philipp Osl, CEO ELPRO-BUCHS AG, ist CEO der ELPRO Gruppe. Neben seinem Studium in Wirtschaftsinforma
tik und einem Doktorat in „Business Innovation“ blickt er auf Erfahrungen als Projektleiter, Produktmanager und Gründer eines Technologie-Start-ups mit Niederlassungen in der Schweiz und Polen zurück.

Björn Niggemann, Präsident GQMA, ist seit April 2016 bei der ELPRO-BUCHS AG als Chief Quality Offi cer tätig. 2004 war er zunächst mit dem Aufbau und der Implementierung von GMP parallel zur bestehenden DIN ISO 17025-Zertifi zierung beauftragt. 2007 hat er als Compliance Manager zu einem bestehenden Good Laboratory Practice (GLP) System ein GMP-System aufgebaut. Von 2009 bis 2010 arbeitete er bei einem Pharmadienstleister als GLP/cGMP Compliance Manager. 2010 bis 2016 war er in einem Schweizer Biotech-Unternehmen in der Rolle des Head of Operations and Quality tätig. Er ist zudem Präsident der GQMA – Germany Quality Management Association e.V.