Computer System Validation (CSV) ist der nachweisbare Beleg, dass ein computergestütztes System für seinen beabsichtigten Zweck geeignet ist und konsistent so funktioniert, wie es soll. CSV ist primär dort relevant, wo Systeme Produktqualität, Patientensicherheit oder Datenintegrität beeinflussen – das sogenannte GxP-Umfeld.
CSV ist kein Testprojekt am Ende der Implementierung, sondern ein Lifecycle-Ansatz: Anforderungen, Risikobewertung, Spezifikation, Test und kontrollierter Betrieb gehören zusammen.
Abzugrenzen ist CSV von GAMP 5: GAMP 5 ist eine Best-Practice-Leitlinie für das Vorgehen. CSV ist das, was am Ende nachweisbar erfüllt sein muss.
Wann ist CSV erforderlich?
CSV wird typischerweise dann benötigt, wenn ein System GxP-relevante Prozesse steuert oder unterstützt – etwa Herstellung, Qualitätskontrolle, Freigaben oder Abweichungsmanagement. Wenn es entscheidungsrelevante Daten erzeugt oder verändert wie Batch-Dokumentation, Prüfergebnisse oder elektronische Freigaben. Und wenn Data Integrity abgesichert werden muss: Audit Trail, Rollen und Rechte, Nachvollziehbarkeit.
Das Dokumentationsset: Was CSV praktisch bedeutet
Das Ziel ist nicht viel Papier, sondern prüffähige Nachweise. Das Kern-Set umfasst einen Validation Plan mit Scope, Rollen, Vorgehen und Akzeptanzkriterien, eine User Requirements Specification (URS) die testbar formuliert ist, ein Risk Assessment das kritische von unkritischen Funktionen trennt, Functional und Design Specifications für die Umsetzung, eine Traceability Matrix die URS, Risiken, Tests und Ergebnisse verbindet, vollständige Testnachweise sowie SOPs für Betrieb, Change Control und Periodic Review.
Risikobasierter Ansatz: Wie viel Test ist nötig?
CSV wird heute praktisch immer risikobasiert aufgesetzt. Entscheidend sind vier Faktoren: GxP-Kritikalität – beeinflusst das Feature Qualität oder Compliance? Komplexität – Standardfunktion, Custom Code oder Integrationslogik? Datenintegrität – können Daten manipuliert, vertauscht oder verzögert werden? Detektierbarkeit – würde ein Fehler schnell auffallen oder unentdeckt bleiben?
Kritische Pfade werden tief getestet: Freigaben, Audit Trail, Berechtigungen, Batch-Dokumentation. Unkritische Komfortfunktionen werden schlank behandelt. Das reduziert Aufwand ohne Compliance-Risiko.
MES-Einführung validierbar aufsetzen
CSV ab Tag 1 integrieren. Wenn Validation erst kurz vor Go-Live beginnt, entstehen Panik-Tests und Lücken. CSV-Artefakte müssen parallel zu Prozessdesign und Systemkonfiguration entstehen.
Scope klar ziehen. Typisch kritische MES-Bereiche sind elektronische Chargen- und Auftragsdokumentation, Qualitätsprüfungen, Sperr- und Freigabeentscheidungen, Abweichungen und Overrides mit Begründung und Eskalation, Rollen, Rechte und Audit Trail sowie Schnittstellen die Daten automatisch übertragen.
Konfiguration vor Customizing bevorzugen. Je weniger Custom Code, desto geringer der Validierungsaufwand. Wo Customizing nötig ist, muss es klar begründet, sauber spezifiziert und gezielt getestet werden – inklusive Regressionstests.
Integrationen als eigenes Validierungsthema behandeln. Viele CSV-Probleme entstehen an Schnittstellen: Datenmapping, Einheiten, Zeitstempel, Fehlerfälle wie Retry und Dubletten sowie die Frage welches System Source of Truth ist.
IQ, OQ, PQ sinnvoll einsetzen. IQ prüft ob die Umgebung korrekt installiert ist. OQ prüft ob Funktionen wie spezifiziert laufen – inklusive Rechte, Audit Trail und Alarme. PQ prüft reale Prozessszenarien mit echten Rollen und Daten end-to-end. Entscheidend ist nicht das Label, sondern dass kritische Anforderungen abgedeckt und bestanden sind.
Typische Fehler bei MES-Projekten
URS als Marketing-Text statt testbarer Anforderungen – wer nicht testbar spezifiziert, kann nicht validieren. Kritikalität nicht bewertet – dann wird alles gleich stark getestet, was teuer und langsam ist. Integrationen unterschätzt – Mapping und Fehlerfälle sind der häufigste CSV-Schwachpunkt. Rollen, Rechte und Audit Trail erst am Ende geklärt. Und kein Change Control nach Go-Live – was unkontrolliert geändert wird, invalidiert die Validation.
FAQ
Was ist der Unterschied zwischen CSV und GAMP 5? GAMP 5 (Good Automated Manufacturing Practice) ist eine Leitlinie der ISPE, die beschreibt wie CSV methodisch durchgeführt werden soll – mit Risikoklassen, Kategorien und Vorgehensempfehlungen. CSV ist das regulatorische Ziel: der nachweisbare Beleg der Systemeignung. GAMP 5 ist der Weg, CSV ist das Ergebnis.
Ist CSV auch für Cloud-MES erforderlich? Ja, wenn der beabsichtigte Einsatzbereich GxP-relevant ist. Bei Cloud-Systemen kommen zusätzliche Aspekte hinzu: Mandantentrennung, Hosting-Qualifikation des Anbieters, Kontrollierbarkeit von Updates und Change Management auf Anbieterseite. Der Anbieter muss entsprechende Nachweise liefern können.
Was ist eine Traceability Matrix (RTM)? Eine Requirements Traceability Matrix verknüpft jede Anforderung aus der URS mit dem zugehörigen Risiko, dem Testfall und dem Testergebnis. Sie ist der Nachweis dass alle kritischen Anforderungen tatsächlich getestet wurden – und damit das zentrale Prüfdokument bei Audits.
Wie aufwendig ist CSV für eine MES-Einführung realistisch? Das hängt stark von Scope und Risikoklassifizierung ab. Ein MES das ausschließlich nicht-validierte Prozesse unterstützt braucht keine CSV. Für GxP-relevante Bereiche wie elektronische Batch-Dokumentation oder Freigabeworkflows ist der Aufwand erheblich – aber durch konsequent risikobasiertes Vorgehen und Standardsoftware mit minimaler Customization deutlich reduzierbar.
