The first question is not which robot you buy

Service robot manufacturers want into the European market, and they want into healthcare. The demand is there: hospitals are looking for relief in transport, visitor guidance, and information services. The hardware can deliver. Navigation, payload, runtime, and build quality have reached a level that carries daily clinical operation. What stalls deployment is almost never the device.

It sits structurally outside it. The architecture and operating model of today's robot solutions grew out of markets where a device largely works on its own and its data is managed in the manufacturer's cloud. That is a sound choice there. European hospital operation works differently: a robot there is an IT system in a sensitive environment, connected to elevators, doors, access systems, and hospital IT, with traceable data flows and documented rights. This gap is not in the robotics. It is in the layer above it.

When we talk to facilities and to integrators, the same two questions come up almost every time. First: why does it need an extra software layer between the robot and the building at all? Second: why not simply use the solution the robot manufacturer ships with the device? Both questions are legitimate, and this post answers them separately for the two groups that ask them. Athegus is a spin-off of Deggendorf Institute of Technology (TH Deggendorf), born out of the SMART FOREST 5G Clinics research project; our platform Axiona has been running in daily clinical operation since 2023 and is documented in six independently peer-reviewed publications.

For healthcare providers

The first question in a robotics project is not which robot you buy. It is what the operation should look like: which task should a robot take on, which systems must it reach to do so, who may commission it, and what do you need to be able to show afterwards? Once that is settled, device choice remains a technical question of task, dimensions, and fit. Reverse the order, and the first device you buy determines how your operation works from then on.

Where the benefit comes from

A robot driving down a corridor is not, by itself, relief. That relief comes into being where robots / building systems / IT meet: the transport starts because an order arrives from the relevant department system. The robot reaches the third floor because it is allowed to call the elevator. It passes through the fire door because the controller releases it. It is admitted to the lab area because the access system recognizes it. And the sample can be located because the handover was logged. Every one of these points sits outside the device.

That is why the extra layer is not an end in itself, but the place where these connections are built once and then apply to every further device. You connect the elevator, doors, access control, HIS and LIS, roles and permissions, logging and reporting once, not again for every robot model. That also gives you what a mixed fleet needs day to day: one task control, one permissions management, and one reporting system, regardless of which device happens to be driving.

That this approach holds up is shown by hospOS live operation: a robot handles 80.68% of lab-sample transports there. That share does not come from the device's performance alone, but from order, elevator, journey, and handover coming together without manual intermediate steps.

Sovereignty is a question of architecture

The second part of the answer concerns data. A service robot in a ward corridor carries a camera and a microphone with it. The sensitivity follows from the location alone: patient rooms, the admissions desk, the lab, waiting areas. You do not need a name list for a recording from a ward corridor to be personal data. That is why, in hospitals, the question of data flow gets asked earlier than in other industries, and why it often decides whether a project starts at all.

The answer that holds up is not another layer of contracts, but an architecture that makes the question smaller.

"What never leaves the facility needs no transfer basis."

That is not a legal trick, but a consequence of how data is held. If coordination runs locally, maps, orders, telemetry, and recordings stay inside your environment, and the assessment shifts from "on what basis do we transfer this?" to "does anything leave the building at all?". Axiona is built for exactly that: three operating modes — cloud, on-premise, and fully offline — carry the same functional logic. The mode therefore remains an operating decision your organization makes, not one the product dictates. For what that looks like technically, see Service robotics without data outflow.

That also puts the origin of a solution in its proper place. For some countries of origin in service robotics, an adequacy decision by the European Commission exists — for Japan and the Republic of Korea, for example — for others it does not. That is a statement about the legal situation, not a judgement of any country. An encapsulable architecture makes you independent of that distinction, because you do not have to answer the question anew for every manufacturer.

One distinction matters here that often gets lost in procurement conversations: where data is stored and who can access it remotely are two different things. A server on your premises says nothing about who can look at it from a distance. The European Data Protection Board spelled this out in Guidelines 05/2021 (Version 2.0, adopted 14 February 2023): para. 9 sets out three cumulative criteria for a processing operation to qualify as a transfer. Para. 16 notes that remote access from a third country can also be a transfer, even where data there is merely displayed on a screen, for example during support, troubleshooting, or administration, provided the three criteria from para. 9 are met. Conversely, para. 17 clarifies that purely internal processing, where data is not disclosed to another controller or processor, is not a transfer within the meaning of Chapter V. That is the architectural reasoning behind the sentence above. Whether the criteria are met in a given case is for your data protection function and your legal counsel to assess. The architecture determines how often that assessment even arises.

This translates into a design principle for us, not a vote of no confidence: no standing remote access. There is no permanently open channel from outside into the facility. Remote support runs as a session — activated by the facility, time-limited, logged. For manufacturers and integrators that is not a loss of serviceability, but the form in which remote support can be reliably agreed in a regulated environment and presented in a tender.

Proving what actually happened

Anyone deploying robotics in a regulated environment must not only ensure operation, but be able to prove it: who triggered an order, which role was authorized to do so, which journey took place when, which systems were involved? Such evidence does not emerge after the fact from the operating data of individual devices; it emerges in the layer that sees all orders. That is why roles and permissions, logs, and reports belong there.

One detail we built deliberately: a data gap is reported as a data gap, not as a zero. If recording is missing for a period, the report says exactly that. A metric that smooths a gap into a zero value looks better and is worthless in an audit. How this relates to the documentation duties under KRITIS and NIS-2 is covered in our practical guide to KRITIS and NIS-2 for service robots; the principles behind it are under sovereignty and security. Logs and reports do not replace a compliance organization, but they do reduce the documentation burden. What never leaves the facility makes the question of a transfer basis moot in many cases.

If you are planning a project, the concrete path is the fastest one: show us one of your workflows, and we will show you how it runs through a neutral layer, in the operating mode your organization requires. Request a demo.

For integrators and system houses

For integrators and system houses, the question about the extra layer looks different. It is not whether such a layer is needed, but who builds and maintains it. In-house robotics software is rarely the cheapest option. The effort is not in the first integration, but in the tenth, and in everything that has to keep running: elevator protocols, door controllers, access systems, role models, update paths, and operating modes.

The division of labor

The split that works in practice follows what each side actually owns. You have the customer relationship, on-site facility know-how, acceptance testing, and commissioning. That is capital you cannot buy in. The platform delivers orchestration, building connectivity, the operating model, and evidence. You work through the GUI or headless via the REST API. That way you build your own commercial offering, under your own brand and your own contract, without building your own robotics team.

The leverage lies in the shared integration library. Every new integration — an elevator type, an access system, a robot model — then becomes available to every industry solution on Axiona: for hospOS just as for shoppiOS. Your work on one hospital project therefore also carries the next retail project.

Mixed fleets, device changes, operating model

That brings us to the second question: why doesn't the software that ships with a device usually carry the operation on its own? Not because it is weak, but because it is built for one device, and the operation consists of several. Three observations from practice:

The mixed fleet is the normal case, not the exception. At Kliniken am Goldenen Steig in Freyung, several device types run on the same platform, including Keenon T3, Keenon W3, and temi v2, on a single KONE elevator integration set up once. At Technologie Campus Grafenau, the same foundation serves as a test environment for new models and elevator controls. Hardly any facility picks one device for every task: a transport robot for lab samples, a companion robot for reception, and a cleaning device are three different machines, often from three manufacturers. Device-specific software knows its own device very well — as it should. It cannot deliver an overview of a mixed fleet, because that is not its job. The installations are documented under references.

Hardware gets replaced, workflows stay. A robot model has a shorter lifecycle than a clinical workflow. If the workflow logic sits in the device, every device change becomes an integration project. If it sits in the layer above, it becomes a procurement. For you, that is the difference between a project you sell once and an installation that grows over years. More on this in More robot choice without switching systems.

The operating model is a prerequisite, not an add-on. In hospitals, at utilities, and in other regulated environments, data handling, remote access, and evidence come up not at the end of the technical clarification, but at the start. Whoever only answers them at acceptance testing negotiates them under time pressure. Whoever brings the answers along has already done part of the tender work.

"With an encapsulable, offline-capable layer, the operating model becomes the integrator's selling point, instead of a project risk."

You go into the conversation with an answer you can back up, instead of a promise you will have to make good on later. That shifts the discussion with data protection, IT, and engineering from "is this even permitted?" to "which workflow do we take on first?". The case-by-case assessment by the facility's data protection function and legal counsel remains unaffected by this.

If you want to add robotics to your portfolio, or put a running project on a solid footing, let's talk about the division of labor. Become a partner.

The ecosystem stays open

New robot models are connected through adapters, not through a special solution per project, and every new integration benefits every industry solution on Axiona. Anyone who wants to bring good hardware into the European healthcare market does not need to rebuild their architecture or replicate their own European operating model to do so: the shorter path runs through a layer that already exists, that has been running in daily clinical operation since 2023, and that takes on the integration and evidence work. Your devices then qualify for more tenders, not fewer. Become a partner.