One Platform for Mixed Hospital Robot Fleets: What to Ask

Why one platform matters once robots come from several brands

A hospital that runs robots from two or more manufacturers ends up with two or more traffic rulebooks. Each vendor ships its own traffic editor, and those editors do not coordinate with one another. A 2019 Open Robotics account of hospital fleets describes the result: robots that jam in elevator lobbies and doorways, stopping to stare at each other until staff shut one of them down. That account is dated, but it names the failure mode precisely.

The pitch for a single platform is that one layer sees every robot, calls the elevator, holds the door and clears the gate, whatever brand is on the chassis. A Nasdaq-hosted Pulse Equity piece says the Gix Internet platform is designed to coordinate robots and human staff, work with robots from different vendors and integrate with a facility's existing elevators, doors, gates and operational systems. Deliverz.ai's US launch release, dated July 27, 2026, says a single integration layer supports any robot from any vendor without constraints. Both are vendor descriptions, not independent tests. We could not match the October 20, 2026 date given for the announcement to a source in our research, so confirm the date against the original release before citing it.

What the platform must reach: elevators, doors and gates

Elevators are the hard part. A healthcare facility guide explains that AMRs talk to elevator control systems through an API or a hardware interface, letting them call a car, hold a door during loading and manage access during high-traffic periods. The same guide notes that many hospital elevators, particularly older installations, need the control panel interface modernized before a robot can use them.

Doors and gates look simpler on paper and get messier in practice, because they usually run through access control. Deliverz.ai lists elevators, doors, gates and access control systems under its facilities integration, which shows what it claims to reach. Ask who holds the credentials, who responds when a door fails to open, and whether the robot waits or reroutes. Corridor geometry matters too. The same guide reports that most AMR vendors require a six-foot minimum clear corridor for two-way robot traffic. That is a vendor-side figure, so measure your own halls against it.

Why integration usually takes longer than the robot install

Integration tends to consume more time than the physical install. The 2019 Open Robotics account put the timeline bluntly: three years to connect and hook up all interfaces for one fleet when a new platform was deployed. That number is old and may not reflect current tooling, but the pattern it describes still shows up in hospital projects.

Elvio Robotics, in a CEO and CTO interview with Medica, argues that many current solutions are isolated systems, barely integrated with elevators, doors or IT. For an elevator roughly 30 years old, its team works with facilities management, the elevator manufacturer and the maker of the control system. The same interview flags weak documentation: existing systems are inadequately documented, or interfaces are missing or described only in limited detail. In many buildings, paperwork is the bottleneck, not wiring.

Which integration questions to put to any platform provider

Put these questions to any platform provider before you compare demos. Vendors who answer in specifics have usually done the integration work at least once.

• Name each elevator control protocol the platform runs today, and the sites where it runs in production.
• Show how a robot from a new manufacturer joins the platform, and whether that requires a fresh integration project. Elvio says new hardware can be added without one, a claim to test on your own equipment.
• Explain who owns the traffic rules when two vendors' robots meet in the same corridor, and who changes them.
• Describe the fallback when the network drops, and what each robot does when a door will not open.
• Put the interface documentation in writing, and confirm who keeps it current after go-live and at contract end.
• Clarify route mapping, dispatch software, maintenance response and spare-parts terms, since these affect uptime more than headline speed claims.

How to test multi-brand support claims before you believe them

Multi-brand claims often arrive as logo walls. Athegus lists hospOS integrations with Keenon, AutoXing, Orionstar, temi, KONE, Schindler, Newlift and Reimann, and says existing doors and elevators connect through adapters instead of rebuilds. It also reports that hospOS has been in real operation in two clinics since 2023. Those are the company's own statements, so treat them as claims until a reference site confirms them.

Four checks turn a logo list into evidence. First, ask for a live reference for each vendor pair you plan to run, not for the platform in general. Second, request an elevator call log from that site showing requests, waits and failures. Third, run a dry test in your own corridors with two vendors' robots approaching the same door. Fourth, compare the platform's partner list with what its sales material says. Any gap between the two is a fair question to ask.

Reading deployment numbers from a vendor announcement

Deployment figures in these announcements mean little without their denominators. The company-reported Sheba Medical Center results say chemotherapy delivery times fell from 40 minutes to 14. The same material says commercial operations began in December 2025 and more than 9,000 autonomous missions were completed as of October 2026. Sheba's public tender permits up to 30 robots, with 3 currently deployed.

Read those numbers in three ways. The 40-to-14-minute drop is company-reported and comes from one site. The 9,000 missions are a count, not a measure of uptime or failure rate. The gap between 30 permitted and 3 deployed shows how far the program sits from its tender ceiling. None of this is independent verification, so ask every vendor for the same denominators: sites, robots in service, missions completed and how each number was counted.

How an OEM-neutral integrator handles the interface work

Service Robot Co. is an OEM-neutral integrator. We select robots across manufacturers for the job in front of us, then deploy, integrate, train and service every unit through a nationwide US engineer network. Elevator, door and gate connections, and the documentation that goes with them, fall inside the same scope as the robot choice, so the team that picks the hardware also answers for how it reaches the building.

Customers lease our robots on a 3-year lease with one fixed payment, quoted after a site assessment. That assessment is where the questions in this article get answered for a specific building: which elevators, which control systems, which corridors and which doors. We are not a platform vendor, and we do not claim one platform fits every fleet. We do tell hospitals which parts of the integration we can own and which need the facilities team in the room.