Computer System Validation (CSV) vs. Computer System Assurance (CSA): Was sind die Hauptunterschiede?

Wenn Sie in der Pharma- oder Medizinproduktebranche arbeiten, haben Sie wahrscheinlich in letzter Zeit häufig die Begriffe CSV und CSA gehört. Und wenn Sie jemals versucht haben, sie nachzuschlagen, sind Sie möglicherweise auf Wände von regulatorischer Sprache gestoßen, die eher verwirrend als hilfreich wirkten. 

Lassen Sie uns das also in klaren, einfachen Worten aufschlüsseln: was diese beiden Ansätze tatsächlich bedeuten, wie sie sich unterscheiden und warum das für Ihre Organisation wichtig ist.

Was ist Computer System Validation (CSV)?

Validierung von Computersystemen, oder CSV, ist seit Jahrzehnten der Standardansatz in regulierten Branchen. Im Kern ist CSV ein dokumentierter Prozess, der sicherstellt, dass ein Computersystem genau das tut, wofür es vorgesehen ist,  konsistent und wiederholt. Das Ziel ist, die Datenintegrität, die Produktqualität und die Einhaltung der geltenden GxP-Vorschriften zu gewährleisten.

Die FDA veröffentlichte ihre CSV-Leitlinie erstmals im Jahr 2003, zusammen mit der bekannten Vorschrift 21 CFR Part 11, die elektronische Aufzeichnungen und elektronische Signaturen regelt. Seitdem ist CSV der bevorzugte Rahmen für Pharmaunternehmen, Clinical Research Organizations und Hersteller medizinischer Geräte bei der Implementierung oder Aktualisierung eines computerisierten Systems.

Die vier Fragen, die den CSV-Prozess antreiben

Bei einem CSV-Ansatz folgt der Validierungsprozess einem strukturierten Lebenszyklus. Bevor irgendwelche Tests beginnen, muss ein Team vier grundlegende Fragen beantworten: 

• Was wird validiert? 
• Was sind die Akzeptanzkriterien? 
• Wie wird validiert? 
• Und wer führt die Validierung durch? 

Diese Fragen prägen die gesamte Dokumentationsstrategie und helfen, den Umfang der Arbeiten zu definieren.

Die drei Kern-Spezifikationsdokumente

Die Validierung selbst basiert auf drei wichtigen Spezifikationsdokumenten. Die Benutzeranforderungs­spezifikation (URS) erfasst, was das System aus Sicht des Anwenders leisten muss; beispielsweise muss ein Laborsystem möglicherweise Analystenschulungsnachweise verfolgen, Aufgaben automatisch zuweisen und mit 21 CFR Part 11 konform sein. 

Die Funktionale Spezifikation (FS) beschreibt, wie das System diese Anwenderanforderungen erfüllen wird, einschließlich der Benutzeroberfläche und der Datenverarbeitung. Die Konstruktionsspezifikation (DS) geht tiefer in die technische Architektur,  Datenbankdesign, Sicherheitsmaßnahmen, Netzwerkanforderungen und Schnittstellenkonfigurationen.

Wie Tests funktionieren: IQ, OQ und PQ

Sobald diese Dokumente vorliegen, folgen die Tests dem klassischen V-Modell (auch linearer Ansatz genannt).Installationsqualifizierung (IQ) stellt sicher, dass das System gemäß den Designspezifikationen korrekt installiert wurde. Betriebsqualifizierung (OQ) prüft, dass das System wie in der Functional Specification beschrieben funktioniert. Und Leistungsqualifizierung (PQ) bestätigt, dass das System unter realen Bedingungen den Anwenderanforderungen entspricht. Kurz gesagt: Jede Spezifikation hat einen entsprechenden Test, was zu einem erheblichen Dokumentationsumfang führt.

Die Stärken und die Kritik an CSV

Diese dokumentationsintensive Natur von CSV war immer sowohl seine Stärke als auch seine größte Kritik. Ja, es ist gründlich. Ja, es schafft eine solide Papierspur. Aber es ist auch zeitaufwändig, teuer und führt manchmal dazu, dass Organisationen Berge von Papierkram erzeugen, die wenig tatsächlichen Mehrwert für die Patientensicherheit oder Produktqualität liefern.

Was ist Computer Software Assurance (CSA)?

An dieser Stelle kommt Computer-Software-Absicherung (CSA) ins Spiel. Die FDA stellte CSA durch ein Entwurfsleitdokument mit dem Titel "Computer Software Assurance für Produktions- und Qualitätssystemsoftware," veröffentlicht am 13. September 2022. Die zugrundeliegende Idee von CSA ist einfach: Anstatt alles mit dem gleichen Maß an Strenge unabhängig vom Risiko zu validieren, konzentrieren Sie Ihre Bemühungen dort, wo sie am wichtigsten sind.

CSA ist ein risikobasierter Ansatz, der darauf abzielt, Vertrauen darin zu schaffen und aufrechtzuerhalten, dass Software für ihren vorgesehenen Gebrauch geeignet ist. Anstatt für jede Systemfunktion umfangreiche Dokumentation zu erstellen, fordert CSA Teams auf, kritisch darüber nachzudenken, was schiefgehen könnte und wie schwerwiegend die Konsequenzen wären. Je höher das Risiko für die Patientensicherheit oder die Produktqualität, desto rigider müssen die Tests sein. Für Softwarefunktionen mit geringerem Risiko sind weniger Dokumentation und einfachere Testmethoden völlig akzeptabel.

Schritt 1: Bestimmung des vorgesehenen Gebrauchs

Der CSA-Prozess beginnt mit der Bestimmung des vorgesehenen Gebrauchs der Software. Die FDA unterscheidet zwischen Software, die direkt als Teil der Produktion oder eines Qualitätssystems verwendet wird, wie z. B. Tools, die Herstellungsprozesse automatisieren oder Qualitätsdaten erfassen, und Software, die diese Systeme unterstützt, wie z. B. Testtools oder allgemeine Anwendungen zur Aufzeichnung. Software, die für allgemeine Geschäftsaufgaben wie E-Mail oder Buchhaltung verwendet wird, fällt vollständig außerhalb des Geltungsbereichs.

Schritt 2: Risikobewertung

Sobald der vorgesehene Gebrauch klar ist, besteht der nächste Schritt darin, das Risiko zu bewerten. Eine Softwarefunktion gilt als hohes Risiko, wenn ihr Ausfall zu einem Qualitätsproblem führen könnte, das die Patientensicherheit gefährdet.

Beispielsweise würde Software, die kritische Prozessparameter wie Temperatur oder Druck überwacht, oder Software, die die Produktakzeptanz ohne zusätzliche menschliche Überprüfung analysiert, typischerweise in die Kategorie hohes Risiko fallen. Andererseits wird Software, die für CAPA-Routing, Beschwerdeverfolgung oder Änderungssteuerung verwendet wird, im Allgemeinen nicht als hohes Risiko angesehen.

Schritt 3: Bestimmung der geeigneten Testart

Der Risikograd bestimmt dann die erforderliche Testart. Funktionen mit hohem Risiko erfordern robuste skriptgestützte Tests, die strukturiert, dokumentiert und nachvollziehbar gegenüber den Anforderungen sind. Funktionen mit mittlerem Risiko können begrenzte skriptgestützte Tests verwenden, eine Mischung aus strukturierten und flexiblen Methoden.

Für Funktionen mit geringem Risiko sind unskriptete Testmethoden wie exploratives Testen, Ad-hoc-Tests oder Error-Guessing völlig ausreichend. Der Tester nutzt sein Wissen und Urteilsvermögen, um das System zu erkunden, ohne dass formelle Testskripte erforderlich sind.

Schritt 4: Führung der richtigen Aufzeichnungen

Aufzeichnungen müssen unter CSA weiterhin geführt werden, jedoch sind sie schlanker und zielgerichteter. Ein CSA-Dokument sollte den vorgesehenen Gebrauch der Softwarefunktion, die festgelegte Risikostufe, eine Beschreibung der durchgeführten Tests, gefundene Probleme und deren Behebung, eine Schlussfolgerung, ob die Ergebnisse akzeptabel sind, das Testdatum und den Namen der durchführenden Person erfassen.

CSV vs. CSA: Die wichtigsten Unterschiede

Sowohl CSV als auch CSA dienen dazu, sicherzustellen, dass computerisierte Systeme in regulierten Branchen zuverlässig, konform und für den Gebrauch geeignet sind. Beide beinhalten Planung, Tests, Dokumentation und Berichterstattung. Und beide gelten für Systeme, die die Patientensicherheit, Produktqualität und Datenintegrität beeinflussen. Doch die Gemeinsamkeiten verblassen, wenn man die zugrunde liegenden Philosophien der jeweiligen Ansätze betrachtet.

CSV: Von Natur aus Compliance-getrieben

CSV ist grundlegend compliance-getrieben. Es validiert, dass ein System eine vordefinierte Reihe von Spezifikationen erfüllt, und tut dies mit gleicher Gründlichkeit für alle Systemfunktionen. Die Dokumentationslast ist hoch, und der Prozess ist größtenteils derselbe, unabhängig davon, ob Sie ein missionskritisches Datenerfassungssystem oder eine einfache Dokumentenverwaltungsfunktion testen.

CSA: Von Grund auf Assurance-getrieben

CSA hingegen ist assurance-getrieben. Es fordert Teams auf, kritisch über Risiken nachzudenken und den Testaufwand proportional zu dem einzusetzen, was tatsächlich auf dem Spiel steht. Es ersetzt die Einheitsgröße-für-alles-Mentalität von CSV durch einen gezielten, flexiblen und intelligenteren Ansatz. Für Funktionen mit geringem Risiko wird weniger Zeit mit dem Schreiben von Testscripts verbracht, und mehr Zeit auf sinnvolle Absicherung in Bereichen verwendet, die Patienten wirklich schaden oder die Produktqualität gefährden könnten.

Was CSA in der Praxis bedeutet

Praktisch gesehen reduziert CSA die Durchlaufzeiten für Testentwurf, Überprüfung und Freigabe. Es verringert die Anzahl der erzeugten Dokumente. Es erlaubt Organisationen, die Testnachweise von Lieferanten anzuerkennen, anstatt dieselben Validierungsarbeiten zu wiederholen. Und es unterstützt Unternehmen, die sich in Richtung Automatisierung und agile Entwicklungspraktiken bewegen, bei denen starre, lineare Validierungsmodelle häufig Engpässe erzeugen.

Ersetzt CSA CSV?

Eine wichtige Unterscheidung, die es zu beachten gilt: CSA beseitigt nicht die Notwendigkeit von CSV. Vielmehr definiert es neu, wie Validierung durchgeführt wird. Einige stark regulierte Systeme können weiterhin von der umfassenden Struktur profitieren, die CSV bietet. Die Entscheidung, welchen Ansatz man anwendet oder ob man beide kombiniert, hängt von der Art der Software, dem eingegangenen Risiko und den regulatorischen Verpflichtungen der Organisation ab.

Der Übergang von CSV zu CSA

Für Organisationen, die seit Jahren CSV verwenden, kann die Umstellung auf CSA wie ein großer kultureller Wandel erscheinen. Und in vielerlei Hinsicht ist es das auch. Der Übergang erfordert, dass Teams aufhören, Validierung als eine Dokumentationsübung zu betrachten, und stattdessen als eine Risikomanagementaufgabe anfangen zu denken.

Praktisch bedeutet der Übergang, aktuelle Validierungspraktiken zu bewerten, um Bereiche zu identifizieren, in denen die Dokumentation reduziert werden kann, ohne die Compliance zu gefährden. Es bedeutet, Qualitäts- und IT-Teams in CSA-Prinzipien und risikobasiertem Denken zu schulen.

Es bedeutet, zu lernen, Lieferantendokumentation und Daten zur Lieferantenqualifizierung effektiver zu nutzen, anstatt Validierungsaufwände intern zu duplizieren. Und es bedeutet, Tools und Technologien anzunehmen, die Teile des Assurance-Prozesses automatisieren können.

Die Umstellung muss nicht über Nacht erfolgen. Viele Organisationen wenden die CSA-Prinzipien bei neuen Systemimplementierungen an, während sie ihren bestehenden CSV-Ansatz für Altsysteme beibehalten. Diese gestufte Strategie ermöglicht es Teams, Erfahrung und Vertrauen in den neuen Ansatz aufzubauen, ohne den laufenden Betrieb zu stören.

Warum das für Ihre Organisation wichtig ist

Der Wechsel von CSV zu CSA spiegelt einen breiteren Wandel in der FDA-Herangehensweise an Qualität wider. Anstatt Konformität mit Papierkram gleichzusetzen, drängt die FDA auf eine Kultur, in der Qualität in Prozessen verankert ist, Entscheidungen auf risikobasierter Denkweise beruhen und Validierungsmaßnahmen dort konzentriert werden, wo sie echten Mehrwert schaffen.

Für Pharma- und Medizinprodukteunternehmen ist das letztlich vorteilhaft. Es bedeutet weniger Zeit, die in Testskripten verschwendet wird, und mehr Zeit, die auf den Aufbau von Systemen verwendet wird, die wirklich sicher, zuverlässig und wirksam sind. Es bedeutet schnellere Implementierungszeiten, effizientere Ressourcennutzung und Validierungspraktiken, die mit der Komplexität moderner Software skalieren.

Ob Sie noch vollständig CSV verpflichtet sind, CSA aktiv erkunden oder irgendwo dazwischen liegen: Das Verständnis des Unterschieds zwischen diesen beiden Ansätzen ist der erste Schritt, um klügere Entscheidungen darüber zu treffen, wie Ihre Organisation computergestützte Systeme verwaltet und validiert.

Häufig gestellte Fragen (FAQs)

F1. Was ist der Hauptunterschied zwischen CSV und CSA in der Pharmaindustrie?

CSV (Computer System Validation) ist ein dokumentationsintensiver, konformitätsgetriebener Ansatz, der alle Systemfunktionen mit gleicher Strenge validiert. CSA (Computer Software Assurance) ist ein von der FDA eingeführter, risikobasierter Ansatz, der Testaktivitäten auf Bereiche mit dem höchsten Einfluss auf Patientensicherheit und Produktqualität konzentriert und unnötige Dokumentation für niedrigrisikobehaftete Funktionen reduziert.

F2. Ersetzt CSA CSV in der Pharmaindustrie?

CSA ersetzt CSV nicht vollständig. Vielmehr definiert es neu, wie Validierung durchgeführt wird. Die FDA hat CSA eingeführt, um den Validierungsprozess effizienter und risikoorientierter zu gestalten. Organisationen können CSV weiterhin für stark regulierte oder komplexe Systeme einsetzen und gleichzeitig CSA-Prinzipien auf andere Software anwenden, bei der ein leichterer Ansatz angebracht ist.

F3. Welche Vorschriften regeln CSV und CSA in den Life Sciences?

CSV wird hauptsächlich durch FDA 21 CFR Part 11 und GxP-Richtlinien sowie GAMP 5 geregelt, das computergestützte Systeme nach Risiko kategorisiert. CSA wird durch den Entwurf der FDA-Leitlinie von 2022 zur "Computer Software Assurance for Production and Quality System Software" gelenkt, die einen risikobasierten Rahmen für Assurance-Aktivitäten beschreibt.

F4. Welche Testarten werden in CSA verwendet?

CSA verwendet zwei Hauptarten von Tests, basierend auf dem Risikoniveau. Für Softwarefunktionen mit hohem Risiko sind robuste skriptbasierte Tests mit formaler Dokumentation erforderlich. Für Funktionen mit niedrigem bis mittlerem Risiko sind unskriptierte Testmethoden wie Exploratory Testing, Ad-hoc-Testing und Error-Guessing akzeptabel, wodurch die Notwendigkeit formaler Testskripte und umfangreicher Dokumentation reduziert wird.

F5. Wie wechselt ein Pharmaunternehmen von CSV zu CSA?

Ein Übergang von CSV zu CSA umfasst die Anwendung risikobasierter Denkweise auf bestehende Validierungsprozesse, die Reduzierung skriptbasierter Tests für niedrigrisikobehaftete Systemfunktionen, die Nutzung von vom Lieferanten bereitgestellten Qualifizierungsnachweisen und die Schulung von Qualitäts- und IT-Teams in CSA-Prinzipien. Die meisten Organisationen verfolgen einen gestuften Ansatz, beginnen mit neuen Systemimplementierungen und befassen sich später mit Altsystemen.