Skip to content
This repository has been archived by the owner on Jun 15, 2023. It is now read-only.

DPL-330 Heron fail plate process via Lighthouse-UI - how to handle certain fail scenarios #231

Open
7 tasks
andrewsparkes opened this issue Mar 22, 2022 · 1 comment

Comments

@andrewsparkes
Copy link
Contributor

andrewsparkes commented Mar 22, 2022

Description
As Operations and CoTrack/PAM we need to be clear on when the destination plate fail screens in Lighthouse-UI should be used and the implications to reporting.

Who the primary contacts are for this work
Carl R (CoTrack/PAM)
Lizzy T, Sara S (Operations)

Knowledge or Stake holders
Scott T (R&D) - knowledge of Biosero and Beckman robot methods
Andrew S (PSD)

Acceptance criteria

  • create list of fail plate scenarios for Beckman and Biosero for use in following discussions
  • discuss with CoTrack/PAM whether Ok for samples to be both failed in cherrypicking but also put forward to library prep, and if there is any alternative
  • discuss with Ops how to more clearly identify when the fail screens should NOT be used
  • discuss with Ops if we need a 'Source plate failed' screen for Beckman schedule file errors (not linked to destination)
  • discuss with Scott T whether schedule file issue on Beckman can be improved
  • discuss with Scott T whether Biosero duplicate sample picks issue can be resolved
  • modify fail code to cope with duplicate samples

Additional context or information
See RTs 746405, 746257
For both systems we occasionally have scenarios where samples are duplicate picked. Some may be on a plate that is failed, but also on another plate that gets library prepped. Or the duplicates may be on the same plate. Possible the current code is not handling duplicates and throwing exception (needs fix).
On Beckman there is a scenario where a schedule file (picking file) gets re-used, resulting in a source plate being used up with incorrect picking (but no record of that source against the destination), and at the same time the previous source was picked fine into a previous destination, but is now falsely linked (with it's samples) to the new destination. We don't want to 'fail' those picked samples.

@TWJW-SANGER
Copy link

TWJW-SANGER commented Mar 25, 2022

I think this is a good overview of the research that needs to be done to understand the situation.

I wonder if "modify fail code to cope with duplicate samples" is research? It sounds like a bug fix / enhancement in its own right, unless we are unsure of what the actual behaviour should be?

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

No branches or pull requests

2 participants