AI Health Monitoring

Care Home Data Isolation: What Must Never Cross Between Two Residents

Illustrative rendering of a companion device form factor
Illustrative rendering of the form factor — a watching device is defined by who can see its data, not by its sensors. Illustrative rendering, not a photograph of a shipped unit.
2 === TITLE: Care Home Data Isolation: What Must Never Cross Between Two Residents DESC: One fleet, many residents, one operator. Partition design, key scope, feature separation and deletion propagation decide whether a care home can deploy AI hardware at all. KEYWORDS: care home data isolation, resident data separation, multi tenant ai hardware, voice feature storage TAGS: privacy, architecture, elder care, procurement Q: What is the minimum isolation unit in a care home deployment? A: The resident, not the building and not the room. Every stored item, feature and export has to be attributable to one resident, or the operator cannot answer a family's question. Q: Why separate voice features from identity data? A: So that one breached store cannot be reassembled into a named person. The feature tells you a voice is the same; the identity table tells you whose. Q: What does deletion have to propagate to? A: The live record, the caches, the search index and the backup policy — a delete that only clears one table is not a deletion, and it is the most common gap in a product demo. Q: Does a shared lounge device need isolation at all? A: Yes, in the other direction: it must be able to prove that lounge conversation was not written into any resident's record.

A care home is not one user with a lot of data. It is a hundred individual data subjects living within twenty metres of each other, whose devices are managed by one operator, whose families each have a right to ask what was recorded, and whose regulator may ask the same question with a deadline attached.

That combination makes isolation the central architectural decision in a Health & Wellness deployment, ahead of sensor choice, ahead of model choice. Get it wrong and the product cannot be sold into an institution, no matter how well it converses.

The four partitions that have to exist

  • Per resident — memories, reminders, call records and notes, all attributed to one person, all exportable for that person alone.
  • Per staff member — who set the reminder, who logged the handover, who approved a change, so accountability survives turnover.
  • Per device — the room's unit is an instrument, not an owner. Its serial links to a resident assignment that can be changed without dragging data with it.
  • Shared spaces — a lounge or dining-hall unit that stores nothing against an individual is a feature, and it needs to be provable rather than asserted.

Two design rules that do most of the work

Keep no audio, keep the fact. The device extracts a non-replayable voice feature during processing and the audio is discarded. What remains is a text memory, an attribution and a timestamp. This is simultaneously a privacy decision, a storage-cost decision, and the reason a breach does not hand somebody recordings of residents talking about their health.

Keep identity away from the feature. A vector that says "same voice as before" is useful to the product and nearly useless to an attacker on its own; the table that says which resident it belongs to lives separately, with narrower access. Two stores, two different keys, two different blast radii — the same logic that governs whether a ring with a charging case can be reassigned between wearers without carrying anyone's history.

What must never cross between residents

  1. A first name mentioned in one resident's conversation, surfacing in another's reply.
  2. A carer's note logged during a shift in room 12 appearing in room 14's history.
  3. A family member's phone number or personal request stored under the resident's global preferences.
  4. Health-related statements attributed to a resident without provenance — a device that infers writes liability, so it records what was said, not what it concluded.

The last one is where a wellness product quietly turns into something nobody wants to sign for. We hold the line at: describe, do not interpret. A wrist device and a companion robot in the same building should not be allowed to merge into one inferred dossier either — a resident's family may have consented to one and not the other, which makes cross-device linking a documented, revocable act.

Deletion, and the part everyone forgets

Deleting a resident's record is easy; deleting it everywhere is the audit question. Live store, derived index, cache, the copy inside the nightly export, and whatever the retention policy promised about backups. A credible answer is a written propagation list per data class, with a stated deadline — and the same list, inverted, is what an operator hands to a family that asks a harder question.

Multi-site operators add one more layer: two homes under one management company still means two populations, because the second home's staff should have no path to the first home's residents. That is a tenancy decision, not an app permission, and it is cheap to reserve and painful to retrofit — the same argument as the wider AI wearables line where personal devices join institutional networks.

What an operator should see before signing

A data map: which classes exist, which system holds each, who may read it, how long it lives, and how it dies. Alongside it, the certification and transport documents for the physical hardware, because procurement reviews both and they are usually written by different people — sampling and lead times set the schedule, OEM and ODM customisation sets what the branding and firmware do to that data map, and how the units are built and tested is the part a facility can actually verify on a visit. The rest of the catalogue is at products; a care programme scoping both the wrist and the room layer can send the specification through the contact form.

Questions buyers ask

What is the minimum isolation unit in a care home deployment?

The resident, not the building and not the room. Every stored item, feature and export has to be attributable to one resident, or the operator cannot answer a family's question.

Why separate voice features from identity data?

So that one breached store cannot be reassembled into a named person. The feature tells you a voice is the same; the identity table tells you whose.

What does deletion have to propagate to?

The live record, the caches, the search index and the backup policy — a delete that only clears one table is not a deletion, and it is the most common gap in a product demo.

Does a shared lounge device need isolation at all?

Yes, in the other direction: it must be able to prove that lounge conversation was not written into any resident's record.

Related: more on ai health monitoring · buyer guides · customisation tiers