Interoperabilität für medizinische Geräte
Plug-and-Play im Gesundheitswesen
In der PC-Welt funktioniert inzwischen die Interoperabilität meist reibungslos - Standards wie USB und Bluetooth sei Dank. Davon kann auch das Gesundheitswesen profitieren, zumal sich viele Experten dadurch hohe Kosteneinsparungen versprechen. Dabei gibt es verschiedene Implementierungsansätze. Im Folgenden werden eine vollintegrierte und eine modulare Lösung vorgestellt und ihre jeweiligen Vor- und Nachteile aufgezeigt.
Das Konzept interoperabler medizinischer Geräte existiert bereits seit einiger Zeit: Schon seit dem Ende des 20. Jahrhunderts wird über entsprechende Standards diskutiert, und inzwischen scheinen wir der praktischen Umsetzung Plug-and-Play-fähiger medizinischer Geräte immer näher zu kommen. Vor dem Hintergrund ständig steigender Gesundheitskosten entstanden Organisationen, die klinische Geräte (für Krankenzimmer und Operationssäle) standardisieren und die Branche für die gesundheitliche Versorgung zu Hause mit aufbauen sollen.
In der Vergangenheit war es für Dritte sehr kostspielig und außerdem zu zeit- und arbeitsaufwändig, eine interoperable Umgebung zu schaffen. Erklärtes Ziel eines Standards ist es, diesen Zeit- und Kostenaufwand zu eliminieren. Die Effektivität interoperabler Geräte wurde mit den WiFi-Netzwerken (IEEE 802.11) sowie mit Bluetooth-Zubehör für Mobiltelefone klar bewiesen. Die gleichen Konzepte sollten auch auf medizinische Geräte angewandt werden.
Denn die Implementierung einer Plug-and-Play-Umgebung resultiert in zahlreichen Vorteilen für den Markt und - was noch wichtiger ist - für die Patienten. Zu diesen Vorteilen gehören der Produktivitätszuwachs, weniger Behandlungsfehler, die Möglichkeit zum Erfassen und Austauschen von Informationen in Echtzeit sowie mehr Sicherheit für den Patienten. Die Interoperabilität medizinischer Geräte wird durch eine Kombination aus standardisierter, bekannter und geprüfter Hardware mit betriebssicherer und dennoch flexibler Firmware erzielt. Durch das Zusammenführen etablierter und erprobter Hardware mit der Firmware entstehen Designs, die robust, effizient und überdies relativ unkompliziert sind.
Auf Standards aufbauen
Die »Continua Health Alliance«, eine der wenigen Standardisierungsorganisationen im Bereich der Interoperabilität medizinischer Geräte, wurde für den entstehenden Markt der »Home Health«-Geräte ins Leben gerufen. Sie fand Unterstützung durch eine Vielzahl großer Unternehmen, darunter Medizintechnik-Hersteller ebenso wie Krankenhäuser und Versicherungsunternehmen, aber auch andere Standardisierungsorganisationen.
Erst kürzlich beschloss die Continua Health Alliance die Ausweitung ihres Tätigkeitsfelds vom Home-Health-Markt auf einen größeren Teil des Gesundheits-Ökosystems, um das gesamte Spektrum vom Patienten bis zu den elektronischen Krankenakten abzudecken. Die Continua Health Alliance entschied sich dafür, Standardschnittstellen zu verwenden, um von dem, was in der Welt der Elektronik bereits verfügbar und bekannt ist, profitieren zu können. Bis dato fiel die Wahl auf folgende Standards:
- USB (für leitungsgebundene Schnittstellen),
- Bluetooth (für drahtlose Schnittstellen),
- ZigBee (für wenig Strom verbrauchende LAN-Sensorschnittstellen) und
- Bluetooth Low Energy (für sparsame PAN-Schnittstellen).
Hinsichtlich der Firmware ist die Verwendung etablierter Technologien sehr attraktiv, ermöglicht sie doch eine einfache Implementierung. Allerdings ist jeder Standard durch eine Variante zu ergänzen, die auf ein bestimmtes Datenformat ausgerichtet ist und einen effizienten Datenfluss ermöglicht. Bei Continua fiel die Entscheidung, zusätzlich zu den Hardware- und Firmware-Standards auch das Datenformat des auf medizinische Geräte ausgerichteten Standards IEEE 11073 zu nutzen.
Der IEEE-11073-Stack ist zwischen den bestehenden unteren Schichten des Kommunikations-Stacks und dem Applikations-Code des medizinischen Geräts angesiedelt und arbeitet mit diesen zusammen (Bild 1). Im Standard IEEE 11073 sind die Informationsübertragung und die Gerätespezifikationen bestimmter medizinischer Applikationen definiert. Tabelle 1 enthält ein Beispiel für das, was definiert wurde. Auch wenn keine Rücksicht auf die Interoperabilität genommen werden muss, ist das Design und die Produktion eines medizinischen Geräts allein alles andere als trivial.
Je nach Anwendung sind Designzyklen von einem bis drei Jahren oder mehr keine Seltenheit. Unter Umständen sind überdies klinische Versuche und die behördliche Zulassung erforderlich. Eine zusätzlich hinzukommende Funktion wie die Plug-and-Play-Kommunikation macht das Design noch komplexer, speziell wenn das Team mit dieser Technik nicht vertraut ist. Beim Abstecken der Strategie für ein solches Design sind einige Aspekte zu beachten:
- Zeit- und Ressourcenbedarf,
- Kosten,
- Platzaufwand,
- Leistungsaufnahme und
- Systemressourcen.
Berücksichtigt man diese Aspekte, können die Entwickler mit Überlegungen beginnen, welche Lösung oder welche Lösungskombination für das Design in Frage kommt. Abhängig von der verfügbaren Zeit, dem Aufwand an Ressourcen und Know-how, den Kosten und dem angestrebten Integrationsgrad stehen dem Designteam verschiedene Alternativen zur Wahl. Die Bilder 2 und 3 zeigen zwei verschiedene in Frage kommende Lösungen. Diese sind bei weitem nicht die einzigen Implementierungsmöglichkeiten, stellen aber verschiedenartige Ansätze dar. Je nach den Anforderungen des Designs lassen sie sich auch kombinieren und individuell zuschneiden.
Vollintegrierte Lösung
Bild 2 zeigt eine vollintegrierte Lösung. Die Stack-Software und die verschiedenen Protokolle residieren hier im Applikations-Mikrocontroller. Die drahtlosen Übertragungsfunktionen und die USB-Schnittstelle wurden mit Blick auf minimale Kosten implementiert. Die externen Funkeinheiten mit ihren zugehörigen Schaltungen einschließlich der Antenne sind über bekannte Schnittstellen (z.B. SPI, UART, usw.) an den Applikations-Mikrocontroller angeschlossen. Der in den Mikrocontroller integrierte USB-Port benötigt zusätzliche Schaltungen für die physische Schnittstelle und die Anbindung an die Außenwelt.
Wie Bild 2 zeigt, gliedert sich die Lösung in den Abschnitt »Application«, in dem die Datenerfassung erfolgt, und den Teil »Communication« für die Weitergabe der erfassten und aufbereiteten Daten. Der interne Speicher des Mikrocontrollers muss selbstverständlich ausreichend groß für den Applikationscode und die ausgewählten Kommunikations-Stacks sein. Die Mikrocontroller der »STM32«-Familie auf »ARM Cortex«-Basis von STMicroelectronics bieten skalierbare Speicherkapazitäten und sind über die meisten Speicherdichten hinweg 1:1 pinkompatibel.
Ist ein Design mit unterschiedlich vielen Kommunikationsprotokollen zu bestücken, kann der Designer die Speicherkapazität somit dem jeweiligen Bedarf entsprechend individuell anpassen, ohne dass das Layout für den Mikrocontroller verändert werden muss. Es bedarf eigentlich keiner Erwähnung, dass der Mikrocontroller in seiner Performance und seinen Ressourcen für die verschiedenen Kommunikationsprotokolle gerüstet und auch in der Lage sein muss, den Applikationscode zu verarbeiten. Voraussetzung hierfür ist eine entsprechende Ressourcenzuweisung. Ein Echtzeitbetriebssystem könnte ebenfalls eingesetzt werden, um die Ressourcen des Mikrocontrollers zu verwalten, jedoch würde dies den Speicherbedarf des Designs in die Höhe treiben.
Modular Ansatz
Einen stärker modularen Ansatz stellt die zweite Lösung in Bild 3 dar. Applikations-Mikrocontroller und Applikationscode stimmen mit der Lösung aus Bild 2 überein, doch kommt es bei dieser Lösung weniger auf die Kosten und den Platzbedarf an, während die Einfachheit des Designs wichtig für den Zeitaufwand ist. Die wichtigste Besonderheit ist, dass der Kommunikationsteil durch ein eigenständiges IC oder Modul realisiert wird.
Um die Kommunikationsprotokolle zu implementieren, muss der Entwickler somit nicht über das Innenleben der Module Bescheid wissen. Der Applikations-Mikrocontroller bedient sich der gleichen standardmäßigen Kommunikations-Ports (SPI, UART, usw.) wie zuvor, während die externen Module beziehungsweise ICs die jeweiligen Protokoll-Stacks enthalten. Der Applikations-Mikrocontroller muss sich hier ausschließlich der Verarbeitung des Applikationscodes widmen und die erfassten und aufbereiteten Daten an die Kommunikationsmodule übergeben. Er sendet dazu über die Kommunikationsschnittstellen einfache Befehle an die Module, welche die Daten daraufhin in medizinspezifische Informationen verwandeln und weiterleiten.
Diese zweite Variante lässt sich einfacher implementieren, da die Protokoll-Stacks eigenständig implementiert sind. Die Hardware wird jedoch durch die Module und den zusätzlichen Mikrocontroller teurer. Es steht außer Zweifel, dass die erste Lösung kostengünstiger ist als die zweite, doch ist es abhängig von den Kriterien für das Design auch möglich, Konzepte aus Bild 2 und 3 miteinander zu kombinieren.
Unter Berücksichtigung der Kosten-, Zeit-, Performance- und Ressourcenvorgaben kann das Design so flexibel wie nötig gestaltet werden. Die einfache Implementierung steht bei diesen Designs nicht im Vordergrund. Die verfügbaren Optionen und Komponenten machen die Auswahl der Alternativen und deren Implementierung jedoch so unkompliziert wie irgend möglich. Hersteller medizinischer Geräte müssen keineswegs Experten im Bereich der drahtlosen Übertragungsstandards, der USB-Technik, der IEEE-Normen und der elektronischen Krankenakten sein.
Auch wenn die Interoperabilität medizinischer Geräte nach wie vor keine einfache Sache ist, gibt die Verfügbarkeit von immer mehr System-on-Chip-Mikrocontrollern, großen Flash-Speichern und unterschiedlichsten Kommunikationsports den Designingenieuren die Möglichkeit, flexible und skalierbare Designs hervorzubringen. Da die Tools und Lösungen im Laufe der Zeit immer intuitiver geworden sind, können die Designer ihre Zeit und ihre Ressourcen immer mehr der eigentlichen Applikation widmen, anstatt sich mit den Kommunikationsprotokollen zu befassen.
| Spezifikation | Beschreibung |
|---|---|
| IEEE 11073-20601 |
Applikationsprofil - optimiertes Austauschprotokoll |
| IEEE 11073-10417 | Gerätespezifikation für Blutzuckermessgeräte |
| IEEE 11073-10a407 | Gerätespezifikation für Blutdruckmessgeräte |
| IEEE 11073-10415 | Gerätespezifikation für Waagen |
| IEEE 11073-10472 |
Gerätespezifikation für Medikations-Monitore |
Tabelle: Einige Gerätespezifikationen aus der IEEE 11073
Über den Autor:
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
STMicroelectronics
Energieeffizienter Single-Chip-Prozessor für Bluetooth 4.0
Healthcare-IT
Marabu beweist Interoperabilität beim Connectathon
