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 Computer-System 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 Computer-System.
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 / 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 (andere Geräte oder IT-Systeme) wie spezifiziert funktioniert.
Wer verlangt was? Regulatorische Anforderungen an CSV
a) Überblick
Die Anforderungen an die Validierung von Computer-Systemen finden sich in:
- FDA 21 CFR part 820.70
- FDA 21 CFR part 11.10
- FDA 21 CFR part 820
- FDA Guidance Document zur Software Validation (das auch Prozesssoftware adressiert)
- FDA Computer Software Assurance for Production and Quality System Software
- ISO 13485 u.a. Kapitel 4.1.6, 7.5.2.1 und 8.2.3 (dazu hier ein eigener Artikel)
- GMP-Richtlinien
- GAMP 5 z.B. zum „risikobasierten Ansatz zum Test von GxP-Systemen“
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
Dieses Guidance Document soll das sehr in die Jahre gekommene FDA Guidance Document zur „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.
Die ohnehin schon große Menge an Vorgaben zur CSV wird noch umfangreicher.
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 Computer-Software 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).
Sie wollen bei Audits glänzen und keine Fragen zur CSV offenlassen?
Dann ist der Auditgarant genau das Richtige für Sie! Hier lernen Sie alles über die Computer System Validierung und die entsprechenden Regularien – und können diese eigenständig durchführen.
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?
- Mindestanforderung: In jedem Fall müssen Sie das „fertige“ Computer-System validieren.
- 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) Computer-System validieren wollen, dann müssen Sie die Anforderungen an das Computer-System 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:
- 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. - 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 Computer-System zu validieren, gehen Sie wie folgt vor:
1. Anforderungen dokumentieren
Wenn die Anforderungen an Ihr Software- bzw. Computer-System nicht oder nicht vollständig dokumentiert sind, holen Sie das nach.
- Benutzer-Produkt-Schnittstellen
- Anzeige: Beschreiben Sie, wie Ihre Benutzer-Produkt-Schnittstelle (GUI = graphical user interface) aussieht und was sie anzeigen muss.
- Algorithmen: Wenn diese Anzeige von Berechnungen abhängt, dann benennen Sie diese.
- Eingaben: Beschreiben Sie, welche Daten die Anwender in welchen Formaten eingeben können. Ebenso, wie sich das System bei Fehleingaben verhalten soll.
- 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.
- Berechtigungen: Ein spezieller Aspekt des oben Genannten ist die Spezifikation von Rollenkonzepten, Autorisierung und Authentifizierung.
- Daten-Schnittstellen
- System-Kontext: Beschreiben Sie, mit welchen Nachbarsystemen Ihr System interagieren soll.
- 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. - Berechtigungen: Beschreiben Sie, wie sich die Nachbarsysteme an Ihrem System authentifizieren und autorisieren.
- 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.
- Laufzeitumgebung
- Hardware: Spezifizieren Sie die Mindestanforderungen an die Hardware (CPU, RAM, Festplatte, Bildschirmgröße, Bildschirmauflösung usw.).
- Betriebssystem: Legen Sie auch das Betriebssystem fest, das Sie mindestens voraussetzen.
- 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,
- welche Daten der Anwender oder das Nachbarsystem eingeben oder übertragen sollen,
- welche Voraussetzungen erfüllt sein müssen, z. B. die Software-Version oder vorhandene Daten betreffend,
- die Prozedur, z. B. in welcher Reihenfolge vorzugehen ist,
- die Pass-/Fail-Kriterien: Welche Werte erwarten Sie? Welche Ergebnisse erfüllen die Anforderungen?
- 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.
Traumjob gesucht?
Atlassian Berater (m/w/d) für eQMS-Lösungen
(remote)
Verstärke unser Team als Atlassian Berater (m/w/d) und unterstütze unsere Kund:innen bei der Einführung und Konfiguration von einem eQMS mit dem Fokus auf Confluence und Jira.
Wir freuen uns auf Deine Bewerbung!
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.
Lesen Sie hier auch die Artikel zum AAMI TIR 36 und zur IEC 80002-2. Beide geben konkrete Hilfestellungen beim Validieren von „Computerized Systems“.
Änderungshistorie:
- 2022-09-15: FDA Guidance Computer Software Assurance for Production and Quality System Software ergänzt
Sehr interessante Darstellung – es fehlt mir ds thema reduierte IQOQ
Wie muss ich dokumentieren, wenn ich 200 workstations in einer Produktion reduziertevalidieren muss
Danke für die kurze Antwort
Sehr geehrter Herr Müller,
danke für die spannende Frage. Die Qualifizierung / Validierung von 200 Workstations können Sie beispielsweise dann abkürzen, wenn Sie
a) nachweisen können, dass eine Validierung eines Systems auf die anderen übertragbar ist (z.B. weil sie identisch sind)
b) die Risiken, die durch fehlerhafte Workstations entstehen können, beherrschbar sind
c) die Validierung automatisieren
Natürlich sind die Antworten nicht „absolut“ zu verstehen. Beispielsweise kann es sein, dass Sie einen Teil der Anforderungen an die Workstations nur bei einer nachweisen müssen, andere Anforderungen sind hingegen bei jeder Workstation zu validieren.
Herzliche Grüße
Christian Johner
>>Es gibt Werkzeuge, mit denen Sie auch Tests der Benutzerschnittstelle semiautomatisiert aufzeichnen und wieder abspielen können.<<
Können Sie einige vorschlagen?
Vielen Dank
Andreas Heertsch
Eine Übersicht finden Sie z.B. hier: https://www.testing-board.com/testautomatisierung-tools/
Die Tools hängen stark vom Testobjekt ab (z.B. Web, stand-alone Software, Mobile Apps, Geräte) usw.
Sehr umfangreiche, übersichtliche Info! – Vielen Dank.
Danke für die sehr übersichtliche Darstellung.
Haben Sie bereits Erfahrungen wie mit Validierung umgegangen wird, wenn z.B. das ERP System als ein Software-As-A-Service eingesetzt wird. Somit liegen z.B. Code Änderungen nicht mehr in der Hand des einzelnen Unternehmens.
Ist mit so einem System eine Validierung überhaupt möglich oder werden wesentliche Themen ausgehebelt. Ich würde mich sehr über Ihre Expertise zu diesem Punkt freuen.
Danke bereits im Voraus.
Das ist ein sehr wichtiger Punkt, den Sie adressieren, Herr Stenske!
Bei einem SaaS-Konstrukt müssen man genauso sicherstellen, dass die (für das QM-System / Produkt) entscheidenden Anforderungen an die Software erfüllt sind. Hier sind regelmäßig automatisierte Regressionstests und eine Qualitätssicherungsvereinbarung (QSV) mit dem SaaS-Anbieter hilfreiche Werkzeuge. Die QSV könnte auch verpflichten, Änderungen zu melden. Bitte bedenken Sie, dass jetzt zusätzlich did Anforderungen der ISO 13485 an Lieferanten und ausgelagerte Prozesse zu beachten sind.
Beste Grüße, Christian Johner
Tolle Ausführungen.
Aber wie ist es denn eigentlich mit Access-Datenbanken, deren Ziel ist, ein zentrales Erfassungssystem zu sein? Der Re-Zertifizierungsauditor meinte, man müsse diese SW validieren und hat eine Abweichung platziert. Z.Bsp. Fehlermeldungen werden über eine Formular-Garnitur mit gedruckten, vordefinierten Fehlernummern erfasst und abgearbeitet bis und mit Wirksamkeitsüberprüfung und CAPA. Eine Kopie der Garnitur geht an eine Person zum Erfassen der Meldung in der DB. Im anderen Fall ein Access-Erfassungssystem zur Erfassung von Änderungen, die aber ebenfalls separat auf einem Änderungsformular erfasst und abgearbeitet wird. Alle QM-sowie Kundenvorgabe-Dokumente sind in der DB mit V-Nr. und Freigabedatum erfasst. Allerdings werden alle internen QM-Dokumente handschriftlich auf der Hardcopy selbst geprüft/freigegeben. a) bin ich der Meinung, dass solche Tools nicht validiert werden müssen und b) wenn doch, dann mache ich den Vorstoss zum Wechsel auf Excel-Tabellen. Übrigens, es gibt nur gerade mal 2 von 14 Mitarbeitenden, die Zugriff auf diese Access-DB haben.
Vielen Dank für Ihre Inputs.
Wenn Sie die Aufzeichnung defacto als Hardcopy vorliegen haben und das Ihre gültigen Dokumente sind, dann würde ich die Datenbank gar nicht erwähnen. Sie wäre dann wahrscheinlich wie ein Textverarbeitungsprogramm zu klassifizieren und zu bewerten. Die Anzahl der Mitarbeitenden ist für die Entscheidung, ob eine SW zu validieren ist, unerheblich. Mein Tipp: Entscheidend für den Validierungsaufwand sollte das Risiko sein.
Sehr geehrter Herr Prof. Johner,
wie verhält es sich mit der Validierung eines Ticketing oder Requirement-Systems?
Wir haben JIRA im Einsatz (Erfassung von Requirements, Entwicklungsaufgaben) & somit liegt der Code auch hier nicht in unserer Hand und der Hersteller wird keine QSV abschließen wollen.
Gibt es dafür einige Tipps in der Vorgehensweise?
Beste Grüße
Gerald Fruh
Sehr geehrter Herr Fruh,
danke für Ihre spannende Frage!
Die erste Möglichkeit wäre, die selbstgehostete Version von JIRA zu nutzen. Die zweite Möglichkeit bestünde darin, mit automatisierten Tests sicherzustellen, dass die relevanten Funktionen weiterhin gegeben sind.
Es ist in beiden Varianten nicht notwendig, über den Source-Code zu verfügen. Eine Validierung kann auch anderweitig möglich sein.
Mit den besten Grüßen, Christian Johner
Hallo Herr Fruh und Herr Johner,
Die Benutzung von Tools wie JIRA, Confluence, GIT (oder andere wie redmine usw.) werden in der Regel „intern“ zur Erstellung von Source Code benutzt (entweder als Teil des MedDev oder zur Herstellung usw.). Prinzipiell kann man aber Confluence auch als eQMS benutzen usw. – die möglichen Einsätze sind sehr breit (JIRA als CAPA system).
Die Validierung von Tools (wie auch PLM – z.B. PTC/Windchill) basiert grundsätzlich auf der Integration in das Qualitätssystem (ISO 13485/21 CFR Part 820) – d.h. in die tatsächlichen Prozesse. Wenn wir z.B. requirements und Entwicklungsaufträge inkl. Release Management in Jira abbilden, dann wäre das nach Part 820 der „Design Input“, ggf. „Design Validation“ und „Design Output“, bzw. Teil des Design History Files / Design Transfer. Man sollte hier nicht eine „plumpe“ Art „Pharma“ Validierung machen (IQ;OQ,PQ), sondern gegen den „intended use“ validieren – und das sind die Business Prozesse.
Interessanterweise gibt es ja auch Add-On Apps für JIRA und Confluence, z.b. Workflow Management und e-Signature, die einen Einsatz in unserem Bereich leicht ermöglichen.
Vielleicht darf ich in diesem Zuge auf einen Event verweisen, den wir am 8. Februar 2018 in Stuttgart halten wollen. Dort haben wir Experten zu diesem spannenden Thema eingeladen:http://www.ccs-innovation.com/how-to-validate-software-development-tools-used-for-gxp-and-meddev/
Bitte verstehen sich das nicht als Werbung – aber das Thema ist relativ breit.
Im Herbst ’18 wollen wir dann einen Event über PLM tools abhalten – starten aber mit SDLC tools.
Freundliche Grüße
Hallo,
vielen Dank für die vielen Info’s. Mich würde interessieren, wie es sich mit der qual. von PC’s verhält, die „Oberkante“ Betriebssystem von einem dritten ausgeliefert werden. Kann ich dann dort den Status quo mit einer IQ qualifizieren oder muss ich den komplett platt machen und bei der Windows Installation, plus Office, plus SAP plus plus jedes Updates usw. beginnen? Die Qualifizierung des fertig Installierten PC’s wäre ja retrospektiv anzusehen. Am Ende muss dann nur noch die eigentlich benötigte Software, für z.B. ein Analysegerät, qualifiziert installiert werden.
Vielen Dank
Es gibt keine Anforderung, wo Sie mit der CSV beginnen. Es ist nicht unüblich, auf bereits existierenden PCs (mit Software) die neue Software zu installieren und zu validieren. Über die Pflicht zur Re-Validierung bei Updates kann nur anhand des Risikomanagement im Einzelfall entschieden werden.
Die Validierung sollte nicht retrospektiv erfolgen, sondern vor der ersten Nutzung. Die Tatsache, dass es den fertig installierten PC gibt, macht es nicht zu einer retrospektiven CSV.
Hallo zusammen,
wenn ich richtig Informiert bin ist es im Bereich der Prozessvalidierung durchaus legitim zu sagen, dass eine Validierung nicht durchgeführt werden muss, sofern man das Ergbnis des Prozesses erneut verifiziert und somit sicherstellt, dass alles den Erwartungen entspricht.
Gibt es bei der CSV einen ähnlichen Ansatz und wenn ja auf welchen Regularien könnten man diesen Schritt begründen?
Beste Grüße
S.Marl
Die ISO 13485 nennt keine Ausnahme, erlaubt aber risikobasiert vorzugehen. Mit einer entsprechenden Begründung würde das Ihrem Vorschlag fast entsprechen.
Bzgl. Frage 15 – Herr Marl.
Dies muss man individuell bewerten – ist aber wie Herr Johner geantwortet hat, selbstverständlich möglich. Ich finde es manchmal unglücklich, wenn man Prozesse und „Computer“ logisch von einander trennt. Das kann manchmal zu Problemen führen. Grundsätzlich wäre ein „Computer“ ein Teil eines Prozesses – er wäre Mittel zum Zweck. Nehmen wir an, Sie haben einen Herstellschritt (CNC Maschine) = Ergebnisse Platte mit 10 mm Dicke. Danach machen Sie eine 100 % Verifikation jeder Platte (ggf. Messschieber oder besser automatisiert). Das Ergebniss muss so oder so richtig aufgezeichnet werden und wird teil des Master Records. Der Herstellschritt wäre prinzipiell durch die 100 % Verifikation „validiert“. Wobei Sie natürlich das richtige Programm an der CNC Maschine gewählt haben müssten (QM System – „Device Master Record“ = Vorgabe) und die automatische Dickenmessung (SW = validiert) sein sollte. Dabei validieren wir aber nicht wirklich nur das SW Objekt – dass eine CNC Maschine funktioniert, stellen wir nicht in Frage durch die Validierung. Ich sage das nur, weil ich es teils erlebe, dass man dann funktionale Tests macht, was nicht notwendig ist, sondern das immer im Prozesskontext und zur Dokumentation (Vorgabe) und Aufzeichnung (Nachweis) sehen sollte.
Hallo Herr Prof. Dr. Johner,
können Sie „Änderung an der Software“ genauer definieren? D.h. ist eine Validierung auch erforderlich, wenn nur Fehlerbehebungen als „Hotfix“ eingespielt werden oder bezieht sich Änderung nur auf neue oder geänderter Funktionalität der Software?
Genau genommen müsste man dann ja jedes Windows-Update validieren, da kommt man ja dann zu nichts anderem mehr!
viele Grüße
Jean
Sie finden hier Beispiele für Software-Changes. Wenn das nicht ausreicht, haken Sie gerne einfach nach.
Hallo Herr Prof. Dr. Johner,
vielen Dank für die Beispiele. In meinem speziellen Fall geht es aber nicht un so etwas kritisches wie Software in Medizinprodukten sondern z.B. um eCTD-Authoring Tools und Dokumentenmanagementsysteme, die wir einsetzen, um unsere Zulassungsdossiers zu erstellen, zu verwalten und einzureichen.
Hier geht von einem Fehler also nicht unmittelbar eine Gefahr für den Patienten aus. Sind hier die Regeln genauso streng?
viele Grüße
Jean
Sehr geehrter Herr Oed,
die Regeln sind eigentlich die gleichen. Wie Sie aber schreiben, sind die Risiken geringer. Daher wird es eher Änderungen geben, die keiner Re-Validierung des Systems bedürfen.
Was Sie also machen sollten wäre, alle Änderungen zu erfassen, auf mögliche Auswirkungen auf die Konformität Ihres QM-Systems und auf die Sicherheit der Patienten zu bewerten und dann fallweise über eine Re-Validierung zu entscheiden und all dies zu dokumentieren.
Die Art der Änderung wird bei dieser Entscheidung nicht der wesentliche Parameter sein. Ein kleiner Hot-Fix kann ebenfalls zu großen Auswirkungen führen. Wenn Ihre Analyse zum Ergebnis kommt, dass dies im konkreten Fall nicht passieren kann, dann können Sie sich die erneute Computerized Systems Validation CSV ersparen.
Christian Johner
Lieber Herr Prof. Johner:
Leicht Off-topic, aber doch passend, hätte ich eine Frage zu EU GMP Anhang 11 „computerised systems“:
4.5 The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately.
Da frage ich mich nämlich, was „an appropriate QMS“ sein mag. Wir sind eine kleine Medizinproduktefirma und kaufen für viel Geld ein System ein, welches GMP-konform sein soll. Beim Audit durch unsere benannte Stellen (ISO 13485:2016 und MDR) möchte ich da wenig Probleme bekommen, daher werden wir den Zulieferer auditieren fahren. Aber nach welchem Regelwerk macht man das am besten?
Liebe Grüße
Wolfgang Kürschner
Sehr geehrter Herr Kürschner,
das einfachste wäre es, die IEC 62304 als Basis zu nutzen. Vielleicht hat der Zulieferer auch ein QMS. Das würde helfen.
Ob wirklich ein Audit notwendig ist, würde ich risikobasiert entscheiden. Im einfachsten Fall wäre die vom Zulieferer erzeugte Dokumentation (z.B. Anforderungen, Tests usw.) ausreichend, um das Einhalten von Lebenszyklusprozessen vermuten zu lassen.
Beste Grüße, Christian Johner
Sehr geehrter Herr Prof. Johner,
wir setzen Minitab bei uns ein. Die Software wurde einmalig validiert.
Als Betriebssystem am Client wird Windows 10 verwendet.
Muss ich nun bei jedem Sicherheitsupdate vom Betriebssystem eine Revalidierung durchführen? Muss ich vor jeder Updateeinspielung eine Bewertung des Updates durchführen?
Welche Vorgehensweise würden Sie empfehlen.
Beste Grüße Volker Grathwol
Sehr geehrter Herr Grathwol,
danke für die spannende Frage! Ohne genaue Kenntnis des Kontexts insbesondere der Risiken lässt sich diese nicht beantworten. Man würde auch nie die Software ingesamt validieren, sondern die Teile (Anforderungen), die relevant sind.
In Unkenntnis der genauen Situation würde ich vermuten, dass eine Revalidierung bei einem Betriebssystem-Update nicht notwendig ist (im Gegensatz zum Pharmabereich), kann es aber nicht abschließend beurteilen.
Viele Grüße, Christian Johner
Sehr geehrter Herr Prof. Johner,
vielen Dank für Ihre Antwort.
Wie Sie richtig angemerkt haben, haben wir nur die von uns verwendeten Funktionen aus Minitab validiert.
Jedoch muss ich noch einmal bezüglich den Updates von Windows 10 nachfragen.
Heißt dies nun, dass wenn die von uns verwendete Funktion von Minitab bei Fehlfunktion ein nicht akzeptiertes Risiko darstellen würde, müssten generell die Sicherheitsupdates vom Betriebssystem verhindert bzw. anschließend erneut die verwendeten Funktionen von Minitab revalidieren.
Viele Grüße Volker Grathwol
Sehr geehrter Herr Grathwol,
wenn ein Windows-Update eine Fehlfunktion provozieren könnte, die zu nicht akzeptablen Risiken führt, dann müssen Sie Maßnahmen ergreifen. Ob das Verhindern eines Betriebssystem-Updates die richtige Maßnahme ist, kann ich nicht beurteilen. Ich würde vermuten, dass die Risiken, die durch diese Maßnahme entstehen, höher sind, als die Risiken ohne die Maßnahme. Damit würde man wahrscheinlich eine andere Maßnahmen wählen.
Wenn Sie offline weiter diskutieren wollen, schreiben Sie mir gerne eine E-Mail.
Beste Grüße, Christian Johner
Sehr geehrter Herr Prof. Johner,
in der Rubrik „CSV: Wer verlangt was? Regulatorische Anforderungen“ im Abschnitt „a) Überblick“ ist das Kapitel 7.5.2.1 als Basis für CSV Anforderungen genannt. Hier hat sich sicherlich ein Typo eingeschlichen, Sie meinten sicherlich Kapitel 7.5.6.
LG
Hallo,
ich würde gerne wissen, wann die Laptops und die zugehörigen Zubehöre, welche in ein Pharmaunternehmen überall an die MA zur eigenen Verwendung zur Verfügung gestellt werden, GxP relevant sind, Z.B: Qualität-, Herstellung-, Logistik-, Labor-, Beschaffung-, IT- Abteilung usw.
Hier meine ich Qualifizierung der Geräte und Validierung der Software.
Wie relevant ist CSV in der Pharma?
Vielen Dank im Voraus
Elena Chis
Liebe Frau Chis, vielen Dank für Ihre spannende Frage.
Die Entscheidung, ob ein Computerisiertes System GxP relevant ist findet ganz am Anfang statt und wird meist durch Entscheidungsfragen angeleitet. Ein Beispiel, wie das in der Medizintechnik mit wenigen Fragen gehandhabt werden kann, zeigen wir in unserem Artikel zum AAMI TIR 36: Validierung von Prozesssoftware. Einfach gesagt: Findet in einem der von Ihnen genannten Bereiche eine Tätigkeit statt, die unter GxP fällt und werden mit dem System diesbezüglich qualitätsrelevante Aufzeichnungen verwaltet, dann sind die Rechner zu qualifizieren und die Software sollte validiert werden. In grossen Organisationen werden dazu meist Konzepte bzgl. Images implementiert, die einmal komplett validiert und dann ausgerollt werden können. Damit kann die Validierung auf mehrere Systeme übertragen werden, evtl. sollten beim Ausrollen einer bestimmten Software für bestimmte Nutzer Prüfungen wiederholt werden (risikobasierter Entscheid).
CSV ist in der Pharmawelt in Europa schon sehr lange ein Thema, ein Muss, entsprechend relevant und wird sehr aufwändig betrieben. Z.B. stammt auch die ganze GAMP Initiative aus diesem Umfeld und wurde 1991 ins Leben gerufen. Die Betrachtungen rund um das Thema Datenintegrität rücken aktuell in den Fokus, was z.B. auch durch den kürzlich veröffentlichten PIC/S Leitfaden zu Datenintegrität zum Ausdruck gebracht wird (PIC/S Guidance on Data Integrity).
Herzliche Grüsse
Urs Müller
Sehr geehrter Herr Müller,
Herzlichen Dank für den ausführlichen Antwort an meinen ersten Anfrage.
Ich würde gerne weiter wissen, wie ist einen Umzug für den GxP relevanten Computer Systeme zu betrachten?
Hier sprechen wir über einen neuen Serverraum mit mehr als drei Lieferanten ( Boden, Türen, Wände, Clima Geräte usw).
Wie ist den Serverraum zu Qualifizieren in diesem Fall? IQ-OQ zusammen mit den Lieferanten vor Ort durchzuführen und danach PQ?
Wie sieht aus mit den schon qualifizierten Geräten nach dem Umzug? Sollten wir die Requalifizieren ( Server, Drucker, PCs) oder ist nicht notwendig?
Vielen Dank im Voraus
Elena Chis
Liebe Frau Chis,
Vielen Dank für Ihre interessante Frage. Bei Umzug von Infrastruktur gilt generell, dass diese requalifiziert werden sollte. Den Umfang der Requalifizierung der IT-Infrastruktur könnten Sie risikobasiert festlegen und damit beispielsweise OQ Aktivitäten verringert werden.
Bzgl. der Qualifizierung des Serverraums sollten Sie vor allem die Aspekte Umgebungsbedingungen (z.B. Temperatur, Verkabelung, Stromversorgung) und physische Sicherheit betrachten. Das betrifft IQ Aspekte. Sie könnten für den Serverraum ein IQ bzw. kombiniertes IQ/OQ Protokoll erstellen. Der ISPE Leitfaden zu IT-Infrastruktur erwähnt Qualifizierung der Räumlichkeiten nur in der IQ. Anschliessend sollten Sie regelmässige Prüfungen bzgl. der Überwachung der Umgebungsbedingungen und der Zugangsberechtigungen vorsehen.
Herzliche Grüsse
Urs Müller
Hallo Herr Müller, insgesamt find ich Ihren Artikel wirklich sehr hilfreich. Vor allem um Kolleg (inn)en, die nicht so mit der Thematik vertraut sind einen klaren Überblick zu geben.
Leider gibt es auch etwas was mich stört, zum einen: Die Vermischung der Begriffe Validierung und Qualifizierung (auch wenn die FDA auch Prozesse qualifiziert haben möchte).
Natürlich gehören DQ/ IQ/ OQ/ PQ zur Validierung dazu (ohne qualifizierte „Geräte“ kann kein Prozess validiert werden. Aber das führt bei den Kolleg (inn)en oft zu Verwirrungen.
Das andere ist, dass es vielen schwerfällt die „Validierung der Anwendung der Computersoftware im Qualitätsmanagementsystem“ von der Validierung von Software als Medizinprodukt zu unterscheiden. Und hier muss ich als QMB immer aufs Neue Überzeugungsarbeit leisten, dass wir als Medizinprodukte-Hersteller die von uns genutzte CS bzw. Software für unsere Prozesse auch validieren müssen.
Wie gesagt insgesamt ein sehr guter Artikel.
Vielleicht haben Sie ja Tipps für mich.
Vielen Dank und viele Grüße,
Angelika Seiler
Liebe Frau Seiler,
Besten Dank für Ihre Rückmeldung, die ich gerne für eine kommende Überarbeitung des Artikels aufnehme. Eine scharfe und eindeutige Trennung zwischen den Aktivitäten Qualifizierung und Validierung in Bezug auf Computerisierte Systeme bzw. generell Equipments ist meines Erachtens auch mit dem referenzierten GMP-Leitfaden nicht so einfach ableitbar. IQ/OQ/PQ werden quasi als Qualifizierung zusammengefasst, dann folgt die Prozessvalidierung, und trotzdem wird im Text laufend von Qualifizierung /Validierung geredet.
In unserer täglichen Arbeit führen wir die Prozessvalidierung bei Medizintechnikherstellern allerdings mit den Schritten IQ/OQ/PQ durch. Nach meiner Erfahrung trifft man verschiedenen Unternehmen verschiedene Einordnungen an, bis wann qualifiziert wird und ab wann validiert wird. Schlussendlich wende ich den Leitsatz an: Infrastruktur soll qualifiziert sein, Prozesse validiert – wichtig ist, dass das richtige getan wird, wie das benannt wird und mit welchen Arbeitsanweisungen das erschlagen wird, ist zweitrangig.
Im Kontext von Software im Rahmen des QM-Systems vermeide ich persönlich die Begrifflichkeiten IQ/OQ/PQ. Man trifft CSV Prozesse an, die computerisierte Systeme tatsächlich auch in diesem Schema betrachten, der WHO Leitfaden beschreibt z.B. die Tätigkeiten in IQ/OQ/PQ eingeordnet und einen entsprechenden Prozess dazu. In ISO 80002-2 und GAMP 5 werden die Aktivitäten rund um CSV bewusst nicht in IQ/OQ/PQ eingeordnet: Die IT/Software Welt benutzt ihre eigene Terminologie. GAMP 5 hat beispielsweise den Anspruch, IT SME nicht mit den Aktivitäten der Prozessvalidierung zu verwirren. Entsprechend reden wir vom Installations- und Konfigurationstest, dem System- bzw. Funktionstest und dem Abnahmetest. Natürlich ist es nun so, dass Sie CSV relevante Aktionen im Qualifzierungs- (oder Validierungs)-prozess von Equipment unterbringen können. Dann würden Sie Installationstätigkeiten in der IQ und ggf. Funktionsprüfungen wie Export von Daten, Benutzerverwaltung etc. z.B. in speziellen Kapiteln in der IQ prüfen und nicht in einen separaten CSV Prozess abspringen – erst bei komplexeren Systemen oder z.B. bei Sondermaschinen. Für die Qualifizierung von IT Infrastruktur ist eine Einordung in IQ/OQ allerdings durchaus wieder nachvollziehbar.
Was den Begriff Validierung angeht ist es leider so, dass an verschiedenen Stellen validiert wird: mindestens in Produktentwicklung, Prozessvalidierung, CSV. Das hat mit der Definition des Begriffs Validierung zu tun, den nicht die Medizintechnik für sich alleine beanspruchen darf und auch nicht als etwas einmaliges verstanden werden darf. Konkret: ISO 9000 definiert den Begriff als „Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind“. Somit: Auch wer z.B. ein ISO 9001 QM System hat, muss validieren. Kommt dazu, dass Validierung im Kontext der Produktentwicklung als auch der CSV für Medizintechnikhersteller doppelt belegt ist (Tätigkeit am Ende und Tätigkeiten bis zu diesem Ende). Ich würde entsprechend durch die Ergänzung der jeweiligen Validierung klar machen, wo wir uns befinden (Produktvalidierung, Computerized Systems Validierung, Prozessvalidierung, etc.). Eine Diskussion darüber, ob denn nur am Ende der Produktentwicklung validiert wird, ist im Sinne der Definition vom Begriff Validierung hinfällig und entsprechend eindeutig beantwortbar: Alles, was eine Zweckbestimmung und Anforderungen hat, kann validiert werden.
Melden Sie sich gerne und jederzeit bzgl. spezifischer Fragen – wir stehen Ihnen gerne mit Rat und Tat zur Seite.
Mit nochmaligem Dank und besten Grüssen
Urs Müller
Hallo,
vor Einsatz einer SW in bestimmten Bereichen (z.B. im Zsh. mit der Herstellung von Medizinprodukten) sind diese einer CSV zu unterziehen. Bei Änderungen an der SW sind diese Änderungen einer Teilvalidierung oder ggf. nach Umfang der Änderung einer vollständigen CSV zu unterziehen. Wenn ich also nur SW nutzen darf, welche nachweißlich (z.B. über einen gültigen Validierungsreport) validiert wurde, muss man dann eine nach GAMP 5 computersoftware-validierte SW noch einmal zusätzlich regelmäßig überprüfen, ob die SW neu validiert werden muss? Und wenn ja, welche Kriterien würden sie dafür zu Grunde legen? Denn das Thema „Änderungen an der SW“ dürfte ja durch den ursächlichen Validierungszwang vor Einsatz ja gar keine Rolle spielen, oder?
Vielleicht haben Sie ja einen konstruktiven Ansatz für mich.
Vielen Dank und viele Grüße,
Dietmar Freund
Lieber Herr Freund,
Vielen Dank für Ihre spannende Frage. Das eigentliche Hauptkonzept von GAMP 5 ist die Beschreibung eines Lebenszykluskonzepts für Software, mit allem was für ein reguliertes Unternehmen im Pharma oder Medizintechnikbereich angemessen ist (Kapitel 1.4 von GAMP 5 V2 erwähnt auch Medizintechnikhersteller). GAMP 5 ist also eine Sammlung von Vorschlägen von Aktivitäten, Aufgaben und damit verbundenen Prozessen, die von der Idee bis zur Stilllegung eines computerisierten Systems durchgeführt/aufgesetzt werden können, um die Anforderungen an Validierung, Validierung nach Änderung oder die Datenintegritätsanforderungen eines 21 CFR Part 11 zu erfüllen. Das heisst: GAMP 5 sieht explizit vor, dass Systeme geändert werden. Wenn eine Software nach GAMP 5 klassifiziert und initial validiert worden ist, wurde nur der Teil Validierungsumfang wie beschrieben z.B. in Anhang M4 angewendet, das würde ich aber nicht als GAMP 5 Validierung bezeichnen.
GAMP 5 V2 erwähnt z.B. Change Management und CAPA in Kapitel 4.3 – Operation. Explizit wird zum Change Management in Kapitel 4.3.4 folgendes erwähnt:
„The process should allow the rigor of the approach, including the extent of documentation and verification, to be scaled based on the nature, risk, and complexity of the change, by application of critical thinking“
Ob eine Änderung nötig ist, kann sich beispielsweise auch aus dem Incident- und CAPA Management oder dem Monitoring des Systems ergeben.
Anhang O6 in GAMP 5 beschreibt den Änderungsprozess. Im Risk- und Impact Assessment bewerten Sie den Einfluss der Änderung auf Patientensicherheit, Datenintegrität und Produktqualität. Ich würde anschliessend die von der Änderung betroffenen Funktionen identifizieren und via der Konfigurations- oder Designspezifikation sicherstellen, wo softwaretechnisch Module abgegrenzt sind, dass ich sicher sein kann, dass deren Funktionalität nicht durch die Änderung betroffen ist.
Falls Ihre Frage darauf abzielt, dass eine Software initial und nach Änderungen immer validiert werden muss und somit eine Bewertung nicht nötig ist, würde ich einmal einen Blick in Anhang O8 in GAMP 5 V2 werfen. Im pharmazeutischen Umfeld müssen Sie diese periodische Prüfung zwingend durchführen und ich würde dringend empfehlen, dass auch in Organisationen zu tun, die nicht unter den GMP Annex 11 fallen. Ein Ergebnis der periodischen Prüfung kann sein, dass erneut Validierungstätigkeiten durchgeführt werden. Verzichten Sie auf periodische Prüfung, kann Revalidierung Ihr Mittel der Wahl sein. Ggf. bezeichnen Sie auch die periodische Prüfung als Revalidierung – ich habe diesbezüglich in Organisationen schon Verschiedenes angetroffen – wichtig ist an der Stelle, das Richtige zu tun, die Benennung ist sekundär. GAMP 5 V2 erwähnt in Anhang M12 unter anderem, dass durch „Criticial Thinking“ die Häufigkeit von periodischen Prüfungen reduziert und Revalidierungen unnötig werden können. Grundlage dafür ist, dass Sie Ihre Prozesse, den Einfluss der Systeme auf Patientensicherheit, Datenintegrität und Produktqualität kennen, bewertet und dokumentiert haben.
Fragen Sie gerne nach, wenn ich Ihre Fragen nicht verstanden habe.
Freundliche Grüsse
Urs Müller
Hallo Herr Müller,
vielen Dank für die präzise Einordnung des Themas in die grundsätzlichen Zusammenhänge GAMP 5. Unstrittig sind wir der gleichen Meinung, dass eine SW vor Nutzung initial validiert wird sowie ab da einem Änderungsmanagement unterworfen ist. Änderungen können aus verschieden anderen Prozessen initiiert werden. Gleichzeitig ist der periodische Review des Validierungszustandes einer SW zwingend erforderlich. Meine weitergehende spezifische Frage ist nun, auf welche sinnvollen Kriterien sich dieser periodische Review begründet. Sollte es einzig und alleine nur die Bewertung durchgeführter Änderungen an der SW sein, erschließt sich mir dieser Ansatz nur, wenn ich im Validierungsreport festgelegt habe, bestimmte (z.B. nicht signifikante Änderungen) auch ohne Validierung in der SW umsetzen zu dürfen (wenn das überhaupt regulatorisch abgedeckt ist). Sehen sie daher für die Entscheidung zu der Notwendigkeit der Revalidierung einer SW innerhalb dieses periodischen Reviews noch andere Kriterien, welche man in dieser Entscheidung einfließen lassen kann oder sogar muss?
Ich denke hier z.B. an den Aspekt wie lange eine SW Version bereits im Einsatz ist und wie viele nachfolgende upgrads vom Anbieter bereits (bisher nicht genutzt) mit z.B. welchen bugfixes, neuen Features oder anderen verbesserten Änderungen zur usibility vorliegen. Wäre das sinnvoll? Und würden Ihnen da noch andere Aspekte einfallen oder wichtig erscheinen?
Vielen Dank
Dietmar Freund
Guten Abend Herr Freund,
Besten Dank für das Nachfassen. Verpflichtende Vorgaben gibt es für uns in der Medizintechnik wie erwähnt nicht. So gesehen dürfen wir das also „risikobasiert festlegen“. Also, nehmen wir die Best Practices zur Hand, die uns zur Verfügung stehen: ISO 80002-2 und GAMP 5. Zusammenfassend kann daraus abgeleitet werden, dass regelmässig Bewertungen durchgeführt werden sollen bzgl. bekanntgewordener Fehler, Kompatibilität zu anderen Systemen und Infrastruktur, Änderungen an der Zweckbestimmung, IT Sicherheit, Nutzungsverhalten. Wie umfangreich nun eine Änderung auf die Validierung bzw. den validierten Zustand wirkt, dazu kann in GAMP 5 eine Aussage im Anhang O6 angezogen werden. GAMP 5 schlägt vor, unterschiedliche Typen von Änderungen zu definieren. Z.B. könnte ein Typ „System Administration Change“ definiert werden, der mit Systemverwaltungsarbeiten verknüpft ist, damit nicht jedes Mal der ganze Änderungsprozess durchlaufen werden muss. Für „Routine Changes“ sagt GAMP 5
„A record of the change should be maintained, including any verification tasks required to confirm successful implementation of the change“.
Im gleichen Kapitel empfiehlt GAMP 5 als Teil der periodischen Prüfung auch Patching und Vulnerability Monitoring zu prüfen. ISO 80002-2 empfiehlt für den Einfluss einer Änderung vor- und nachgelagerte Aktionen miteinzubeziehen. Punkte in der Prüfung, die direkt mit Änderungen verbunden sein können, habe ich oben bereits erwähnt, ergänzen könnte man das z.B. um Bewertung von Informationen zum SW Hersteller, um z.B. sicherzustellen, dass Verträge noch aktuell sind und er weiter am Markt bleibt. Auch das kann zu einer Änderung führen, wenn Sie sich z.B. entscheiden müssen, ein neues System einzuführen, weil der Hersteller vom Markt zu verschwinden droht.
Somit dürfen Sie innerhalb Ihrer Organisation selbst festlegen, unter welchen Umständen Sie welchen Umfang von Validierungstätigkeiten durchführen. Sie können unterschiedliche Arten von Änderungen definieren, die bestimmte Aspekte bereits abdecken, Sie dürfen den Umfang einer umfangreicheren Validierung nach Änderungen selbst festlegen. Wichtig ist, dass Sie Kontrolle über Änderungen an einem System haben. Im Falle von Standardänderungen sollte mindestens der Änderungsantrag vorliegen, in dem Sie alle Bewertungen zum Einfluss der Änderung festhalten. Die Revalidierung bzw. Validierung nach Änderung wäre damit abgeschlossen. Ob Sie das gewissenhaft so machen können, hängt vom Risiko des Systems auf Patienten/Anwender, Datenintegrität und Ihr Unternehmen/allgemeine Produktqualität ab, was wiederum ebenfalls durch Sie bewertet wird.
Freundliche Grüsse
Urs Müller