Von der Theorie zur Praxis: Durchführung einer CSA-Validierung in 4 Schritten

Der Übergang zu Computer Software Assurance (CSA) kann einschüchternd wirken, wenn man keinen klaren Fahrplan hat. Wie entscheidet man, was getestet wird? Wie rechtfertigt man vor dem Inspektor, dass wir nicht für alles ein detailliertes Protokoll geschrieben haben? Hier ist eine operative Roadmap basierend auf CSA-Best-Practices, um Ihren Validierungsprozess zu transformieren.

Schritt 1: Identifizierung des Verwendungszwecks (Intended Use) und Risikobewertung

Alles beginnt mit dem Intended Use. Was macht die Software? Welche Prozesse unterstützt sie? Sobald die Funktionen kartiert sind, wenden Sie den Risikofilter an:

• High Risk (Kritisch): Die Funktion hat einen direkten Einfluss auf die Patientensicherheit oder die Produktqualität (z. B. Dosierungsberechnung, Chargenfreigabe).
• Non-High Risk (Niedrig/Mittel): Die Funktion hat nur Auswirkungen auf das Geschäft oder indirekte Auswirkungen, die durch andere Kontrollen gemindert werden (z. B. Trainingsmanagement, statistisches Reporting).

Schritt 2: Festlegung der Teststrategie (Scripted vs. Unscripted)

Dies ist die große Neuerung. Die Strenge des Tests muss dem Risiko entsprechen.

• Für High-Risk-Funktionen: Verwenden Sie Scripted Testing. Hier wird das klassische Schritt-für-Schritt-Protokoll mit präzisen erwarteten Ergebnissen und Beweis-Screenshots benötigt. An kritischen Punkten geht man kein Risiko ein.
• Für Non-High-Risk-Funktionen: Verwenden Sie Unscripted Testing.
• Exploratory Testing: Ein erfahrener Benutzer erkundet das System mit einem Ziel (Charter), aber ohne festgelegte Schritte, sucht nach Fehlern (Bugs) und überprüft die Benutzerfreundlichkeit.
• Ad-Hoc / Scenario Testing: Simulation eines realen Arbeitsablaufs (z. B. „einen Auftrag eingeben und abschließen“), ohne jeden einzelnen Klick aufzuschreiben.

Schritt 3: Durchführung und „schlanke“ Beweissicherung

Vergessen Sie 500-Seiten-Berichte für ein einfaches System. Bei Unscripted Tests ist der Beweis ein Test Log, das zusammenfasst: „Wer hat getestet, was wurde getestet, was wurde gefunden“. Wenn alles funktioniert, reicht eine Zeile der Bestätigung. Wenn es einen Fehler gibt, wird der Bug detailliert dokumentiert. Tipp: Nutzen Sie digitale Tools oder Videoaufzeichnungen für explorative Sitzungen, falls das System dies zulässt, um eine vollständige Rückverfolgbarkeit ganz ohne Papier zu erreichen.

Schritt 4: Lieferantenmanagement (SaaS und Cloud)

In der Cloud-Welt können Sie die Infrastruktur von Amazon oder Google nicht validieren. CSA rät zum Vendor Leveraging.

• Bewerten Sie den Lieferanten (Audit/Zertifizierungen ISO 27001).
• Akzeptieren Sie dessen Basistests.
• Testen Sie intern nur Ihre Konfigurationen und kritischen Prozesse. Duplizieren Sie nicht die Arbeit, die der Anbieter bereits geleistet hat!

⚠️ Achtung vor... Dem Fehler „Keine Dokumente“

CSA bedeutet nicht „keine Dokumente“. Es bedeutet „Dokumente, die einen Wert haben“. Häufiger Fehler: Exploratives Testen ohne Spuren zu hinterlassen. Lösung: Jede explorative Sitzung muss eine „Charter“ (Ziel) und ein signiertes Abschluss-Log haben. Ohne Beweis existiert der Test für den Auditor nicht.

Synthetische operative CSA-Checkliste

• [ ] Genehmigtes Risk Assessment, das klar zwischen High und Non-High Risk unterscheidet.
• [ ] Testplan, der eine Mischung aus Scripted und Unscripted vorsieht.
• [ ] Lieferantenbewertung (Vendor Assessment) für SaaS-Systeme.
• [ ] Korrekt ausgefüllte Logs für explorative Tests.
• [ ] Fehlerprotokoll (Discrepancy Log), das zeigt, wie Probleme gelöst wurden.

Vertiefen Sie das Thema mit dem vollständigen Leitfaden auf GuideGxP.com, um Vorlagen für Risk Assessments und Test Logs herunterzuladen.