Computer System Validation (CSV) in der Medizintechnik
Kompakt, praxisnah und auditfest
Digitale Systeme sind aus der Medizintechnik nicht mehr wegzudenken: Sie erfassen Prüfwerte, steuern Prozesse, dokumentieren Ergebnisse und liefern Entscheidungsgrundlagen. Gleichzeitig steigt mit der Digitalisierung das Risiko: Fehlerhafte Berechnungen, unkontrollierte Änderungen oder unzureichend abgesicherte Workflows können Produktqualität, Patientensicherheit und Datenintegrität direkt beeinflussen.
Genau hier setzt Computer System Validation (CSV) an. CSV ist der systematische Nachweis, dass ein computergestütztes System für den vorgesehenen Zweck geeignet ist und zuverlässig arbeitet. Richtig umgesetzt ist CSV kein Selbstzweck, sondern ein wirksames Werkzeug für stabile Prozesse, kontrollierte Systeme und Audit-Sicherheit.
- Hintergründe: Validierung vs. Verifikation
- Normative Grundlagen der Computer System Validation
- Welche Softwarearten gibt es – und was bedeutet das für Validierung?
- Welche Systeme müssen validiert werden – und welche nicht?
- Typen der Validierung
- CSV in der Praxis: So entsteht ein auditfester Nachweis
- Wartung & Stilllegung
Hintergründe: Validierung vs. Verifikation
Der Begriff Validierung stammt vom lateinischen validus („stark“, „wirksam“, „zuverlässig“). Im Qualitätsmanagement nach ISO 9000 bedeutet Validierung den objektiven Nachweis, dass Anforderungen für eine bestimmte beabsichtigte Nutzung erfüllt sind, . Kurz gesagt: „Haben wir das richtige System gebaut?“
Davon abzugrenzen ist die Verifikation. Diese prüft, ob spezifizierte Anforderungen korrekt umgesetzt wurden, also ob das System gemäß Spezifikation funktioniert. Kurz gesagt: „Haben wir das System richtig gebaut?“
Gerade in der Medizintechnik ist diese Unterscheidung entscheidend. Ein System kann technisch korrekt umgesetzt sein (verifiziert), aber dennoch nicht für den vorgesehenen Zweck geeignet sein (nicht validiert). Die Folgen können gravierend sein, da computergestützte Systeme häufig Entscheidungen unterstützen oder Qualitätsnachweise erzeugen.
Praxisbeispiele verdeutlichen den Unterschied:
- Eine Excel-Tabelle wird in der Fertigung zur Auswertung von Prüfergebnissen eingesetzt. Die Datei enthält ungesicherte Makros, zudem wird eine falsche Formel zur Berechnung der Standardabweichung verwendet. Obwohl die Tabelle technisch funktioniert, ist die statistische Auswertung teilweise fehlerhaft – das System ist verifiziert, aber nicht validiert.
- Ein ERP-System wird zur Planung und Dokumentation von Wareneingangsprüfungen genutzt. Eine Checkbox zur Bestätigung einer bestandenen Prüfung ist standardmäßig vorausgewählt. Dadurch kann eine Prüfung als „bestanden“ dokumentiert werden, ohne dass das tatsächliche Prüfergebnis berücksichtigt wird. Auch hier erfüllt das System die Spezifikation, unterstützt aber den vorgesehenen Prozess nicht korrekt.
Diese Beispiele zeigen: Validierung betrachtet immer den Nutzungskontext, nicht nur die technische Umsetzung. Ziel ist die nachweisbare Eignung für den vorgesehenen Zweck (Fitness for Intended Use) im regulierten Prozess
Weiterführend dazu folgender Artikel: Unterschied Verifizierung und Validierung | qtec-group
Ist dein System CSV-pflichtig?
Du bist unsicher, ob deine Excel-Lösung, dein ERP oder ein anderes Anwendungssystem validiert werden muss? In einem kostenlosen Erstgespräch (30 Minuten) klären wir gemeinsam:
- ob CSV für dein System erforderlich ist
- welche Normen für dich relevant sind
- wie hoch der Validierungsaufwand realistisch ist
Normative Grundlagen der Computer System Validation
CSV ist in der Medizintechnik klar verankert. Die Grundlage ist die ISO 13485:2016, insbesondere Kapitel 4.1.6, das fordert: Software im Qualitätsmanagementsystem muss vor Erstnutzung und nach Änderungen validiert werden – risikobasiert und dokumentiert.
Ergänzend dazu sind FDA-Anforderungen relevant, z. B.:
- 21 CFR 820.70(i): Validierung automatisierter Prozesse
- 21 CFR Part 11: Anforderungen an elektronische Aufzeichnungen und Signaturen, inkl. Schutz vor Manipulation
Leitlinien wie GAMP 5, ISO/TR 80002-2 und FDA-Guidances zeigen konkrete Wege zur Umsetzung. Dabei gilt:
- GAMP 5 ist sehr umfassend und bietet ein komplettes Framework zur Implementierung.
- ISO/TR 80002-2 ist schlanker und pragmatischer – oft schneller umsetzbar, besonders für überschaubare Systemlandschaften.
Für Tipps zur Umsetzung haben wir den Artikel „Softwarevalidierung mit Computer Software Assurance“ für Sie erstellt.
Welche Softwarearten gibt es – und was bedeutet das für Validierung?
SSoftware ist nicht gleich Software – und genau deshalb ist auch Validierung nicht einheitlich, sondern abhängig von Art, Einsatz und Risiko des jeweiligen Systems. In der Medizintechnik unterscheidet man mehrere Kategorien von Software, für die jeweils unterschiedliche normative Anforderungen und Validierungsansätze gelten.
Es müssen für die Entwicklung und Prüfung verschiedene Daten: Trainings-, Validierungs-, Test- und Produktionsdaten vorgehalten werden. Ein Fokus besteht in den Kennzahlen wie Accuracy, Loss, Precision und Recall. Overfitting muss erkannt und kontrolliert werden (z. B. gemäß ISO 24027). Das gesamte Medizinprodukt inklusive KI-Komponente muss zusätzlich über die Gebrauchstauglichkeit nach IEC 62366-1 validiert werden, um eine sichere Anwendung durch Nutzer nachzuweisen.
Eigenentwickelte Software in Medizinprodukten
Selbst entwickelte Medizinproduktsoftware wird typischerweise nach IEC 62304 bzw. IEC 82304-1 entwickelt. Für die Validierung des Gesamtsystems spielt zusätzlich IEC 62366-1 (Usability) eine zentrale Rolle. Ziel ist nicht nur technische Korrektheit, sondern sichere Nutzung im Anwendungskontext.
Software in Systemen: SOUP und OTS
Viele Systeme enthalten eingebundene Komponenten wie Betriebssysteme, Bibliotheken, Treiber oder Datenbanken.
SOUP (Software of Unknown Provenance): bezeichnet Software, deren Entwicklungsprozess und vollständige Spezifikation dem Hersteller nicht in der erforderlichen Tiefe bekannt oder nicht vollständig kontrollierbar ist. Das kann kommerzielle Software sein, Open-Source-Komponenten oder auch intern verfügbare Altsoftware, für die die ursprünglichen Entwicklungsnachweise nicht ausreichend vorliegen. Für SOUP ist insbesondere relevant: Identifikation der Komponente, Ableitung von Anforderungen, Bewertung bekannter Anomalien, Risikobewertung sowie die Definition von Risikokontrollmaßnahmen (inkl. Nachweisführung/Teststrategie) – jeweils risikobasiert.
OTS (Off-The-Shelf Software): Standardsoftware als FDA-Pendant zu SOUP, mit Fokus auf FDA-Guidelines. Auch hier bleibt der Hersteller verantwortlich; je nach Risiko kann der Aufwand bis zu Lieferantenbewertungen/Audits reichen.
Für Details zu SOUP / OTS konsultieren Sie gerne den Blogbeitrag "Tipps für die Softwareentwicklung".
Computer System Validierung von Anwendungssystemen (CSV)
CSV ist für QMS-relevante Anwendungssysteme verpflichtend – z. B. Excel, ERP, LIMS, eDMS oder QMS-Systeme. Ziel ist der Nachweis „fit for intended use“ und der Schutz der Datenintegrität. Darum geht es in diesem Blogbeitrag.
CSV auditfest und pragmatisch umsetzen
Du möchtest Computer System Validation schlank, risikobasiert und auditfest umsetzen, ohne unnötige Dokumentationslast? In einem persönlichen Beratungstermin zeigen wir dir u.a. wie ein passender CSV-Lifecycle für deine Systemlandschaft aussieht
Welche Systeme müssen validiert werden – und welche nicht?
CSV ist relevant, wenn Software:
- Daten erfasst (z. B. Prüfwerte, Laborwerte, Produktionsparameter)
- Daten speichert (lokal, Cloud, Datenbanken)
- Daten verarbeitet (Berechnungen, Auswertungen, Statistiken)
- Daten überträgt (Schnittstellen, Exporte)
- Workflows steuert (Freigaben, elektronische Signaturen)
- Entscheidungsgrundlagen liefert (Trending, automatische Checks)
Nicht validierungspflichtig sind typischerweise Tools ohne QMS-Bezug, z. B. reine Office-Viewer, Kalender-/Kommunikationssoftware oder Anwendungen aus nicht qualitätsrelevanten Bereichen.
CSV Quick-Check
Wenn mindestens eine Frage mit „Ja“ beantwortet wird:
Daten erfassen
Daten speichern
Daten verarbeiten
Daten übertragen
Workflows steuern
Entscheidungen unterstützen
ist CSV sehr wahrscheinlich erforderlich.
Bestandssysteme CSV-sicher aufstellen
Du hast bereits Systeme im Einsatz (z. B. Excel, LIMS, QMS, ERP), die nie oder nur teilweise validiert wurden? Wir unterstützen dich bei:
- retrospektiver bzw. risikobasierter Revalidierung
- Audit-Findings und CAPA-Maßnahmen
- der nachhaltigen Absicherung des validierten Zustands
Typen der Validierung
In der Medizintechnik unterscheidet man drei Grundtypen:
- Prospektive Validierung: vor Erstnutzung (bevor Schulung und Prozessfreigabe erfolgen) – der bevorzugte Standard.
- Begleitende Validierung: parallel zur Einführung/Entwicklung, z. B. bei iterativen Rollouts.
- Retrospektive Validierung: nachträglich für Bestands-/Altsysteme – nur eingeschränkt geeignet.
Aus GAMP-Sicht sollte prospektiv validiert werden; begleitende und retrospektive Ansätze sind nur begründet und risikobasiert akzeptabel.
CSV Lifecycle: von der Planung bis zur Freigabe
Damit CSV im Audit nachvollziehbar ist, reicht es nicht aus, „irgendwie zu testen“. Entscheidend ist eine klare, dokumentierte Kette von vorgesehener Zweck → Anforderungen → Risikoanalyse → Tests → Freigabe. Je nach Systemkritikalität und Komplexität kann der Umfang variieren – die folgenden Artefakte bilden jedoch den typischen Standard in CSV-Projekten:
| Schritt / Artefakt | Inhalt (Was wird geprüft?) | Zweck (Wozu?) | Typische Nachweise / Output |
|---|---|---|---|
| vorgesehener Zweck | Einsatzkontext, Prozess, Datenfluss, Grenzen | Basis für Scope, Risiken und Tests | Zweckbestimmungs-dokument / URS / Validierungsplan |
| GxP Assessment | Patientensicherheit, Produktqualität, Datenintegrität | Entscheidung zur Validierungstiefe | GxP-Bewertung inkl. Begründung |
| GAMP Kategorie | Bestimmung Komplexität und Anpassungsgrad | Ableitung des Validierungsaufwands | Kategorisierung + Begründung |
| Zulieferer Assessment | QMS, Doku, Tests, Stabilität, Monitoring | Vertrauen in Lieferantennachweise | Fragebogen/Auditbericht, Re-Assessment |
| URS (Benutzer-anforderungen) | UI, Inputs, Berechnungen, Schnittstellen, Rollen | Testbare Anforderungen definieren | URS + Traceability |
| Risikoanalyse | kritische Funktionen, Hazards, Controls | Fokus auf risikorelevante Nachweise | Risk Assessment + Maßnahmen |
| DQ (Design Qualifikation) | Review: Anforderungen vs. Design/Konfiguration | Design unterstützt vorgesehener Zweck | DQ-Protokoll / Review-Records |
| IQ (Installation Qualifikation) | Installation, Konfiguration, Version, Umgebung | System korrekt installiert | IQ-Testplan/-report |
| OQ (Operational Qualifikation) | Funktionstest gegen Spezifikation | System arbeitet wie spezifiziert | OQ-Testfälle inclusive Pass/Fail |
| PQ (Performance Qualifikation) | End-to-End Szenarien im realen Prozess | System funktioniert im Betrieb | PQ-Szenarien + Ergebnisnachweise |
| Abweichungen | Impact | Fehler kontrolliert behandeln | Abweichungsreport + Abschluss |
| Validierungsreport | Scope, Aktivitäten, Ergebnisse, Freigabe | „Eignung für den vorgesehenen Zweck“ belegen | Report + Release Statement |
| Änderungs-kontrolle / Periodischer Review | Updates, Änderungen, Revalidierung | Validierter Zustand bleibt erhalten | Change Records, Review-Protokolle |
| Stilllegung | Migration, Archivierung | Zugriff & Datenintegrität sichern | Stilllegungsplan + Nachweise |
Folgende GAMP Kategorien gibt es:
| Kategorie | Beschreibung | Beispiel |
|---|---|---|
| Kategorie 1 | Infrastruktur | Betriebssysteme, Datenbanken, Backup, Antivirus |
| Kategorie 3 | Standardsoftware | COTS - Commercial Off the Shelf Software (Excel, Compiler) |
| Kategorie 4 | konfigurierte Standardsysteme | ERP, LIMS, QMS, eDMS |
| Kategorie 5 | kundenspezifisch/stark angepasst | Excel mit VBA |
CSV in der Praxis: So entsteht ein auditfester Nachweis
CSV ist nicht nur eine Sammlung von Dokumenten, sondern ein nachvollziehbarer Prozess, der zeigt, dass ein System kontrolliert eingeführt, getestet und freigegeben wurde. In Audits wird dabei besonders geprüft, ob vorgesehener Zweck, Anforderungen, Risiken und Tests logisch zusammenpassen und ob kritische Funktionen mit angemessener Tiefe abgesichert sind.
Im Zentrum stehen eine risikobasierte Teststrategie und klare Nachweise: Testfälle werden aus den Benutzeranforderungen abgeleitet (inkl. Negativ- und Grenzfalltests), Pass/Fail-Kriterien sind definiert und Abweichungen werden bewertet sowie sauber geschlossen. Ergänzend ist ein Supplier Assessment wichtig, um Lieferantennachweise, Dokumentation und Change-Fähigkeit angemessen zu bewerten – bei kritischen Systemen kann dies bis zu Auditaktivitäten beim Anbieter reichen.
Der Validation Report bündelt die Ergebnisse und endet mit der formalen Aussage zur Eignung für den vorgesehenen Zweck. So entsteht ein schlanker, aber belastbarer Nachweis, der im Audit verständlich ist und im Betrieb tragfähig bleibt. Wer CSV pragmatisch starten möchte, kann sich an einem schlankeren Vorgehen orientieren, wie es z. B. die ISO/TR 80002-2 beschreibt. Dazu kann ich Ihnen den Artikel: Softwarevalidierung mit Computer Software Assurance | qtec-group) empfehlen.
Wartung & Stilllegung
Wartung (Betrieb)
Nach der Initialvalidierung muss das System im validierten Zustand gehalten werden. Dazu gehören Änderungen & Änderungsmanagement, Incident-/Problem-Management, geregelte Benutzer- und Rechteverwaltung sowie periodische Reviews. Backups, Restore-Tests, Security-Maßnahmen und gepflegte Dokumentation sichern Datenintegrität und Systemverfügbarkeit.
Stilllegung (Außerbetriebnahme)
Stilllegung ist die geplante Außerbetriebnahme eines Systems, z. B. bei Ersatz oder fehlendem Vendor-Support. Der Fokus liegt auf Datenintegrität und dauerhaftem Zugriff auf QMS-relevante Records – auch nach Abschaltung. Bei Migration ins Neusystem darf es zu keinem Datenverlust und keinen Konvertierungsfehlern kommen. Stilllegung erfolgt formal über Change Control mit Plan, Risikoanalyse und Freigaben.
Fazit
CSV ist ein zentraler Bestandteil eines wirksamen Qualitätsmanagements in der Medizintechnik. Wer CSV risikobasiert aufsetzt, reduziert Aufwand, erhöht die Compliance und schützt Patientensicherheit, Produktqualität und Datenintegrität. Der beste Einstieg ist klar: vorgesehener Zweck + GxP Assessment + saubere Anforderungen, daraus abgeleitet eine pragmatische Teststrategie – und ein Lifecycle, der auch Betrieb und Stilllegung kontrolliert abdeckt.
Kommt dir bekannt vor?
Dann lass uns drüber sprechen. Unsere Expertinnen und Experten kennen genau diese Herausforderungen – und unterstützen MP-Hersteller flexibel, pragmatisch und auf Augenhöhe.
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
