Publication: hospOS: A Platform for Service Robot Orchestration in Hospitals
Authors: S. Schmidt, D. Sommer, T. Greiler, F. Wahl
Published in: ICT4AWE, pp. 221–228 (2024)
In brief
Hospitals that want to introduce service robots quickly hit a sobering reality: every robot comes with its own closed control system. Combine a transport robot, a reception robot and a telemedicine system, and you end up operating three separate islands that talk neither to each other nor to hospital IT. That is expensive, inflexible and does not scale.
This paper – the foundational architecture work behind hospOS – proposes a different path: a central system that orchestrates existing service robots from different manufacturers, instead of procuring an expensive special-purpose robot for every task.
Why this matters now
Day-to-day hospital work is full of activities that are necessary but add little clinical value: walking long corridors, fetching and delivering supplies, escorting and orienting visitors. Every minute that skilled staff spend on transport or directions is a minute away from the bedside. Service robots promise relief here – especially in rural hospitals, where staff are scarce and distances are often long.
The expectation that a single robot will handle all of this, however, regularly leads into a dead end. A machine meant to transport, receive and provide telemedicine support all at once becomes expensive, complicated and, in the end, good at none of these tasks. This is exactly where the work begins: it shifts the focus away from the individual machine and toward the system that brings several machines together in a useful way.
The problem: closed systems, missing interoperability
The two biggest barriers to robots in healthcare, the paper argues, are the robots' task-specific inflexibility and the lack of interoperability. Existing systems are usually built so that a single robot fulfils all requirements on its own – resulting in complex and costly solutions.
On top of that, every manufacturer brings its own interface, its own operating logic and its own data model. For a hospital this means that each additional robot increases not only the purchase cost but also the integration and operating effort. Updates, maintenance and training multiply, because nothing rests on a shared foundation.
The counter-design: use and combine existing, affordable robots for different tasks. As robot adoption grows, a dedicated management system – a "robot management system" – becomes a necessity. It takes on the role that an operating system plays in conventional IT: it mediates between heterogeneous hardware and the applications meant to run on it, turning a collection of individual devices into a controllable whole.
The solution: modular, flexible, compliant
hospOS is designed as a centralised platform for orchestrating service robots. Three principles shape the architecture:
- Interoperability: seamless integration of different robots into the existing hospital IT infrastructure.
- Modularity: functions can be added individually, rather than buying one monolithic system.
- Compliance: alignment with regulations and industry standards is considered from the start.
The paper provides a concrete architecture blueprint and describes how tasks are modelled and delegated to robots – for example transporting blood samples, which requires temperature-controlled and access-protected containers.
The underlying idea is deliberately sober: not every robot has to do everything. A task is described in such a way that the system can select and assign the right device based on its requirements. This makes it possible to expand the fleet step by step – one more robot, one more function – without having to re-procure the entire solution. It lowers the barrier to entry and makes the expansion plannable.
Validated in two hospitals
The platform was not left on the drawing board but realised in two rural hospitals across three use cases: telemedicine, transport and orientation. Experience from these deployments points to improvements in service delivery and operational management.
That the validation took place in real hospital operations rather than in a lab is not a detail but the point: an architecture that holds up under scarce resources, legacy IT and everyday operational load has proven its viability. These three use cases in particular – escorting and orienting people, secure transport, and the telemedicine connection – stand as examples of the range that an orchestrating system must cover.
The foundation of our platform
This paper is the conceptual origin of Athegus. The idea described here – a vendor-independent software layer between robots and the outside world – is our product today: the Axiona middleware and the sector-specific hospOS layer for healthcare. If you want to understand why we build the orchestrating layer rather than "yet another robot", the rationale is here.
This stance also shapes how we think about digital sovereignty: whoever controls the orchestrating layer stays independent of individual manufacturers and retains authority over their own processes and data. More on this on the sovereignty page.