PHARMA LAB · PL-06-005

CDS auswählen: Laboranforderungen, Architektur und Nachweise

Eine verfügbare Funktion belegt noch keinen geeigneten QC-Ablauf. Übersetzen Sie den CDS-Verwendungszweck in Anforderungen und vergleichbare Demonstrationen.
Technische Illustration zweier Fachleute, die am Tisch eine CDS-Architektur mit Chromatografen und vernetzten Laborarbeitsplätzen bewerten.

Ein CDS wird häufig nach unterstützten Geräten und Berichtsdarstellung ausgewählt. Schwierigkeiten zeigen sich später: Eine unterbrochene Sequenz verhält sich unerwartet, der Prüfer sieht die Auswertehistorie nicht oder ein zweiter Standort hängt von einer unbewerteten Verbindung ab. Die Auswahl muss den gesamten Weg vom Signal zur Entscheidung betrachten.

1. Die vom CDS zu unterstützende Arbeit beschreiben

Definieren Sie Geräte, Modelle, Module, Methoden, Techniken, Benutzer, Standorte und erwartete Auslastung. Unterscheiden Sie installierte Geräte von künftigen Erweiterungen und kennzeichnen Sie bestätigte Planungen. Halten Sie fest, wer Daten erfasst, auswertet, prüft und genehmigt, welche Ergebnisse GMP-Entscheidungen unterstützen und welche Tätigkeiten in anderen Systemen verbleiben.

Die angegebene Unterstützung einer Gerätefamilie belegt nicht die tatsächliche Kombination aus Modell, Modul, Version und Funktion. Fordern Sie Nachweise für die vorgeschlagene Konfiguration an: Gerätesteuerung, Erfassung benötigter Kanäle, Sequenzverwaltung und Fehlerverhalten. Vermeiden Sie allgemeingültige Kapazitätsgrenzen; definieren Sie eine repräsentative Laborauslastung und deren Bewertungskriterium.

Die Übersicht zu LIMS, ELN, CDS und SDMS hilft bei den Systemgrenzen. Das CDS darf nicht stillschweigend für Probenlebenszyklus oder Archiv verantwortlich werden, wenn diese Funktionen anderweitig zugeordnet sind.

2. Datenerfassung, Auswertung und Prüfung trennen

Stellen Sie Objekte und Zuständigkeiten im Ablauf dar: Analysenauftrag, Sequenz, Injektion, Originalsignal, Auswertemethode, Ergebnis, Prüfung und Genehmigung. Prüfen Sie die pro Schritt benötigten Module und Lizenzen. Ein Arbeitsplatz zur Berichtsanzeige ermöglicht möglicherweise keine Prüfung des Datensatzes und seiner Audit Trails.

Kontrollen müssen Benutzer und Methodenversionen erkennen lassen, relevante Auswertungen erhalten und erklären, warum sich ein Ergebnis geändert hat. Betrachten Sie Rollentrennung, Berechtigungen, Bedeutung der Genehmigung und Verknüpfung zur genehmigten Aufzeichnung. Die Bezeichnung „Part 11 compliant“ ersetzt keine Bewertung von Verwendung, Konfiguration und Laborverfahren.

Lassen Sie einen vollständigen Vorgang zeigen: genehmigte Änderung, Begründung, neue Version, Vergleich zur vorherigen und anschließende Prüfung. Eine Audit-Trail-Schaltfläche genügt nicht, wenn der Prüfer Ereignisse nicht mit dem betrachteten Ergebnis verbinden kann.

3. Architekturen und Abhängigkeiten vergleichen

Beschreiben Sie, wo Gerätesteuerung, Erfassung, Speicherung, Auswertung und Prüfung stattfinden. Lokale, zentrale oder verteilte Architekturen können je nach Kontext geeignet sein; keine ist automatisch konform oder vorzuziehen. Identifizieren Sie Server, Arbeitsplätze, Netzwerk, Identitätsverwaltung, gemeinsame Dienste sowie LIMS- oder SDMS-Verbindungen.

Bewerten Sie für jede Abhängigkeit deren Ausfall: Läuft die Erfassung weiter oder stoppt sie? Wo verbleiben die Daten? Wie wird die Unterbrechung gemeldet und die Wiederaufnahme abgeglichen? Lassen Sie dies an der vorgeschlagenen Konfiguration nachweisen, ohne eine unabhängige lokale Erfassung bei jedem CDS vorauszusetzen.

Kontinuität betrifft auch Menschen: Wer greift ein, wer bewertet analytische Auswirkungen und wer genehmigt die Wiederinbetriebnahme? Planen Sie Ausfallprüfungen in isolierten, genehmigten Umgebungen. Eine Vertriebsdemonstration rechtfertigt keine Unterbrechungen produktiver Systeme.

4. Eine Matrix aus Anforderung, Risiko und Nachweis nutzen

Vergleichen Sie Angebote anhand gleicher Szenarien und synthetischer Datensätze. Vereinbaren Sie Ausgangsbedingungen, erwartetes Ergebnis und Akzeptanzkriterium vorab. Dokumentieren Sie Version, Konfiguration, Ergebnis und Grenzen der Demonstration. Unterscheiden Sie vorhandene Funktionen, erforderliche Konfiguration, vorgeschlagene Anpassung und zukünftige Zusage.

AnforderungZu bewertendes RisikoDemonstrationsszenarioBenötigter Nachweis
GerätekompatibilitätNicht unterstützte Funktion oder KanalDaten mit repräsentativer Kombination erfassenDokumentierte Versionen, Kanäle und Grenzen
Kontrollierte MethodenFalsche Version verwendetNeue Version aktivieren, vorherige lesenStatus, Rechte und Datensatzbeziehung
Vollständige PrüfungNur Bericht genehmigtErfassung und erneute Auswertung rekonstruierenDaten, Ereignisse und Entscheidung für Prüfer zugänglich
RollenZu weitreichende RechteErlaubte und verbotene Aktion prüfenErgebnisse je Rolle, keine gemeinsamen Konten
NetzwerkunterbrechungDatenverlust oder DuplikateSimulierter Ausfall und kontrollierte WiederaufnahmeBeobachtetes Verhalten und Abgleich
Export und AbrufFormat- oder LizenzabhängigkeitVollständigen historischen Datenumfang abrufenSignale, Methoden, Metadaten und nutzbares Anzeigeprogramm
LIMS-SchnittstelleFalsche Zuordnung oder UmwandlungErgebnis, Einheit und Kennung übertragenZuordnung, Fehlerbehandlung und semantischer Vergleich

Die Matrix ist ein eigenständiges Arbeitsbeispiel, keine validierte Spezifikation. Eine nicht nachgewiesene wesentliche Anforderung bleibt offen: Ein guter Durchschnittswert gleicht den Verlust von Originaldaten nicht aus. Gewichtungen und Auswahlkriterien sind durch das Labor zu begründen; allgemeingültige Ranglisten gibt es nicht.

5. Simulierter Fall und Lebenszyklusentscheidung

Zwei QC-Standorte vergleichen eine Lösung mit lokalen Arbeitsplätzen und eine mit zentralen Diensten. Beide zeigen reguläre Erfassung und Berichterstellung. Die erste verlangt eine konsistente Steuerung mehrerer Konfigurationen, die zweite führt eine Netzwerkabhängigkeit zwischen Standorten ein. Das sind keine absoluten Vor- oder Nachteile: Prüfungen und Zuständigkeiten unterscheiden sich.

Das QC–QS–IT-Team ergänzt eine unterbrochene Sequenz, die Prüfung vom anderen Standort und den Abruf eines historischen Datensatzes. Kann das zentrale Angebot das Verhalten bei Verbindungsverlust nicht belegen, bleibt dieser Punkt offen. Kann das lokale Angebot die kontrollierte Methodenverteilung nicht nachweisen, bleibt auch dieser Punkt offen. Das Beispiel benennt keinen Sieger und erfindet keine Kosten: Nachweise und unverzichtbare Anforderungen bestimmen die Wahl.

Prüfen Sie vor einer Bindung Validierbarkeit, verfügbare Dokumentation, Schulung, Unterstützung, Updates, zukünftige Kompatibilität und Export bei Vertragsende. Klären Sie, wer native Formate, Beziehungen und Leseabhängigkeiten erhält: vorhandene Dateien belegen noch keinen nutzbaren Abruf.

Eine Demonstration unterstützt die Auswahl; sie ersetzt nicht die Validierung des installierten Systems für seinen Verwendungszweck. Übergeben Sie genehmigte Anforderungen, bewertete Nachweise, Restrisiken und vor Freigabe zu schließende Bedingungen an das Projekt. Halten Sie spätere Änderungen von Konfiguration und Einsatzbereich nachvollziehbar.

6. Referenzen und Grenzen

Quellen am 1. Oktober 2026 geprüft; Beitrag am 2. Oktober erstellt. Kontext: GMP-Labor für Humanarzneimittel. Die Planungskriterien sind an den Prozess anzupassen und schreiben keine bestimmte Architektur vor.

Fachinformationen zur Entscheidungsfindung; sie ersetzen weder freigegebene Verfahren noch geltende Anforderungen oder das Gerätehandbuch.

Weiterführende Artikel