SlideShare ist ein Scribd-Unternehmen logo
Dieses White Paper untersucht einige der klassischen Herausforderungen des
Risikomanagements für Medizinprodukte und zeigt, wie mit der Siemens PLM
Software-Lösung der Prozess erheblich verbessert werden kann. Siemens PLM
Software bietet eine stabile Repository- und Workflowmanagement-Lösung, die
Aufgaben wie Anforderungsmanagement und Reporting vereinfacht und gleich-
zeitig eine tiefe Verfolgbarkeit automatisiert.
www.siemens.comWhite Paper ausgegeben von: Siemens PLM Software
Verbesserung des
Risikomanagements für
Medizinprodukte
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
2
Inhalt
Kurzdarstellung ..............................................................3
Die Herausforderungen des Risikomanagements
für Medizinprodukte .......................................................4
Ein Datenmodell für Rückverfolgbarkeit .........................6
Ein Datenmodell für Risikomanagement .........................9
Dokumentendefinition Risikomanagement ...................15
Fazit ..............................................................................19
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
3
Die Entwicklung von Medizinprodukten stellt schon so lange
das Fundament der Ausübung und Verbesserung der
Heilkunde dar, wie die Menschheit schon versucht,
Menschen zu heilen. Mörser und Stößel wurden schon vor
mehr als 6.000 Jahren zur Herstellung von Arzneipulver
verwendet.
Im Laufe der Jahrtausende sind unsere medizinischen
Instrumente komplexer und leistungsfähiger geworden, was
auch für die regulatorischen Rahmenbedingungen gilt.
Vorschriften sind unerlässlich, da sie dazu beitragen, sicher-
zustellen, dass medizinische Instrumente gemäß dem
Prinzip der Verifizierung und Validierung (V&V) konstruiert
werden, so dass sie die erforderlichen Spezifikationen erfül-
len und für ihren vorgesehene klinische Zwecke eingesetzt
werden können.
In konzeptioneller Hinsicht ist Risikomanagement einfach zu
beschreiben und zu verstehen. Aufgrund der Tatsache, dass
potenziell gefährliche Situationen zu einem Schaden führen
können, müssen diese dokumentiert und abgeschwächt
werden, um Ergebnisse zu steuern und damit die Nutzung
eines Geräts berechenbar und sicher zu machen.
Wie jeder weiß, der mit Regelkonformität zu tun hat, können
die Dinge allerdings sehr schnell komplex werden, beson-
ders dann, wenn man mit vielerlei Vorschriften und in
Konflikt stehenden Definitionen zurechtkommen und die
Regelkonformität auf digitaler Ebene nachverfolgen muss.
Diese Komplexität wird durch eine Vielzahl Faktoren verur-
sacht, wie z. B. die Anzahl von Variablen, die für die
Beschreibung der Beziehungen zwischen
Systemkomponenten erforderlich sind, Optionen zur einzig-
artigen und wiederverwendbaren Gestaltung dieser
Konzepte, die m:n-Beziehungen, die für die Verfolgung der
Regelkonformität erforderlich sind, und zuweilen vage oder
verwirrende regulatorische Erwartungen.
Tools, die derzeit zum Zwecke der Verfolgung der
Komplexität eingesetzt werden, sind nicht nur simpel son-
dern simplistisch. Obwohl Tabellen
gut sind für die Verfolgung von 1:1-Beziehungen, werden
sie schnell weit weniger nützlich bei der Verfolgung von
1:n- und m:n-Beziehungen, die für die Gewährleistung der
Einhaltung gesetzlicher Bestimmungen bei der Entwicklung
von Medizinprodukten erforderlich sind.
Tabellen und Microsoft® Word Softwaredokumente sind
nicht wirklich für die wichtige Aufgabe bestimmt,
Rückerfolgbarkeit zu erhalten. Rückverfolgbarkeit bildet das
Herzstück der Qualitätssicherung während der
Konstruktions- und Entwicklungsphase und bleibt eine
wichtige nachträgliche Kontrolle nach der Freigabe bei der
Verknüpfung von Überwachungsberichten zurück zu spezifi-
schen Produktanforderungen und V&V-Prozessen.
Glücklicherweise bietet Siemens PLM Software eine leis-
tungsstarke Lösung für die Entwicklung von
Medizinprodukten.
Kurzdarstellung
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
4
Traditionell eine der schwierigeren
Systementwicklungsaufgaben für Entwickler ist die
Herausforderung der Implementierung eines effektiven
Risikomanagements für Medizinprodukte. Das Schlagwort ist
effektiv, da Risikomanagement ein lebendiger Prozess zu
sein hat, der zu einem granularen Teil des Gesamtprozesses
wird; vom ersten Entwurf über die Fertigung bis zur
Marktbeobachtung nach Inverkehrbringen des Produkts.
Die meisten der Schwierigkeiten haben ihren Ursprung
darin, dass veraltete Technologie – statische schriftliche
Dokumente und Tabellen – zur Verfolgung der komplexen
und dynamischen Umgebung verwendet wurde, in der
geltende Standards und sonstige Produktanforderungen im
Laufe der Zeit und durch Entwurfs- und
Entwicklungsiterationen verfolgt werden.
Das Risikomanagement für medizinische Instrumente muss
auf lebendigen Konstruktionselementen basieren, die aus
einem zentralen Repository weitergegeben werden können,
um die Dokumente der Beteiligten zu aktualisieren und die
Versionssteuerung aufrechtzuerhalten. Ohne die
Verwendung einer solchen Automatisierung zur Verfolgung
der Beziehungen zwischen Konstruktionselementen, kann
die Konstruktionsabsicht über die verschiedenen Workflows,
Produktänderungen und aktualisierten Anforderungen
hinweg verloren gehen.
Anerkannte Standards
Die Entwicklung von Medizinprodukten ist ein hochintegrier-
ter und regulierter Prozess. Zwei wesentliche Standards, die
das Risikomanagement für Medizinprodukte umfasst, sind
ISO 14971:2009, die den Prozess für den Hersteller bei der
Identifizierung der Gefährdungen in Verbindung mit
Medizinprodukten festlegt und der ISO Technical
Information Report (TIR) 24971:2013, der wertvolle
Hinweise bezüglich der Anwendung bestimmter Bereiche
der ISO 14971 bei der Umsetzung des Risikomanagements
bietet. Europa hat darüber hinaus die Norm EN ISO
14971:2012 eingeführt, die sich in verschiedenen wichtigen
Aspekten von den anderen unterscheidet und erforderlich
ist, wenn ein Unternehmen Medizinprodukte in den europäi-
schen Raum verkauft.
Der durch diese Standards definierte Prozess ist in Abbildung
1 dargestellt.
Risikoanalyse
Risikobewertung
Risikokontrolle
Risikomanagement-Bericht
Bewertung der Akzeptanz des
Gesamt-Restrisikos
Informationen aus der Produktion und
der Produktion nachgelagerten Phasen
•	Bestimmungsgemäßer Gebrauch und
Identifizierung der Charakteristika in
Bezug auf die Sicherheit des
Medizinprodukts
•	Ermittlung der Gefährdungen
•	Einschätzung des Risikos/der Risiken
der jeweiligen Gefahrensituation
•	Risikokontrolloptionsanalyse
•	Umsetzung der
Risikokontrollmaßnahme(n)
•	Bewertung des Restrisikos
•	Risiko-/Nutzenanalyse
•	In Verbindung mit Risikokontrollmaß-
nahmen entstehende Risiken
•	Vollständige Risikokontrolle
RisikomanagementRisikobeurteilung
Abbildung 1. Risikomanagement-Workflow
Die Herausforderungen des
Risikomanagements
für Medizinprodukte
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
5
Von der Risikoanalyse zur Marktbeobachtung nach
Inverkehrbringen des Produkts
Eine Risikomanagement-Komplettlösung für
Medizinprodukte muss
die komplette Palette an Verknüpfungen abdecken, wie in
Abbildung 1 gezeigt.
Der grundlegende logische Verlauf schließt folgendes ein:
•	 Risikoanalyse:
‒‒ Gefährdungen
‒‒ Vorhersehbare Reihenfolge der Ereignisse (zuweilen
definiert als
Reihenfolge der eigentlichen Ursachen)
‒‒ Gefahrensituationen
‒‒ Schäden
•	 Risikobewertung:
‒‒ Werte für Eintrittswahrscheinlichkeit vor und nach der
Durchführung von Risikominderungsmaßnahmen
‒‒ Schwere des Schadens
‒‒ Risikoprioritätsstufe
‒‒ Beurteilung der Risikoakzeptanz
•	 Risikokontrolle:
‒‒ Konstruktionsanforderungen
‒‒ Realisierungsanforderungen
‒‒ Kennzeichungsanforderungen
‒‒ Verifizierung der Implementierung
‒‒ Verifizierung der Effektivität
•	 Abschluss und Berichterstellung:
‒‒ Bewertung des Produktrestrisikos
‒‒ Bewertung der Risikoakzeptanz
•	 Marktbeobachtung nach Inverkehrbringen des
Produkts:
‒‒ Risikotrendkennzahlen
‒‒ Rückverfolgbarkeit der Risikoanalysetrendkennzahlen
Wesentliche Bestandteile des Risikomanagementsystems
Das Risikomanagementsystem sollte den
Produktdesignern Informationen über Maßnahmen liefern,
wie z. B.:
•	 Auswirkungen auf Anwender – wie sich Konstruktions-
Features auf Anwender auswirken
•	 Gefahrensituationskontrollplan – Daten zur Steuerung
der Entwicklung des Gefahrensituationskontrollplans,
inkl. Risikominderungsmaßnahmen bei Konstruktion,
Produktherstellung und Kennzeichnung
•	 Feldergebnisse – Feldergebnisse sollten mit der
Risikoanalyse verknüpft werden, um sicherzustellen,
dass Problembereiche in der Analyse Berücksichtigung
finden und die bei der Produktanwendung entdeckten
Problembereiche schnell darin integriert werden
•	 Risikominderungsmaßnahmen – Leistungsdaten, inkl. der
Formulierung von Anforderungen zur Vergewisserung,
dass V&V-Maßnahmen verwendet werden können, um
die Umsetzung und Effektivität der Anforderungen
sicherzustellen
Die Leistungsfähigkeit relationaler Daten, durchsetzbarer
Workflows
und Automatisierung
Sie können leicht überfordert sein bei der Verwendung
tabellenbasierter Methoden zur Verfolgung aller gegenseiti-
gen Abhängigkeiten
der Risikoanalyse, -kontrolle, -berichterstellung und -über-
wachung. Die Siemens PLM Software-Lösung für
Medizinprodukte mit ihrer relationalen Datenstruktur, durch-
setzbaren Workflows, Automatisierungen,
Rückverfolgbarkeit und Reporting erleichtert das Verfolgen
und Erstellen von Berichten mit den jeweils erforderlichen
Risikomanagementinformationen. Und mit dem zentralen
Repository der Lösung wird gewährleistet, dass jeder die
gleichen Datensätze verwendet. Das Identifizieren von
Schäden und sonstigen Artefakten ist so leicht wie per
Knopfdruck Berichte mit den Arbeitselementen auszuführen,
die systematisch mit den relevanten Daten ausgefüllt
wurden.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
6
Rückverfolgbarkeit ist die Basis des Risikomanagements für
Medizinprodukte. Von der Konstruktion, Entwicklung und
Fertigungsausführung bis zur Marktbeobachtung nach
Inverkehrbringen der Produkte müssen Unternehmen mitei-
nander verbundene Arbeitselemente und ihre Beziehungen
zu Konstruktions- und Rechtsvorschriften, Testfällen, V&V-
Prozessen, Bestandskontrollen, Gefährdungen, Schäden und
Risikominderungsmaßnahmen präzise zurückverfolgen
können. Einige der grundlegenden Bausteine der
Rückverfolgbarkeit sehen Sie in der in Abbildung 2 darge-
stellten, Verfolgbarkeitsmatrix der Siemens PLM Software
Vorlage für Medizinprodukte Das Flussdiagramm zeigt
Elemente, die die Basis für die Entwicklung des Design
V&V-Testplans und des Risikomanagement-Framework
bilden.
Umfassende Rückverfolgbarkeit
Die Komplexität dieser Zusammenhänge kann durch
Tabellen oder schriftliche Dokumente nicht in angemesse-
nem Maße verfolgt werden. Zum Beispiel bereits früh im
Konstruktionsprozess könnten Sie Nutzerbedürfnisse in
einem Dokument angeben, das mit Word erstellt wurde. Bei
jedem aufgeführten Nutzerbedürfnis könnten Sie eine Zahl
am Ende des Satzes zum Zwecke der Verfolgung angeben.
Beim Schreiben eines separaten
Produktanforderungsdokuments können Sie jede
Anforderung auf das Nutzerbedürfnis zurückverweisen, das
von der Anforderung erfüllt wird. Die numerische
Verknüpfung kann dann in einer Tabelle platziert werden
und somit lässt sich die Abhängigkeit zwischen
Nutzerbedürfnissen und Produktanforderungen
zurückverfolgen.
Risikoerfassung
Schaden
Gefahren-
situation
Fehler
Testfall
Aufgabe
Designvorgaben
Nutzerbedürf-
nisse
Produkt-
anforderungen
Fehler
Bestandskontrollen
Prozess-
validierung
Inspektion
Lieferanten-
kontrolle
Ausgaben
Quelle
Erfüllen
Implementie-
ren
Nutzt
Implementiert Erklären
Erfüllt
Validiert
Verifiziert
Verifizieren
Validieren
Implementiert
Aufgabe
Fertigungsan-
forderungen
Verifiziert
Nutzt
Hat zur Folge
Ursache
Hat RisikohistorieHat Risikohistorie
Mindern (PFMEA)Quelle
Verfeinert
Produkt-
quellen
Wird ausgelöst durch
Mindert (PFMEA)
Abbildung 2. Verfolgbarkeitsmatrix
Ein Datenmodell für Rückverfolgbarkeit
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
7
Jedoch während der Entwicklung ist es unwahrscheinlich,
dass Sie jedes Entwicklungsergebnis, inkl. Unterbaugruppen
mit jedem Nutzerbedürfnis oder jeder Produktanforderung
werden verknüpfen können.
Die Rückverfolgung gestaltet sich noch komplizierter, wenn
Designdateiausgaben an die Produktion weitergeleitet
werden, die üblicherweise einen Produktherstellungssplan
und eine Tabelle zur Verfolgung ihrer eigenen produktions-
technischen Anliegen erstellt. Um somit nun die
Rückverfolgbarkeit von Nutzerbedürfnissen,
Produktanforderungen und Ausgaben bis zu
Fertigungsanforderungen festzustellen, müssen Sie sämtli-
che dieser Dokumente öffnen. Sie wurden ggf. nicht
aktualisiert und zentral gespeichert und haben keine
Versionssteuerung. Sie werden die Elemente manuell finden
und die Rückverfolgung jedes einzelnen Dokuments ent-
schlüsseln müssen.
Diese fehlende effiziente Rückverfolgung führt zu viel
größeren Problemen und Verzögerungen für die Teams in
ihrem Versuch, auf CAPA- (Korrektur- und
Vorbeugemaßnahmen) Anforderungen zu reagieren.
Tests von Benutzer- und Produktanforderungen
Eine effiziente Lösung für die Verwaltung von
Produktanforderungen sollte das Verknüpfen von
Nutzerbedürfnissen mit Produkt-
und Softwareanforderungen und den relevanten Tests
vereinfachen, wie
in Abbildung 3 dargestellt.
Zum Beispiel zeigen die ersten Einträge in der Tabelle in
Abbildung 3, dass das Nutzerbedürfnis 1010-3873 (das
Medizingerät ist steril) der Produktanforderung 1010-3874
(das Medizingerät ist laut ISO 11135 mit Ethylenoxid sterili-
siert) zugeordnet ist und auf den Test (1010-3821) verweist.
Eine robuste Anforderungsmanagement-Lösung unterstützt
Abbildung 3. Test von Benutzer- und Produktanforderungen
Workflows und Rückverfolgbarkeit der gesamten
Zusammenhänge in Konstruktion, Fertigung und
Risikomanagement, die im Entwicklungsprozess von
Medizinprodukten üblich sind. Die Lösung sollte die
Integration von im Entwicklungsprozess verwendeten
Begriffen unterstützen, wie z. B. die Integration von
Standards, Richtlinien der United States Food and Drug
Administration (FDA, US-amerikanische Behörde für die
Zulassung von Lebens- und Arzneimittel), von ISO und der
American Society for Testing and Materials (ASTM) und alle
sonstigen geltenden Compliance-Daten sowie Bilder und
textbasierte Erklärungen.
Verfolgen untergeordneter Aspekte
Einer der wesentlichen Vorteile in der Nutzung eines soliden
Anforderungsmanagement-Tools 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 Punkts bei der Verwendung des
Standardtextes sichergestellt. Dies kann entscheidend sein
für die Ermittlung der Änderungsauswirkungen und die
Sicherstellung, dass eine Änderung richtig auf alle relevan-
ten Dokumente übertragen wird.
Robuste Nach- und Rückverfolgbarkeit sind für die
Dokumentation und Minimierung von Gefahrensituationen
erforderlich, um Ergebnisse zu steuern und sicherzustellen,
dass ein Medizinprodukt berechenbar und sicher ist.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
8
Best Practices
Wie wir gesehen haben, ist die Implementierung eines
effizienten und effektiven Risikomanagementsystems –
besonders eines, das auf traditionellen Tabellen und
statischen Dokumenten basiert – kompliziert
und anspruchsvoll.
Wie bereits erwähnt, ist dies auf eine Reihe von Faktoren
zurückzuführen, wie z. B.:
•	 Die Anzahl der Variablen, die zur Beschreibung der
Beziehungen zwischen Systemkomponenten benötigt
werden
•	 Optionen zur einzigartigen und wiederverwendbaren
Gestaltung dieser Konzepte
•	 Die Fähigkeit, n:m-Datenbankbeziehungen zu
unterstützen
•	 Zuweilen vage oder verwirrende regulatorische
Erwartungen
Einige der Best Practices zur Anordnung von Komponenten
des
Systems zur Unterstützung der Marktbeobachtung nach
Inverkehrbringen des Produkts beinhalten:
•	 Zunächst sind die Daten in der Reihenfolge, in der sie
überprüft werden, zu ordnen: Nach dem Inverkehrbringen
des Produkts wird durch die Marktbeobachtung das
Produkt basierend auf Schaden und Gefährdung für den
Benutzer und Anzahl und Prozentsatz des Auftretens die-
ser Gefährdungen in der Praxis bewertet. Ihre Datenfelder
sollten mit den zurückgesendeten Daten direkt verknüpft
sein, damit ein einfacher Vergleich und eine reibungslose
Bearbeitung der auf dem Markt festgestellten Probleme
ermöglicht wird. Sie sollten in der Lage sein, den
Schadensfall auf dem Markt zu sehen und ihn direkt mit
dem Risikomanagementprozess zu vergleichen. Dies
ermöglicht Ihnen eine sofortige Bewertung, ob der Faktor,
mit dem ermittelt wurde, wie oft die Gefahrensituation
einen Schaden zur Folge hatte, korrekt ist, oder ob die
Wahrscheinlichkeit des Auftritts der Gefahrensituation
falsch eingeschätzt wurde.
•	 Verwenden Sie gängige Terminologie für Datenfelder:
Die Aufsichtsbehörden haben festgelegt, was unter
Gefährdung oder Gefahrensituation zu verstehen ist. Sie
sollten die genormte Terminologie in Ihr Modell einbauen,
damit die Prüfer Ihre Absicht ohne zusätzliche Erklärungen
besser verstehen.
•	 Verknüpfungskomplexität minimieren: die
Arbeitselemente sollte 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.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
9
Risikomanagementmethoden werden oftmals unzureichend
verstanden und unpräzise definiert, weshalb es umso wich-
tiger ist, ein solides Risikomanagementmodell zu haben.
Ein gut konzipiertes, umfassendes Risikomanagement-Tool
sollte in der Lage sein, ein Risikomanagement-Datenmodell
zu unterstützen, dass
die konsistente Verwendung von Definitionen,
Arbeitselementen und Workflows zur Ermittlung und
Minimierung von Schäden und Gefährdungen sicherstellt.
Ihr Risikomanagement-Tool sollte den in Abbildung 4
beschriebenen logischen Ablauf basierend auf ISO 14971
Anhang E, unterstützen. Dieser ist für die Konformität mit
den Zulassungsystemen für Medizinprodukte in den USA
und Europa erforderlich. Er enthält Messelemente wie die
Reihenfolge der Ereignisse, die Eintrittswahrscheinlichkeit
einer Gefahrensituation und die Wahrscheinlichkeit, dass die
Gefahrensituation einen Schaden zur Folge hat.
Ein Risikomanagement-Datenmodell bringt Präzision in Ihre
Abläufe. Es ermöglicht Ihnen, Definitionen festzulegen
– basierend auf den jeweiligen konstruktiven oder regulato-
rischen Anforderungen, mit denen Sie es zu tun haben
– und dann eine konsistente Anwendung durchzusetzen, um
die Datenqualität deutlich zu steigern.
Durchsetzbare Workflows
Die Erstellung eines Risikomanagement-Datenmodells mit
der Siemens PLM Software-Lösung für Medizinprodukte gibt
Ihnen die Möglichkeit, durchsetzbare Workflows zu entwi-
ckeln, so dass alle Teammitglieder, unabhängig von ihrem
geografischen Standort und sonstigen Variablen, die glei-
chen definierten Workflows verwenden. Ihr Unternehmen
kann die Workflows jedweder Art erstellen, die es benötigt.
Nach der erfolgten Konzeption ist der entscheidende Punkt,
dass Sie die konsistente Verwendung des Modells sicherstel-
len können.
Dies bietet ein einheitliches Framework (Rahmen), mit dem
sichergestellt werden kann, dass Aufgaben vollständig
erledigt werden, und welches Variablen einführt, die durch
oberflächliche Definitionen oder unvollständige Aufgaben
verursacht wurden.
Der Prozess der Definition Ihrer Workflows in einem durch-
setzbaren Framework bringt Klarheit in die Arbeit der
Identifizierung möglicher Gefährdungen und Schäden und
die Festlegung optimaler Risikominderungsstrategien.
Durch dieses Framework wird auch eine Automatisierung
ermöglicht. Nach erfolgreicher Erstellung des Framework
geht es an die Erstellung der Arbeitselemente. Sie durchlau-
fen den selben Bewertungsprozess bei der Identifizierung
von Gefährdungen und Schäden, wie beim Arbeiten mit
einer Tabelle, nun werden jedoch alle wechselseitigen
Beziehungen verwaltet. Dies reduziert erheblich die Zeit, die
für die Durchführung von Berechnungen, Rückverfolgungen
und sonstigen normalerweise zeitintensiven Aufgaben
benötigt wird. Die Wiederverwendung der Anforderungen
und Beziehungen für ähnliche zukünftige Produkte bietet
ebenfalls eine erhebliche Reduzierung des Arbeitsaufwands.
Schadens-
schwere
Eintrittswahrschein-
lichkeit des SchadensProzess
P1 x P2
Gefährdung
Gefahren-
situation
Schaden
Risiko
ReihenfolgederEreignisse
P2
Exposition (P1)
Hinweis: P1 ist die Wahrscheinlichkeit des Eintritts einer Gefahrensitu-
ation.
P2 ist die Wahrscheinlichkeit, dass eine Gefahrensituation zu einem
Schaden führt.
Abbildung 4. Logisches Flussdiagramm für
Risikomanagement basierend auf ISO 14971, Anhang E.
Ein Datenmodell für
Risikomanagement
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
10
Es ist wichtig, die Tatsache zu unterstreichen, dass eine
Tabelle
kein Framework ist. Sie ist nur eine Ansammlung von Zellen,
die nicht
für die Durchsetzung von Workflows oder die Arbeit mit
relationalen Daten verwendet werden kann.
Notwendigkeit der Konsistenz
Das Framework und die von der Siemens PLM Lösung bereit-
gestellte, unterstützende Umgebung verleihen Ihnen auch
die Fähigkeit, Konsistenz bei anderen Elementen, wie z. B.
Definitionen, Terminologie und Schreibweise durchzusetzen.
Obwohl die Durchsetzung einer konsistenten Schreibweise
auf den ersten Blick belanglos erscheinen könnte, kann
fehlende Konsistenz die Qualität Ihrer Daten
beeinträchtigen.
Wenn Sie eine Datenbank nach einem Schaden, wie z. B.
einem perforierten Darm durchsuchen, sehen Sie üblicher-
weise nur einen Teil solcher Ereignisse, wenn das Wort
perforiert in 30 Prozent Ihrer Tabelleneinträge falsch geschrie-
ben wurde. Mit einem Risikomanagement-Tool, das eine
konsistente Schreibweise durchsetzen kann, könnte man mit
einer Suche alle Ereignisse identifizieren.
Die Durchsetzung konsistenter Terminologie wird aus den
gleichen Gründen benötigt. Wenn Sie z. B. mit den Gefahren
eines arteriellen Ballons arbeiten, können einige Ereignisse
als entfernter Ballon beschrieben werden und andere das
gleiche Ereignis als deflatierten Ballon beschreiben; und da
kann es ein breites Spektrum an Variationen geben. Indem
man sich zu Beginn auf eine richtige Terminologie einigt,
kann Ihr Framework die konsistente Verwendung dieser
durchsetzen und Ihnen die Flexibilität bieten,
Ereignisvariationen aufzunehmen und ordnungsgemäß zu
dokumentieren.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
11
Arbeitselemente der Risikobewertung
Die Implementierung eines systematischen, logischen
Verlaufs für das Risikomanagement erfordert, dass
Arbeitselemente und entsprechende Variablen definiert
werden müssen, um die Analyse logisch zu gestalten.
Abbildung 5 bietet ein Beispiel eines Flussdiagramms eines
Systems, das mit dem im vorigen dargestellten
Risikomanagement-Flussdiagramm in Abbildung 4, konform
ist. Angeordnet wird das System mit den drei
Arbeitselementen: Risikoerfassung, Schaden und
Gefahrensituation (GS).
Migration
implementiert
Migration effektiv
Wesentliche Leistung
ja/nein
Abbildung 5. Arbeitselemente der Risikobewertung.
**GS-Attribut
Schritt1**
P1 – Migrationswahrscheinlichkeit
nach dem Eintritt der GS
**GS-Attribut
Schritt1**
P1 – Migrationswahrscheinlichkeit
vor dem Eintritt der GS
Prozess/Quelle/
Designattribut
Gefährdung/
Ursache
Feststellung der
Migration vor dem
Eintritt
Vorhersehbare Rei-
henfolge der
Ereignisse
Feststellung der
Migration nach
dem Eintritt
Gefahrensituation
**Verknüpfung
Beziehung**
Schritt 2
P2 – Wahrscheinlich-
keit, dass
GS zu Schaden führt
**Risikoberichtsda-
ten**
Schritt 3**
Schaden vor Migration
**Risikoberichtsda-
ten**
Schritt 3**
Schaden vor Migration
**Risikoberichtsda-
ten**
Schritt 4**
RPS nach Migration
**Risikoberichtsda-
ten**
Schritt 4**
RPS vor Migration
Beschreibung des Schadens
**Schadensattribut –
Schritt 4****
Schwere des Schadens
Arbeitselement SchadenArbeitselement Gefahrensituation
Arbeitselement Risikoerfassung
Ursachen
Analysiert durch 1/1 Analysiert durch 1/1
■ Arbeitselemente
GS
■ Arbeitselemente
Schaden
■ Tabellengesteu-
ert
■ Benutzereingabe
Die gesamte Systemanalyse ist in Form einer traditionellen
Fehlermöglichkeits- und -auswirkungsanalyse (Failure Mode
and Effects Analysis (FMEA)).
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
12
Diese Aufteilung ist dank mehrerer Faktoren praktisch:
•	 Die Arbeit wird von unterschiedlichen Abteilungen
fertiggestellt und überprüft, jeweils mit ihren entspre-
chenden Workflows. Diese Zweiteilung ist logisch, da
die Gefahrensituation größtenteils eine Engineering-
Aufgabe ist, während die Risikoanalyse im Normalfall von
Risikomanagement-Spezialisten und klinischem Personal
durchgeführt wird.
•	 Die Umrechnungs-/Wahrscheinlichkeitsvariablen kön-
nen nicht ohne die im Arbeitselement beschriebenen
Bestandteile festgelegt werden: beispielsweise kann
die Eintrittswahrscheinlichkeit einer Gefahrensituation
nicht ohne Kenntnis der Gefährdung, der vorherseh-
baren 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 Arbeitselements an den behörd-
lichen Fachbegriff zum Zweck der Klarheit für die Prüfer
praktisch.
Beispiele für Arbeitselemente
Typen von Arbeitselementen können zur Erfüllung eines
Spektrums von Anforderungen definiert werden. Wie im
Vorigen erwähnt, lauten die grundlegenden drei
Arbeitselemente: Schaden, Gefahrensituation und
Risikoerfassung.
Arbeitselement Schaden
Das Arbeitselement Risikobeurteilung enthält
Schadensbeschreibung und Schadensschwere.
Beispielsweise könnte die Schadensbeschreibung für einen
anaphylaktischen Schock einer Schadensschwere von vier
auf einer Skala von eins bis fünf zugeordnet werden.
Arbeitselement Gefahrensituation
Die vollständig charakterisierte Gefahrensituation beinhaltet
die Gefahrenquelle (Gefahr), die Beschreibung des fehler-
haften Zustandes (vorhersehbare Ereignisabfolge) und die
örtliche Wirkung (Gefahrensituation). Variable Bestandteile
sind unter Anderem die Migrationswahrscheinlichkeit vor
bzw. nach dem Eintritt der Gefahrensituation sowie die
Feststellung der Migration vor und nach dem Eintritt
Ein Beispiel dafür ist:
•	 Elektromagnetische Strahlung > 1) Einschnitt in der
Isolierung, 2) Leiter berührt 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
Arbeitselement Risikoerfassung
Das Arbeitselement Risikoerfassung kombiniert eine ein-
zelne
Gefahrensituation mit einem Schaden, so dass beide als Paar
analysiert werden können. Mehrere Arbeitsschritte werden
in dieser Stufe zum erfolgreichen Abschluss der
Risikobeurteilung durchgeführt.
Der Faktor P2 wird als Beziehung zwischen
Gefahrensituation und Schaden (Wahrscheinlichkeit, dass
die Gefahrensituation zu einem Schaden führt) definiert. 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 P2 zur
Verringerung der Eintrittswahrscheinlichkeit auf das
Gefahrenniveau, dem der Anwender tatsächlich ausgesetzt
wäre.
Die Faktoren P1 und P2 werden dann multipliziert, um die
Eintrittswahrscheinlichkeit des Schadens zu bestimmen.
Der finale Faktor P wird dann zusammen mit der
Schadensschwere zur Bestimmung des Risikoindex des
Schadens/der Gefahrensituation verwendet.
Die Risikoprioritätsstufe oder der Risikoindex wird berech-
net, um die Auswirkung des Risikos auf Produkte und
Unternehmenssysteme zu ermitteln.
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 Beispiele für diesen Arbeitsschritt.
Schaden/Schwere
In dem in Abbildung 6 beschriebenen System wird die
Schadensschwere als eine von 5 Stufen, auf einer Skala von
eins bis fünf, definiert.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
13
Eintritt einer Gefahrensituation (P1)
Der Eintritt der Gefahrensituation wird auf der Basis der
Wahrscheinlichkeit eingestuft. Die Tabelle in Abbildung 7
bietet ein Beispiel für ein solches Bewertungssystem.
Wahrscheinlichkeit, dass Gefahrensituation zum Schaden
führt (P2)
Dass eine Gefahrensituation zu einem Schaden führt, wird
auch anhand der Wahrscheinlichkeit eingestuft. Ein Beispiel
dafür sehen Sie in Abbildung 8.
Eintrittswahrscheinlichkeit eines Schadens
Durch Multiplikation der oben definierten
Eintrittswahrscheinlichkeitswerte können Sie die
Eintrittswahrscheinlichkeit eines Schadens, wie in Abbildung
9 gezeigt, berechnen.
Wahrscheinlichkeit, dass Gefahrensituation zum Scha-
den führt (P2)
Ebene Definitionen Schadenswahrschein-
lichkeit
Extrem
unwahr-
scheinlich (1)
<=5 % Verletzung selten
Unwahr-
scheinlich
aber möglich
(2)
6 – 25 % Verletzung denkbar
aber nicht
wahrscheinlich
Wahrschein-
lich (3)
26 – 75 % Verletzung möglich
Sehr wahr-
scheinlich (4)
76 – 95 % Verletzung wird vor-
aussichtlich eintreten
Extrem wahr-
scheinlich (5)
>=96 % Verletzung wird
eintreten
Abbildung 8. Wahrscheinlichkeit, dass Gefahrensituation zu
einem Schaden führt.
P1 – Wahrscheinlichkeit des Eintritts einer Gefahrensituation
Unwahrschein-
lich
(1)
Entfernt vorstell-
bar
(2)
Gelegentlich
(3)
Wahrscheinlich
(4)
Häufig
(5)
P2–Wahrscheinlichkeit,dass
Gefahrensituation
zueinemSchadenführt
Extrem
unwahrscheinlich
(1)
1 1 1 1 2
Unwahrscheinlich,
aber
möglich (2)
1 1 1 1 3
Wahrscheinlich (1) 1 1 1 2 4
Sehr wahrscheinlich
(4)
1 2 2 3 5
Extrem
wahrscheinlich (5)
1 2 3 4 5
Abbildung 9. Eintrittswahrscheinlichkeit einer Gefahrensituation
Kennzeichnung der Schadensschwere
Ebene Definitionen
Gering (1) Führt zu einer vorübergehenden Verletzung/
Beeinträchtigung, die keine professionelle
medizinische Behandlung erfordert;
Unannehmlichkeit
Mittel (2) Vorübergehende Verletzung oder Beeinträchti-
gung, die eine geringfügige professionelle
medizinische Behandlung erfordert
Schwerwiegend (3) Führt zu einer Verletzung oder Beeinträchti-
gung, die eine größere professionelle medizi-
nische Behandlung erfordert
Kritisch (4) Führt zu einer dauerhaften Beeinträchtigung
oder einer lebensbedrohlichen Verletzung
Katastrophal (5) Führt zum Tod des Patienten
Abbildung 6. Beschreibung der Schadensschwere auf einer
Skala von eins bis fünf.
Wahrscheinlichkeit des Eintritts einer Gefahrensituation (P1)
Ebene Häufigkeit
Häufig (5) >1/100 und <=1
Wahrscheinlich
(4)
>1/1000 und <=1
Gelegentlich (3) >1/10.000 und <=1/1000
Entfernt vorstell-
bar (2)
>1/100.000 und <=1/10.000
Unwahrschein-
lich (1)
>0 und <=1/100.000
Abbildung 7. Eintrittswahrscheinlichkeit einer
Gefahrensituation
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
14
Risikoprioritätsstufe
Die Risikoprioritätsstufe (RPS) kann auf der Grundlage der in
den obigen Tabellen hergeleiteten Schweregrade und
Eintrittswahrscheinlichkeiten berechnet werden. Sie kann
entweder aus einer Auswahltabelle oder einer Vielzahl
an Berechnungsmethoden hergeleitet werden. Was unter
einer Auswahltabelle zu verstehen ist, wird in Abbildung 10
verdeutlicht.
Schadensschwere
Schadenseintritt(p1xP2)
Gering
1
Mittel
2
Schwerwiegend
3
Kritisch
4
Katastrophal
5
1 D D C C B
2 D D C B B
3 D C B B A
4 C C B A A
5 C B A A A
Abbildung 10. Eintrittswahrscheinlichkeit einer Gefahrensituation
Beispiel für einen Bericht
Nach Abschluss der Beschreibung der jeweiligen
Kombination aus Gefährdung/Schaden kann ein
Beurteilungsbericht für Risikomanagement und
Risikominderungsmaßnahmen erstellt werden. Ein solcher
Bericht wird in Abbildung 11 auszugsweise als Screenshot
dargestellt.
FMEA-Analyse – Beurteilung Schaden/Gefährdung und Risikominderung
Abbildung 11. Beurteilungsbericht für Schaden/Gefährdung und Risikominderung
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
15
Definitionen sind sehr wichtig während des gesamten
Prozesses des Risikomanagements für Medizinprodukte.
Dazu gehört die Definition der Struktur und Inhalte der
erforderlichen Dokumente, wie z. B. Risikomanagementplan,
Risikoanalyse und Risikomanagementbericht.
Die Struktur der Dokumente ist teilweise vorgeschrieben.
Natürlich sollte speziell darauf geachtet werden, dass die
Dokumente alle kraft Gesetz vorgeschriebenen
Informationen enthalten.
Risikomanagementplan
Die Risikomanagementplan gemäß EN ISO 14971:2009
sollte enthalten:
•	 Umfang der Aktivitäten
•	 Zuweisung von Verantwortlichkeiten
•	 Akzeptierbarkeitskriterien
•	 Verifizierungsaktivitäten
•	 Aktivitäten in Bezug auf Erfassung und Prüfung
Risikoanalyse
Die ISO-Norm erfordert einen
schadensbasierten Ansatz der Risikoanalysedokumente.
Elemente der Risikoanalyse beinhalten:
•	 DFMEA (Device Failure Mode and Effects Analysis,
Gerätefehlermöglichkeits- und auswirkungsanalyse)
•	 PFMEA (Process Failure Mode and Effects Analysis,
Prozessfehlermöglichkeits- und auswirkungsanalyse)
•	 UseFMEA (Use Failure Mode and Effects Analysis,
Anwendungsfehlermöglichkeits- und auswirkungsanalyse)
•	 Schäden
•	 Gefahrensituationen
•	 Schadensbasierte Fehlerbaumanalyse (Fault Tree Analysis,
FTA): Tabelle
zur Datenbankverfolgbarkeit
Risikomanagementbericht
Mit dem Risikomanagementbericht gemäß EN ISO
14971:2009 sollte folgendes sichergestellt werden:
•	 Der Risikomanagementplan wurde angemessen
implementiert
•	 Das Gesamtrisiko ist akzeptabel
•	 Es wurden Methoden angewandt, um relevante
Produktions-
sowie nachträgliche Informationen zu erhalten
Mit der Siemens PLM Software Lösung können Sie
Informationen aus dem US-Federal Register im Tool als
Anforderungsdokumente übernehmen und sie mit den
unternehmensinternen SOP-Anforderungen verknüpfen.
Eine Kombination beider trägt dazu bei, sicherzustellen,
dass die rechtlichen Anforderungen durch die unternehmen-
sinternen SOP-Anforderungen bzw. durch einen
ISO-Standard erfüllt werden, der wiederum durch Befolgung
der Designdokumente im Rahmen der firmeninternen SOP
erfüllt wäre.
Dieser Prozess gewährleistet die Verfolgbarkeit der
Prüfschritte (Audit) von der Anforderungsquelle zu den
vorhandenen Designdokumenten. 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.
Dies Nachweishierarchie ist wie folgt:
Gesetzliche Bestimmung
Firmeninterne SOP-Anforderung/ISO-Standard
Alle Projektdokumente
Produktherstellungsdaten
Daten zur Marktbeobachtung nach
Inverkehrbringen des Produkts
Dokumentendefinition
Risikomanagement
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
16
Integration von Dokumenten
In Ihren Risikomanagement-Dokumenten sollten klar defi-
nierte Elemente enthalten sein, wie z. B.:
•	 Schäden: Schäden sollten im Mittelpunkt der umfassen-
den 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, wer-
den 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 wur-
den, und was zur Korrektur des Problems in dem Bereich
erforderlich ist. Dies bietet eine eindeutige Möglichkeit,
um zu ermitteln, ob die eigentliche Ursache des Problems
berücksichtigt wurde und was zur Korrektur des Problems
in der Praxis erforderlich ist. Daneben kann das mit
der Designfunktion in Verbindung stehenden Design
V&V-Testverfahren 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äts zu iden-
tifizieren. All diese Methoden (DFMEA, PFMEA,UseFMEA,
Fehlerbaum, Beurteilung der klinischen Anwendung,
klinische Tests, u.s.w.) sollten gefährliche Situationen
ermitteln und in der schadensbasierten Analyse als mögli-
che Ursachen des Anwenderschadens sichtbar machen
•	 Gefahrenminderung: Jede für das Unternehmen
mögliche Minderung von Gefahren sollte in der
schadensbasierten Fehlerbaumanalyse 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 Produktanwendung, 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
•	 Produktetikettierung: Die Risikominderungsstrategie ist
zudem die beste Datenquelle für die Produktetikettierung.
Anstatt ein ähnliches Gerät zu verwenden, das gegen-
wä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.
Dokumentenstruktur
Bei der Planung Ihres Dokumentationsgesamtpakets sollten
Sie sicherstellen, dass es folgende Dokumente enthält:
•	 Strukturvorgaben: Die Unterlagen sollten zumindest ein
Dokument (zumeist eine Vielzahl an
Dokumenten) enthalten, das Nutzerbedürfnisse
sowie Produktanforderungen definiert, wie es im
Produktanforderungsdokument (PRD) der Fall ist.
Diese Dokumente werden oftmals erstellt, um den
gegenwärtigen Entwicklungsprozess sowie die am
Entwicklungsprozess mitwirkenden Zulieferer wider-
zuspiegeln. 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. Andererseits können
die Testprozesse für alle laut Produktqualitätsplan
erforderlichen Daten (Erstmusterprüfung, prozessinterne
Tests, Eingangsprüfung) verfolgt werden, wenn alle
Spezifizierungen im System sind, wodurch ein vollständi-
geres 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.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
17
•	 Designverifizierung und Validierungsplan: Wie zuvor
erwähnt, ist die Suche nach Nutzerbedürfnissen,
Produktanforderungen und deren entsprechendem
Testfall innerhalb der Projektdatei eine leistungsstarke
Funktionalität.
Dokumente für die Produktion
Sie sollten über eine robuste Sammlung von Dokumenten
für die Produktion verfügen, wie z. B.:
•	 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
zur Konstruktion des Produkts angewandten Prozesse,
die Ermittlung aller Prozesse, welche einer Validierung
bedürfen, und die Aufbewahrung für die Testobjekte der
Prozessvalidierung. Die Prozessvalidierungsarbeit ist eine
Art 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
Konstruktionsablauf festgelegt ist, wird der
Qualitätsmanagementplan zur Sicherstellung
der Produktqualität mit Aspekten zur
Produktleistungsüberprüfung im Rahmen des
Konstruktionsplan 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.
Bewertung der Ziele der Qualitätsrichtlinie
Die Ziele der firmeninternen Qualitätsrichtlinie müssen in
jedem Qualitätsmanagement-Beurteilungsmeeting 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 für Kontrollstellen sind u.a.:
•	 Interne Audits
•	 Audits durch Dritte
•	 Eingangsprüfung
•	 Erstmusterprüfung
•	 Fertigungskontrolle
•	 Produktbezogene Reklamationen
•	 Anwendungsausfälle
Würden diese Tests in das Entwicklungskontrollprogramm
aufgenommen, könnten die Daten der Tests automatisch in
den Management-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.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
18
Personalisierung
Visual Reporting-Tools erlauben dem Programm-Manager
höchste Flexibilität bei der Festlegung des Formats und der
für jeden erforderlichen Bericht notwendigen Daten. Mit
dieser Flexibilität geht die leistungsstarke Funktion einher,
Berichts- und Datenstrukturen mit unerwarteten oder kom-
plizierten Ergebnissen zu ändern. Berichtsausgaben und
Hintergrunddatenmanipulationen sollten sorgfältig analy-
siert und Änderungen getestet werden, ehe das Tool auf
einem umfassenden Datensatz implementiert werden kann.
Möglichkeiten zur personalisierten Gestaltung sind u.a.:
•	 RPS-Berechnung – einzigartige Methoden zur Berechnung
der Prioritätsstufe des Produktrisikos. Vielfältige
Methoden können dabei zur Anwendung kommen.
Schweregrad X Eintritt, Schweregrad 2 X Eintritt,
Schweregrad X Erkennung X 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 Sie ggf. Ihre eine individuelle Risikoprioritätsstufe
zur Anpassung an die Bedürfnisse Ihres Unternehmens
berechnen möchten.
•	 Verknüpfungsbeziehungen – In manchen Fällen
wird das System ausgehend von den produktbezo-
genen 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. Die gute Nachricht
ist, dass die Siemens PLM Software flexibel ist und beide
Ansätze unterstützt.
•	 Arbeitselemente-Terminologie – Es kann oftmals viele
unterschiedliche Bezeichnungen für dasselbe logische
Konzept geben. Üblicherweise muss das System mit der
Firmenpolitik vereinbar sein.
•	 DFMEA-, PFMEA-Terminologie – Obwohl FMEA
bereits seit einiger Zeit existiert, variiert die Nutzung
dieses Tools stark von Branche zu Branche. Auch die
Medizinproduktbranche hat sich gelegentlich unter-
schiedliche 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 Konstruktionsdesign. Das Format des
Berichts und die dargestellten Verknüpfungen müssten
geändert werden, wenn
ein beliebiger Strukturbestandteil (Arbeitselemente,
Verknüpfungsbeziehungen, Hintergrundinformationen)
verändert wird. Ein gutes Beispiel hierfür sind Workflows
zur Freigabe von Arbeitselementen.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
19
Fazit
Es ist nicht verwunderlich, dass die zur erfolgreichen
Entwicklung eines medizinischen Geräts erforderliche
Systemarchitektur von Programm-Managern gelegentlich als
erdrückend empfunden wird. Anfangs ist man geneigt zu
denken, „es wäre schon nicht so schwer. Ich erstelle nur eine
Liste“ und starte den Prozess mit einer Excel®-Tabelle für die
Entwicklungsvorgaben und einem Word-Dokument für die
erste Erstellung der Produktanforderungen. Jedoch stellt
man nach einem allgemeinen Überblick über die
Komplexität des Entwicklungsprozesses fest, dass das
Projekt mit stetig wachsendem Aufwand und einer exponen-
tiellen Steigerung der Fehleranfälligkeit einhergeht.
Die Siemens PLM Software-Lösung ist ein Tool, das Sie bei
der Bearbeitung komplexer Entwicklungsschritte und
Verknüpfungsbeziehungen unterstützt. Mit dieser Lösung
bedürfen die eingerichteten Verknüpfungen keiner kostspie-
ligen Pflege, während Programm-Updates in einer
strukturierten und durchsuchbaren Umgebung ausgeführt
werden können.
White Paper ausgegeben von: Siemens PLM Software
White Paper | Verbesserung des Risikomanagements für Medizinprodukte
20
www.siemens.com/plm
© 2017 Siemens Product Lifecycle Management Software Inc. Siemens und das Siemens-
Logo sind eingetragene Marken der Siemens AG. ALM, D-Cubed, Femap, Fibersim, Geolus,
GO PLM, I-deas, Insight, JT, NX, Parasolid, Polarion, Solid Edge, Syncrofit, Teamcenter und
Tecnomatix sind Marken oder eingetragene Marken der Siemens Product Lifecycle
Management Software Inc. oder ihrer Niederlassungen in den USA und in anderen
Ländern. Microsoft und Excel sind Marken oder eingetragene Marken der Microsoft
Corporation. Alle anderen Marken, eingetragenen Marken oder Dienstleistungsmarken
sind Eigentum der jeweiligen Inhaber.
63108-A7 5/17 o2e
Siemens PLM Software
Siemens PLM Software, eine Business Unit der Siemens
Digital Factory Division, ist ein führender, weltweit tätiger
Anbieter von Software, Systemen und Dienstleistungen für
das Product Lifecycle Management (PLM) und das
Fertigungsmanagement (MOM) mit über 15 Millionen
lizenzierten Anwendern und mehr als 140.000 Kunden in
aller Welt. Siemens PLM Software mit Sitz in Plano, Texas,
entwickelt in enger Zusammenarbeit mit seinen Kunden
branchenspezifische Softwarelösungen, die Unternehmen in
allen Bereichen durch Umsetzung bedeutender Innovationen
einen nachhaltigen Wettbewerbsvorteil verschaffen. Weitere
Informationen über die Produkte und Leistungen von
Siemens PLM Software unter www.siemens.com/plm.
Siemens PLM Software
Deutschland
Siemens Industry Software GmbH
Franz-Geuer-Straße 10
50823 Köln
Tel. +49 221 20802-0
Schweiz
Siemens Industry Software AG
Freilagerstrasse 40
8047 Zürich
Tel. +41 44 755 72 72
info.ch.plm@siemens.com
Österreich
Siemens Industry Software GmbH
Wolfgang-Pauli-Straße 2
4020 Linz
Tel. +43 732 37 75 50
office-linz.plm@siemens.com
Hauptsitz
Granite Park One
5800 Granite Parkway
Suite 600
Plano, TX 75024
USA
+1 972 987 3000

Weitere ähnliche Inhalte

Was ist angesagt?

PLM Open Hours - Fortschrittsübersicht bei Änderungen
PLM Open Hours - Fortschrittsübersicht bei ÄnderungenPLM Open Hours - Fortschrittsübersicht bei Änderungen
PLM Open Hours - Fortschrittsübersicht bei Änderungen
Intelliact AG
 
PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...
PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...
PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...
Intelliact AG
 
PLM Open Hours - Konfigurierung, ein zentrales Element in der Auftragsabwicklung
PLM Open Hours - Konfigurierung, ein zentrales Element in der AuftragsabwicklungPLM Open Hours - Konfigurierung, ein zentrales Element in der Auftragsabwicklung
PLM Open Hours - Konfigurierung, ein zentrales Element in der AuftragsabwicklungIntelliact AG
 
PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...
PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...
PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...
Intelliact AG
 
Swiss PLM-Forum 2011 - Suchen und Finden im Digitalen Produkt
Swiss PLM-Forum 2011 - Suchen und Finden im Digitalen ProduktSwiss PLM-Forum 2011 - Suchen und Finden im Digitalen Produkt
Swiss PLM-Forum 2011 - Suchen und Finden im Digitalen Produkt
Intelliact AG
 
PLM Open Hours - Produktstrukturen im Auftragsabwicklungsprozess
PLM Open Hours - Produktstrukturen im AuftragsabwicklungsprozessPLM Open Hours - Produktstrukturen im Auftragsabwicklungsprozess
PLM Open Hours - Produktstrukturen im Auftragsabwicklungsprozess
Intelliact AG
 
PLM Open Hours - Best Practices in der Produkstrukturierung
PLM Open Hours - Best Practices in der ProdukstrukturierungPLM Open Hours - Best Practices in der Produkstrukturierung
PLM Open Hours - Best Practices in der Produkstrukturierung
Intelliact AG
 
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und SystemenPLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
Intelliact AG
 
PLM Open Hours - Service- und Ersatzteilmanagement
PLM Open Hours - Service- und ErsatzteilmanagementPLM Open Hours - Service- und Ersatzteilmanagement
PLM Open Hours - Service- und Ersatzteilmanagement
Intelliact AG
 
PLM Open Hours - PDM vs ERP - Was in welchem System
PLM Open Hours - PDM vs ERP - Was in welchem SystemPLM Open Hours - PDM vs ERP - Was in welchem System
PLM Open Hours - PDM vs ERP - Was in welchem System
Intelliact AG
 
Fehlererkennung und Optimierung von Produktionsprozessen
Fehlererkennung und Optimierung von ProduktionsprozessenFehlererkennung und Optimierung von Produktionsprozessen
Fehlererkennung und Optimierung von ProduktionsprozessenThomas Schulz
 
Plm med dev-white-paper (deutsch)
Plm med dev-white-paper (deutsch)Plm med dev-white-paper (deutsch)
Plm med dev-white-paper (deutsch)Ralf Kittel
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM Trends
Intelliact AG
 
Stakeholder analyse v1
Stakeholder analyse v1Stakeholder analyse v1
Stakeholder analyse v1
PM Automotive Blog
 
PLM Open Hours - Projektfortschrittsübersicht anhand der Dokumentation
PLM Open Hours - Projektfortschrittsübersicht anhand der DokumentationPLM Open Hours - Projektfortschrittsübersicht anhand der Dokumentation
PLM Open Hours - Projektfortschrittsübersicht anhand der DokumentationIntelliact AG
 
PLM Open Hours - Heterogene Systemlandschaften
PLM Open Hours - Heterogene SystemlandschaftenPLM Open Hours - Heterogene Systemlandschaften
PLM Open Hours - Heterogene Systemlandschaften
Intelliact AG
 
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
Sps whitepaper   auvesy   datenmanagement in der automatisierungstechnikSps whitepaper   auvesy   datenmanagement in der automatisierungstechnik
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
AUVESY
 
PLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLM
PLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLMPLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLM
PLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLM
Intelliact AG
 
PLM Open Hours - Fertigungsgrobplanung (capable to promise)
PLM Open Hours - Fertigungsgrobplanung (capable to promise)PLM Open Hours - Fertigungsgrobplanung (capable to promise)
PLM Open Hours - Fertigungsgrobplanung (capable to promise)
Intelliact AG
 
UE in der agilen Produktentwicklung #iak10
UE in der agilen Produktentwicklung #iak10UE in der agilen Produktentwicklung #iak10
UE in der agilen Produktentwicklung #iak10Sandra Griffel
 

Was ist angesagt? (20)

PLM Open Hours - Fortschrittsübersicht bei Änderungen
PLM Open Hours - Fortschrittsübersicht bei ÄnderungenPLM Open Hours - Fortschrittsübersicht bei Änderungen
PLM Open Hours - Fortschrittsübersicht bei Änderungen
 
PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...
PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...
PLM Open Hours - Evaluation von Tools oder Apps im PLM (Product Lifecycle Man...
 
PLM Open Hours - Konfigurierung, ein zentrales Element in der Auftragsabwicklung
PLM Open Hours - Konfigurierung, ein zentrales Element in der AuftragsabwicklungPLM Open Hours - Konfigurierung, ein zentrales Element in der Auftragsabwicklung
PLM Open Hours - Konfigurierung, ein zentrales Element in der Auftragsabwicklung
 
PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...
PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...
PLM Open Hours - Effizienzsteiguerung durch Erkennen von Abhängigkeiten zwis...
 
Swiss PLM-Forum 2011 - Suchen und Finden im Digitalen Produkt
Swiss PLM-Forum 2011 - Suchen und Finden im Digitalen ProduktSwiss PLM-Forum 2011 - Suchen und Finden im Digitalen Produkt
Swiss PLM-Forum 2011 - Suchen und Finden im Digitalen Produkt
 
PLM Open Hours - Produktstrukturen im Auftragsabwicklungsprozess
PLM Open Hours - Produktstrukturen im AuftragsabwicklungsprozessPLM Open Hours - Produktstrukturen im Auftragsabwicklungsprozess
PLM Open Hours - Produktstrukturen im Auftragsabwicklungsprozess
 
PLM Open Hours - Best Practices in der Produkstrukturierung
PLM Open Hours - Best Practices in der ProdukstrukturierungPLM Open Hours - Best Practices in der Produkstrukturierung
PLM Open Hours - Best Practices in der Produkstrukturierung
 
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und SystemenPLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
PLM Open Hours - Fachübergreifende Entwicklung von Produkten und Systemen
 
PLM Open Hours - Service- und Ersatzteilmanagement
PLM Open Hours - Service- und ErsatzteilmanagementPLM Open Hours - Service- und Ersatzteilmanagement
PLM Open Hours - Service- und Ersatzteilmanagement
 
PLM Open Hours - PDM vs ERP - Was in welchem System
PLM Open Hours - PDM vs ERP - Was in welchem SystemPLM Open Hours - PDM vs ERP - Was in welchem System
PLM Open Hours - PDM vs ERP - Was in welchem System
 
Fehlererkennung und Optimierung von Produktionsprozessen
Fehlererkennung und Optimierung von ProduktionsprozessenFehlererkennung und Optimierung von Produktionsprozessen
Fehlererkennung und Optimierung von Produktionsprozessen
 
Plm med dev-white-paper (deutsch)
Plm med dev-white-paper (deutsch)Plm med dev-white-paper (deutsch)
Plm med dev-white-paper (deutsch)
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM Trends
 
Stakeholder analyse v1
Stakeholder analyse v1Stakeholder analyse v1
Stakeholder analyse v1
 
PLM Open Hours - Projektfortschrittsübersicht anhand der Dokumentation
PLM Open Hours - Projektfortschrittsübersicht anhand der DokumentationPLM Open Hours - Projektfortschrittsübersicht anhand der Dokumentation
PLM Open Hours - Projektfortschrittsübersicht anhand der Dokumentation
 
PLM Open Hours - Heterogene Systemlandschaften
PLM Open Hours - Heterogene SystemlandschaftenPLM Open Hours - Heterogene Systemlandschaften
PLM Open Hours - Heterogene Systemlandschaften
 
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
Sps whitepaper   auvesy   datenmanagement in der automatisierungstechnikSps whitepaper   auvesy   datenmanagement in der automatisierungstechnik
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
 
PLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLM
PLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLMPLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLM
PLM Open Hours - Reifegrad-Modelle als Mittel zur Standortbestimmung im PLM
 
PLM Open Hours - Fertigungsgrobplanung (capable to promise)
PLM Open Hours - Fertigungsgrobplanung (capable to promise)PLM Open Hours - Fertigungsgrobplanung (capable to promise)
PLM Open Hours - Fertigungsgrobplanung (capable to promise)
 
UE in der agilen Produktentwicklung #iak10
UE in der agilen Produktentwicklung #iak10UE in der agilen Produktentwicklung #iak10
UE in der agilen Produktentwicklung #iak10
 

Ähnlich wie Verbesserung des Risikomanagements für Medizinprodukte

FMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, Fahrzeugdiagnose
FMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, FahrzeugdiagnoseFMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, Fahrzeugdiagnose
FMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, Fahrzeugdiagnose
bbrand84
 
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiNavigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiMatthias Leisi
 
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen BereichAgile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Christoph Schmiedinger
 
AMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management Software
AMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management SoftwareAMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management Software
AMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management Software
Bjoern Bartels
 
Contech analyser fuer_robust_design_v1.6_dt
Contech analyser fuer_robust_design_v1.6_dtContech analyser fuer_robust_design_v1.6_dt
Contech analyser fuer_robust_design_v1.6_dt
Claudia Herrmann
 
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht management consultants
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Marc Bless
 
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Intelliact AG
 
Methodenstreit im Datenqualitätsmanagement
Methodenstreit im DatenqualitätsmanagementMethodenstreit im Datenqualitätsmanagement
Methodenstreit im DatenqualitätsmanagementVizlib Ltd.
 
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...
Michael Groeschel
 
Risikomanangement in der Entwicklung
Risikomanangement in der EntwicklungRisikomanangement in der Entwicklung
Risikomanangement in der Entwicklung
suxeo gmbh
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
Ernest Wallmueller
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
Eduard van den Bongard
 
Universelle Dienstleisterschnittstelle im Schadenmanagement
Universelle Dienstleisterschnittstelle im SchadenmanagementUniverselle Dienstleisterschnittstelle im Schadenmanagement
Universelle Dienstleisterschnittstelle im Schadenmanagement
SoftProject GmbH
 
Anforderungen an IT-sichere Steuerungssysteme
Anforderungen an IT-sichere SteuerungssystemeAnforderungen an IT-sichere Steuerungssysteme
Anforderungen an IT-sichere Steuerungssysteme
Torben Haagh
 
Application Lifecycle Management _ Was bedeutet das?
Application Lifecycle Management _ Was bedeutet das?Application Lifecycle Management _ Was bedeutet das?
Application Lifecycle Management _ Was bedeutet das?
Minerva SoftCare GmbH
 
Softwarewerkzeuge Portfoliomanagement Vortrag TU Darmstadt
Softwarewerkzeuge Portfoliomanagement Vortrag TU DarmstadtSoftwarewerkzeuge Portfoliomanagement Vortrag TU Darmstadt
Softwarewerkzeuge Portfoliomanagement Vortrag TU Darmstadt
Andreas Borchert
 
EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-SicherheitsmanagementEN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
Sven Wohlgemuth
 
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglichPLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
Intelliact AG
 
Fehlerbaumanalyse für Energiesysteme
Fehlerbaumanalyse für EnergiesystemeFehlerbaumanalyse für Energiesysteme
Fehlerbaumanalyse für EnergiesystemeE P
 

Ähnlich wie Verbesserung des Risikomanagements für Medizinprodukte (20)

FMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, Fahrzeugdiagnose
FMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, FahrzeugdiagnoseFMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, Fahrzeugdiagnose
FMEA Failure Mode Effect Analysis, FTA Fault Tree Analysis, Fahrzeugdiagnose
 
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiNavigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
 
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen BereichAgile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich
 
AMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management Software
AMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management SoftwareAMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management Software
AMSYS Life Cycle Management (LCM) Client - Obsoleszenz Management Software
 
Contech analyser fuer_robust_design_v1.6_dt
Contech analyser fuer_robust_design_v1.6_dtContech analyser fuer_robust_design_v1.6_dt
Contech analyser fuer_robust_design_v1.6_dt
 
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
Kirchner + Robrecht-White Paper "IT-Systeme erfolgreich auswählen"
 
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...
 
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
 
Methodenstreit im Datenqualitätsmanagement
Methodenstreit im DatenqualitätsmanagementMethodenstreit im Datenqualitätsmanagement
Methodenstreit im Datenqualitätsmanagement
 
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...
Prozessanalyse mit Process Mining, Studentisches Projekt der Hochschule Mannh...
 
Risikomanangement in der Entwicklung
Risikomanangement in der EntwicklungRisikomanangement in der Entwicklung
Risikomanangement in der Entwicklung
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
 
Universelle Dienstleisterschnittstelle im Schadenmanagement
Universelle Dienstleisterschnittstelle im SchadenmanagementUniverselle Dienstleisterschnittstelle im Schadenmanagement
Universelle Dienstleisterschnittstelle im Schadenmanagement
 
Anforderungen an IT-sichere Steuerungssysteme
Anforderungen an IT-sichere SteuerungssystemeAnforderungen an IT-sichere Steuerungssysteme
Anforderungen an IT-sichere Steuerungssysteme
 
Application Lifecycle Management _ Was bedeutet das?
Application Lifecycle Management _ Was bedeutet das?Application Lifecycle Management _ Was bedeutet das?
Application Lifecycle Management _ Was bedeutet das?
 
Softwarewerkzeuge Portfoliomanagement Vortrag TU Darmstadt
Softwarewerkzeuge Portfoliomanagement Vortrag TU DarmstadtSoftwarewerkzeuge Portfoliomanagement Vortrag TU Darmstadt
Softwarewerkzeuge Portfoliomanagement Vortrag TU Darmstadt
 
EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-SicherheitsmanagementEN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
 
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglichPLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
 
Fehlerbaumanalyse für Energiesysteme
Fehlerbaumanalyse für EnergiesystemeFehlerbaumanalyse für Energiesysteme
Fehlerbaumanalyse für Energiesysteme
 

Verbesserung des Risikomanagements für Medizinprodukte

  • 1. Dieses White Paper untersucht einige der klassischen Herausforderungen des Risikomanagements für Medizinprodukte und zeigt, wie mit der Siemens PLM Software-Lösung der Prozess erheblich verbessert werden kann. Siemens PLM Software bietet eine stabile Repository- und Workflowmanagement-Lösung, die Aufgaben wie Anforderungsmanagement und Reporting vereinfacht und gleich- zeitig eine tiefe Verfolgbarkeit automatisiert. www.siemens.comWhite Paper ausgegeben von: Siemens PLM Software Verbesserung des Risikomanagements für Medizinprodukte
  • 2. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 2 Inhalt Kurzdarstellung ..............................................................3 Die Herausforderungen des Risikomanagements für Medizinprodukte .......................................................4 Ein Datenmodell für Rückverfolgbarkeit .........................6 Ein Datenmodell für Risikomanagement .........................9 Dokumentendefinition Risikomanagement ...................15 Fazit ..............................................................................19
  • 3. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 3 Die Entwicklung von Medizinprodukten stellt schon so lange das Fundament der Ausübung und Verbesserung der Heilkunde dar, wie die Menschheit schon versucht, Menschen zu heilen. Mörser und Stößel wurden schon vor mehr als 6.000 Jahren zur Herstellung von Arzneipulver verwendet. Im Laufe der Jahrtausende sind unsere medizinischen Instrumente komplexer und leistungsfähiger geworden, was auch für die regulatorischen Rahmenbedingungen gilt. Vorschriften sind unerlässlich, da sie dazu beitragen, sicher- zustellen, dass medizinische Instrumente gemäß dem Prinzip der Verifizierung und Validierung (V&V) konstruiert werden, so dass sie die erforderlichen Spezifikationen erfül- len und für ihren vorgesehene klinische Zwecke eingesetzt werden können. In konzeptioneller Hinsicht ist Risikomanagement einfach zu beschreiben und zu verstehen. Aufgrund der Tatsache, dass potenziell gefährliche Situationen zu einem Schaden führen können, müssen diese dokumentiert und abgeschwächt werden, um Ergebnisse zu steuern und damit die Nutzung eines Geräts berechenbar und sicher zu machen. Wie jeder weiß, der mit Regelkonformität zu tun hat, können die Dinge allerdings sehr schnell komplex werden, beson- ders dann, wenn man mit vielerlei Vorschriften und in Konflikt stehenden Definitionen zurechtkommen und die Regelkonformität auf digitaler Ebene nachverfolgen muss. Diese Komplexität wird durch eine Vielzahl Faktoren verur- sacht, wie z. B. die Anzahl von Variablen, die für die Beschreibung der Beziehungen zwischen Systemkomponenten erforderlich sind, Optionen zur einzig- artigen und wiederverwendbaren Gestaltung dieser Konzepte, die m:n-Beziehungen, die für die Verfolgung der Regelkonformität erforderlich sind, und zuweilen vage oder verwirrende regulatorische Erwartungen. Tools, die derzeit zum Zwecke der Verfolgung der Komplexität eingesetzt werden, sind nicht nur simpel son- dern simplistisch. Obwohl Tabellen gut sind für die Verfolgung von 1:1-Beziehungen, werden sie schnell weit weniger nützlich bei der Verfolgung von 1:n- und m:n-Beziehungen, die für die Gewährleistung der Einhaltung gesetzlicher Bestimmungen bei der Entwicklung von Medizinprodukten erforderlich sind. Tabellen und Microsoft® Word Softwaredokumente sind nicht wirklich für die wichtige Aufgabe bestimmt, Rückerfolgbarkeit zu erhalten. Rückverfolgbarkeit bildet das Herzstück der Qualitätssicherung während der Konstruktions- und Entwicklungsphase und bleibt eine wichtige nachträgliche Kontrolle nach der Freigabe bei der Verknüpfung von Überwachungsberichten zurück zu spezifi- schen Produktanforderungen und V&V-Prozessen. Glücklicherweise bietet Siemens PLM Software eine leis- tungsstarke Lösung für die Entwicklung von Medizinprodukten. Kurzdarstellung
  • 4. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 4 Traditionell eine der schwierigeren Systementwicklungsaufgaben für Entwickler ist die Herausforderung der Implementierung eines effektiven Risikomanagements für Medizinprodukte. Das Schlagwort ist effektiv, da Risikomanagement ein lebendiger Prozess zu sein hat, der zu einem granularen Teil des Gesamtprozesses wird; vom ersten Entwurf über die Fertigung bis zur Marktbeobachtung nach Inverkehrbringen des Produkts. Die meisten der Schwierigkeiten haben ihren Ursprung darin, dass veraltete Technologie – statische schriftliche Dokumente und Tabellen – zur Verfolgung der komplexen und dynamischen Umgebung verwendet wurde, in der geltende Standards und sonstige Produktanforderungen im Laufe der Zeit und durch Entwurfs- und Entwicklungsiterationen verfolgt werden. Das Risikomanagement für medizinische Instrumente muss auf lebendigen Konstruktionselementen basieren, die aus einem zentralen Repository weitergegeben werden können, um die Dokumente der Beteiligten zu aktualisieren und die Versionssteuerung aufrechtzuerhalten. Ohne die Verwendung einer solchen Automatisierung zur Verfolgung der Beziehungen zwischen Konstruktionselementen, kann die Konstruktionsabsicht über die verschiedenen Workflows, Produktänderungen und aktualisierten Anforderungen hinweg verloren gehen. Anerkannte Standards Die Entwicklung von Medizinprodukten ist ein hochintegrier- ter und regulierter Prozess. Zwei wesentliche Standards, die das Risikomanagement für Medizinprodukte umfasst, sind ISO 14971:2009, die den Prozess für den Hersteller bei der Identifizierung der Gefährdungen in Verbindung mit Medizinprodukten festlegt und der ISO Technical Information Report (TIR) 24971:2013, der wertvolle Hinweise bezüglich der Anwendung bestimmter Bereiche der ISO 14971 bei der Umsetzung des Risikomanagements bietet. Europa hat darüber hinaus die Norm EN ISO 14971:2012 eingeführt, die sich in verschiedenen wichtigen Aspekten von den anderen unterscheidet und erforderlich ist, wenn ein Unternehmen Medizinprodukte in den europäi- schen Raum verkauft. Der durch diese Standards definierte Prozess ist in Abbildung 1 dargestellt. Risikoanalyse Risikobewertung Risikokontrolle Risikomanagement-Bericht Bewertung der Akzeptanz des Gesamt-Restrisikos Informationen aus der Produktion und der Produktion nachgelagerten Phasen • Bestimmungsgemäßer Gebrauch und Identifizierung der Charakteristika in Bezug auf die Sicherheit des Medizinprodukts • Ermittlung der Gefährdungen • Einschätzung des Risikos/der Risiken der jeweiligen Gefahrensituation • Risikokontrolloptionsanalyse • Umsetzung der Risikokontrollmaßnahme(n) • Bewertung des Restrisikos • Risiko-/Nutzenanalyse • In Verbindung mit Risikokontrollmaß- nahmen entstehende Risiken • Vollständige Risikokontrolle RisikomanagementRisikobeurteilung Abbildung 1. Risikomanagement-Workflow Die Herausforderungen des Risikomanagements für Medizinprodukte
  • 5. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 5 Von der Risikoanalyse zur Marktbeobachtung nach Inverkehrbringen des Produkts Eine Risikomanagement-Komplettlösung für Medizinprodukte muss die komplette Palette an Verknüpfungen abdecken, wie in Abbildung 1 gezeigt. Der grundlegende logische Verlauf schließt folgendes ein: • Risikoanalyse: ‒‒ Gefährdungen ‒‒ Vorhersehbare Reihenfolge der Ereignisse (zuweilen definiert als Reihenfolge der eigentlichen Ursachen) ‒‒ Gefahrensituationen ‒‒ Schäden • Risikobewertung: ‒‒ Werte für Eintrittswahrscheinlichkeit vor und nach der Durchführung von Risikominderungsmaßnahmen ‒‒ Schwere des Schadens ‒‒ Risikoprioritätsstufe ‒‒ Beurteilung der Risikoakzeptanz • Risikokontrolle: ‒‒ Konstruktionsanforderungen ‒‒ Realisierungsanforderungen ‒‒ Kennzeichungsanforderungen ‒‒ Verifizierung der Implementierung ‒‒ Verifizierung der Effektivität • Abschluss und Berichterstellung: ‒‒ Bewertung des Produktrestrisikos ‒‒ Bewertung der Risikoakzeptanz • Marktbeobachtung nach Inverkehrbringen des Produkts: ‒‒ Risikotrendkennzahlen ‒‒ Rückverfolgbarkeit der Risikoanalysetrendkennzahlen Wesentliche Bestandteile des Risikomanagementsystems Das Risikomanagementsystem sollte den Produktdesignern Informationen über Maßnahmen liefern, wie z. B.: • Auswirkungen auf Anwender – wie sich Konstruktions- Features auf Anwender auswirken • Gefahrensituationskontrollplan – Daten zur Steuerung der Entwicklung des Gefahrensituationskontrollplans, inkl. Risikominderungsmaßnahmen bei Konstruktion, Produktherstellung und Kennzeichnung • Feldergebnisse – Feldergebnisse sollten mit der Risikoanalyse verknüpft werden, um sicherzustellen, dass Problembereiche in der Analyse Berücksichtigung finden und die bei der Produktanwendung entdeckten Problembereiche schnell darin integriert werden • Risikominderungsmaßnahmen – Leistungsdaten, inkl. der Formulierung von Anforderungen zur Vergewisserung, dass V&V-Maßnahmen verwendet werden können, um die Umsetzung und Effektivität der Anforderungen sicherzustellen Die Leistungsfähigkeit relationaler Daten, durchsetzbarer Workflows und Automatisierung Sie können leicht überfordert sein bei der Verwendung tabellenbasierter Methoden zur Verfolgung aller gegenseiti- gen Abhängigkeiten der Risikoanalyse, -kontrolle, -berichterstellung und -über- wachung. Die Siemens PLM Software-Lösung für Medizinprodukte mit ihrer relationalen Datenstruktur, durch- setzbaren Workflows, Automatisierungen, Rückverfolgbarkeit und Reporting erleichtert das Verfolgen und Erstellen von Berichten mit den jeweils erforderlichen Risikomanagementinformationen. Und mit dem zentralen Repository der Lösung wird gewährleistet, dass jeder die gleichen Datensätze verwendet. Das Identifizieren von Schäden und sonstigen Artefakten ist so leicht wie per Knopfdruck Berichte mit den Arbeitselementen auszuführen, die systematisch mit den relevanten Daten ausgefüllt wurden.
  • 6. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 6 Rückverfolgbarkeit ist die Basis des Risikomanagements für Medizinprodukte. Von der Konstruktion, Entwicklung und Fertigungsausführung bis zur Marktbeobachtung nach Inverkehrbringen der Produkte müssen Unternehmen mitei- nander verbundene Arbeitselemente und ihre Beziehungen zu Konstruktions- und Rechtsvorschriften, Testfällen, V&V- Prozessen, Bestandskontrollen, Gefährdungen, Schäden und Risikominderungsmaßnahmen präzise zurückverfolgen können. Einige der grundlegenden Bausteine der Rückverfolgbarkeit sehen Sie in der in Abbildung 2 darge- stellten, Verfolgbarkeitsmatrix der Siemens PLM Software Vorlage für Medizinprodukte Das Flussdiagramm zeigt Elemente, die die Basis für die Entwicklung des Design V&V-Testplans und des Risikomanagement-Framework bilden. Umfassende Rückverfolgbarkeit Die Komplexität dieser Zusammenhänge kann durch Tabellen oder schriftliche Dokumente nicht in angemesse- nem Maße verfolgt werden. Zum Beispiel bereits früh im Konstruktionsprozess könnten Sie Nutzerbedürfnisse in einem Dokument angeben, das mit Word erstellt wurde. Bei jedem aufgeführten Nutzerbedürfnis könnten Sie eine Zahl am Ende des Satzes zum Zwecke der Verfolgung angeben. Beim Schreiben eines separaten Produktanforderungsdokuments können Sie jede Anforderung auf das Nutzerbedürfnis zurückverweisen, das von der Anforderung erfüllt wird. Die numerische Verknüpfung kann dann in einer Tabelle platziert werden und somit lässt sich die Abhängigkeit zwischen Nutzerbedürfnissen und Produktanforderungen zurückverfolgen. Risikoerfassung Schaden Gefahren- situation Fehler Testfall Aufgabe Designvorgaben Nutzerbedürf- nisse Produkt- anforderungen Fehler Bestandskontrollen Prozess- validierung Inspektion Lieferanten- kontrolle Ausgaben Quelle Erfüllen Implementie- ren Nutzt Implementiert Erklären Erfüllt Validiert Verifiziert Verifizieren Validieren Implementiert Aufgabe Fertigungsan- forderungen Verifiziert Nutzt Hat zur Folge Ursache Hat RisikohistorieHat Risikohistorie Mindern (PFMEA)Quelle Verfeinert Produkt- quellen Wird ausgelöst durch Mindert (PFMEA) Abbildung 2. Verfolgbarkeitsmatrix Ein Datenmodell für Rückverfolgbarkeit
  • 7. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 7 Jedoch während der Entwicklung ist es unwahrscheinlich, dass Sie jedes Entwicklungsergebnis, inkl. Unterbaugruppen mit jedem Nutzerbedürfnis oder jeder Produktanforderung werden verknüpfen können. Die Rückverfolgung gestaltet sich noch komplizierter, wenn Designdateiausgaben an die Produktion weitergeleitet werden, die üblicherweise einen Produktherstellungssplan und eine Tabelle zur Verfolgung ihrer eigenen produktions- technischen Anliegen erstellt. Um somit nun die Rückverfolgbarkeit von Nutzerbedürfnissen, Produktanforderungen und Ausgaben bis zu Fertigungsanforderungen festzustellen, müssen Sie sämtli- che dieser Dokumente öffnen. Sie wurden ggf. nicht aktualisiert und zentral gespeichert und haben keine Versionssteuerung. Sie werden die Elemente manuell finden und die Rückverfolgung jedes einzelnen Dokuments ent- schlüsseln müssen. Diese fehlende effiziente Rückverfolgung führt zu viel größeren Problemen und Verzögerungen für die Teams in ihrem Versuch, auf CAPA- (Korrektur- und Vorbeugemaßnahmen) Anforderungen zu reagieren. Tests von Benutzer- und Produktanforderungen Eine effiziente Lösung für die Verwaltung von Produktanforderungen sollte das Verknüpfen von Nutzerbedürfnissen mit Produkt- und Softwareanforderungen und den relevanten Tests vereinfachen, wie in Abbildung 3 dargestellt. Zum Beispiel zeigen die ersten Einträge in der Tabelle in Abbildung 3, dass das Nutzerbedürfnis 1010-3873 (das Medizingerät ist steril) der Produktanforderung 1010-3874 (das Medizingerät ist laut ISO 11135 mit Ethylenoxid sterili- siert) zugeordnet ist und auf den Test (1010-3821) verweist. Eine robuste Anforderungsmanagement-Lösung unterstützt Abbildung 3. Test von Benutzer- und Produktanforderungen Workflows und Rückverfolgbarkeit der gesamten Zusammenhänge in Konstruktion, Fertigung und Risikomanagement, die im Entwicklungsprozess von Medizinprodukten üblich sind. Die Lösung sollte die Integration von im Entwicklungsprozess verwendeten Begriffen unterstützen, wie z. B. die Integration von Standards, Richtlinien der United States Food and Drug Administration (FDA, US-amerikanische Behörde für die Zulassung von Lebens- und Arzneimittel), von ISO und der American Society for Testing and Materials (ASTM) und alle sonstigen geltenden Compliance-Daten sowie Bilder und textbasierte Erklärungen. Verfolgen untergeordneter Aspekte Einer der wesentlichen Vorteile in der Nutzung eines soliden Anforderungsmanagement-Tools 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 Punkts bei der Verwendung des Standardtextes sichergestellt. Dies kann entscheidend sein für die Ermittlung der Änderungsauswirkungen und die Sicherstellung, dass eine Änderung richtig auf alle relevan- ten Dokumente übertragen wird. Robuste Nach- und Rückverfolgbarkeit sind für die Dokumentation und Minimierung von Gefahrensituationen erforderlich, um Ergebnisse zu steuern und sicherzustellen, dass ein Medizinprodukt berechenbar und sicher ist.
  • 8. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 8 Best Practices Wie wir gesehen haben, ist die Implementierung eines effizienten und effektiven Risikomanagementsystems – besonders eines, das auf traditionellen Tabellen und statischen Dokumenten basiert – kompliziert und anspruchsvoll. Wie bereits erwähnt, ist dies auf eine Reihe von Faktoren zurückzuführen, wie z. B.: • Die Anzahl der Variablen, die zur Beschreibung der Beziehungen zwischen Systemkomponenten benötigt werden • Optionen zur einzigartigen und wiederverwendbaren Gestaltung dieser Konzepte • Die Fähigkeit, n:m-Datenbankbeziehungen zu unterstützen • Zuweilen vage oder verwirrende regulatorische Erwartungen Einige der Best Practices zur Anordnung von Komponenten des Systems zur Unterstützung der Marktbeobachtung nach Inverkehrbringen des Produkts beinhalten: • Zunächst sind die Daten in der Reihenfolge, in der sie überprüft werden, zu ordnen: Nach dem Inverkehrbringen des Produkts wird durch die Marktbeobachtung das Produkt basierend auf Schaden und Gefährdung für den Benutzer und Anzahl und Prozentsatz des Auftretens die- ser Gefährdungen in der Praxis bewertet. Ihre Datenfelder sollten mit den zurückgesendeten Daten direkt verknüpft sein, damit ein einfacher Vergleich und eine reibungslose Bearbeitung der auf dem Markt festgestellten Probleme ermöglicht wird. Sie sollten in der Lage sein, den Schadensfall auf dem Markt zu sehen und ihn direkt mit dem Risikomanagementprozess zu vergleichen. Dies ermöglicht Ihnen eine sofortige Bewertung, ob der Faktor, mit dem ermittelt wurde, wie oft die Gefahrensituation einen Schaden zur Folge hatte, korrekt ist, oder ob die Wahrscheinlichkeit des Auftritts der Gefahrensituation falsch eingeschätzt wurde. • Verwenden Sie gängige Terminologie für Datenfelder: Die Aufsichtsbehörden haben festgelegt, was unter Gefährdung oder Gefahrensituation zu verstehen ist. Sie sollten die genormte Terminologie in Ihr Modell einbauen, damit die Prüfer Ihre Absicht ohne zusätzliche Erklärungen besser verstehen. • Verknüpfungskomplexität minimieren: die Arbeitselemente sollte 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.
  • 9. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 9 Risikomanagementmethoden werden oftmals unzureichend verstanden und unpräzise definiert, weshalb es umso wich- tiger ist, ein solides Risikomanagementmodell zu haben. Ein gut konzipiertes, umfassendes Risikomanagement-Tool sollte in der Lage sein, ein Risikomanagement-Datenmodell zu unterstützen, dass die konsistente Verwendung von Definitionen, Arbeitselementen und Workflows zur Ermittlung und Minimierung von Schäden und Gefährdungen sicherstellt. Ihr Risikomanagement-Tool sollte den in Abbildung 4 beschriebenen logischen Ablauf basierend auf ISO 14971 Anhang E, unterstützen. Dieser ist für die Konformität mit den Zulassungsystemen für Medizinprodukte in den USA und Europa erforderlich. Er enthält Messelemente wie die Reihenfolge der Ereignisse, die Eintrittswahrscheinlichkeit einer Gefahrensituation und die Wahrscheinlichkeit, dass die Gefahrensituation einen Schaden zur Folge hat. Ein Risikomanagement-Datenmodell bringt Präzision in Ihre Abläufe. Es ermöglicht Ihnen, Definitionen festzulegen – basierend auf den jeweiligen konstruktiven oder regulato- rischen Anforderungen, mit denen Sie es zu tun haben – und dann eine konsistente Anwendung durchzusetzen, um die Datenqualität deutlich zu steigern. Durchsetzbare Workflows Die Erstellung eines Risikomanagement-Datenmodells mit der Siemens PLM Software-Lösung für Medizinprodukte gibt Ihnen die Möglichkeit, durchsetzbare Workflows zu entwi- ckeln, so dass alle Teammitglieder, unabhängig von ihrem geografischen Standort und sonstigen Variablen, die glei- chen definierten Workflows verwenden. Ihr Unternehmen kann die Workflows jedweder Art erstellen, die es benötigt. Nach der erfolgten Konzeption ist der entscheidende Punkt, dass Sie die konsistente Verwendung des Modells sicherstel- len können. Dies bietet ein einheitliches Framework (Rahmen), mit dem sichergestellt werden kann, dass Aufgaben vollständig erledigt werden, und welches Variablen einführt, die durch oberflächliche Definitionen oder unvollständige Aufgaben verursacht wurden. Der Prozess der Definition Ihrer Workflows in einem durch- setzbaren Framework bringt Klarheit in die Arbeit der Identifizierung möglicher Gefährdungen und Schäden und die Festlegung optimaler Risikominderungsstrategien. Durch dieses Framework wird auch eine Automatisierung ermöglicht. Nach erfolgreicher Erstellung des Framework geht es an die Erstellung der Arbeitselemente. Sie durchlau- fen den selben Bewertungsprozess bei der Identifizierung von Gefährdungen und Schäden, wie beim Arbeiten mit einer Tabelle, nun werden jedoch alle wechselseitigen Beziehungen verwaltet. Dies reduziert erheblich die Zeit, die für die Durchführung von Berechnungen, Rückverfolgungen und sonstigen normalerweise zeitintensiven Aufgaben benötigt wird. Die Wiederverwendung der Anforderungen und Beziehungen für ähnliche zukünftige Produkte bietet ebenfalls eine erhebliche Reduzierung des Arbeitsaufwands. Schadens- schwere Eintrittswahrschein- lichkeit des SchadensProzess P1 x P2 Gefährdung Gefahren- situation Schaden Risiko ReihenfolgederEreignisse P2 Exposition (P1) Hinweis: P1 ist die Wahrscheinlichkeit des Eintritts einer Gefahrensitu- ation. P2 ist die Wahrscheinlichkeit, dass eine Gefahrensituation zu einem Schaden führt. Abbildung 4. Logisches Flussdiagramm für Risikomanagement basierend auf ISO 14971, Anhang E. Ein Datenmodell für Risikomanagement
  • 10. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 10 Es ist wichtig, die Tatsache zu unterstreichen, dass eine Tabelle kein Framework ist. Sie ist nur eine Ansammlung von Zellen, die nicht für die Durchsetzung von Workflows oder die Arbeit mit relationalen Daten verwendet werden kann. Notwendigkeit der Konsistenz Das Framework und die von der Siemens PLM Lösung bereit- gestellte, unterstützende Umgebung verleihen Ihnen auch die Fähigkeit, Konsistenz bei anderen Elementen, wie z. B. Definitionen, Terminologie und Schreibweise durchzusetzen. Obwohl die Durchsetzung einer konsistenten Schreibweise auf den ersten Blick belanglos erscheinen könnte, kann fehlende Konsistenz die Qualität Ihrer Daten beeinträchtigen. Wenn Sie eine Datenbank nach einem Schaden, wie z. B. einem perforierten Darm durchsuchen, sehen Sie üblicher- weise nur einen Teil solcher Ereignisse, wenn das Wort perforiert in 30 Prozent Ihrer Tabelleneinträge falsch geschrie- ben wurde. Mit einem Risikomanagement-Tool, das eine konsistente Schreibweise durchsetzen kann, könnte man mit einer Suche alle Ereignisse identifizieren. Die Durchsetzung konsistenter Terminologie wird aus den gleichen Gründen benötigt. Wenn Sie z. B. mit den Gefahren eines arteriellen Ballons arbeiten, können einige Ereignisse als entfernter Ballon beschrieben werden und andere das gleiche Ereignis als deflatierten Ballon beschreiben; und da kann es ein breites Spektrum an Variationen geben. Indem man sich zu Beginn auf eine richtige Terminologie einigt, kann Ihr Framework die konsistente Verwendung dieser durchsetzen und Ihnen die Flexibilität bieten, Ereignisvariationen aufzunehmen und ordnungsgemäß zu dokumentieren.
  • 11. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 11 Arbeitselemente der Risikobewertung Die Implementierung eines systematischen, logischen Verlaufs für das Risikomanagement erfordert, dass Arbeitselemente und entsprechende Variablen definiert werden müssen, um die Analyse logisch zu gestalten. Abbildung 5 bietet ein Beispiel eines Flussdiagramms eines Systems, das mit dem im vorigen dargestellten Risikomanagement-Flussdiagramm in Abbildung 4, konform ist. Angeordnet wird das System mit den drei Arbeitselementen: Risikoerfassung, Schaden und Gefahrensituation (GS). Migration implementiert Migration effektiv Wesentliche Leistung ja/nein Abbildung 5. Arbeitselemente der Risikobewertung. **GS-Attribut Schritt1** P1 – Migrationswahrscheinlichkeit nach dem Eintritt der GS **GS-Attribut Schritt1** P1 – Migrationswahrscheinlichkeit vor dem Eintritt der GS Prozess/Quelle/ Designattribut Gefährdung/ Ursache Feststellung der Migration vor dem Eintritt Vorhersehbare Rei- henfolge der Ereignisse Feststellung der Migration nach dem Eintritt Gefahrensituation **Verknüpfung Beziehung** Schritt 2 P2 – Wahrscheinlich- keit, dass GS zu Schaden führt **Risikoberichtsda- ten** Schritt 3** Schaden vor Migration **Risikoberichtsda- ten** Schritt 3** Schaden vor Migration **Risikoberichtsda- ten** Schritt 4** RPS nach Migration **Risikoberichtsda- ten** Schritt 4** RPS vor Migration Beschreibung des Schadens **Schadensattribut – Schritt 4**** Schwere des Schadens Arbeitselement SchadenArbeitselement Gefahrensituation Arbeitselement Risikoerfassung Ursachen Analysiert durch 1/1 Analysiert durch 1/1 ■ Arbeitselemente GS ■ Arbeitselemente Schaden ■ Tabellengesteu- ert ■ Benutzereingabe Die gesamte Systemanalyse ist in Form einer traditionellen Fehlermöglichkeits- und -auswirkungsanalyse (Failure Mode and Effects Analysis (FMEA)).
  • 12. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 12 Diese Aufteilung ist dank mehrerer Faktoren praktisch: • Die Arbeit wird von unterschiedlichen Abteilungen fertiggestellt und überprüft, jeweils mit ihren entspre- chenden Workflows. Diese Zweiteilung ist logisch, da die Gefahrensituation größtenteils eine Engineering- Aufgabe ist, während die Risikoanalyse im Normalfall von Risikomanagement-Spezialisten und klinischem Personal durchgeführt wird. • Die Umrechnungs-/Wahrscheinlichkeitsvariablen kön- nen nicht ohne die im Arbeitselement beschriebenen Bestandteile festgelegt werden: beispielsweise kann die Eintrittswahrscheinlichkeit einer Gefahrensituation nicht ohne Kenntnis der Gefährdung, der vorherseh- baren 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 Arbeitselements an den behörd- lichen Fachbegriff zum Zweck der Klarheit für die Prüfer praktisch. Beispiele für Arbeitselemente Typen von Arbeitselementen können zur Erfüllung eines Spektrums von Anforderungen definiert werden. Wie im Vorigen erwähnt, lauten die grundlegenden drei Arbeitselemente: Schaden, Gefahrensituation und Risikoerfassung. Arbeitselement Schaden Das Arbeitselement Risikobeurteilung enthält Schadensbeschreibung und Schadensschwere. Beispielsweise könnte die Schadensbeschreibung für einen anaphylaktischen Schock einer Schadensschwere von vier auf einer Skala von eins bis fünf zugeordnet werden. Arbeitselement Gefahrensituation Die vollständig charakterisierte Gefahrensituation beinhaltet die Gefahrenquelle (Gefahr), die Beschreibung des fehler- haften Zustandes (vorhersehbare Ereignisabfolge) und die örtliche Wirkung (Gefahrensituation). Variable Bestandteile sind unter Anderem die Migrationswahrscheinlichkeit vor bzw. nach dem Eintritt der Gefahrensituation sowie die Feststellung der Migration vor und nach dem Eintritt Ein Beispiel dafür ist: • Elektromagnetische Strahlung > 1) Einschnitt in der Isolierung, 2) Leiter berührt 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 Arbeitselement Risikoerfassung Das Arbeitselement Risikoerfassung kombiniert eine ein- zelne Gefahrensituation mit einem Schaden, so dass beide als Paar analysiert werden können. Mehrere Arbeitsschritte werden in dieser Stufe zum erfolgreichen Abschluss der Risikobeurteilung durchgeführt. Der Faktor P2 wird als Beziehung zwischen Gefahrensituation und Schaden (Wahrscheinlichkeit, dass die Gefahrensituation zu einem Schaden führt) definiert. 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 P2 zur Verringerung der Eintrittswahrscheinlichkeit auf das Gefahrenniveau, dem der Anwender tatsächlich ausgesetzt wäre. Die Faktoren P1 und P2 werden dann multipliziert, um die Eintrittswahrscheinlichkeit des Schadens zu bestimmen. Der finale Faktor P wird dann zusammen mit der Schadensschwere zur Bestimmung des Risikoindex des Schadens/der Gefahrensituation verwendet. Die Risikoprioritätsstufe oder der Risikoindex wird berech- net, um die Auswirkung des Risikos auf Produkte und Unternehmenssysteme zu ermitteln. 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 Beispiele für diesen Arbeitsschritt. Schaden/Schwere In dem in Abbildung 6 beschriebenen System wird die Schadensschwere als eine von 5 Stufen, auf einer Skala von eins bis fünf, definiert.
  • 13. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 13 Eintritt einer Gefahrensituation (P1) Der Eintritt der Gefahrensituation wird auf der Basis der Wahrscheinlichkeit eingestuft. Die Tabelle in Abbildung 7 bietet ein Beispiel für ein solches Bewertungssystem. Wahrscheinlichkeit, dass Gefahrensituation zum Schaden führt (P2) Dass eine Gefahrensituation zu einem Schaden führt, wird auch anhand der Wahrscheinlichkeit eingestuft. Ein Beispiel dafür sehen Sie in Abbildung 8. Eintrittswahrscheinlichkeit eines Schadens Durch Multiplikation der oben definierten Eintrittswahrscheinlichkeitswerte können Sie die Eintrittswahrscheinlichkeit eines Schadens, wie in Abbildung 9 gezeigt, berechnen. Wahrscheinlichkeit, dass Gefahrensituation zum Scha- den führt (P2) Ebene Definitionen Schadenswahrschein- lichkeit Extrem unwahr- scheinlich (1) <=5 % Verletzung selten Unwahr- scheinlich aber möglich (2) 6 – 25 % Verletzung denkbar aber nicht wahrscheinlich Wahrschein- lich (3) 26 – 75 % Verletzung möglich Sehr wahr- scheinlich (4) 76 – 95 % Verletzung wird vor- aussichtlich eintreten Extrem wahr- scheinlich (5) >=96 % Verletzung wird eintreten Abbildung 8. Wahrscheinlichkeit, dass Gefahrensituation zu einem Schaden führt. P1 – Wahrscheinlichkeit des Eintritts einer Gefahrensituation Unwahrschein- lich (1) Entfernt vorstell- bar (2) Gelegentlich (3) Wahrscheinlich (4) Häufig (5) P2–Wahrscheinlichkeit,dass Gefahrensituation zueinemSchadenführt Extrem unwahrscheinlich (1) 1 1 1 1 2 Unwahrscheinlich, aber möglich (2) 1 1 1 1 3 Wahrscheinlich (1) 1 1 1 2 4 Sehr wahrscheinlich (4) 1 2 2 3 5 Extrem wahrscheinlich (5) 1 2 3 4 5 Abbildung 9. Eintrittswahrscheinlichkeit einer Gefahrensituation Kennzeichnung der Schadensschwere Ebene Definitionen Gering (1) Führt zu einer vorübergehenden Verletzung/ Beeinträchtigung, die keine professionelle medizinische Behandlung erfordert; Unannehmlichkeit Mittel (2) Vorübergehende Verletzung oder Beeinträchti- gung, die eine geringfügige professionelle medizinische Behandlung erfordert Schwerwiegend (3) Führt zu einer Verletzung oder Beeinträchti- gung, die eine größere professionelle medizi- nische Behandlung erfordert Kritisch (4) Führt zu einer dauerhaften Beeinträchtigung oder einer lebensbedrohlichen Verletzung Katastrophal (5) Führt zum Tod des Patienten Abbildung 6. Beschreibung der Schadensschwere auf einer Skala von eins bis fünf. Wahrscheinlichkeit des Eintritts einer Gefahrensituation (P1) Ebene Häufigkeit Häufig (5) >1/100 und <=1 Wahrscheinlich (4) >1/1000 und <=1 Gelegentlich (3) >1/10.000 und <=1/1000 Entfernt vorstell- bar (2) >1/100.000 und <=1/10.000 Unwahrschein- lich (1) >0 und <=1/100.000 Abbildung 7. Eintrittswahrscheinlichkeit einer Gefahrensituation
  • 14. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 14 Risikoprioritätsstufe Die Risikoprioritätsstufe (RPS) kann auf der Grundlage der in den obigen Tabellen hergeleiteten Schweregrade und Eintrittswahrscheinlichkeiten berechnet werden. Sie kann entweder aus einer Auswahltabelle oder einer Vielzahl an Berechnungsmethoden hergeleitet werden. Was unter einer Auswahltabelle zu verstehen ist, wird in Abbildung 10 verdeutlicht. Schadensschwere Schadenseintritt(p1xP2) Gering 1 Mittel 2 Schwerwiegend 3 Kritisch 4 Katastrophal 5 1 D D C C B 2 D D C B B 3 D C B B A 4 C C B A A 5 C B A A A Abbildung 10. Eintrittswahrscheinlichkeit einer Gefahrensituation Beispiel für einen Bericht Nach Abschluss der Beschreibung der jeweiligen Kombination aus Gefährdung/Schaden kann ein Beurteilungsbericht für Risikomanagement und Risikominderungsmaßnahmen erstellt werden. Ein solcher Bericht wird in Abbildung 11 auszugsweise als Screenshot dargestellt. FMEA-Analyse – Beurteilung Schaden/Gefährdung und Risikominderung Abbildung 11. Beurteilungsbericht für Schaden/Gefährdung und Risikominderung
  • 15. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 15 Definitionen sind sehr wichtig während des gesamten Prozesses des Risikomanagements für Medizinprodukte. Dazu gehört die Definition der Struktur und Inhalte der erforderlichen Dokumente, wie z. B. Risikomanagementplan, Risikoanalyse und Risikomanagementbericht. Die Struktur der Dokumente ist teilweise vorgeschrieben. Natürlich sollte speziell darauf geachtet werden, dass die Dokumente alle kraft Gesetz vorgeschriebenen Informationen enthalten. Risikomanagementplan Die Risikomanagementplan gemäß EN ISO 14971:2009 sollte enthalten: • Umfang der Aktivitäten • Zuweisung von Verantwortlichkeiten • Akzeptierbarkeitskriterien • Verifizierungsaktivitäten • Aktivitäten in Bezug auf Erfassung und Prüfung Risikoanalyse Die ISO-Norm erfordert einen schadensbasierten Ansatz der Risikoanalysedokumente. Elemente der Risikoanalyse beinhalten: • DFMEA (Device Failure Mode and Effects Analysis, Gerätefehlermöglichkeits- und auswirkungsanalyse) • PFMEA (Process Failure Mode and Effects Analysis, Prozessfehlermöglichkeits- und auswirkungsanalyse) • UseFMEA (Use Failure Mode and Effects Analysis, Anwendungsfehlermöglichkeits- und auswirkungsanalyse) • Schäden • Gefahrensituationen • Schadensbasierte Fehlerbaumanalyse (Fault Tree Analysis, FTA): Tabelle zur Datenbankverfolgbarkeit Risikomanagementbericht Mit dem Risikomanagementbericht gemäß EN ISO 14971:2009 sollte folgendes sichergestellt werden: • Der Risikomanagementplan wurde angemessen implementiert • Das Gesamtrisiko ist akzeptabel • Es wurden Methoden angewandt, um relevante Produktions- sowie nachträgliche Informationen zu erhalten Mit der Siemens PLM Software Lösung können Sie Informationen aus dem US-Federal Register im Tool als Anforderungsdokumente übernehmen und sie mit den unternehmensinternen SOP-Anforderungen verknüpfen. Eine Kombination beider trägt dazu bei, sicherzustellen, dass die rechtlichen Anforderungen durch die unternehmen- sinternen SOP-Anforderungen bzw. durch einen ISO-Standard erfüllt werden, der wiederum durch Befolgung der Designdokumente im Rahmen der firmeninternen SOP erfüllt wäre. Dieser Prozess gewährleistet die Verfolgbarkeit der Prüfschritte (Audit) von der Anforderungsquelle zu den vorhandenen Designdokumenten. 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. Dies Nachweishierarchie ist wie folgt: Gesetzliche Bestimmung Firmeninterne SOP-Anforderung/ISO-Standard Alle Projektdokumente Produktherstellungsdaten Daten zur Marktbeobachtung nach Inverkehrbringen des Produkts Dokumentendefinition Risikomanagement
  • 16. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 16 Integration von Dokumenten In Ihren Risikomanagement-Dokumenten sollten klar defi- nierte Elemente enthalten sein, wie z. B.: • Schäden: Schäden sollten im Mittelpunkt der umfassen- den 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, wer- den 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 wur- den, und was zur Korrektur des Problems in dem Bereich erforderlich ist. Dies bietet eine eindeutige Möglichkeit, um zu ermitteln, ob die eigentliche Ursache des Problems berücksichtigt wurde und was zur Korrektur des Problems in der Praxis erforderlich ist. Daneben kann das mit der Designfunktion in Verbindung stehenden Design V&V-Testverfahren 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äts zu iden- tifizieren. All diese Methoden (DFMEA, PFMEA,UseFMEA, Fehlerbaum, Beurteilung der klinischen Anwendung, klinische Tests, u.s.w.) sollten gefährliche Situationen ermitteln und in der schadensbasierten Analyse als mögli- che Ursachen des Anwenderschadens sichtbar machen • Gefahrenminderung: Jede für das Unternehmen mögliche Minderung von Gefahren sollte in der schadensbasierten Fehlerbaumanalyse 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 Produktanwendung, 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 • Produktetikettierung: Die Risikominderungsstrategie ist zudem die beste Datenquelle für die Produktetikettierung. Anstatt ein ähnliches Gerät zu verwenden, das gegen- wä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. Dokumentenstruktur Bei der Planung Ihres Dokumentationsgesamtpakets sollten Sie sicherstellen, dass es folgende Dokumente enthält: • Strukturvorgaben: Die Unterlagen sollten zumindest ein Dokument (zumeist eine Vielzahl an Dokumenten) enthalten, das Nutzerbedürfnisse sowie Produktanforderungen definiert, wie es im Produktanforderungsdokument (PRD) der Fall ist. Diese Dokumente werden oftmals erstellt, um den gegenwärtigen Entwicklungsprozess sowie die am Entwicklungsprozess mitwirkenden Zulieferer wider- zuspiegeln. 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. Andererseits können die Testprozesse für alle laut Produktqualitätsplan erforderlichen Daten (Erstmusterprüfung, prozessinterne Tests, Eingangsprüfung) verfolgt werden, wenn alle Spezifizierungen im System sind, wodurch ein vollständi- geres 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.
  • 17. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 17 • Designverifizierung und Validierungsplan: Wie zuvor erwähnt, ist die Suche nach Nutzerbedürfnissen, Produktanforderungen und deren entsprechendem Testfall innerhalb der Projektdatei eine leistungsstarke Funktionalität. Dokumente für die Produktion Sie sollten über eine robuste Sammlung von Dokumenten für die Produktion verfügen, wie z. B.: • 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 zur Konstruktion des Produkts angewandten Prozesse, die Ermittlung aller Prozesse, welche einer Validierung bedürfen, und die Aufbewahrung für die Testobjekte der Prozessvalidierung. Die Prozessvalidierungsarbeit ist eine Art 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 Konstruktionsablauf festgelegt ist, wird der Qualitätsmanagementplan zur Sicherstellung der Produktqualität mit Aspekten zur Produktleistungsüberprüfung im Rahmen des Konstruktionsplan 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. Bewertung der Ziele der Qualitätsrichtlinie Die Ziele der firmeninternen Qualitätsrichtlinie müssen in jedem Qualitätsmanagement-Beurteilungsmeeting 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 für Kontrollstellen sind u.a.: • Interne Audits • Audits durch Dritte • Eingangsprüfung • Erstmusterprüfung • Fertigungskontrolle • Produktbezogene Reklamationen • Anwendungsausfälle Würden diese Tests in das Entwicklungskontrollprogramm aufgenommen, könnten die Daten der Tests automatisch in den Management-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.
  • 18. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 18 Personalisierung Visual Reporting-Tools erlauben dem Programm-Manager höchste Flexibilität bei der Festlegung des Formats und der für jeden erforderlichen Bericht notwendigen Daten. Mit dieser Flexibilität geht die leistungsstarke Funktion einher, Berichts- und Datenstrukturen mit unerwarteten oder kom- plizierten Ergebnissen zu ändern. Berichtsausgaben und Hintergrunddatenmanipulationen sollten sorgfältig analy- siert und Änderungen getestet werden, ehe das Tool auf einem umfassenden Datensatz implementiert werden kann. Möglichkeiten zur personalisierten Gestaltung sind u.a.: • RPS-Berechnung – einzigartige Methoden zur Berechnung der Prioritätsstufe des Produktrisikos. Vielfältige Methoden können dabei zur Anwendung kommen. Schweregrad X Eintritt, Schweregrad 2 X Eintritt, Schweregrad X Erkennung X 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 Sie ggf. Ihre eine individuelle Risikoprioritätsstufe zur Anpassung an die Bedürfnisse Ihres Unternehmens berechnen möchten. • Verknüpfungsbeziehungen – In manchen Fällen wird das System ausgehend von den produktbezo- genen 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. Die gute Nachricht ist, dass die Siemens PLM Software flexibel ist und beide Ansätze unterstützt. • Arbeitselemente-Terminologie – Es kann oftmals viele unterschiedliche Bezeichnungen für dasselbe logische Konzept geben. Üblicherweise muss das System mit der Firmenpolitik vereinbar sein. • DFMEA-, PFMEA-Terminologie – Obwohl FMEA bereits seit einiger Zeit existiert, variiert die Nutzung dieses Tools stark von Branche zu Branche. Auch die Medizinproduktbranche hat sich gelegentlich unter- schiedliche 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 Konstruktionsdesign. Das Format des Berichts und die dargestellten Verknüpfungen müssten geändert werden, wenn ein beliebiger Strukturbestandteil (Arbeitselemente, Verknüpfungsbeziehungen, Hintergrundinformationen) verändert wird. Ein gutes Beispiel hierfür sind Workflows zur Freigabe von Arbeitselementen.
  • 19. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 19 Fazit Es ist nicht verwunderlich, dass die zur erfolgreichen Entwicklung eines medizinischen Geräts erforderliche Systemarchitektur von Programm-Managern gelegentlich als erdrückend empfunden wird. Anfangs ist man geneigt zu denken, „es wäre schon nicht so schwer. Ich erstelle nur eine Liste“ und starte den Prozess mit einer Excel®-Tabelle für die Entwicklungsvorgaben und einem Word-Dokument für die erste Erstellung der Produktanforderungen. Jedoch stellt man nach einem allgemeinen Überblick über die Komplexität des Entwicklungsprozesses fest, dass das Projekt mit stetig wachsendem Aufwand und einer exponen- tiellen Steigerung der Fehleranfälligkeit einhergeht. Die Siemens PLM Software-Lösung ist ein Tool, das Sie bei der Bearbeitung komplexer Entwicklungsschritte und Verknüpfungsbeziehungen unterstützt. Mit dieser Lösung bedürfen die eingerichteten Verknüpfungen keiner kostspie- ligen Pflege, während Programm-Updates in einer strukturierten und durchsuchbaren Umgebung ausgeführt werden können.
  • 20. White Paper ausgegeben von: Siemens PLM Software White Paper | Verbesserung des Risikomanagements für Medizinprodukte 20 www.siemens.com/plm © 2017 Siemens Product Lifecycle Management Software Inc. Siemens und das Siemens- Logo sind eingetragene Marken der Siemens AG. ALM, D-Cubed, Femap, Fibersim, Geolus, GO PLM, I-deas, Insight, JT, NX, Parasolid, Polarion, Solid Edge, Syncrofit, Teamcenter und Tecnomatix sind Marken oder eingetragene Marken der Siemens Product Lifecycle Management Software Inc. oder ihrer Niederlassungen in den USA und in anderen Ländern. Microsoft und Excel sind Marken oder eingetragene Marken der Microsoft Corporation. Alle anderen Marken, eingetragenen Marken oder Dienstleistungsmarken sind Eigentum der jeweiligen Inhaber. 63108-A7 5/17 o2e Siemens PLM Software Siemens PLM Software, eine Business Unit der Siemens Digital Factory Division, ist ein führender, weltweit tätiger Anbieter von Software, Systemen und Dienstleistungen für das Product Lifecycle Management (PLM) und das Fertigungsmanagement (MOM) mit über 15 Millionen lizenzierten Anwendern und mehr als 140.000 Kunden in aller Welt. Siemens PLM Software mit Sitz in Plano, Texas, entwickelt in enger Zusammenarbeit mit seinen Kunden branchenspezifische Softwarelösungen, die Unternehmen in allen Bereichen durch Umsetzung bedeutender Innovationen einen nachhaltigen Wettbewerbsvorteil verschaffen. Weitere Informationen über die Produkte und Leistungen von Siemens PLM Software unter www.siemens.com/plm. Siemens PLM Software Deutschland Siemens Industry Software GmbH Franz-Geuer-Straße 10 50823 Köln Tel. +49 221 20802-0 Schweiz Siemens Industry Software AG Freilagerstrasse 40 8047 Zürich Tel. +41 44 755 72 72 info.ch.plm@siemens.com Österreich Siemens Industry Software GmbH Wolfgang-Pauli-Straße 2 4020 Linz Tel. +43 732 37 75 50 office-linz.plm@siemens.com Hauptsitz Granite Park One 5800 Granite Parkway Suite 600 Plano, TX 75024 USA +1 972 987 3000