Imaging-to-surgical-plan datasets: what must be paired?

What counts as a surgical planning target?

Start with the output the research team wants to predict or evaluate. A scan, an anatomy mask, a three-dimensional anatomical model, and a documented surgical plan answer different questions. The phrase “surgical planning dataset” is not enough to specify the target.

DICOM PS3.3: Segmentation IOD describes segmentation as pixel classification associated with referenced images. KiTS23: official challenge repository is a concrete kidney-tumor segmentation benchmark. Neither the name of a segmentation file nor a segmentation score establishes that an operative-plan target is present.

Intuitive: 3D Models describes CT/MRI-derived anatomical models used in a surgical planning workflow. That is useful context for separating the model from the decisions made with it; it does not establish access to exportable plans or an Operavue partnership.

What belongs in an imaging–plan pair?

Write a target definition before requesting cases. For a text or structured-decision task, specify the fields and how reviewers interpret them. For a spatial target, specify the representation, coordinate system, units, and required mapping to the source images. A screenshot can help someone review a plan without providing the machine-readable geometry an experiment needs.

For implant or hardware targets, the CT-to-implant dataset guide explains geometry lineage, design revisions, and version-specific review with a separate synthetic example.

• An approved case reference and the exact delivered image-series references.
• The target artifact, version, definition, and source-series mapping.
• The planner or reviewer role, review status, and unresolved disagreements.
• The information available to create the target and the intended model-input cutoff.
• Geometry and transformation records when the target depends on spatial alignment.
• Documented permissions, release version, limitations, and evaluation grouping.

Keep a proposed plan, later revision, and postoperative record distinct. An initial choice may change for reasons outside the delivered scan. Preserve the revision history and the scope of available context instead of silently replacing the original target.

How do you verify that the plan belongs to the scan?

Have the source team establish which images actually informed the plan and how they map to the delivered files. A shared folder name or case reference is a useful join key, not proof of that relationship. A later scan, another reconstruction, or a processed image can belong to the same case while answering a different question.

For spatial outputs, inspect the declared coordinate mapping and representative overlays under the agreed review process. DICOM segmentation can share a frame of reference without having identical sampling or extent to the source images. Do not infer alignment merely from matching array dimensions. Record unresolved mappings explicitly.

This is a source-side evidence review. The small manifest below records declared relationships; it cannot inspect files, recover a missing transform, or establish clinical correctness.

Which information was available when the plan was made?

Distinguish three things: the information the model may use, when the reference target was authored, and what evidence its author could see. For a task intended to reflect a preoperative decision, postoperative findings used to construct the target can change the question being evaluated.

Retrospective authorship alone does not make a plan unusable. ClinicalTrials.gov: NCT06434727 describes retrospective simulated preoperative planning with scans and 3D models, evaluated through surgeon questionnaires. A retrospective task needs an explicit method and evidence basis; it should not be silently presented as the contemporaneous clinical plan.

If the evidence basis is unknown, keep it unknown. Do not convert a missing date into “preoperative only.” Keep outcome information separate from model inputs when the experiment requires that separation, and document how reviewers were restricted to the intended information.

Worked example: four proposed pairs, four different decisions

The following is an original synthetic example. Every case, identifier, review status, and circumstance is invented. No scans or plans are included. For this exercise, the requested target is a documented plan based only on information available before surgery; it does not require spatial geometry.

Download the four-case pairing CSV and the field guide. These are original planning fields, not a DICOM schema, clinical standard, or automated acceptance test.

P01 is not a claim that a dataset is ready to train on. P02 reports a mapping discrepancy, not an incorrect clinical plan. P03 could be useful for a different segmentation task. P04 illustrates known use of later evidence, not a rule excluding all retrospective research.

What should a first evaluation establish?

Before expanding collection, reconstruct one complete example from the approved input to the exact target version. Confirm that the files can be read, the source mapping is supported, the target definition is usable, and qualified reviewers can assess the evidence. Record disagreements and cases that cannot be assessed.

A recorded plan may be one defensible choice rather than the only valid answer. Specify how the evaluation handles reasonable alternatives, incomplete context, and revisions. A reference label and an observed outcome are different kinds of evidence.

IMDRF: Good Machine Learning Practice, 2025 emphasizes reference standards suited to the intended purpose and attention to dependencies between training and testing. Keep related patient/case versions together when the design calls for independent groups, and record the basis for that grouping. The dataset quality guide explains evaluation splits in more detail.

Check access and reuse conditions separately for images, plans, software exports, and derived artifacts. Public documentation of a workflow or benchmark does not grant permission to license its underlying data.

How do you scope an imaging-to-plan inquiry?

Describe the modality, procedure family, exact planning target, required representation, and missing evidence. State whether the research needs a contemporaneous plan, a retrospective reconstruction under a defined protocol, or both as separate cohorts.

Use the data procurement brief to record those requirements. Operavue can discuss the proposed scope and feasibility; this guide does not announce an available imaging-to-plan dataset or a confirmed supplier. Share a non-confidential description through the contact form, without patient records, scans, or case-level manifests.