Begin with the working day
A hospital does not run to a single rhythm. Stores may prepare replenishment early, wards may be busiest during handover and pharmacy may have its own release checks. A robot schedule that ignores these patterns can move waiting time from one department to another. Observe the current service before proposing automation. Include the people who load carts, answer delivery calls, find missing stock and clear space at the receiving point.
Map the whole task rather than only the journey. Record preparation, travel, receipt, put-away and exception handling. Some work is informal and therefore easy to overlook: a porter may notice that a destination has moved or confirm that an urgent item has reached the right colleague. If that judgement is currently important, the new service needs an explicit way to preserve it rather than assuming the robot inherits it.
Give dispatch useful rules
A job request needs a defined origin, destination, approved load type and service priority. It also needs a receiving arrangement. Dispatching whenever a robot is idle can create queues at wards or congest shared lifts. Use agreed delivery windows where appropriate, and consider the capacity of both the sending and receiving teams. Charging, cleaning and maintenance time should be planned alongside transport time.
Priority rules deserve particular care. An urgent label should not become a shortcut around pharmacy checks, access restrictions or safety controls. Some time-critical movements may remain unsuitable for the robotic service. Define what happens when demand exceeds capacity, how a job is cancelled and who can request an alternative. A human-supported fallback is a planned part of resilience, not evidence that a trial has failed.
Connect systems only where it helps
Integration can reduce duplicate entry, but every interface introduces responsibilities. A stock system might generate a replenishment request; a fleet manager might assign a suitable robot; a notification system might alert the destination. Each link needs clear meanings for accepted, in progress, arrived, received and failed. Without those distinctions, one system can mark a task complete while another team is still waiting for its supplies.
HL7 and its FHIR specification are important references for healthcare information exchange, but a logistics workflow does not automatically require patient-level integration or FHIR. VDA 5050 provides an interface specification for communication between mobile robots and a master control system in intralogistics; compatibility depends on versions and actual implementation. Standards can help structure procurement questions, but they do not guarantee that two products work together without testing.
Minimise information, protect access
A routine supply delivery often needs a destination code and a task identifier, not a patient name. Use the least information necessary, especially on public-facing screens and notifications. Review sensor data, logs, remote support access and retention periods with information governance and security teams. A camera used for navigation may still raise privacy questions depending on what is captured, retained or transmitted.
The Information Commissioner’s Office provides UK data protection guidance, including information about data protection impact assessments. The National Cyber Security Centre offers guidance on managing cyber risk and supplier relationships. ISO/IEC 27001 is a reference for information security management, not a guarantee that any individual interface is secure. Ask who manages credentials, how software updates are authorised and how remote access is disabled when no longer required.
Test the handoffs, not just the connection
An integration test should include duplicate requests, delayed acknowledgements, lost connections and a destination that cannot accept a delivery. Decide which system is authoritative for each state and how staff see unresolved work. Error messages need to explain the next action rather than merely display a technical code. Recovery should avoid creating a second task for a load that has already been received.
In NHS settings, DCB0129 and DCB0160 may be relevant where a health IT system falls within their scope. They address clinical risk management in manufacture and deployment respectively; applicability should be assessed by appropriate specialists. A logistics product should not be described as clinically assured merely because it exchanges messages with a hospital system. Review the actual intended use, dependencies and potential effect of failures.
Measure the service people experience
Useful measures include complete receipts, late or missed deliveries, time spent preparing and accepting loads, fault recovery effort and reported obstruction. Compare these with a documented baseline. Distance travelled and job counts can describe activity, but they do not establish that staff have gained usable time or that stock availability has improved. Include staff feedback and observe whether new workarounds are appearing.
Start with a bounded pilot, explicit review criteria and a way to stop or change the service. Agree who evaluates the results and who has authority to expand the route. Report limitations alongside benefits, including changes in workload between teams. Sustainable automation is not a machine doing more journeys; it is a dependable arrangement in which people know what to expect and what to do when expectations are not met.