Systemsoftware für Medizingeräte wählen

Entwickler können bei der Realisierung von Medizingeräten auf eine Reihe von Software-Angeboten zurückgreifen. Das Spektrum reicht von kundenspezifischen Lösungen oder kommerziellen Off-the-Shelf-Produkten über Echtzeitbetriebssysteme bis zu einem Allzweck-OS, zum Beispiel Linux oder Android. Jede Diskussion über Software oder Spezifikationen für Medizingeräte muss jedoch mit der übergeordneten Tatsache beginnen, dass diese Geräte das Leben von Menschen unmittelbar beeinflussen.

Moderne medizinische Geräte gibt es in allen erdenklichen Größen und Formen. Angefangen bei sehr großen und hochwertigen Systemen mit Strahlenquellen bis hin zu kleinen implantierbaren Schrittmachern mit Batterieversorgung. Die Bedeutung ihrer Funktionen ist je nach Gerät verschieden.

Die primäre Überlegung gilt dem Einsatzfall. Muss das Gerät Daten sammeln und speichern? Wird es von Patienten oder Technikern oder von beiden Gruppen eingesetzt? Gibt es spezielle Service-Betriebsarten, die nur von Technikern benutzt werden können? Wie wird das betreffende Gerät versorgt? Muss es auch beim Aufladen des internen Akkus funktionsfähig sein?

Echtzeiteigenschaften sind bei kleinen, implantierbaren Systemen normalerweise vernachlässigbar. Die Software muss lediglich das Monitoring weniger Sensoren übernehmen und einen kleinen Anteil der Behandlung administrieren. In der Wartungs- oder Datensammlungs-Betriebsart kann das Gerät eventuell ein Funksignal von außerhalb des Körpers empfangen. Dies lässt sich mithilfe eines relativ einfachen Mikrocontrollers mit geringem Energieverbrauch realisieren. Hingegen erfordern große und komplexe Maschinen, wie zum Beispiel bildgebende Systeme, ein Allzweck-OS. Die physikalischen Abmessungen oder Einschränkungen des Speichers sind bei solchem Medizinequipment meist unbedeutend.

Marktveränderungen

Die Mehrheit der portablen, elektronischen Medizingeräte ist jedoch zwischen diesen beiden Extremen angesiedelt. Die Mehrzahl der Geräte arbeitet batteriegespeist, ist vernetzbar, hat bestimmte Anforderungen an die Speicherung von Daten und benötigt eventuell Echtzeitverhalten.

Es ist auch wichtig, bedeutende Industrietrends zu berücksichtigen. Zum Beispiel der zunehmend größere Kreis an Fachleuten, die heute alle möglichen Geräte zur Behandlung von Patienten einsetzen. Und da medizinische Geräte allgegenwärtig werden und auch von Laien benutzt werden, müssen sie nicht nur ihre Aufgaben ausführen, sondern sich auch von Personen bedienen lassen, die nur über Grundwissen verfügen. In Verbindung mit steigenden Kosten für das Gesundheitswesen liegt es in den Händen der Entwickler von Embedded-Software, Lösungen zu realisieren, die über die reine Funktion hinausgehen.

Hinzu kommt, dass in vielen Ländern die durchschnittliche Lebenserwartung steigt und damit verbundene Krankheiten weitaus häufiger auftreten als bisher. Gesellschaften suchen daher nach Möglichkeiten, Diagnosen effizienter durchführen zu können. Außerdem werden Wege zur Administration von Vorsorgemaßnahmen gesucht.

Neue Technologien sollen zusätzlich die Gerätekosten minimieren. In zunehmendem Maße müssen Medizingeräte auch Informationen zwischen Geräten sowie zwischen Geräten und Netzwerken oder mit der Cloud austauschen können. Zugleich muss die Sicherheit aller Daten sowie die Konformität zur aktuellen Gesetzgebung gewährleistet werden (Bild 1).

Systemanforderungen

Offensichtlich gibt es einen großen Bereich medizinischer Applikationen. Alle Medizingeräte müssen jedoch ein bestimmtes Maß an Systemzuverlässigkeit aufweisen, sich einfach bedienen lassen und fehlertolerant sein. Ein Defibrillator zum Beispiel sollte als Basis-Systemanforderungen folgende Merkmale aufweisen: lange Lagerbeständigkeit, ganz gleich ob netz- oder batterieversorgt, einfache Mensch/Maschine-Schnittstelle (HMI), sichere und stabile Kommunikation und Multi-CPU-Design für hohe Leistungsfähigkeit sowie Power-Management.

Die Forderung nach einer langen Lagerbeständigkeit ist bei Geräten wie einem Defibrillator besonders wichtig. Falls das Gerät mit Batterien versorgt wird, muss es, ohne erneut aufgeladen zu werden, seine gesamte Lebensdauer überstehen. Dies bedeutet, dass die Systemsoftware so entwickelt werden muss, dass sie die Gerätebatterie nur minimal belastet.

Eine Methode ist der Einsatz von zwei Prozessoren. Ein kleinerer Baustein hält die Systemfunktionen aufrecht, evaluiert Hardware, gewährleistet die Systembereitschaft und erstellt Statusreports. Ein größerer Prozessor ist für ein intuitives HMI und Echtzeitereignisse wie zum Beispiel das Monitoring der Vitalparameter des Patienten zuständig und liefert elektrische Impulse, sobald erforderlich. Gleichzeitig wird die Leistungsaufnahme für einen kompletten Produktlebenszyklus minimiert.

Audiofähigkeiten und eine einfache, intuitive grafische Benutzerschnittstelle (GUI) mit minimalen Optionen sind bei einem Defibrillator anstelle einer komplizierten Schnittstelle ebenfalls zu begrüßen. Auch der Einsatz von zwei Cores in einem Multi-CPU-Systemdesign ist bei einem Defibrillator zu empfehlen. Einer der Cores überwacht den Zustand des Gerätes täglich oder wöchentlich, während der andere in der Lage sein muss, höhere Leistungen und mehr Funktionen zum Treiben der Schnittstelle zur Verfügung zu stellen und den Zugriff auf Patientendaten zu ermöglichen. Auch ist dieser Core für die Abgabe elektrischer Impulse zuständig.

Eine sichere und stabile Kommunikation ist ebenfalls wichtig. Nach einem Einsatz muss die Einheit Daten an einen Administrator liefern, der relevante Daten an den für den Patienten zuständigen Arzt zur Begutachtung weiterleiten kann. In diesem Fall erfordert die Kommunikation den Einsatz eines GSM-Protokoll-Stacks. Während des Einsatzes ist eine CPU mit wesentlich höherem Leistungsvermögen notwendig, um zu bestimmen, ob die Abgabe eines elektrischen Schocks gerechtfertigt ist.

Der Einsatz eines einfachen »Round-Robin«-Schedulers ist wegen dieser Anforderungen nicht ausreichend. Dies begründet abhängig von mehreren Faktoren einschließlich Fast-Boot- und Low-Power-Anforderungen den Einsatz eines RTOS oder Allzweck-OS. Minimale Software würde ein RTOS rechtfertigen, das typischerweise lediglich ein Zwanzigstel so groß ist wie ein Allzweck-OS. Eine kleinere Codegröße bedeutet geringere RAM-Anforderungen und somit eine geringere Leistungsaufnahme sowie weniger auszuführenden Code. Falls Zeit ein kritischer Faktor ist, ist ein RTOS gerechtfertigt. Falls ein medizinisches Gerät außerhalb von Notfällen verwendet wird, könnte ein Allzweck-OS akzeptabel und Middleware ebenfalls von Vorteil sein.

Zusätzliche Überlegungen

Entwickler von Medizingeräten sollten im Hinblick auf die Systemsoftware auch folgende Eigenschaften berücksichtigen: Modularität, Skalierbarkeit, Funktionssicherheit (Safety), Datensicherheit (Security), Konnektivität und Benutzerschnittstelle.

Geräte müssen sich an sich ändernde Netzwerkanforderungen anpassen lassen. Somit muss das OS auf einer modularen, erweiterbaren und zukunftssicheren Architektur basieren, bei welcher der Kernel von Middleware, Protokollen, Applikationen und anderen Paketen getrennt ist, damit sich diese Elemente ohne Änderungen am Kernel hinzufügen oder erweitern lassen. Die Skalierbarkeit der Systemsoftware ist ebenfalls sehr wichtig, wenn man die Verbreitung von Geräten, angefangen bei Systemen mit kleinem Formfaktor und für nur eine Applikation bis hin zu komplexen Systemen für mehrere Applikationen berücksichtigt. Ein einziges RTOS, das so skaliert werden kann, dass es die Anforderungen mehrerer Produktklassen hinsichtlich Speichergröße, Funktionsumfang und Verarbeitungsmöglichkeiten erfüllt, kann Herstellern helfen, den ROI zu steigern, die Entwicklungskosten zu senken und die Time-to-Market zu verkürzen.

Sicherheit ist bei Medizingeräten von entscheidender Bedeutung. Doch nicht alle Applikationen sind lebenswichtig. Es gibt Software, die es erlaubt, mehrere Applikationen mit unterschiedlichen Kritikalitätsgewichtungen auf der gleichen Hardwareplattform zu betreiben. Hingegen sind Eigenschaften im Hinblick auf die Datensicherheit nicht nur wichtig, um das System vor Schadsoftware oder schädlichen Applikationen zu schützen, sondern auch um Daten sicher speichern und übertragen zu können sowie Designs manipulationssicher zu gestalten. Entscheidend ist, dass diese Eigenschaften auf Betriebssystemebene unterstützt werden. Auf Benutzer- oder Applikationsebene wären sie ineffizient, teuer und risikobehaftet.

Im Hinblick auf Konnektivität werden Medizingeräte zunehmend mit öffentlichen Netzwerken verbunden. Dies bedeutet, dass Systemsoftware eventuell Kommunikationsprotokolle wie CAN, Bluetooth, Continua, 802.15.4, WLAN und Ethernet unterstützen müssen. Hinzu kommt, dass sich die Anwenderschnittstelle zu einem wichtigen Unterscheidungsmerkmal wandelt. Somit sind HMI-Funktionen von zunehmender Bedeutung.

Kommerziell oder Open Source?

Auf dem Markt gibt es ein großes Angebot an kommerzieller und quelloffener Systemsoftware mit jeweils eigenen Vor- und Nachteilen. Die Wahl jedoch fällt normalerweise auf kommerzielle statt preiswerter und allgegenwärtiger Open-Source-Angebote.

Ein Beispiel für ein kommerzielles System für Medizingeräte ist das »Medical Profile« für »VxWorks«. Dies ist ein komplettes RTOS von Wind River für Medizingeräte bis zur Class III. Es erweitert VxWorks um Safety-, Security-, Konnektivitäts-, Manageability-, User-Interface- und Grafik-Leistungsmerkmale und beinhaltet ein Compliance-Package für Zulassungen bei der FDA (U.S. Food and Drug Administration) und anderen Regulierungsbehörden weltweit.

Open-Source-Softwareoptionen wie Linux sind aus mehreren Gründen ebenfalls populär. Erstens sind Linux-Distributionen kostenlos und können modifiziert und wiedervertrieben werden. Außerdem erfreut sich Linux einer breiten Akzeptanz bei den Entwicklern und macht es einfach, Expertise zu finden. Linux ist auch ein sehr ausgereiftes Betriebssystem mit hohem Funktionsumfang hinsichtlich Tools, Management, Security und Grafik. Ferner läuft Linux auf praktisch allen Prozessoren und wird durch fast alle bedeutenden Hardwarehersteller unterstützt. Abschließend ist das umfangreiche Ökosystem an Board- und Softwarelieferanten zu erwähnen. Der Einsatz von quelloffener Software bringt jedoch einige Herausforderungen mit sich. Dazu gehört die Befolgung mehrerer FDA-Richtlinien und des Softwarestandards IEC 62304, was heute von den meisten Behörden anerkannt beziehungsweise verlangt wird.

Über den Autor:

Stephen Olsen arbeitet im Product Management bei Wind River.

Lesen Sie mehr zum Thema