Die erste Frage ist nicht, welchen Roboter Sie kaufen

Serviceroboter-Hersteller wollen in den europäischen Markt, und sie wollen ins Gesundheitswesen. Die Nachfrage ist da: Kliniken suchen Entlastung bei Transporten, Besucherführung und Auskünften. Die Hardware kann das. Navigation, Nutzlast, Laufzeit und Fertigungsqualität haben ein Niveau erreicht, das den Klinikalltag trägt. Was den Einsatz aufhält, liegt fast nie am Gerät.

Es liegt strukturell außerhalb davon. Architektur und Betriebsmodell heutiger Roboterlösungen sind für Märkte entstanden, in denen ein Gerät weitgehend für sich arbeitet und seine Daten in der Cloud des Herstellers verwaltet werden. Das ist dort eine gute Entscheidung. Der europäische Klinikbetrieb funktioniert anders: Ein Roboter ist dort ein IT-System in einer sensiblen Umgebung, angeschlossen an Aufzüge, Türen, Zutrittssysteme und Klinik-IT, mit nachweisbaren Datenflüssen und dokumentierten Rechten. Diese Lücke liegt nicht in der Robotik. Sie liegt in der Schicht darüber.

Wenn wir mit Einrichtungen und mit Integratoren sprechen, kommen fast immer die gleichen zwei Fragen. Erstens: Warum braucht es überhaupt eine zusätzliche Softwareschicht zwischen Roboter und Haus? Zweitens: Warum nicht einfach die Lösung nehmen, die der Roboterhersteller mitliefert? Beide Fragen sind berechtigt, und dieser Beitrag beantwortet sie getrennt für die zwei Gruppen, die sie stellen. Athegus ist als Spin-off der TH Deggendorf aus dem Forschungsprojekt SMART FOREST 5G Clinics hervorgegangen; unsere Plattform Axiona läuft seit 2023 im Klinikalltag und ist in sechs unabhängig begutachteten Publikationen dokumentiert.

Für Einrichtungen

Die erste Frage in einem Robotikvorhaben ist nicht, welchen Roboter Sie kaufen. Sie lautet, wie der Betrieb aussehen soll: Welche Aufgabe soll ein Roboter übernehmen, welche Systeme muss er dafür erreichen, wer darf ihn beauftragen, und was müssen Sie hinterher belegen können? Ist das geklärt, bleibt die Gerätewahl eine fachliche Frage nach Aufgabe, Maßen und Eignung. Wird die Reihenfolge umgedreht, legt das erste Gerät fest, wie Ihr Betrieb künftig funktioniert.

Wo der Nutzen entsteht

Ein Roboter, der einen Gang entlangfährt, ist noch keine Entlastung. Sie entsteht dort, wo Roboter / Gebäudetechnik / IT zusammenkommen: Der Transport beginnt, weil ein Auftrag aus dem Fachsystem kommt. Der Roboter erreicht die dritte Etage, weil er den Aufzug rufen darf. Er kommt durch die Brandschutztür, weil die Steuerung sie freigibt. Er darf in den Laborbereich, weil das Zutrittssystem ihn kennt. Und die Probe ist auffindbar, weil die Übergabe protokolliert wurde. Jeder dieser Punkte liegt außerhalb des Geräts.

Deshalb ist die zusätzliche Schicht kein Selbstzweck, sondern der Ort, an dem diese Verbindungen einmal entstehen und danach für jedes weitere Gerät gelten. Aufzug, Türen, Zutritt, HIS und LIS, Rollen und Rechte, Protokollierung und Reporting binden Sie einmal an, nicht je Robotermodell erneut. Damit bekommen Sie auch das, was eine gemischte Flotte im Alltag braucht, nämlich eine Auftragssteuerung, eine Rechteverwaltung und ein Berichtswesen, unabhängig davon, welches Gerät gerade fährt.

Dass dieser Ansatz trägt, zeigt der hospOS-Livebetrieb: 80,68 % der Laborproben-Transporte übernimmt dort ein Roboter. Dieser Anteil kommt nicht allein aus der Leistung des Geräts, sondern daraus, dass Auftrag, Aufzug, Fahrt und Übergabe ohne manuelle Zwischenschritte zusammenlaufen.

Souveränität ist eine Frage der Architektur

Der zweite Teil der Antwort betrifft die Daten. Ein Serviceroboter im Stationsflur führt Kamera und Mikrofon mit sich. Die Sensibilität ergibt sich schon aus dem Ort: Patientenzimmer, Anmeldung, Labor, Wartebereich. Es braucht keine Namensliste, damit eine Aufnahme aus einem Stationsflur personenbezogen ist. Das ist der Grund, warum in Kliniken die Frage nach dem Datenfluss früher gestellt wird als in anderen Branchen, und warum sie oft darüber entscheidet, ob ein Vorhaben überhaupt startet.

Die tragfähige Antwort darauf ist kein zusätzliches Vertragswerk, sondern eine Architektur, die die Frage kleiner macht.

„Was die Einrichtung nicht verlässt, braucht keine Übermittlungsgrundlage.“

Das ist kein rechtlicher Kunstgriff, sondern die Konsequenz der Datenhaltung. Läuft die Koordination lokal, bleiben Karten, Aufträge, Telemetrie und Aufnahmen in Ihrer Umgebung, und die Prüfung verschiebt sich von „auf welcher Grundlage übermitteln wir?“ zu „was verlässt das Haus überhaupt?“. Axiona ist darauf ausgelegt: Drei Betriebsmodi – Cloud, On-Premise und vollständig offline – tragen dieselbe Funktionslogik. Der Modus bleibt damit eine Betriebsentscheidung Ihres Hauses und wird nicht durch das Produkt vorgegeben. Wie das technisch aussieht, steht in Servicerobotik ohne Datenabfluss.

Damit rückt auch die Herkunft einer Lösung an die richtige Stelle. Für einige Herkunftsländer der Servicerobotik liegt ein Angemessenheitsbeschluss der EU-Kommission vor, etwa für Japan und die Republik Korea, für andere nicht. Das ist eine Feststellung zur Rechtslage, keine Bewertung eines Landes. Eine kapselbare Architektur macht Sie von dieser Unterscheidung unabhängig, weil Sie die Frage nicht je Hersteller neu beantworten müssen.

Wichtig ist dabei eine Unterscheidung, die in Beschaffungsgesprächen oft untergeht: Speicherort und Zugriffsmöglichkeit sind zwei verschiedene Dinge. Ein Server im Haus sagt nichts darüber, wer aus der Ferne auf ihn schauen kann. Der Europäische Datenschutzausschuss hat das in den Leitlinien 05/2021 (Version 2.0, angenommen am 14. Februar 2023) ausbuchstabiert: Rn. 9 nennt drei kumulativ zu erfüllende Kriterien, damit eine Verarbeitung als Übermittlung gilt. Rn. 16 hält fest, dass auch ein Fernzugriff aus einem Drittland eine Übermittlung sein kann, selbst wenn Daten dort lediglich auf einem Bildschirm angezeigt werden, etwa bei Support, Fehlersuche oder Administration, sofern die drei Kriterien aus Rn. 9 erfüllt sind. Umgekehrt stellt Rn. 17 klar, dass eine rein interne Verarbeitung, bei der Daten keinem weiteren Verantwortlichen oder Auftragsverarbeiter offengelegt werden, keine Übermittlung im Sinne von Kapitel V ist. Das ist die architektonische Begründung für den Satz oben. Ob die Kriterien im Einzelfall erfüllt sind, beurteilen Ihre Datenschutzfunktion und Ihre Rechtsberatung. Die Architektur bestimmt, wie oft diese Prüfung überhaupt anfällt.

Daraus folgt für uns ein Konstruktionsprinzip, kein Misstrauensvotum: Kein stehender Fernzugriff. Es gibt keinen dauerhaft offenen Kanal von außen in die Anlage. Remote-Support läuft als Sitzung – von der Einrichtung freigeschaltet, zeitlich begrenzt, protokolliert. Für Hersteller und Integratoren ist das kein Verlust an Servicefähigkeit, sondern die Form, in der Fernunterstützung in einer regulierten Umgebung belastbar vereinbart werden kann und in einer Ausschreibung vorzeigbar ist.

Nachweisen, was tatsächlich passiert ist

Wer Robotik in einer regulierten Umgebung einsetzt, muss den Betrieb nicht nur sicherstellen, sondern belegen können: Wer hat einen Auftrag ausgelöst, welche Rolle war dazu berechtigt, welche Fahrt hat wann stattgefunden, welche Systeme waren beteiligt? Solche Nachweise entstehen nicht nachträglich aus den Betriebsdaten einzelner Geräte, sondern in der Schicht, die alle Aufträge sieht. Rollen und Rechte, Protokolle und Berichte gehören deshalb dorthin.

Ein Detail, das wir bewusst so gebaut haben: Eine Datenlücke wird als Datenlücke ausgewiesen, nicht als Null. Fehlt für einen Zeitraum die Erfassung, steht genau das im Bericht. Eine Kennzahl, die eine Lücke als Nullwert glättet, sieht besser aus und ist im Audit wertlos. Wie sich das zu den Nachweispflichten aus KRITIS und NIS-2 verhält, steht im Praxisleitfaden zu KRITIS und NIS-2 im Robotereinsatz; die Prinzipien dahinter finden Sie unter Souveränität und Sicherheit. Protokolle und Berichte ersetzen keine Compliance-Organisation, senken aber den Nachweisaufwand. Was die Einrichtung nicht verlässt, macht die Frage nach der Übermittlungsgrundlage in vielen Fällen gegenstandslos.

Wenn Sie ein Vorhaben planen, ist der konkrete Weg der schnellste: Zeigen Sie uns einen Ihrer Abläufe, und wir zeigen Ihnen, wie er über eine neutrale Schicht läuft, in dem Betriebsmodus, den Ihr Haus verlangt. Demo anfragen.

Für Integratoren und Systemhäuser

Für Integratoren und Systemhäuser stellt sich die Frage nach der zusätzlichen Schicht anders. Sie lautet nicht, ob eine solche Schicht nötig ist, sondern wer sie baut und pflegt. Eigene Robotik-Software ist dabei selten die günstigste Variante. Der Aufwand entsteht nicht bei der ersten Integration, sondern bei der zehnten und in allem, was dauerhaft mitläuft: Aufzugsprotokolle, Türsteuerungen, Zutrittssysteme, Rollenmodelle, Update-Wege und Betriebsmodi.

Die Arbeitsteilung

Die Aufteilung, die in der Praxis funktioniert, folgt dem, was jede Seite tatsächlich besitzt. Sie haben den Kundenzugang, das Anlagen-Know-how vor Ort, die Abnahme und die Inbetriebnahme. Das ist Kapital, das sich nicht einkaufen lässt. Die Plattform liefert Orchestrierung, Gebäudeanbindung, Betriebsmodell und Nachweise. Sie arbeiten über die GUI oder headless über die REST-API. So bauen Sie Ihre eigene kommerzielle Lösung, mit Ihrer Marke und Ihrem Vertragsverhältnis, ohne ein eigenes Robotik-Team aufzubauen.

Der Hebel liegt in der gemeinsamen Integrationsbibliothek. Jede neue Integration – ein Aufzugstyp, ein Zutrittssystem, ein Robotermodell – steht anschließend allen Branchenlösungen auf Axiona zur Verfügung: Für hospOS ebenso wie für shoppiOS. Ihre Arbeit an einem Klinikprojekt trägt damit auch das nächste Handelsprojekt.

Mischflotte, Gerätewechsel, Betriebsmodell

Damit zur zweiten Frage: Warum trägt die Software, die ein Gerät mitbringt, den Betrieb in der Regel nicht allein? Nicht, weil sie schwach wäre, sondern weil sie für ein Gerät gebaut ist und der Betrieb aus mehreren besteht. Drei Beobachtungen aus der Praxis:

Die Mischflotte ist der Normalfall, nicht die Ausnahme. In den Kliniken am Goldenen Steig in Freyung laufen mehrere Gerätetypen über dieselbe Plattform, unter anderem Keenon T3, Keenon W3 und temi v2, an einer einmal eingerichteten KONE-Aufzugsintegration. Am Technologie Campus Grafenau dient dieselbe Basis als Testumgebung für neue Modelle und Aufzugssteuerungen. Kaum ein Haus wählt ein Gerät für alle Aufgaben: Ein Transportroboter für Laborproben, ein Begleitroboter für die Pforte und ein Reinigungsgerät sind drei verschiedene Maschinen, oft von drei Herstellern. Eine gerätenahe Software kennt sinnvollerweise ihr Gerät sehr genau. Den Überblick über eine gemischte Flotte kann sie nicht liefern, weil das nicht ihre Aufgabe ist. Die Installationen sind unter Referenzen dokumentiert.

Hardware wird ersetzt, Abläufe bleiben. Ein Robotermodell hat einen kürzeren Lebenszyklus als ein Klinikablauf. Steckt die Ablauflogik im Gerät, wird jeder Gerätewechsel zu einem Integrationsprojekt. Liegt sie in der Schicht darüber, ist er eine Beschaffung. Für Sie ist das der Unterschied zwischen einem Projekt, das Sie einmal verkaufen, und einer Installation, die über Jahre wächst. Ausführlich dazu: Mehr Roboterauswahl ohne Systemwechsel.

Das Betriebsmodell ist Voraussetzung, nicht Zusatz. In Kliniken, bei Versorgern und in anderen regulierten Umgebungen kommen Datenhaltung, Fernzugriff und Nachweisführung nicht am Ende der technischen Klärung, sondern am Anfang. Wer sie erst in der Abnahme beantwortet, verhandelt sie unter Zeitdruck. Wer sie mitbringt, hat einen Teil der Ausschreibungsarbeit bereits erledigt.

„Mit einer kapselbaren, offline-fähigen Schicht wird das Betriebsmodell zum Verkaufsargument des Integrators, statt zum Projektrisiko.“

Sie gehen mit einer belegbaren Antwort in das Gespräch statt mit einer Zusage, die Sie später einholen müssen. Das verschiebt die Diskussion mit Datenschutz, IT und Technik von „ist das überhaupt zulässig?“ zu „welchen Ablauf nehmen wir zuerst?“. Die Einzelfallprüfung durch Datenschutzfunktion und Rechtsberatung des Hauses bleibt davon unberührt.

Wenn Sie Robotik in Ihr Portfolio aufnehmen oder ein laufendes Projekt auf eine tragfähige Basis stellen wollen, sprechen wir über die Arbeitsteilung. Partner werden.

Das Ökosystem bleibt offen

Neue Robotermodelle werden über Adapter angebunden, nicht über eine Sonderlösung pro Projekt, und jede neue Integration kommt allen Branchenlösungen auf Axiona zugute. Wer mit guter Hardware in den europäischen Gesundheitsmarkt will, muss dafür weder seine Architektur umbauen noch ein eigenes europäisches Betriebsmodell nachbauen: Der kürzere Weg führt über eine Schicht, die es schon gibt, die seit 2023 im Klinikalltag läuft und die den Integrations- und Nachweisteil übernimmt. Ihre Geräte kommen damit für mehr Ausschreibungen infrage, nicht für weniger. Partner werden.