Outcomes Articles

When a Hospital Delivery Robot Stops, Who Owns the Problem?

October 26, 2026

About This Report

Featuring insights from Sultan Mehrabi and Craig Anderson, Chris Kennedy, and Stan Schneider hosted by our CEO, Saul Marquez.

Who gets the call if a hospital robot can't finish delivering a lab sample? This is a planning question, not a reported failure. For the care team waiting on the service, the practical concern is what happens next. The cause could sit with the robot, a building interface, software or an operating process, but the nurse shouldn't have to identify the faulty component before someone takes responsibility.

In an Outcomes Rocket conversation with Saul Marquez, Sultan Mehrabi of Relay Robotics and Craig Anderson of BayCare described how their approach evolved from experimenting with robots pressing elevator buttons to integrating directly with hospital elevators and doors. The interview describes that integration as a way to improve the customer experience and reliability, while illustrating how much of a delivery depends on systems beyond the robot itself.

Before expanding a deployment, follow one possible exception across those boundaries. The hospital-and-vendor account provides the operating context. Separate interviews on specialist software and connected systems help test whether an assigned owner has the capabilities and information to act. Start by naming who owns the service problem, then establish how that person gets it resolved.

Give the Exception an Operating Owner

For Sultan Mehrabi, CEO of Relay Robotics, and Craig Anderson, Vice President of Innovation at BayCare, hospital delivery automation starts with work that care teams need completed reliably. In their joint Outcomes Rocket interview, they described robots transporting lab samples from intensive care floors to the laboratory and medications from the pharmacy to nursing units. Some hospital areas lack pneumatic tube systems, and certain materials cannot travel through them. Without another delivery option, nurses or pharmacy technicians must make those trips themselves.

The robots, including Beaker and Hygieia, navigate hospital hallways and use elevators through direct integration with building infrastructure. That makes the service useful, but it also introduces responsibilities beyond the machine. A delivery depends on the robot operating correctly, the building accommodating its movement and the hospital team knowing what to expect.

The joint conversation makes frontline participation part of the design: understand the work teams do now, what they want solved and what they would accept. It also connects reliability to hardware, software and support. Relay's reported responsiveness is part of that account, not an independently verified service guarantee. A buyer still needs to establish the support commitment for its own deployment.

For an innovation team, those details suggest a practical ownership question. Suppose a delivery cannot be completed. Who receives the exception, and who remains responsible while the cause is investigated? A nurse should know where to report the issue and how to obtain an appropriate status update. The designated service owner should know whether building operations, technical support or another responsible party needs to participate.

That doesn't mean one person must repair every component. It means someone coordinates the investigation, keeps affected teams informed and follows through until the issue reaches an appropriate resolution. Existing hospital contingency procedures still govern how time-sensitive materials are handled when normal delivery is unavailable.

Naming the owner answers where the exception goes. The next question is whether that owner can reach the people qualified to investigate it and make a change.

Make the Software Responsibility More Than a Handoff

An escalation contact can acknowledge a problem without being able to fix it. If the relevant software knowledge or access sits somewhere else, the operating owner needs a working connection to that capability before the exception occurs.

Chris Kennedy, Vice President of Partnerships at Prolucid Technologies, described this challenge in a separate Outcomes Rocket interview. Prolucid develops software for medical technology companies, including software running on devices, connected applications and cloud systems. The interview describes work that extends beyond writing code. Product teams must also address design controls, quality systems, cybersecurity and the regulatory requirements relevant to their products.

His conversation highlights how substantial the continuing responsibility for specialist software capability can be. Companies can build those teams internally or obtain expertise from a development partner. For an operating service, either sourcing approach still leaves the team with practical questions about maintenance, interface knowledge and who can investigate problems after initial development.

Apply that distinction to a hospital delivery service. If an incomplete delivery appears to involve a software interface, who has the knowledge and access to investigate? Can the hospital's support team identify the responsible technical partner? If a correction requires coordination between organizations, who manages that work and confirms that the issue has been addressed?

These are service-design questions drawn from Chris's development perspective, not evidence that Prolucid develops Relay's robots or supports BayCare. His interview doesn't establish that outsourcing is faster, cheaper or preferable for every organization.

The practical decision is to identify which capabilities the operating team retains, which it obtains from partners and who remains accountable when responsibilities overlap. A support contact alone cannot resolve an issue without the appropriate technical capability behind it.

Even qualified specialists need to know what the system was waiting for. That shifts the review from who can help to which exchanges they must be able to inspect.

Trace the Dependencies the Owner Must Investigate

Even with an operating owner and qualified software support, an investigation can stall if nobody knows which systems exchanged information, what each component needed or whether that information arrived when required.

Stan Schneider, CEO of Real-Time Innovations (RTI), brings a useful systems perspective from a separate Outcomes Rocket conversation. RTI connects intelligent algorithms with sensors and actuators across complex applications, including surgical robotics, imaging and patient monitoring. Stan explicitly distinguished that medical work from delivery robotics. His experience provides an analogy for investigating hospital delivery dependencies, not evidence that RTI supplies technology to Relay Robotics or BayCare.

Stan described the challenge of getting the right information to the right place at the right time. In connected systems, knowing which components communicate is only part of the problem. The information must also be usable and arrive when the application needs it.

That distinction becomes important when moving from prototype demonstrations into production. Stan emphasized how much additional work reliable operation requires beyond making a prototype function. A successful demonstration may show that components work together under familiar conditions without establishing everything an operating team will need to investigate an exception.

For a hospital delivery service, the practical question is which dependencies exist in its actual implementation. Technical leads should identify the relevant building interfaces, robotic components and information exchanges, then determine what evidence would help investigate an interrupted delivery. The responsible teams must establish appropriate timing requirements rather than borrowing assumptions from another system.

The service owner doesn't need to personally interpret every technical record. That owner does need to know who can obtain the necessary information, who can evaluate it and how the findings reach the people responsible for resolution.

The exception plan becomes credible when responsibility and the ability to investigate sit together.

Review One Exception Before Calling the Service Complete

Before expanding a hospital delivery service, bring together the hospital operations owner, a frontline representative, the building or IT owner and the responsible vendor support lead. Include additional technical partners only if they're involved in the actual deployment.

Choose one delivery route and a hypothetical interruption. Make the exception-ownership map answer four questions:

Receipt: Who accepts the issue and coordinates the response?
Investigation: Who examines robot, software and building dependencies, and what information do they need?
Communication: Who updates frontline staff while the issue remains unresolved?
Resolution: Who confirms the outcome and owns any required technical or process change?

Check the map against the hospital's applicable, validated contingency procedures. This ownership review should clarify service responsibilities without replacing those procedures or authorizing new clinical responses.

If the review reveals missing information, unavailable capabilities or unassigned responsibilities, identify an owner and corrective action before expanding the service.

Return to the waiting care team. They need an accepted exception, an appropriate update and a response governed by the hospital's established procedures. Naming the accountable person is useful only if the supporting teams can act on the issue that person brings them.

A reliable service needs more than a normal route. It needs someone responsible when the route is not normal.

About the Conversations

These are three separate Outcomes Rocket conversations, not a shared case study. During the time of recording, the guest names and titles were as follows: Sultan Mehrabi, CEO of Relay Robotics. Craig Anderson, Vice President of Innovation at BayCare. Chris Kennedy, Vice President of Partnerships at Prolucid Technologies. Stan Schneider, CEO of Real-Time Innovations.