SoftMax Pro GxP validieren: vom Plattensignal zum geprüften Ergebnis

Edition und Version zuerst eindeutig benennen

Molecular Devices beschreibt SoftMax Pro als Erfassungs- und Auswertungssoftware für Mikroplattenlesegeräte. Die Produktfamilie unterscheidet Standard, GLP Mode und GxP. Sie ist kein Chromatographiedatensystem. Eine Anleitung zu Peak-Integration beantwortet deshalb nicht die entscheidenden Fragen einer Plattenauswertung.

Der dokumentierte Bezugspunkt dieses Artikels ist Version 7.6: der IT Configuration Guide 5325894A vom Juli 2026 und das Datenblatt 2771D vom August 2026. Das Datenblatt enthält eine eigene GxP-Funktionsmatrix. Damit ist keine Aussage über Ihren installierten Patchstand verbunden. Prüfen Sie Lizenz, Komponenten und Geräteanbindung gemeinsam.

Die Herstellerunterlagen kennzeichnen das Produkt als Research Use Only und nicht für diagnostische Verfahren. Diese Grenze wird nicht durch den Zusatz GxP aufgehoben. Klären Sie die konkrete Verwendung vor Projektbeginn. Ebenso wenig folgt aus dem Produktnamen eine allgemeine Zulassung oder bereits nachgewiesene Eignung jedes betrieblichen Assays.

Quellen: [1] [2] [3]

Drei Nachweise unterscheiden: Reader, Software und analytisches Verfahren

Im hier betrachteten Humanarzneimittel-GMP-Kontext betrifft Annex 11 den computergestützten Prozess. Die Gerätequalifizierung und die Eignung der analytischen Methode haben andere Prüfziele. Kapitel 6 der EU-GMP-Leitlinie behandelt Prüfmethoden, Aufzeichnungen und die kritische Prüfung von Berechnungen. Der EudraLex-Index führt die verwendeten Leitlinien weiterhin im Humanarzneimittelbereich.

Die folgende eigene Arbeitshilfe grenzt diese Ebenen ab. Ein gemeinsamer Plan kann ihre Nachweise verbinden; getrennte Dokumentensysteme sind nicht erforderlich. Ein bestandener Test einer Ebene darf jedoch nicht stellvertretend für alle anderen ausgegeben werden. Bei einem FDA-Bezug bestimmen Sie die tatsächlich einschlägigen Aufzeichnungsregeln gesondert.

Quellen: [5] [6] [10] [11] [9]

Vom Protokoll zur konkreten Probe im Well

Beginnen Sie mit der Ergebnisfrage: Welche Aussage soll der spätere Bericht ermöglichen? Beschreiben Sie dafür Messmodus, Plattenbelegung, Probenkennungen, Kontrollen, Berechnung, Rundung und Entscheidung. Ein vorgefertigtes Protokoll kann die Einrichtung unterstützen. Seine Verfügbarkeit belegt noch nicht, dass es Ihre Fragestellung richtig abbildet.

Der 7.6-Leitfaden unterscheidet Protokolle mit Einstellungen von Datendokumenten, die zusätzlich Messdaten und Berechnungsergebnisse enthalten. Für Ihre Nachweise sollte erkennbar sein, welcher freigegebene Ausgangsstand in eine Messung einging und welche Änderungen danach erfolgten. Die Dateibezeichnung allein reicht dafür als Vergleichsgrundlage nicht immer aus.

Prüfen Sie eine absichtlich vertauschte Probenzuordnung und eine fehlende Well-Belegung. Legen Sie vorab fest, welche Fälle die Auswertung verhindern und welche kontrolliert ergänzt werden dürfen. Die Software kann den physisch pipettierten Inhalt nicht allein aus einer eingegebenen Kennung erkennen. Dieser Übergang braucht einen zum Laborprozess passenden Nachweis.

Quellen: [1] [3] [11]

Die zusammengehörigen Komponenten und Einstellungen erfassen

Der Hersteller trennt SoftMax-Pro-GxP-Client, Admin Portal und GxP Admin. Der IT-Leitfaden beschreibt Single- und Multi-Computer-Aufbauten und verlangt übereinstimmende Komponentenversionen nach Installation oder Update. Die Bestandsaufnahme muss daher über den Versionsdialog des Messplatzes hinausgehen.

Dokumentieren Sie den gewählten Aufbau, Datenhaltung, Reader und Firmware sowie die genutzten Verbindungen. Beurteilen Sie Herstelleranforderungen an Betriebssystem und Umgebung passend zum Aufbau. Ein Nachweis aus einem Einzelplatzsystem kann etwa nicht ungeprüft die Zugriffs- und Sicherungsfragen einer verteilten Installation beantworten.

Der 7.6-Leitfaden nennt außerdem einen Punkt als erforderliches Dezimalzeichen für die Verarbeitung von Berechnungen. Prüfen Sie deshalb die tatsächliche regionale Einstellung und den verwendeten Eingabepfad. Die deutschsprachige Darstellung dieses Artikels mit Dezimalkomma ist keine Vorgabe für die technische Konfiguration. Ein Testfall sollte Formatfehler sichtbar machen, bevor Ergebnisse übernommen werden.

Quellen: [3] [6]

Rechte, Dokumentenstatus und fachliche Entscheidung verbinden

Der Herstellerleitfaden für 7.6 begrenzt den Document Workflow ausdrücklich auf die GxP-Lizenz; bei GLP sind diese Funktionen nicht sichtbar. Prüfen Sie deshalb den tatsächlich vorhandenen Ablauf, bevor Sie Anforderungen an Statuswechsel formulieren. Auch ein vordefinierter Rollenname belegt noch keine geeignete Befugnistrennung.

Die fachliche Frage lautet: Wer darf eine Vorlage entwickeln, zur Verwendung bereitstellen, Messungen ausführen und Ergebnisse bewerten? Prüfen Sie erlaubte Handlungen und bewusst fehlende Rechte mit unterschiedlichen Testkonten. Berücksichtigen Sie dabei Dokumentzugriff und Bearbeitungsbefugnis. Ein Benutzer kann einen Datensatz sehen dürfen, ohne dessen Auswertung verändern zu dürfen.

Legen Sie fest, welche Bedeutung eine Bestätigung oder Signatur im eigenen Prozess hat. Eine technische Statusänderung und ein fachlicher Review sind nicht austauschbar. Der Nachweis muss zeigen, welche Person welchen Inhalt in welchem Stand beurteilt hat. Ein grüner Status allein erklärt weder den geprüften Umfang noch die zugrunde liegende Entscheidung.

Quellen: [3] [6] [7]

Illustratives Prüfbeispiel: Blankkorrektur und Replikate unabhängig rechnen

Das folgende Beispiel ist vollständig konstruiert und kein realer Assay oder Produkttest. Das eigene Soll definiert zwei zugeordnete Replikate, einen Blank und den Faktor 5. Der dimensionslose Prüfkennwert K lautet: Mittelwert der beiden Signale minus Blank, anschließend multipliziert mit 5. Beide Replikate sind für eine abschließende Ausgabe erforderlich. Es gibt keine Konzentrations- oder Produktfreigabegrenze.

Unter Protokoll V1 gelten die Signale 0,82 und 0,86 sowie Blank 0,10. Unabhängig gerechnet: Mittelwert 0,84; korrigierter Wert 0,74; K = 3,70. V2 ändert ausschließlich den Blank auf 0,12. Die Prüfung verwendet festgelegte Testdaten in einer geeigneten Testumgebung. Eine manuell eingespeiste Zahlenprüfung belegt dabei keine tatsächliche optische Messung.

Jeder Fehlerfall startet aus einem wiederhergestellten definierten Ausgangszustand. Erwartete Reaktionen werden vor Ausführung festgelegt; die Tabelle behauptet keine automatischen Produktsperren. Ergänzen Sie beim Test die tatsächliche Beobachtung und ihren Beleg. Insbesondere darf ein ausgeschlossener Wert nicht allein deshalb verschwinden, weil das spätere Ergebnis günstiger aussieht.

Quellen: [6] [11] [7] [8]

Änderungen und Ausschlüsse bis zum Ergebnis nachvollziehen

Die öffentliche GxP-Selbstauskunft von Molecular Devices unterscheidet Rohdaten von Änderungen an Reduktion und Analyse. Für den Review ist damit die entscheidende Frage noch offen: Welcher Auswertestand wurde tatsächlich verwendet, und warum? Die unveränderte Erhaltung eines Rohsignals macht jede daraus erzeugte Auswertung noch nicht fachlich richtig.

Prüfen Sie gezielt einen Wechsel der Berechnungsregel, einen begründeten Ausschluss und eine spätere erneute Auswertung. Der Reviewer benötigt den Zusammenhang zwischen ursprünglicher Grundlage, Änderung, Begründung und verwendetem Ergebnis. Eine reine Suche nach dem Endwert würde genau diesen Zusammenhang übersehen.

Bestimmen Sie relevante Ereignisse anhand des eigenen Ablaufs und prüfen Sie deren Erfassung und Lesbarkeit. Systemhistorie und Datendokumenthistorie können unterschiedliche Fragen beantworten. Der Reviewumfang soll zu den Risiken passen und fachlich begründet sein. Die Existenz einer Historienfunktion ist keine Zusage, dass sämtliche gewünschten Ereignisse automatisch und vollständig abgedeckt sind.

Quellen: [4] [6] [11]

Export, AutoSave und vollständige Wiederherstellung auseinanderhalten

Ein weitergegebener Ergebnisbericht erfüllt nicht zwingend denselben Zweck wie der vollständige elektronische Datensatz. Der 7.6-IT-Leitfaden weist beim Single-Computer-Aufbau darauf hin, dass exportierte Dateien den System-Audit-Trail nicht vollständig erhalten. Bestimmen Sie deshalb vor einer Übergabe, welche zusätzlichen Zusammenhänge am Ursprungsort oder in einer anderen geeigneten Form zugänglich bleiben müssen.

Prüfen Sie die Wiederherstellung mit einem Datensatz, zu dem Änderungen und ein fachlicher Bearbeitungsstand gehören. Öffnet sich nur die letzte Ergebnisanzeige, ist damit der benötigte Kontext noch nicht nachgewiesen. Vergleichen Sie die wiederhergestellte Grundlage mit einem zuvor gesicherten unabhängigen Sollverzeichnis.

Der Hersteller beschreibt unterschiedliche Sicherungsverfahren je Aufbau und warnt vor Inkonsistenzen bei gleichzeitiger Nutzung während bestimmter Sicherungsvorgänge. Stimmen Sie den Ablauf daher mit der konkreten Betriebsanleitung ab. Eine AutoSave- oder Wiederherstellungsfunktion der Anwendung ersetzt kein passendes Backup-Konzept. Intervalle und Aufbewahrung werden aus dem eigenen Prozess abgeleitet, nicht aus einem pauschalen Produktversprechen.

Quellen: [3] [4] [6] [7]

Herstellerpakete und Änderungen passend zum eigenen Umfang bewerten

Ein Validierungspaket kann geeignete Belege liefern. Ordnen Sie jedoch jeden benötigten Nachweis seinem Stand und Zweck zu: Welche Edition, welche Funktion, welche Konfiguration und welche Voraussetzung wurden geprüft? Eine allgemeine Paketbeschreibung beantwortet diese Fragen nicht vollständig. Fehlende Abdeckung wird gezielt ergänzt, statt den Herstellernamen als Ersatz für eine Bewertung zu verwenden.

Für Änderungen betrachten Sie sowohl Software als auch Laborlogik. Ein Update kann Datenhaltung oder Berechtigungen berühren; eine Protokolländerung kann das Ergebnis verändern, obwohl die Softwareversion gleich bleibt. Begründen Sie, welche vorhandenen Belege gültig bleiben und welche zusätzlichen Tests erforderlich werden. Eine universelle Pflicht zur vollständigen Wiederholung folgt daraus nicht.

Dokumentieren Sie offene Befunde und Entscheidungen vor der vorgesehenen Verwendung. Ein rechnerisch richtiger Testwert löst keinen noch ungeklärten Verlust der Probenzuordnung. Ebenso wenig darf eine technische Versionsumstellung die fachliche Bewertung betroffener Protokolle ersetzen. Die Übergabe umfasst den geprüften Stand, Zuständigkeiten und den Umgang mit späteren Auffälligkeiten.

Quellen: [2] [6] [8]

Was QA, Labor und IT vor dem Start vorbereiten sollten

Benennen Sie zuerst den vorgesehenen Assay und die Verwendung seiner Ergebnisse. Die Laborleitung liefert fachliche Regeln und repräsentative Daten. QA klärt Nachweis- und Entscheidungsbedarf. IT beschreibt Komponenten und Betrieb. Der Anbieter stellt versionspassende Unterlagen bereit. Ein gemeinsamer Anforderungsausschnitt ist dafür meist hilfreicher als mehrere unverbundene Dokumentlisten.

Der Aufwand hängt unter anderem von verschiedenen Auswertelogiken, Altprotokollen, Schnittstellen, Rollen und vorhandener Evidenz ab. Auch die Verfügbarkeit fachlich begründeter Sollwerte zählt. Eine reine Anzahl installierter Arbeitsplätze ist deshalb keine belastbare Schätzgrundlage. Nutzen Sie folgende Vorbereitungsliste:

• Verwendung, Regelbereich und Herstellergrenzen dokumentiert.
• Edition, Lizenz und zusammengehörige Komponentenversionen erfasst.
• Reader, Firmware, Anbindung und Umgebung beschrieben.
• Gerätequalifizierung, Softwareprüfung und Methodeneignung zugeordnet.
• Probenkennungen, Well-Belegung und Kontrollen festgelegt.
• Berechnungen, Rundung und Ausschlussregeln fachlich begründet.
• Unabhängige Normal- und Fehlerfälle vorbereitet.
• Rollen, Review und gegebenenfalls Signaturbedeutung bestimmt.
• Exportkontext und Wiederherstellung geeigneter Datensätze vorgesehen.
• Lieferantenbelege, Änderungen und betriebliche Verantwortung zugeordnet.

Quellen: [6] [8] [11]