Hospital Robotics Operating System — a cloud + edge hybrid platform that coordinates multi-vendor robot fleets for supply delivery, cleaning, disinfection, and logistics.
Accelerate sits between hospital operations and heterogeneous robot fleets — TUG, Moxi, Pudu, Avidbots, UVD, Relay, Keenon, and more.
Eight non-negotiable principles that guide every technical decision.
Robots operate even if cloud is unreachable. All real-time tasking, traffic, and safety logic runs at the edge.
Never leak vendor-specific concepts above the Fleet Abstraction Layer. Upper layers speak a universal robot language.
Operate on locations, tasks, and assets — not patients. Where patient context is needed, use opaque references only.
Every state transition, command, override, and access attempt is logged immutably. Non-negotiable for healthcare.
Loss of any single component degrades capability, not halts operations. Robots fall back to vendor-native behavior.
All inter-service communication defined by protobuf/OpenAPI schemas before implementation. No ad-hoc coupling.
All commands to robots are idempotent. Network retries must be safe — no duplicate deliveries or double-stops.
Structured logging, distributed tracing (OpenTelemetry), and health metrics on every service from day one.
Each module is independently deployable, with clear API boundaries and an explicit edge vs cloud split.
Vendor-neutral interface for connecting, monitoring, and commanding heterogeneous robot fleets. Everything above this layer doesn't know or care what vendor built the robot.
The "brain" — creates, prioritizes, assigns, monitors, and completes tasks across the fleet. Scoring-based assignment, not rules engine, for transparency and debuggability.
Hospital-aware movement coordination — zone definitions, elevator/door integration, congestion awareness, restricted areas, priority routing. Prevents collisions and deadlocks.
Hospital-facing web portal for operations managers, charge nurses, and administrators. Real-time map, fleet view, task management, alerts, and dashboards.
Keep the fleet running — health monitoring, battery management, preventive maintenance, remote diagnostics, incident management, and uptime tracking.
Healthcare-grade governance — immutable hash-chained audit logs, PHI filtering, RBAC, approval workflows. Regulatory requirement, not optional.
Connect to hospital systems and building infrastructure — elevators, doors, identity (AD/SSO), EMR, WiFi monitoring, RTLS. Each integration is a plugin behind a common interface.
The #1 make-or-break integration for multi-floor robot operations. A robot that can't use elevators is confined to a single floor.
View Full Elevator Integration Case Study →Fallback stack ensures every elevator in every hospital is reachable — cloud API down to mechanical button push.
Single API all robots use regardless of elevator brand or integration method. Upper layers never know which OEM built the elevator.
Dedicated adapter modules for each elevator manufacturer's cloud API. Hot-pluggable — adding a new OEM means deploying a new adapter.
For elevators without cloud APIs — older models, Fujitec, Hitachi, small OEMs. Relay module with WiFi/cellular simulates button presses via dry contacts. Partner with M2MTech for their ELSA IoT Gateway.
Camera vision + arm/actuator physically presses buttons. Proven at hospital scale by Diligent/Moxi (110,000+ autonomous rides). For emergency/temporary situations or elevators that cannot be modified.
| Company | API | Protocol | Developer Portal | Hospital Proof | Priority |
|---|---|---|---|---|---|
| KONE | Best — WebSocket + REST | OAuth 2.0, OPC | dev.kone.com | Multiple, Open-RMF adapter | #1 |
| Otis | Yes — OID | Azure Cloud API | developers.otis.com | MMUH UK, many US hospitals | #2 |
| TK Elevator | Yes — Touchless | WiFi/4G via TAC | developer.ea.tkelevator.com | Calgary Cancer Centre (30 elevators) | #3 |
| Schindler | Yes — BuilT-In | REST via local server | developer.schindler.com | Rice Robotics (HK) | #4 |
| Hyundai | Yes — Open API | Cloud API | Unknown | 30+ buildings (Korea) | #5 |
| Mitsubishi | Partnership only | Proprietary | None | Cartken partnership | TBD |
| Hitachi | No | Patent-based | None | None public | Relay |
| Fujitec | No | None | None | None | Relay |
"Nurse requests supply delivery from pharmacy to Room 412" — traced through every system component.
Adapter detects fault → Task reassigned to next-best robot → Alert generated → Maintenance record created → Full audit trail preserved
5-min timeout → Check alternate routes → Escalate to Ops Manager if no alternative → Priority auto-escalates as SLA approaches
3 missed heartbeats (15s) → OFFLINE status → Robot continues on vendor-native nav → Resync on reconnect → Alert if >2min
Business Associate-grade security. PHI minimization as the primary defense, with defense in depth at every layer.
Real-time operations at the edge, analytics and management in the cloud. Offline-resilient by design.
| Data Type | Direction | Mechanism | Frequency |
|---|---|---|---|
| Robot status | Edge → Cloud | NATS → gRPC batch | Every 10s |
| Task events | Edge → Cloud | NATS → gRPC batch | Real-time (buffered) |
| Audit entries | Edge → Cloud | gRPC stream | Real-time (buffered) |
| Health metrics | Edge → Cloud | Prometheus remote write | Every 15s |
| Robot registry | Cloud → Edge | gRPC sync | On change + 5min |
| Facility map | Cloud → Edge | gRPC sync | On publish |
| RBAC permissions | Cloud → Edge | gRPC sync | On change + 5min |
Five phases from foundation to pilot-ready, each with clear exit criteria.
Infrastructure, contracts, and scaffolding — audit, RBAC, PHI filter.
Connect to first robot fleet, see robots on a map.
Create, assign, and complete delivery tasks end-to-end.
Multi-floor operations with elevator and door integration.
Second vendor adapter validates abstraction. Support tooling and analytics.
Production-ready for first hospital pilot. Security audit, chaos engineering, documentation.
Three languages, each chosen for where it excels. No ML in V1 — predictability over optimality.
Features deliberately deferred to maintain V1 focus and predictability.
Discharge → cleaning, diet order → meal delivery. Requires hospital-specific FHIR work.
PWA or native app for floor staff — web works for V1, mobile is a UX improvement.
Full trajectory planning via Open-RMF. Zone-based is sufficient for <30 robots.
Need 6+ months of operational data before ML assignment makes sense.
V1 is single-facility focused. Cross-campus task routing requires new coordination layer.
Mobility, transport, humanoid support — regulatory complexity, higher liability.