Patient-specific implant datasets: from CT to design

Which object is the model learning to produce?

Define the research output before requesting files. A model that segments anatomy, proposes implant geometry, or ranks design revisions needs different targets. The broader imaging-to-plan guide covers planning decisions; this guide focuses on the designed object and its history.

Materialise: cranial reconstruction workflow separately describes CT/CBCT intake, planning of objectives and fixation points, design approval, and manufacturing. This is an example of a published workflow, not evidence that its files are available for external training or that Operavue has a relationship with the company.

How do you connect implant geometry to the scan?

An export should have an explicit link to the source series and anatomy version. Record the distance units, coordinate-frame identifiers, and any mapping between frames. Include the direction and convention of a supplied transform; a matrix without those definitions is ambiguous. Check the actual artifacts, not just matching filenames or a plausible screenshot.

DICOM PS3.3: Encapsulated STL identifies the frame of reference with the origin and axes of encapsulated STL geometry. DICOM PS3.3: Manufacturing 3D Model Module defines distance units and fields for model usage, modification, mirroring, and derivation software. Some descriptive fields are optional; their existence in the standard does not mean every export contains them.

These references concern DICOM manufacturing-model objects. A project can agree on another representation, but it still needs enough information to interpret the geometry. Record unknown units or missing mapping as unresolved. Do not guess a scale, assume that two frames are identical, or treat an anatomy surface as an implant simply because it opens in the same viewer.

Which design version should become the reference target?

Write the target rule first: for example, the design documented as approved for the case at a defined export snapshot. Then link the delivered geometry to that exact review record. Preserve preceding and subsequent versions, their order, the requirements available at each step, and what is known about the changes. The newest filename is not automatically the approved reference.

DICOM PS3.17: revised CT/MR-derived model example illustrates a revised anatomical planning model with source-image references and a predecessor reference. It is an informative planning-aid example, not an implant dataset or proof that full CAD editing history is available.

• Keep design-requirement versions separate from geometry versions. A changed requirement can explain a changed design.
• Do not label every earlier candidate as incorrect. The reason for revision may be unknown or outside the delivered inputs.
• Keep revisions of one case together when defining evaluation groups; also account for other known shared patients or source anatomy.
• If the study asks about review time or revision count, request those records explicitly. A final mesh alone cannot supply them.

A recorded case approval identifies a decision for a particular purpose and version. It does not establish regulatory clearance, manufacturing suitability, clinical performance, or that only one acceptable geometry exists.

A synthetic example: six exports, four cases

The example below uses invented records. Its research target is the documented approved implant mesh at one fixed export snapshot. There are no scans, meshes, patients, approval documents, or clinical outcomes in the download.

Download the six-row design-lineage CSV and the field guide. These original planning fields are not a DICOM schema or clinical standard.

A-v1, A-v2, and A-v3 share one case-group reference. The missing-unit, missing-mapping, and screenshot examples are separate problems; none can be fixed by changing a status label in the manifest.

Check the example locally with Python

The implant-lineage manifest checker flags missing or contradictory declarations under the example's fixed target rule. It reads one CSV on your computer and prints a JSON report. It does not upload files, open the referenced artifacts, or change the input. Python 3 is required; no additional packages are needed.

Save the script and example CSV in the same folder, then run:

python3 check_implant_lineage.py implant-design-lineage-example.csv

The six-row example produces five findings: two exports whose review names a different design, one missing unit declaration, one unresolved coordinate mapping, and one export that is not an implant mesh. A-v2 has no declaration finding; its underlying artifacts and evidence still need review. The report uses CSV record numbers, with the header counted as record 1, rather than echoing case references or free text.

The checker also flags broken predecessor links, cycles, inconsistent revision order, and case revisions assigned to different split groups. Its required fields and supported declarations are documented in the field guide. A custom task or schema requires corresponding changes to the rules.

This is a manifest consistency check, not a clinical or dataset release acceptance test. It cannot validate a mesh, alignment, anatomy, design suitability, review authenticity, de-identification, licensing, or independence between different cases. Use the fictional example to learn the workflow; keep real clinical manifests inside an authorized environment.

What should a data request specify?

• The intended model task and which information will be available at its decision point.
• The anatomy or procedure family and the required design-stage context.
• Whether the target is a surface mesh, editable CAD, a structured design decision, or a different agreed artifact.
• Required source references, units, coordinate mappings, review records, and revision relationships.
• How unknowns, incomplete cases, and alternative acceptable designs will be handled in the evaluation.
• Who can authorize reuse of each image, segmentation, design, review record, and third-party component.

Access to a viewer or a hospital image archive does not establish access to native CAD, manufacturer files, or permission to reuse them. Confirm export capability and the proposed training, evaluation, and onward-use scope with the responsible parties before treating any component as supply.

Operavue can discuss a proposed dataset brief and the evidence needed to assess feasibility. This guide does not announce available implant datasets or clinical design services. Send a non-confidential description through the contact form; do not send scans, patient-level manifests, or proprietary design files.