oncoanalyser icon indicating copy to clipboard operation
oncoanalyser copied to clipboard

Support for multiple tumor samples per patient (longitudinal and multi-region) in a single run

Open peteryzheng opened this issue 3 months ago • 3 comments

Description of feature

Currently, the pipeline only supports one tumor DNA sample per patient per run. This limitation makes it difficult to analyze longitudinal or multi-region tumor samples for the same patient, especially when there is a single normal sample and multiple tumor (DNA and/or RNA) samples from different timepoints or anatomical regions.

Feature Request:

  • Allow users to specify multiple tumor samples (with different sample_ids) for a single patient and single normal in the samplesheet, and have the pipeline process all of them in the same run.
  • Enable output for each tumor sample and, where appropriate, longitudinal or comparative analyses (e.g., WISP, joint variant calling, etc.)

Use cases:

  • Longitudinal MRD or monitoring: A patient has a single normal and tumor samples from several timepoints (e.g., diagnosis, relapse, post-treatment).
  • Multi-region sequencing: A patient has a single normal and tumor DNA from multiple regions of the primary or metastatic tumor.

Current workaround:

  • Users must run the pipeline once per tumor sample, duplicating the normal sample, which is inefficient and complicates downstream comparative analyses.

Benefit:

  • Streamlines longitudinal and spatial tumor analysis workflows and aligns with common research and clinical use cases in oncology genomics.

peteryzheng avatar Sep 11 '25 15:09 peteryzheng

Hi @peteryzheng, thanks for writing up this as an issue - addressing redundancy in the analysis of multiple tumours from the same patient has been planned for some time. I'm aiming to include relevant changes in the 3.0.0 release, specifically focusing on the longitudinal workflow as you've described

However, some of the improvements you've noted aren't possible within only oncoanalyser itself and require changes in upstream tools themselves e.g. AMBER can only handle a single tumour sample

scwatts avatar Sep 12 '25 04:09 scwatts

Thanks for the quick response — great to hear this is on the roadmap for 3.0.0!

Two quick things to help me plan my analysis and give useful feedback:

Timeline

  • Do you have a tentative window for the 3.0.0 release? Even a rough ETA would help us schedule our analyses.

Implementation thoughts

  • Given AMBER’s single-tumor constraint, it seems sensible to run AMBER/COBALT/PURPLE per tumor sample while reusing the same aligned normal once across those runs.
  • Where feasible, joint SNV/SV/fusion calling across the tumor set would be hugely valuable for longitudinal alteration/neoantigen tracking.
  • Conceptually, a structure like the one below (which you likely already have in mind) would cover most use cases :
    1. Align all samples (for fastq entry)
    2. Iterate over tumor DNA (+/− RNA) samples using the same aligned normal.
    3. Enable optional longitudinal/comparative modules (e.g., WISP, joint calling).

Thanks again for all the work on oncoanalyser — much appreciated!

peteryzheng avatar Sep 12 '25 17:09 peteryzheng

The 3.0.0 release will be a few months away, and will likely begin to come together towards / around the new year. Thank you for the feedback, we share the ideas you have put forward as well!

In terms of reducing redundancy for the current release in the described scenario, one approach is to perform only the alignment and REDUX steps (which are generally the most computationally demanding steps) for each sample and then start the analysis from REDUX BAM

Running the pipeline in this way avoids aligning and running REDUX several times for normal samples in the case of multiple tumours

scwatts avatar Sep 14 '25 01:09 scwatts