1. Was ist Computer System Validation?
Computer System Validation (CSV) - Definition
Computer System Validation (CSV) ist der dokumentierte Nachweis, dass ein computergestütztes System konsistent und reproduzierbar gemäß seiner Spezifikation und den regulatorischen Anforderungen arbeitet. CSV stellt sicher, dass Software in regulierten Umgebungen zuverlässig und nachvollziehbar funktioniert.
Warum CSV?
| Aspekt | Erklärung |
|---|---|
| Datenintegrität | Elektronische Daten müssen verlässlich und unverfälscht sein |
| Rückverfolgbarkeit | Wer hat wann was geändert? |
| Regulatorisch | FDA, EU GMP, ISO 13485 fordern validierte Systeme |
| Patientensicherheit | Fehlerhafte Software kann Patienten gefährden |
| Audit Trail | Jede Änderung muss nachvollziehbar sein |
Was ist ein "Computergestütztes System"?
Computergestütztes System - Definition
Ein computergestütztes System besteht aus Hardware, Software, Netzwerkkomponenten, Peripheriegeräten, Dokumentation, Personal und den zugehörigen Prozessen, die zusammen eine bestimmte Funktion erfüllen.
Beispiele:
| Kategorie | Beispiele |
|---|---|
| Labor | LIMS, HPLC-Software, Waagen-Software |
| Produktion | SCADA, MES, SPS-Steuerungen |
| Qualität | QMS-Software, CAPA-Systeme, Dokumentenmanagement |
| Logistik | ERP (SAP, etc.), Warehouse Management |
| Klinisch | EDC-Systeme, eCTD, eTMF |
2. Regulatorische Grundlagen
21 CFR Part 11 (FDA)
21 CFR Part 11 - Definition
21 CFR Part 11 ist die FDA-Verordnung, die Anforderungen an elektronische Aufzeichnungen und elektronische Unterschriften definiert. Sie legt fest, wann elektronische Dokumente als gleichwertig zu Papierdokumenten gelten.
Kernanforderungen:
| Anforderung | Beschreibung |
|---|---|
| Audit Trail | Automatische Aufzeichnung aller Änderungen |
| Elektronische Signaturen | Eindeutig, nicht übertragbar, mit Zeitstempel |
| Zugriffskontrolle | Benutzer-IDs, Passwörter, Berechtigungen |
| System Security | Schutz vor unbefugtem Zugriff |
| Datenintegrität | ALCOA+ Prinzipien |
ALCOA+ Prinzipien
| Buchstabe | Bedeutung | Erklärung |
|---|---|---|
| A | Attributable | Wer hat die Daten erzeugt? |
| L | Legible | Lesbar und dauerhaft |
| C | Contemporaneous | Zeitnah erfasst |
| O | Original | Originalaufzeichnung oder zertifizierte Kopie |
| A | Accurate | Fehlerfrei und korrekt |
| + | Complete | Vollständig |
| + | Consistent | Widerspruchsfrei |
| + | Enduring | Dauerhaft verfügbar |
| + | Available | Bei Bedarf zugänglich |
EU GMP Annex 11
| Kapitel | Anforderung |
|---|---|
| Risikomanagement | Risikobasierter Ansatz für Validierungsumfang |
| Personal | Schulung und Qualifikation |
| Lieferanten | Lieferantenbewertung für Software |
| Validierung | Dokumentierter Nachweis der Eignung |
| Daten | Integrität, Backup, Archivierung |
| Security | Zugriffskontrolle, Audit Trail |
| Änderungen | Change Control für alle Änderungen |
| Periodische Bewertung | Regelmäßige Überprüfung |
ISO 13485:2016
| Kapitel | Anforderung |
|---|---|
| 4.1.6 | Validierung von Software für QMS |
| 7.5.6 | Validierung von Produktionssoftware |
| 7.6 | Validierung von Software für Überwachung/Messung |
3. GAMP 5: Der Industriestandard
GAMP 5 - Definition
GAMP 5 (Good Automated Manufacturing Practice) ist ein Leitfaden der ISPE, der einen risikobasierten Ansatz für die Validierung computergestützter Systeme in regulierten Industrien beschreibt.
GAMP 5 Softwarekategorien
| Kategorie | Beschreibung | Beispiele | Validierungsaufwand |
|---|---|---|---|
| 1 | Infrastruktur-Software | Betriebssysteme, Datenbanken, Netzwerk | Gering (Konfiguration dokumentieren) |
| 3 | Nicht-konfigurierbare Software | Firmware, einfache Tools | Mittel (Funktionstest) |
| 4 | Konfigurierbare Software | ERP, LIMS, MES (Standard) | Mittel-Hoch (Konfiguration validieren) |
| 5 | Maßgeschneiderte Software | Eigenentwicklung, Custom Code | Hoch (Vollständiger SDLC) |
Info
Kategorie 2 (Firmware) wurde in GAMP 5 Second Edition in Kategorie 3 integriert. Die meisten aktuellen Referenzen sprechen von Kategorien 1, 3, 4 und 5.
Validierungsaufwand nach Kategorie
Validierungsaufwand
▲
│
Hoch │ ┌─────┐
│ │ Kat │
│ ┌─────┐ │ 5 │
│ │ Kat │ │ │
Mittel │ ┌─────┐ │ 4 │ │ │
│ ┌─────┐ │ Kat │ │ │ │ │
│ │ Kat │ │ 4 │ │ │ │ │
Gering │ ┌─────┐ │ 3 │ │(low)│ │(high)│ │
│ │ Kat │ │ │ │ │ │ │ │ │
│ │ 1 │ │ │ │ │ │ │ │ │
└────┴─────┴─┴─────┴─┴─────┴─┴─────┴─┴─────┴──►
Infra- Nicht- Konfig. Konfig. Custom
struktur konf. (simple) (complex)4. Der CSV-Lifecycle
V-Modell für CSV
Anforderungen Qualifizierung/Test
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ URS │◄────────────────────────►│ PQ │
│(User Req.) │ │(Performance)│
└─────────────┘ └─────────────┘
│ ▲
▼ │
┌─────────────┐ ┌─────────────┐
│ FS │◄────────────────────────►│ OQ │
│(Functional) │ │(Operational)│
└─────────────┘ └─────────────┘
│ ▲
▼ │
┌─────────────┐ ┌─────────────┐
│ DS/CS │◄────────────────────────►│ IQ │
│(Design/Conf)│ │(Installation)│
└─────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ Coding/ │
│ Config │
└─────────────┘CSV-Phasen
| Phase | Aktivitäten |
|---|---|
| Planung | Validierungsplan, Risikobewertung, Kategorisierung |
| Spezifikation | URS, FS, DS/CS |
| Konfiguration/Entwicklung | System einrichten, Code entwickeln |
| Test | IQ, OQ, PQ, UAT |
| Freigabe | Validierungsbericht, Go-Live-Freigabe |
| Betrieb | Change Control, periodische Reviews |
| Außerbetriebnahme | Datenmigration, Archivierung |
5. Validierungsdokumentation
Validierungsplan (VP)
Checkliste: Inhalte Validierungsplan
- ☐ Systembeschreibung
- ☐ Geltungsbereich
- ☐ GAMP-Kategorie
- ☐ Risikobewertung
- ☐ Validierungsstrategie
- ☐ Rollen und Verantwortlichkeiten
- ☐ Zu erstellende Dokumente
- ☐ Testansatz
- ☐ Akzeptanzkriterien
- ☐ Zeitplan
- ☐ Genehmigungen
User Requirements Specification (URS)
URS - Definition
Die User Requirements Specification (URS) beschreibt, was das System aus Anwendersicht leisten muss. Sie ist die Basis für alle weiteren Spezifikationen und Tests.
| Abschnitt | Inhalt |
|---|---|
| Zweck | Wofür wird das System verwendet? |
| Funktionale Anforderungen | Was muss das System tun? |
| Datenanforderungen | Welche Daten werden verarbeitet? |
| Schnittstellen | Mit welchen Systemen wird kommuniziert? |
| Regulatorische Anforderungen | 21 CFR Part 11, Annex 11, etc. |
| Leistungsanforderungen | Geschwindigkeit, Verfügbarkeit |
| Sicherheitsanforderungen | Zugriff, Audit Trail, Backup |
Praxis-Tipp
Schreiben Sie URS so, dass sie testbar ist! "Das System soll benutzerfreundlich sein" ist nicht testbar. "Der Benutzer kann einen Datensatz in maximal 3 Klicks anlegen" ist testbar.
6. Testen: IQ, OQ, PQ
Die Testphasen IQ, OQ und PQ sind zentral für die Validierung. Jede Phase prüft gegen verschiedene Spezifikationen und wird von unterschiedlichen Rollen durchgeführt.
| Test | Was wird geprüft? | Beispiele |
|---|---|---|
| IQ | Installation & Konfiguration | Server installiert, Software-Version korrekt, Backup funktioniert |
| OQ | Funktionen & Features | Berechnungen korrekt, Audit Trail protokolliert, Zugr iffsrechte funktionieren |
| PQ/UAT | Geschäftsprozesse End-to-End | Workflows mit echten Daten, Performance unter Last, Anwenderakzeptanz |
Wichtig
Testen Sie auch negative Szenarien! Was passiert bei falschen Eingaben? Bei Netzwerkausfall? Bei zu vielen gleichzeitigen Benutzern? Diese Tests sind oft wichtiger als die "Happy Path" Tests.
7. Audit Trail und elektronische Unterschriften
| Element | Beschreibung |
|---|---|
| Wer | Benutzer-ID (eindeutig) |
| Was | Welche Daten wurden geändert |
| Wann | Zeitstempel (mit Zeitzone) |
| Warum | Grund für Änderung (wenn erforderlich) |
| Alter Wert | Vorheriger Zustand |
| Neuer Wert | Aktueller Zustand |
Kritisch
Der Audit Trail muss unveränderlich sein! Wenn Benutzer den Audit Trail deaktivieren oder Einträge löschen können, ist das System nicht Part 11 compliant.
8. Change Control und Maintenance
┌─────────────────┐
│ Change Request │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Bewertung │
│ (Impact, Risiko)│
└────────┬────────┘
│
▼
┌─────────────────┐ Nein
│ Genehmigung? │─────────► Ablehnung
└────────┬────────┘
│ Ja
▼
┌─────────────────┐
│ Implementierung│
│ (Test, Doku) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Freigabe │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Validierungs- │
│ dokumente │
│ aktualisieren │
└─────────────────┘9. Typische Fehler vermeiden
Diese Fehler führen zu FDA Warning Letters:
- Kein Audit Trail: Änderungen nicht nachvollziehbar
- Shared Logins: Mehrere Benutzer verwenden denselben Account
- Keine Change Control: Updates ohne Bewertung eingespielt
- Excel nicht validiert: Spreadsheets mit GxP-Berechnungen nicht validiert
- Backup nie getestet: Wiederherstellung funktioniert nicht
- Veraltete Dokumentation: Validierungsdoku nicht aktuell
14. Zusammenfassung
✓ Regulatorisch: 21 CFR Part 11, EU GMP Annex 11, ISO 13485
✓ GAMP 5: Kategorien 1, 3, 4, 5 mit unterschiedlichem Aufwand
✓ Datenintegrität: ALCOA+ Prinzipien
✓ Audit Trail: Wer, Was, Wann, Warum – unveränderlich
✓ Risikobasiert: Aufwand nach GxP-Relevanz
✓ Dokumentation: URS → FS → CS/DS → IQ → OQ → PQ
✓ Change Control: Jede Änderung bewerten und dokumentieren
✓ Periodische Reviews: System bleibt validiert
CSV-Projekt geplant oder Audit steht bevor?
Ich unterstütze Sie bei der Validierung computergestützter Systeme - von der GAMP-Kategorisierung über URS und Testprotokolle bis zur 21 CFR Part 11 Compliance.
Kostenlose Erstberatung vereinbaren