 |
Computer System Validation CSV
Mittwoch 5. April 2017
| Inhaltsübersicht |
|---|
| CSV: Was ist das? » |
| Abgrenzung zu IQ, OQ, PQ » |
| Abgrenzung zu Software-Validation » |
| Praxistipps » |
Computer System Validation CSV: Was ist das?
a) Erste Definition und Ziel der CSV
Computer System 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].
Validation (Bildquelle: iStock)
b) Was ist unter Validierung in diesem Kontext 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) Computer System 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) Computer System Validation versus Software Validation
Die Computer System Validation umfasst prinzipiell sowohl Computer Hardware als auch Computer Software. Speziell bei Standard-Hardware wie PC-basierten Systemen entspricht die Computer System 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.
CSV: Wer verlangt was? Regulatorische Anforderungen
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)
- 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) 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.
e) GAMP 5
Der GAMP 5 fühlt sich ebenfalls für Medizinproduktehersteller als anwendbar. 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).
Computer System Validation CSV: Wie macht man das?
Als erstes sollten Sie sich klarmachen: welche Anforderungen an die Computer System 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 die Nutzer, die Betreiber und der 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 roter fetter 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 „Schritt für Schritt Anleitung“.
Der vollständige Entwicklungsprozess
Wenn Sie im Sinn des FDA Software Validation Guidance Documents „validieren“, dann werden Sie den kompletten Entwicklungsprozess dokumentieren wie
- 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.
Computer System Validation: Schritt für Schritt Anleitung
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 wie 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 Computer System Validation:
- Systematisches Ableiten von Testdaten: Die Testdaten sollten Sie sich nicht einfach ausdenken, sondern anhand von Blackbox-Test-Methoden 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, d.h. bei denen Fehler zu den höchsten Risiken führen.
- Regression: Die Computer System Validation 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“.
Kategorien: Regulatory Affairs
Tags: Software-Qualitätssicherung bei Medizinprodukten, Software-Testing: Die Forderungen der IEC 62304 und FDA erfüllen
Montag 10. Oktober 2016 um 10:05
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
Montag 10. Oktober 2016 um 11:50
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
Mittwoch 5. April 2017 um 14:50
>>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
Mittwoch 5. April 2017 um 22:03
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.
Donnerstag 6. April 2017 um 07:14
Sehr umfangreiche, übersichtliche Info! – Vielen Dank.
Freitag 28. April 2017 um 20:05
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.
Samstag 29. April 2017 um 08:53
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
Dienstag 14. November 2017 um 11:50
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.
Dienstag 14. November 2017 um 17:07
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.
Mittwoch 22. November 2017 um 13:41
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
Mittwoch 22. November 2017 um 20:22
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
Donnerstag 28. Dezember 2017 um 12:17
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
Mittwoch 24. Januar 2018 um 15:40
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
Donnerstag 25. Januar 2018 um 17:48
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.
Dienstag 6. Februar 2018 um 19:53
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
Dienstag 6. Februar 2018 um 21:04
Die ISO 13485 nennt keine Ausnahme, erlaubt aber risikobasiert vorzugehen. Mit einer entsprechenden Begründung würde das Ihrem Vorschlag fast entsprechen.
Freitag 9. Februar 2018 um 09:33
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.
Donnerstag 22. März 2018 um 17:40
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
Donnerstag 22. März 2018 um 17:53
Sie finden hier Beispiele für Software-Changes. Wenn das nicht ausreicht, haken Sie gerne einfach nach.
Donnerstag 22. März 2018 um 18:41
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
Freitag 23. März 2018 um 07:24
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
Freitag 27. Juli 2018 um 11:52
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
Samstag 28. Juli 2018 um 18:16
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
Donnerstag 14. März 2019 um 15:55
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
Donnerstag 14. März 2019 um 16:27
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
Montag 18. März 2019 um 08:26
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
Montag 18. März 2019 um 21:09
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