IT-GxP-Compliance im Prüflabor: Validierung eines Labor-Informations- und Management-Systems

4. November 2024

Ein Artikel von Miro Oswald, DHC AG, erschienen in der GIT Labor-Fachzeitschrift 7/2024, S. 19–21

Overview

Der grundsätzliche Ablauf im Prüflabor besteht aus einem Zyklus der Prüfloserzeugung, Prüfauftragserzeugung, Probenvorbereitung, Probenanalyse, Prüfauftragsabschluss und Prüflosabschluss, der durch eine kontinuierliche Klimaüberwachung und Archivierung begleitet wird und in dem das Labor-Informations- und Management-System (LIMS) die zentrale Rolle spielt (Abb. 1). Dabei sind die Ebenen der IT-Infrastrukturqualifizierung, Laborgerätequalifizierung, Computersystemvalidierung und Methodenvalidierung klar zu trennen, bauen aber in bestimmter Art und Weise aufeinander auf. Die Validierung eines LIMS basiert aufgrund der benötigten Konfiguration und kundenspezifischen Erweiterung der Standardsoftware gemäß V-Modell auf einem Ansatz, der Folgendes umfasst: Anforderungsspezifikation, Funktionsspezifikation, Konfigurationsspezifikation, Modulspezifikation, Modultest, Konfigurationstest, Funktionstest sowie Anforderungstest.

Systemlandschaft im Prüflabor

Das LIMS ist mit dem Enterprise Resource Planning System (ERP) verbunden und tauscht mit diesem Prüflosinformationen aus. Mit dem Laboratory Execution System (LES) und den Laborgeräten (DEV) tauscht es Probeninformationen im Zuge der Probenvorbereitung aus. Für die Probenanalyse kommuniziert es mit den Chromatography Data Systems (CDS) und den Laborgeräten (DEV). Das Monitoring System (MON) sowie das Scientific Data Management System (SDMS) sind oft nicht mit dem LIMS verbunden.

Qualifizierungs- / Validierungsebenen

Im regulierten Umfeld der Life Science Industrie müssen aufgrund gesetzlicher Vorgaben IT-Infrastruktur [1, 2] und Laborgeräte [3, 4] qualifiziert sowie computergestützte Systeme [5, 6] und analytische Methoden [7, 8] validiert werden, deren Nichteignung für den vorgesehenen Verwendungszweck die Qualität oder sogar die Wirksamkeit und Sicherheit des Produktes negativ beeinflussen kann. Die verschiedenen Qualifizierungs- und Validierungsebenen sind zumindest logisch sauber zu trennen und bauen in bestimmter Weise aufeinander auf, wie in Abbildung 2 dargestellt. Auf der Ebene der Computersystemvalidierung wird zum Beispiel das LIMS inklusive LES auf Basis einer qualifizierten IT-Infrastruktur validiert und mit qualifizierten beziehungsweise überprüften Laborgeräten, CDS und ERP verbunden.

Validierung eines LIMS

Planung

In Abbildung 3 ist der auf dem V-Modell und GAMP 5 [9] basierende Ansatz für die Initialvalidierung eines LIMS dargelegt. Die Planung beginnt mit der Initialen Risikobeurteilung (IRA). Diese dient basierend auf dem Verwendungszweck der Beurteilung der Qualitätsrelevanz des LIMS, des Qualitätsrisikos, der Komplexität, der Anwendbarkeit von elektronischen Aufzeichnungen und Signaturen [10] sowie der Bereitstellung. Danach folgt der Validierungsplan (VP). In ihm werden auf Basis der IRA und der Lieferantenqualifizierung der Umfang, die Vorgehensweise inklusive Aktivitäten, Lieferobjekte, Rollen, Verantwortlichkeiten und Team sowie formale Aspekte der Validierung dargelegt.

Spezifikation

Die Spezifikation startet mit der Anforderungsspezifikation (RS). Diese dient der Beschreibung der technisch-funktionalen (was soll das LIMS tun), der technisch-nicht-funktionalen (wie soll das LIMS sein) und der organisatorischen Anforderungen. Es folgt die Funktionsspezifikation (FS). In ihr wird die durch funktionale Konfiguration und kundenspezifische Erweiterung neu erstellte Funktionalität konkretisiert. Die Standardfunktionalität wird direkt in der Traceability Matrix referenziert. Die anschließende Konfigurationsspezifikation (CS) dient der Beschreibung der parametrisierenden Konfiguration (Einstellung von Funktionalität anders als per Installation) und der funktionalen Konfiguration (Neuerstellung von Funktionalität via Konfigurationsmechanismus), wobei die Abgrenzung gegenüber den Stammdaten wichtig ist. Die Spezifikation endet mit der Modulspezifikation (MS). In ihr wird die kundenspezifische Erweiterung (Neuerstellung von Funktionalität via Scriptingmechanismus) beschrieben.

Übergang

Der Übergang beinhaltet die Technische Risikobeurteilung (TRA). Diese dient der Beurteilung und Handhabung der Qualitätsrisiken der technischen Anforderungen mit Qualitätsrelevanz via zweidimensionale FMEA mit Eintrittswahrscheinlichkeit (gemäß Realisierungsart der Anforderung) und Schweregrad (gemäß Auswirkung auf Qualität, Wirksamkeit, Sicherheit des Produkts). Auch Teil des Übergangs ist die Traceability Matrix (TM). In ihr wird die Rückverfolgbarkeit über die verschiedenen Spezifikations-, Risiko- und Verifikationsebenen hinweg sichergestellt. Die Designprüfung (DR) wiederum dient der Rekapitulation der Spezifikation und Überprüfung der korrekten Adressierung aller technisch-funktionalen, technisch-nicht-funktionalen und organisatorischen Anforderungen gemäß deren Realisierungsart. Schließlich beinhaltet der Übergang auch die Codeprüfung (CR). Sie dient der Überprüfung des Quellcodes und der Einhaltung der Scriptingrichtlinie bei der kundenspezifischen Erweiterung.

Verifikation

Bei den verschiedenen Stufen der Verifikation gibt es jeweils einen Testplan (TP) inklusive Testfälle (TCs) sowie einen Testbericht (TR) inklusive Testläufe und zugehörige Abweichungen (TEs). Die Verifikation startet mit dem Modultest (MT). Dieser dient der Überprüfung der kundenspezifischen Erweiterung gemäß MS im Verbund mit funktionaler Konfiguration und Standardkomponenten in einer Art Prä-Funktionstest (White-Box-Test). Es folgt der Installationstest (ILT). In ihm werden sowohl die Standardsoftware als auch die Transporte für die kundenspezifische Erweiterung, funktionale und allenfalls parametrisierende Konfiguration sowie Stammdaten auf den Systemumgebungen installiert und die Installation verifiziert. Der anschließende Konfigurationstest (CT) dient sowohl dem Setzen der nicht-transportierbaren Konfiguration gemäß CS auf den Systemumgebungen und der Überprüfung des Setzens, als auch der einmaligen Überprüfung der transportierbaren Konfiguration gemäß CS. Es folgt der Funktionstest (FT). In ihm wird die durch funktionale Konfiguration und kundenspezifische Erweiterung neuerstellte Funktionalität gemäß FS verifiziert (Black-Box-Test). Die Verifikation endet mit dem Anforderungstest (RT). Dieser dient der dynamisch-integrativen und statischen Überprüfung der Erfüllung der Anforderungen gemäß RS (Black-Box-Test).

Einführung

Die Einführung beinhaltet die Bedienungsanleitung (MN) inklusive Schulung. Diese dient der Beschreibung der Instruktionen zur Bedienung des LIMS für die verschiedenen Rollen gemäß dem Validierungsrahmen. Auch Teil der Einführung ist die Anpassung beziehungsweise Erstellung der Standardarbeitsanweisungen für die gemäß IRA durch das LIMS zu unterstützenden Laborprozesse und der Prüfanweisungen der im LIMS durch Stammdaten repräsentierten Analysenmethoden (PRO) einschließlich der Schulung. Die für den Betrieb des LIMS notwendigen Prozesse werden ebenfalls sichergestellt.

Abschluss

Der Abschluss beginnt mit der Systembeschreibung (SD). Diese dient der Charakterisierung des LIMS und der Angabe der Rollen, Verantwortlichkeiten, Team für die Betriebsphase, der Liste aller Validierungslieferobjekte des Systems sowie der geltenden, allgemeinen und systemspezifischen Prozesse für den Betrieb des LIMS. Danach folgt schließlich der Validierungsbericht (VR). In ihm werden die Abweichungen gegenüber dem VP, noch offene Testabweichungen, die Liste aller Lieferobjekte der aktuellen Validierung, die Erfüllung der Akzeptanzkriterien gemäß VP und die Rechtfertigung des Go-Live dargelegt.

Ausblick

Die elektronische, dokumentenbasierte Validierung computergestützter Systeme hat die traditionelle, papierbasierte Variante mittlerweile weitegehend abgelöst. Sie ermöglicht eine bessere Zusammenarbeit, schnellere Fortschritte, einfachere Genehmigungsabläufe sowie eine optimalere Ablage der Dokumente. Dafür wird oft ein Document Management System (DMS) eingesetzt, das die Genehmigung, Ablage und weitere Arbeitsschritte integriert. Bei überschaubareren Systemen mit einer entsprechend simplen Traceability Matrix stellt diese Variante keine Probleme dar. Bei größeren Systemen, zu denen meistens auch das LIMS zu zählen ist, mit einer komplexen Traceability Matrix kann diese Variante aber nicht mehr sinnvoll praktiziert werden. Spätestens hier sollte der Einsatz eines itembasierten Validation Lifecycle Management System (VLMS) in Anbetracht gezogen werden. Dieses selbst muss zwar validiert werden, erleichtert die Validierung komplexer Systeme jedoch sehr.

---

 

Autor:

Miro Oswald ist als Berater auf dem Gebiet der IT-GxP-Compliance bei DHC, Schweiz, tätig. Zuvor arbeitete er über 15 Jahre mehrheitlich als Projektmanager in den Bereichen Laborautomatisierung und Computersystemvalidierung in der Life Science Industrie. Er ist diplomierter Naturwissenschaftler der ETH Zürich auf den Gebieten Biochemie, Molekularbiologie und Bioinformatik.

Literatur

[1] International Organization for Standardization (2016). ISO 13485:2016 Medical devices – Quality management systems – Requirements for regulatory purposes, Geneva, Switzerland, 6.3 & 7.5.1b.

[2] European Commission (2015). EudraLex – Volume 4 – Good Manufacturing Practice (GMP) guidelines, Brussels, Belgium, Annex 11 & Annex 15.

[3] International Organization for Standardization (2016). ISO 13485:2016 Medical devices – Quality management systems – Requirements for regulatory purposes, Geneva, Switzerland, 6.3 & 7.5.1b & 7.6.

[4] European Commission (2015). EudraLex – Volume 4 – Good Manufacturing Practice (GMP) guidelines, Brussels, Belgium, Part I 3.34 & Annex 15.

[5] International Organization for Standardization (2016). ISO 13485:2016 Medical devices – Quality management systems – Requirements for regulatory purposes, Geneva, Switzerland, 4.1.6 & 7.5.6 & 7.6.

[6] European Commission (2015). EudraLex – Volume 4 – Good Manufacturing Practice (GMP) guidelines, Brussels, Belgium, Annex 11.

[7] International Organization for Standardization (2016). ISO 13485:2016 Medical devices – Quality management systems – Requirements for regulatory purposes, Geneva, Switzerland, 7.6.

[8] European Commission (2015). EudraLex – Volume 4 – Good Manufacturing Practice (GMP) guidelines, Brussels, Belgium, Part I 6.15 & Annex 15 9.1.

[9] International Society for Pharmaceutical Engineering (2022). GAMP 5 – A Risk-Based Approach to Compliant GxP Computerized Systems – Second Edition, Tampa (Florida), USA.

[10] Office of the Federal Register (2024). Code of Federal Regulations – Title 21 – Food and Drugs, Washington (District of Columbia), USA, Part 11.