Software für wissenschaftliche Messgeräte Gute Daten-Praxis: GMP-konforme Software und was sie leisten muss

Anbieter zum Thema

Xylem Analytics Germany Sales GmbH & Co. KG

VACUUBRAND GMBH + CO KG

Anton Paar Germany GmbH

Interlabor Belp AG

Audit Trail, User Management, Data Integrity ... die Good Manufacturing Prac­tice (GMP) stellt diverse Anforderungen wie mit Daten umgegangen werden muss. Doch wie lässt sich das softwareseitig effizient und sicher abbilden? Der erste Teil unserer zweiteiligen Artikelserie zeigt, worauf es bei GMP-konformer Software für wissenschaftliche Messgeräte ankommt.

In Zeiten stetig wachsender Datenmengen muss mit diesen sinnvoll umgegangen und ihre Sicherheit garantiert werden. Je sensibler die Daten, um so höher ist i. d. R. das Bedürfnis, diese zu schützen. In einigen Bereichen hat diesbezüglich auch der Gesetzgeber seine Finger im Spiel: Die so genannte Good Manufacturing Prac­tice (GMP) stellt bekanntermaßen bestimmte Anforderungen, wie Daten im Umfeld der Arzneimittelproduktion erzeugt, bewirtschaftet und langfristig gespeichert werden sollen.

Dabei sind Audit Trail und Benutzerverwaltung auch aus der ISO 17025 oder 13485 bekannte Begriffe. Data Integrity, kurz DI und ALCOA (Definitionen s. LP-Info-Kas­ten) sind weitere Prinzipien aus der europäischen und amerikanischen GMP/cGMP [1] bis [6]. Diese Anforderungen müssen sowohl von der Software als auch den Anwendern erfüllt werden. Die Erfahrung zeigt, dass die Anwender mit behördlichen und kundenseitigen Audits mehr als gut auf die Einhaltung dieser Anforderungen überwacht werden.

Demgegenüber erfüllen die Produkte der meisten Softwarehersteller für Messgeräte, Steuerungs- oder Produktionsanlagen die Anforderungen deutlich weniger. Für die „innere Integrität“ der abgespeicherten Daten kann ausschließlich der Hersteller sorgen. Eine Benutzerverwaltung mit Abstufung der Rechte für die Funktionen in seiner Software kann ebenfalls nur der Hersteller integrieren.

Labor-Digitalisierung in der Pharmaindustrie

Das moderne hochproduktive Labor der Zukunft

Für eine korrekte Bewirtschaftung hingegen – eine geschützte Verwendung, Sicherung und Archivierung – ist dann der Anwender zusammen mit seiner IT-Abteilung verantwortlich. Aber nur für einfache, auto­matische Anwendungen ohne Benutzer-Interaktion kann man auf Windows-Zugriffrechte mit „read/write“ zurückgreifen. Der Hersteller muss also seinen Teil dazu beitragen, dass die Prinzipien mit den Möglichkeiten seiner Software überhaupt erfüllt werden können. Die Anforderungen ihrerseits sind allerdings nicht wirklich neu: Die U.S. cGMP stellt die Anforderungen seit weit über 20 Jahren, und die EU GMP seit immerhin zehn Jahren.

Fragen über Fragen

Die eher abstrakten Prinzipien Data Integrity und ALCOA oder Benutzerverwaltung und Audit Trail lassen sich durchaus in sehr reale Fragen zu den Funktionen der Software und Leistungen des Herstellers übersetzen. Die Quality Assurance fasst diese Fragen klassisch als User Requirement Specifications URS zusammen und erwartet ein Lasten- und Pflichtenheft zur Freigabe. Wichtiger als diese äußere Form sind jedoch die Inhalte: Eine QA-Freigabe bedeutet nicht unbedingt volle GMP-Konformität, wenn die Fragen zuvor fachlich nicht hinreichend gestellt oder wahrheitsgemäß beantwortet wurden (s. Tab. 1).

Datentypen und Risiken

Die Datenintegrität und die Umsetzung des ALCOA+-Prinzips wird in erster Linie durch das Design der datenerzeugenden Software bestimmt. Die EDV-Struktur und Datenbewirtschaftung inklusive der Zugriffsrechte sichern erst danach die dauerhafte Aufrechterhaltung der Datenintegrität. Eine Software kann sowohl lokal als auch zentral im Netzwerk Daten erzeugen. Die Daten selber können dateibasiert oder in einer Datenbank abgelegt werden. Heutige Dateisysteme zeichnen schlichtweg keine Datei­historie oder gar Versionierung von Dateien auf. Die wenigen Metadaten eines Dateisystems wie etwa „Besitzer“ oder „Speicherdatum“ sind ungenügend für ein Audit Trail.

Mit Hilfsmitteln, etwa Syn­chronisa­tionstools wie Dirsyncpro oder Viceversa, kann immerhin eine zeitbasierte Versionierung für Einzel­dateien („Single File“) erreicht werden. Aber erst mit einer Datenbank können ein vollständiger Audit Trail, Zugriffsrechte oder eine automatische Versionierung „by Design“ verwirklicht werden. Und nur serverbasierte Daten im Netzwerk, sowohl Dateien als auch Datenbanken, werden in aller Regel vollautomatisch gesichert. Daraus ergibt sich die in Tabelle 2 dargestellte Risikomatrix.

Speicherung als Datei

Die Speicherung und Archivierung von Daten als Datei ist technisch einfacher als eine Speicherung in einer Datenbank, hat aber gleich mehrere gravierende Nachteile. Die Speicherung aller Daten einer Messung sollte zumindest als „Single File“ erfolgen. Zu den Daten zählen alle Rohdaten der Messung, Einstellungen für das Messgerät, Metadaten wie Datum, Uhrzeit und User. Wenn Vorlagen verwendet werden, die die Arbeit vereinfachen sollen, müssen diese als vollständige Kopie in der Datendatei enthalten sein. Parameter einer Weiterverarbeitung, beispielsweise einer Signalerkennung oder Integration, müssen ebenso in der Datei enthalten sein. Das erlaubt eine externe Versionierung, für den Fall, dass Daten überarbeitet und erneut gespeichert werden. In diesem Fall müssen die Daten zudem automatisch gespeichert werden, damit die überarbeiteten Daten ebenfalls dauerhaft archiviert werden können. Bei einer Speicherung von Daten in mehreren Dateien und Verzeichnissen pro Messung ist eine externe Versionierung nicht mehr möglich. Dateibasierte und im User-Kontext gespeicherte Dateien können zudem – auch bei einer eigenen Benutzer­oberfläche der Software für die Handhabung von Daten oder Dateien – durch den User bedingt verschoben oder gelöscht werden. Ein Schutz der Daten vor Manipulation ist damit nicht vorhanden.

Geringerer Dokumentationsaufwand bei höherer Datenintegrität

pH-Messung: Konforme Datenübertragung in der Pharmaindustrie

Die Software sollte zudem netzwerkfähig sein und die Daten direkt auf einem Netzlaufwerk ablegen. In diesem Falle kann mit externen Hilfsmitteln auf dem Dateiserver eine Archivierung und Versionierung bei nachträglicher Weiterverarbeitung ermöglicht werden. Die Software sollte auch mit einem Virenscanner auf dem Netzlaufwerk zurechtkommen, was meist nicht zutrifft.

Falls die Software nicht netzwerkfähig ist, sollte der Pfad zur Speicherung der Daten innerhalb der Software frei einstellbar und nicht etwa hart kodiert sein. In jedem Falle sollten die Daten in einem zugänglichen Verzeichnis und nicht im User-Profil oder gar im Programmverzeichnis gespeichert werden. Das Programmverzeichnis wird seit 2007 von allen Windows-Betriebssystemen geschützt. Die Daten werden durch das Betriebssystem stattdessen in einem virtuellen Ast des User-Profils abgelegt. Die Daten sind in der Folge nur für den ursprünglichen User zugänglich; selbst ein Administrator oder ein als Dienst laufendes Dateitransferprogramm hat ohne administrativen Eingriff auf jedes User-Verzeichnis zur erzwungenen Übernahme keine Zugriffsrechte. Ein automatischer Transfer auf ein Netzlaufwerk für eine Archivierung und Versionierung ist damit praktisch nicht möglich.

Speicherung in Datenbank

Die Speicherung von Daten und den oben genannten Metadaten in einer Datenbank bietet bei geeigneter Umsetzung gewaltige Vorteile: Die Daten einer Messung stehen inklusive aller Metadaten zur Verfügung. Der Zugriff auf die Daten kann mit verschiedenen Auswahlkriterien durch die Software gestaltet werden. Das User-Management mitsamt Berechtigungen lässt sich mit oder ohne Anbindung an einen zentralen Verzeichnisdienst in die Anwendung integrieren. Ein Audit Trail oder eine Versionierung der Daten bei einer Weiterverarbeitung ist ebenso realisierbar.

Wichtig ist auch die Art der Speicherung der Datenbank: Als lokale, wiederum dateibasierte Datenbank im User-Kontext oder als mehrschichtige Client Server Architektur? Eine lokal mit den Rechten des Users gespeicherte Datenbank ist dem gleichen Risiko einer Löschung ausgesetzt wie eine einzelne Datei. Einen Zugriffsschutz gibt es dabei noch nicht. Und die Archivierung und der Backup müssen von außen mit Hilfe von Synchronisationstools ausgeführt werden.

Eine mehrschichtige Client-Server-Architektur erfordert einen lokalen Dienst zur Steuerung des Messgerätes inklusive Speicherung der Daten in einer zentralen Datenbank. Ein netzwerkweit verwendbares Client-Programm dient zur Steuerung des Dienstes – beispielsweise für eine Analysensequenz – oder Auswertung der gespeicherten Daten.

Mit einer solchen Architektur können eine kontrollierte Erzeugung der Daten, der Zugriffschutz auf die Daten, ein zentraler Audit Trail, eine Versionierung und Nachverfolgung aller Zwischenschritte und Ausführenden der Verarbeitung „by Design“ realisiert werden. Die Trennung von Messwerterfassungsdienst und Anwenderprogramm erlaubt auch einen personenun­abhängigen Schichtdienst mit User-Wechsel am Computer.

Archivierung von Dateien

Lokal erzeugte Daten müssen für eine GMP-konforme Bewirtschaftung zuerst „eingesammelt“ werden. Dazu werden diese Daten typischerweise mit einem Synchronisationstool auf ein Netzlaufwerk (in Abb. 2 G:\) repliziert. Netzwerkfähige Software kann diese bei der Erzeugung gleich dort ablegen. Auf dem Netzlaufwerk können die Rohdaten dann durch die Anwender mit der jeweiligen Software zentral ausgewertet und weiterverarbeitet werden.

Die Daten auf G:\ werden durch ein serverbasiertes Synchronisationstool versioniert auf einen für die Anwender zugriffsgeschützten Speicherplatz, im Bild unten H:\, repliziert. Dies ist das Langzeitarchiv. Dateien vom Typ „Single File” können dann aus älteren Versionen wiederhergestellt und eingesehen werden. Messwertsoftware, bei der die Inhalte in einer Vielzahl von Dateien und Verzeichnissen gespeichert werden, ist auch mit externen Tools nicht versionierungsfähig.

Langfrist-Archivierung

Alle Daten müssen langfristig und vollständig verfügbar sein. Die langfristige Verfügbarkeit erfordert auch die ebenso langfristige Verwendbarkeit der dazugehörigen Software; zumindest einer Auswertungs- oder Anzeigesoftware. Der Archivzeitraum beträgt ab dem Erzeugungsdatum üblicherweise 20 Jahre, da nach dem letzten Gebrauch der Geräte und Software die Daten für mindes­tens weitere zehn Jahre verfügbar sein muss.

Nach heutigem Stand der Technik wird die langfristige Verfügbarkeit von Software und älteren Betriebssystemen durch virtuelle Systeme realisiert, in denen die Software und das dazugehörige Betriebssystem auch ohne die ursprüngliche Hardware in einer virtuellen und aus Sicherheitsgründen gekapselten Umgebung funktionsfähig gehalten werden können.

Die Software muss demzufolge frei von Schutzmaßnahmen sein, die eine Interaktion nach außen erfordert. Dazu zählen insbesondere eine Online Registrierung via Internet beim Hersteller oder ein „Dongle“ als Hardware. Kein Hersteller kann garantieren, dass er 20 oder gar 30 Jahre nach dem Verkauf weiterhin existiert und freiwillig die entsprechenden Dienste anbietet. Daher muss bereits beim Verkauf eine Virtualisierung in einer gekapselten Umgebung ohne externe Hardware oder Internet-Zugang jederzeit möglich sein.

Die Daten und Datenbanken aller Netzlaufwerke inklusive des Archivlaufwerkes werden regelmäßig als Schutz gegen Verlust mit einem zentralen Backup gesichert. Die
Daten müssen also – insbesondere im Falle einer Datenbank – auch
archivierbar und backupfähig sein. Lokal gehaltene Dateien oder
Datenbanken sind nicht ohne externe Hilfsmittel archivierbar. Das Archiv ist übrigens im Backup enthalten – der Backup ist nicht das Archiv!

User Management

Es sollte natürlich generell verhindert werden, dass unbefugte User Daten erzeugen, verändern oder löschen. Die erzeugende Software muss daher im GMP-Umfeld über ein User Management verfügen, bei dem die erforderlichen Rechte den entsprechenden User-Gruppen zugewiesen werden können. Die Software sollte in keinem Falle Adminis­tratorrechte für den Betrieb benötigen. In einem Netzwerk existiert in aller Regel bereits ein User-Management in Form eines Active Directory oder kompatibler Dienste. Die Software sollte daher kein eigenes User-Management als Insellösung einrichten, sondern sich an das vorhandene User-Management anlehnen. Dies erlaubt eine zentrale User-Verwaltung und ein „Inte­grated Login“ ohne zusätzliche Passworte.

Audit Trail

Im Audit Trail muss die Erzeugung, Verarbeitung oder nachträgliche Veränderung der Daten bis hin zu einer gewollten Löschung nach dem Prinzip „wer, was, wann, warum“ dokumentiert werden. Der Audit Trail darf nicht löschbar oder ver­änderbar sein. Dateibasierte Logdateien im Klartext sind demzufolge kein GMP konformer Audit Trail.

Der Audit Trail muss ebenso wie die Daten im Netzwerk abgelegt oder automatisch transferiert werden können, damit Archivierung und Backup möglich sind. Ohne zentrale Archivierung ist auch ein ansonsten umfangreicher Audit Trail nahezu wertlos, weil mit dem Verlust des lokalen Datenträgers oder Computers der Audit Trail auch verloren gehen würde.

Literatur:

[1] FDA 21 CFR Part 11 (1997)

[2] EU GMP Annex 11 (Jan 2011)

[3] FDA Draft Guidance „Data Integrity and Compliance with cGMP“ (April 2016)

[4] EMA Guidance „Data Integrity“ (Aug 2016)

[5] PIC/S Draft Guidance „Good Practices for Data Management and Integrity in regulated GMP/GDP Environments“ (Aug 2016)

[6] MHRA „GxP Data Integrity Guidance and Definitions“ (March 2018)

* Dr. K. W. Mandelatz, Interlabor Belp AG, 3123 Belp, Bern/Schweiz

(ID:47923454)