Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One Case Per Sample for FASTQ #455

Open
3 tasks
RasmusBurge-CG opened this issue Jun 13, 2024 · 6 comments
Open
3 tasks

One Case Per Sample for FASTQ #455

RasmusBurge-CG opened this issue Jun 13, 2024 · 6 comments

Comments

@RasmusBurge-CG
Copy link

As a user assigned to the pipeline FASTQ,
I want one case per sample,
So that the order-view in Trailblazer would tell me if a sample failed on amount of reads.

Acceptance Criteria

  • For each sample, generate one case in any ticket that includes an app-tag related to FASTQ delivery.

...

Notes

  • Additional information.
  • Dependencies.
  • Related user stories.

Implementation plan

  • Work item 1
  • Work item 2
@RasmusBurge-CG
Copy link
Author

@karlnyr, This is a start at least

@ChrOertlin
Copy link

ChrOertlin commented Jun 13, 2024

As a user of the trailblazer order view I would like to have FASTQ order stratified on a sample level and an indication whether samples did not reach the required amount of reads. @RasmusBurge-CG Is this right?

Added to refinement 19-06-2024

@islean
Copy link
Contributor

islean commented Jun 13, 2024

As a user of the trailblazer order view I would like to have FASTQ order stratified on a sample level and an indication whether samples did not reach the required amount of reads. @RasmusBurge-CG Is this right?

Added to refinement 19-06-2024

I can just add that I would prefer having one case per sample than having the order summary logic depending on the workflow. Having one case per sample was also how I interpreted Rasmus' wishes

@RasmusBurge-CG
Copy link
Author

RasmusBurge-CG commented Jun 13, 2024

As a user of the trailblazer order view I would like to have FASTQ order stratified on a sample level and an indication whether samples did not reach the required amount of reads. @RasmusBurge-CG Is this right?
Added to refinement 19-06-2024

I can just add that I would prefer having one case per sample than having the order summary logic depending on the workflow. Having one case per sample was also how I interpreted Rasmus' wishes

Hi, yes @ChrOertlin, 'user of trailblazer' is a more accurate description. In my mind it does not need to be on a sample level, it could still be at case level(now that case and sample are somewhat equal, if we make the changes for Fastq).

I guess one only needs multiple samples in a case when we are running trios. Do you agree, @islean? This might be a good discussion for a larger audience.

Note: the changes are only suggested for pipeline FASTQ. (but I'm tempted to say that this would be a good change for all pipelines. However, I think that trios should be in the same case)

@ChrOertlin
Copy link

Ok, this is more of an trailblazer issue, I am transferring the issue there.

@ChrOertlin ChrOertlin transferred this issue from Clinical-Genomics/cg Jun 17, 2024
@Vince-janv
Copy link
Contributor

Vince-janv commented Oct 17, 2024

Suggestion by devs:

When order is placed for FASTQ orders, create one case per sample

Considerations @ChrOertlin will look into these

get_cases_to_analyse should behave the same way.

Needs testing - although no change expected as it works for other cases as well. Mostly depends on how the OrderSubmitter stores the case data

get_analyses_to_upload should behave the same way.

Needs testing - although no change expected as it works for other cases as well. Mostly depends on how the OrderSubmitter stores the case data

See if file-structure on caesar remains the same.

Since fastq is a sample level file it will be formatted as ticket/sample/file just as it is now. No change expected. Will be confirmed with a test.

Finding "pair" samples when canceling them. Ask AZ if the change would cause issues for the lab

No issues, it would be an improvement.

According to AZ it can become a confusion that multiple fastq samples are stored under a single case if they have no relationship that just the order they are in. Especially, when just one sample needs to be cancelled the question could arise whether the whole order would need to be cancelled. If a sample would have it's own case this ambiguity would not exist.

According to KN this would be very nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants