Validierung (MedTech / regulierte Branchen)

Unternehmen in regulierten Branchen (MedTech, Pharma, Automotive, Finanzdienstleistungen) müssen Softwareänderungen gemäß ihrer Qualitäts- und Sicherheitsnormen validieren, bevor sie produktiv gehen. ContextDecay bietet dafür ein integriertes Validierungs-Modul, das ISO 13485, IEC 62304 und GAMP 5konform dokumentiert werden kann.

Cloud vs. On-Premise: Bei On-Premise-Installationen entscheidet der Kunde selbst, wann welche Version eingespielt wird. In der Cloud wird der Rollout normalerweise zentral gesteuert - das Validierungs-Modul gibt regulierten Kunden dieselbe Kontrolle: eine neue Version wird erst wirksam, wenn der Kunde sie freigibt.

Wie funktioniert die Validierung?

Wenn eine neue Version freigegeben wird, kann Ihr Organisations-Administrator eine Validierungs-Umgebung erstellen. Dabei wird ein isolierter Daten-Klon Ihrer Organisation angelegt. Ihr QM-Team kann dort die neue Version gegen einen vollständigen Testkatalog (IQ, OQ, PQ) prüfen, ohne dass Produktionsdaten betroffen sind.

Jeder Testfall wird mit einem TOTP-signierten Eintrag abgeschlossen. Sobald alle Testfälle bestanden sind, kann der Administrator die Version mit einem Klick produktiv schalten. Ein unveränderlicher Validierungsbericht mit allen Signaturen und SHA-256-Hashes wird erzeugt.

Schritt für Schritt

1. Validierungs-Umgebung erstellen

Als Organisations-Administrator einloggen.
Im Hauptmenü Validierung öffnen.
Auf Validierung starten klicken.
Version-Tag (z. B. v2.5.0) und Release-Notes eingeben.
Mit Umgebung anlegen bestätigen.

Im Hintergrund wird ein separates PostgreSQL-Schema (val_xxxxxxxx) erstellt und mit einer Kopie Ihrer Daten befüllt (Entscheidungen, Benutzer, Audit-Log).

2. Testfälle durchlaufen

Der Testkatalog ist in drei Phasen unterteilt:

Phase	Inhalt	Beispiele
IQ (Installation Qualification)	Installationszustand, Version, Schema, Security-Header	TLS-Konfiguration, DB-Migration, Build-Metadaten
OQ (Operational Qualification)	Kernfunktionen arbeiten wie spezifiziert	Entscheidung anlegen, freigeben, archivieren; Export; 2FA-Login
PQ (Performance Qualification)	Anwendung erfüllt Performance- und Workflow-Anforderungen	End-to-End-Workflow, Antwortzeiten, DSGVO-Löschung

3. Tests signieren

Jeder Validator öffnet einen Testfall, führt die beschriebene Prozedur im Test-Workspace aus (der gegen den Daten-Klon arbeitet), dokumentiert das Ist-Ergebnis und signiert das Resultat mit seinem TOTP-Code. Die Signatur wird als SHA-256 über userId | testCaseId | totpCode | timestamp berechnet und in der Datenbank gespeichert.

Wichtig: Jeder Validator muss 2FA aktiviert haben. Die TOTP-Signatur ist das qualitative Äquivalent zur elektronischen Unterschrift nach 21 CFR Part 11.

4. Produktiv schalten

Wenn alle Testfälle den Status bestanden oder n/a haben, erscheint die Schaltfläche Produktiv schalten. Nach Bestätigung wird:

Die freigegebene Version in organizations.approved_version gespeichert.
Die Validierungs-Umgebung auf activated gesetzt.
Das geklonte Schema gelöscht (Tests-Daten werden verworfen).
Der Validierungsbericht mit SHA-256-Hash eingefroren.

5. Bericht archivieren

Der Bericht kann als HTML geöffnet und im Browser als PDF gedruckt werden. Er enthält:

Kopfdaten (Organisation, Version, Zeitpunkte)
Zusammenfassung (Anzahl bestanden / fehlgeschlagen / n a / offen)
Alle Testfälle mit Soll- und Ist-Ergebnis, Signatur-Hash (erste 16 Zeichen)
Chronologischer Audit-Trail aller Validierungs-Aktionen
Unterschriftsfelder für Organisations-Administrator und QMB
SHA-256-Hash des gesamten Bericht-Inhalts (Manipulationsschutz)

Isolation des Daten-Klons

Der Daten-Klon liegt technisch in einem separaten PostgreSQL-Schema in derselben Datenbank. Alle Lese- und Schreibzugriffe im Test-Workspace werden transaktional per SET LOCAL search_path auf dieses Schema umgeleitet. Schema-Namen folgen dem Muster val_[a-f0-9]{8} und werden strikt per Regex validiert, bevor sie in dynamischem SQL verwendet werden (Schutz vor SQL-Injection).

Nach der Aktivierung (oder dem Verwerfen) wird das Schema per DROP SCHEMA CASCADEgelöscht. Die Validierungs-Metadaten (Testläufe, Audit-Einträge, Signaturen) bleiben für Audit-Zwecke erhalten.

Für Auditoren

Der Bericht enthält alles, was ein Auditor typischerweise in einem IEC 62304-Projekt erwartet:

Traceability: Testfall-ID (IQ-01, OQ-03, …) → Anforderung → Ist-Ergebnis
Evidence: Signatur-Hash pro Testfall, Zeitstempel, Benutzer
Change Control: Version und Release-Notes werden beim Anlegen erfasst
Release-Freigabe: Unterschriftsfelder auf dem Bericht (Admin + QMB)
Integritätsschutz: SHA-256 über den Bericht-Inhalt, prüfbar nach Archivierung

Grenzen

Die Validierung bildet folgende Szenarien nicht automatisch ab:

Schema-Migrationen mit Breaking Changes: Der Daten-Klon verwendet das aktuelle Schema. Bei Major-Releases mit DB-Migrationen empfehlen wir, vor der Validierung eine Staging-Kopie zu ziehen (kontaktieren Sie uns für Unterstützung).
Externe Integrationen: Tests gegen SharePoint, Slack, Teams etc. sollten gegen Test-Endpunkte konfiguriert werden, um Produktionsnachrichten zu vermeiden.

API-Referenz

Endpunkt	Beschreibung
`GET /api/validation/environments`	Liste der Umgebungen
`POST /api/validation/environments`	Neue Umgebung anlegen
`GET /api/validation/environments/:id`	Details inkl. Tests & Audit
`DELETE /api/validation/environments/:id`	Umgebung verwerfen
`POST /api/validation/environments/:id/tests`	Testergebnis signieren
`POST /api/validation/environments/:id/activate`	Version produktiv schalten
`GET /api/validation/environments/:id/report`	Validierungsbericht (HTML)
`GET /api/validation/environments/:id/workspace/decisions`	Test-Workspace: Entscheidungen

FAQ

Muss ich jede neue Version validieren?

Nein. Die Validierungs-Pflicht richtet sich nach Ihrem internen SOP und der Klassifizierung der Version (Patch, Minor, Major). Patches ohne funktionale Änderungen werden häufig per Change-Control-Dokumentation ohne vollständige Re-Validierung freigegeben.

Wie viele Benutzer können gleichzeitig validieren?

Beliebig viele - jeder Benutzer mit Login Ihrer Organisation kann Testfälle durchlaufen. Nur der Organisations-Administrator kann die Umgebung anlegen, verwerfen oder aktivieren.

Wo wird der Bericht gespeichert?

Die Metadaten liegen in Ihrer Datenbank. Das HTML wird bei Bedarf on-the-fly generiert und kann lokal archiviert werden. Der SHA-256 des aktivierten Berichts ist persistiert und ermöglicht spätere Manipulations-Prüfungen.