Egocentric Elder Care and Assisted Living Task Data

Egocentric elder care and assisted living task data is real-world, first-person video of care-support tasks in a nursing home or assisted living setting: assisting with feeding, handling medication packs, helping with personal hygiene, supporting a resident to stand or walk, and preparing a room. It is recorded from the operator viewpoint, with depth, 3D hand pose, contact events and frame-accurate action segments aligned on one hardware clock.

The site lists these as five rows in its task catalog, all in one environment called Nursing Home & Assisted Living. Until now they have appeared on other pages only as neighbours: the Feeding assistance row on the beverage and coffee prep page, and the Room preparation row on the bed-making and object rearrangement pages. This page is built on the five rows together.

The site states five rows and no other elder care row. This page says so plainly instead of inventing a task list. It also states no clinical, diagnostic or treatment work, and nothing here should be read as care guidance. It describes what is collected for robot training, not how to care for a person.

The task catalog states five rows in the Nursing Home & Assisted Living environment, which sits in the Healthcare & Life Sciences sector. The rows are Feeding assistance, Medication handling, Personal hygiene care, Resident mobility assistance and Room preparation. Four are rated Medium and one, Room preparation, is rated Easy. All five are listed as Available on request.

The environment is described with the examples "Nursing home, assisted living facility, hospice, memory care unit -- resident mobility assistance, feeding, medication handling, personal hygiene care, and room preparation." Those settings are the examples the catalog gives for the environment. The site does not state which of them a collection runs in, and it does not name a facility or a provider.

The first table below lists each row exactly as the catalog words it, with its rating, capture mode and status.

Feeding assistance reads "Set up the meal tray, cut food and help the resident eat with spoon and cup at a safe pace." Read in order, that is setting up the tray, cutting the food, then helping with a spoon and a cup. The words "at a safe pace" are part of the row text. The site does not state how pace is measured or judged.

Medication handling reads "Check the medication chart, pop tablets from packs into cups and record what was given." The site states the handling steps only: reading a chart, moving tablets from packs into cups and recording. It states no medication names, doses or schedules, and makes no claim about correct medication practice.

Personal hygiene care reads "Help a resident wash, brush teeth and dress, handling towels, brushes and clothing." Resident mobility assistance reads "Support a resident standing, transferring to a chair or walking with a frame." Room preparation reads "Make the bed, tidy surfaces, set out water and personal items and prepare the room." The second table below sets each row against what the site does and does not state.

No. The five rows describe assisting tasks and room tasks, and the site states no diagnosis, treatment, assessment or clinical decision for any of them. This page makes no clinical, medical, patient-care or diagnostic claim beyond the row wording quoted above.

The healthcare data page says its task set is deliberately non-clinical, and that the site does not perform or claim to perform later-stage clinical validation. The same limit applies here. A model trained on this kind of data would learn the physical steps of a task. The site does not claim that such a model would be safe, correct or approved for use around people.

The catalog also has a row called Medical Procedures in a Hospital & Clinical Care environment, which covers clinical procedures on a phantom or mannequin. It is a different environment, it is rated Hard, and this page does not count it or claim it.

The site does not state that it records real residents, and this page does not claim it. The five rows use the word resident, but the catalog does not say who plays that part in a given collection.

The healthcare data page states that capture in healthcare settings happens only in training environments with simulated patients, and that real patient footage is never captured, under any circumstance, regardless of what a spec requests. The nursing home rows sit in the same Healthcare & Life Sciences sector. The site does not separately say how that boundary names a resident, so who stands in for the resident, and how that person is consented, is settled in the written spec before capture begins.

A second person in the frame is a privacy question as well as a data one. The site states that an un-consented person who is identifiable in a frame means the footage is de-identified or discarded. This page therefore makes no claim about footage of real residents, families or staff.

The five rows sit in the Nursing Home & Assisted Living environment, whose examples are a nursing home, an assisted living facility, a hospice and a memory care unit. The environment is listed under the Healthcare & Life Sciences sector, and each row is Available on request, which the site defines as scoped and recruited to spec when a buyer asks for it.

Every row names the capture mode Phone (head-mounted) / multiview rig. The site describes that mode in general as the first-person view of real work on site, and it is not the staged handheld-gripper mode. For care settings that has to be read together with the simulated-patient boundary in the section above, so this page does not claim work with real residents.

The site also states that clinical and care settings are among its thinner-coverage environments, so access is a scoping matter. It does not state which sites a collection runs at, does not name a facility, and does not state capture at a buyer own care site, so the environment, access and schedule are agreed in the written spec.

The five rows name the capture mode Phone (head-mounted) / multiview rig. A head-mounted phone records the first-person view, and a multiview rig adds synchronized third-person angles when the spec asks for them. A wrist-mounted camera is available alongside the head camera for close-range detail.

Depth, 3D hand pose, contact events and action segments are aligned to video on one hardware clock, synced under 2 ms. Distance-invalid pixels beyond the depth sensor reliable range are flagged rather than interpolated.

The site does not state a camera count, resolution or frame rate for these rows. Lighting, room layout, bed and chair types, mobility aids and the number of people in the scene are Not stated, so they are agreed in the written spec.

Each episode follows the same episode schema used across Firsthand custom collections: ten streams synced under 2 ms, with head and wrist RGB, depth, 3D hand pose with per-joint visibility, contact and grasp events, and frame-accurate action segments.

For care-support tasks, hand pose tracks the operator through each step, contact events mark when the fingers make and break contact with a spoon, a cup, a towel, a medication pack or a walking frame, and action segments mark where one step ends and the next begins. Because the labels share one clock with the video and depth, a boundary such as the end of cutting food and the start of helping with a spoon lines up with the exact frame where it happens.

The site does not say how finely hand pose resolves a grip on a cup or a medication pack, and it states no measurement of force, pace or posture, so this page makes no precision claim.

The catalog has a separate environment called Care Room (assistive care), in the same Healthcare & Life Sciences sector. Its examples are "Care room: bed, tray table, linens, participant or mannequin". It has twelve rows, all Available on request, and the third table below lists them by their exact names. The site does not describe the Care Room as elder care, so this page treats it as an adjacent environment and not as part of the five rows.

Two things differ. The Care Room rows use the capture mode Multiview rig + handheld grippers, which the site describes as a staged working set recorded by a multiview rig while the operator performs the task with handheld grippers, so demonstrations map onto a robot end effector. And its examples say participant or mannequin, and the site does not say which is used for a given row.

If your program needs assisted feeding, a meal tray, a mobility aid or medication pack sorting in a staged set, those are Care Room row names: Assisted feeding, Deliver meal tray, Hand over mobility aid and Sort medication packs. Which environment fits is set in the spec.

The healthcare data page covers non-clinical hospital-adjacent work under a simulated-patient-only boundary, and it names none of the five nursing home rows. This page covers those five rows and points back to that page for the boundary rather than restating more than that page states.

The bed-making page covers making a bed across the care and hotel rows that include it, and it treats the Room preparation row as one step of making a bed. This page covers Room preparation as one of five care-support tasks, and the bed-making page is the place for linen and bedding detail.

The hotel room turnover page covers a hotel and lodging environment, which is a separate setting in the catalog. The hospital rows Patient room prep, Equipment setup, Specimen handling and Surface decontamination sit in Hospital & Clinical Care and are not counted here. The fourth table below lists them with the reason. Streams, labels and formats are the same across all of these pages.

Care-support tasks are sequences of manipulations in a set order, performed with two hands around objects such as trays, cups, towels, medication packs and walking frames. A policy has to learn both the moves and the order. First-person data gives the hand and object detail for each move, and the action segments give the order. That combination is what the site describes for every task family it collects.

Several of these rows involve soft goods and small items, such as clothing, towels and tablets in packs. The site states no per-row manipulation difficulty beyond the Easy and Medium ratings in the catalog, so this page does not rank the rows by how hard they are for a robot.

The site states no robot results for these rows and makes no claim that any model was trained on this data. It also makes no safety claim about robots working near people. This page describes what is collected, not what a policy trained on it will do.

Every episode links to a signed contributor release through a documented consent chain, and the consent record is part of the delivery. Contributors are the people who perform the tasks, so their release covers the footage captured of their hands and workspace.

Faces, plates and screens are detected and irreversibly blurred at ingest, and a reviewer confirms the result before anything ships. Clips that cannot be de-identified are discarded. The anonymization record is delivered with the data.

The site does not state a consent process for residents or families, and it does not list name tags, medication charts, wristbands or room numbers as blur categories, so this page does not claim they are blurred. Treat them as spec items: if a medication chart or a resident name could be in view, settle in the spec how the scene is set up.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd. The first three are the training-loader formats; HDF5 and zarr carry arrays for custom pipelines, and Rerun .rrd gives a multi-stream synchronized playback file for review. The last table below sets each against what its official documentation states.

Converter source is readable, so you can retarget the schema to your own loader, and the episode schema page lists the fields.

Every batch is validated against signed accept criteria before it ships, with a reject log, and delivery is rolling, per validated batch.

Where coverage is already deep, the first validated batch lands in a median of 48 hours from signed spec. Thin environments typically take three to four weeks, because vetting operators there is the bottleneck, and we quote that timeline up front.

The healthcare data page states that clinical and care settings are among the thinner-coverage environments, with a first validated batch that typically takes three to four weeks. The five rows are Available on request, which means contributors are scoped and recruited to your spec when you ask. The site does not map that status to a specific number of days, and it states no elder-care-specific turnaround or contributor count, so the timeline is quoted against your spec.

On-demand top-ups run against the same spec and accept criteria after each training run, so new care task data stays consistent with what you already hold.

You describe the care tasks your policy needs: which of the five rows, the objects, the start state and the end state, and who is in the scene. We turn that into a written spec covering tasks, environments, capture tier, annotation depth, the scene boundary and accept criteria, then quote reach, timeline and price against that document before any capture begins.

A Spec Pilot, a small and fast first batch, can prove the spec and the accept criteria before you scale volume. Billing is per validated hour, a reject log ships with every batch, and rejected items are recaptured at our cost.