Inhaltsverzeichnis
Das Wichtigste vorab
Wie validieren Sie Agilent MassHunter im GxP-Einsatz?
Sie validieren die tatsächlich verwendete Kombination aus Gerät, Acquisition, Auswertung, Datenhaltung und Benutzerverwaltung für ihren vorgesehenen Zweck. Entscheidend ist, ob Messdaten, Methodenstände, Bearbeitung und Ergebnisse nachvollziehbar zusammenpassen. Herstellerunterlagen liefern dafür konkrete Belege, deren Passung Sie prüfen. Altresultate öffnen, erneut verarbeiten und manuell ändern sind getrennte Prüffälle. Der Familienname MassHunter oder eine einzelne Versionsnummer reicht als Systembeschreibung nicht aus.
- Erfassung und Auswertung besitzen eigene Versionen und Abhängigkeiten.
- OpenLab-/ECM-Anbindung richtet sich nach der konkreten Betriebsform.
- Ergebnisanzeige und erneute Berechnung brauchen unterschiedliche Sollkriterien.
- Datenformat, Methodenbezug und Bearbeitungshistorie gehören in den Nachweis.
Welche MassHunter-Komponenten gehören zu Ihrem System?
Agilent beschreibt MassHunter Acquisition für LC/MS als Instrumentensteuerung und Datenerfassung für unterschiedliche LC/MS-Gerätefamilien. Qualitative Analysis und Quantitative Analysis erfüllen andere Aufgaben. Beginnen Sie deshalb mit dem tatsächlich eingesetzten Mess- und Auswertungsweg. Die bloße Angabe „MassHunter installiert“ lässt wesentliche Abhängigkeiten offen.
Der hier betrachtete Dokumentstand ist bewusst uneinheitlich: Qualitative Analysis 14.0 wird in Release Notes vom Mai 2026 beschrieben. Die separat betrachteten LC/TQ-Acquisition-Release-Notes tragen Version 12.3 und Mai 2025. Das sind komponentenspezifische Belegstände, keine gemeinsame freigegebene Kombination und keine Aussage über jeden neuesten Patch.
Erfassen Sie Instrument, Steuerungssoftware, Auswertungsprogramme, Betriebssystem, Datenablage und angebundene Dienste mit ihren realen Ständen. Ordnen Sie jedem Übergang einen Nachweis zu: Wer erzeugt den Datensatz, wer verändert ihn, wo wird er gespeichert und womit später gelesen? GC/MS- oder ICP-MS-Funktionen übernehmen Sie nur aus den jeweils passenden Unterlagen.
Den analytischen Zweck vor der Testliste festlegen
Dieser Leitfaden verwendet das Beispiel einer LC/MS-Anwendung in der Qualitätskontrolle von Humanarzneimitteln. Für computergestützte GMP-Tätigkeiten ist Annex 11 der EU-GMP-Leitlinie ein maßgeblicher Bezug. Der aktuelle EudraLex-Index führt weiterhin die Revision Januar 2011. Andere Laborzwecke benötigen eine eigene Einordnung.
Beschreiben Sie konkret, welche Entscheidung ein Ergebnis unterstützt. Eine Identitätsprüfung, ein quantitativer Gehalt und eine explorative Auswertung stellen unterschiedliche Anforderungen. Halten Sie fest, wer Messungen beauftragt, Methoden vorgibt, Ergebnisse bewertet und die Nutzung beschließt. So wird aus „Datenintegrität sicherstellen“ eine überprüfbare Anforderung.
Systemvalidierung belegt nicht automatisch die analytische Eignung einer Methode. Umgekehrt ersetzt eine geeignete Methode keinen Nachweis der Datenverarbeitung. Bei FDA-relevanten Aufzeichnungen klären Sie zusätzlich den tatsächlichen Part-11-Scope anhand der zugrunde liegenden Aufzeichnungspflichten. Der Produktname schafft weder eine universelle FDA-Pflicht noch eine Zulassung.
Eine Komponentenmatrix verhindert falsche Versionsannahmen
Die folgende Arbeitshilfe führt unterschiedliche Ebenen zusammen. Tragen Sie für Ihr Projekt jeweils den installierten Build und die dazu gültige Herstellerdokumentation ein. Ein vorhandener Herstellerbeleg ist nutzbar, wenn Zweck, Version, Konfiguration und erwartetes Verhalten passen. Eine zusätzliche Prüfung schließt die konkret verbleibende Lücke.
Besonders wichtig ist der Versionsabgleich zwischen Acquisition und Auswertung. Die ältere LC/TQ-12.3-Dokumentation nennt Qualitative 13.0 als unterstützten Stand. Qualitative 14.0 nennt andere, neuere Abhängigkeiten. Aus zwei einzeln verfügbaren Programmen folgt daher keine belegte Kompatibilität.
| Baustein | Belegter Bezug | Im Projekt nachzuweisen |
|---|---|---|
| LC/TQ-Erfassung | Acquisition 12.3, Dokument Mai 2025 | Gerät, Build, Treiber, Worklist und erzeugter Datensatz |
| Qualitative Auswertung | Qualitative Analysis 14.0, Mai 2026 | Passende Eingangsdaten, Methodenstand und vorgesehene Verarbeitung |
| Quantitative Auswertung | Eigenständige Komponente; hier nur als Abhängigkeit belegt | Gültige Anleitung für verwendete Integration, Berechnung und Ergebnisstände |
| Datenhaltung und Anmeldung | Konfigurationsabhängige lokale oder zentrale Dienste | Tatsächlicher Speicherort, Authentifizierung und wirksame Berechtigungen |
Datenformat und Betriebsform gemeinsam betrachten
Qualitative Analysis 14.0 beschreibt Workstation, Networked Workstation und einen OpenLab-CDS-Client/Server-Kontext. Damit ist eine OpenLab-Anbindung in bestimmten Konfigurationen belegt. Sie ist weder bei jeder MassHunter-Installation vorausgesetzt noch generell ausgeschlossen. Die tatsächliche Architektur entscheidet über Speicher- und Verwaltungsgrenzen.
Der Versionsstand unterstützt .d und .sirslt; für .sirslt wird ein Sample Audit Trail beschrieben. Auch ein Export nach .d ist dokumentiert. Daraus folgt keine identische Informationsabdeckung der Formate. Prüfen Sie bei einem Export, welche Daten und Bezüge übertragen werden und welche Informationen weiterhin im Ursprung benötigt werden.
Eine hilfreiche Abnahmefrage lautet: Kann ein berechtigter Prüfer das gewählte Ergebnis einschließlich seiner Herkunft nachvollziehen, ohne auf mündliche Erläuterungen angewiesen zu sein? Legen Sie dafür einen repräsentativen Datensatz fest. Vergleichen Sie Original, Auswertung, Export und gegebenenfalls Bericht anhand der tatsächlich benötigten Informationen.
Öffnen, erneut verarbeiten und manuell ändern unterscheiden
Die Release Notes zu Qualitative 14.0 unterscheiden das unveränderte Anzeigen früherer Ergebnisse von erneut ausgeführten Workflows oder manuellen Aktionen. Geänderte Algorithmen können bei erneuter Verarbeitung andere Ergebnisse liefern. Deshalb benötigt ein Versionswechsel getrennte Erwartungen für reine Anzeige und neue Berechnung.
Definieren Sie vor dem Vergleich, welche Ausgangsdaten und Methodenstände gleich bleiben. Halten Sie jede bewusst geänderte Größe fest. Sonst lässt sich ein Unterschied nicht sinnvoll einem Algorithmus, einer Methode oder einer anderen Datenbasis zuordnen. Ein abweichender Zahlenwert ist zunächst ein Befund mit Untersuchungsbedarf.
Manuelle Integration wird nicht über eine allgemeine MassHunter-Funktion angenommen. Die konkrete Bedienaktion, Berechtigung und Historie sind anhand der tatsächlich verwendeten Auswertungskomponente zu prüfen. Für den Review bestimmen Sie, welche ursprünglichen und nachfolgenden Ergebnisse benötigt werden. Weder jede Änderung noch jede Wiederholung ist automatisch ein OOS-Fall oder ein Täuschungsversuch.
Illustratives Prüfbeispiel: ein Ergebniswechsel von 1,5 Prozent
Das folgende Beispiel ist eine eigene, vollständig konstruierte Arbeitshilfe. Es beschreibt keine durchgeführte Produktprüfung und keine analytische Freigabegrenze. Beispieldatensatz Q17 besitzt das dokumentierte Altresultat R1 mit einem Flächenwert von 100.000 willkürlichen Einheiten. Das Labor plant einen Auswertungswechsel und legt vorab eine Untersuchungsschwelle von mehr als 1,0 Prozent fest.
Die Schwelle dient hier ausschließlich dazu, Vergleichsbefunde gezielt zu untersuchen. Sie ist keine Arzneimittelspezifikation und keine allgemeine Softwaretoleranz. Für jeden Teilfall wird eine kontrollierte Kopie des gleichen Ausgangszustands verwendet. Die Tabelle benennt das Soll; die tatsächlichen Beobachtungen werden erst bei der Ausführung eingetragen.
| Teilfall | Vorgegebene Vergleichswerte | Soll und Entscheidung |
|---|---|---|
| Altresultat nur öffnen | R1 = 100.000; angezeigter Vergleichswert = 100.000 | 0 Prozent Unterschied; Identität und ursprünglichen Kontext zusätzlich prüfen. |
| Workflow erneut ausführen | R1 = 100.000; hypothetisches R2 = 101.500 | (101.500 − 100.000) / 100.000 × 100 = 1,5 Prozent; Ursache untersuchen. |
| Grenzfall der eigenen Regel | Hypothetischer Vergleichswert = 101.000 | 1,0 Prozent; Regel „mehr als 1,0 Prozent“ nicht ausgelöst. Weitere Akzeptanzkriterien bleiben wirksam. |
| Falsche Probe trotz gleichem Wert | Q18 statt Q17; beide Werte = 100.000 | Zuordnungsprüfung nicht bestanden; numerische Gleichheit reicht nicht. |
| Ergebnis exportieren | Q17/R1 mit festgelegten erforderlichen Begleitinformationen | Daten- und Methodenbezug sowie benötigte Historie am vorgesehenen Leseort nachweisen. |
Benutzer, Bearbeitungsbefugnis und Audit-Umfang belegen
Erstellen Sie eine kleine Tätigkeitsmatrix: messen, Methoden ändern, auswerten, Ergebnisse prüfen, exportieren und administrieren. Beschreiben Sie die zulässigen Handlungen jeder Rolle. Prüfen Sie anschließend mit repräsentativen Konten, ob die wirklichen Berechtigungen diese Vorgabe abbilden. Eine Rollenbezeichnung allein belegt keine wirksame Begrenzung.
Die LC/TQ-Release-Notes nennen im historischen Abschnitt 12.0 Audit-Funktionen für Methoden, Worklists, Datendateien und Studies. Diese konkrete Angabe hilft beim Einordnen vorhandener Installationen. Sie belegt keinen lückenlosen Ereigniskatalog aller MassHunter-Ausprägungen. Für Ihr System muss erkennbar sein, welche Änderung an welchem Objekt nachgewiesen werden kann.
Planen Sie den Review so, dass relevante Änderungen und ihre Bedeutung für das Ergebnis sichtbar werden. Häufigkeit und Umfang richten sich nach Prozess und Risiko. Falls elektronische Signaturen eingesetzt werden, bestimmen Sie zusätzlich Bedeutung und Datensatzbezug. Ein Login, eine Bearbeitungshistorie oder eine gespeicherte Datei erfüllt diese Aufgabe nicht automatisch.
Den benötigten Datenzusammenhang wiederherstellen
Bestimmen Sie, welche Informationen einen Laborbefund im vorgesehenen Aufbewahrungszeitraum nachvollziehbar machen. Dazu können Messdaten, Methoden, relevante Ergebnisstände, Bearbeitungsinformationen und die Zuordnung zum Auftrag gehören. Legen Sie fest, wo diese Informationen liegen und wie ein berechtigter Prüfer sie erhält.
Ein geeignetes Wiederherstellungsszenario beginnt mit einem definierten Laborfall, nicht nur mit einer erfolgreich kopierten Datei. Nach dem Restore sollen die benötigten Informationen lesbar, zugeordnet und fachlich verwendbar sein. Prüfen Sie dabei auch, welche Software- oder Diensterreichbarkeit erforderlich ist. Die konkrete Auswahl und Tiefe begründen Sie anhand des Risikos.
Bei einer Daten- oder Formatmigration beschreiben Sie, was am Ziel vollständig vorliegen muss und was kontrolliert im Altsystem verbleibt. Vermeiden Sie pauschale Lösch- oder Aufbewahrungsentscheidungen anhand des Dateialters. Maßgeblich sind der unterstützte Zweck und die dafür geltenden Fristen.
Updates nach ihren Auswirkungen bewerten
Ordnen Sie eine geplante Änderung zuerst einer Ebene zu: Geräteerfassung, Auswertungsalgorithmus, Methodenbestand, Datenformat, Speicherweg oder Benutzerverwaltung. Daraus ergeben sich unterschiedliche Nachweise. Ein Algorithmuswechsel verlangt andere Vergleichsfälle als eine reine Anpassung der zulässigen Benutzergruppe.
Bewerten Sie Release Notes, Kompatibilität und vorhandene Lieferantentests gegen Ihre Anforderungen. Geeignete Nachweise können übernommen werden. Ergänzen Sie diejenigen Prozessübergänge, die sie nicht ausreichend abdecken. Eine dokumentierte Begründung ist hilfreicher als die automatische Wiederholung aller bisherigen Tests oder ein unbegründeter Verzicht darauf.
Für den Betrieb regeln Sie außerdem den Umgang mit unerwarteten Ergebnissen und technischen Vorfällen. Sichern Sie die benötigten Ausgangsinformationen, bewerten Sie betroffene Entscheidungen und bestimmen Sie zulässige Folgeschritte. Ein erneuter Lauf oder eine erneute Auswertung sollte einen nachvollziehbaren Anlass besitzen, statt lediglich einen gewünschten Wert zu erzeugen.
Was Labor, QA und IT vorbereiten sollten
Für ein kleines Unternehmen spart eine gemeinsame Bestandsaufnahme unnötige Schleifen. Das Labor stellt typische Methoden, Datensätze und Entscheidungsregeln bereit. IT beschreibt Komponenten, Konten und Datenwege. QA und die verantwortlichen Prozesseigner legen den geregelten Zweck, die notwendigen Nachweise und den Umgang mit offenen Befunden fest.
Aufwandstreiber sind unterschiedliche Gerätefamilien, mehrere Auswertungsstände, unklare historische Datenbezüge und Änderungen zentraler Dienste. Auch verfügbare Testdaten und die Passung vorhandener Lieferantenbelege beeinflussen den Umfang. Daraus lässt sich erst nach der Abgrenzung eine belastbare Planung ableiten; der Produktname liefert keine seriöse Pauschaldauer.
- Sind alle Komponenten mit Build, Gerät und gültiger Kompatibilitätsgrundlage erfasst?
- Sind Anzeige, Reprocessing und manuelle Bearbeitung getrennt beschrieben?
- Sind Ausgangsdaten, Methodenstände und erwartete Ergebnisse vor den Tests festgelegt?
- Sind kritische Zuordnungs-, Berechtigungs- und Fehlerfälle enthalten?
- Ist der benötigte Kontext bei Export und Wiederherstellung prüfbar?
- Sind fachliche Befundbewertung, Betriebsverantwortung und Änderungen geregelt?
Häufige Fragen zu Agilent MassHunter
Kann Agilent MassHunter als ein einziges System validiert werden?
Sie können einen gemeinsamen Validierungsumfang festlegen, müssen darin aber die tatsächlichen Komponenten und Übergänge beschreiben. LC/TQ-Erfassung, qualitative und quantitative Auswertung sowie Datenhaltung besitzen unterschiedliche Aufgaben und Versionen. Ein zusammenhängender Nachweis ist sinnvoll, wenn die Grenzen sichtbar bleiben. Eine einzige Versionsangabe oder ein allgemeines Herstellerzertifikat ersetzt diese Beschreibung nicht.
Ist Qualitative Analysis 14.0 mit jeder Acquisition-Version kompatibel?
Nein, eine solche allgemeine Kompatibilität ist nicht belegt. Die Release Notes nennen konkrete Abhängigkeiten. Die separat betrachtete LC/TQ-12.3-Dokumentation beschreibt einen älteren Zusammenhang mit Qualitative 13.0. Stellen Sie für die geplante Kombination die passenden Herstellerstände zusammen. Ungeklärte Kombinationen müssen vor der Nutzung geklärt werden, auch wenn sich beide Programme installieren lassen.
Benötigt MassHunter immer OpenLab CDS oder ECM?
Nein. Die dokumentierten Betriebsformen unterscheiden lokale Workstations, Networked Workstations und einen spezifischen OpenLab-CDS-Client/Server-Kontext. Welche zentralen Dienste benötigt werden, hängt von der Komponente und ihrer Konfiguration ab. Erfassen Sie den tatsächlichen Daten- und Anmeldeweg. Eine Installation mit dem Familiennamen MassHunter belegt noch keine zentrale Archivierung oder eine bestimmte Signaturfunktion.
Warum kann ein Altresultat nach dem Update anders ausfallen?
Zunächst klären Sie, ob das alte Ergebnis nur angezeigt oder erneut berechnet wurde. Qualitative 14.0 beschreibt mögliche Algorithmuseffekte bei erneuter Verarbeitung. Vergleichen Sie identische Ausgangsdaten und nachvollziehbare Methodenstände. Ein Unterschied benötigt eine fachliche Bewertung; er ist weder automatisch ein Softwarefehler noch automatisch akzeptabel. Die vorgesehene analytische Entscheidung bestimmt die Konsequenz.
Darf eine manuelle Integration als normaler Prüffall vorgesehen werden?
Ja, wenn sie zu Ihrem tatsächlich erlaubten Auswertungsprozess gehört. Beschreiben Sie Anlass, befugte Rolle, konkrete Aktion und erforderlichen Nachweis. Die Bedienung und Historie müssen für die eingesetzte Auswertungskomponente belegt werden. Dieser Leitfaden setzt keine identische Integrationsfunktion in allen MassHunter-Programmen voraus. Bewerten Sie ursprüngliches Ergebnis und neue Bearbeitung im vorgesehenen Reviewzusammenhang.
Beweist ein .d-Export die vollständige Übernahme eines .sirslt-Datensatzes?
Nein. Die dokumentierte Exportmöglichkeit sagt zunächst, dass dieser Formatweg existiert. Sie belegt nicht automatisch identische Audit-Informationen, Metadaten oder Signaturbezüge. Bestimmen Sie vorab den benötigten Informationsumfang und vergleichen Sie Quelle und Ziel. Falls relevante Informationen kontrolliert im Ursprung verbleiben, müssen Zugriff und Zuordnung für den vorgesehenen Zweck weiterhin funktionieren.
Reicht ein PDF-Bericht zur späteren Bewertung des Ergebnisses?
Das hängt vom benötigten Nachweis ab. Ein Bericht kann die Entscheidung unterstützen, ohne sämtliche Eingangsdaten und Verarbeitungsschritte zu enthalten. Definieren Sie, welche Informationen für Ihren Laborfall erforderlich sind und wo sie verfügbar bleiben. Prüfen Sie anhand eines repräsentativen Ergebnisses, ob Herkunft, Methode und relevante Änderungen nachvollziehbar sind. Eine universelle Gleichsetzung von Bericht und vollständigem Datensatz ist ungeeignet.
Sind alle verfügbaren Audit Trails bei jedem Messlauf vollständig zu prüfen?
Ein pauschaler Vollumfang ist keine sinnvolle Vorgabe. Bestimmen Sie anhand des Prozesses und Risikos, welche Änderungen für die Ergebnisbewertung relevant sind und wann sie überprüft werden. Dazu müssen die tatsächlich vorhandenen Informationsquellen bekannt sein. Die historischen LC/TQ-Angaben zu Methoden und Worklists ersetzen keinen aktuellen Ereigniskatalog Ihrer Installation oder ein begründetes Reviewverfahren.
Muss nach jeder MassHunter-Aktualisierung alles erneut getestet werden?
Nicht automatisch. Bewerten Sie die betroffenen Komponenten, Funktionen, Daten und vorhandenen Nachweise. Bei Algorithmusänderungen können Vergleichsauswertungen wesentlich sein; bei geänderten Zugriffsrechten stehen andere Prüfungen im Vordergrund. Dokumentieren Sie die Auswahl und offene Risiken. Geeignete Lieferantentests sind nutzbar, wenn ihre tatsächliche Abdeckung zum vorgesehenen System und Ihren Anforderungen passt.
Welche Unterlagen helfen bei der ersten Aufwandsschätzung?
Benötigt werden Komponenten- und Geräteliste, Versionen, Datenwege, Rollen, repräsentative Methoden und Datensätze sowie vorhandene Validierungs- und Lieferantenbelege. Ergänzen Sie geplante Änderungen und bekannte Vorfälle. Damit werden offene Übergänge sichtbar und Prüfaufgaben zuordenbar. Ohne diese Grundlage wären feste Aussagen zu Projektzeit oder Testanzahl lediglich Annahmen, keine belastbare Planung.
Quellen & fachlicher Stand
Stand 6. Oktober 2026. Produktbezüge: MassHunter Qualitative Analysis 14.0, Mai 2026, und LC/TQ Acquisition 12.3, Mai 2025, mit ausdrücklich historischen Teilabschnitten. Diese Stände bilden keine pauschal freigegebene Kombination. Quantitative Integrationsdetails sind versionsbezogen zu klären. Tabellen und Zahlen sind eigene illustrative Arbeitshilfen; keine Installation wurde dafür getestet.
- Agilent MassHunter Acquisition für LC/MS
- MassHunter Qualitative Analysis 14.0 – Release Notes
- MassHunter Acquisition for LC/TQ 12.3 – Release Notes
- Europäische Kommission: EudraLex Volume 4
- EU-GMP Annex 11: Computerised Systems
- EU-GMP Kapitel 4: Dokumentation
- FDA: Part 11 — Scope and Application
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Den Nachweis an Ihrem LC/MS-Prozess ausrichten
Wir unterstützen Sie dabei, Komponenten und Datenwege abzugrenzen, vorhandene Belege zu bewerten und aussagekräftige Prüfungen für Ihren Laborprozess vorzubereiten.
- IT-GxP-Audit →
Vorhandene Nachweise und offene Übergänge Ihres Laborsystems einordnen.
- IT-GxP-Consulting →
Anforderungen, Vergleichsfälle und betriebliche Verantwortung gemeinsam ausarbeiten.