| Inhaltsübersicht |
|---|
| CSV: Was ist das? » |
| Abgrenzung zu IQ, OQ, PQ » |
| Abgrenzung zu Software-Validation » |
| Praxistipps » |
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).
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.
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
Kategorien: Regulatory Affairs
Tags: Software-Qualitätssicherung bei Medizinprodukten, Software-Testing: Die Forderungen der IEC 62304 und FDA erfüllen
32 Kommentare
Hinterlassen Sie einen Kommentar
Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.
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