Skip to content

Offered-versus-refused activity reporting for a care home group

Activity tracking for a UK care home group, with an AI report of offered versus refused sessions that only ever sees de-identified records.

HealthcareA UK care home group with several homes ยท 4 min read

Carer offering drinks to residents in a care home lounge decorated with bunting
Client
A UK care home group with several homes
Industry
Healthcare
Platforms
Web, Mobile
Download one-pager (PDF)

The project in brief

  1. The challenge

    Homes in the group run many activities each week. Managers wanted to know which ones residents turn down and what staff say about them, without reading every attendance list and enrichment chart by hand. Any AI involved could not be allowed to see who the residents are.

  2. What we built

    We built the activities module first: interest-based invitations, attendance with mandatory absence reasons, and enrichment chart entries. On top of that record we added an AI breakdown that works only on redacted, de-identified text, with results matched back to residents inside the group's own platform.

  3. The result

    For each activity, planners see how often it was offered against how often it was refused, with negative staff comments brought to the top. The data behind the report is captured during ordinary shifts, and resident identities never reach the AI model.

What the system does.

The parts of the system that made the difference for the client and the people who use it.

  • Offered versus refused

    Per activity, the AI shows times offered against times refused, so planners see at a glance which sessions are not landing.

  • Negative comments first

    Critical staff comments from enrichment charts rise to the top, so the reason behind a refusal is easy to find.

  • De-identified before AI

    Names, dates of birth, NHS numbers, phone numbers and addresses are removed or replaced with placeholders before any text reaches the model.

  • Matched back in-house

    Results return keyed to placeholders and are joined to the right resident inside the group's own platform.

  • Mandatory absence reasons

    Staff must give a reason, such as 'not interested', for every absent resident, which gives the report its evidence.

  • Interest-based invitations

    The system suggests residents for an activity from their interests, and staff add or remove names.

  • Reviewed by planners

    The home manager and wellbeing coordinator read the breakdown before changing a program.

  • Reporting only

    The breakdown never cancels a session, edits a schedule or changes a resident's record.

Built with

The tools behind it, layer by layer.

  1. Front end

    • React
  2. Back end

    • Node.js
    • Express.js
  3. Database

    • MongoDB
  4. AI

    • OpenAI API
  5. Cloud and hosting

    • AWS
  6. CI/CD and DevOps

    • GitHub Actions
    • Git

The full story

The challenge

A UK care home group with several homes plans its activities around what residents enjoy. Some sessions fill up. Others are offered week after week and quietly turned down, and the pattern stays hidden until a manager sits down with a pile of attendance sheets.

The group wanted care home activity tracking software that showed which activities residents refuse and what staff say about them. Reading every attendance list and enrichment chart by hand was slow, so it rarely happened across a whole month or a whole home.

There was a firm condition. Activity records describe older people, often frail, so any AI in the system had to do its job without ever learning who those people are.

What we built: care home activity tracking software with AI

We built the interests and activities module for the group's care platform on React, Node.js, Express.js and MongoDB, for desktop and mobile. Then we added an AI breakdown on top of the records staff already keep.

  • Interest-based invitations. Staff tick each resident's interests. When an activity is scheduled, the system suggests residents who might enjoy it, and staff add or remove names.

  • Mandatory absence reasons. After each session, staff mark every resident as attended or absent. An absence can't be saved without a reason, such as "not interested".

  • Enrichment chart entries. Residents who attended get an entry covering engagement, mood and staff comments.

  • The AI breakdown. For each activity, the AI shows how many times it was offered against how many times it was refused, and brings negative staff comments to the top.

The breakdown is a report and nothing more. It never cancels a session, edits a schedule or touches a resident's record.

How it works day to day

Picture the wellbeing coordinator planning next month's program. Instead of paging through attendance sheets, they open the breakdown and see each activity's offered and refused counts side by side, with the critical comments listed first.

A session that residents keep declining stands out right away, and the comments beside it hint at why. The coordinator and the home manager talk it through and decide what to change. The software points; people choose.

Because absence reasons are mandatory, the report's evidence is gathered as staff close each session. Nobody fills in an extra form for the AI.

How resident data stays private

Only redacted, de-identified text is passed to the AI model. That rule shaped the whole design.

  1. Identifiers come out first. Before anything leaves the group's platform, the system removes or replaces personal identifiers: names, dates of birth, NHS numbers, phone numbers and addresses. Each resident becomes a placeholder, including when a name appears inside a staff comment.

  2. The model sees de-identified text only. It counts offers and refusals and ranks comments without knowing whose they are.

  3. Results are matched back in-house. The breakdown returns keyed to placeholders, and the group's own platform joins it to the right residents for staff to read.

  4. People check the output. The home manager and wellbeing coordinator review the report before anything changes in a resident's week.

We designed this flow with UK GDPR in mind, sending the model the least information the task needs.

The result

Activities, attendance, absence reasons and enrichment entries now live in one place, on desktop and mobile. For any activity, planners can see how often it was offered, how often it was refused and the comments that explain the gap.

They get that view without exposing a single resident's identity to the AI model. We have no measured outcome figures to share, so we don't quote any. What changed is the capability: refusal patterns that used to hide in paperwork are now a report the team can act on.

What the research says

  • Digital care records are now the norm. The Department of Health and Social Care estimates that 81.1% of CQC-registered adult social care provider locations in England had a digital social care record as of October 2025 (DHSC provider statistics). Those records are the raw material for reporting like this.

  • Data security weighs on providers. In the government's 2025 adult social care provider technology survey, 41% of respondents named the cost of cyber and data security as a barrier to adopting care technology over the next five years (DHSC technology survey).

  • Placeholders still need protecting. The UK Information Commissioner's Office notes that pseudonymized data is still personal data for whoever holds the extra information, while pseudonymization can reduce the risks to the people concerned (ICO guidance). That is why the key to each placeholder never leaves the group's platform.

Where AI fits next

Neither of these is built yet. The AI could suggest alternative activities drawn from the interests of the residents who refuse most often. Managers could also compare breakdowns across homes to see which sessions work in one home and struggle in another.

Planning something similar?

Before you add AI reporting to care home activity tracking, settle four questions:

  1. Which records does the AI genuinely need, and which identifiers can come out before it sees anything?

  2. Do staff record the reason behind a refusal, or only the absence?

  3. Who reads the AI output, and what are they allowed to change because of it?

  4. Where does the link between placeholders and real residents live, and who can open it?

This report looks across sessions; for one resident over time, see our AI activity summaries for care homes, and for residents who rarely take part, the AI resident engagement audit. Read our guide to keeping business data private with AI, see how we approach AI automation, or explore our healthcare software work.

Common questions

What does care home activity tracking software do?

It records which activities are scheduled, who was invited, who attended and why anyone did not. This group's version adds an AI breakdown that shows, for each activity, how often it was offered against how often it was refused, with negative staff comments listed first.

Does the AI see residents' names or personal details?

No. Before any text goes to the AI model, the system removes or replaces personal identifiers such as names, dates of birth, NHS numbers, phone numbers and addresses. The model works on de-identified text, and its results are matched back to the right resident inside the group's own platform.

Can the AI change activity schedules or resident records?

No. The breakdown is a report for the home manager and wellbeing coordinator. People decide what to change; the AI only points them at activities residents keep turning down.

What data does an AI activity report need?

Activity schedules, attended or absent marks, a reason for every absence and staff comments from enrichment charts. Making absence reasons mandatory means that evidence is collected during normal shifts.

What technology was the activities module built with?

React for the interface, with Node.js, Express.js and MongoDB behind it. Staff use it on desktop and mobile.

More of our work.

Projects that used the same services or served the same industry.

See all our work

Free project estimate

Talk through a project like these.

Thirty minutes with a founder, not a salesperson. Bring the problem; leave knowing what we'd build first and what it would cost.

What you get back

  • An indicative budget range
  • A realistic timeline
  • What moves the cost up or down
  • A reply within 4 business hours
  • Answered by a founder
  • NDA on request, before you share details

Tell us what you need

A few lines is plenty. You get a number before any call.

Fields marked * are required.