qcompetence empfiehlt: Anforderungsmanagement bei Medizinprodukten mit Hilfe von Risikomanagement

Freie-PresseMitteilungen.de: www.qcompetence.de
info@qcompetence.de

Für die Produktentwicklung und Zulassung von Medizinprodukten ist das Anforderungsmanagement bzw. Requirement Engineering (z.B. Lastenheft) ebenso essentiell wie das Risikomanagement. Das Risikomanagement dient der Erkennung und angemessenen Kontrolle von Produktrisiken, was wiederum Auswirkung auf das Anforderungsmanagement hat. Die Frage lautet dabei immer: Was ist das Ziel meines Produkts bzw. Projekts? Was muss mein Produkt können? Welche Bedürfnisse / Anforderungen meines Kunden bzw. welche gesetzliche Anforderungen müssen umgesetzt werden? Welche Risiken sind mit der Anwendung meines Produktes verbunden? Wurden sie vollständig und umfassend erkannt? Wurden die geeigneten Risikominimierungs¬maßnahmen definiert? Wie groß ist der Kostenfaktor, der sich aus einem Produktrisiko ergibt? Kann auch dieser angemessen kontrolliert werden?

Doch zurück zum Ausgangspunkt der Fragestellung nach den "richtigen" Anforderungen. Das Problem ist dabei fast immer, wie Interessengruppen mit ihren jeweiligen Anforderungen angemessen zu berücksichtigen sind. Dabei sollte der Anforderungskatalog verständlich, handhabbar und übersichtlich gestaltet sein. Das ist in Bezug auf die Entwicklung komplexer Medizinprodukte nicht immer ohne weiteres möglich. Ein Lösungsansatz ist, das Gesamtprodukt bzw. Projekt in Module zu unterteilen. Dadurch werden Änderungen von Anforderungen auf definierte Bereiche = Module begrenzt. Das wiederum würde die Pflege des Anforderungsprofils bzw. das Änderungsmanagement von Anforderungen sehr erleichtern. Ebenso könnte die Kommunikation zwischen den Beteiligten an der Produktentwicklung besser umgesetzt werden.

Doch weitere Herausforderungen sind dadurch noch nicht gelöst. Oftmals sind viele Interessen¬gruppen an einem Projekt beteiligt, die aus unterschiedlichen Bereichen kommen und "verschiedene" Sprachen sprechen. Diese Sprache beschreibt allgemeinverständlich und in Form von "Anwender Geschichten" den "alltäglichen" Nutzen eines Medizinproduktes für den Anwender, z.B. einen Arzt oder eine Pflegekraft. Deshalb ist eine Sprache für die Beschreibung von Anforderungen nötig, die alle verstehen. Das heißt, die Sprache ist eher umgangssprachlich als technisch, sie ist bildhaft und arbeitet mit Analogien, ihr Inhalt ist qualitativ und nicht quantitativ. Ebene der technischen Entwicklung eines Produktes erfolgt die Definition von Anforderungen in einer technischen Sprache, was auch erst auf der modularen Ebene der Bauteile oder Komponenten des Medizinproduktes sinnvoll ist. Von der Ebene des Anwenders zu der des Entwicklers muss dann eine Übersetzung der begrifflichen Beschreibung von Anforderungen stattfinden.

Wie kann diese Übersetzung aussehen? Hilfestellung kann dabei die Methode des modularen Risikomanagements bieten. Die Methode der Risikobewertung eignet sich hervorragend, um aus Maßnahmen, die das Risiko eines Medizinproduktes reduzieren, die Anforderungen an seine Module (=Bauteile, Komponenten) abzuleiten. Diese Module sind die "Träger" dieser Maßnahmen. Beispielsweise stellt eine Sterilverpackung als Bestandteil / Modul eines sterilen Medizinproduktes die Anforderung nach Aufrechterhaltung der Sterilität des Medizinproduktes sicher. Das bedeutet, modulares Risikomanagement dient somit auch der Generierung von Anforderungen für die jeweiligen Module aus denen das Produkt besteht. Jedes Modul kann dann in der "Sprache" beschrieben und spezifiziert werden, die für seine Entwicklung bzw. Erstellung am Besten geeignet ist.

Doch wie können Anforderungen hinsichtlich ihrer Wichtigkeit bzw. ihres Risikos gewichtet werden? Dies kann ebenfalls mit der Methodik der Risikobewertung umgesetzt werden. Der Ansatz ist, dass eine nicht realisierte Anforderung ein Risiko darstellt. Zuerst ist deshalb eine Risikoabschätzung für die Größe des Risikos erforderlich, um akzeptable Risiken von nicht akzeptablen zu unterscheiden. Zweitens, wenn ein Risiko als nicht akzeptabel bewertet wurde, müssen geeignete und wirksame Maßnahmen zur Risikominimierung definieren werden. Das Ziel dieser Methodik ist die Entwicklung eines für den Kunden optimalen Produktes, dessen Risiken umfassend bewertet und erheblich vermindert worden sind, bei gleichzeitig reduziertem Entwicklungsaufwand.

Eine weitere Herausforderung ist, dass Anforderungen miteinander verlinkt bzw. die Entwicklung von Anforderungen rückverfolgt werden können. Z.B. ist das der Fall bei der Entwicklung von medizinischer Software. Softwareanwendungen, die als OEM-Produkte weiter veräußert werden - nachdem sie unter eigenem Namen in Verkehr gebracht worden sind -, haben ein ähnliches bzw. "verwandtes" aber nicht identisches Anforderungsprofil wie das Ausgangsprodukt. Der Grund: Der jeweilige Vertragspartner stellt noch zusätzliche Anforderungen an das Produkt, die das Ausgangsprodukt eventuell nicht hat. Oftmals beziehen sich diese Anforderungen an die Kompatibilität mit einer definierten Hardware des Partners, auf der die Software laufen soll. Obwohl es sich um fast identische Produkte handelt, ist oftmals das Anforderungsmanagement des einen Entwicklungsprojektes nicht auf das des anderen abgestimmt. Vielmehr sind beide voneinander losgelöst. Änderungen der Anforderungen in einem Projekt werden nicht zwangsläufig an andere Projekte kommuniziert. Wichtiges Wissen und wertvolle Erkenntnisse für die Produktentwicklung werden ggf. nicht berücksichtigt, obwohl dieses Wissen und diese Erkenntnisse im Unternehmen vorhanden sind.

Legt man die oben beschriebene Situation des Nicht-Verlinktseins von "verwandten" Entwicklungsprojekten zugrunde, dann werden Produktreklamationen von Kunden und Partnern nur für die jeweiligen Produkte berücksichtigt, auf die sich die Reklamation bezieht. "Verwandte" Produkte, die dieselben oder ähnliche Anforderungen wie das reklamierte Produkt haben, bleiben dabei unberücksichtigt. Das heißt, die Reklamation eines Produktfehlers fließt nicht in das Anforderungs- und Risikomanagement des "verwandten" Medizinproduktes ein.
Wie können also Synergien hergestellt werden? Wie kann eine Kommunikation zwischen den Projektteams in Bezug auf Anforderungs- und Risikomanagement "verwandter" Produkte stattfinden?

Die Lösung könnte eine relationale Datenbank-Anwendung sein, die ein Risk driven Requirement Engineering ermöglicht, wobei die einzelnen Anforderungen je nach "Verwandtschaft" über eine Matrixstruktur aufeinander referenzieren. Zusätzlich zur Erfüllung der gesetzlichen Anforderungen in Bezug auf Risikomanagement gemäß der EG-Richtlinie für Medizinprodukte 93/42/EWG und der Norm EN ISO 14971, werden auch die Normforderungen für das Qualitätsmanagement für die Herstellung von Medizinprodukten gemäß der EN ISO 13485 und der spezifischen Norm für die Entwicklung von medizinischer Software gemäß der EN ISO 62304 "Medizingeräte-Software, Software-Lebenszyklus-Prozesse" als auch Anforderungen in Bezug auf die Validierung von Software-Anwendungen (Stichwort: Gebrauchstauglichkeit bzw. Usability) berücksichtigt.

Sollten Sie zu Risikomanagement und Requirement Engineering noch weitere Fragen haben, würden wir uns sehr über Ihren Anruf oder Ihre Email freuen.
München, Thomas Baier
Senior QM Berater der qcompetence

Die qcompetence GmbH ist ein Beratungsunternehmen für Risiko- und Qualitätsmanagement sowie für die die Zulassung von Medizinprodukten.
qCompetence GmbH
Herr Thomas Baier
Edisonstr. 6
85716
Unterschleißheim
tbaier@qcompetence.de
+ 49(0)89 316 0598 770
http://qcompetence.de

www.qcompetence.de
info@qcompetence.de

Für die Produktentwicklung und Zulassung von Medizinprodukten ist das Anforderungsmanagement bzw. Requirement Engineering (z.B. Lastenheft) ebenso essentiell wie das Risikomanagement. Das Risikomanagement dient der Erkennung und angemessenen Kontrolle von Produktrisiken, was wiederum Auswirkung auf das Anforderungsmanagement hat. Die Frage lautet dabei immer: Was ist das Ziel meines Produkts bzw. Projekts? Was muss mein Produkt können? Welche Bedürfnisse / Anforderungen meines Kunden bzw. welche gesetzliche Anforderungen müssen umgesetzt werden? Welche Risiken sind mit der Anwendung meines Produktes verbunden? Wurden sie vollständig und umfassend erkannt? Wurden die geeigneten Risikominimierungs¬maßnahmen definiert? Wie groß ist der Kostenfaktor, der sich aus einem Produktrisiko ergibt? Kann auch dieser angemessen kontrolliert werden?

Doch zurück zum Ausgangspunkt der Fragestellung nach den "richtigen" Anforderungen. Das Problem ist dabei fast immer, wie Interessengruppen mit ihren jeweiligen Anforderungen angemessen zu berücksichtigen sind. Dabei sollte der Anforderungskatalog verständlich, handhabbar und übersichtlich gestaltet sein. Das ist in Bezug auf die Entwicklung komplexer Medizinprodukte nicht immer ohne weiteres möglich. Ein Lösungsansatz ist, das Gesamtprodukt bzw. Projekt in Module zu unterteilen. Dadurch werden Änderungen von Anforderungen auf definierte Bereiche = Module begrenzt. Das wiederum würde die Pflege des Anforderungsprofils bzw. das Änderungsmanagement von Anforderungen sehr erleichtern. Ebenso könnte die Kommunikation zwischen den Beteiligten an der Produktentwicklung besser umgesetzt werden.

Doch weitere Herausforderungen sind dadurch noch nicht gelöst. Oftmals sind viele Interessen¬gruppen an einem Projekt beteiligt, die aus unterschiedlichen Bereichen kommen und "verschiedene" Sprachen sprechen. Diese Sprache beschreibt allgemeinverständlich und in Form von "Anwender Geschichten" den "alltäglichen" Nutzen eines Medizinproduktes für den Anwender, z.B. einen Arzt oder eine Pflegekraft. Deshalb ist eine Sprache für die Beschreibung von Anforderungen nötig, die alle verstehen. Das heißt, die Sprache ist eher umgangssprachlich als technisch, sie ist bildhaft und arbeitet mit Analogien, ihr Inhalt ist qualitativ und nicht quantitativ. Ebene der technischen Entwicklung eines Produktes erfolgt die Definition von Anforderungen in einer technischen Sprache, was auch erst auf der modularen Ebene der Bauteile oder Komponenten des Medizinproduktes sinnvoll ist. Von der Ebene des Anwenders zu der des Entwicklers muss dann eine Übersetzung der begrifflichen Beschreibung von Anforderungen stattfinden.

Wie kann diese Übersetzung aussehen? Hilfestellung kann dabei die Methode des modularen Risikomanagements bieten. Die Methode der Risikobewertung eignet sich hervorragend, um aus Maßnahmen, die das Risiko eines Medizinproduktes reduzieren, die Anforderungen an seine Module (=Bauteile, Komponenten) abzuleiten. Diese Module sind die "Träger" dieser Maßnahmen. Beispielsweise stellt eine Sterilverpackung als Bestandteil / Modul eines sterilen Medizinproduktes die Anforderung nach Aufrechterhaltung der Sterilität des Medizinproduktes sicher. Das bedeutet, modulares Risikomanagement dient somit auch der Generierung von Anforderungen für die jeweiligen Module aus denen das Produkt besteht. Jedes Modul kann dann in der "Sprache" beschrieben und spezifiziert werden, die für seine Entwicklung bzw. Erstellung am Besten geeignet ist.

Doch wie können Anforderungen hinsichtlich ihrer Wichtigkeit bzw. ihres Risikos gewichtet werden? Dies kann ebenfalls mit der Methodik der Risikobewertung umgesetzt werden. Der Ansatz ist, dass eine nicht realisierte Anforderung ein Risiko darstellt. Zuerst ist deshalb eine Risikoabschätzung für die Größe des Risikos erforderlich, um akzeptable Risiken von nicht akzeptablen zu unterscheiden. Zweitens, wenn ein Risiko als nicht akzeptabel bewertet wurde, müssen geeignete und wirksame Maßnahmen zur Risikominimierung definieren werden. Das Ziel dieser Methodik ist die Entwicklung eines für den Kunden optimalen Produktes, dessen Risiken umfassend bewertet und erheblich vermindert worden sind, bei gleichzeitig reduziertem Entwicklungsaufwand.

Eine weitere Herausforderung ist, dass Anforderungen miteinander verlinkt bzw. die Entwicklung von Anforderungen rückverfolgt werden können. Z.B. ist das der Fall bei der Entwicklung von medizinischer Software. Softwareanwendungen, die als OEM-Produkte weiter veräußert werden - nachdem sie unter eigenem Namen in Verkehr gebracht worden sind -, haben ein ähnliches bzw. "verwandtes" aber nicht identisches Anforderungsprofil wie das Ausgangsprodukt. Der Grund: Der jeweilige Vertragspartner stellt noch zusätzliche Anforderungen an das Produkt, die das Ausgangsprodukt eventuell nicht hat. Oftmals beziehen sich diese Anforderungen an die Kompatibilität mit einer definierten Hardware des Partners, auf der die Software laufen soll. Obwohl es sich um fast identische Produkte handelt, ist oftmals das Anforderungsmanagement des einen Entwicklungsprojektes nicht auf das des anderen abgestimmt. Vielmehr sind beide voneinander losgelöst. Änderungen der Anforderungen in einem Projekt werden nicht zwangsläufig an andere Projekte kommuniziert. Wichtiges Wissen und wertvolle Erkenntnisse für die Produktentwicklung werden ggf. nicht berücksichtigt, obwohl dieses Wissen und diese Erkenntnisse im Unternehmen vorhanden sind.

Legt man die oben beschriebene Situation des Nicht-Verlinktseins von "verwandten" Entwicklungsprojekten zugrunde, dann werden Produktreklamationen von Kunden und Partnern nur für die jeweiligen Produkte berücksichtigt, auf die sich die Reklamation bezieht. "Verwandte" Produkte, die dieselben oder ähnliche Anforderungen wie das reklamierte Produkt haben, bleiben dabei unberücksichtigt. Das heißt, die Reklamation eines Produktfehlers fließt nicht in das Anforderungs- und Risikomanagement des "verwandten" Medizinproduktes ein.
Wie können also Synergien hergestellt werden? Wie kann eine Kommunikation zwischen den Projektteams in Bezug auf Anforderungs- und Risikomanagement "verwandter" Produkte stattfinden?

Die Lösung könnte eine relationale Datenbank-Anwendung sein, die ein Risk driven Requirement Engineering ermöglicht, wobei die einzelnen Anforderungen je nach "Verwandtschaft" über eine Matrixstruktur aufeinander referenzieren. Zusätzlich zur Erfüllung der gesetzlichen Anforderungen in Bezug auf Risikomanagement gemäß der EG-Richtlinie für Medizinprodukte 93/42/EWG und der Norm EN ISO 14971, werden auch die Normforderungen für das Qualitätsmanagement für die Herstellung von Medizinprodukten gemäß der EN ISO 13485 und der spezifischen Norm für die Entwicklung von medizinischer Software gemäß der EN ISO 62304 "Medizingeräte-Software, Software-Lebenszyklus-Prozesse" als auch Anforderungen in Bezug auf die Validierung von Software-Anwendungen (Stichwort: Gebrauchstauglichkeit bzw. Usability) berücksichtigt.

Sollten Sie zu Risikomanagement und Requirement Engineering noch weitere Fragen haben, würden wir uns sehr über Ihren Anruf oder Ihre Email freuen.
München, Thomas Baier
Senior QM Berater der qcompetence

Die qcompetence GmbH ist ein Beratungsunternehmen für Risiko- und Qualitätsmanagement sowie für die die Zulassung von Medizinprodukten.
qCompetence GmbH
Herr Thomas Baier
Edisonstr. 6
85716
Unterschleißheim
tbaier@qcompetence.de
+ 49(0)89 316 0598 770
http://qcompetence.de

Software-Infos-247.de: News, Infos & Tipps zu Software

Software-Infos-24/7.de - Infos, News & Tipps rund um Software !



Software-Infos-247.de: News, Infos & Tipps zu Software	Seiten-Suche:


Software-Infos-24/7.de <-Startseite Anmelden oder Einloggen