In der Medizintechnik können technische Fehler in einem Gerät fatale Folgen für Bediener oder Patienten haben. Daher wird bei der Zulassung des Medizinprodukts auch generell eine Sicherheitsarchitektur gefordert. Wichtig ist, das Thema funktionale Sicherheit schon bei der Konzeptionierung eines Produkts anzugehen. Dabei ist das Ziel der funktionalen Sicherheitsüberlegungen, Medizingeräte derart auszulegen, dass technische Fehler frühzeitig erkannt werden und eine Gefährdung durch den jeweiligen Fehler ausgeschlossen werden kann. In diesem Blogartikel möchte ich Ihnen anhand eines einfachen Beispiels vorstellen, wie so eine Sicherheitsarchitektur für ein Medizingerät erstellt werden kann.
Info: anhand eines früheren Blogartikels sollten Sie sich, falls Sie es nicht bereits gemacht haben, mit den Begrifflichkeiten auseinandersetzen, die in diesem Artikel benutzt werden. Der Artikel beschreibt außerdem theoretische Grundlagen hinter der funktionalen Sicherheit und nennt die für uns Medizintechnik-Entwickler relevanten Normen.
Das Beispiel
Wir werden uns einem möglichst einfachen Beispiel widmen, das wahrscheinlich jeder schon einmal benutzt hat (oder zumindest kennt ;-)): ein Inhalationsgerät zur Inhalation von Kochsalzlösungen, mit welchem die Atemwege gereinigt werden können. Das Beispiel dient allein der Anschaulichkeit, deshalb gebe ich bewusst keine Gewähr auf Vollständigkeit und Funktionalität (bzw. Machbarkeit) :)
Schritt 1: Konzept & (falls vorhanden) Anforderungen verstehen
Aus dem Konzept erfahren wir, aus welchen Basis-Komponenten das System bestehen soll. Zunächst werden hier die elektrischen Komponenten genannt:
- Steuereinheit (Mikrocontroller)
- Erhitzer
- Elektronischer Schalter für die Schaltregelung (MOSFET)
- NTC-Temperaturfühler
- Bedienpanel:
- LCD Display zur Anzeige von Soll- und Isttemperatur
- Drehknopf zur Einstellung der Solltemperatur
- Magnetventil zur Steuerung des Lösungszuflusses in den Kessel
- Wippschalter zum Ein- und Ausschalten des Geräts
- Netzteil zur Bereitstellung der internen 24V-Versorgungsspannung
Dann werden die mechanischen Basis-Komponenten genannt:
- Gehäuse
- Schlauch und Mundstück
- Kessel
- Lösungs-Reservoir
Aus dem Geräte-Konzept können wir ebenfalls über die physikalische Funktionsweise des Inhalators erfahren:
„Vom Lösungs-Reservoir gelangt die Flüssigkeit, angetrieben von der Schwerkraft, über das Magnetventil zum Kessel, wo es auf die vom Nutzer einstellbare Sollwert-Temperatur (max. 130°C) erhitzt wird und verdampft. Der Dampf steigt von dort in den Schlauch, welcher ihn zum Mundstück transportiert. Der Patient inhaliert den Dampf am Mundstück.“
Die physikalische Wirkweise ist auch in einem Blockschaltbild festgehalten worden:
Konzeptuelles Blockschaltbild
Außerdem sind bereits einige System-Anforderungen definiert:
- Req. 1: Das System muss die Temperatur des Kessels auf die Sollwerttemperatur regeln.
- Req. 2: Das System muss über ein Bedienpanel Möglichkeit zur Einstellung der Sollwerttemperatur für den Kessel bieten.
- Req. 3: Das System muss den Sollwert für den Kessel auf maximal 130°C begrenzen.
- Req. 4: Das System muss den Erhitzer abschalten, wenn dessen Ist-Temperatur 150°C überschreitet.
Wenn wir verstanden haben, wie das Gerät funktioniert, aus welchen Komponenten es besteht und wie die Bedienung des Geräts funktioniert, können wir uns um die Risikoanalyse kümmern!
Schritt 2: Risikonalyse (Erfassung und Bewertung von Risiken)
Gefahren im Sinne der funktionalen Sicherheit entstehen dann, wenn physikalisch-technische Prozesse unkontrolliert ablaufen. Das ist z.B. der Fall, wenn ungewollt viel Energie durch das Gerät abgegeben wird oder toxische Chemikalien freigesetzt werden (oder beides). Diese Gefahren können für Anwender, Patienten und das Umfeld – das sind beispielsweise Personen, die sich im selben Raum wie das Gerät befinden – entstehen.
Eine Möglichkeit zum Sammeln und Bewerten von möglichen Fehlern und Risiken innerhalb komplexer technischer Systeme stellt die (System-)FMEA (Failure Mode and Effects Analysis) dar. Lässt man bei dieser die Risikoprioritätszahl außer Acht und kombiniert sie mit einer Risikoakzeptanzmatrix (siehe ISO 14971), ergibt sich ein Tool für die systemweite Erfassung und Bewertung von Risiken. Nun kann schnell und einfach entschieden werden, wo geeignete Sicherheitsmaßnahmen eingeführt werden sollten.
Ein Auszug aus der Risiko-Management-Akte (Risikoakzeptanzmatrix + Risiko Management Table) könnte für unser Gerät z.B. folgendermaßen aussehen:
a) Risiko Matrix nach ISO 14791
b) Risiko Management Tabelle
Schritt 3: Safe-States
Zunächst wollen wir uns dem sogenannten „Safe-State“ widmen. Das ist der Zustand, in dem vom fehlerbehafteten Gerät keine Gefahr mehr ausgehen kann. Für den Safe-State kommen, je nach Fehler, mehrere Zustände in Frage. Beim Definieren der Safe-States ist es wichtig, die Konsequenzen des Fehlers gegen die Konsequenzen des Safe-Sates abzuwiegen. Wird durch den Safe-State z.B. eine lebenserhaltende Maßnahme unterbrochen, so ist ein Stopp des Gerätes nur durch schwerwiegendere Fehler (z.B. akute Lebensgefahr) vertretbar. Für weniger gravierende Fehler könnte es dann einen weiteren Safe-State geben, in dem die Funktionalität des Gerätes auf das Minimum reduziert wird und der Nutzer über einen Alarm auf den Fehler aufmerksam gemacht wird (Notbetrieb).
In unserem Falle ist die Unterbrechung der Therapie allerdings kein Problem und wir können den Therapie-Stopp als einzigen Safe-State annehmen.
Schritt 4: Sicherheitsanforderungen
Ausgehend von Schritt 2 können wir aus den 5 erkannten Risiken 4 Sichereitsanforderungen ableiten, die unsere Sicherheitsarchitektur umreißen. Diese sind ebenfalls in den Systemanforderungen zu dokumentieren, um später auch einen Nachweis über die Erfüllung der Anforderungen (Validierung) führen zu können.
- Req. 5: Das System muss eine verfälschte Temperaturmessung erkennen und den Erhitzer infolgedessen abschalten.
- Req. 6: Das System muss gegen hohe Ströme geschützt sein.
- Req. 7: Das System muss einen Ausfall der Schalt-MOSFETs erkennen und den Erhitzer infolgedessen abschalten.
- Req. 8: Das System muss einen SW-Stall erkennen und den Erhitzer infolgedessen abschalten.
Für die Dokumentation bietet sich ein eigenes Kapitel im Lastenheft an, dass man z.B. „Sicherheitsanforderungen“ nennen könnte.
Schritt 5: Festlegung von FTT und MFOT
Zur Erinnerung:
- FTT (Fault Tolerance Time) beschreibt die Zeit, die vergehen kann, bis der Fehler zur Gefährdung wird.
- MFOT (Multi-Fault Occurence Time) beschreibt die Zeit bis zum Auftreten mehrerer Fehler.
Die FTT muss für jede Fehlerart einzeln definiert werden. Die Grundlage für ihre Bestimmung bietet die physikalischen Auswirkungen des Fehlers: meistens ist die FTT ziemlich kurz! Es sollte in jedem Fall eine Rationale für die Wahl einer geeigneten FTT geliefert werden, denn die FTT fließt direkt in die Auslegung der Sicherheitsmaßnahmen mit ein!
Für unser Beispiel könnte eine Angabe der FTTs folgendermaßen aussehen:
| Fehler | Gefahren | FTT | Rationale |
|---|---|---|---|
| Verfälschte Temperaturmessung | Brand, Verletzung | 10s | Die Regelstrecke ist zu langsam, um sich in weniger als 10s auf eine gefährliche Temperatur zu erhitzen. Dies zeigt die Berechnung XY. |
| Schalterausfall | Brand, Verletzung | 10s | Begründung wie bei verfälschter Temperaturmessung. |
| SW-Stall | Brand, Verletzung | 10s | Begründung wie bei verfälschter Temperaturmessung. |
| Hohe Ströme | Brand | 0,5s | Kurzschlussströme erzeugen sehr viel Hitze, welche umliegendes Material entzünden könnte. Der Wert ergibt sich aus der Norm XY, die den beim gewählten Netzteil zu erwartendem Kurzschlussstrom sowie die Leiterdicke zum Erhitzer berücksichtigt. |
Auch die MFOT sollten wir für unser Produkt festlegen. Häufig (z.B. bei Infusionspumpen) ist diese Zeit in der entsprechenden Produktnorm definiert. Üblicherweise kann für die MFOT die Zeit für eine Behandlung angenommen werden, sofern diese jedoch nicht zu lange ist (z. B. länger als ein Tag). Das bedeutet, dass ein Selbsttest bei Gerätestart, der einen potenziellen ersten Fehler erkennt, nicht während der Behandlung wiederholt werden muss, sofern die Zeit der Behandlung kurz genug ist. Wir werden für unser Produkt die durschnittliche Benutzungsdauer als MFOT festlegen: diese beträgt 20 min!
Schritt 6: Safety Measures
Aus den Anforderungen können wir nun die Maßnahmen („Safety-Measures“) ableiten, die eine konkrete Umsetzung der Anforderungen beschreiben. Dabei zielen alle funktionalen Sicherheitsmaßnahmen darauf ab, das Gerät in den jeweiligen Safe-State zu überführen. Die Sicherheitsmaßnahmen werden vom Architekten in den SW-, HW- sowie Mechanischen Anforderungen festgehalten. Dort dienen Sie den Entwicklern als Grundlage für die Implementierung in SW / HW / Mechanik.
In der Regel setzt man Sicherheitsanforderungen in Form von Laufzeitüberprüfungen (Runtime Checks), Selbsttest nach Gerätestart (Power On Startup Test, kurz POST) und Nutzerüberprüfungen vor Inbetriebnahme (Pre-Operative System Checks) um. Oft kommen auch doppelte Maßnamen (z.B. Runtime Check + POST) zum Einsatz. Wenn es sich um modulare Systeme mit vielen dezentralen, interoperablen Komponenten handelt, empfehlen sich besonders Pre-Operative System Checks. Weiterhin müssen die normativen Vorgaben zur Teststrategie beachtet werden: je nach gewählter Sicherheitsarchitektur sind zusätzliche Tests notwendig. Ist z.B. eine automatische Abschaltung involviert, so ist diese innerhalb der MFOT durch einen Selbsttest zu überprüfen.
Für unser System wählen wir nun die folgenden Maßnahmen (ausschließlich HW- und SW- Requirements, hier in Form einer Traceability Matrix):
Ausleitung der Sicherheitsanforderungen in HW- und SW-Anforderungen
Wie man sehen kann, sind in der Tabelle einige Textabschnitte rot markiert. Es handelt sich hier um normative Forderungen (FTTs und Teststrategien).
Schritt 7: Validierung
An dieser Stelle sind bereits alle Maßnahmen in Requirements gegossen. Natürlich ist es wichtig, die korrekte Funktion der Maßnahmen zu überprüfen! Hierfür müssen wir eine adäquate Test-Spezifikation schreiben, die dann durch die Durchführung der Tests in einen Testbericht überführt werden kann! Dies dient, wie oben bereits erwähnt, als Gesamtnachweis für die funktionale Sicherheit unseres Produkts. Wie man eine gute Test-Spezifikation schreibt, erfahren Sie in diesem Blog-Artikel über das Testen.
Fazit
Die funktionale Sicherheit eines Medizingeräts trägt einen großen Teil zur erfolgreichen Zulassung eines Medizingeräts bei. Sind die ersten konzeptionellen Entscheidungen zur Systemarchitektur eines Produkts gefallen, kann und sollte sich mit Überlegungen zur funktionalen Sicherheit befasst werden, da diese sich direkt auf das HW-, SW- und mechanische Design des Gerätes auswirken wird. Ich hoffe, Ihnen mit diesem Blog-Beitrag einen Ansatz zur Erstellung der Sicherheitsarchitektur geliefert zu haben. Sollten Sie weiterführende Fragen zu dem Thema haben, kommen Sie gerne auf uns zu! Sie können hierfür die Kommentarfunktion benutzen oder uns direkt über den Kontakt-Button, per E-Mail oder unter der 09131/691240 erreichen.
