Egocentric Hospital and Clinical Care Task Data

Egocentric hospital and clinical care task data is first-person video of hospital tasks: positioning and connecting bedside equipment, labelling and bagging specimen containers, preparing a patient room, wiping down surfaces, and practising clinical procedures on a phantom or mannequin. 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 one environment, Hospital & Clinical Care, and states no other hospital row. This page covers those five and describes what is collected for robot training, not how to deliver care.

The task catalog states five rows in the Hospital & Clinical Care environment, which sits in the Healthcare & Life Sciences sector. The rows are Equipment setup, Medical Procedures, Patient room prep, Specimen handling and Surface decontamination. Two are rated Easy, two Medium and one, Medical Procedures, Hard. All five are listed as Available on request.

The environment carries the examples "Patient room prep, equipment setup, specimen handling, surface decontamination -- requires HIPAA compliance". Those are the catalog examples for the environment. The site does not name a hospital, a ward or a provider.

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

Equipment setup reads "Position and connect monitors, pumps and stands at the bedside and check they run." Patient room prep reads "Make the bed, stock supplies, position equipment and set up the room for the next patient." The site states the physical steps only. It names no device model and no clinical setting for the equipment.

Specimen handling reads "Label, bag and log specimen containers and place them in transport racks." Surface decontamination reads "Wipe down beds, rails and equipment with disinfectant and dispose of used wipes." The site names no disinfectant, no label format and no log system, and it makes no claim about correct infection-control practice.

Medical Procedures reads "Perform clinical procedures on a phantom or mannequin, dressings, injections and checks." The second table below sets each row against what the site does and does not state.

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

One row sits closer to the edge than the others. The healthcare data page describes its task set as deliberately non-clinical, and says the site does not perform or claim to perform later-stage clinical validation. Medical Procedures is a catalog row for clinical procedures on a phantom or mannequin, rated Hard. The row wording is the only description the site gives, so exactly which steps a collection records is settled in the written spec.

No. 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 Medical Procedures row itself says phantom or mannequin. The site does not say which of those, or which person, stands in for the patient on the other four rows, so that is settled in the spec.

The catalog example text for this environment ends with the words "requires HIPAA compliance". That is catalog wording and nothing more. The site states no HIPAA certification, no compliance programme and no audit for these rows, and this page claims none. Because capture uses simulated patients only, the spec is where any regulatory question for your own program is raised.

The five rows sit in the Hospital & Clinical Care environment. 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, which the site describes in general as the first-person view of real work on site rather than the staged handheld-gripper mode.

For healthcare that has to be read with the simulated-patient boundary above, so this page does not claim work with real patients. The site also states that clinical and care settings are among its thinner-coverage environments, so access, sites and schedule are agreed in the written spec. The site names no facility.

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. Each episode follows the 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 bedside tasks, contact events mark when the fingers make and break contact with a stand, a container or a wipe, and action segments mark where one step ends and the next begins. The site does not state a camera count, resolution, frame rate or any measurement of force or pace, so this page makes no precision claim.

The catalog has neighbouring healthcare environments: Nursing Home & Assisted Living (five care-support rows), Care Room (assistive care) (a staged set with twelve rows), Wet Lab & Clinical Bench (laboratory work) and Dental Lab & Medical Device Workshop. The site does not describe any of them as hospital work, so this page counts only the five Hospital & Clinical Care rows. Which environment fits is set in the spec.

Hospital support tasks are sequences of manipulations in a set order, performed with two hands around monitors, pumps, containers, linens and wipes. First-person data gives the hand and object detail for each move, and the action segments give the order.

The site states no robot results for these rows, makes no claim that any model was trained on this data, and makes no safety claim about robots working near patients. 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 how the screens category applies to a bedside monitor display, and it does not list wristbands, specimen labels or chart text as blur categories, so this page does not claim they are blurred. Treat them as spec items and 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.

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 site lists clinical settings among the thin environments. The five rows are Available on request, and the site does not map that status to a specific number of days or state a hospital-specific 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.

You describe the hospital tasks your policy needs: which of the five rows, the objects, the start state and the end state, and who or what plays the patient. 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.