Python und Jupyter im GxP-Umfeld validieren

Die Anwendung ist der Prüfgegenstand

Python ist eine Programmiersprache und eine Laufzeitumgebung. Jupyter stellt eine interaktive Arbeitsform bereit. Daraus folgt weder eine allgemeine GxP-Freigabe noch ein pauschales Verbot. Entscheidend ist, ob der konkrete Prozess für seinen vorgesehenen Einsatz geeignet ist. Ein exploratives Notebook in der Entwicklung hat einen anderen Zweck als ein freigegebener Ablauf zur Berechnung einer chargenbezogenen Qualitätskennzahl. Beschreiben Sie zuerst diese Entscheidung und ihre möglichen Fehlerfolgen.

Zur Systemgrenze gehören mehr Komponenten als die selbst geschriebenen Zeilen: Interpreter, Bibliotheken, Betriebssystem, Datenbanktreiber, Importlogik, Konfiguration, Benutzerrechte und Ausgabewege. Auch ein ausgelagerter Scheduler oder eine Cloudplattform kann relevant sein. Bewerten Sie Komponenten nach ihrem Einfluss auf das Ergebnis. Die Einstufung einer Bibliothek beantwortet nicht automatisch die Frage, wie ein individuell entwickeltes Berechnungsverfahren geprüft werden muss. Eine vorhandene R- oder Excel-Validierung ersetzt den Python-Nachweis ebenfalls nicht.

Quellen: [1]

Ein überprüfbarer Auswertungsvertrag

Formulieren Sie den vorgesehenen Ablauf so, dass zwei Personen dieselbe Aussage prüfen können. Welche Felder werden verarbeitet? Welche Einheiten, Grenzwerte und Ausschlussregeln gelten? Wie werden fehlende Werte, Wiederholungsmessungen und Dubletten behandelt? Was bedeutet das Ergebnis fachlich? Definieren Sie auch, wann kein verwendbares Ergebnis entstehen darf. Ein Programm, das einen unbekannten Einheitentext stillschweigend als Standard interpretiert, kann technisch durchlaufen und fachlich falsch rechnen.

Trennen Sie Datenauswahl, Berechnung und Entscheidung. Ein korrekter Mittelwert über eine unzulässige Population bleibt unbrauchbar. Die Spezifikation sollte deshalb den Datenstand, Auswahlfilter und Umgang mit korrigierten Aufzeichnungen einschließen. Legen Sie die benötigte Genauigkeit und den Rundungszeitpunkt ausdrücklich fest. Ein gerundeter Anzeigewert ist nicht zwangsläufig der Wert, auf dessen Basis eine Grenze beurteilt werden soll. Testen Sie beide Ebenen gegen die freigegebene Regel.

Pakete und Laufzeit kontrolliert festlegen

Die pip-Dokumentation unterscheidet Versionsbindung, Hashprüfung und die Bereitstellung von Installationspaketen. Berücksichtigen Sie neben direkten Paketen auch deren Abhängigkeiten. Ein gespeicherter Paketname ohne Version hält den tatsächlich eingesetzten Stand nicht fest. Hashes unterstützen den Abgleich gelieferter Dateien; sie beweisen weder fachliche Korrektheit noch Sicherheit sämtlicher Paketfunktionen. Installationspakete können außerdem an Betriebssystem und Architektur gebunden sein.

Ein eigener Umgebungssatz kann Interpreterversion, Paketliste, relevante Systembibliotheken, Konfiguration und Installationsnachweis zusammenführen. Entscheidend ist, dass Sie damit die freigegebene Umgebung gezielt herstellen und erkennen können. Prüfen Sie diesen Wiederaufbau auf einer kontrollierten Zielumgebung. Ein Versionsprotokoll vom Entwicklerrechner allein beantwortet nicht, ob später ein anderer Rechner dieselbe benötigte Umgebung erhält. Dokumentieren Sie auch externe Dienste, deren Verhalten sich unabhängig von der lokalen Paketliste ändern kann.

Quellen: [2] [3]

Jupyter: sichtbarer Code und tatsächlicher Zustand

Ein Notebook erlaubt interaktive Arbeit. Zellen können während der Entwicklung wiederholt oder in anderer Reihenfolge ausgeführt werden. Gespeicherte Ausgaben können einen anderen Bearbeitungsstand zeigen als der aktuell sichtbare Code. Für einen freigegebenen Lauf braucht es deshalb einen definierten Ausgangszustand und eine kontrollierte Ausführung. Testen Sie, ob der Ablauf nach einem frischen Kernelstart mit den festgelegten Eingaben vollständig durchläuft. Verdeckte Variablen aus einem vorherigen Experiment dürfen das Ergebnis nicht tragen.

nbconvert unterstützt die programmatische Ausführung und unterschiedliche Fehlerbehandlungen. Die Option allow_errors kann eine Fortsetzung trotz Ausführungsfehlern ermöglichen. Ein fertig geschriebenes Ausgabedokument ist deshalb kein ausreichendes Erfolgssignal. Prüfen Sie den tatsächlichen Ausführungsstatus, Fehlermeldungen und die Vollständigkeit erwarteter Ergebnisse. Vereinbaren Sie, wie bewusst erwartete Fehlertests von unerwarteten Laufabbrüchen unterschieden werden. Ein Testbericht darf einen teilweise ausgeführten Lauf nicht als vollständig bestandene Berechnung darstellen.

Quellen: [4]

Konstruiertes Beispiel: Konzentrationen richtig zusammenführen

Ein eigener Übungsprozess übernimmt drei Messungen: 0,8 mg/ml, 900 µg/ml und 1,0 mg/ml. Die festgelegte Zieleinheit ist mg/ml. Nach korrekter Umrechnung liegen 0,8, 0,9 und 1,0 vor; ihr arithmetischer Mittelwert beträgt 0,9 mg/ml. Wer nur die Zahlen mittelt, erhält ungefähr 300,6. Das ist kein kleiner Rundungsfehler, sondern eine andere Aussage. Bestimmen Sie die Referenz unabhängig vom zu prüfenden Umrechnungscode und halten Sie die Ausgangseinheiten fest.

Erweitern Sie denselben Fall gezielt: Die zweite Zeile besitzt eine leere Einheit, eine Probe steht doppelt im Import, ein Ergebnis wurde nachträglich korrigiert. Die Sollreaktion wird jeweils vor der Prüfung definiert. Ein fehlender Wert darf beispielsweise nicht ohne Freigaberegel als Null in den Mittelwert eingehen. Die folgende Arbeitshilfe ist ein methodischer Vorschlag. Sie legt keine universellen regulatorischen Toleranzen fest und ersetzt keine fachliche Festlegung Ihrer tatsächlichen Berechnung.

Referenzen, Grenzfälle und Fehlererkennung

Wählen Sie Referenzdaten nach den tatsächlich verwendeten Funktionen. Für Gruppenbildung braucht es mehrere Gruppen und ähnliche Bezeichnungen. Für Zeitfilter braucht es Datensätze vor, auf und nach der Grenze. Für Verknüpfungen braucht es fehlende und mehrfach vorhandene Schlüssel. Testen Sie nicht nur einen komfortablen Normalfall. Eine kleine, bewusst aufgebaute Referenzpopulation kann die Logik zunächst besser erklären als ein großer Produktionsauszug ohne unabhängig bekannte Erwartung.

Prüfen Sie auch die Prüfmethode. Erkennt der Vergleich einen absichtlich vertauschten Einheitentext oder eine entfernte Ergebniszeile? Gemeinsame Hilfsfunktionen zwischen Produktivberechnung und Referenzberechnung können denselben Fehler auf beiden Seiten erzeugen. Nutzen Sie für kritische Referenzen einen geeigneten unabhängigen Rechenweg. Bei numerischen Verfahren begründen Sie Toleranzen aus dem Verfahren und dem Verwendungszweck. Exakte Bitgleichheit ist nicht für jede Berechnung sinnvoll; großzügige Toleranzen dürfen aber keine fachlich relevante Abweichung verdecken.

Ergebnis, Lauf und Freigabe miteinander verbinden

Ein nachvollziehbares Ergebnispaket identifiziert Eingabedaten, Codeversion, Umgebung, Parameter, Laufzeitpunkt, Status und zuständige Prüfung. Berücksichtigen Sie die tatsächliche elektronische Originalinformation. Ein PDF mit einer Grafik kann den vollständigen Zusammenhang einer komplexen Auswertung nicht automatisch ersetzen. Legen Sie fest, welche Dateien, Protokolle und Metadaten für die spätere Rekonstruktion benötigt werden. Beschreiben Sie außerdem, wie Änderungen an bereits geprüften Ergebnissen erkennbar bleiben.

Versionsverwaltung unterstützt die Zuordnung von Codeänderungen. Sie ist jedoch nicht automatisch ein vollständiger fachlicher Audit Trail für alle Dateneingaben und Ausführungshandlungen. Ebenso ist ein erfolgreicher automatisierter Testlauf noch keine Genehmigung des Ergebnisses. Rollen, Zugriff, Review und Freigabe werden passend zum Prozess gestaltet. Vermeiden Sie ein Modell, in dem derselbe Anwender unbemerkt Eingangsdaten, Code und abschließende Freigabedatei austauschen kann.

Quellen: [1] [5]

Änderungen und laufenden Einsatz beherrschen

Eine Änderung kann vom eigenen Code, einem Paket, der Datenquelle oder der Infrastruktur ausgehen. Bewerten Sie ihre Wirkung auf die freigegebene Aussage. Ein neuer Dateiexport kann etwa Datentypen und Spaltennamen verändern, obwohl der Pythoncode unverändert bleibt. Ein Paketupdate kann andere Standardwerte verwenden. Beschreiben Sie, welche Prüfungen durch welche Änderung ausgelöst werden und welche Nachweise unverändert weiterverwendbar sind. Ein pauschaler Komplettneustart bei jeder Änderung ist ebenso wenig begründet wie ein ungeprüftes Weiterlaufen.

Schulen Sie die Anwender in den Grenzen des freigegebenen Ablaufs. Exploration, Entwicklung und reguläre Ergebniserzeugung sollten erkennbar unterschiedliche Zustände haben. Eine manuell reparierte Notebookzelle gehört nicht stillschweigend in den nächsten Routinebericht. Wenn eine Verarbeitung fehlschlägt, werden Ursache, betroffene Ergebnisse und Wiederholung nachvollziehbar behandelt. Ein tragfähiger Pythonprozess ist dadurch im Alltag nutzbar: Das Team erkennt seinen Stand, seine Grenzen und den nächsten erlaubten Schritt.