Kriterien für die Verwendung von Off-the-Shelf-Software
Linux im Medizin-Einsatz
Der Einsatz von Linux in Medizingeräten ist verlockend, birgt jedoch zahlreiche Herausforderungen bezüglich behördlicher Vorschriften, Safety, Security und der Implementierung. Mit langfristigem Support durch einen erfahrenen OTS-Linux-Partner können Gerätehersteller Produkte effizient realisieren, die nicht nur die behördliche Zulassung erhalten, sondern auch über Jahre zuverlässig arbeiten.
Linux ist für viele Medizingeräte das Betriebssystem der Wahl - angefangen bei Systemen zur Überwachung der Vitalparameter über Infotainment-Systeme für den Krankenhaus-Nachttisch bis hin zu komplexen bildgebenden Geräten für medizinische Untersuchungen. Doch nicht alle Linux-Implementierungen sind gleich. Weil in einigen Situationen das Leben von Patienten in Gefahr sein könnte, muss die in Medizingeräten eingesetzte Software bestimmte behördliche Richtlinien erfüllen.
Der Versuch, Linux-Lösungen ohne kommerziellen Support zu entwickeln, überträgt Aufgaben wie Test, Validierung und Dokumentation sowie das Einhalten von Richtlinien auf die Gerätehersteller und Software-Entwickler - ein ehrenhafter, aber zeitraubender und komplexer Prozess, der aus dem kostenlosen Linux ein kostspieliges Unterfangen macht. Selbstverständlich gibt es kommerzielle Linux-Anbieter, die stabile Versionen der Open-Source-Software mit zusätzlicher Wertschöpfung einschließlich »Board Support Packages« (BSP) anbieten.
Service, Unterstützung und Dokumentation sind jedoch je nach Anbieter unterschiedlich. So bieten zum Beispiel einige Chip-Lieferanten Software an, aber keinen echten Support.
Open Source - Pro und Contra
Linux ist in unterschiedlichen Medizingeräten anzutreffen. Als »General Purpose«-Betriebssystem bietet es alle Vorteile von Open-Source. Kostenfreie Linux-Versionen stehen zur Verfügung, die im Rahmen der »GNU General Public License« (GPL) modifiziert und weiterverkauft werden können. Linux ist heute weit verbreitet, wurde von vielen Entwicklern bereits ausgiebig geprüft und erfreut sich großen Zuspruchs.
Alle bedeutenden Hardware-Hersteller unterstützen das Betriebssystem, und es läuft auf praktisch jedem Prozessor. Außerdem hat Linux ein umfassendes Ökosystem von Board- und Software-Anbietern, die bewährte »Toolchains« und APIs (Application Programming Interfaces) nutzen. Eine außerordentliche Grafikunterstützung, einschließlich beliebter Frameworks wie »Qt« und »Android« - wichtig für gestochen scharfe und optimal lesbare Darstellungen auf Gerätebildschirmen -, ist ein weiteres Merkmal von Linux.
Diese Innovation und Reife hat dieses Betriebssystem zu einem wichtigen Bestandteil von Medizingeräten gemacht. Allerdings bringt dessen Einsatz in Medizingeräten auch besondere Herausforderungen mit sich. Medizingeräte für den US-Markt müssen die Vorschriften der FDA (Food and Drug Administration) erfüllen. Die FDA ist weltweit als Institution anerkannt, welche die Richtlinien für Medizingeräte herausgibt.
Europäische Hersteller, die Geräte in den USA verkaufen möchten, müssen die FDA-Richtlinien ebenfalls erfüllen. Unabhängig davon, ob der Gerätehersteller die Konformität der Medizingeräte-Software nach IEC 62304 bescheinigt, muss sie mehrere FDA-Richtlinien erfüllen. Ein Betriebssystem kann als »Software of Unknown Provenance« (SOUP) oder »Off-the-Shelf Software« (OTS) betrachtet werden.
Die FDA macht auch klar, dass die Aufgabe, sichere und zuverlässige Performance sicherzustellen, nicht mit der Markteinführung des Produkts endet. Bei der Evaluierung von Betriebssystemen ist es daher erforderlich, »Bug-Fixes« und »Security Updates« für den gesamten Produktlebenszyklus zu berücksichtigen.
»Cybersecurity«: Sicherheit vernetzter Geräte
Medizingeräte und ihre Komponenten müssen eine umfangreiche Fehleranalyse durchlaufen, die normalerweise der Gerätehersteller durchführt. Bei der Fehleranalyse geht es jedoch nicht um den Versuch, die Wahrscheinlichkeit von Fehlern vorauszusagen - vielmehr sollen die Auswirkungen eines möglichen Fehlers auf den Patienten untersucht werden (Bild 1).
Es gibt zwei Dokumentationsstufen für OTS-Software: »Basic« und »Special«. Welche der beiden Stufen erforderlich ist, richtet sich nach der Fehleranalyse. Die FDA bietet in ihrer »Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices« einen vollständigen Überblick.
Für einen Gerätehersteller ist es wichtig, einen kommerziellen Linux-Anbieter zu wählen, der ihm dabei helfen kann, diese Anforderungen, wie zum Beispiel die Verfügbarkeit geeigneter Produktentwicklungs-, Verifikations- und Überprüfungsmethoden, zu erfüllen.
Die Vernetzung von Medizingeräten nimmt ständig zu - und wenn Linux an ein Netzwerk angebunden wird, gelten die FDA-Richtlinien zum Thema »Cybersecurity«, also der Sicherheit der Anwendung vor Angriffen über das Netzwerk: »Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software«. Im Prinzip stellen diese Richtlinien fest, dass Netzwerke möglichen Angriffen durch Hacker ausgesetzt sind und der Hersteller einen Plan für die Softwarepflege haben muss, der sich mit diesen Netzwerk-Schwachstellen befasst.
Laut den Richtlinien sollten formale Geschäftsbeziehungen mit OTS-Software-Herstellern gepflegt werden, um den zeitnahen Empfang von Informationen hinsichtlich Qualitätsproblemen und empfohlenen Korrektur- und Schutzmaßnahmen sicherzustellen. Falls ein kommerzieller Linux-Anbieter mit seinen Kunden keine formale Support-Beziehungen eingeht oder nicht über einen ständig aktualisierten Cybersecurity-Plan verfügt, fällt diese Aufgabe ausschließlich dem Gerätehersteller zu. Dieser muss dann die Entwicklungen in der Linux-Gemeinde verfolgen, Schwachstellen identifizieren und erforderliche Maßnahmen ergreifen - ein Vollzeitjob für ein eigenes, hochspezialisiertes Mitarbeiterteam.
Falls Security-Funktionen keine Kernkompetenz des Geräteherstellers sind, ist es wichtig, einen Betriebssystemanbieter zu haben, der bei der Konfiguration der Security-Komponenten des Netzwerk-Stacks hilft. Medizingerätehersteller und ihre Softwarepartner müssen in Anbetracht zunehmender Malware-Angriffe wie zum Beispiel »Stuxnet« besonders wachsam sein.
Natürlich lässt sich die Anwendung vor Angriffen über USB schützen, indem der Entwickler mittels eines Kernel-Konfigurators die USB-Komponenten vom Kernel entfernt - dies geht aber auf Kosten des Funktionsumfangs. Gerätehersteller müssen also entscheiden, welches Maß an Security angebracht ist. In Geräten, bei denen jede Art des Angriffs verhindert werden muss, möchten Hersteller die zusätzliche Gewährleistung von Security-Funktionen vielleicht in das Betriebssystem integrieren.
Unterstützung beim Implementieren
ber die Security hinaus sind bei der Nutzung von Linux in Medizingeräten weitere Kriterien zu beachten. So müssen hochwertige Testwerkzeuge vorhanden sein, die Fehler bei der Überprüfung sicher anzeigen können. Nicht nur die OTS-Software muss optimal entwickelt sein, auch die Evaluation-Tools müssen überprüft werden. Der Einsatz eines automatisierten Testsystems, das die durchgeführten Tests automatisch dokumentiert, kann gegenüber manuellen Systemen Zeitvorteile bringen und zugleich die Risiken von durch den Menschen verursachten Fehlern reduzieren.
Dies stärkt das Vertrauen in die Ergebnisse. Auch ist es wesentlich, dass die Anforderungen der GPL und anderer zutreffender Open-Source-Lizenzen erfüllt werden. Board-Support-Packages (BSPs) sind wichtig bei der Implementierung von Embedded-Betriebssystemen inklusive Linux. Wenige Hersteller sind in der Lage, BSPs im eigenen Haus zu entwickeln.
Zudem kann die Entwicklung individueller BSPs sehr kostspielig sein. Bei der Entwicklung von Multicore-Systemen bringt die Vereinfachung des Systemdesigns bei gleichzeitiger Performance-Steigerung durch mehrere Prozessoren und Betriebssysteme neue Herausforderungen mit sich. Entwickler, die moderne Analysetools in einer Linux-Umgebung einsetzen, können auf Hindernisse treffen, die sich in einer Umgebung mit mehreren Cores oder auch mehreren Threads multiplizieren. Mit den Werkzeugen eines kommerziellen OS-Anbieters, der Support auf professionellem Level bietet, reduzieren sich die Aufgaben der Entwickler.
Um mit Virtualisierung zu arbeiten und den Betrieb mehrerer Betriebssysteme auf einem Board zu ermöglichen, nutzen Entwickler zunehmend einen »Embedded Hypervisor«. Wenn ein Gerätehersteller einen solchen Embedded-Hypervisor für Aufgaben wie Konfiguration der Multicore-Umgebung, Booten mehrerer Cores, Zuteilung von Hardware-Ressourcen, Zugang zu und Schutz von Speicher (für Safety und Security) sowie Überwachung des Systemzustands nutzt, kann er sich völlig auf seine spezielle Applikation konzentrieren.
Über den Autor:
Ken Herold ist Lead Medical Engineering Specialist bei Wind River Systems.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
