Shift Handover From a Companion Robot: What It Should Record and What It Must Not
Ask a care home director what would make an AI device worth installing and the answer is rarely "better conversation". It is: can the next shift tell what happened. That reframes the product from a companion into a record-keeping instrument with a personality, and it changes what the software must capture.
A useful handover from a companion robot is narrow and boring on purpose. The resident asked for a photograph of her sister at 06:40. A reminder was set for tablets at 08:00 and confirmed. She declined to talk twice during the evening round. The call to her son connected for eleven minutes. Each of those is a fact with a timestamp and an author, and together they give the incoming carer something to act on that a paper sheet usually loses.
The line between a record and a conclusion
Everything above is safe to write down. What follows is where products overreach: "resident appears low", "possible sleep disturbance", "ate less than usual". Those are inferences from thin signals, drawn by a system that has no clinical role, in a building where another professional would have been the one to notice.
We hold the line at describe, do not interpret. If a device cannot help generating an impression, the design answer is to surface the underlying observations to a person and let the person's judgement be the record — with their name on it. An inference attributed to a machine, in a home where the family may later ask why nothing was done, is the worst of both worlds for everybody except the litigator.
What an audit trail has to contain
- Author — resident, relative, carer or system, per entry. Anonymous entries are the first thing an inspector rejects.
- Time — and whether the entry was edited later, with the previous version retained.
- Scope — which resident, which shift, which room, so that a handover cannot drift between people.
- Read access — who opened the record. Care staff notice when a colleague has been reading a difficult resident's notes, and they are entitled to a system that says so.
- Export — one resident's handover history, printable for a family meeting, without exposing two other residents' names in the same document.
The export requirement is quietly the hardest one. It forces the isolation design underneath to be real: per-resident partitions, per-staff attribution, and a report builder that cannot join across residents by accident. Where the same operator also deploys a health ring or a wrist device for the same person, those two records have to stay in their own lanes unless a documented consent joins them — the same reason we treat cross-device linking as an explicit act in the wider wearables line.
The family report is where this pays for itself
A relative's question is always the same: how was she this week? A weekly report built from real entries — who called, what she asked for, which reminders were confirmed, how many evenings she declined to talk — answers it in a page, and is the single most effective thing an operator can send. It also puts honest pressure on the device's silence: a week that reads as nothing happened may mean a quiet week or a dead battery, and a good report distinguishes those two, which is why connectivity state belongs in the record alongside content.
What to insist on from a supplier
Three answers in writing. Which fields exist per entry and who can change them. What the system does not store, stated positively rather than as a promise. And what happens to a resident's handover history when they move out or object — a number, a process, and an export format that a family can read without us.
The documentation an institutional buyer bundles with those answers is the same file the radio and battery work produces, itemised in our CE RED checklist; the schedule to place a first fleet is set out under MOQ, sampling and lead times; and how the units are exercised before packing is on the factory page. For a programme that wants its own branding, app and retention policy, that is an OEM or ODM scope discussion — send the specification through the contact form, or start by comparing suppliers using how to vet an AI wearable supplier.
Questions buyers ask
Can a companion robot produce a care record?
It can produce the raw material of one — what was asked, what was requested at what time, what the device was told to remind about — which a human then turns into a handover. It should not produce conclusions about a resident's condition.
Who should be able to read those notes?
The rota role that needs them, for the residents they are caring for, with an audit trail showing who read what. Family access is a separate, narrower permission.
What is the most common failure in a handover record?
Attribution. A note that does not say who made it and when is worth nothing at an inspection, and is often exactly what a device writes by default.
How long should handover notes survive?
A stated period, published in advance and enforced by the system rather than left to a person with a delete button. The number is a policy decision between operator, resident and legal counsel — not a vendor default.
Related: more on ai companions · buyer guides · customisation tiers