Risikomanagement und Systemarchitektur

Für das Risikomanagement ist das Vorgehen in „Systeme in der Medizintechnik – sinnvolle Grenzen setzen“ eine vorteilhafte Hilfestellung. Allerdings genügt dabei nicht die Systemgrenze als solches, sondern wir müssen noch darüber hinaus blicken.

Die erste Frage, die sich aus dem Blogeintrag ergibt ist folgende: „Kann ich Risiken nur aufgrund der Architektur ermitteln?“ – Dies ist natürlich nicht richtig, da schon vor der Architektur mit der Sammlung von Risiken und Risikosituationen begonnen werden sollte. Diese Risiken beziehen sich dann allerdings auf die Zweckbestimmung und den Produkteinsatz und sind damit oberhalb der Systemgrenzen. Bei der Ermittlung dieser Risiken rate ich Ihnen, die vorhandenen Fragen zu Gefährdungen und auch die bekannten Hazard-Kataloge aus der EN ISO14971, IEC8001, IEC TR 80002 und der IEC60601-1 zu prüfen, und zu ermitteln was für Sie zutrifft. Gefährdungen, die nicht zutreffen, sind mit Begründung zu dokumentieren. Dies erleichtert Ihnen im späteren Verlauf die Arbeit mit den Prüflaboren. Und von hier müssen wir mittels der Architektur in den Sinkflug zum Produkt gleiten.

Je mehr man über ein System nachdenkt, umso komplexer und unschärfer werden die Risiken im System-Gesamtwerk. Dies liegt an der von Goran beschriebenen Definitionsunklarheit und der damit einhergehenden Verwendung des Begriffs „System“. Für den Risikomanager ist dies allerdings egal, welche Definition greift, denn er sieht das System/Gerät/Produkt von außen, also auf alle der bezeichneten Schnittstellen und die im Blog beschriebene Systemabgrenzung und muss diese bewerten. Ja – ich empfehle alle Schnittstellen zu bewerten und ich rate Ihnen auch, diese Bewertung niederzuschreiben. Z.B. nach folgenden Schema:

SchnittstelleRisikorelevantBegründung
EKG-KabelJaKontakt zum Patienten
Spezial-Update-SchnittstelleNeinUpdatefunktion, Schnittstelle ist nur unter bestimmten Voraussetzungen aktiv.
EthernetJaPatientendaten werden übertragen
USB-AnschlussJaSpeichern von Patientendaten und Logfiles
SD-KarteNeinNur aktiv mit Spezial-Update-Schnittstelle und nur im Update-Modus
GehäuseJaPatientenkontakt

Sobald Sie Schwierigkeiten bekommen, die Begründung für das „Nein“ zu finden, sollten Sie es als Relevant einzustufen.

Warum ist diese Flughöhe und das schärfen des Schnittstellenprofils wichtig?

Als Risikomanager müssen Sie vorerst nicht auf den inneren Aufbau ausgerichtet sein, sondern auf die Einflussfaktoren auf das Gerät und aus dem Gerät zum Menschen oder der Umwelt. Dies verläuft über Schnittstellen. Zudem erreicht Sie hier auch die Information aus der Architektur, welche Produkte mit Ihrem Gerät oder System zu anderen Geräten oder Systemen tatsächlich kommunizieren und auch die Umsetzung der Zweckbestimmung wird damit prüfbar. In Analogie zum Bauwesen ist der Risikomanager jetzt der Statiker und muss den Entwurf des Architekten auf Tragfähigkeit prüfen.

Sobald die Schnittstellen und die vorhandenen Risiken aus der Zweckbestimmung verknüpft wurden, sollte ein Vergleich der Schnittstellen gegen die Risiken durchgeführt werden. Sind alle Schnittstellen zumindest mit einer Gefährdung verbunden? Sind alle Schnittstellen bewertet? Falls nicht, ist das Verfahren noch nicht abgeschlossen. Falls ja, empfehle ich Ihnen, die Architektur einzufrieren und zu sichern.

Die Bewertung von Risiken aus dieser Schnittstellenanalyse verfährt im gleichen Prozess wie die Risikoanalyse selbst. Weichen Sie auch hier nicht von Ihrem Prozess ab, sondern erweitern Sie diesen bei neuen Erkenntnissen.

Verifikation der Schnittstellen-Risiken und deren Risikokontrollmaßnahmen

Die Architektur muss Ihnen für jede Schnittstelle eine Spezifikation anbieten und auch eine entsprechende Verifikation für diese Spezifikation. Für Ihre Risiken müssen Sie jetzt noch die Prüfung auf die Gefährdungssituationen adaptieren und die Verifikation entsprechend beschreiben.

Wenn eine Ihrer Schnittstellen sogar eine Risikokontrollmaßnahme ist oder beinhaltet, halte ich es sogar für unabdingbar, dass diese in einer separaten Verifikation behandelt wird und einen entsprechenden Stellenwert in Ihrer Risikoanalyse und der Systemarchitektur besitzt. In dieser Verifikation wird erwartet, dass Sie die Gefährdungen bearbeiten, die aus der ursächlichen Schnittstelle kommen und Ihre Kontrollmaßnahme tatsächlich auch gegen die Gefährdung wirkt. Beispiele dafür sind unter anderem das Gehäuse im Sinne der Elektrischen Sicherheit und Luft/Kriechstrecken sowie Berührungsschutz, oder auch ein separater Erdungskontakt.

Und ab hier sind Sie im Risikomanagement für Ihr Teilsystem, Teilprodukt oder Produkt innerhalb des Systems. Dies kommt vielleicht im nächsten Blog ;-)

Zusätzliche Tipps:

Legen Sie sich einen speziellen Risiko-Verifikations-Plan an. Diesen sollten Sie immer durchführen, sobald eine neue Version oder Produktänderung durchgeführt wird. So bleiben Sie auf der sicheren Seite.

Weisen Sie den Schnittstellen, auch in der modellierten Form oder der Spezifikation den entsprechenden Gefährdungen zu. Häufig diffundieren die Risikoanalyse und die Systemarchitektur an den Schnittstellen.

Prüfen Sie jede Architekturveränderung auf neue Schnittstellen. Dies ist mit der Schnittstellenliste des Risikomanagements und dem Architekturbild sehr einfach.

Viele der Systemschnittstellen geben Ihnen Hinweise auf „Erste Fehler“ innerhalb Ihres Produkts/Systems.

Stefan Bolleininger

Auch interessant:

Veranstaltungstipp im Februar in München

Für alle, die sich gerne über die Themen Functional Safety, Requirements Engineering oder Systems Engineering austauschen oder neues lernen wollen, habe ich einen Veranstaltungstipp. Vom 23.02.2017 - 25.02.2017 findet in…

Links

http://www.b-quality.de/

Blog: Systeme in der Medizintechnik – sinnvolle Grenzen setzen

(Gast) Stefan Bolleininger

Stefan Bolleininger ist unabhängiger Berater für Risikomanagement, Qualitätsmanagement, Regulatory Affairs und Entwicklungsprozesse. Sein hauptsächliches Themengebiet liegt in der Qualitätsbegleitung von Entwicklungsprojekten von Medizinprodukteherstellern während der CE-Zulassung oder dem FDA Approval sowie deren Begleitung durch Audits, Assessments und Inspektionen. Im Bereich „Risikomanagement und Usability für Medizinprodukte und medizinische Netzwerke“ hält er einen Lehrauftrag an der TH Nürnberg und engagiert sich im Verein „International Certified Professional for Medical Software (ICPMSB.e.V.)“ sowie im VDI-Fachausschuss „Qualitätssicherung für Software in der Medizintechnik“.

Getagged mit: , , , ,
Ein Kommentar zu “Risikomanagement und Systemarchitektur
  1. Goran Madzar Goran Madzar sagt:

    Lieber Stefan, vielen Dank für Deinen Gastblog. Es ist der erste Gastblog auf medtech-ingenieur.de überhaupt :-) Weitere Referenten werden in Kürze nachlegen. Risikomanagement ist eine Disziplin, die viel Erfahrung und Know-how verlangt. Der Risikomanager ist eine wichtige Rolle in einem Projekt. Daher kann ich jedem nur raten diese Rolle richtig zu besetzen oder sich Hilfe ins Projekt zu holen. Sonst tut man sich nur unnötig schwer mit Risikomanagement und das ist nicht notwendig. Ich habe mit Stefan als Risikomanager und Qualitäter bereits einige Projekte erfolgreich abgeschlossen. Er ist ein absoluter Experte auf diesem Gebiet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.