Kategorien: Regulatory Affairs
Tags: ,

28 Kommentare

  1. Hans joerg Müller | Montag, 10. Oktober 2016 um 10:05 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Montag, 10. Oktober 2016 um 11:50 Uhr - Antworten

      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


  2. Andreas Heertsch | Mittwoch, 5. April 2017 um 14:50 Uhr - Antworten

    >>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


  3. Andreas Heertsch | Donnerstag, 6. April 2017 um 07:14 Uhr - Antworten

    Sehr umfangreiche, übersichtliche Info! – Vielen Dank.


  4. Christian Stenske | Freitag, 28. April 2017 um 20:05 Uhr - Antworten

    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.


    • Prof. Dr. Christian Johner | Samstag, 29. April 2017 um 08:53 Uhr - Antworten

      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


  5. Isabella Moser | Dienstag, 14. November 2017 um 11:50 Uhr - Antworten

    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.


    • Prof. Dr. Christian Johner | Dienstag, 14. November 2017 um 17:07 Uhr - Antworten

      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.


  6. Gerald Fruh | Mittwoch, 22. November 2017 um 13:41 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Mittwoch, 22. November 2017 um 20:22 Uhr - Antworten

      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


  7. Markus Roemer | Donnerstag, 28. Dezember 2017 um 12:17 Uhr - Antworten

    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


  8. Thomas Breucker | Mittwoch, 24. Januar 2018 um 15:40 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Donnerstag, 25. Januar 2018 um 17:48 Uhr - Antworten

      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.


  9. Stefan Marl | Dienstag, 6. Februar 2018 um 19:53 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Dienstag, 6. Februar 2018 um 21:04 Uhr - Antworten

      Die ISO 13485 nennt keine Ausnahme, erlaubt aber risikobasiert vorzugehen. Mit einer entsprechenden Begründung würde das Ihrem Vorschlag fast entsprechen.


  10. Markus Roemer | Freitag, 9. Februar 2018 um 09:33 Uhr - Antworten

    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.


  11. Jean | Donnerstag, 22. März 2018 um 17:40 Uhr - Antworten

    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


  12. Jean | Donnerstag, 22. März 2018 um 18:41 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Freitag, 23. März 2018 um 07:24 Uhr - Antworten

      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


  13. Wolfgang Kürschner | Freitag, 27. Juli 2018 um 11:52 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Samstag, 28. Juli 2018 um 18:16 Uhr - Antworten

      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


  14. Grathwol Volker | Donnerstag, 14. März 2019 um 15:55 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Donnerstag, 14. März 2019 um 16:27 Uhr - Antworten

      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


  15. Volker Grathwol | Montag, 18. März 2019 um 08:26 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Montag, 18. März 2019 um 21:09 Uhr - Antworten

      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


  16. Stephan Blab | Dienstag, 4. Februar 2020 um 14:53 Uhr - Antworten

    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


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.