05 Mai GAMP5 Second Edition – Appendices Teil 2
Die Second Edition der Guideline GAMP5: „A Risk-Based Approach to Compliant GxP Computerized Systems“ wurde im Juni 2022 veröffentlicht. In unserem letzten Blogpost haben wir die ersten vier der acht neuen Anhänge des Leitfadens vorgestellt. In diesem Beitrag geht es nun um die Inhalte, der Entwicklungsanhänge (D8, D9, D10, D11), die wir kurz und knapp für Sie zusammengefasst haben. In den Anhängen geht es um hoch aktuelle innovative Themen, wie Machine Learning sowie Artificial Intelligence, Cloud Computing, Blockchains und Open-Source Software.
Anhang D8 – Agile Software Development
Im neu hinzugekommenen Anhang D8 – „Agile Software Development des GAMP5 2nd Edition“ wird erläutert, wie bereits gut entwickelte und etablierte agile Prozesse genutzt werden können, um Software für GxP-Applikationen bereitzustellen. Zum Einen wird besonders betont, dass Agilität nicht für GxP-Konformität angepasst werden muss und soll. Zum Anderen wird hervorgehoben, dass die Anwendung agiler Prozesse kein Grund sei, ein geringeres Level an Qualität oder GxP-Konformität zu akzeptieren.
Im Vordergrund des Kapitels stehen vor allem die Dokumentation und die Testung bei der Anwendung agiler Prozesse.
Die Verwendung von Tools gestattet es neue agile Dokumentationsweisen zu etablieren. Das „Mapping“ von Dokumenten des V-Modells auf beispielsweise Scrum (als ein agiles Vorgehensmodell) soll aber vermieden werden. Eine gute Auswahl an Tools kann den Bedarf an zusätzlicher Dokumentation auf ein Minimum reduzieren. Bei der Anwendung von Tools müssen aber alle relevanten Informationen wie Lieferantenbewertung, Schulung, Periodic Review, usw. dokumentiert werden.
Allgemein gilt für die Testung der Funktionalitäten, dass diese, Teil der Sprints sind – das finale User Acceptance Testing sollte dementsprechend minimiert werden. Des Weiteren sollten Regressionstest in jeden Sprint aufgenommen werden. Das gesamte Ausmaß an Testungen lässt sich i.d.R. dann nur durch Testautomatisierung realisieren, minimiert jedoch dadurch auch den Gesamttestaufwand erheblich.
Appendix D9 – Software Tools
Im Appendix D9 geht es um Tools, die nicht Teil des regulierten Prozesses sind und somit keine direkte Auswirkung auf GxP-Daten haben. Diese Tools gehören der GAMP-Kategorie 1 an. Sie müssen nicht validiert werden und unterliegen nicht den entsprechenden strengen aufsichtsrechtlichen Vorschriften. Im Anhang wird stattdessen empfohlen sie durch routinemäßige Bewertungen und IT-Praktiken des Unternehmens zu verwalteten. Als äußerst hilfreich wird eine Übersicht der genutzten Tools im Unternehmen angesehen.
Insgesamt sollte die Intensität der Kontrolle der beschriebenen Tools, dem durch sie induzierten Risiko entsprechend geringer ausfallen. Trotzdem ist die Durchführung einer Risikobewertung sinnvoll, da diese die Auswahl der Tools unterstützen kann und deren Zuverlässigkeit nachweist.
Auch der Aspekt der Cyber Security soll für die Tools betrachtet werden. Tools, die im gesamten Netzwerk eingesetzt werden, z.B. für Leistungsüberwachung, erfordern eine detaillierte Sicherheitsanalyse. Außerdem sollte bei den Tools über die gesamte Aufbewahrungsfrist die Datenintegrität und die Zugriffverwaltung gewährleistet sein.
Appendix D10 – Distributed Ledger Systems (Blockchain)
Anhang D10 schildert Überlegungen, die ein Unternehmen anstellen sollte, wenn es Blockchains für GxP-Prozesse verwenden möchte. Blockchains erzeugen Vertrauen in Daten aufgrund der Kryptographie, den systemimmanent enthaltenen Beweisen und der dezentralen Kontrolle. Der Grad der Sicherheit der Daten wird bedingt durch und hängt ab von der Verknüpfung der Datenblöcke mittels gewählter Hash-Funktion und der eingesetzten asymmetrische Verschlüsslung.
Der Fokus des Appendix liegt auf der Anwendung von Large Scale Public Blockchains (Open-Source Software OSS). Durch die Verteilung auf externe Stakeholder sind dann ggf. auch Systeme betroffen, die in nicht-regulierter Umgebung betrieben werden. Die Governance der Blockchains wird sichergestellt durch Verträge, Off-Chain-Datenstandards bzw. regulierte Prozesse.
Bei der Verwendung von Blockchains ist es wichtig den Intended Use festzulegen und einen risikobasierten Ansatz zu wählen. Dabei ist der Zuordnung der Funktion der Blockchain besondere Beachtung zu schenken. Die ausgewählte Blockchain lässt sich einordnenden als Netzwerklayer (Infrastruktur) oder als Programm, durch die Anwendung von Smart Contracts (Customized Software oder konfigurierte Software).
Der Anhang beschreibt die Besonderheiten, innerhalb der Lebenszyklusphasen, die für die Anwendung einer Blockchain berücksichtig werden sollten. Dabei heben sich besonders die Konzeptphase und die Projektphase hervor.
Außerdem werden in diesem Anhang Überlegungen präsentiert, die ein Unternehmen anstellen sollte, wenn die Nutzung neuer Technologien, wie z.B. Blockchains erwogen werden. Dazu gehören zum Beispiel der Reifegrade der genutzten Technologie und der Lieferantensupport.
Zusammenfassung Appendix D11 – Artificial Intelligence and Machine Learning (AI/ML)
Artificial Intelligence (AI) and Machine Learning (ML) halten zunehmend Einzug im Unternehmen, als Mittel das Business zu Steuern und die Datenprozessierung zu gestalten. Dies ist dadurch bedingt, dass Datensätze immer größer werden und Computersystem im Unternehmen immer stärker integriert werden.
Der Anhang zur AI und ML vermittelt das Basisverständnis zu den digitalen Lösungen und liefert einen Leitfaden wie diese unter Einhaltung der Compliance angewandt werden können. Der Fokus des Leitfadens liegt dabei auf AI/ML-Subsystemen, die in andere IT-Systemen integriert sind.
Der größte Unterschied zwischen der Validierung von AI und ML im Vergleich zu klassischer algorithmischer Programmierung liegt darin, dass das Datenmanagement schon währen der Konzept-Phase implementiert werden muss. PLS Daten sind die Schlüsselressource der digitalen Lösung. Der Anhang beschreibt was in den unterschiedlichen Lebenszyklusphasen eines ML-Subsystems berücksichtig werden sollte. Dabei werden die Konzeptphase, das Prototyping, die Projektphase und der Betrieb besonders detailliert beschrieben.
Die Projektphase für AI/ML-Subsysteme ist meist iterativ und inkrementell und umfasst:
- das Model und Datenengineering,
- das Modeltraining,
- die Bewertung und Modeltestung
- die Integration und Bereitstellung.
- Verifizierung und Akzeptanz.
Das Ergebnis daraus ist die Freigabe der ersten Version eines AI/ML-Subsystems integriert in eine übergreifendes IT-System mit Performance-Bewertung.
Anschließend wird in der Betriebsphase die Performance überwacht und bewertet. Livedaten sollen in die AI/ML integriert werden, so dass Verbesserungen vorgenommen werden können. Voraussetzung dafür ist, dass zusätzliche Daten die AI nicht überfordern. Unterstützende Prozesse, die während allen Lebenszyklen benötigt werden, sind Risikomanagement, Datenverwaltung/Steuerung und ein effektives Änderungs- und Konfigurationsmanagement sowie eine Versionskontrolle.
Autorin: Anna