Wann wird eine Softwarefunktion GMP-relevant?

Eine Tabellenkalkulation kann addieren, Mittelwerte bilden, Werte vergleichen oder Formeln ausführen. Das beschreibt technische Fähigkeiten.

Für die regulatorische Betrachtung nach GMP reicht diese Beschreibung nicht.

Dieselbe Berechnungsfunktion kann beispielsweise einen Wert erzeugen, den ein Mitarbeiter nur zur Orientierung nutzt. Sie kann eine Berechnung für einen nachfolgenden fachlichen Review vorbereiten. Oder sie kann den Wert bestimmen, den ein regulierter Prozess anschließend als Ergebnis weiterverwendet.

Die mathematische Operation kann in allen drei Fällen identisch sein.

Die Aufgabe der Funktion ist es nicht.

Für diesen Beitrag bezeichnet „betriebliche Rolle" deshalb die konkrete Aufgabe, die eine Softwarefunktion innerhalb einer GMP-regulierten Tätigkeit erfüllt. Der Begriff ist eine analytische Kategorie dieses Beitrags, keine Definition aus Annex 11.

Bei Tismor war die technische Fähigkeit vergleichsweise unspektakulär: Ein Spreadsheet führte Berechnungen aus. Seine betriebliche Rolle war wesentlich konkreter. Der Betrieb setzte diese Berechnung für Assays ein und stützte sich auf ihr Ergebnis bei der Bestimmung des reportable result für die finale Chargenfreigabe.

Damit verschiebt sich auch die Kontrollfrage.

Sie lautet nicht nur:

Funktioniert die Formel technisch?

Sondern:

Welche Aufgabe erfüllt ihr Ergebnis im GMP-Prozess – und welche Verlässlichkeit muss die Funktion deshalb für genau diese Aufgabe bieten?

Annex 11 des EU-GMP-Leitfadens gilt für computergestützte Systeme, die als Teil GMP-regulierter Tätigkeiten eingesetzt werden. Er sieht eine Validierung der Anwendung und eine Qualifizierung der IT-Infrastruktur vor. Der Umfang der Validierung und der Data-Integrity-Kontrollen soll auf einer begründeten und dokumentierten Risikobewertung beruhen, die unter anderem Patientensicherheit, Datenintegrität und Produktqualität berücksichtigt.

Für kritische Systeme sieht Annex 11 zudem eine aktuelle Systembeschreibung vor; die Systemlandschaft soll relevante Systeme und ihre GMP functionality erkennen lassen. Die User Requirements sollen die erforderlichen Funktionen beschreiben und auf dokumentierter Risikobewertung sowie GMP impact beruhen. Annex 11 trennt außerdem die Verantwortlichkeit des Process Owner für den Business Process von derjenigen des System Owner für Verfügbarkeit, Wartung und Sicherheit des computergestützten Systems.

Diese Vorgaben definieren keine „betriebliche Rolle" im hier verwendeten Sinne. Für die Analyse lässt sich daraus aber eine klare Beziehung ableiten: Welche Kontrolle für eine Softwarefunktion angemessen ist, lässt sich nicht sinnvoll bestimmen, ohne ihre konkrete Aufgabe innerhalb der GMP-regulierten Tätigkeit zu erfassen.

Für deutsche Arzneimittelhersteller ist die rechtliche Einordnung differenziert. § 2 Nr. 3 AMWHV definiert den EU-GMP-Leitfaden ausdrücklich einschließlich seiner Anhänge als die von der Europäischen Kommission veröffentlichten ausführlichen Leitlinien zur Auslegung der GMP-Grundsätze. Annex 11 wurde vom Bundesministerium für Gesundheit auf dieser Grundlage mit Bekanntmachung vom 8. August 2011 (BAnz Nr. 125, S. 2901–2906) in deutscher Sprache bekannt gemacht. § 3 Abs. 2 AMWHV ordnet daneben für Arzneimittel Teil I des EU-GMP-Leitfadens ausdrücklich als Auslegungsmaßstab für die Grundsätze der Guten Herstellungspraxis ein. Annex 11 sollte deshalb weder als eigenständige EU-Rechtsnorm noch als beliebige technische Empfehlung beschrieben werden; seine regulatorische Einordnung muss vielmehr über den EU-GMP-Leitfaden und seine amtliche Bekanntmachung sauber von den zugrunde liegenden Rechtsakten getrennt bleiben.

Der Unterschied lässt sich ohne komplexes Computersystem zeigen.

Eine Softwarefunktion berechnet aus mehreren Eingabewerten einen Zahlenwert.

Im ersten Prozess dient dieser Wert ausschließlich als Hilfsinformation. Ein Mitarbeiter nutzt ihn beispielsweise zur Orientierung; die eigentliche GMP-relevante Feststellung entsteht unabhängig davon in einem kontrollierten Verfahren.

Im zweiten Prozess erstellt dieselbe Funktion eine Berechnungsgrundlage für einen nachfolgenden Review. Der erzeugte Wert geht in die Tätigkeit ein, wird dort aber noch anhand festgelegter Informationen fachlich geprüft.

Im dritten Prozess bestimmt die Funktion selbst den Wert, den der nachfolgende GMP-Prozess als Ergebnis übernimmt. Genau hier lag die besondere Rolle des Tismor-Spreadsheets: Es wurde nicht lediglich als Rechenhilfe beschrieben, sondern zur Assay-Berechnung und zur Bestimmung des berichteten Ergebnisses für die finale Chargenfreigabe eingesetzt.

Die technische Fähigkeit – eine Berechnung auszuführen – kann in allen drei Konstellationen ähnlich sein. Die regulatorische Bedeutung der Funktion ist es nicht.

Daraus folgt nicht, dass sich für jede Rolle abstrakt eine bestimmte Validierungsklasse ableiten ließe. Der risikobasierte Ansatz verlangt gerade die Betrachtung des konkreten Einsatzes.

Aber eine Aussage lässt sich aus dem Vergleich gewinnen:

Der Kontrollbedarf einer Softwarefunktion folgt nicht allein aus ihrer technischen Komplexität. Er hängt auch davon ab, welche Aufgabe ihr Ergebnis im GMP-Prozess erfüllt.

„Hängt ab" bezeichnet hier keine zeitliche Entwicklung. Der Beitrag behauptet insbesondere nicht, dass eine zunächst unterstützende Softwarefunktion im Laufe ihres Lebenszyklus regelmäßig in eine kritischere Rolle hineinwächst. In den für diesen Beitrag ausgewerteten Behördenbefunden ließ sich ein solcher zeitlicher Rollenwandel nicht belastbar rekonstruieren.

Die praktische Konsequenz besteht deshalb nicht darin, jede Software gleich streng zu behandeln.

Zunächst muss die Rolle erfasst werden.

Welche Tätigkeit führt die Funktion aus? Was geschieht mit ihrem Ergebnis? Nutzt der nachfolgende Prozess den Output als bloße Information, als Grundlage eines weiteren Reviews oder als maßgebliches Ergebnis einer GMP-relevanten Tätigkeit?

Erst danach lässt sich für diese Rolle ein angemessener Nachweis bestimmen. Nicht irgendeine abstrakte Softwareeigenschaft muss bestätigt werden, sondern die zuverlässige Erfüllung derjenigen Funktion, auf die der regulierte Prozess tatsächlich angewiesen ist.

Und schließlich muss diese Rolle im Betrieb kontrolliert bleiben. Welche Maßnahmen dafür erforderlich sind, hängt vom Risiko und von der jeweiligen Funktion ab. Die Analyse führt deshalb nicht automatisch zu einer bestimmten Kombination aus Zugriffskontrollen, Audit Trails, manuellen Gegenprüfungen oder technischen Schutzmechanismen. Sie verlangt zunächst, dass diese Kontrollen auf die tatsächlich relevante Funktion gerichtet sind.

Die britische MHRA hat diese Relation in ihrer Data-Integrity-Guidance von 2018 ungewöhnlich ausdrücklich formuliert. Unter „Validation – for intended purpose" führt sie aus, dass die Validierung eines computergestützten Systems ein Verständnis seiner Funktion innerhalb eines Prozesses voraussetzt. Vendor-Validierungsdaten oder rein funktionale Verifikation reichen danach isoliert nicht aus, wenn Konfiguration und tatsächlicher intended use nicht berücksichtigt werden. Beim Beispiel eines individuell konfigurierten Reports unterscheidet die Guidance zwischen funktionaler Verifikation und der Validierung für den vorgesehenen Zweck: Entscheidend ist auch, ob die Schritte zur Report-Erzeugung zum vorgesehenen Kontrollprozess passen und der Output für den anschließenden Review geeignet ist.

Die MHRA-Guidance ist eine britische regulatorische Guidance und keine EU-Rechtsnorm. Sie konkretisiert hier aber besonders anschaulich, warum technische Funktion und Aufgabe im Prozess nicht dieselbe Betrachtung sind. Der europäische regulatorische Ausgangspunkt für diesen Beitrag bleibt Annex 11.

Gegen die Unterscheidung lässt sich ein naheliegender Einwand erheben: Genau dafür gibt es User Requirements, Risikobewertung, Systemklassifizierung und Validierung. Wenn diese Instrumente richtig angewendet werden, müsste die Rolle der Funktion längst erfasst sein.

Der Einwand ist richtig.

Die Frage dieses Beitrags beginnt nicht dort, wo Validierung endet, und sie stellt auch keinen zusätzlichen Kontrollapparat neben Annex 11.

Sie liegt einen Schritt früher:

Welche Rolle wird überhaupt Gegenstand dieser Kontrolle?

Eine Risikobewertung kann nur diejenigen Auswirkungen bewerten, die in der betrachteten Verwendung erkannt wurden. Eine User Requirement kann nur diejenigen Funktionen angemessen beschreiben, deren Aufgabe im Prozess bestimmt ist. Und eine Validierung kann nur für einen vorgesehenen Zweck belastbar sein, wenn dieser Zweck die tatsächliche GMP-relevante Rolle der betrachteten Funktion erfasst.

Deshalb lautet die Kontrollfrage nicht:

Ist diese Software validiert?

Sie lautet zunächst:

Entspricht die Rolle, auf die sich der reale GMP-Prozess verlässt, der Rolle, die Gegenstand von Requirements, Risikobewertung und Validierung ist?

Das ist keine These über einen nachträglichen Rollenwandel. Sie betrifft bereits den vorhandenen Zustand eines Systems.

Ein zweiter FDA-Befund zeigt, weshalb diese Unterscheidung praktisch relevant ist.

Bei Sichuan Friendly Pharmaceutical beanstandete FDA 2018 ein nicht validiertes Excel-Spreadsheet, das zur Berechnung von Assay-Ergebnissen für Product Release und Stability Testing eingesetzt wurde. Die Datei war nicht passwortgeschützt; Berechnungsformeln waren entsperrt und teilweise falsch. Nach dem Warning Letter führten die fehlerhaften Formeln zu unzutreffenden Daten in mehreren Certificates of Analysis. Das Unternehmen identifizierte außerdem Stabilitätsergebnisse, die das Spreadsheet als innerhalb der Spezifikation berechnet hatte, obwohl sie tatsächlich OOS waren.

Sichuan beantwortet eine andere Frage als Tismor.

Tismor macht besonders deutlich, welche betriebliche Rolle eine scheinbar einfache Tabellenkalkulation übernommen hatte und dass FDA die betroffenen Tätigkeiten als kritische CGMP-Funktionen einordnete.

Sichuan zeigt, weshalb diese Rolle für die Kontrolle entscheidend wird: Wenn ein Prozess eine Berechnungsfunktion für Release- oder Stability-Ergebnisse verwendet, können Fehler dieser Funktion unmittelbar in diejenigen Informationen eingehen, mit denen der GMP-Prozess anschließend arbeitet.

Damit geht es nicht um Excel als besondere Risikoklasse. Eine andere technische Lösung mit derselben betrieblichen Rolle würde dieselbe Grundfrage aufwerfen.

Computerisierte Systeme lassen sich klassifizieren. Funktionen lassen sich spezifizieren. Validierung kann geplant und dokumentiert werden.

Aber vor diesen Instrumenten steht eine fachliche Frage:

Welche Aufgabe erfüllt die Funktion im GMP-Prozess tatsächlich?

Erst diese Antwort macht sichtbar, worauf sich der Betrieb verlässt. Sie bestimmt nicht automatisch die konkrete Kontrollmaßnahme, aber sie bestimmt, was überhaupt kontrolliert werden muss.

Bei einer Berechnungsfunktion kann der Unterschied erheblich sein: Sie kann einen Hilfswert liefern, eine fachliche Prüfung vorbereiten oder das Ergebnis bestimmen, das der weitere GMP-Prozess übernimmt.

Die technische Operation mag ähnlich aussehen.

Die betriebliche Rolle ist es nicht.

Der Ausgangspunkt einer risikobasierten Kontrolle sollte deshalb nicht allein der Produktname, die Softwarekategorie oder die technische Komplexität sein. Entscheidend ist die Aufgabe, für deren zuverlässige Ausführung sich die GMP-regulierte Tätigkeit auf diese Funktion verlässt.

Welche Aufgaben hat Ihr GMP-Prozess Softwarefunktionen tatsächlich übertragen – und werden genau diese Rollen kontrolliert?