Liver Tru-Cut Cohort

The working data behind the liver core-biopsy project — pseudonymised slide archives, their extracted form, and a FileMaker clinical database, all held on a drive and deliberately outside git.

The working data behind the liver core-biopsy project — pseudonymised slide archives, their extracted form, and a FileMaker clinical database — held on the K: drive and deliberately outside version control.

What it is

A small, well-organised working directory (K:/liver-tru-cut-medical) with three parts:

• rawData/ — slide archives as .zip, named with ANON… pseudonym tokens, roughly 1.1 GB across the four present.
• extractedData/ — one directory per case, using the same ANON… tokens, i.e. the unpacked form of the archives.
• data/ — liver_tru_cut_medical.fmp12, a FileMaker clinical database, alongside hepatocyte-app-pipeline-output/, the results of running hepatocyte-app over these slides.

It is not a git repository, which is the correct arrangement and worth stating plainly: clinical images and a clinical database live on the drive, and only derived, de-identified tables should ever reach a repository. That is the same governance boundary Memorial WSI Share describes, applied to a single project’s working set.

The pseudonymisation is also consistent here in a way it is not everywhere else. Every archive and every extracted directory carries an ANON… token and nothing else — no accession numbers, no dates in filenames. Compare the .qpproj finding on Liver Tru-Cut — Tumour Origin AI, where the tracked QuPath project mixes those same ANON… tokens with a large number of accession-format strings. The data folder is clean; the repository that analyses it is not. That is a useful thing to know, because it means the leak is in the tooling layer rather than in how the cohort was assembled.

Why it matters for my work

It is the substrate for two projects at once — the tumour-origin question in Liver Tru-Cut — Tumour Origin AI and the segmentation pipeline in hepatocyte-app — and the presence of hepatocyte-app-pipeline-output/ inside it is the evidence that the second has actually been run over this material rather than only described.

The FileMaker database is the part with no counterpart elsewhere in this wiki. Every other clinical backbone recorded here is a spreadsheet or an LIS extract; this is a live relational database sitting beside the images. It also resolves a question left open on Digital Pathology Drafts: a liver_tru_cut.fmp12 in a small demo repository could not be cleared as sample-or-real, and this is its full-sized sibling — which makes the demo copy far more likely to be exactly what its own notes claimed, a schema sample. The real one lives here, outside git, as it should.

Nothing from this folder is reproduced in this wiki — no case identifiers, no counts of patients by any clinical attribute, no images.

How it connects

Liver Tru-Cut — Tumour Origin AI — the project that asks where each biopsy’s tumour came from; this is the data it asks the question of.

hepatocyte-app — has been run over these slides, with its output stored alongside them.

Memorial WSI Share — the same governance rule at department scale; this is one project’s working set rather than the shared archive, and it is unclear whether these slides also exist there or only here.

De-identification — the ANON… scheme used consistently here is what that page asks for, and the contrast with the tracked project file is the worked example of doing it right in one place and not the other.

Foundation Model Cache — the sibling directory K:/liver holds the model environments used against this cohort, so the data and the models it is fed to sit on the same drive.

Open questions

• How many cases are actually in the cohort? Answered, and the premise was wrong. Four cases looked far too few for the modelling on Liver Tru-Cut — Tumour Origin AI because these are two different cohorts. The tumour-origin work uses a separate 509-case set under K:/liver, with its own FileMaker database of a similar name. This folder is the small set that hepatocyte-app runs morphometry over. Correcting it here because the two are one letter apart in the filename and the mistake is easy to repeat.
• Is the ANON… mapping key stored, and where? Pseudonymisation implies a lookup existing somewhere; if it does not, the cohort cannot be re-linked to outcomes, and if it does, it is a re-identification key that needs its own access control. Neither state is recorded.
• hepatocyte-app-pipeline-output/ is read now. Each case folder holds patches/ with three parallel sets of roughly 1,565 tiles each — source_patches (the raw tile), predict_patches (the segmentation mask) and visual_patches (a QC overlay) — then assembled/ with the same three stitched back to slide scale, and morphometry/ with a morphometry_report.xlsx that is the actual quantitative output. So the pipeline runs patch → predict → assemble → measure, and keeps every intermediate. Storing all three patch sets at full count is generous with disk; keeping the QC overlay is a good habit, since it is what makes a bad segmentation visible without re-running anything. Still no record of which code version produced any of it.
• Is the drive backed up, and is the FileMaker database included in whatever backup exists? It is the only non-reproducible artefact here: slides can be re-exported, a hand-curated clinical database cannot.
• The closest published work to this cohort is now filed, and it is close indeed. Zabihollahy 2026 — CurvReg (multi-stain liver biopsy registration) registers curved liver needle biopsies across H&E, Masson trichrome and CK7 — the same specimen geometry and the same stain family — and reports that transferring MT-derived portal tract and hepatic vein segmentations onto H&E raises H&E segmentation Dice from 0.86 to 0.92, because MT shows the vascular boundaries that H&E obscures. Two questions for this cohort follow and neither is recorded here: does it hold MT or CK7 levels alongside the H&E, and are any of them from the same block rather than merely the same case? Serial multi-stain levels are what make any of that applicable, and a cohort of H&E alone cannot use it at all. [unverified] See Cross-Stain Registration for what the technique would and would not deliver.