Computerized Systems Validation (CSV)

Eine häufige Frage an uns lautet: „Bieten Sie auch Computerized Systems Validation an?“ Einer der Gründe für das Interesse ist sicherlich, dass Behörden und Benannte Stellen das Thema CSV immer öfter zum Gegenstand von Audits machen.

Lesen Sie hier, welche Regularien es zur „Computerized Systems Validation“ gibt und wie Sie deren Forderungen am elegantesten erfüllen.

Computerized Systems Validation: Was ist CSV?

a) Erste Definition und Ziel der CSV

Computerized Systems Validation (CSV) ist ein dokumentierter Prozess, mit dem konsistent und reproduzierbar sichergestellt wird, dass ein Computersystem genau das tut, wofür es entwickelt wurde [1].

b) Was ist in diesem Kontext unter Validierung zu verstehen?

Als Validierung gilt üblicherweise eine „Bestätigung durch Vorlage eines objektiven Nachweises, dass die Anforderungen für einen spezifischen vorgesehenen Gebrauch oder eine spezifische vorgesehene Anwendung erfüllt sind.“ [ISO 9001:2015]

Bei Medizinprodukten bedeutet dies eine „Prüfung mit objektiven Mitteln, ob die spezifizierten Nutzer im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele (–> Zweckbestimmung) erreichen können.“

Dies klingt, als müsse nur das fertige Produkt validiert werden, hier also das installierte Computersystem.

Doch viele Regularien gehen darüber hinaus, auch Anforderungen der FDA: Sie fordern, den kompletten Entwicklungsprozess zu validieren, nicht nur dessen letzte Phase oder das Endprodukt. Dazu später mehr.

c) Computerized Systems Validation versus DQ, IQ, OQ und PQ

DQ, IQ, OQ und PQ – diese Akronyme begegnen uns im Kontext der CSV. Sie stehen für:

• DQ: Design Qualification (Designqualifizierung)
• IQ: Installation Qualification (Installationsqualifzierung)
• OQ: Operation Qualification (Funktionsqualifizierung)
• PQ: Performance Qualification (Leistungsqualifizierung)

Diese Qualifizierungen werden vor allem im pharmazeutischen Umfeld beispielsweise von GMP-Richtlinien verlangt und zählen wie die CSV zu den Gerätevalidierungen. IQ, OQ und PQ umfassen bestimmte Aspekte der Validierung bzw. Qualifizierung [2]:

• IQ: Erste Prüfungen beim Kunden während der Installation sollen sicherstellen: Das Gerät ist gemäß der Spezifikation geliefert, aufgebaut und installiert. Es entspricht den Anforderungen der Nutzer. Die Dokumentation liegt vor.
• OQ: Checks möglichst bald nach der IQ sollen bestätigen: Das Gerät arbeitet spezifikationsgemäß – auch an den Spezifikationsgrenzen.
• PQ: Bei diesen Tests geht es unter anderem um die Messgenauigkeit (inkl. Kalibrierung und Justierung).

d) Computerized Systems Validation versus Software Validation

Die Computerized Systems Validation umfasst prinzipiell sowohl Hardware als auch Software. Speziell bei Standard-Hardware wie PC-basierten Systemen entspricht die Computerized Systems Validation jedoch weitgehend der Software-Validation. Bei spezifischer Hardware wäre beispielsweise zu prüfen, ob

• sich die Software auf der Hardware installieren lässt,
• das Gesamtsystem mit ausreichender Geschwindigkeit arbeitet
• das Zusammenspiel mit Nachbarsystemen (z. B. anderen Geräten oder IT-Systemen) wie spezifiziert funktioniert.

Wer verlangt was? Regulatorische Anforderungen an CSV

a) Überblick

Die Anforderungen an die Validierung von Computersystemen finden sich in:

b) FDA 21 CFR part 820.70

Die FDA schreibt im 21 CFR part 820.70:

„When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.“

c) FDA 21 CFR part 11

Der 21 CFR fordert im Teil (part) 11.10:

„Persons who use systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records. Such procedures and controls shall include validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.“

Diese Forderung nach Validierung entspricht dem, was auch der 21 CFR part 820.70 fordert.

d) FDA Computer Software Assurance for Production and Quality System Software

Diese Leitlinie soll das sehr in die Jahre gekommene Guidance-Dokument der FDA zu „Software Validation“ in den Teilen ablösen, die nicht die Software betreffen, die Teil des Medizinprodukts bzw. selbst das Medizinprodukt wird.

Anforderungen

Die FDA fordert bzw. erlaubt einen risikobasierten Ansatz. Abhängig vom Risiko des Produktes müssen die Hersteller „Assurance Activities“ wie Software-Tests durchführen.

Bewertung

Positiv zu bewerten ist, dass die FDA mit diesem Dokument die Entwicklung von Medizinprodukte-Software von der Entwicklung von Software unterscheidet, die im Rahmen von QM-Systemen eingesetzt wird.

Gleichzeitig halte ich das Dokument für keinen großen Wurf:

• Erneut wirkt es so, als hätten keine Software-Engineering-Experten die Leitlinie verfasst. Gleich ob Definitionen, Terminologien oder Methoden. Das Dokument nutzt eigene Konzepte.
• Die Software-Qualitätssicherung so sehr auf die analytische Qualitätssicherung, insbesondere das Software-Testing, zu reduzieren, ist schwierig. Qualität lässt sich nicht in die Software hineintesten.
• Leider beschränkt sich das Dokument auf die Software für die Produktion und das Qualitätsmanagement, wozu auch bestimmte „Development-Tools“ und sogar Lern-Managementsysteme zählen.

Die ohnehin schon große Menge an Vorgaben zur CSV wird noch umfangreicher. 

Dass die FDA auch das Cloud-Computing adressiert, ist hingegen wichtig und hilfreich.

e) ISO 13485:2016

Die ISO 13485:2016 hat in ihrer aktuellen Version die Anforderungen an die Validierung von Computersystemen noch klarer formuliert:

Sie verlangt in Kapitel 4.1.6, dass die Hersteller die Computersoftware gemäß dokumentierter Verfahren validieren. Das betrifft alle Software, die im Rahmen eines Prozesses verwendet wird, der das QM-System steuert. Die Validierung muss nicht nur vor der ersten Nutzung, sondern auch bei Änderungen an der Software erfolgen.

Um es noch deutlicher auszudrücken: In Europa war die CSV bisher nur für die Produktions- und Dienstleistungsprozesse gefordert. Seit der ISO 13485:2016 gilt diese Forderung für alle Prozesse des QM-Systems. Im FDA-Kontext war das schon immer so.

f) GAMP 5

Der GAMP 5 fühlt sich ebenfalls als anwendbar für Medizinproduktehersteller. Die Autoren schreiben:

The scope has been widened [im Vergleich zum Gamp 4] to include related industries and their suppliers, including biotechnology and systems used in medical device manufacturing (excluding software embedded within the medical devices).

Computerized Systems Validation: Wie macht man CSV?

Machen Sie sich klar: Welche Anforderungen an die Computerized Systems Validation wollen oder müssen Sie erfüllen?

1. Mindestanforderung: In jedem Fall müssen Sie das „fertige“ Computersystem validieren.
2. Zusätzliche Anforderung: Zumindest, wenn Sie das System selbst entwickeln oder entwickeln lassen, müssen Sie den kompletten Entwicklungsprozess dokumentieren.

Auf beide Varianten gehen wir im Folgenden ein.

Die eigentliche Validierung

Wenn Sie das „fertige“ (ggf. bereits installierte) Computersystem validieren wollen, dann müssen Sie die Anforderungen an das Computersystem kennen. Falls diese Anforderungen fehlen, müssen Sie diese retrospektiv herleiten.

Leider werfen viele Firmen und teilweise auch Behörden die verschiedenen Arten von Anforderungen in einen Topf:

1. Stakeholder-Anforderungen und Zweckbestimmung: Das sind die wirklichen Ziele und Anforderungen, die die verschiedenen Stakeholder wie Nutzer, Betreiber und Gesetzgeber haben, um ihre jeweiligen Ziele erreichen zu können.
   Wenn Sie beispielsweise ein Laborinformationssystem haben, wäre eine Anforderung: Das System muss dem Anwender ermöglichen, Patienten mit Hepatitis zu erkennen.
2. System-Anforderungen / System Requirements Specification: Diese Anforderungen beschreiben, was das System können muss, um die Stakeholder-Anforderungen zu erfüllen. Idealerweise sind diese System- oder Software-Anforderungen als Blackbox-Anforderungen spezifiziert.
   Im Fall des Laborinformationssystems wäre eine solche Anforderung, dass das System alle Patienten, die mindestens einen positiven Hepatitis-Wert haben, in fetter roter Schrift kennzeichnet.

Streng genommen ist die Validierung eine Prüfung, ob der erste Typ an Anforderungen erfüllt ist. In der Praxis beobachtet man allerdings, dass während der Validierung eher die Erfüllung der System- oder Software-Anforderungen geprüft wird. Das ist streng genommen aber eine Verifizierung.

Wie Sie diese Form der Validierung durchführen, lesen Sie weiter unten im Kapitel „CSV: Schritt für Schritt“.

Der vollständige Entwicklungsprozess

Wenn Sie im Sinn des FDA Software Validation Guidance Documents „validieren“, dann werden Sie den kompletten Entwicklungsprozess dokumentieren, z. B.:

• Software-Anforderungen
• Verifizierung der Software-Anforderungen einschließlich Traceability zu Stakeholder-Anforderungen
• Software-Architektur und detailliertes Design
• Verifizierung der Software-Architektur und detailliertes Design einschließlich Traceability zu Software-Anforderungen
• Software-Code, Code-Reviews und Unit-Tests einschließlich Traceability zu Software-Architektur bzw. detailliertem Design
• Integrations- und Systemtests einschließlich Traceability zu Software-Architektur bzw. Software-Anforderungen

Die IEC 62304 und künftige IEC 82304 geben Ihnen ebenso wie das o. g. FDA-Dokument wertvolle Hinweise, wie Sie solch einen Entwicklungsprozess definieren und umsetzen sollten.

Computerized Systems Validation: Schritt für Schritt zur CSV

Um ein Computersystem zu validieren, gehen Sie wie folgt vor:

1. Anforderungen dokumentieren

Wenn die Anforderungen an Ihr Software- bzw. Computersystem nicht oder nicht vollständig dokumentiert sind, holen Sie das nach.

1. Benutzer-Produkt-Schnittstellen
   1. Anzeige: Beschreiben Sie, wie Ihre Benutzer-Produkt-Schnittstelle (GUI = graphical user interface) aussieht und was sie anzeigen muss.
   2. Algorithmen: Wenn diese Anzeige von Berechnungen abhängt, dann benennen Sie diese.
   3. Eingaben: Beschreiben Sie, welche Daten die Anwender in welchen Formaten eingeben können. Ebenso, wie sich das System bei Fehleingaben verhalten soll.
   4. Navigation: Spezifizieren Sie, wie durch das System navigiert wird, d. h., welche „Screens“ das System anzeigen soll, wenn man gewisse Auswahlen macht, z. B. durch Anklicken.
   5. Berechtigungen: Ein spezieller Aspekt des oben Genannten ist die Spezifikation von Rollenkonzepten, Autorisierung und Authentifizierung.
2. Daten-Schnittstellen
   1. System-Kontext: Beschreiben Sie, mit welchen Nachbarsystemen Ihr System interagieren soll.
   2. Interoperabilität: Spezifizieren Sie, wie diese Interaktion stattfindet. Nennen Sie die Standards (z. B. TCP/IP, HTTP, Bus-Systeme), Formate, Ordnungssysteme, Berechtigungen usw. Lesen Sie hier mehr zum Thema Interoperabilität.
      Vergessen Sie nicht, festzulegen, wie sich Ihr System verhalten soll, wenn die Daten in falschem Format, falschem Volumen, unerwarteter Frequenz usw. übertragen werden.
   3. Berechtigungen: Beschreiben Sie, wie sich die Nachbarsysteme an Ihrem System authentifizieren und autorisieren.
   4. Performanz: Spezifizieren Sie, wie schnell Ihr System auf die Datenübertragung reagieren können muss. Diese Anforderung wird wahrscheinlich von der Anzahl der Transaktionen, dem Datenvolumen o. Ä. abhängen.
3. Laufzeitumgebung
   1. Hardware: Spezifizieren Sie die Mindestanforderungen an die Hardware (CPU, RAM, Festplatte, Bildschirmgröße, Bildschirmauflösung usw.).
   2. Betriebssystem: Legen Sie auch das Betriebssystem fest, das Sie mindestens voraussetzen.
   3. Andere Software: Erlauben Sie weitere Software wie Anti-Virus-Programme? Setzen Sie diese sogar voraus, wie z. B. eine Datenbank? Vergessen Sie nicht, diese Anforderungen zu spezifizieren.

2. Testfälle spezifizieren

Als Nächstes müssen Sie die Testfälle spezifizieren, d. h. festlegen,

1. welche Daten der Anwender oder das Nachbarsystem eingeben oder übertragen sollen,
2. welche Voraussetzungen erfüllt sein müssen, z. B. die Software-Version oder vorhandene Daten betreffend,
3. die Prozedur, z. B. in welcher Reihenfolge vorzugehen ist,
4. die Pass-/Fail-Kriterien: Welche Werte erwarten Sie? Welche Ergebnisse erfüllen die Anforderungen?
5. Auch die Dokumentation der Tests ist Teil der Spezifikation.

3. Tests durchführen und dokumentieren

Schließlich müssen Sie die Tests gemäß der Testspezifikation durchführen, dokumentieren und bewerten.

Weitere Tipps

Vielleicht helfen Ihnen folgende Gedanken bei Ihrer CSV:

• Systematisches Ableiten von Testdaten: Die Testdaten sollten Sie sich nicht einfach ausdenken, sondern anhand von Blackbox-Testmethoden wie den äquivalenzklassen-, grenzwert-, entscheidungstabellen-, fehler- oder zustandsbasierten Testverfahren systematisch ableiten. Software-Tester können das.
• Nicht nur der Happy-Path: Prüfen Sie nicht nur, ob das System sich wie spezifiziert verhält, sondern auch, ob es mit falschen oder unvollständigen Eingaben korrekt umgeht.
• Risikobasierter Ansatz: Wenn Sie mit dem Umfang der Tests überfordert sind, dann konzentrieren Sie sich auf jene Teile der Funktionalität, die am kritischsten sind. Das sind jene, bei denen Fehler zu den höchsten Risiken führen.
• Regression: Die CSV ist keine einmalige Sache, sondern jedes Mal zu wiederholen, wenn Sie am System oder der Software etwas ändern. Daher empfiehlt es sich, die Tests zu automatisieren. Es gibt Werkzeuge, mit denen Sie auch Tests der Benutzerschnittstelle semiautomatisiert aufzeichnen und wieder abspielen können.

Änderungshistorie:

Ähnliche Beiträge