Memorial WSI Share
The de-identified whole-slide image cohort held on the Memorial network share — the group’s primary image asset, deliberately kept outside git.
What it is
A shared storage location holding de-identified scanned slides, referenced by name across several projects rather than described in one place. It is defined as much by a governance rule as by its contents: large images, PHI, and raw exports live here, and only de-identified, analysis-ready tables are committed to repositories.
What is recorded about it:
- Holds de-identified scanned slides for HER2 Intratumoral Heterogeneity (gastric/GEJ cases with HER2 IHC and reflex ISH), Pancreas Morphology (a de-identified image cohort explicitly stated as not in git), and Omentum (WSIs where available).
.qpprojQuPath project files for cohorts containing patient identifiers stay here rather than in repos.- Linkage to clinical data runs through hashed accession IDs.
What is not recorded anywhere: total slide count, scanner models and magnifications, date range, storage size, or per-project subdivision. [unverified] The schema for this wiki asks for scanner and magnification on every model paper, so this is a real and repeated gap rather than a cosmetic one.
Why it matters for my work
Nearly every image-based project depends on it, and its governance rule is the boundary that keeps the public repositories safe. It is also the single point of dependency that is least documented — a new contributor can read the whole portal and still not know what is actually on the share.
How it connects
De-identification — the process every file passes through before landing here, and the reason the share exists as a separate tier at all.
Whole Slide Imaging — the file characteristics that make this a share rather than a repo.
QuPath Annotation Workflow — reads from here and writes GeoJSON annotations back.
Memorial LIS Extracts — the clinical-data counterpart, joined via hashed accession IDs.
Scanner and Stain Variability — if the share spans multiple scanners, that is a covariate every model project needs to know about.
Open questions
- What is actually on the share? A one-time inventory — slide count, scanners, magnifications, date range, per-project breakdown — would answer the schema’s standing questions for every AI project at once. This is probably the single highest-value gap in the wiki right now. It is also mostly a read-only crawl rather than a research task: ScanTools would give scan dates and a content hash per slide, and
large_imageexposes scanner name and magnification from the same headers. The output is a CSV of one row per slide, and it can be written without modifying a single file. The obstacle is not tooling. - Is the hashed-accession lookup table stored separately with its own access controls? It is the asset that makes the data pseudonymised rather than anonymous.
- Is scanner metadata captured before anonymisation strips it? The ecosystem notes suggest anonymisation deletes it, in which case it is being lost permanently.