Warum Integration über den Erfolg entscheidet

Ein Transportroboter, der Medikamente holt, ist technisch beeindruckend. Nützlich wird er aber erst, wenn er die Station auch wirklich erreicht. Und genau daran scheitern viele Projekte — nicht am Roboter, sondern an der Umgebung. Türen, Aufzüge und die gewachsene Klinik-IT sind im Alltag die eigentlichen Hürden.

Ein Krankenhaus ist eben keine offene Lagerhalle. Es steckt voller Brandschutztüren, enger Flure und mehrerer Etagen, dazu kommt eine über Jahre gewachsene IT-Landschaft. Der Roboter muss sich in dieses Umfeld einfügen, ohne den Betrieb zu stören. Das ist am Ende eine Frage der Integration, nicht der Robotertechnik.

Der Wettbewerb entscheidet sich deshalb weniger am einzelnen Roboter als an seiner Anbindung. Zwei baugleiche Modelle können sich im Alltag völlig unterschiedlich schlagen, je nachdem, wie gut sie mit Türen, Aufzügen und Software sprechen. Wer Klinikrobotik bewertet, sollte darum zuerst auf die Integration schauen. Der Datenblatt-Wert des Roboters verrät darüber erstaunlich wenig.

Die drei Integrations-Ebenen im Überblick

Praktisch trennt man die Integration in drei Ebenen, die sich gut auseinanderhalten lassen. Auf der physischen Ebene geht es um Türen und Aufzüge, also um die Gebäudetechnik. Auf der Daten-Ebene geht es um die Anbindung an Klinik-Software wie KIS und LIS. Und auf der Flotten-Ebene geht es darum, mehrere Roboter über einen Leitstand zu koordinieren.

Diese drei Ebenen sind unterschiedlich weit. Türen und Aufzüge werden real genutzt, hängen aber stark vom jeweiligen Standort ab. Die Datenanbindung läuft von Projekt zu Projekt verschieden und ist selten Standard. Am jüngsten ist die herstellerübergreifende Flotten-Ebene, obwohl der zugrunde liegende Standard längst existiert.

Jede dieser Ebenen bringt eigene Anbieter, eigene Standards und eigene Grenzen mit. Ein Projekt kann auf einer Ebene glänzen und auf einer anderen scheitern. Deshalb lohnt es sich, sie einzeln zu betrachten statt über einen Kamm zu scheren.

Türen öffnen: Arm gegen Funk-Schnittstelle

Türen sind die häufigste physische Hürde, und für autonome Roboter gibt es dabei zwei grundverschiedene Wege. Der eine setzt auf einen mechanischen Arm, der Klinken und Knöpfe bedient wie eine Hand. Der andere setzt auf Funk, über den der Roboter Automatiktüren direkt anspricht.

Für den Arm-Ansatz steht der Roboter Moxi von Diligent Robotics. Laut Herstellerangaben öffnet Moxi Türen und drückt Aufzugknöpfe mit seinem Manipulator (Status: im Verkauf, Herstellerangabe). Das macht ihn flexibel, denn er kommt auch an Türen zurecht, die gar nicht vernetzt sind. Der Preis dafür ist mehr Mechanik und ein langsamerer Ablauf.

Die United Robotics Group verfolgt für ihre Klinik-Lösungen den umgekehrten Anspruch. Ihre Systeme sollen laut Anbieter „ohne Schienen und ohne Umbauten“ durch vorhandene Flure fahren (Herstellerangabe). In der Praxis läuft die automatische Türdurchfahrt aber meist über eine Funk-Schnittstelle zur Türsteuerung. Das ist schneller und robuster, setzt dafür nachgerüstete oder kompatible Automatiktüren voraus.

Aufzüge rufen und autonom nutzen

Der Aufzug ist die kniffligste physische Hürde im Krankenhaus. Der Roboter muss ihn rufen, die richtige Kabine erkennen, einsteigen und die Zieletage wählen — und dabei niemanden im Weg stehen. Das gelingt nur, wenn er an die Aufzugssteuerung angebunden ist.

Auch hier gibt es die beiden bekannten Wege. Ein Arm-Roboter wie Moxi drückt die Knöpfe physisch, was ohne Umbau am Aufzug klappt. Oder der Roboter spricht die Aufzugssteuerung per Funk an und ruft die Kabine digital. Der digitale Weg ist zuverlässiger, verlangt aber eine passende Schnittstelle am Aufzug.

Für die Praxis macht das den entscheidenden Unterschied. Erst ein Aufzug mit offener Schnittstelle macht den Betrieb über mehrere Etagen wirklich planbar. Fehlt diese Anbindung, bleibt der Roboter auf eine Etage beschränkt oder braucht menschliche Hilfe. Genau deshalb ist die Aufzug-Frage oft der Knackpunkt einer Ausschreibung.

Anbindung an Klinik-IT, KIS und LIS

Die Bewegung durchs Haus ist nur die halbe Miete. Ein Transportroboter muss auch wissen, was er wohin bringt. Diese Aufträge kommen aus der Klinik-Software, etwa dem Krankenhausinformationssystem (KIS) oder dem Laborinformationssystem (LIS). Ohne diese Datenanbindung fährt der Roboter blind.

Fertig von der Stange gibt es diese Datenanbindung selten. Jede Klinik hat ihre eigene, über Jahre gewachsene IT mit unterschiedlichen Systemen. Ein Roboter-Auftrag muss deshalb an vorhandene Schnittstellen andocken, oft über das Klinik-WLAN. Diese Kopplung hängt am jeweiligen Projekt und macht einen guten Teil des Integrationsaufwands aus.

Sobald Roboter Laborproben oder Patientendaten transportieren, wird die Sache sensibel. Es geht um Gesundheitsdaten, also um eine besonders geschützte Kategorie. Wer welche Probe wann übergibt, muss nachvollziehbar dokumentiert sein. Damit landet die Datenanbindung mitten im Feld von DSGVO und IT-Sicherheit, das wir weiter unten einordnen.

Leitstand und Flottenmanagement

Ein einzelner Roboter ist noch überschaubar. Spannend wird es, sobald mehrere gleichzeitig durchs Haus fahren. Dann braucht es einen Leitstand, der Aufträge verteilt, Wege koordiniert und Engpässe auflöst. Diese Software-Schicht nennt man Flottenmanagement.

Der Leitstand entscheidet zum Beispiel, welcher Roboter zuerst in den Aufzug darf. Er stellt dringende Fahrten vor, etwa den eiligen Labortransport vor der Wäscheabholung. Er meldet Störungen und behält den Ladezustand jeder Einheit im Blick. Ohne diese Koordination kämen sich mehrere Roboter schnell gegenseitig in die Quere.

Solange alle Roboter vom selben Hersteller stammen, ist das gelöst. Jeder größere Anbieter liefert seinen eigenen Flottenmanager gleich mit. Aethon bringt seinen Server, Swisslog sein Leitsystem, jeder AMR-Hersteller seine Plattform. Knifflig wird es erst, wenn Marken gemischt werden — und darum geht es im nächsten Abschnitt.

Herstellerübergreifende Orchestrierung

Kliniken kaufen selten alles aus einer Hand. Über die Jahre wachsen gemischte Flotten aus Transportrobotern, AGV und Servicerobotern verschiedener Marken. Das Problem dabei: Diese Systeme reden oft gar nicht miteinander. Jeder Roboter kennt nur seinen eigenen Leitstand.

Genau das soll die herstellerübergreifende Orchestrierung lösen. Eine neutrale Schicht koordiniert die Roboter mehrerer Marken über eine gemeinsame Plattform. Sie verteilt Aufträge, regelt die Vorfahrt am Aufzug und bündelt den Überblick. Das klingt nach einer frischen Idee — ist es aber nur zum Teil.

Denn Neuland ist das nicht. Der offene Kommunikationsstandard VDA5050 kümmert sich seit Jahren um das Mixed-Brand-Problem, und Anbieter wie Meili Robots bauen darauf ganze Plattformen. Ein neues „OS“ für Klinikroboter muss sich also an diesem Stand messen lassen, nicht an einem einzelnen Roboter. Wer Orchestrierung als brandneue Erfindung verkauft, übergeht eine längst etablierte Lösungsschicht.

Standards & Anbieter der Orchestrierung

Bei der Orchestrierung treffen vier ziemlich verschiedene Ansätze aufeinander. Ein offener Standard legt die gemeinsame Sprache fest. Neutrale Plattformen koordinieren darüber Roboter mehrerer Marken. Herstellereigene Flottenmanager bleiben dagegen an ihre Marke gebunden. Und neue Anbieter versuchen, eine eigene Betriebsschicht darüberzulegen.

Der Dreh- und Angelpunkt ist dabei VDA5050. Der Standard stammt aus VDA und VDMA und beschreibt, wie ein AMR mit einer übergeordneten Leitsteuerung spricht. In der Intralogistik ist er längst etabliert und wandert zunehmend in den Klinikbereich. Wichtig zu wissen: Er ist ein Kommunikationsprotokoll, kein fertiges Produkt.

Meili Robots aus Dänemark baut auf diesem Standard ein herstellerunabhängiges Flottenmanagement. Nach Anbieterangaben war die Interoperabilität im Gesundheitswesen sogar der ursprüngliche Auslöser des Produkts (sekundär). Das zeigt: Das Mixed-Brand-Problem im Klinikumfeld ist erkannt und wird bearbeitet. Es ist eben keine offene Baustelle, sondern ein bereits bestelltes Feld.

Elvio steht hier bewusst nur als frühes Beispiel in der Tabelle. Ein „Elvio OS“ als Orchestrierungs-Schicht ordnen wir über die Firma Elvio in unserem Firmenprofil ein. Der Ehrlichkeit halber: Ein öffentlich belegtes Produktdetail zu diesem OS ließ sich nicht sichern (Status: unbelegt). Wir behandeln den Anspruch als Unternehmensangabe, nicht als bewiesenen Marktstand — und verlinken die Firma, statt Inhalte doppelt aufzuführen.

Was heute wirklich funktioniert

Trennt man Vision von Alltag, sieht das Bild nüchtern aus. Real und im Einsatz ist die Nutzung von Türen und Aufzügen, sofern die Infrastruktur mitspielt. Der Marktführer im Wagen-Transport, ST Engineering Aethon, betreibt seine TUG-Systeme seit rund 20 Jahren in hunderten Kliniken. Diligent meldet für Moxi mehr als 1,25 Millionen Lieferungen in über 25 US-Kliniken (Herstellerangabe).

Auch die Datenanbindung funktioniert — aber als Projekt, nicht als Standard. Jede Klinik-Integration ist ihr eigener Aufwand, der geplant und getestet werden will. Die Marktzahlen stützen den Trend: Laut IFR World Robotics 2025 wurden 2024 rund 102.900 Transport- und Logistikroboter verkauft, ein Plus von 14 Prozent (PRIMÄR). Damit ist das das größte Serviceroboter-Segment.

Weniger weit ist die herstellerübergreifende Orchestrierung in der Fläche. Standard und Plattformen existieren, doch breite Klinik-Rollouts über viele Marken hinweg sind noch selten. Swisslog betreibt nach eigenen Angaben über 700 AGV in mehr als 50 Kliniken weltweit — überwiegend im eigenen System. Der Sprung zur echten Multi-Brand-Flotte ist noch der offene Teil.

Reifegrad und ehrliche Grenzen

Integration ist nie „fertig“, sondern immer an den konkreten Standort gebunden. Ein Roboter, der in Klinik A reibungslos fährt, kann in Klinik B an einer einzigen Tür hängenbleiben. Der Grund liegt in unterschiedlicher Gebäudetechnik, anderer IT und baulicher Enge. Ein Referenzprojekt sagt darum wenig über das nächste Haus aus.

Auch das Wort „autonom“ hat seine Grenzen. Roboter fahren autonom durch die Flure, doch die Anbindung an Aufzug und IT ist konfiguriert, nicht selbst erlernt. Fällt das WLAN aus oder ändert sich eine Türsteuerung, steht der Ablauf. Autonomie im Alltag hängt an einer stabilen, gepflegten Umgebung.

Und selbst der Standard schafft nicht automatisch reibungslose Praxis, wenn ihn jeder Hersteller ein wenig anders umsetzt. Kompatibel auf dem Papier heißt eben nicht kompatibel im Betrieb. Genau diese Lücke zwischen Norm und Umsetzung ist der eigentliche Test für den Reifegrad.

Deutschland: Beispiele und Verfügbarkeit

In Deutschland ist der Treiber stark und der Bedarf belegt. Laut Statistischem Bundesamt fehlen bis 2049 je nach Szenario zwischen 280.000 und 690.000 Pflegekräfte (PRIMÄR, 24. Januar 2024). Dieser Druck macht jede Entlastung durch Transportrobotik attraktiv. Roboter sollen die Wege übernehmen, damit das Personal beim Patienten bleibt. Welche Einweisungspflichten für das Personal an solchen Systemen gelten, behandelt der Beitrag zu Einweisung und Qualifikation nach MPBetreibV.

Bei Middleware und Standards ist Europa stark aufgestellt. VDA5050 stammt aus Deutschland, Meili aus Dänemark, die United Robotics Group sitzt in Bochum. Bei der reifen Klinik-Logistik geben dagegen US-Anbieter wie Diligent, Aethon und Relay den Ton an. Diese Arbeitsteilung prägt den europäischen Markt.

Die Verfügbarkeit muss man getrennt betrachten. Türen- und Aufzug-Nutzung ist real, hängt aber am Standort und an der Infrastruktur. Herstellerübergreifende Orchestrierung ist noch früh und teils nur angekündigt. Zu Preisen sagen wir hier nichts, weil belastbare, aktuelle Zahlen mit Quelle fehlen. Wer die Gattung darunter verstehen will, findet den Rahmen im Überblick zur Robotik im Gesundheitswesen.

Recht: Cyberresilienz, DSGVO, CE

Sobald Roboter mit Gebäude- und Klinik-IT vernetzt sind, wird IT-Sicherheit zur Rechtsfrage. Der Cyber Resilience Act (Verordnung EU 2024/2847) stellt Anforderungen an vernetzte Produkte mit digitalen Elementen. Eine Roboterflotte, die an Aufzüge und KIS andockt, fällt genau in dieses Feld. Sicherheitsupdates und Schwachstellen-Management sind damit keine Kür.

Dazu kommt der Datenschutz. Transportiert oder verarbeitet ein Roboter Bezüge zu Gesundheitsdaten, greift die DSGVO mit ihrem besonderen Schutz nach Art. 9. Bei riskanten Datenverarbeitungen kann eine Datenschutz-Folgenabschätzung nach Art. 35 nötig werden. Die Datenflüsse zwischen Roboter, Leitstand und Klinik-IT müssen deshalb sauber geregelt sein.

Hinzu kommen Produkt- und KI-Regeln. Die Roboter selbst brauchen je Funktion eine CE-Kennzeichnung; die EU-Maschinenverordnung 2023/1230 gilt ab dem 20. Januar 2027. Steuert KI das Verhalten, wird zusätzlich der EU AI Act relevant. CE ist dabei eine Herstellererklärung, kein Gütesiegel — und dieser Abschnitt ist Einordnung, keine Rechtsberatung.

Worauf Kliniken bei der Integration achten

Die wichtigste Frage lautet nicht „welcher Roboter“, sondern „welche Anbindung“. Kliniken sollten zuerst prüfen, ob Türen und Aufzüge offene Schnittstellen mitbringen. Erst danach lohnt der Blick auf das Robotermodell. Ein starker Roboter an einer geschlossenen Infrastruktur bleibt ein teurer Solist.

Genauso zählt, ob die Flotte zukunftsfähig bleibt. Unterstützt eine Plattform den Standard VDA5050, sind spätere Marken-Erweiterungen möglich. Setzt ein Anbieter nur auf sein geschlossenes System, droht ein Lock-in. Wer Mixed-Brand-Betrieb plant, sollte die Orchestrierung von Anfang an mitdenken.

Und schließlich die IT-Sicherheit über den gesamten Lebenszyklus. Verantwortliche sollten nach Update-Politik, Rechte-Konzept und Datenflüssen fragen. Das verbindet Betrieb und Recht — vom Cyber Resilience Act bis zur DSGVO. Wie KI-Systeme in diesem Umfeld einzuordnen sind, vertiefen wir bei KI im Krankenhaus.

Einordnung

Klinikrobotik entscheidet sich unter dem Datenblatt. Die realen Hürden sind Türen, Aufzüge und die Klinik-IT, nicht die Motorleistung des Roboters. Wer Projekte bewertet, sollte die drei Integrations-Ebenen einzeln durchgehen. Denn ein Roboter ist nur so gut wie seine schwächste Anbindung.

Am meisten hängt am Ende an der Orchestrierung. Herstellerübergreifende Koordination ist über VDA5050 und Plattformen wie Meili seit Jahren teils gelöst, also kein Neuland. Neue Betriebsschichten wie ein Elvio OS müssen sich daran messen und sind teils nur angekündigt statt belegt. Unterm Strich entscheidet die Integration stärker über den Erfolg als der einzelne Roboter — und wer die Transportschicht darüber verstehen will, findet sie in unserem Überblick zur Krankenhauslogistik mit AMR.