Hospital Robot Traffic and Elevator Capacity Planning

A hospital robot can navigate successfully and still deliver too late if it spends the mission waiting for an elevator. Elevator access and elevator capacity are different questions: an integration may allow a robot to request a car, while shared traffic and hospital priorities determine when that request can be served.

Plan hospital robot elevator capacity as a shared-resource problem. Define the logistics service, observe competing demand and agree the priority and fallback rules with the hospital and elevator-system owners. This guide concerns logistics planning and does not specify lift-control modifications or emergency operating procedures.

Map complete vertical journeys

For each mission class, record origin floor, destination floor, release pattern, payload, permitted elevator bank, waiting location and service window. Include repositioning and empty returns where they are part of the workflow. A fleet schedule that counts only loaded journeys can understate demand on the shared resource.

Separate robot travel time from elevator waiting, boarding, door cycle, movement, intermediate stops and exit. Observe the full journey rather than treating nominal car speed as the dominant input. Keep the hospital’s clinical, accessibility and emergency priorities outside any assumed robot entitlement.

The hospital AMR integration guide explains the wider interface boundary. Here, the decision is whether the proposed service can use that interface at the required times.

Establish how the selected system uses a car

Ask whether a robot requests an empty car, can share a car under an approved operating design, or uses a dedicated service arrangement. Confirm the actual controller, building configuration and supplier-supported behavior. Do not infer one product’s behavior from another’s demonstration.

Aethon’s T3 documentation describes software and hardware that request elevators and can arrange an empty cabin. This is an attributed example of a manufacturer-specific approach, not a universal hospital AMR capability or a promise about Warpify’s compatibility with a particular building.

Record entry and exit confirmation, timeout, abandoned request, unavailable bank, manual intervention and communications-loss behavior. Identify which organization owns each side of the interface and the evidence needed to resume after an interruption.

Measure contention in the periods that matter

Observe the accepted service windows and the hospital’s relevant peaks. Include staff movement, carts and other traffic permitted in the same bank. Use authorized, privacy-conscious measurement methods and avoid collecting patient identity or unnecessary clinical information.

Retain the distribution of waits, not just an average. Several acceptable short waits can conceal a smaller number of delays that breach a time-sensitive logistics window. Link each observation to its floor pair, direction, time interval and traffic condition.

Record exclusions and unusual events. A quiet weekend survey should not be presented as proof of weekday replenishment capacity. Likewise, a single unusually disrupted period should not silently become the normal planning baseline.

Use a screening budget without mistaking it for a schedule

An illustrative screening calculation might allocate 10 robot journeys in an hour at four minutes of exclusive elevator occupation per journey. That uses 40 car-minutes before allowing for other users, positioning, disruption or any journey-time assumption omitted from the four-minute estimate.

If the assumed occupation rises to five minutes, the same demand uses 50 car-minutes; at six minutes it consumes the full hour. These are arithmetic scenarios, not observed hospital performance or recommended limits. They show why small timing assumptions deserve verification.

Even a calculation below 60 car-minutes does not prove feasibility. Requests may arrive together, start on different floors or conflict with higher-priority use. Replay the actual request pattern and dispatch rules, or use a suitable simulation validated against observed building behavior.

Control queues and waiting locations

Agree where the robot waits without narrowing a doorway, obstructing egress or occupying a clinical work area. Check the configured payload envelope as well as the base. If several requests can accumulate, define the permitted queue and the condition that stops new dispatches into that area.

Consider scheduling routine logistics outside observed conflicts where the hospital accepts that change. Consolidating compatible work or changing a handoff location may reduce lift dependence, but assess payload, custody, cleaning and receiving constraints before changing the process.

Do not solve a capacity problem by adding robots automatically. More units can add requests to the same constrained bank. Compare the effect of scheduling, workflow changes and fleet quantity separately.

Test unavailable and degraded service

Define what happens when the accepted elevator bank is unavailable, an authorized priority overrides logistics, or a robot cannot exit as expected. Agree safe test methods with the responsible building team. Do not interfere with emergency controls or live clinical operations to create a demonstration.

Measure the time until the logistics task is resolved, including manual fallback, rather than ending the test when the robot stops. Keep unfinished requests and payload custody visible to the operating team.

Make elevator evidence part of fleet acceptance

Connect the capacity assessment to the hospital fleet operating model and pilot acceptance criteria. Require representative floor pairs, traffic periods, payloads and exception paths in the test record.

The output should state supported mission classes, service windows, dispatch conditions, exclusions and fallback owners. Bring that record to a hospital logistics assessment before treating elevator integration as completed transport capacity.

The numerical example is an illustrative scenario using editorial assumptions, not measured deployment performance.

Explore Warpify's hospital logistics robotics to connect these requirements with workflow assessment and deployment planning.

Sources and scope

• Aethon T3: Hospital transport platform — Vendor-specific transport and elevator behavior; not evidence that every hospital robot behaves identically.