How ProstateView is generated

Simple explanation

ProstateView starts with public prostate MRI research data. The prostate structures are outlined either from public dataset annotations or from a segmentation pipeline. Those outlines are converted into 3D surfaces, exported as lightweight 3D models, and displayed in a phone-friendly viewer.

The aim is not to read the MRI or replace PACS. The aim is to give the urologist a simplified orientation model of gland, zones and lesion context so they can rehearse the location mentally before opening PACS or sitting down at an MDT.

Pipeline

1. 01
   Public MRI dataset

   Source case from Prostate158 (Adams et al., 2022). Public research data only. No NHS patient scans. No identifiable data.
2. 02
   Prostate structures outlined

   Either via the dataset's expert ground-truth annotations (ground-truth-derived) or via the MONAI prostate_mri_anatomy bundle run on the GPU (model-inferred). Each case declares which path was used.
3. 03
   3D surfaces generated

   Marching cubes is run on each labelled volume. Surfaces are decimated and smoothed for phone-friendly file sizes.
4. 04
   GLB model exported

   Per-case GLB with named nodes (prostate_gland, peripheral_zone, transition_zone, lesion_01 if present). Lesions are never invented; missing nodes are reported as not available.
5. 05
   ProstateView viewer

   Astro PWA serves the GLB directly from /demo-cases/. No backend required for viewing. Rotate, toggle zones, dial opacity, jump to preset orientations.
6. 06
   Orientation before PACS

   The clinician returns to PACS, the radiology report and MDT discussion for the formal clinical decision. ProstateView is the urology-side mental-map layer, not a replacement for any of those.

GPU usage

MONAI inference and any heavy mask processing run on the project workstation (Jarvis, NVIDIA RTX 5070 Ti, 16 GB). The viewer itself does not require a GPU on the user's phone or laptop - the model is a small GLB. See GPU_RUN_LOG.md for the hardware probe and GPU_BATCH_RUN_LOG.md for per-batch runtime.

Validation approach

For cases where we have both ground-truth labels and a model-inferred output, we compute:

• Dice coefficient for whole gland / PZ / TZ (where comparable)
• Volume of GT and inferred structures, and percentage difference
• Centroid distance, as a sanity check for spatial alignment

This is technical validation of segmentation agreement against public dataset annotations. It is not clinical validation, not diagnostic validation, and not proof of biopsy-targeting accuracy. See docs/VALIDATION_METHOD.md and docs/ACCURACY_FAQ.md.

Limitations and what is not claimed

• No diagnosis.
• No PI-RADS assignment by ProstateView. PI-RADS, if displayed in future, will come only from formal report metadata.
• No staging.
• No biopsy targeting.
• No clinical validation.
• No automated cancer detection.
• The MRI preview is downscaled and window-levelled. It is not a diagnostic image viewer.
• Some library slots reuse an existing public GLB for UI demonstration only - these are clearly labelled "UI demonstration case using existing public model geometry".