Entwicklungskontrolle für
Medizingeräte
Real World Business Best Practices
Die Entwicklung von Medizinprodukten ist ein st...
Polarion Software®
2www.polarion.com
Wie funktioniert ein CONCEPT-Managementsystem?
Im Wesentlichen wurde ein Konzeptmanag...
Polarion Software®
3www.polarion.com
Herstellung
Das Flussdiagramm stellt die für den Produktentwicklungsprozess eines med...
Polarion Software®
4www.polarion.com
notwendigen Variablen, Optionen zur einzigartigen und wiederverwendbaren Gestaltung d...
Polarion Software®
5www.polarion.com
Das Gesamtsystem hat die Form eines herkömmlichen FMEA.
Diese Aufteilung ist dank meh...
Polarion Software®
6www.polarion.com
Aus diesem Grund sollte eine automatisierte Berechnung vom Worst-Case-Szenario ausgeh...
Polarion Software®
7www.polarion.com
•	 Schwerwiegend - Kann zu dauerhaften Beeinträchtigungen oder Verletzungen des Anwen...
Polarion Software®
8www.polarion.com
Analyse Behördlicher Vorgaben
Typischerweise werden im Entwicklungsprozess zwei Dokum...
Polarion Software®
9www.polarion.com
Wenn die Frage im Rahmen der Prüfung gestellt wird, könnte die firmeninterne Befolgun...
Polarion Software®
10www.polarion.com
Andererseits können die Testprozesse für alle laut Produktqualitätsplan erforderlich...
Polarion Software®
11www.polarion.com
Europe, Middle-East, Africa: Polarion Software GmbH
Kesselstraße 19 — 70327 Stuttgar...
Nächste SlideShare
Wird geladen in …5
×

Entwicklungskontrolle für Medizingeräte

545 Aufrufe

Veröffentlicht am

Die Entwicklung von Medizinprodukten ist ein stark integrierter und regulierter Prozess. Die Einführung einer Lösung zur Nachverfolgung von Anforderungen bedarf der Berücksichtigung einer Reihe differenzierter Themen. Bei der Aufgabe, die zahlreichen konzeptionellen Beziehungen in einem Projekt dieser Art nachzuverfolgen, ist die Softwarelösung erster Wahl normalerweise ein zweidimensionales Textsystem wie z.B. MS ExcelTM oder NumbersTM von Apple. Rückblickend betrachtet fällt die Wahl aufgrund der mehrdimensionalen Logik komplexer Anforderungen jedoch oft auf eine ganz andere Lösung.

Erfahren Sie in diesem Whitepaper, wie Sie die Software-Entwicklung für Ihre medizintechnischen Geräte professionalisieren.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
545
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
12
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Entwicklungskontrolle für Medizingeräte

  1. 1. Entwicklungskontrolle für Medizingeräte Real World Business Best Practices Die Entwicklung von Medizinprodukten ist ein stark integrierter und regulierter Prozess.Die Einführung einer Lösung zur Nachverfolgung von Anforderungen bedarf der Berücksichtigung einer Reihe differenzierter Themen. Bei der Aufgabe, die zahlreichen konzeptionellen Beziehungen in einem Projekt dieser Art nachzuverfolgen, ist die Softwarelösung erster Wahl normalerweise ein zweidimensionales Textsystem wie z.B. MS Excel™ oder Numbers™ von Apple. Rückblickend betrachtet fällt die Wahl aufgrund der mehrdimensionalen Logik komplexer Anforderungen jedoch oft auf eine ganz andere Lösung.Polarion steht für eine neueArt von Softwareplattform zur Modellierung der Prozessbeziehungen und zur Bereitstellung einer mehrdimensionalen, echtzeitverknüpften, relationalen Datenbanklösung für komplexe Entwicklungsumgebungen der heutigen Zeit. Die Lösung ermöglicht dem Entwicklungspersonal die einmalige Festlegung von Beziehungen und damit die anschließende Konzentration auf wichtigere Aufgaben anstelle einer ständigen Aktualisierung der Projektsteuerunterlagen. Einleitung Ziel dieser Arbeit ist die Erörterung aller differenzierten Themen in Bezug auf eine Nachverfolgungs- und Managementlösung für Anforderungen zur Aufstellung von Rahmenbedingungen für die Entwicklung und Implementierung von Polarion als entsprechendes System. Ein zweites Ziel besteht in der Erforschung eines breiteren Anwendungsbereiches für das Tool zur umfassenden Verwaltung von CONCEPTS während der gesamten Lebensdauer auf höchst effiziente und effektive Weise - ein Prozess, der in schnelllebigen Entwicklungsumgebungen der heutigen Zeit unerlässlich ist. Polarion ist im Wesentlichen ein Tool zur Erstellung und Bearbeitung von Dokumenten mit dem Ziel, Ideen/CONCEPTS effizient zu erfassen, zu verknüpfen und nachzuverfolgen. Das Tool kann von allen Abteilungen im Unternehmen angewendet werden, in denen die Verwaltung komplexer Informationen im gesamten Lebenszyklus sowie projekt- und teamübergreifend Teil des Aufgabenbereichs ist. Dies beinhaltet beispielsweise die Erstellung und Implementierung von V&V-Tests, Qualitätsmanagementsysteme (Erfüllung bundesweiter Vorgabenkataloge) sowie Herstellungsprozesse (Einhaltung unternehmensinterner Betriebsvorgänge). Daher sollte jeder Implementierungsprozess des Tools den breiteren Kontext in Bezug auf Implementierungsmöglichkeiten berücksichtigen und nicht auf die unmittelbare Entwicklungsumgebung beschränkt sein, um sicherzustellen, dass die Lösung auch mittel- und langfristig zur bestmöglichen Nutzung ihrer raffinierten Funktionalitäten eingerichtet ist. Polarion Software® Whitepaper Copyright © 2015 Polarion Software - Die Vervielfältigung und Weitergabe dieses Dokuments in unveränderter Form ist gestattet.
  2. 2. Polarion Software® 2www.polarion.com Wie funktioniert ein CONCEPT-Managementsystem? Im Wesentlichen wurde ein Konzeptmanagementsystem zur Zerlegung von Dokumenten in deren grundlegende Bestandteile entwickelt. Diese Bestandteile werden anschließend auf der Grundlage ihrer Definition und ihrer logischen Beziehungen verknüpft, um Workflows zur Erledigung bestimmter Aufgaben zu bilden. ImFalleinerDesign-ValidierungkanneinProduktanforderungsdokumentbeispielsweiseinNutzerbedürfnisse,Systemanforderungen, mechanische Anforderungen und Softwareanforderungen aufgegliedert werden. Die mechanischen Anforderungen werden anschließend weiter in Entkeimung, Verpackung und Transitanforderungen zerlegt. Da sich all diese CONCEPTS logisch voneinander unterscheiden und unabhängig voneinander etikettiert sind, können sie sortiert und spezifischen Workflows zugeordnet werden. Die Entkeimungsanforderungen können beispielsweise in einen mikrobiologischen Prüfungsvorgang kopiert werden, und die Nutzerbedürfnisse können in einem Validierungstest zusammengefasst werden. Daneben kann jeder Workflow unabhängig bearbeitet werden. Ein weiteres Beispiel ist das Qualitätsmanagement. Wenn ein Unternehmen beispielsweise einen rechtlichen Anforderungskatalog und behördliche Richtlinien zur System-Compliance erhält, können diese in bestimmte rechtliche Anforderungen eingeteilt und anschließend mit Hilfe standardisierter betrieblicher Vorgänge im Unternehmen erfüllt werden. Da die spezifische Kategorisierung jedes einzelnen Arbeitsblocks, der um Problem-, Veränderungs- und Variantenmanagement erweitert wird, für Klarheit sorgt, können die Aufzeichnungen zum Nachweis von Compliance einfach im Rahmen eines Audits kontrolliert werden. Dies geschieht auf ähnliche Weise wie ein Produktdesign-Verifizierungsvorgang. Das Besondere an Polarion ist die Tatsache, dass die Erstellung von Dokumenten sowie die Festlegung von deren Logik und deren unabhängige Nachverfolgung ermöglicht wird. Die CONCEPTS, einschließlich der ausgefeilten mehrdimensionalen Beziehungen, können in Polarion gespeichert und nachverfolgt werden oder als vollständiges Dokument an ein herkömmliches PLM-Tool (Agile, Arena Solutions, Image Silo, usw.) herausgegeben werden. In jedem Fall können detaillierte Berichte und Dokumentationen zur internen Prüfung sowie für externe Audits in Echtzeit generiert werden,umAufschluss über den genauen Stand Ihrer Projekte zu geben.Damit unterscheidet sich die Lösung wesentlich von herkömmlichen PLM (Produkt-Lebenszyklus-Management)-Tools, mit denen das Gesamtdokument und nicht Konzepte INNERHALB des Dokuments verwaltet werden können, wodurch Prozesse wesentlich aufwendiger werden. Verfolgbarkeitsmatrix Design V&V Die erste Aufgabe in jedem Produktentwicklungsprozess besteht im Allgemeinen in der Herausarbeitung, Definition und Verknüpfung der für das Produkt interessanten Aspekte. Dies erfolgt typischerweise in einem logischen Flussdiagramm und bildet die Grundlage für die Entwicklung eines Design V&V-Testplans. In komplexen Entwicklungsumgebungen der heutigen Zeit kann dies mit extremem Aufwand einhergehen. Glücklicherweise wurden Vorlagen für typische Anordnungen erstellt und zur Nutzung verfügbar gemacht. Ein Beispiel für ein solches Diagramm ist die umfassende SwanVMC-Verfolgbarkeitstabelle (auf der nächsten Seite dargestellt).
  3. 3. Polarion Software® 3www.polarion.com Herstellung Das Flussdiagramm stellt die für den Produktentwicklungsprozess eines medizinisches Gerätes typischen Entwicklungs-,Herstellungs- und Risikomanagementbeziehungen dar. Es beinhaltet zudem die im Entwicklungsprozess angewandten Konzepte wie z.B. die Integration von Standards (FDA-Anweisungen, ISO, ASTM, u.s.w...), Bildern, erklärenden Texten, wesentlichen Anforderungen und Standardglossardefinitionen. Andere Werkzeuge Ein wesentlicher Vorteil der Nutzung von Polarion ergibt sich aus der Art und Weise der Referenzierung untergeordneter Aspekte in der gesamten Entwicklungshistoriendatei (design history file, DHF). Beispielhaft dafür ist die Beschreibung des Verwendungszwecks eines medizinischen Gerätes. Der Text kann auf bequeme Weise einmal zur Genehmigung erstellt werden und anschließend als etikettierter Arbeitsschritt in sämtlichen Anwendungsbereichen referenziert werden. Dadurch wird die Einheitlichkeit im Text sowie die Möglichkeit zur Erstellung jedes einzelnen Punktes bei der Verwendung des Standardtextes sichergestellt, was zur Ermittlung der gesamten Auswirkungen einer Veränderung wesentlich ist und dafür sorgt, dass alle relevanten Dokumente an die Veränderung angepasst werden. Risikomanagement In konzeptioneller Hinsicht ist Risikomanagement einfach zu beschreiben und zu verstehen.Es gibt Gefahren,die Schäden hervorrufen. Diese Schäden müssen dokumentiert und abgeschwächt werden, um ein Ergebnis steuern und damit die Nutzung eines Gerätes berechenbar und sicher machen zu können. Allerdings ist die Implementierung eines entsprechenden System kompliziert aufgrund einer Reihe Faktoren, einschließlich der zur Beschreibung der Beziehungen zwischen den unterschiedlichen Systembestandteilen
  4. 4. Polarion Software® 4www.polarion.com notwendigen Variablen, Optionen zur einzigartigen und wiederverwendbaren Gestaltung dieser Konzepte, m:n-Datenbankbeziehungen und gelegentlich unklarer oder verwirrender regulatorischer Erwartungen. Aus diesem Grund wird im Folgenden erläutert, wie diese unterschiedlichen Systembestandteile organisiert werden können. Zunächst sind die Daten in der Reihenfolge,in der sie überprüft werden,zu ordnen.Nach der Markteinführung eines Produkts durch die Niederlassungen wird die Aufsichtsabteilung das Produkt auf der Grundlage der Schäden beim Nutzer, der Nutzergefährdung und der Anzahl bzw.des Prozentanteils der beim Nutzer eingetretenen Risiken bewertet.Unsere Datenfelder sollten die zurückgesendeten Daten direkt spiegeln,damit ein einfacherVergleich und eine reibungslose Bearbeitung der auf dem Markt festgestellten Probleme ermöglicht wird. Wir sollten in der Lage sein, den Schadensfall auf dem Markt zu sehen und ihn direkt mit dem Risikomanagementprozess zu vergleichen. Dadurch werden wir sofort feststellen können, ob der Faktor zur Ermittlung der Häufigkeit mit der eine Gefahrensituation zu einem Schaden führt korrekt ist oder ob die Wahrscheinlichkeit der Gefahrensituation unangemessen bewertet wurde. Zweitens sollten die Datenfelder die gemeinhin verwendete Terminologie enthalten. Die Aufsichtsbehörden haben festgelegt, was unter Gefährdung oder Gefahrensituation zu verstehen ist. Wir sollten die genormte Terminologie in unser Modell einbauen, damit die Prüfer unsere Absicht ohne zusätzliche Erklärungen besser verstehen. Zweitens sollten die Datenfelder die gemeinhin verwendete Terminologie enthalten. Die Aufsichtsbehörden haben festgelegt, was unter Gefährdung oder Gefahrensituation zu verstehen ist. Wir sollten die genormte Terminologie in unser Modell einbauen, damit die Prüfer unsere Absicht ohne zusätzliche Erklärungen besser verstehen. Drittens sollten die Arbeitspunkte auf eine Weise geordnet werden, mit der die Verknüpfungskomplexität minimiert wird. Das System gewährt dem Nutzer dabei so viel Freiheit,dass die Logik schwer nachvollziehbar wird.Dadurch kann die Einarbeitung von Mitarbeitern sowie die Erläuterung für die Aufsichtsbehörden erschwert werden. Im folgenden Flussdiagramm ist ein System dargestellt,das die oben genanntenVoraussetzungen in Bezug auf das Risikomanagement- Design erfüllt. Das System ist mit Hilfe zweier Arbeitspunkte organisiert. • Gefahrensituation • Risikoanalyse
  5. 5. Polarion Software® 5www.polarion.com Das Gesamtsystem hat die Form eines herkömmlichen FMEA. Diese Aufteilung ist dank mehrerer Faktoren praktisch. • Die Arbeit wird von unterschiedlichen Abteilungen fertiggestellt und überprüft (unterschiedlicher Workflow). Die Gefahrensituation ist größtenteils eine Engineering-Aufgabe, während die Risikoanalyse im Normalfall von Risikomanagement-Spezialisten und klinischem Personal durchgeführt wird. • Die Umrechnungs-/Wahrscheinlichkeitsvariablen können nicht ohne die im Arbeitspunkt beschriebenen Bestandteile festgelegt werden. Beispielsweise kann die Eintrittswahrscheinlichkeit einer Gefahrensituation nicht ohne Kenntnis der Gefahr, der vorhersehbaren Ereignisabfolge und der sich daraus ergebenden Gefahrensituation definiert werden. In der Risikoanalyse ist die Wahrscheinlichkeit, mit der eine Gefahrensituation zum Schaden am Patienten führt, nicht ohne eine Eintrittshäufung der Gefahrensituation und eine Charakterisierung des Schadens erkennbar. • Der Begriff „Gefahrensituation” wird beispielsweise in behördlichen Dokumenten (ISO 14971) erläutert. Daher ist die Angleichung des Arbeitspunktes an den behördlichen Fachbegriff zum Zweck der Klarheit für die Prüfer praktisch. Arbeitspunkt Gefahrensituation Die vollständig charakterisierte Gefahrensituation beinhaltet die Gefahrenquelle (Gefahr), die Beschreibung des fehlerhaften Zustandes (vorhersehbare Ereignisabfolge) und die örtliche Wirkung (Gefahrensituation). Variable Bestandteile sind unter Anderem die Migrationswahrscheinlichkeit vor bzw. nach dem Eintritt der GS sowie die Feststellung der Migration vor und nach dem Eintritt. Hier ein Beispiel: Elektromagnetische Strahlung > 1) Einschnitt in der Isolierung, 2) Leiter berührt die Hülle > Bestromung des Schrankgehäuses. oder Biokompatibilität, Allergenität > 1) Spritzenspitze erfüllt Spezifizierung nicht, zu groß 2) Verabreichung einer Überdosis > Patient erhält Überdosis. Arbeitspunkt Risikobewertung DerArbeitspunkt Risikobeurteilung beinhaltet eine Beschreibung des Schadens,der Schwere des Schadens,des Gesamteintrittsrisikos einer Gruppe von Gefahrensituationen - vor und nach der Migration - der Wahrscheinlichkeit, mit der die Gefahrensituation zum Schaden führt, sowie Berechnungswerte für den endgültigen Schadenseintritt und die Prioritätsstufe des Risikos. Die oben genannten Beispiele können wie folgt weitergeführt werden: Stromschlag > Tod des Patienten/Schweregrad 5 oder Anaphylaktischer Schock > stationäre Behandlung des Patienten 4. Jede Gefahrensituation tritt in einem bestimmten Maße ein. Die Zusammenlegung mehrerer Eintrittswahrscheinlichkeiten von Gefahrensituationen ist problematisch. Bei der Analyse als allgemeines Problem besteht keine Kenntnis über die Zusammenhänge zwischen den unterschiedlichen Arten von Gefahrensituationen. Treten die Fehler der Reihe nach auf (folgt einer auf den anderen)? Treten die Fehler unabhängig auf (d.h. nicht durch vorhergehende Gefahrensituationen bedingt)? Sind die Gefahrensituationen voneinander abhängig (hat der Eintritt der ersten Einfluss auf das Ergebnis oder den Eintritt der zweiten)?
  6. 6. Polarion Software® 6www.polarion.com Aus diesem Grund sollte eine automatisierte Berechnung vom Worst-Case-Szenario ausgehen, welches durch manuelle Eingabe überschritten werden kann, sofern dies von der Engineering-Abteilung als angemessen betrachtet wird. Da die Eintrittsraten typischerweise niedrig sind, ist eine Summierung der Raten die scheinbar vernünftigste Methode. Der berechnete Wert wird anschließend mit P2 (Wahrscheinlichkeit, mit der die Gefahrensituation zum Schaden führt) multipliziert. In unserem Beispiel ist die Gefahrensituation die Bestromung des Gehäuses. Der Schaden ist ein Stromschlag für den Anwender. Offensichtlich stellt sich die Frage, wie oft ein Stromschlag zum Tod des Anwenders führt. Glücklicherweise bedingt ein Ereignis nicht immer das andere. Wir verwenden den Umrechnungsfaktor zur Verringerung der Eintrittswahrscheinlichkeit auf das Gefahrenniveau, dem der Anwender tatsächlich ausgesetzt wäre. FMEA Sowohl die Charakterisierung der Gefahrensituation und die Risikobewertung sind zur Fertigstellung der Fehlermöglichkeits- und Einflussanalyse (FMEA) erforderlich. Nach Abschluss der beiden Arbeitsschritte können wir analysieren, wie sich eine bestimmte Fehlermöglichkeit auf den Endnutzer auswirkt. Anschließend wird das Ergebnis im Rahmen der gesamten Verfolgbarkeitsanalyse - Schaden > Gefahr > Migration - zur endgültigen Übermittlung aufbereitet. Bewertungsskalen Bei der Festlegung eines Risikomanagementsystems ist stets auch die Entwicklung der Bewertungsskalen erforderlich. Im Folgenden wird jede Skala und deren Bedeutung erläutert. Die Skalen sind lediglich ein Beispiel für diesen Arbeitsschritt. Ich habe eine Vielzahl unterschiedlicher Methoden gesehen. Schaden/Schweregrad Im unten beschriebenen System wird ein Schaden als eine von fünf Optionen beschrieben: • Unwesentlich - Kann zu geringfügigen Beeinträchtigungen des Anwenders oder Patienten ohne Verletzung, Schäden am System oder Einflüsse auf den Prozess / das Produkt führen. Minimale Auswirkungen auf die Produktqualität. • Gering - Kann zu Schäden im Prozesssystem und damit zu Prozessverzögerungen mit geringfügigen zeitweisen Verletzungen führen. Moderater Einfluss auf die Produktqualität einschließlich geringfügiger Konformitätsabweichungen. • Erheblich - Kann zu erheblichen zeitweisen Verletzungen des Anwenders, Patienten oder anderen Personen vor Ort führen. WesentlicherEinflussaufdieProduktqualitäteinschließlichdeutlicherKonformitätsabweichungen,diemithoherWahrscheinlichkeit zu wesentlichen zeitweisen Verletzungen führen.
  7. 7. Polarion Software® 7www.polarion.com • Schwerwiegend - Kann zu dauerhaften Beeinträchtigungen oder Verletzungen des Anwenders, Patienten oder anderen Personen vor Ort führen. Wesentlicher Einfluss auf die Produktqualität, einschließlich Konformitätsabweichungen, die mit hoher Wahrscheinlichkeit Produktfehler und damit schwere Verletzungen hervorrufen. • Sehr schwerwiegend - Kann zum Tod des Anwenders, des Patienten oder anderer Personen vor Ort führen. Sehr starker Einfluss auf die Qualität, was mit hoher Wahrscheinlichkeit zu Produktfehlern an lebenserhaltenden Geräten führt. Eintritt von Gefahren Das Eintrittsrisiko von Gefahren kann folgendermaßen kategorisiert werden: 1. Unwesentlich (< .01 %) 2. Gering - (.1 - .01%) 3. Gelegentlich (1 - .1%) 4. Wahrscheinlich (1 - 5%) 5. Häufig (>5%) Risikoprioritätsstufe (RPS) Die RPS wird auf der Grundlage der in den obigen Tabellen hergeleiteten Schweregrade und Eintrittswahrscheinlichkeiten berechnet. Sie kann entweder aus einer Auswahltabelle oder einer Vielzahl an Berechnungsmethoden hergeleitet werden. Im Folgenden wird die in diesem Beispiel verwendete Auswahltabelle dargestellt. Dokumentendefinition Der nächste Schritt ist die Dokumentendefinition. In dieser Phase wird festgelegt, welche Dokumente zur Darstellung der erford- erlichen Arbeitspunkte verwendet werden und wie diese Dokumente freigegeben werden. Einige der von den Behörden geforderten Dokumente sind unten dargestellt:
  8. 8. Polarion Software® 8www.polarion.com Analyse Behördlicher Vorgaben Typischerweise werden im Entwicklungsprozess zwei Dokumente verwendet, die von der Aufsichtsabteilung erstellt werden. Regulatorische Analyse - dabei analysiert die Aufsichtsabteilung das neue Produkt, um behördliche Anforderungen, einschließlich • Märkte für das Gerät sowie rechtliche Zuständigkeitsbereiche • Geräteklassifizierung(en) • erforderliche Zubehörteile • andere behördliche Anforderungen in Bezug auf das in Entwicklung befindliche Gerät herauszuarbeiten. Klinischer Beurteilungsbericht (Clinical Evaluation Report, CER) - Dieser Bericht wird auf unterschiedliche Weise bezeichnet und ist eine Zusammenfassung der Leistung des Gerätes oder eines ähnlichen Gerätes auf dem entsprechenden Gebiet. Er beschreibt die Art der Anwenderschäden/Schweregrade, die bei der jeweiligen Anwendergruppe auftraten, sowie die Eintrittshäufigkeit auf der Grundlage öffentlicher und firmeninterner Aufzeichnungen. Diese Daten bilden die Grundlage der ersten Risikoanalyse und liefern eine solide Basis für die Design-Anforderungen. Die aufsichtsrechtliche Bewertung ist ein gutes Beispiele für firmengenerierte Anforderungsquellen. Andere Beispiele sind Best Practices in Bezug auf das Design, rechtliche Haftung und SOPs, die zur weiteren Bearbeitung internationaler Standards verwendet wurden. Risikomanagement Die Risikomanagementinformationen setzen sich aus drei Dokumenten zusammen. Der Inhalt für die Risikoanalyse basiert daneben auf folgenden Zusatzdokumenten: • The Risk Management Plan • Risk Analysis - DFMEA - PFMEA - Schäden - Gefahrensituationen - schadensbasierte Fehlerbaumanalyse (Fault Tree Analysis, FTA) - Tabelle zur Datenbankverfolgbarkeit • Risikomanagementbericht ManchederstrukturellenBestandteiledesDokumentssindvorgegeben.BeispielsweiseerfordertdieISO-Normeinenschadensbasierten Ansatz der Risikoanalyse. Daneben sollte darauf geachtet werden, dass die Dokumente alle kraft Gesetz vorgeschriebenen Informationen enthalten, beispielsweise: • Risikomanagementplan (EN ISO 14971:2009, Der Plan muss Folgendes enthalten: Umfang der Aktivitäten...Aufgabe von...Verantwortlichkeiten...Akzeptierbarkeitskriterien...Verifizierungsaktivitäten...Aktivitäten in Bezug auf Erfassung und Prüfung). • Risikomanagementbericht(ENISO14971:2009,DiePrüfungmusszumindestsicherstellen,dassderRisikomanagementplan angemessen implementiert wurde...das Gesamtrestrisiko ist akzeptabel...es wurden Methoden angewandt, um relevante Produktions- sowie nachträgliche Informationen zu erhalten). Eine Art, dies sicherzustellen wäre die Integration behördlicher Regelkataloge als Anforderungsdokumente in das Polarion-Tool. Die rechtlichen Anforderungen würden durch die unternehmensinternen SOP-Anforderungen erfüllt bzw. durch einen ISO-Standard, der wiederum durch Befolgung der Designdokumente im Rahmen der firmeninternen SOP erfüllt wäre. Wie könnte die Verfolgbarkeit der Prüfschritte (Audit) von der Anforderungsquelle zu den vorhandenen Designdokumenten auf bessere Weise gewährleistet werden?
  9. 9. Polarion Software® 9www.polarion.com Wenn die Frage im Rahmen der Prüfung gestellt wird, könnte die firmeninterne Befolgung eines bestimmten Paragraphen der FDA CFRs oder der Europäischen MDDs direkt von der gesetzlichen Bestimmung zum SOP nachverfolgt werden,wodurch die Identifizierung der Dokumente zum Compliance-Nachweis vereinfacht würde. Die Nachweishierarchie ist wie folgt: Gesetzliche Bestimmung > firmeninterne SOP-Anforderung/ISO Standard > Alle Projektdokumente Schäden - Schäden sollten im Mittelpunkt der umfassenden Produktrisikoanalyse stehen. Neben den behördlichen Bestrebungen, dies sicherzustellen, werden dadurch Audit-Prozesse nach der Markteinführung erleichtert. Treten nachteilige Ereignisse in diesem Bereich ein, werden sie zumeist mit Schäden für den Anwender in Verbindung gebracht. Da die Risikomanagement-Datei auf der Grundlage der Schäden geordnet ist, kann in solchen Fällen schnell festgestellt werden, welche Gefahrensituationen von den Beteiligten im Vorfeld in Bezug auf den vorliegenden Schaden vorhergesagt wurden, und was zur Korrektur des Problems in dem Bereich erforderlich ist. Daneben kann das mit der Designfunktion in Verbindung stehende Design V&V sowie die im Falle notwendiger Design-Änderungen wiederholt erforderlichen Prüfmaßnahmen schnell ermittelt werden. Gefahrensituationen - Gefährdungen und Gefahrensituationen sollten auf alle möglichen Arten analysiert werden, um mögliche Probleme in Bezug auf Design, Verarbeitung und Verwendung des Gerätes zu identifizieren. All diese Methoden (DFMEA, PFMEA, Fehlerbaum, Beurteilung der klinischen Anwendung, klinische Tests, u.s.w...) sollten gefährliche Situationen ermitteln und selbige in der schadensbasierten Analyse als mögliche Ursachen des Anwenderschadens sichtbar machen. Gefahrenminderung-JedefürdasUnternehmenmöglicheMinderungvonGefahrensollteinderschadensbasiertenFehlerbaumanalyse aufgeführt werden. Nutzerbedürfnisse, Produktanforderungen und Herstellungsvoraussetzungen sollten als legitime Maßnahmen zur Abschwächung einer Gefahrensituation in Betracht gezogen werden. Dies ergibt sich teilweise aus der Anforderung entsprechend ISO 14971:2012 Anhang Z, laut der Etikettierung nicht als Maßnahme zur Verringerung der Eintrittswahrscheinlichkeit einer Gefährdung eingesetzt werden soll. Wir benötigen eine möglichst umfassende Strategie zur Kontrolle der Geräteanwendung, wenn die Anwendungskontrolle über das Gerätedesign nicht möglich ist. Bei der Minderung einer Gefahrensituation müssen wir zur Senkung des Risikos auf alle Mittel zurückgreifen, die dem Unternehmen zur Verfügung stehen, d.h. “as much as possible” nach dem Wortlaut der ISO 14971:2012. Die Risikominderungsstrategie ist zudem die beste Datenquelle für die Produktetikettierung.Anstatt ein ähnliches Gerät zu verwenden, das gegenwärtig auf dem Markt ist, oder einen Ärzteausschuss zur Definition der Vorbeugung, Warnung oder Gegenanzeigen erfordernden Risiken einzuberufen, wird die Erarbeitung einer umfassenden Liste möglicher Probleme im Rahmen der Risikoanalyse empfohlen. Wird ein hohes/mittleres Risiko erkannt, sollte unter Anderem die Produktetikettierung als Minderungsmaßnahme angewandt werden. Obwohl das Etikett nicht die Eintrittswahrscheinlichkeit der Gefahrensituation mindern kann, bietet es in Bezug auf die Produkthaftung eine hervorragende Möglichkeit zur Erklärung, wann und wo Benachrichtigungen der Anwender zum Einsatz kommen sollen. Struktur/Design Strukturvorgaben (PRD) - Strukturvorgaben (PRD) - Die Unterlagen sollten zumindest ein Dokument (zumeist eine Vielzahl an Dokumenten) enthalten, das Nutzerbedürfnisse und Produktanforderungen definiert. Diese Dokumente werden oftmals erstellt, um den gegenwärtigen Entwicklungsprozess sowie die am Entwicklungsprozess mitwirkenden Zulieferer widerzuspiegeln. Dabei sollte über die Art und Weise der Dokumentenorganisation in der Projektvertragsumgebung nachgedacht werden. Design-Spezifizierungen - Spezifizierungen gibt es in vielen unterschiedlichen Formen, z.B. Druck, Code und Produktionsanleitungen. Daneben sollte ein Plan zur Verfolgung der Erfüllung aller Designvorgaben aufgestellt werden. Oftmals ist die Aufnahme aller Spezifizierungen in die Designkontrollfunktion nicht sinnvoll, da je nach Prüfstrategie eine Berücksichtigung aller Dateien nicht notwendig ist.
  10. 10. Polarion Software® 10www.polarion.com Andererseits können die Testprozesse für alle laut Produktqualitätsplan erforderlichen Daten (erste Artikel, prozessinterne Tests, Eingangsprüfung) verfolgt werden, wenn alle Spezifizierungen im System sind, wodurch ein vollständigeres Bild vom gesamten Lebenszyklus des Geräts entsteht. Diese Strategie könnte vorteilhafterweise mit der Integration von Testdaten, die nach der Markteinführung generiert wurden, in die Produkthistorie durch die für Integration verantwortliche Produktionsabteilung einhergehen. Designverifizierung und Validierungsplan (Design V&V) - Wie zuvor erwähnt, ist die Suche nach Nutzerbedürfnissen, Produktanforderungen und deren entsprechendem Testfall innerhalb der Projektdatei eine leistungsstarke Funktionalität. Herstellung Produktherstellungsplan - Dieser Plan wird verwendet, um festzulegen, wie das Produkt aufgebaut wird. Oftmals wird diese Liste im Unternehmen in mehr als ein Dokument unterteilt. • Produktkonstruktions-Flussdiagramm - Das Flussdiagramm liefert den Kontext für die spätere Besprechung der Prozesse und Anforderungen aller Schritte der Produktherstellung.Anschließend wird die Liste auf Dopplungen geprüft und bildet die Grundlage für den Validierungs-Masterplan. Ist eine Prozessvalidierung erforderlich, wird der Testfall festgelegt; ansonsten beinhaltet die Datei eine Erklärung für die Auslassung von selbigem. • Master-(Prozess)validierungsplan - Dieser Teil des Dokuments ist ein praktischer Ort für die Erläuterung aller zum Bau des Produkts angewandten Prozesse, die Ermittlung aller Prozesse, welche einer Prozessvalidierung bedürfen, und die Aufbewahrung für dieTestobjekte der Prozessvalidierung.Die Prozessvalidierungsarbeit ist eineArt der Minderung möglicher Produktgefahren und sollte als solche mit der Gefährdung zur Einbindung in die schadensbasierte Fehlerbaumanalyse verknüpft werden. • Qualitätsmanagementplan - Sobald der Produktionsablauf festgelegt ist, wird der Qualitätsmanagementplan zur Sicherstellung der Produktqualität mit Aspekten zur Produktleistungsüberprüfung im Rahmen des Konstruktionsplans verwendet. Diese Verifizierungsaspekte dienen zudem zur Minderung möglicher Produktgefahren und sollten in der schadensbasierten Fehlerbaumanalyse aufgeführt werden. Designübertragungsplan - Nach Abschluss und Freigabe der Produktentwicklungs- und Prüfungsschritte muss das Design als zum Bau zugelassenes Produkt zur externen Verwendung an die Produktionsabteilung übertragen werden. Dieser Plan beinhaltet zudem wichtige Hinweise zur Art der Kontrolle und Erfassung der Geräteleistung während der Herstellung und auf dem Markt. Die Ziele der firmeninternen Qualitätsrichtlinie müssen in jedem Qualitätsmanagement-Beurteilungsgespräch bewertet werden. Diese Ziele beinhalten die Leistung der Qualitätsprüfungs-, CAPA-, Reklamations- und Produktionssysteme. Die designbezogene Gefahrenminimierungsstrategie umfasst idealerweise die Ausarbeitung von Rahmenbedingungen zur Bestimmung der Bereiche höchsten Risikos und zur Einrichtung von Kontrollstellen. Beispiele sind u.a.: • Interne Audits • Audits durch Dritte • Eingangsinspektion • Erstmusterprüfung • Fertigungskontrolle • Produktbezogene Reklamationen • Anwendungsausfälle WürdendieseTestsindasEntwicklungskontrollprogrammaufgenommen,könntendieDatenderTestsautomatischindenManagement- Review-Prozess einfließen. Das Auftreten von Gefährdungen würde in Tabellen erfasst, womit eine einfache und intuitive Überprüfung der Felder Schaden/Gefahrenrisiko möglich wäre. Personalisierung Wiki-Berichtstools erlauben dem Programmleiter höchste Flexibilität bei der Festlegung des Formats und der für jeden erforderlichen BerichtnotwendigenDaten.DieseFlexibilitätbeinhaltetdieBefugnis,Berichts-undDatenstrukturenmitunerwartetenoderkomplizierten Ergebnissen zu ändern. Die Bearbeitung von Berichtsergebnissen und Hintergrunddaten sollte einer sorgfältigen Analyse unterzogen
  11. 11. Polarion Software® 11www.polarion.com Europe, Middle-East, Africa: Polarion Software GmbH Kesselstraße 19 — 70327 Stuttgart, GERMANY Tel +49 711 489 9969 - 0 Fax +49 711 489 9969 - 20 www.polarion.com - info@polarion.com Americas & Asia-Pacific: Polarion Software, Inc. 1001 Marina Village Parkway, Suite 403, Alameda, CA 94501, USA Tel +1 877 572 4005 Fax +1 510 814 9983 www.polarion.com - info@polarion.com werden und Veränderungen vor der Implementierung des Tools mit einer großen Datenmenge getestet werden. Möglichkeiten zur personalisierten Gestaltung sind u.a.: • RPL-Berechnung - Einzigartige Methoden zur Berechnung der Prioritätsstufe des Produktrisikos. Ich habe vielfältige Methoden in Anwendung gesehen. Schweregrad * Eintritt, Schweregrad 2 * Eintritt, Schweregrad * Erkennung * Eintritt, mit einer Vielfalt an Bewertungsskalen. 1-10, 1-5, 1-20, Auswahllisten, Gleichungen und zusätzliche Größen. Es gibt tatsächlich so viele Möglichkeiten, diese Aufgabe zu bewältigen, dass meiner Erwartung zufolge eine Anpassung an die Bedürfnisse Ihres Unternehmens erfolgen müsste. • Linkbeziehungen - In manchen Fällen wird das System ausgehend von den produktbezogenen Bedürfnissen bis zum Schaden aufgebaut; in anderen Fällen ausgehend vom Schaden zu den Risikominderungsmaßnahmen. Ist Ihr internes System ein festes System, müssen Sie möglicherweise die Beziehungen neu aufbauen sodass sie mit den SOPs Ihres Unternehmens kompatibel sind. • Arbeitsaufgabentechnik - Es gibt viele unterschiedliche Bezeichnungen für dasselbe logische Konzept. Üblicherweise muss das System mit der Firmenpolitik vereinbar sein. • DFMEA-,PFMEA-Terminologie - obwohl FMEA bereits seit einiger Zeit existiert,variiert die Nutzung diesesTools stark von Branche zu Branche.Auch die Medizinproduktbranche hat sich gelegentlich unterschiedliche Techniken zu Nutze gemacht. Besonderes Augenmerk sollte auf die Art der Darstellung der FMEA und deren Integration in die Entwicklungskontrolldatei gelegt werden. • Verfolgbarkeitsbericht über die Entwicklung - Der Verfolgbarkeitsbericht über die Entwicklung ist eine Darstellung des Konstruktionsdesigns. Das Format des Berichts und die dargestellten Verknüpfungen müssten geändert werden, wenn ein beliebiger Strukturbestandteil (Aufgaben, Verknüpfungsbeziehungen, Hintergrundinformationen) verändert wird. Ein gutes Beispiel hierfür sind Workflows zur Freigabe von Arbeitsschritten. Fazit Es ist nicht verwunderlich, dass die zur erfolgreichen Entwicklung eines medizinischen Gerätes erforderliche Systemarchitektur von Programm-Managern gelegentlich als erdrückend empfunden wird. Anfangs ist man geneigt zu denken, es wäre schon nicht so schwer, man müsse doch nur eine Liste machen. Man erstellt dann eine Excel-Tabelle für die Entwicklungsvorgaben, ein Word -Dokument für eine erste Darstellung der Produktanforderungen und stellt nach einem allgemeinen Überblick über die Komplexität des Entwicklungsprozesses fest, dass das Projekt mit stetig wachsendem Aufwand und einer exponentiellen Steigerung der Fehleranfälligkeit einhergeht. Polarion ist ein Tool, das Sie bei der Bearbeitung komplexer Entwicklungsschritte und Verknüpfungsbeziehungen unterstützt. Mit diesem Tool bedürfen die eingerichteten Verknüpfungen keiner kostspieligen Wartung, während Programm-Updates in einer strukturierten und durchsuchbaren Umgebung ausgeführt werden können. Bitte rufen Sie uns an und beginnen Sie, Ihre Produktivität und Innovationen zu beschleunigen sowie Fehler in Ihrem nächsten Entwicklungsprojekt zu vermeiden. Über Polarion Software Polarion Software ist ein führender Anbieter einer durchgängigen und zu 100% Browser-basierten Plattform für Anforderungs-,Test- und Application-Lifecycle-Management (ALM). Polarion wird von globalen Unternehmen in einer Vielzahl von Branchen eingesetzt, wie zum Beispiel im Automobilbau, in der Medizintechnik und in der Luft- und Raumfahrt. Kunden erzielen mit Polarion die für die Herstellung Ihrer Produkte nötige Agilität, Traceability und Compliance. Käufer der mit Polarion entwickelten Produkte erwarten eine herausragende Qualität und Sicherheit. Mehr als 2,5 Millionen Anwender weltweit vertrauen deswegen auf Polarion, um die Zusammenarbeit in ihren Unternehmen voranzutreiben, ALM und Product Lifecycle Management (PLM) zu verküpfen und um ihre hochwertigen Produkte auf den Markt zu bringen. Weitere Informationen unter: www.polarion.com

×