09.03.2012
Seite 6 von 6
Geräte-Fernsteuerung
Während chirurgischer Eingriffe müssen Assistenten sehr häufig Geräteeinstellungen vor-
nehmen wie beispielsweise die Regulierung von Raum- und OP-Licht sowie der Leistung
elektronischer Schneidinstrumente. Da die räumlichen Verhältnisse im Operationssaal ohne-
hin sehr begrenzt und die Geräte oftmals sehr ungünstig positioniert sind, ermöglicht die Be-
dienung der Gerätlandschaften an einem zentralen Punkt massive Arbeitsentlastungen. Au-
ßerdem könnte auf diesem Wege Einsparpotential für separate Monitore entstehen.
Bei der Fernsteuerung von Geräten gibt es verschiedene Design-Fragen und Herangehenswei-
sen zu berücksichtigen. Beispielsweise stecken einige Firmen sehr viel Know-How und Kapi-
tal in die Mensch-Maschine-Schnittstellen ihrer Produkte (grafische Bedienoberflächen). Kli-
nisches Personal erlernt die Bedienung von Geräten/Software anhand dieser speziellen Ober-
flächen. Es kann deshalb wünschenswert sein, wenn das Monitoring-Gerät keine eigenen gra-
fischen Bedienoberflächen aus den Geräteschnittstellen erstellt, sondern die GUI vom Gerät
selbst lädt und visualisiert. Hiermit gehen jedoch neue Probleme einher, nämlich:
1.
Jede Oberfläche muss sich dem Bildschirm des Monitoring-Gerätes anpassen können.
Dass es hier zu eklatanten Schwierigkeiten kommen kann, zeigen bereits die mannig-
faltigen Darstellungsformen für Smartphones, Tablet-PCs und PC-Monitore.
2.
Es gibt eine Fülle verschiedener technologischer Ansätze, aus denen einer für eine
mögliche Standardisierung herangezogen werden müsste; z. B. XUL, HTML, XAML,
URC usw. Gegenwärtig sind dabei noch immer Performanzverluste im Gegensatz zu
nativ umgesetzten Applikationen zu verzeichnen, weshalb der Einsatz grundsätzlich
in Frage gestellt werden sollte.
3.
Ein einheitliches Bedienkonzept geht verloren, wenn jedes Gerät seine eigenen grafi-
schen Schnittstellen liefert.
Ein möglicher Lösungsansatz wäre die Umsetzung einer Plugin-Architektur, mit der Schnitt-
stellen dynamisch an einem Monitoring-/Steuerungsgerät nachinstalliert werden können. Mo-
derne Plugin-Ansätze wie OSGi unterstützen bereits die Hot-Plug-Installation von Software.
Klarer Nachteil ist, dass man sich durch so eine fest definierte Architektur von Betriebssyste-
men und Programmiersprachen abhängig macht, was schlussendlich dem Sinn der Web-
Service-Philosophie widerspräche.
Falls es zukünftig standardisierte Schnittstellen gibt, kann davon ausgegangen werden, dass
Klassen bestimmter Geräte über uniforme Funktionen verfügen. Hersteller von fernsteuernden
Geräten könnten den Basissatz an Funktionalität vorimplementieren, so dass auf das dynami-
sche Nachladen von Plugins weitestgehend verzichtet werden kann.
Fazit
Allgemeines Geräte-Monitoring lässt sich relativ einfach und flexibel in der Applikations-
schicht einer DPWS-Anwendung platzieren. Geräte liefern diverse Daten wie den Gerätezu-
stand, Abbildungen, Modell-, Seriennummer etc. Die Monitoring-Geräte visualisieren diese
Daten entsprechend und können Teil eines OP-Managementsystems sein oder in Form eines
Tablet-PCs ausgeliefert werden. Komplizierter gestaltet sich ein generischer Ansatz zur Gerä-
tefernsteuerung. Es ist damit zu rechnen, dass zunächst primitive Plugin-Ansätze verfolgt
werden, um verschiedenste Geräteschnittstellen zur Fernsteuerung zugänglich zu machen. Für
Standardfunktionalität müssen sich allgemeine, klassenbasierte Geräteschnittstellen durchset-
zen, um adäquate Interoperabilität zu generieren.