Unsere Leistungen bei der GAMP 5 Kategorie 5 Validierung
Vom Validierungsplan bis zur Behördeninspektion: strukturiert entlang GAMP 5 und Ihrem SDLC – mit belastbaren Nachweisen für QA und Audit.
Umfang klären?
Erstgespräch vereinbarenKategorie-5-Wegweiser
Wo steht Ihre Individualsoftware?
Wählen Sie die Ausgangslage für GAMP-5-Kategorie-5-Software mit vollem SDLC-Nachweis.
Individualsoftware von Anfang an validieren
Spezifikation, Code, Tests und Freigabe wachsen in einem SDLC – ideal mit unserer Softwareentwicklung.
Retrospektive Validierung
Wir erfassen Ist-Zustand, schließen Lücken und führen die Anwendung in den validierten Betrieb.
Änderung unter Change Control
Impact-Analyse, Re-Test und Freigabe für Releases ohne den validierten Zustand zu verlieren.
Unser Vorgehen in GxP-Projekten: von Planung bis Freigabe – jeder Schritt endet mit einem Ergebnis, das Sie in QA-Review und Audit vorlegen können. GxP-Beratung in fünf Schritten ansehen
GAMP 5: Was bedeutet Kategorie 5?
Das Good Automated Manufacturing Practice (GAMP 5)-Rahmenwerk der ISPE klassifiziert Software in vier Kategorien nach ihrem Risikoniveau und Validierungsaufwand. Kategorie 5 umfasst individuell entwickelte Software: maßgeschneiderte oder stark angepasste Systeme, die speziell für die jeweilige GxP-Umgebung erstellt werden.
Typische Beispiele für GAMP 5 Kategorie 5 sind: intern entwickelte LIMS, maßgeschneiderte Reporting- und Auswertungstools, GxP-Datenmigrationssoftware, individuelle Laborautomatisierungs-Applikationen sowie Datenkonverter für regulierte Systeme.
| Kategorie | Beschreibung | Beispiele | Validierungsaufwand |
|---|---|---|---|
| Kat. 1 | Infrastruktur-Software | Betriebssysteme, Middleware, Datenbanken | Minimal |
| Kat. 3 | Nicht-konfigurierbare COTS | Standard-Office-Software | Gering |
| Kat. 4 | Konfigurierbare COTS | ERP, LIMS (Standard), EDMS | Mittel |
| Kat. 5 | Individuell entwickelt / maßgeschneidert | Eigenentwicklungen, stark angepasste Systeme, Datenmigrations-Tools | Umfassend: voller SDLC |
Wichtig: GAMP 5 (2. Auflage, 2022) betont ausdrücklich den risikobasierten Ansatz. Nicht jede Funktion einer Kategorie-5-Software muss mit gleichem Aufwand validiert werden: der Fokus liegt auf Funktionen mit direktem Einfluss auf Produktqualität oder Patientensicherheit.
Der Software-Lebenszyklus nach V-Modell
Für GAMP 5 Kategorie 5 ist der Software Development Life Cycle (SDLC) nach V-Modell der regulatorisch anerkannte Standard. Jede Spezifikationsebene auf der linken Seite wird durch eine entsprechende Teststufe auf der rechten Seite verifiziert.
Dokumentenpaket bei GAMP 5 Kategorie 5
GAMP 5 Kategorie 5 verlangt einen vollständigen CSV-Rahmen über den Software-Lebenszyklus – nicht aber für jedes Artefakt denselben Detailgrad. Statt einer starren Pflichtliste gilt: vollständige Nachweiskette, risikobasierte Tiefe. GAMP 5 (2022) und der CSA-Ansatz der FDA betonen kritisches Denken – weniger Papier dort, wo das Risiko es erlaubt, volle Tiefe bei Patientensicherheit und Datenintegrität.
Das Paket gliedern wir in vier logische Gruppen: Der Kern bildet den auditfesten Rahmen, Spezifikation und Qualifikation folgen dem V-Modell, SDLC-Nachweise belegen die kontrollierte Entwicklung. Wie Sie Testplanungs- und Protokollaufwand gezielt reduzieren, ohne die Nachweistiefe zu verlieren, zeigen wir auf unserer Seite Validierungskosten senken mit CSA & KI.
Gruppe 1
Kern – Validierungsrahmen
Planung, Risiko, Rückverfolgbarkeit und Abschluss – ohne diesen Kern ist keine auditfähige Kategorie-5-Validierung möglich.
Gruppe 2
Spezifikation – V-Modell links
Die Spezifikationshierarchie beschreibt Intended Use, Verhalten und technische Umsetzung – Grundlage für Design, Entwicklung und Test.
Gruppe 3
Qualifikation – IQ / OQ / PQ
Testpläne und Testprotokolle auf Systemebene – Umfang und Detaillierungsgrad orientieren sich an der Risikoanalyse, nicht an pauschaler Vollabdeckung jeder Hilfsfunktion.
Gruppe 4
SDLC-Nachweise – kontrollierte Entwicklung
Was Kategorie 5 von Konfiguration unterscheidet: Nachweis, dass Quellcode unter Kontrolle entwickelt, geprüft und getestet wurde – ergänzend zu IQ/OQ/PQ, nicht stattdessen.
Hinweis: Nicht jedes Dokument braucht denselben Umfang. GAMP 5 (2022) erwartet vollständige Nachweiskette und begründete Testtiefe – keine Checklisten-Gleichbehandlung aller Funktionen. OQ-Testprotokolle und Entwicklertests ergänzen sich; doppelte Abdeckung vermeiden wir bewusst.
Traceability Matrix: das Rückgrat der Validierung
Im Kern-Rahmen oben verknüpft die Traceability Matrix jede Anforderung aus der URS lückenlos mit Funktionsspezifikation, Design und Testprotokollen. Der Inhalt der Rückverfolgbarkeit ist praktisch unverzichtbar – die TM ist das übliche, auditfest etablierte Werkzeug dafür.
Bei cube one pflegen wir die Traceability Matrix als lebendes Dokument: sie wird bei jedem Change Control aktualisiert und bleibt damit dauerhaft valide.
Risikobasierte Testtiefe nach GAMP 5 (2. Auflage 2022)
Die 2022 aktualisierte GAMP 5 2nd Edition stärkt den risikobasierten Ansatz weiter: Die Intensität der Testdokumentation orientiert sich am kritischen Einfluss auf Produktqualität und Patientensicherheit. Nicht jede Funktion muss mit gleichem Aufwand getestet und dokumentiert werden.
-
Geringes Risiko
Hilfsfunktionen und UI-Elemente ohne GxP-Relevanz: vereinfachte Tests, reduzierte Dokumentation – begründet durch kritisches Denken.
Testtiefe · reduziert -
Mittleres Risiko
Konfiguration, Reporting, Benutzerverwaltung: angemessene Tests und Dokumentation proportional zum Risiko.
Testtiefe · mittel -
Hohes Risiko
Funktionen mit direktem GxP-Einfluss (Audit Trail, ERES, Chargenfreigabe): vollständige Testdokumentation, dreifache Review.
Testtiefe · maximal
Grundprinzip GAMP 5 (2022)
Kritisches Denken
GAMP 5 fordert strukturiertes kritisches Denken statt blindem Befolgen von Checklisten – die Basis für jede Risikostufe oben.
Testplanung und Testprotokolle: Minimum sichern, Aufwand reduzieren
Bei GAMP 5 Kategorie 5 lautet eine häufige Frage: Wie formal müssen Testpläne sein und wie detailliert die Testprotokolle? Gemeint ist die Qualifikationsdokumentation in IQ, OQ und PQ – der Testplan legt fest, was geprüft wird; das Testprotokoll dokumentiert die Ausführung und das Ergebnis. Nicht der Anwendungsquellcode selbst, der über SDLC, Code-Review und Entwicklertests abgesichert wird. Der Schlüssel ist risikobasiertes kritisches Denken: gleiche Auditfestigkeit, weniger Papier dort, wo das Risiko es erlaubt.
Auditfestes Minimum
Das können Sie nicht weglassen
- Risikobegründung im VP/VMP: formaler Testplan vs. fokussierte Prüfung mit Protokoll – dokumentiert und freigegeben
- Rückverfolgung zur Anforderung (URS/FS), auch bei kurzen Testfällen
- Prüflogik im Testplan: Eingabe, erwartetes Ergebnis, eindeutiges Pass/Fail-Kriterium
- Freigegebene Version von Testplan und Protokollvorlage (Versionskontrolle / Change Control)
- Testprotokoll mit Ist-Ergebnis, Tester, Datum und Testumgebung
- Abweichungsweg bei Fail (Deviation, Impact, ggf. CAPA) – vor der Ausführung definiert
Praxis ohne Overhead
So reduzieren Sie den Aufwand
- Nur GxP-kritische Funktionen mit vollem Testplan und detailliertem Protokoll; Hilfs-UI mit schlankem Plan und Ausführungsprotokoll
- CSA / kritisches Denken: kürzere Testpläne, wenn Risiko niedrig und Nachweis anderweitig vorliegt
- Wiederverwendbare Testbibliotheken und parametrisierte Daten statt hunderte Einzeltestpläne
- Automatisierung mit freigegebenem Baseline-Lauf – manuelle Wiederholung entfällt
- Entwicklernachweise (Unit/Integration) sinnvoll nutzen, nicht in OQ duplizieren
- Vorlagen & Testdesign-Standards – einheitliche Struktur, schnellere Reviews
- Impact-basiertes Re-Testing nach Changes statt pauschaler Komplett-Regression
Testtiefe skaliert mit dem Risiko – nicht pauschal „alles maximal dokumentieren“