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 solche, 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:

Schnittstelle Risikorelevant Begründung
EKG-Kabel Ja Kontakt zum Patienten
Spezial-Update-Schnittstelle Nein Updatefunktion, Schnittstelle ist nur unter bestimmten Voraussetzungen aktiv.
Ethernet Ja Patientendaten werden übertragen
USB-Anschluss Ja Speichern von Patientendaten und Logfiles
SD-Karte Nein Nur aktiv mit Spezial-Update-Schnittstelle und nur im Update-Modus
Gehäuse Ja Patientenkontakt

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

 

Links

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

Blog: Systeme in der Medizintechnik – sinnvolle Grenzen setzen

Kontaktieren Sie uns!

Autor

  • (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“.

Auch interessant:

Hardware-Entwicklung bei MEDtech Ingenieur – Altium Designer

Bei MEDtech Ingenieur kennen und nutzen wir verschiedene Tools in der HW-Entwicklung. Für eigene Entwicklungen und wenn wir wählen können, bevorzugen wir Altium Designer für Schaltplan und Layout-Erstellung. Dieser Artikel beschreibt, warum Altium unser bevorzugtes Werkzeug für Schaltpläne und Layouts ist und wie wir das Tool einsetzen. Falls Sie überlegen…
Getagged mit: , , , ,

Schreibe einen Kommentar