Fehlerfreie Medizinsoftware

Von der Vision zur Wirklichkeit

15. April 2019, 16:33 Uhr | Daniel Kästner (Absint)
Software ist in der Medizin nicht nur Teil eines Gerätes, sondern kann auch als eigenständiges Medizinprodukt gelten. Damit einher gehen erhöhte Anforderungen an deren Sicherheit.
© Pixabay

Aktuelle Sicherheitsnormen fordern den Nachweis, dass die funktionalen Anforderungen erfüllt und sicherheitsrelevante nicht-funktionale Softwarefehler ausgeschlossen sind. Hierzu zählen Stacküberläuge, Laufzeit- und Compiler-Fehler. Deren Abwesenheit kann durch moderne Analysen bewiesen werden.

Das Gebiet der Software für Medizinprodukte ist umwälzenden und sich zunehmend beschleunigenden Änderungen unterworfen. Wurde Medizinsoftware vor einigen Jahren lediglich als kleiner Zusatz zur elektronischen Hardware wahrgenommen, werden heutzutage drei große Bereiche unterschieden: Software als integraler Bestandteil eines Medizinprodukts (zum Beispiel zur Steuerung von Infusionspumpen oder Dialysegeräten), Software als eigenständiges Medizinprodukt (zum Beispiel Bildanalyseverfahren für Kernspintomographen) und Gesundheitssoftware (zum Beispiel mobile Applikationen auf Mehrzweckgeräten) [1]. Tiefgreifende Änderungen gibt es dabei auch innerhalb des klassischen Bereichs der software-gesteuerten eingebetteten medizinischen Systeme. Wie auch in anderen Industriebereichen wird immer mehr sicherheitskritische Funktionalität durch Software realisiert. Eine Fehlfunktion der Steuerungssoftware kann im Extremfall Menschenleben gefährden, aber auch in weniger kritischen Systemen hohe Kosten verursachen – nicht zuletzt durch Rückrufaktionen. Nur im Zusammenhang mit Infusionspumpen wurden nach Aussage der FDA zwischen 2005 und 2009 mehr als 500 Tote registriert. Im gleichen Zeitraum wurden aus Sicherheitsgründen 87 Rückrufe von Infusionspumpen durchgeführt. Eine Analyse dieser Ereignisse durch die FDA hat Softwarefehler als eine der Hauptursachen identifiziert [2]. Seitdem ist die Zahl weiter gestiegen: Aufgrund von Software-Defekten wurden zwischen 2011 und 2015 durch die FDA 627 Software-Geräte zurückgerufen, 12 davon mit der höchsten Gefährdungsstufe [3]. Zusätzlich steigt durch die zunehmende Vernetzung elektronischer Geräte die Gefahr von Cybersecurity-Risiken dramatisch an – nicht nur im Bereich von Gesundheitssoftware, sondern auch im Bereich von eingebetteten Medizinprodukten.

Dies unterstreicht die zentrale Bedeutung einer systematischen Verifikation und Validierung von Medizinsoftware: Das Ziel der Software-Verifikation liegt in der Bereitstellung eines objektiven Nachweises, dass die relevanten Anforderungen an die Software erfüllt worden sind und keine Sicherheitsverletzungen auftreten können. Die Validierung prüft zusätzlich, ob die gestellten Anforderungen konsistent und vollständig sind und das gewünschte Verhalten abbilden [4].

Normenlandschaft

Der Software-Entwicklungsprozess wird durch nationale und internationale Normen und Vorschriften reguliert. Bei Medizinprodukten ist in Deutschland der Nachweis der Übereinstimmung mit dem Medizinproduktegesetz (MPG) erforderlich [5]. Darin wurde die Richtlinie 2007/47/EG in deutsches Recht übernommen, die in Absatz (20) explizit fordert, Software für Medizinprodukte – sowohl als eigenständiges Element wie auch als Bestandteil eines Medizinproduktes – in Übereinstimmung mit dem Stand der Technik zu validieren. Grundsätzlich unterliegen alle Elektrisch-/Elektronischen Systeme der Norm IEC-61508 [6], von der im Automobilsektor die branchenspezifische Norm ISO-26262 [7] oder im Bahnsektor die Norm EN 50128 [8] abgeleitet wurden. Die höchsten Anforderungen werden mit der Norm DO-178C [9] im Luftfahrtbereich gestellt; auch die Zertifizierungsprozesse sind dort deutlich strikter als im Medizintechnikbereich.

Im Medizinbereich formulieren EN-60601-1 [10] und IEC 61010-1 [11] allgemeine Anforderungen für die Erstellung funktional sicherer Medizingeräte. Der Schwerpunkt der IEC-62304 [12, 1] liegt auf Software für Medizingeräte und definiert insbesondere einen Lebenszyklus für Softwareentwicklung mit Fokus auf komponentenorientierte Softwarearchitekturen und Softwarewartung. Die Vorgaben für Verifikation und Validierung sind jedoch sehr allgemein gehalten und im Detailgrad nicht mit IEC-61508, ISO-26262 oder EN-50128 vergleichbar. EN 45502-1 [13] und ISO 14708-1 [14] geben spezifische Leitlinien für aktive implantierte Geräte und verweisen dabei bezüglich Softwareanforderungen auf die IEC 62304. Mit dem Risikomanagement für Medizingeräte befasst sich die ISO 14971 [15]. Die Norm ISO 13485 [16] betrachtet allgemeines Qualitätsmanagement. Zu den relevanten nationalen Richtlinien im Bereich Verifikation und Validierung zählen insbesondere auch die US Quality System Regulations [17] und die FDA General Principles of Software Validation [4].

Darstellung des Aufrufpfads mit maximalem Stackverbrauch im StackAnalyzer.
Darstellung des Aufrufpfads mit maximalem Stackverbrauch im StackAnalyzer.
© Absint

  1. Von der Vision zur Wirklichkeit
  2. Anforderungen an Verifikation und Validierung
  3. Nachweis der Echtzeitfähigkeit

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu AbsInt Angewandte Informatik GmbH