Clinical & care
Constraints
Capture for this setting happens only in training environments with simulated patients. Real patient footage is never captured, under any circumstance, regardless of what a spec requests. That constraint is fixed before any other scoping conversation happens.
Clinical and care settings are one of the thinner-coverage environments on this site, alongside construction, agriculture, and hospitality. Vetting operators for a hospital-adjacent training environment is the bottleneck, which is why a first validated batch here typically takes three to four weeks rather than the faster turnaround available in deeper-coverage settings.
What gets captured is the kind of work that happens around patient care rather than clinical treatment itself — tasks a robot or AI system needs to learn in a controlled, simulated setting before any later-stage clinical validation, which this site does not perform or claim to perform.
Beyond the simulated-patient boundary, a healthcare collection runs through the identical process used for every custom collection on this site — a written skill spec, paid and consented contributors, synchronized sensor streams, per-batch QA, and licensed delivery.
Definition
Egocentric healthcare and hospital data is first-person video of hospital-adjacent task work — recorded from a camera near the worker’s own point of view, a chest mount, head rig, or wrist camera, rather than a fixed overhead or side-angle camera. What makes this setting different from every other industry page on this site is a hard constraint on where capture can happen: only in training environments with simulated patients, never with real patient footage.
The underlying capture, labeling, QA, and licensing process is the same one used across every custom collection on this site: a written skill spec describing the task and setting, paid and consented contributors performing the work, synchronized sensor streams recorded alongside the video, and per-batch QA before delivery. What changes for this setting is the simulated-patient-only boundary applied before any capture begins.
Fit
A good fit is non-clinical hospital-adjacent work — the kind of task that happens in and around a hospital without involving direct clinical treatment of a real patient. Because capture only happens in a simulated-patient training environment, a spec names the specific non-clinical task, the controlled setting it will be performed in, and the simulated-patient arrangement used, rather than describing a live ward or clinic.
Tasks that require a real patient, a live clinical environment, or any patient-identifying footage are not a fit for this program and are not captured here under any spec. If your training pipeline needs that kind of data, it falls outside what this site captures and should be sourced through a dedicated clinical-research or medical-device data provider instead.
This page is about the healthcare and hospital setting specifically. For a broader workplace task framing that is not hospital-specific, see this site’s general workplace task data page; for a procedure-structure framing that applies across industries, see the procedural task video data page.
From task to spec
A healthcare collection starts the same way any custom collection on this site does: you describe the non-clinical task your training pipeline needs covered, the controlled training environment it will be captured in, and the simulated-patient setup, if any, involved. That becomes a written skill spec naming the task, setting, participant mix, capture tier, annotation depth, and accept criteria — quoted for reach, timeline, and price before any capture begins.
Because clinical and care settings are thin coverage on this site, the spec conversation also covers operator vetting up front, since that vetting — not contributor demand — is the actual bottleneck to a first batch in this environment.
Many programs start with a Spec Pilot, a small, fast first batch that proves the spec and accept criteria on a limited task set before scaling to full volume. That lets a buyer confirm the simulated-patient setup and label quality before committing to capture across a larger program.
Capture setup
Capture uses the same stream menu available across every custom collection — head and wrist RGB, depth, IMU, and 3D hand pose — recorded inside the controlled training environment named in the spec, with simulated patients standing in for any patient-facing element of the task. The specific stream set is chosen to fit the task, the same way it is for any other industry on this site.
As with every custom collection, the setting, participant mix, and simulated-patient arrangement are all named explicitly in the written spec before capture begins, rather than left to be decided on the day of a shoot.
Labeling
Captured footage is broken into the same labeled structure used across every collection on this site: action segments marking the start and end of each discrete step, episodes grouping a full task attempt, and hand pose carrying fine manipulation detail. Failure and recovery cases — a dropped item, a misstep, a correction — are captured and labeled as part of the same structure rather than treated as an error to discard.
Where a task has a defined step order — a setup-then-operate-then-reset sequence, for example — that order is written into the spec and carried through into how the action segments are labeled, the same way it is for any procedural task on this site.
Privacy
The governing rule for this setting is that capture happens only with simulated patients in a training environment — real patients are never captured, which removes the patient-privacy question that a live clinical setting would raise. For everyone who is captured, including contributors and any bystander in frame, faces and screens are detected and irreversibly blurred at ingest, with a reviewer confirming the result before anything is delivered.
Every episode is linked to a signed contributor release under a documented consent chain, the same requirement applied to every custom collection on this site. Any clip that cannot be reliably de-identified is discarded rather than shipped with a caveat.
Rights
The buyer. Every custom collection, including a healthcare program, is delivered under a perpetual, non-exclusive commercial license by default, with exclusivity available, so the finished dataset can be trained on and productized without a research-only or unstated licensing arrangement.
Delivery is billed and licensed against the accept criteria named in the written spec, with rejected items recaptured at no cost to the buyer before anything ships. Pricing is quoted per spec rather than published as a flat rate; see the pricing page for how a quote is built.
Delivery formats
Healthcare data ships in the same formats available for any custom collection on this site: RLDS, LeRobot, and WebDataset, plus HDF5, zarr, and Rerun .rrd, or raw streams with metadata if your pipeline needs the unprocessed form. Readable converter source ships alongside the data, so the schema can be retargeted to your own loader.
Getting started
Describe the non-clinical task, the controlled training environment it happens in, and the simulated-patient setup your training pipeline needs. That becomes a written spec covering the task, setting, participant mix, capture tier, annotation depth, and accept criteria, quoted for reach, timeline, and price before capture begins.
Because this is a thin-coverage setting, expect the spec conversation to also cover operator vetting timelines — typically three to four weeks to a first validated batch — up front. From there the program runs through the same end-to-end pipeline as every Firsthand collection: contributor recruiting, capture against the spec, per-batch QA, anonymization, and licensed delivery.
At a glance
Every collection runs through the same seven-stage end-to-end custom collection pipeline. End-to-end custom data collection is a managed service that takes an AI data need from problem to owned dataset in a single accountable pipeline.
Task families
| Hospital task family | Typical steps | What the delivered data contains |
|---|---|---|
| Equipment handling | Retrieve, check, stage, return equipment | Skill spec, action segments, episodes, hand pose |
| Supply and cart handling | Restock, organize, transport supply carts | Skill spec, action segments, episodes |
| Room turnover | Reset, clean-adjacent prep, restage a simulated room | Skill spec, action segments, episodes, completion check |
| Patient-adjacent logistics (simulated) | Transport or handoff tasks performed with a simulated patient stand-in | Skill spec, action segments, episodes, hand pose, failure/recovery label |
Capture constraints
| Capture concern | How the process handles it |
|---|---|
| Risk of real patient involvement | Capture restricted by policy to training environments with simulated patients only; real patient footage is never captured |
| People in frame | Faces and screens blurred at ingest; undeidentifiable clips discarded rather than shipped |
| Operator vetting for a sensitive setting | Treated as thin coverage; first batch typically takes three to four weeks because vetting is the bottleneck |
| Consistency across contributors and batches | Same written spec and accept criteria govern every batch; QA checks labels against those definitions before delivery |
FAQ
Sources
Tell us the non-clinical task and the simulated-patient training setting your pipeline needs covered. We will turn it into a written skill spec and run a Spec Pilot before scaling to a full collection.