Besondere Anforderungen an die Softwareentwicklung im Medizinbereich

Information: YAKINDU Security Analyst Is Now itemis SECURE

Die Bedeutung von Software nimmt allgemein zu, das gilt auch im Medizinbereich. Medizinsoftware steuert sicherheitskritische Apparate, findet Anwendung als Bestandteil von Diagnostiksystemen, als Standalone-Software oder als „App“. Sobald die Gesundheit von Patienten auf dem Spiel steht, ist nicht nur besondere Sorgfalt geboten, es gelten darüber hinaus spezifische Normen und Vorschriften, die ich im Folgenden beleuchte.

Achtung, konkrete Vorgaben!

Die EU-Medizinprodukteverordnung macht, ebenso wie ihre Vorgängerregelungen, genaue Vorgaben zur Verwendung und Entwicklung von Software in Medizinprodukten, die auf dem europäischen Markt zugelassen werden.

Auch die Software selbst kann als Medizinprodukt gelten, zum Beispiel, wenn sie der Erkennung oder Behandlung von Krankheiten dient. Die Software muss also nicht erst ein Gerät mit unmittelbarer Wirkung auf den Patienten steuern, um als Medizinprodukt eingestuft zu werden.

Die Norm ISO/IEC/EN 62304 ist maßgeblich für das Vorgehen bei der Entwicklung von Software im Medizinbereich. Der wichtigste Aspekt ist die Einstufung in sogenannte Sicherheitsklassen, je nach Gefahrenpotential. Die Software, oder auch einzelne Komponenten, wird standardmäßig der höchsten Klasse C zugerechnet. Damit verbunden ist ein erhöhter Dokumentationsaufwand. Die Risikoklasse kann reduziert werden, wenn ein Fehler in der Software nicht zu einer Gefährdung führen kann.

Es ist wichtig zu wissen, dass der gesamte Produktlebenszyklus von Medizinsoftware den Anforderungen der Norm genügen muss. Konkret bedeutet das: Eine ausreichende Dokumentation muss existieren. Ein Katalog von Systemanforderungen muss die Rückverfolgbarkeit (Traceability) zu Softwareanforderungen und zu den konkreten Entwicklungsartefakten sicherstellen.

Auch wenn der tatsächliche Entwicklungsprozess agil ist, ergibt sich nach außen ein Bild, das eher dem V-Modell ähnelt. Grund dafür ist die Vorgabe, dass die Anforderungen auf jeder Ebene validiert beziehungsweise getestet werden müssen.

Die Zertifizierung fordert Prüfungen, ob die Vorgaben eingehalten werden. Daher sollte die Dokumentation immer lückenlos sein und zu jeder Zeit in Form gut lesbarer Dokumente ausgegeben werden können – sowohl vor der Markteinführung als auch während der gesamten Produktlebenszeit.

Requirements Traceability lautet hier das Stichwort. In kleinen Projekten reicht gegebenenfalls eine Requirements-Traceability-Matrix aus, um die Anforderungen an die Nachverfolgbarkeit zu erfüllen. Größere Projekte sollten hingegen auf eine Tool-gestützte Traceability-Lösung setzen, die weitere Vorteile bietet.

Risikoanalyse von Medizinsoftware

Das oberste Ziel bei der Entwicklung von Medizinprodukten ist Safety (Sicherheit). Die Norm ISO/EN 14971 sieht vor, dass Maßnahmen ergriffen werden, um diese Sicherheit nachprüfbar zu gewährleisten. Auch die Risiken beim Betrieb des Gesamtsystems müssen bewertet werden. Hierbei kommen Risikoanalysetechniken wie FMEA (Failure Mode and Effects Analysis) und FTA (Fault Tree Analysis) zum Einsatz.

In dieser Hinsicht unterscheidet sich die Entwicklung von Medizinprodukten nicht von der Entwicklung sicherheitskritischer Systeme im Allgemeinen. Ein Risiko ergibt sich prinzipiell als Produkt der Schwere des Schadens (Severity) und der Eintrittswahrscheinlichkeit. Um Risiken zu bewerten, müssen zunächst die möglichen Einflussfaktoren analysiert werden. Hier kann beispielsweise das Tool YAKINDU Security Analyst (now itemis SECURE) zum Einsatz kommen.

Die Fachsprache kennt eine klare Unterscheidung zwischen Safety und Security. In sicherheitskritischen Systemen kommt beides zusammen. Eine Software, die nicht sicher gegen Angriffe ist und beispielsweise über ein Netzwerk unbemerkt manipuliert werden kann, kann logischerweise auch nicht die Betriebssicherheit gewährleisten. Nebenbei gefährdet sie auch andere essentielle, gesetzlich vorgeschriebene Schutzziele, wie den Datenschutz.

Sicherheit von Medizinsoftware durch Qualität

Nicht nur das Anforderungsmanagement sollte auf der Höhe der Zeit sein: Die bloße Vorgabe der Testbarkeit schließt eine ungenügende Qualität der Software selbst nicht aus.Diese kann zu unerwünschten Fehlfunktionen führen und ein Haftungsrisiko darstellen.

Ein hoher Standard in der Softwarequalität ist also keine unnötige Last, sondern die wichtigste Grundlage für eine effiziente Entwicklung. Je besser und nachvollziehbarer die Medizinsoftware gebaut ist, desto weniger Bugs werden im Laufe der Entwicklung unentdeckt bleiben. Die Software lässt sich später leichter weiterentwickeln, und unvorhergesehene Probleme können vermieden werden.

Die Normen geben allerdings nicht präzise vor, auf welche Weise die Qualität sichergestellt wird. Allgemeine Standards entstehen gerade erst. Bislang geht man in der Regel davon aus, dass bei den meisten Softwareprodukten eine Risikoabschätzung gar nicht möglich ist. Dieser Umstand führt immer zu zusätzlichem Entwicklungsaufwand, da die Sicherheit des Gesamtsystems nur durch zusätzliche Maßnahmen gewährleistet werden kann, etwa durch eine redundante Zustandsüberprüfung durch eine Hardwarekomponente.

Allerdings orientiert man sich bei den Qualitätsanforderungen an Software für Medizinprodukte am Stand der Technik. Dies bedeutet derzeit in der Praxis, dass Unit- und Komponententests die Tauglichkeit belegen sollen. Das ist zwar nicht falsch, aber unzureichend. Denn auch eine vollständige Testabdeckung garantiert nicht, dass die Logik der Software den Anforderungen genügt und keine Fehler enthält.

Weniger Softwarefehler dank formaler Methoden

In der Norm ISO/IEC/EN 62304 ist von „Verifikation“ die Rede, womit die Norm aber nur das herkömmliche Testen der Software-Einheiten meint. Nach der wissenschaftlichen Definition steht der Begriff Software-Verifikation allerdings für einen mathematischen Beweis, dass die Software den spezifizierten Anforderungen genügt. Das ist ein sehr großer Unterschied!

Statische Analysen, die durch Tools wie Sonarqube in den CI-Prozess eingebunden werden, tragen heute in vielen Unternehmen zur Vermeidung einfacher Fehler bei. Software-Verifikation geht über statische Analysen und über Unit-Tests hinaus. Durch den Einsatz formaler Methoden ist es bereits heute möglich, Software im eigentlichen Sinn zu verifizieren und viele Fehlerklassen komplett auszuschließen.

Wenn sich die Normierungskomitees und Gesetzgeber beim Erarbeiten der Normen und Gesetze weiter am Stand der Technik orientieren, dann dürfte es nur eine Frage der Zeit sein, bis formale Methoden in der Entwicklung kritischer Systeme zum verbindlichen Standard werden und Fehler durch nachlässiges Programmieren der Vergangenheit angehören.

Ein erster wichtiger Schritt zum Ausmerzen vermeidbarer Programmierfehler (und zum Einsparen von Entwicklungszeit) kann darin bestehen, den eigentlichen Programmcode auf einer möglichst hohen Abstraktionsebene, also nah an der formalen Verhaltensspezifikation, zu erzeugen. Hierbei können beispielsweise die YAKINDU Statechart Tools (now itemis SECURE) helfen.