Hospital transport robots: how autonomous intralogistics relieves clinical staff

German hospitals are large logistics operations that happen to treat patients. Destatis counted 1,841 hospitals with 472,900 available beds and around 17.5 million inpatient cases for the 2024 reporting year, at an average occupancy of 72.0 percent and an average length of stay of 7.1 days. Every one of those cases triggers meals, linen, sterile goods, medication, samples and waste, and all of it has to be physically moved through the building.

On most wards this movement is absorbed by clinical staff, because the transport is short, unplanned and nobody has budgeted a porter for it. There is no reliable published figure for how many hours that costs per house, and there is no credible published figure for the share of nursing time an autonomous fleet gives back. Vendor material that quotes a fixed percentage of nursing time saved, or a headcount that a robot fleet has replaced, is marketing, not evidence. What can be described precisely is the goods flow itself, and that is where a project has to start. The recurring internal supply chains are:

• Central kitchen: meal trolleys out to the wards, soiled trays back, on a fixed timetable.
• Pharmacy: medication and infusion solutions to the care units, partly requiring access control and traceability.
• Central sterile services (CSSD): sterile containers to the operating theatres and used instruments back, on separated clean and dirty routes.
• Laboratory: time-critical blood and tissue samples from the ward to the central lab.
• Waste and linen: heavy roll containers on disposal routes that must not cross clean routes.

Each of these flows has its own weight class, timing, hygiene regime and access requirement. Treating them as one generic "transport" task is the most common planning error. A structured view of what ground robots do and do not cover in clinical settings is in our overview of service robotics for healthcare.

Autonomous mobile robots do not replace a process, they execute one. That means the process has to exist in a describable form first: origin, destination, time window, payload, container type, who is allowed to open it, and what happens when the destination is blocked. Mapping this is unglamorous work, and it decides more about the outcome of a deployment than the choice of chassis.

The relevant parameters differ sharply between flows:

• Payload and container: a meal trolley or a laundry roll container puts several hundred kilograms behind a tow or lift unit, while a courier run for samples and medication moves a few dozen kilograms in closed drawers.
• Timing: kitchen and CSSD runs are scheduled, lab and pharmacy runs are on demand. A fleet has to serve both without the scheduled traffic starving the on-demand traffic.
• Access control: medication and samples require a compartment that only opens for an authorised person. Locked, individually addressable drawers are a hardware feature and have to be specified up front, not retrofitted.
• Hygiene and routing: clean and dirty routes have to stay separated, surfaces have to tolerate the disinfectants actually used in the house, and the robot has to be cleanable in the same cycle as the container it carries.
• Fallback: what happens when a lift is out of service, a corridor is occupied by a bed, or the network drops. Every flow needs a defined manual fallback, otherwise the ward loses trust in the system after the first incident.

Time-critical sample transport between sites is a separate question again, because ground transport inside a building and inter-site transport follow completely different constraints. For the inter-site case, see medical drone logistics. For the general question of what ground robots actually perform in clinical corridors today, see service robots in hospitals.

The transport robot market for hospitals is smaller and more conservative than the press coverage suggests. A short list of platforms that are genuinely purchasable, with the data their manufacturers publish:

Two practical consequences follow. First, payload class separates the market cleanly: heavy trolley traffic and light courier traffic are different machines, and a mixed operation is a mixed fleet. Second, several products that still circulate in tender documents and consultant slide decks are no longer in their manufacturer's programme. Availability, spare parts supply and regional service coverage belong in the requirement specification, not in the post-award surprise category. A current overview of platforms is maintained in our robot catalogue.

Hospital buildings are hostile to radio. Reinforced concrete, lead-shielded radiology suites, heavy fire doors and metal-clad technical rooms attenuate signals, and hospital WLAN is usually dimensioned for clinical devices and staff laptops, not for a continuously moving client that must not lose its fleet connection mid-corridor. A robot that drops off the network typically stops where it is, which in a hospital corridor is exactly the wrong behaviour.

Roaming, dead zones and priority

The dominant failure mode is not weak coverage but slow handover. A robot travelling at one metre per second crosses cell boundaries constantly, and a handover that takes too long is functionally identical to a network outage. The work that has to happen before the first robot arrives is unspectacular and largely infrastructural:

• Site survey and heat mapping: measure the actual routes at robot antenna height, not at desk height, including lift shafts, ramps and door thresholds.
• Roaming tuning: set signal thresholds on the robot clients so the handover is triggered before the connection degrades, and verify the behaviour under load.
• Local buffering: the robot has to hold non-critical commands locally and continue on its last valid plan through a known dead zone instead of halting.
• Separate SSID and prioritisation: isolate robot traffic from the general hospital network so administrative load does not create latency in fleet control.
• Defined stop behaviour: agree what the robot does on connection loss, park at the edge of the corridor rather than in it, and how it re-registers.

None of this is exotic engineering, but it is nobody's job by default. In practice it sits between the hospital IT department, the robot supplier and the building services team, which is precisely why it tends to be discovered late.

A hospital is divided into fire compartments, and the doors between them are safety equipment governed by building law. Where such doors are held open in normal operation, that is done by a hold-open system (Feststellanlage) which is released by the fire alarm system. This hierarchy is not negotiable: in an alarm, the fire alarm system closes the doors, and any automation on top of it has to accept that without exception.

Here is the honest state of the market. No manufacturer of hospital transport robots publicly documents an interface for controlling fire doors. There is no datasheet, no published protocol, no certified standard solution. What exists in real buildings are project-specific couplings, typically a contact or a controller interface provided by the door or hold-open system supplier, engineered and accepted per building together with the fire protection officer and the responsible approval body. That makes door crossing an integration item in every single project, with its own cost, its own lead time and its own acceptance.

What has to be settled before a fleet can cross compartment boundaries autonomously:

• Legal path: agreement with the fire protection officer and, where required, the approval authority on whether and how the door may be actuated by a technical system at all.
• Interface: which physical or logical contact the door controller offers, who supplies it, and who maintains it after handover.
• Precedence: unconditional priority of the fire alarm system, with a defined robot behaviour on alarm, stop clear of the door leaf and never in the closing area.
• Sensor coverage: the door has to detect the robot as an obstacle in its own right, and the robot has to clear the threshold before the closing sequence starts.
• Acceptance and documentation: the coupling becomes part of the fire protection documentation of the building and has to be re-tested with the periodic inspection of the hold-open system.

Where doors are ordinary automatic doors without a fire protection function, the problem is much smaller and usually solved with a radio or contact-based opening request. It is worth separating the two cases early, because they are often lumped together in requirement documents and priced as one.

Vertical movement is what turns a floor-level pilot into a hospital-wide deployment, and it is where most projects stall. The robot has to call a car, know which car arrives, hold the door long enough to enter and exit, tell the controller its destination floor, and give way when the lift is needed for a patient transfer or an emergency call.

What manufacturers actually publish

No manufacturer of hospital transport robots publicly names a concrete lift protocol or a lift manufacturer as an integration partner. There is no published KONE, Schindler, Otis or thyssenkrupp interface in the datasheets of the platforms listed above. The visible exceptions are narrow: Relay Robotics names lift brands it has worked with, and Pudu lists "elevator control" as an option for the CC1 Pro. Neither amounts to a documented, portable protocol. In the lift industry itself there is a cross-vendor application profile, CANopen Lift (CiA 417), but no hospital transport robot manufacturer publishes conformity to it as a product feature.

The practical consequence is the same as with fire doors: lift coupling is engineered per building, together with the lift maintenance company, and it belongs in the project budget as its own line item rather than being assumed as included. The points that have to be resolved:

• Interface and ownership: which interface the lift controller can offer, whether the maintenance contract permits third-party coupling, and who is liable after modification.
• Priority rules: patient transport and emergency calls override robot calls. The fleet has to be able to release a car it has already requested and wait in a defined position.
• Door timing: hold times and the interaction between car door, shaft door and the robot's own safety sensors, so entry and exit are reliable rather than probabilistic.
• Network coverage in the shaft: a robot that loses connection inside a car is a blocked lift. Coverage in the shaft and in the car has to be measured, not assumed.
• Fallback: what the fleet does when a car is out of service, including rerouting or a defined handover back to staff.

This is the point where the difference between buying a robot and running a fleet becomes visible, and where an integrator earns its place: the hardware is comparatively standardised, the building is not.

One robot is a pilot. A fleet is an operation, and it introduces problems that do not exist with a single unit: units meeting head-on in a corridor, competing for the same lift, queuing at the same charging station, or all returning to charge during the same shift change.

• Spatial planning: docking and charging stations belong in low-traffic side areas, never in escape routes, and the required clear corridor width has to be maintained with a robot parked. This has to be agreed with fire protection and with the ward.
• Right of way: defined rules at junctions and door thresholds, with staff, beds and patient transports always having priority over transport orders, and with a priority level for time-critical payloads such as lab samples.
• Charging strategy: opportunity charging in scheduled low-demand windows so the fleet does not lose capacity during peak periods. The published battery data of the listed platforms, for example around nine hours of operation and just over three hours of charging on the Aethon units, determines how many units are needed for continuous coverage.
• Monitoring: a single view of fleet state, open orders and blockages, so a stuck unit is noticed before the ward calls.
• Manual fallback: a documented procedure for staff to move, unload or park a robot without waiting for support.

Fleet sizing is where the business case is decided, and it depends on route lengths, lift availability and charging windows in the specific building, not on a generic ratio. Our deployment calculator is intended for that kind of building-specific estimate rather than for benchmark figures from other houses.

The regulatory picture for a transport robot in a clinical corridor is clearer than for most service robotics, provided the right framework is applied.

• ISO 3691-4 is the relevant harmonised standard for driverless industrial trucks and transport robots. The updated version dates from March 2024 and has been listed as harmonised in the Official Journal of the EU since May 2024. In practice, hardly any manufacturer publishes a declaration of conformity against it. Requiring one belongs in every tender document.
• ISO 13482 covers personal care robots and is not the applicable standard for a transport robot in a hospital corridor. It is regularly cited incorrectly in vendor material.
• Regulation (EU) 2023/1230, the new Machinery Regulation, applies from 20 January 2027. A robot that transports food, linen, waste or closed samples is machinery under that regulation.
• Regulation (EU) 2017/745 (MDR) only applies once the manufacturer assigns a medical intended purpose, for example dosing or administering a medicinal product. Pure transport of closed containers does not create a medical device. This distinction determines the entire conformity route and should be settled in writing before procurement.

Two further points are worth naming because they are frequently misstated. Transport, cleaning and disinfection robotics are not eligible under the German Hospital Future Act funding scheme; section 19 of the KHSFV contains no corresponding funding category. And camera-based mapping of clinical areas raises a data protection question that has to be assessed before commissioning, not after.

Hardware is the smaller half of a hospital transport project. The larger half is the building: lifts, doors, network, hygiene regime, fire protection documentation and the software systems that generate the transport orders in the first place. A single-vendor package tends to optimise the first half and leave the second to the customer.

werob is a manufacturer-independent systems integrator for service robotics and a brand of CITO GmbH in Hamburg. That means no own hardware, no exclusivity with a manufacturer, and no interest in a particular robot winning a comparison. The work consists of specifying the goods flows, comparing available platforms against them, and engineering the building integration, which as shown above is where the effort and the risk sit. Manufacturers named here are market examples, not partners.