Publikation: hospOS: A Platform for Service Robot Orchestration in Hospitals
Autoren: S. Schmidt, D. Sommer, T. Greiler, F. Wahl
Erschienen in: ICT4AWE, S. 221–228 (2024)
Der Beitrag in Kürze
Krankenhäuser, die Serviceroboter einführen wollen, stoßen schnell auf eine ernüchternde Realität: Jeder Roboter bringt seine eigene, geschlossene Steuerung mit. Wer einen Transportroboter, einen Empfangsroboter und ein Telemedizin-System kombinieren will, betreibt am Ende drei getrennte Insellösungen, die weder miteinander noch mit der Klinik-IT sprechen. Das ist teuer, unflexibel und skaliert nicht.
Dieses Paper – die grundlegende Architekturarbeit hinter hospOS – stellt einen anderen Weg vor: ein zentrales System, das vorhandene Serviceroboter verschiedener Hersteller orchestriert, statt für jede Aufgabe einen teuren Spezialroboter zu beschaffen.
Warum das Thema gerade jetzt drängt
Der Pflegealltag in Kliniken ist von Tätigkeiten geprägt, die zwar notwendig, aber wenig wertschöpfend sind: Wege über lange Flure, das Holen und Bringen von Material, das Begleiten und Orientieren von Besuchern. Jede Minute, die Fachpersonal mit Transport oder Auskunft verbringt, fehlt am Patientenbett. Serviceroboter versprechen hier Entlastung – gerade in ländlichen Häusern, in denen Personal knapp ist und Wege oft weit sind.
Die Erwartung, dass ein einzelner Roboter all diese Aufgaben übernimmt, führt jedoch regelmäßig in die Sackgasse. Eine Maschine, die transportieren, empfangen und gleichzeitig telemedizinisch unterstützen soll, wird teuer, kompliziert und am Ende keiner Aufgabe wirklich gerecht. Genau an diesem Punkt setzt die Arbeit an: Sie verschiebt den Blick von der einzelnen Maschine auf das System, das mehrere Maschinen sinnvoll zusammenführt.
Das Problem: geschlossene Systeme, fehlende Interoperabilität
Die zwei größten Hürden für den Robotereinsatz im Gesundheitswesen sind laut der Arbeit die aufgabenspezifische Unflexibilität der Roboter und der Mangel an Interoperabilität. Existierende Systeme sind in der Regel darauf ausgelegt, dass ein einzelner Roboter sämtliche Anforderungen allein erfüllt – mit dem Ergebnis komplexer und kostspieliger Lösungen.
Hinzu kommt, dass jeder Hersteller seine eigene Schnittstelle, seine eigene Bedienlogik und sein eigenes Datenmodell mitbringt. Für eine Klinik bedeutet das: Mit jedem zusätzlichen Roboter wächst nicht nur die Anschaffung, sondern auch der Integrations- und Betriebsaufwand. Aktualisierungen, Wartung und Schulungen vervielfachen sich, weil nichts auf einer gemeinsamen Grundlage steht.
Der Gegenentwurf: vorhandene, bezahlbare Roboter für unterschiedliche Aufgaben nutzen und kombinieren. Mit wachsendem Robotereinsatz wird ein dediziertes Management-System – ein „Robot Management System" – zur Notwendigkeit. Es übernimmt die Rolle, die in der klassischen IT ein Betriebssystem spielt: Es vermittelt zwischen heterogener Hardware und den Anwendungen, die auf ihr laufen sollen, und macht aus einer Sammlung von Einzelgeräten ein steuerbares Ganzes.
Die Lösung: modular, flexibel, regelkonform
hospOS ist als zentralisierte Plattform für die Orchestrierung von Servicerobotern konzipiert. Drei Prinzipien prägen die Architektur:
- Interoperabilität: nahtlose Einbindung verschiedener Roboter in die bestehende Krankenhaus-IT-Infrastruktur.
- Modularität: Funktionen lassen sich einzeln ergänzen, statt ein monolithisches Gesamtsystem kaufen zu müssen.
- Regelkonformität: Compliance mit Vorgaben und Industriestandards ist von Beginn an mitgedacht.
Das Paper liefert dazu einen konkreten Architektur-Blueprint und beschreibt, wie Aufgaben modelliert und an Roboter delegiert werden – etwa der Transport von Blutproben, der temperaturgeführte und zugangsgeschützte Transportbehälter erfordert.
Der Gedanke dahinter ist bewusst nüchtern: Nicht jeder Roboter muss alles können. Eine Aufgabe wird so beschrieben, dass das System anhand der Anforderungen das passende Gerät auswählen und beauftragen kann. Damit lässt sich der Bestand schrittweise erweitern – ein zusätzlicher Roboter, eine zusätzliche Funktion – ohne die gesamte Lösung neu beschaffen zu müssen. Das senkt die Einstiegshürde und macht den Ausbau planbar.
In zwei Kliniken erprobt
Die Plattform wurde nicht am Reißbrett belassen, sondern in zwei ländlichen Krankenhäusern entlang von drei Anwendungsfällen umgesetzt: Telemedizin, Transport und Orientierung. Die Erfahrungen aus diesen Deployments deuten auf Verbesserungen bei der Leistungserbringung und im operativen Management hin.
Dass die Erprobung im realen Klinikbetrieb stattfand und nicht im Labor, ist dabei kein Detail, sondern der Kern: Eine Architektur, die unter den Bedingungen knapper Ressourcen, gewachsener IT und alltäglicher Betriebslast besteht, hat ihre Tragfähigkeit unter Beweis gestellt. Genau diese drei Anwendungsfälle – das Begleiten und Orientieren von Menschen, der gesicherte Transport und die telemedizinische Anbindung – stehen exemplarisch für die Bandbreite, die ein orchestrierendes System abdecken muss.
Die Grundlage unserer Plattform
Dieses Paper ist der konzeptionelle Ursprung von Athegus. Die hier beschriebene Idee – eine herstellerunabhängige Softwareschicht zwischen Robotern und der Außenwelt – ist heute unser Produkt: die Middleware Axiona und der branchenspezifische Layer hospOS für das Gesundheitswesen. Wer verstehen will, warum wir nicht „noch einen Roboter", sondern die orchestrierende Schicht bauen, findet hier die Begründung.
Aus dieser Haltung folgt auch unser Verständnis von digitaler Souveränität: Wer die orchestrierende Schicht kontrolliert, bleibt unabhängig von einzelnen Herstellern und behält die Hoheit über die eigenen Abläufe und Daten. Mehr dazu auf der Seite zur Souveränität.