In der pharmazeutischen und biotechnologischen Industrie kommt Computern und softwaregestützten Systemen mittlerweile zentrale Bedeutung zu — sei es in der Chargensteuerung, im Laborinformationsmanagement (LIMS), im Manufacturing Execution System (MES), in Qualitätsmanagementsystemen (QMS), in elektronischen Dokumentenmanagementsystemen (EDMS) oder in Systemen zur Prozessführung und Rückverfolgbarkeit. Diese Systeme beeinflussen unmittelbar Produktqualität, Patientensicherheit und Regelkonformität. Daher sind sie Gegenstand strenger regulatorischer Anforderungen, insbesondere hinsichtlich Data Integrity und Computer System Validation (CSV).
Dieser Artikel liefert eine tiefgehende Auseinandersetzung mit den Anforderungen und Best Practices der Validierung von Computersystemen in einem regulierten GxP-Umfeld. Er behandelt das „Warum“ und „Wie“, beleuchtet kritische Aspekte, bringt konkrete Beispiele und diskutiert Chancen und Risiken. Ziel ist es, Fachleuten der Branche ein fundiertes und praktisches Fundament zu bieten.
FDA – General Principles of Software Validation: Diese Guidance legt dar, dass Softwarevalidierung durch „objective evidence” belegt sein muss, dass die User Requirements, Spezifikationen und implementierten Funktionen konsistent und zuverlässig erfüllt werden. (U.S. Food and Drug Administration)
FDA – Computer Software Assurance (CSA): Der neuere Entwurf der FDA betont einen risikobasierten Ansatz, bei dem Testumfang und Validierungsaufwand proportional zur kritischen Bedeutung des Systems bestimmt werden. (U.S. Food and Drug Administration)
EU – EU GMP Annex 11 („Computerised Systems“) (EudraLex Vol. 4, Annex 11): In Europa regelt Annex 11 die Anforderungen an computergestützte Systeme im GMP-Umfeld, u.a. Vorgaben zu Validierung, Änderungsmanagement, Audit-Trails, Datensicherung und Systemmanagement.
WHO – Good Practices for Pharmaceutical Quality System (GPQ) / guidance zur Data Integrity: Die WHO betont, dass Daten während ihres gesamten Lebenszyklus integer, sicher und nachvollziehbar sein müssen (insbesondere gemäß Prinzipien wie ALCOA+).
ICH Q9 (Risk-Based Quality Management): Die Nutzung eines risikobasierten Ansatzes für Validierung und Überwachung von Systemen ist integraler Bestandteil moderner Qualitätsmanagementsysteme.
GAMP® 5 (ISPE: A Risk-Based Approach to GxP Computerized Systems): Der Industriestandard GAMP 5 dient häufig als methodisches Rahmenwerk zur CSV-Planung, Risikobewertung und Lifecycle-Steuerung. (scilife.io)
Diese Leitlinien bilden zusammen den Rahmen, innerhalb dessen Validierungsstrategien in der Praxis umgesetzt werden müssen.
Ein zentrales Prinzip ist, dass jegliche Daten in einem GxP-Computersystem den Anforderungen an Data Integrity genügen müssen. Die FDA etwa definiert in ihrer Guidance „Data Integrity and Compliance with CGMP“ grundlegende Prinzipien wie Attributable, Legible, Contemporaneous, Original, Accurate (ALCOA) sowie Erweiterungen („+“), z. B. Complete, Consistent, Enduring, Available.
In der klinischen Forschung betont die FDA Guidance „Computerized Systems Used in Clinical Investigations“, dass Daten, die in computergestützten Systemen erzeugt, modifiziert, archiviert, abgerufen oder übertragen werden, höchsten Qualitäts- und Integritätsstandards genügen müssen. (U.S. Food and Drug Administration)
Audit-Trails, Versionierung, Zugriffskontrollen, Änderungsnachweise und Rückverfolgbarkeit sind typische Komponenten, um Data Integrity sicherzustellen. Beispielsweise fordert die FDA, dass Audit-Trails unveränderbar sind und Änderungen zeitlich, individuell und begründet nachvollziehbar machen. (clinicalleader.com)
Wenn ein Computersystem nicht zuverlässig funktioniert oder Daten manipuliert werden können, drohen schwerwiegende Konsequenzen:
Falsche Prozessparameter in einem MES könnten zu fehlerhaften Chargen oder Kontamination führen (Qualitätsrisiken).
Fehlerhafte Prüfaufzeichnungen in einem LIMS können dazu führen, dass fehlerhafte Produkte freigegeben werden oder dass Rückrufe erfolgen müssen.
Manipulation von Daten (z. B. im Rahmen von Stabilitätsdaten, Analyseneingaben oder Freigabeprotokollen) kann regulatorische Konsequenzen haben und das Vertrauen in das System untergraben.
Im extremen Fall kann eine fehlerhafte Freigabe oder unerkannte Qualitätsabweichung die Sicherheit der Patienten gefährden.
Die Validierung von Computersystemen trägt somit unmittelbar dazu bei, dass Produktqualität durch konsistente, valide Daten gestützt wird, und Risiken für Patienten minimiert werden.
Die Implementierung einer umfassenden Validierung verursacht Kosten — sowohl für Personal, Tests, Dokumentation, externe Unterstützungsleistungen als auch für Verzögerungen im Projektzeitplan. Andererseits kann mangelnde Validierung zu teuren Nacharbeiten, Systemabweichungen, regulatorischen Beanstandungen, Produktrückrufen oder gar rechtlichen Konsequenzen führen.
Ein risikobasierter Ansatz (etwa im Sinne von CSA) erlaubt, den Validierungsaufwand auf kritische Systeme zu fokussieren und vermeidet überproportionale Kosten in weniger relevanten Bereichen. Zudem kann eine frühzeitige Planung der Validierung (z. B. im Pflichtenheftstadium) helfen, spätere Änderungsaufwände und Verzögerungen zu vermeiden.
Für ein mittleres GxP-System (z. B. LIMS oder MES) kann eine vollständige Validierung inklusive Tests, Dokumentation und Abnahmeworkflow typischerweise einige Wochen bis Monate in Anspruch nehmen. Ein schlecht geplantes Validierungsprojekt kann hingegen leicht den Zeitplan eines gesamten Rollouts gefährden.
Vorteile eines pragmatischen Ansatzes: Fokus auf wesentliche Funktionen, Automatisierung von Tests, Wiederverwendung von Standardtestpaketen und modulare Systemarchitektur können den Aufwand reduzieren.
Risiken eines zu minimalistischen Ansatzes: Wenn wichtige Funktionen nicht adäquat validiert werden, kann das System bei Änderungen oder Updates instabil werden oder unerwartete Fehler erzeugen — und dadurch größere Risiken verursachen.
Balance zwischen Aufwand und Nutzen: Der Schlüssel liegt in einem fundierten Risikomanagement und einer flexiblen, aber kontrollierten Validierungsstrategie.
GAMP 5 empfiehlt, Validierung entlang eines Systemlebenszyklus zu steuern, häufig abgebildet in einem V-Modell:
Planungs- und Konzeptphase (User Requirements, Risikoanalyse)
Entwurf/Designphase (Functional Specification, Design Specification)
Implementierungsphase / Konfiguration / Entwicklung
Testphase (IQ / OQ / PQ)
Go-Live & Abnahmeworkflow
Betrieb, Wartung und Änderungsmanagement
Außerbetriebnahme und Datenarchivierung
Jede Stufe ist mit Rückverfolgbarkeit verbunden — d. h. jede Anforderung muss bis zu den Tests rückverfolgbar sein und umgekehrt.
Ein Risikobasierter Ansatz beginnt mit einer Risikobewertung, typischerweise unter Verwendung von ICH Q9 oder einem firmenspezifischen Bewertungsmodell. Die Risiken werden bewertet nach Wahrscheinlichkeit des Auftretens, Auswirkung auf Produktqualität / Patientensicherheit und Erkennbarkeit.
Basierend auf der Risikobewertung erfolgt eine Kategorisierung des Systems (z. B. „kritisch“, „hoch“, „mittel“, „niedrig“) und eine Zuordnung eines Validierungsregimes (umfassende Tests vs. Stichproben, automatisierte Tests vs. manuelle Prüfung).
Beispiel: Ein MES, das direkt Prozessparameter kontrolliert, hat ein hohes Risiko, und jede Änderung oder Schnittstelle bedarf vollständiger Validierung. Ein System zur Planung von Wartungsaufträgen hingegen könnte in einer geringeren Risikokategorie laufen und weniger intensives Testing benötigen.
Die URS fasst dar, was das System aus Sicht des Anwenders leisten soll (z. B. Funktionen, Schnittstellen, Datenqualität, Sicherheitsanforderungen). Sie ist Ausgangspunkt der gesamten Validierung.
Beispiel: In einem LIMS könnte die URS verlangen, dass Proben zuletzt genutzte Schritte automatisch verfolgt, Sperrlisten geführt werden, und Datenmanipulationen protokolliert werden.
Die FS beschreibt die funktionen, wie sie im System realisiert werden. Die DS (je nach System) verdeutlicht die technische Umsetzung (z. B. Module, Datenbankdesign, Schnittstellen). Es ist essenziell, dass FS und DS konsistent zur URS sind, und dass Änderungen kontrolliert werden.
In einer Requirement-Tracing-Matrix (RTM) werden URS, FS/DS, Testfälle und Testergebnisse miteinander verknüpft. Jede Anforderung sollte verknüpft sein mit Testfällen und deren Ergebnissen, um die Vollständigkeit der Validierung nachzuweisen.
IQ (Installation Qualification / Installationsqualifizierung): Prüfung, ob das System gemäß Spezifikation korrekt installiert wurde — inkl. Hardware, Software, Netzwerke, Lizenzen, Dokumentation.
OQ (Operational Qualification / Funktionsqualifizierung): Überprüfung, ob alle Funktionen wie spezifiziert arbeiten — oft durch definierte Tests, Grenzwerte, Fehlerszenarien.
PQ (Performance Qualification / Leistungsqualifizierung): Test des Systems unter realen Bedingungen, typischerweise mit Produktionsdaten oder simulierten realitätsnahen Daten, um die Leistungsfähigkeit sicherzustellen.
Beispiel: Für ein LIMS könnten in der OQ Tests vorgesehen sein, bei denen Daten importiert, validiert, bearbeitet und gesperrt werden. In der PQ würde man mit realen Probenläufen die Verarbeitung testen und Dauer, Belastung oder Schnittstellenlast simulieren.
Bei modularer Systemarchitektur und wiederkehrenden Funktionen (z. B. Datenimport, Schnittstellen, Validierungsregeln) empfiehlt sich der Einsatz automatisierter Tests, die regelmäßig auch nach Systemänderungen ausgeführt werden (Regressionstests). Das spart Zeit und erhöht Wiederholbarkeit und Konsistenz.
Beispiel: Für eine Schnittstelle zwischen MES und ERP kann ein automatisiertes Skript regelmäßig Standard-Datensätze ein- und ausgeben, Abweichungen protokollieren und eine automatische Validierung durchführen.
Ein robustes Änderungsmanagement (Change Control) ist obligatorisch. Jede Änderung an einem validierten System — ob Konfiguration, Update, Patch, Schnittstellenmodifikation oder Materialänderung — muss bewertet, dokumentiert, getestet und freigegeben werden.
Nicht jede Änderung erfordert eine vollständige Revalidierung: Der Validierungsaufwand sollte proportional zur Risikobedeutung der Änderung sein. Kritische Änderungen verlangen vollständige Regressionstests und PQ-Tests, kleinere Änderungen können durch gezielte Tests abgedeckt werden.
Während des Betriebs ist ein Monitoringplan erforderlich — z. B.:
Regelmäßige Überprüfung der Audit-Trails und Änderungsprotokolle
Systemhealth-Checks, Backup- und Wiederherstellungstests
Benutzerrechteüberprüfung und Sicherheitschecks
Periodische Review der Systemleistung und Datenintegrität
Trendanalyse zur frühzeitigen Identifikation von Abweichungen
Ferner ist ein Revalidierungszeitpunkt bzw. ein Review-Intervall festzulegen (z. B. jährlich oder bei größeren Systemänderungen).
Beim Rückzug eines Systems ist sicherzustellen, dass alle Daten archiviert werden und rückwirkend zugänglich bleiben (z. B. Migration in ein Archivsystem). Die Datenintegrität und Lesbarkeit müssen gesichert bleiben — aufbewahrt gemäß regulatorischer Vorgaben (z. B. 21 CFR 11, EU GMP, nationale Vorschriften).
Backup-Prozesse, Exportformate (z. B. PDF/A, CSV mit Metadaten), elektronische Signaturen und Zugriffskontrollen sind hierbei kritisch.
Ein mittelgroßes Unternehmen plant, von Papierprotokollen auf einen LIMS-basierten Workflow umzusteigen. Die URS enthält u. a.:
Probenannahme, Barcode-Verfolgung, Automatische Statusupdates
Schnittstellen zu Laborgeräten (z. B. HPLC) und MES
Audit-Trail und Änderungsprotokoll
Rollen- und Rechtesystem
In der Risikoanalyse ergibt sich ein mittleres Risiko für Qualitätsdatenmanipulation (z. B. manuelle Datenkorrektur). Daher wird ein Standardtestpaket (funktional) ergänzt um gezielte Tests zu Schnittstellenfehlern, Datenübernahme und Fehlerbedingungen.
IQ umfasst die Installation aller Server- und Clientkomponenten. In der OQ werden automatisierte Testskripte für Geräteanbindungen, Datenfilter, Validierungsregeln, Sperren und Benutzerrechte eingesetzt. PQ erfolgt mittels realer Sample-Runs über mehrere Tage.
Während des Betriebs wird monatlich ein Audit-Trail-Review gemacht, und jedes Upgrade wird durch Change Control gesteuert.
Finanziell: Der Aufwand für Validierung war ca. 10 % der LIMS-Einführungskosten, aber er entlastete später Wartung und Fehlerkorrekturen erheblich.
Ein Unternehmen betreibt ein MES, das Chargendaten generiert, und ein ERP-System zur Materialverfolgung. Bei jeder Charge werden Soll/Ist-Werte über eine Schnittstelle übertragen. Fehlerhafte Schnittstellen können zu fehlerhaften Stücklisten, falschen Materialzuordnungen oder Rückrufereignissen führen.
Hier wird in der URS festgehalten:
Datenmapping und Transformation
Fehlererkennung und Logging
Rückfallmechanismus (z. B. Wiederholversuch)
Zeitfenster und Systemlatenz
Risikobewertung klassifiziert dies als hohes Risiko. Daher wird ein umfangreicher Testaufwand mit unterschiedlichen Datensätzen inklusive Grenzwerten, fehlerhaften Inputs und Schnittstellenabbrüchen realisiert.
Im OQ werden automatisierte oder semi-automatisierte Tests erstellt, die z. B. bewusst fehlerhafte Felder senden (z. B. ungültige Codes), das Systemverhalten prüfen und sicherstellen, dass Fehler korrekt protokolliert und behandelt werden. In der PQ laufen Parallelbetrieb oder Simulationsläufe mit realem Produktionsdatendurchsatz über mehrere Tage.
Änderungen z. B. an der Schnittstellenstruktur (z. B. neues Attribut oder Feld) werden über Change Control mit gezielten Regressionstests behandelt.
Ein multinationales Unternehmen nutzt ein cloudbasiertes elektronisches DMS, das Dokumente, Freigabeprozesse und Versionierung verwaltet. Der Cloud-Anbieter stellt SLAs zur Verfügbarkeit, Backups und Systemarchitektur bereit.
Wesentliche Herausforderungen:
Verantwortungsteilung: Wer ist verantwortlich für Backups, Systemupdates, Verfügbarkeit, Sicherheit?
Datensicherheit & Verschlüsselung: Daten müssen während Transport und Speicherung (at rest) verschlüsselt sein
Audit-Trail und Änderungsnachweise: Der Anbieter muss Audit-Trail-Funktionen zur Verfügung stellen; das Validierungsteam muss diese prüfen
SLA-Prüfung und Verifizierbarkeit: Die SLA-Kriterien müssen validierbar sein (z. B. Nachweise, Monitoring)
In der URS wird definiert, dass:
Alle Dokumentänderungen inklusive Versionsinformationen protokolliert werden
Elektronische Unterschriften möglich sind
Zugriffskontrollen (z. B. Rollen) bestehen
Die Verfügbarkeit mindestens 99,9 % betragen soll
Das System revisionssicher archiviert
Die Validierung wird risikobasiert umgesetzt: Kernfunktionen (Freigabe, Versionierung, Wiedervorlagen) werden umfassend getestet, Standardfunktionen (z. B. Suche) weniger intensiv. Ein mögliches Audit des Anbieters (Sicherheitsaudit, Penetrationstest) wird eingefordert.
Finanziell führt der Cloud-Ansatz zu reduziertem Infrastrukturaufwand, aber der Validierungs- und Qualifizierungsaufwand (Sicherheitsaudit, SLA-Verifizierungen) darf nicht unterschätzt werden.
Frühzeitige Einbindung von QA, IT, Fachbereich: Die Validierung darf nicht als Add-on gesehen werden, sondern muss von Anfang an im Projekt integriert sein.
Kategorisierung nach Risiko: Nicht jedes System benötigt denselben Validierungsumfang — nutze risikobasierte Ansätze.
Modularisierung und Wiederverwendbarkeit: Standardfunktionen (z. B. Login, Audit-Trail) können als modulare Testpakete wiederverwendet werden.
Automatisierung dort, wo sinnvoll: Testskripte, Regressionstests und Schnittstellentests lassen sich automatisieren, was Zeit und Fehler reduziert.
Klare Traceability: Jede Anforderung sollte mit Tests und Ergebnissen rückverfolgbar sein.
Effizientes Änderungsmanagement: Definiere klare Kriterien, wann Revalidierung nötig ist, und gestalte den Prozess schlank, aber kontrolliert.
Dokumentation und Berichtwesen: Der Validierungsbericht fasst alle Aktivitäten, Abweichungen, Korrekturmaßnahmen und Abschlussempfehlungen zusammen.
Monitoring und Review im Betrieb: Periodische Überprüfung (Trendanalysen, Audit-Trail, Systemchecks) darf nicht vernachlässigt werden.
Training und Awareness: Anwender und Validierer müssen geschult sein — insbesondere in Data Integrity-Prinzipien.
Audit Readiness: Die Dokumentation sollte jederzeit prüfbar sein — gut strukturierte Akten, konsistente Namenskonventionen, Versionierung.
Vendor-Audit und Lieferanten-Qualifizierung: Verlange vom Lieferanten Entwicklungs- und Validierungsdokumentation sowie Nachweise zu Sicherheit, Code-Reviews und Tests.
Einbezug von IT-Sicherheit: Insbesondere bei Cloud, Netzwerken und Schnittstellen müssen Sicherheitsaspekte (z. B. Identitätsmanagement, Verschlüsselung, Netzwerksicherheit) integraler Bestandteil der Validierung sein.
Viele moderne Systeme (z. B. modulare Plattformen, Microservices, SaaS, Cloud-native Anwendungen) werden agil entwickelt und deployt. Traditionelle CSV-Ansätze mit striktem V-Modell können hier an Grenzen stoßen. Die FDA-CSA-Guidance adressiert diesen Wandel und erlaubt eine risikobasierte Validierung mit stärkerer Konzentration auf kritische Funktionen und kontinuierliche Überwachung. (U.S. Food and Drug Administration)
Einsatz von KI-/ML-Komponenten in regulierten Systemen bringt zusätzliche Validierungs- und Erklärbarkeitsanforderungen. Im Bereich regulierter medizinischer Software gibt es Initiativen zur Etablierung von Validierungsprinzipien für AI/ML-Komponenten, wobei das Thema noch aktiv in Diskussion ist. (arXiv)
Mit zunehmend digitalem Datenaustausch (z. B. APIs, Cloud-Speicher, Archive) wird die Sicherstellung von Integrität, Identität und Authentizität komplexer. Beispielsweise kann bei Datenmigration oder Schnittstellenfehlern die Verknüpfung von Metadaten und Daten verloren gehen. Audit-Trails, Checksummen, Hashes, digitale Signaturen, Standardformate (z. B. XML mit Signatur) und Datenvalidierungsregeln sind essenziell.
Beim internationalen Betrieb sind Anforderungen verschiedener Regulierungsbehörden (FDA, EMA, PICS, PMDA, Health Canada, Swissmedic) zu beachten. Beispielsweise kann die Erwartungen an elektronische Signaturen, Archivformate oder Datenaufbewahrungsfristen divergieren — ein harmonisierter Ansatz mit lokalem Compliance-Fokus ist oft erforderlich.
Die behördlichen Anforderungen sind im Wandel: FDA’s CSA-Ansatz, neue Draft-Guidances zu elektronischen Systemen in klinischen Investigationsstudien (2023) oder zu E-Signaturen könnten die Validierungsstrategien weiter beeinflussen. (cov.com)
Validierung von Computersystemen (CSV) ist kein Luxus, sondern essenziell für Produktqualität, Patientensicherheit und regulatorische Compliance in der pharmazeutischen und biotechnologischen Industrie.
Data Integrity (ALCOA+) ist ein fundamentaler Bestandteil und durchgängig zu gewährleisten — insbesondere durch Audit-Trails, Zugriffskontrollen und Rückverfolgbarkeit.
Ein risikobasierter Ansatz erlaubt, den Validierungsaufwand effizient zu gestalten, ohne wesentliche Risiken zu vernachlässigen.
Die Validierung sollte entlang eines Lebenszyklusmodells (z. B. V-Modell) organisiert werden, mit klarer Traceability, Spezifikationen, Tests und Wartungsprozessen.
Änderungsmanagement, Monitoring und Revalidierung sind integraler Teil eines robusten Systemsbetriebs.
Testautomatisierung, modulare Testbibliotheken und effiziente Strategie helfen, Zeit und Kosten zu sparen und dennoch hohe Qualität zu gewährleisten.
Neuere Trends wie CSA, Cloud / SaaS-Modelle und KI/ML-Komponenten erfordern Anpassung der Validierungsansätze und eine stärkere Fokussierung auf kritische Funktionen.
Die Validierungsdokumentation muss jederzeit audit-ready sein, mit konsistenter Struktur, Versionierung und Verantwortlichkeiten.
Eine enge und frühzeitige Zusammenarbeit zwischen Qualität, Fachbereichen, IT und externen Anbietern ist ein entscheidender Erfolgsfaktor.
Wenn Sie möchten, kann ich Ihnen spezifische Checklisten, Vorlagen oder Validierungsstrategien für bestimmte Systemtypen (z. B. LIMS, MES, Cloud-DMS) zur Verfügung stellen. Möchten Sie das?
FDA. (2002). General Principles of Software Validation; Final Guidance for Industry and FDA Staff. Zugriff am 04.10.2025, von https://www.fda.gov/media/73141/download (U.S. Food and Drug Administration)
FDA. (n.d.). Computerized Systems Used in Clinical Investigations: Guidance for Industry. Zugriff am 04.10.2025, von https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/fda-bioresearch-monitoring-information/guidance-industry-computerized-systems-used-clinical-trials (U.S. Food and Drug Administration)
FDA. (2022 Entwurf). Computer Software Assurance for Production and Quality System Software. Zugriff am 04.10.2025 (U.S. Food and Drug Administration)
FDA. (n.d.). Computer Software Assurance: a Risk-Based Approach to Compliant Software Work in Medical Device Manufacturing. Zugriff am 04.10.2025 (outsourcedpharma.com)
ISPE. (2008). GAMP®5: A Risk-Based Approach to GxP Computerized Systems.
QbD Group. (n.d.). A Complete Guide to Computer System Validation (CSV). Zugriff am 04.10.2025 (qbdgroup.com)
Scilife. (n.d.). Complete GAMP 5 guide for GxP compliant computerized systems. Zugriff am 04.10.2025 (scilife.io)
PMC. (2024). The Essential Guide to Computer System Validation in the Pharmaceutical Industry. Zugriff am 04.10.2025 (PMC)
QbD / ComplianceQuest. (n.d.). FDA Software Validation – Template & Guide. Zugriff am 04.10.2025 (datacor.com)
ClinicalLeader. (2023). Breaking Down the FDA’s Latest Guidance on Electronic Systems in Clinical Investigations. Zugriff am 04.10.2025 (clinicalleader.com)
Greenlight Guru. (n.d.). CSV vs. CSA: FDA Software Validation Guidance. Zugriff am 04.10.2025 (greenlight.guru)
OutsourcedPharma. (2023). Decoding The FDA’s Draft Guidance on Computer Software Assurance. Zugriff am 04.10.2025 (outsourcedpharma.com)
Cov.com. (2023). FDA Releases Draft Guidance on Electronic Systems, Records, and Signatures in Clinical Investigations. Zugriff am 04.10.2025 (cov.com)
Eranyona. (n.d.). FDA 21 CFR Part 11 & EU Annex 11 – Computerized System and Software Validation. Zugriff am 04.10.2025 (Eran Yona)
Sware. (n.d.). CSV in Pharmaceutical Industry: The Practical Guide to Compliance. Zugriff am 04.10.2025 (sware.com)
PwC. (2025). How AI is transforming computer system validation. Zugriff am 04.10.2025] (PwC)
Wikipedia. (n.d.). Computerized System Validation. Zugriff am 04.10.2025 (Wikipedia)
Wikipedia. (n.d.). Validation (drug manufacture). Zugriff am 04.10.2025 (Wikipedia)
PMC / National Center for Biotechnology Information. (n.d.). PMC – The Essential Guide to CSV. Zugriff am 04.10.2025 (PMC)