Transportroboter im Krankenhaus: wie autonome Intralogistik Pflegekräfte entlastet

Deutsche Krankenhäuser sind große Logistikbetriebe, in denen zusätzlich behandelt wird. Destatis weist für das Berichtsjahr 2024 1.841 Krankenhäuser mit 472.900 aufgestellten Betten und rund 17,5 Mio. stationäre Behandlungsfälle aus, bei einer Bettenauslastung von 72,0 % und einer durchschnittlichen Verweildauer von 7,1 Tagen. Jeder dieser Fälle erzeugt Essen, Wäsche, Sterilgut, Medikamente, Proben und Abfall, und all das muss physisch durch das Gebäude bewegt werden.

Auf Station übernimmt diese Bewegung in der Regel das Pflegepersonal, weil der Transport kurz, ungeplant und für keinen Hol- und Bringdienst eingeplant ist. Wie viele Stunden das je Haus kostet, ist nicht belastbar veröffentlicht, und es gibt auch keine belastbare Zahl dazu, wie viel Pflegezeit eine autonome Flotte zurückgibt. Anbietermaterial, das einen festen Prozentsatz eingesparter Pflegezeit oder eine durch Roboter ersetzte Mitarbeiterzahl nennt, ist Marketing, kein Nachweis. Präzise beschreibbar ist dagegen der Warenstrom selbst, und genau dort beginnt ein Projekt. Die wiederkehrenden internen Versorgungsketten sind:

• Zentralküche: Speisenwagen auf die Stationen, Schmutzgeschirr zurück, nach festem Zeitplan.
• Apotheke: Arzneimittel und Infusionslösungen auf die Pflegeeinheiten, teils mit Zugriffsschutz und Nachverfolgbarkeit.
• ZSVA: Sterilgutcontainer in den OP und benutztes Instrumentarium zurück, auf getrennten Rein- und Unreinwegen.
• Labor: zeitkritische Blut- und Gewebeproben von der Station ins Zentrallabor.
• Abfall und Wäsche: schwere Rollcontainer auf Entsorgungswegen, die Reinwege nicht kreuzen dürfen.

Jeder dieser Ströme hat eine eigene Gewichtsklasse, ein eigenes Zeitregime, eigene Hygieneanforderungen und einen eigenen Zugriffsschutz. Sie als einen generischen Transportauftrag zu behandeln, ist der häufigste Planungsfehler. Eine strukturierte Übersicht, was Bodenroboter in der Klinik abdecken und was nicht, finden Sie in unserem Überblick zur Servicerobotik im Gesundheitswesen.

Autonome mobile Roboter ersetzen keinen Prozess, sie führen einen aus. Der Prozess muss also zuerst beschreibbar vorliegen: Quelle, Ziel, Zeitfenster, Ladung, Behältertyp, Berechtigung zum Öffnen und definiertes Verhalten, wenn das Ziel blockiert ist. Diese Kartierung ist unspektakuläre Arbeit und entscheidet mehr über das Ergebnis als die Wahl des Fahrzeugs.

Die relevanten Parameter unterscheiden sich je Strom deutlich:

• Ladung und Behälter: Ein Speisenwagen oder ein Wäscherollcontainer bringt mehrere hundert Kilogramm hinter eine Zug- oder Hubeinheit, während ein Kurierlauf für Proben und Medikamente wenige Dutzend Kilogramm in geschlossenen Schubladen bewegt.
• Zeitregime: Küche und ZSVA fahren getaktet, Labor und Apotheke auf Abruf. Eine Flotte muss beides bedienen, ohne dass der getaktete Verkehr den Abrufverkehr verdrängt.
• Zugriffsschutz: Medikamente und Proben brauchen ein Fach, das sich nur für Berechtigte öffnet. Verschließbare, einzeln adressierbare Schubladen sind ein Hardwaremerkmal und müssen vorab spezifiziert werden, nicht nachgerüstet.
• Hygiene und Wegeführung: Rein- und Unreinwege bleiben getrennt, Oberflächen müssen die im Haus tatsächlich eingesetzten Flächendesinfektionsmittel vertragen, und der Roboter muss im selben Zyklus aufbereitbar sein wie der Behälter, den er fährt.
• Rückfallebene: Was passiert bei ausgefallenem Aufzug, belegtem Flur oder Netzabriss. Jeder Strom braucht eine definierte manuelle Rückfallebene, sonst verliert die Station nach dem ersten Vorfall das Vertrauen in das System.

Zeitkritischer Probentransport zwischen Standorten ist eine eigene Frage, denn Bodentransport im Gebäude und Transport zwischen Standorten folgen völlig unterschiedlichen Randbedingungen. Zum zweiten Fall siehe medizinische Drohnenlogistik. Zur allgemeinen Frage, was Bodenroboter heute im Klinikflur tatsächlich leisten, siehe Serviceroboter im Krankenhaus.

Der Markt für Transportroboter im Krankenhaus ist kleiner und konservativer, als die Berichterstattung nahelegt. Eine kurze Liste tatsächlich beschaffbarer Plattformen mit den Daten, die die Hersteller selbst veröffentlichen:

Daraus folgen zwei praktische Konsequenzen. Erstens trennt die Traglastklasse den Markt sauber: schwerer Wagenverkehr und leichter Kurierverkehr sind unterschiedliche Maschinen, ein Mischbetrieb ist eine Mischflotte. Zweitens kursieren in Ausschreibungsunterlagen und Beraterfolien weiterhin Produkte, die im Programm des Herstellers gar nicht mehr geführt werden. Verfügbarkeit, Ersatzteilversorgung und regionale Servicedichte gehören deshalb in das Lastenheft und nicht in die Kategorie der Überraschungen nach Zuschlag. Eine aktuelle Übersicht verfügbarer Plattformen pflegen wir im Roboterkatalog.

Klinikgebäude sind funktechnisch unfreundlich. Stahlbeton, bleiabgeschirmte Radiologien, schwere Brandschutztüren und metallverkleidete Technikräume dämpfen das Signal, und das Klinik-WLAN ist üblicherweise für medizinische Geräte und Personalnotebooks ausgelegt, nicht für einen dauerhaft fahrenden Client, der die Verbindung zur Flottensteuerung nicht mitten im Flur verlieren darf. Ein Roboter, der aus dem Netz fällt, bleibt in der Regel stehen, und das ist im Klinikflur genau das falsche Verhalten.

Roaming, Funklöcher und Priorisierung

Der dominierende Fehlerfall ist nicht schwache Abdeckung, sondern langsames Roaming. Ein Fahrzeug mit einem Meter pro Sekunde wechselt permanent die Funkzelle, und ein zu langsamer Handover wirkt funktional wie ein Netzausfall. Die Arbeit, die vor dem ersten Roboter erledigt sein muss, ist unspektakulär und weitgehend infrastrukturell:

• Ausleuchtung und Heatmap: Messung entlang der tatsächlichen Fahrwege auf Antennenhöhe des Fahrzeugs, nicht auf Schreibtischhöhe, einschließlich Aufzugsschächten, Rampen und Türschwellen.
• Roaming-Tuning: Signalschwellen auf den Roboter-Clients so setzen, dass der Handover ausgelöst wird, bevor die Verbindung abbaut, und das Verhalten unter Last verifizieren.
• Lokale Pufferung: Das Fahrzeug muss unkritische Befehle lokal halten und ein bekanntes Funkloch auf dem letzten gültigen Plan durchfahren, statt anzuhalten.
• Eigene SSID und Priorisierung: Robotikverkehr vom allgemeinen Kliniknetz trennen, damit administrative Last keine Latenz in der Flottensteuerung erzeugt.
• Definiertes Stoppverhalten: festlegen, was das Fahrzeug bei Verbindungsverlust tut, am Flurrand parken statt mitten im Flur, und wie es sich wieder anmeldet.

Nichts davon ist exotische Technik, aber es ist standardmäßig niemandes Zuständigkeit. In der Praxis liegt es zwischen Klinik-IT, Roboterlieferant und Technischem Dienst, und genau deshalb fällt es meist spät auf.

Ein Krankenhaus ist in Brandabschnitte unterteilt, und die Türen dazwischen sind sicherheitstechnische Einrichtungen nach Baurecht. Wo solche Türen im Regelbetrieb offen stehen, geschieht das über eine Feststellanlage, die von der Brandmeldeanlage ausgelöst wird. Diese Hierarchie ist nicht verhandelbar: Im Alarmfall schließt die Brandmeldeanlage die Türen, und jede darüberliegende Automatisierung hat das ausnahmslos zu akzeptieren.

Der ehrliche Marktstand dazu lautet: Kein Hersteller von Transportrobotern für Kliniken dokumentiert öffentlich eine Schnittstelle zur Ansteuerung von Brandschutztüren. Es gibt kein Datenblatt, kein veröffentlichtes Protokoll, keine zertifizierte Standardlösung. Was in realen Gebäuden existiert, sind projektspezifische Kopplungen, typisch ein Kontakt oder eine Steuerungsschnittstelle des Tür- oder Feststellanlagenlieferanten, je Gebäude geplant und gemeinsam mit dem Brandschutzbeauftragten und der zuständigen Prüfstelle abgenommen. Damit ist die Türdurchfahrt in jedem einzelnen Projekt ein Integrationsposten mit eigenen Kosten, eigener Vorlaufzeit und eigener Abnahme.

Was geklärt sein muss, bevor eine Flotte Brandabschnittsgrenzen autonom überquert:

• Rechtlicher Weg: Abstimmung mit dem Brandschutzbeauftragten und, wo erforderlich, der Genehmigungsbehörde, ob und wie die Tür überhaupt technisch angesteuert werden darf.
• Schnittstelle: welchen physischen oder logischen Kontakt die Türsteuerung anbietet, wer ihn liefert und wer ihn nach Übergabe wartet.
• Vorrang: unbedingter Vorrang der Brandmeldeanlage, mit definiertem Roboterverhalten im Alarmfall, Halt außerhalb des Türblatts und niemals im Schließbereich.
• Sensorik: Die Tür muss das Fahrzeug eigenständig als Hindernis erkennen, und das Fahrzeug muss die Schwelle vollständig geräumt haben, bevor der Schließvorgang startet.
• Abnahme und Dokumentation: Die Kopplung wird Teil der Brandschutzdokumentation des Gebäudes und ist mit der wiederkehrenden Prüfung der Feststellanlage erneut zu prüfen.

Handelt es sich um gewöhnliche Automatiktüren ohne Brandschutzfunktion, ist das Problem deutlich kleiner und wird meist über eine Funk- oder Kontaktanforderung gelöst. Es lohnt sich, beide Fälle früh zu trennen, denn im Lastenheft werden sie oft zusammengeworfen und gemeinsam bepreist.

Die vertikale Anbindung macht aus einem Pilotbetrieb auf einer Ebene erst einen hausweiten Betrieb, und an ihr scheitern die meisten Projekte. Das Fahrzeug muss eine Kabine rufen, wissen, welche Kabine kommt, die Tür lang genug halten, um ein- und auszufahren, dem Steuergerät sein Zielgeschoss übergeben und zurücktreten, wenn der Aufzug für einen Patiententransport oder einen Notruf gebraucht wird.

Was Hersteller tatsächlich veröffentlichen

Kein Hersteller von Transportrobotern für Kliniken nennt öffentlich ein konkretes Aufzugsprotokoll oder einen Aufzugshersteller als Integrationspartner. In den Datenblättern der oben genannten Plattformen findet sich keine veröffentlichte Schnittstelle zu KONE, Schindler, Otis oder thyssenkrupp. Die sichtbaren Ausnahmen sind eng: Relay Robotics nennt Aufzugsmarken, mit denen gearbeitet wurde, und Pudu führt für den CC1 Pro eine Elevator Control als Option. Beides ist kein dokumentiertes, übertragbares Protokoll. In der Aufzugsbranche selbst existiert mit CANopen Lift (CiA 417) ein herstellerübergreifendes Anwendungsprofil, aber kein Hersteller von Klinik-Transportrobotern veröffentlicht dazu eine Konformität als Produktmerkmal.

Die praktische Konsequenz ist dieselbe wie bei Brandschutztüren: Die Aufzugskopplung wird je Gebäude geplant, gemeinsam mit der Aufzugswartungsfirma, und sie gehört als eigene Position in das Projektbudget, statt als enthalten unterstellt zu werden. Zu klären ist:

• Schnittstelle und Verantwortung: welche Schnittstelle das Aufzugssteuergerät anbieten kann, ob der Wartungsvertrag eine Fremdkopplung zulässt und wer nach dem Eingriff haftet.
• Prioritätsregeln: Patiententransport und Notruf haben Vorrang vor Roboterrufen. Die Flotte muss eine bereits angeforderte Kabine wieder freigeben und in einer definierten Position warten können.
• Türzeiten: Haltezeiten sowie das Zusammenspiel von Kabinentür, Schachttür und der eigenen Sicherheitssensorik des Fahrzeugs, damit Ein- und Ausfahrt zuverlässig statt zufällig gelingen.
• Funkabdeckung im Schacht: Ein Fahrzeug, das in der Kabine die Verbindung verliert, ist ein blockierter Aufzug. Abdeckung in Schacht und Kabine muss gemessen und darf nicht angenommen werden.
• Rückfallebene: definiertes Verhalten der Flotte bei außer Betrieb genommener Kabine, einschließlich Umleitung oder geregelter Rückgabe des Auftrags an das Personal.

An dieser Stelle wird der Unterschied zwischen dem Kauf eines Roboters und dem Betrieb einer Flotte sichtbar, und hier liegt die Rolle des Integrators: Die Hardware ist vergleichsweise standardisiert, das Gebäude ist es nicht.

Ein Roboter ist ein Pilot. Eine Flotte ist ein Betrieb, und sie erzeugt Probleme, die es mit einem Einzelfahrzeug nicht gibt: Begegnungen im schmalen Flur, konkurrierende Aufzugsrufe, Warteschlangen an derselben Ladestation oder die geschlossene Rückkehr aller Fahrzeuge zum Schichtwechsel.

• Flächenplanung: Dock- und Ladestationen gehören in verkehrsarme Nebenflächen, niemals in Rettungswege, und die erforderliche lichte Flurbreite muss auch mit abgestelltem Fahrzeug eingehalten sein. Das ist mit dem Brandschutz und mit der Station abzustimmen.
• Vorfahrtregeln: definierte Regeln an Kreuzungen und Türschwellen, mit generellem Vorrang für Personal, Betten und Patiententransporte gegenüber Transportaufträgen, und mit einer Prioritätsstufe für zeitkritische Ladung wie Laborproben.
• Ladestrategie: Zwischenladen in geplanten Schwachlastfenstern, damit die Flotte in Spitzenzeiten keine Kapazität verliert. Die veröffentlichten Akkudaten der genannten Plattformen, etwa rund neun Stunden Betrieb und gut drei Stunden Ladezeit bei den Aethon-Fahrzeugen, bestimmen, wie viele Fahrzeuge für einen durchgehenden Betrieb nötig sind.
• Überwachung: eine einheitliche Sicht auf Flottenzustand, offene Aufträge und Blockaden, damit ein hängendes Fahrzeug auffällt, bevor die Station anruft.
• Manuelle Rückfallebene: ein dokumentiertes Verfahren, mit dem das Personal ein Fahrzeug bewegen, entladen oder abstellen kann, ohne auf den Support zu warten.

Über die Flottengröße entscheidet sich die Wirtschaftlichkeit, und sie hängt von Wegelängen, Aufzugsverfügbarkeit und Ladefenstern im konkreten Gebäude ab, nicht von einer allgemeinen Kennzahl. Unser Einsatzrechner ist genau für diese gebäudespezifische Abschätzung gedacht und nicht für Vergleichswerte aus anderen Häusern.

Die regulatorische Lage ist für Transportroboter klarer als für die meiste andere Servicerobotik, sofern der richtige Rahmen angewendet wird.

• ISO 3691-4 ist die einschlägige harmonisierte Norm für fahrerlose Flurförderzeuge und Transportroboter. Die aktualisierte Fassung stammt von März 2024 und ist seit Mai 2024 im EU-Amtsblatt harmonisiert gelistet. In der Praxis veröffentlicht kaum ein Hersteller dazu eine Konformitätserklärung. Sie einzufordern gehört in jede Ausschreibung.
• ISO 13482 betrifft persönliche Assistenzroboter und ist nicht die anwendbare Norm für ein Transportfahrzeug im Klinikflur. In Anbieterunterlagen wird sie regelmäßig falsch zitiert.
• Verordnung (EU) 2023/1230, die neue Maschinenverordnung, gilt ab dem 20. Januar 2027. Ein Roboter, der Essen, Wäsche, Abfall oder verschlossene Proben transportiert, ist danach eine Maschine.
• Verordnung (EU) 2017/745 (MDR) greift erst, wenn der Hersteller eine medizinische Zweckbestimmung vergibt, etwa das Dosieren oder Verabreichen eines Arzneimittels. Der reine Transport verschlossener Behälter erzeugt kein Medizinprodukt. Diese Abgrenzung bestimmt den gesamten Konformitätsweg und sollte vor der Beschaffung schriftlich geklärt sein.

Zwei weitere Punkte sind zu nennen, weil sie häufig falsch dargestellt werden. Transport-, Reinigungs- und Desinfektionsrobotik ist nicht nach dem Krankenhauszukunftsgesetz förderfähig; § 19 KHSFV kennt dafür keinen Fördertatbestand. Und die kamerabasierte Kartierung klinischer Bereiche wirft eine datenschutzrechtliche Frage auf, die vor Inbetriebnahme zu bewerten ist und nicht danach.

Die Hardware ist die kleinere Hälfte eines Klinik-Transportprojekts. Die größere Hälfte ist das Gebäude: Aufzüge, Türen, Netz, Hygieneregime, Brandschutzdokumentation und die Softwaresysteme, die den Transportauftrag überhaupt erst erzeugen. Ein Paket aus einer Hand optimiert typischerweise die erste Hälfte und überlässt die zweite dem Betreiber.

werob ist ein herstellerunabhängiger Systemintegrator für Servicerobotik und eine Marke der CITO GmbH in Hamburg. Das bedeutet: keine eigene Hardware, keine Exklusivität mit einem Hersteller und kein Interesse daran, dass ein bestimmter Roboter einen Vergleich gewinnt. Die Arbeit besteht darin, die Warenströme zu spezifizieren, verfügbare Plattformen dagegen zu prüfen und die Gebäudeintegration zu planen, in der, wie oben gezeigt, Aufwand und Risiko stecken. Die hier genannten Hersteller sind Marktbeispiele, keine Partner.