STARLIMS validieren: vom Instrumentendokument zum richtig zugeordneten Laborergebnis

1. QM LIMS, QM Essentials und Ihren GMP-Einsatz abgrenzen

STARLIMS beschreibt eine Plattform aus Quality Manufacturing LIMS, SDMS, LES, ELN und Analysekomponenten. Der Produktname allein sagt deshalb wenig darüber aus, welcher Bestandteil Ihre Aufzeichnungen verarbeitet. R&D-Angebote wie Labstep ELN sowie Lösungen für andere Branchen sind keine austauschbaren Bezeichnungen für das eingesetzte Qualitätslabor-System.

QM Essentials wird als vorkonfiguriertes, abonnementbasiertes Cloud-LIMS für kleinere und mittlere chargenproduzierende Unternehmen angeboten. Genannt werden unter anderem Batch Login, Environmental Monitoring und Outsource Samples; Stability Studies und Advanced Analytics werden als optionale Erweiterungen beschrieben. Welche Komponenten und Anpassungen Ihr Vertrag umfasst, müssen Sie gesondert feststellen.

Dieser Artikel behandelt den Einsatz im GMP-Qualitätslabor für Humanarzneimittel. Die EU-Kommission führt hierfür Annex 11 weiterhin in der Revision Januar 2011. Andere Verwendungszwecke, etwa klinische Diagnostik, sowie Anforderungen anderer Märkte brauchen eine eigene Einordnung. Aus dem Namen STARLIMS folgt weder eine pauschale GAMP-Kategorie noch eine allgemeine Validierungsfreistellung.

Quellen: [1] [2] [6] [7]

2. Eine Komponentenkarte statt eines pauschalen Systemumfangs erstellen

Beginnen Sie mit einer tatsächlich genutzten Prüfung. Zeichnen Sie auf, wo die Probe angelegt, die Arbeitsanweisung aufgerufen, das Messergebnis erzeugt und die Qualitätsentscheidung getroffen wird. Kennzeichnen Sie jeden Medienwechsel. Auch ein außerhalb von STARLIMS aufbewahrter Rohdatensatz gehört in diese Betrachtung, wenn er zum Verständnis der Entscheidung benötigt wird.

Die folgende Tabelle ist eine eigene Planungshilfe. Sie beschreibt Fragen an Ihre Umgebung, keine zugesicherte Lizenzkombination. Eine nützliche Ergänzung ist jeweils der verantwortliche Ansprechpartner und der konkrete Nachweis: Konfigurationsstand, freigegebene Anforderung, Testbeleg oder Betriebsvereinbarung.

Quellen: [1] [3] [4] [7] [8]

3. Prüfumfang aus der Ergebnisentscheidung ableiten

Formulieren Sie Anforderungen so, dass ein Laborverantwortlicher das gewünschte Verhalten beurteilen kann. Beispielsweise: Ein Ergebnis darf nur der eindeutig identifizierten Probe und der vorgesehenen Prüfung zugeordnet werden. Eine unbekannte Einheit muss vor weiterer Verwendung geklärt werden. Eine nachträgliche Korrektur muss mit dem betroffenen ursprünglichen Eintrag zusammen nachvollziehbar sein.

Bewerten Sie dann den möglichen Schaden: Ein unvollständiger Suchfilter hat andere Folgen als ein vertauschtes Ergebnis, das eine Materialentscheidung beeinflusst. Berücksichtigen Sie vorhandene Kontrollen und deren nachgewiesene Wirkung. Wenn niemand weiß, ob der Eingang auf Dubletten geprüft wird, ist das zunächst eine Wissenslücke; es ist kein Beleg für ein geringes Risiko.

Fordern Sie passende Herstellerunterlagen an und ordnen Sie deren Abdeckung Ihren Anforderungen zu. Ein nachgewiesener Standardablauf kann Arbeit ersparen. Offen bleiben jedoch möglicherweise kundenspezifische Extraktionsregeln, Stammdaten oder Schnittstellen. Die Risikoentscheidung sollte genau diese Lücken adressieren, statt sämtliche Lieferantenbelege zu verwerfen oder ungeprüft zu übernehmen.

Quellen: [7] [9]

4. SDMS: Das gelesene Ergebnis mit seiner Quelle verbinden

Die offizielle SDMS-Beschreibung nennt die Erfassung und Verwaltung wissenschaftlicher Dokumente sowie die Extraktion von Daten aus instrumentenbezogenen PDF-Dateien. Das ist eine relevante Produktfähigkeit, aber noch keine Beschreibung Ihrer konkreten Extraktionsregel. Lassen Sie sich zeigen, wie ein Feld erkannt, die passende Probe bestimmt und eine nicht lesbare oder mehrdeutige Datei behandelt wird.

Erstellen Sie einen kontrollierten Satz typischer Quelldokumente. Variieren Sie gezielt Probenkennungen, Messgrößen, Dezimaldarstellung, Seitenumbrüche und Einheiten, soweit solche Varianten im vorgesehenen Betrieb vorkommen können. Für jede Variante steht vor dem Test fest, welcher Eingang akzeptiert, zurückgewiesen oder zur Klärung gehalten werden soll. Ein ignoriertes Feld darf nicht unbemerkt einen plausiblen Standardwert erzeugen.

Prüfen Sie das vollständige Zielergebnis nach der Übernahme. Ein technischer Erfolgsstatus reicht für eine fachliche Zuordnungsprüfung nicht aus. Bewahren Sie den unabhängigen Originalbeleg neben dem beobachteten Zielzustand auf. Die lesbare Darstellung einer Datei beweist außerdem nicht, dass sämtliche benötigten instrumentellen Rohdaten und Metadaten in ihr enthalten sind.

Quellen: [3] [7] [8]

5. Durchgerechnetes Beispiel: Zwei Proben, eine Extraktionsregel

Illustratives Prüfbeispiel, kein Kundenfall und kein ausgeführter STARLIMS-Produkttest: Die Testdatei LAB-017 enthält Probe A17 mit Prüfung Gehalt und 0,125 mg/mL sowie Probe B18 mit derselben Prüfung und 0,250 mg/mL. Für den Zielprozess ist die Einheit µg/mL festgelegt. Die unabhängige Rechnung lautet 0,125 × 1.000 = 125 und 0,250 × 1.000 = 250. Weitere Verdünnungsfaktoren sind hier ausdrücklich nicht vorgesehen.

Die freigegebene Beispielanforderung verlangt, dass die Einheit genau einmal umgerechnet und jede Probe anhand ihrer Kennung zugeordnet wird. Als Fehlerkontrolle dient ein separat erzeugter Testeingang. Das unveränderte Original und die vorab geprüften Sollwerte bleiben erhalten. Ob STARLIMS die gewünschte Kontrolle durch Konfiguration, eine Anbindung oder eine ergänzende Maßnahme erfüllt, ist im Projekt erst zu belegen. Im konstruierten Soll existieren nur A17 und B18 als zulässige Proben; X99 ist nicht angelegt. Eine identische Datei mit derselben Dateikennung und unverändertem Inhalt gilt hier als Dublette und darf keinen zweiten fachlich verwendbaren Ergebnissatz erzeugen.

Quellen: [3] [7] [9]

6. LES-Ausführung und Methodenstand zusammen prüfen

STARLIMS beschreibt LES als Unterstützung geführter Arbeitsanweisungen mit Anbindung an das LIMS. Die Herstellerseite nennt auch das Prüfen und Genehmigen von Tests vor der Weitergabe. Für Ihre Validierung bleibt entscheidend, welchen Teil der Laboranweisung Sie dort tatsächlich abbilden und welche Schritte außerhalb stattfinden.

Wählen Sie eine Anweisung mit einer fachlich relevanten Entscheidung, beispielsweise einer zusätzlichen Verdünnung nach einem definierten Messergebnis. Prüfen Sie den normalen Weg und den abweichenden Weg anhand vorab bestimmter Eingaben. Fragen Sie zusätzlich, was bei einer Unterbrechung mit bereits erfassten Werten geschieht und welcher Benutzer den Vorgang fortsetzen darf.

Ändert sich die zugrunde liegende Arbeitsanweisung, klären Sie den Übergang für neue und bereits begonnene Prüfungen. Ein aktueller Bildschirm allein erklärt nicht den früheren Ausführungsstand. Der Nachweis sollte erkennen lassen, welche Vorgabe galt und wie eine Änderung behandelt wurde. Die konkrete technische Versionsbindung ist aus den öffentlichen Produktseiten nicht vollständig ersichtlich und muss für Ihre Umgebung belegt werden.

Quellen: [4] [8] [7]

7. Ergebnisprüfung, Korrekturen und Freigaben auseinanderhalten

Beschreiben Sie, was ein Prüfer vor der Genehmigung tatsächlich sehen soll: Ergebnis, Einheit, Spezifikation, Quelle, relevante Bearbeitungen und noch offene Auffälligkeiten. Legen Sie auch fest, wer Zuordnungen ändern darf. Ein Benutzer, der eine fehlerhafte Extraktionsregel korrigiert, entscheidet damit nicht automatisch über die Verwendbarkeit aller schon übernommenen Ergebnisse.

Als eigener Prüffall eignet sich eine zulässige Ergebniskorrektur nach dem ersten Review. Kann der spätere Prüfer den ursprünglichen Eintrag, den korrigierten Wert und den dokumentierten Anlass zusammen verstehen? Welche Folgen hat die Änderung für einen schon erstellten Bericht oder eine bereits erfolgte Weitergabe? Die Antwort ergibt sich aus Ihrem Workflow und den tatsächlichen Aufzeichnungen.

Wo elektronische Signaturen eingesetzt werden, prüfen Sie den vollständigen Signaturprozess und seine Verbindung zum genehmigten Datensatz. Eine Laborergebnisgenehmigung ist von einer Materialentscheidung und der gegebenenfalls rechtlich erforderlichen QP-Zertifizierung einer Arzneimittelcharge zu unterscheiden. Annex 16 beschreibt diesen eigenständigen Zertifizierungs- und Freigabeprozess; ein beliebig benannter LIMS-Status ersetzt ihn nicht.

Quellen: [7] [8] [10]

8. Übergaben und übernommene Bestandsdaten fachlich vergleichen

Wenn STARLIMS Ergebnisse oder Entscheidungen an ein weiteres System übergibt, vereinbaren beide Seiten deren Bedeutung. Enthält eine Nachricht einen vorläufigen Messwert, ein geprüftes Ergebnis oder eine abgeschlossene Laborentscheidung? Ermitteln Sie die tatsächlich übertragenen Felder, ihre Einheiten und die Voraussetzungen für die Verwendung im Zielsystem.

Planen Sie für Ihren Integrationsweg einen abgelehnten Datensatz und eine Wiederholung nach Fehlerbehebung. Beobachten Sie dabei auch den bestehenden Zielzustand. Ein nachträglich angenommener älterer Ergebnissatz darf beispielsweise nicht unbemerkt eine neuere Entscheidung verdrängen, wenn dies Ihrem vorgesehenen Ablauf widerspricht. Die konkrete Reihenfolgelogik ist festzulegen, nicht aus dem Produktnamen abzuleiten.

Bei der Datenübernahme aus einem Altsystem ist ein Summenvergleich nur ein Einstieg. Wählen Sie begründet zusätzliche Vergleiche für Probe, Prüfung, Methodenbezug, Status und historische Änderungen. Dokumentieren Sie, welche Informationen bewusst im zugänglichen Altsystem verbleiben. Eine solche Aufteilung braucht klare Verweise und Verantwortlichkeiten; ein schöner Abschlussbericht schließt eine ungeklärte Historienlücke nicht.

Quellen: [7] [8] [9]

9. Produkt-, Plattform- und Regeländerungen kontrolliert behandeln

Ein offizieller STARLIMS-Beitrag beschreibt QM 12.3 SP1 auf Technology Platform 12.4. Dieser Beitrag ist ein dokumentiertes Versionsbeispiel, kein Nachweis des neuesten Standes im Oktober 2026. Er zeigt, weshalb der Name des LIMS allein nicht als Versionsangabe genügt. Halten Sie Ihre tatsächlich eingesetzte Anwendung, Plattform, Erweiterungen und Extraktionsregeln getrennt fest.

Bei einer Änderung bestimmen Sie zuerst die betroffenen Datenwege und Entscheidungen. Ein neues Instrumentenlayout kann andere Tests erfordern als ein geänderter Genehmigungsablauf. Nutzen Sie geeignete bestehende Belege weiter und ergänzen Sie die begründete Prüfung der Auswirkungen. Die Auswahl sollte erkennen lassen, welche früheren Annahmen weiterhin gelten und welche neu nachgewiesen werden müssen.

Zur Betriebsfähigkeit gehören außerdem Wiederherstellung und historische Lesbarkeit. Ein brauchbarer Wiederherstellungsversuch zeigt nicht nur eine startende Anwendung, sondern einen nachvollziehbaren ausgewählten Vorgang mit den benötigten Bezügen. Für die langfristige Aufbewahrung bestimmen Sie Datenumfang und Frist aus dem tatsächlichen Zweck. Ein einzelner PDF-Export oder eine pauschale Jahreszahl ist dafür keine allgemeine Lösung.

Quellen: [5] [7] [8]

10. Was Laborleitung, QA und IT vor Projektstart vorbereiten sollten

Der Aufwand hängt stark von der Zahl wirklich unterschiedlicher Prüfabläufe, Eingangsformate und Entscheidungen ab. Zehn Instrumente mit demselben kontrollierten Format können anders zu bearbeiten sein als zwei Geräte mit stark wechselnden Berichten. Auch unklare Stammdaten, benötigte Historien und spätere Ausnahmen treiben die Arbeit. Eine Nutzerzahl allein ist deshalb keine belastbare Kalkulationsbasis.

Die Laborleitung liefert fachlich repräsentative Prüfungen und unabhängige Sollwerte. QA bestimmt Entscheidungswege und bewertet offene Befunde. IT und Systemverantwortliche klären Betrieb, Zugriffe, Schnittstellen und Wiederherstellung; der Anbieter muss den tatsächlichen Funktions- und Lieferumfang belegen. Benennen Sie zusätzlich, wer fachliche Konflikte zwischen gewünschtem Ablauf und Produktkonfiguration entscheiden darf.

• Produktvariante, Module, Release und Plattformstand sind für die vorgesehene Umgebung dokumentiert.
• Ein realer Probenweg mit allen Eingängen, Entscheidungen und Übergaben ist gemeinsam beschrieben.
• Quelldaten, Extraktionsregeln, Einheiten und unabhängige Sollwerte liegen vor.
• Normale Fälle, Mehrdeutigkeiten, Fehlereingänge und Wiederholungen haben klare Annahmekriterien.
• Review, Korrektur, Signatur und Weitergabe sind mit Berechtigungen und Historie abgegrenzt.
• Lieferantenbelege sind Anforderungen zugeordnet; verbleibende Nachweislücken sind sichtbar.
• Änderung, Wiederherstellung, Aufbewahrung und Datenexit haben benannte Verantwortliche.

Quellen: [7] [9]