Buying surgical robotics data: a procurement checklist

What belongs in a surgical data request?

Start with a short technical brief that an engineer, surgeon, and procurement lead can all interpret. “We need surgical video for AI” is too broad to price or evaluate. “We want to recognize a defined set of instruments across specified procedure types” gives the supplier something concrete to assess.

• Research objective and intended stage of development.
• Procedure types, operative approach, and views that matter.
• Required video specifications and any synchronized non-video signals.
• Requested labels, their granularity, and the expected clinical reviewer role.
• Desired source diversity and which settings should be held out for testing.
• Delivery format, security arrangements, timeline, and budget structure.

State what is optional. If stereo is desirable but monocular is acceptable for a first phase, say so. If outcomes are not needed, avoid collecting them by default. A narrower brief may reduce both cost and governance work.

How should a buyer evaluate sample footage?

Ask for a sample selection method as well as sample files. A highlight reel can establish visual appeal but conceal ordinary recording defects. Include complete sequences, boundaries between files, difficult visual conditions, and a small annotation sample that reflects the proposed production process.

Have the people who will use the data inspect it before procurement closes. An annotation export that looks complete in a spreadsheet may still be difficult to align with decoded frames. A test ingestion is a practical way to surface those gaps.

Why discuss evaluation splits before purchase?

An evaluation can be misleading if closely related clips appear in both training and testing. Ask what stable, privacy-preserving identifiers are available to keep related recordings together. Where relevant, plan separation by case, patient, site, recording system, or time period.

The IMDRF: good machine learning practice, 2025 emphasizes representative datasets and appropriate independence between training and test data. Your exact split design still depends on the intended use and the claims you want to assess.

Write down what the test set is meant to challenge. Performance on new clips from a familiar setting answers a different question from performance at an unseen site. Do not treat the number of frames as the number of independent clinical examples.

Which commercial terms deserve explicit treatment?

Review the identity of the licensee, permitted research and commercial uses, affiliates and contractors, model training and evaluation rights, retention, redistribution, and use of derived artifacts. Clarify whether exclusivity applies to the source files, a field of use, a geography, or a time period.

Also define access revocation and correction handling. If a release contains a defective annotation or an incorrectly included file, both parties need a workable process for notifying recipients, replacing data, and recording the change. A license and a data release should remain connected throughout the project.

What should the first delivery prove?

The first delivery should prove that the agreed workflow works: files arrive securely, checksums match, manifests reconcile, labels align, and the acceptance sample meets the brief. Keep the acceptance decision separate from a model-performance promise. A supplier can satisfy a data specification without guaranteeing a downstream model outcome.

Use a written issue log with a responsible owner, a response window, and a resolution category. Distinguish unusable media, missing context, disputed labels, and new requirements. This makes remediation specific and keeps scope changes visible. Our dataset quality guide offers a framework for the review.