DPL-964 Research - As a long read user (James) I want the ability to track sample volumes and enable top-up management

[SujitDey2022]

User story As a long-read user (James W.) I want to be able to track sample volumes so that the customers can be effectively view and manage sample re-reruns (top-ups) without manual intervention.

An unknown number of ToL samples require additional sequencing - estimated 25-50%. Currently, the process requires an email from the customer to SeqOps to confirm if any sample remains. Then the lab team manually checks the volume remaining. By tracking the volume in Traction and having the data accessible through MLWH, the customers will be able to see without manual intervention if a sample can be re-run. It also opens the way to automating the process on their end as well. Around 500 samples are estimated to need a top-up of data. This is a very significant amount of manual work that we would like to prevent in the future

Who are the primary contacts for this story James W.

Who is the nominated tester for UAT James W.

Acceptance criteria To be considered successful the solution must allow:

• [ ] System allows/detects to track estimated Library volumes remaining
• [ ] System enables customers to view volume tracking data

Dependencies This story is blocked by the following dependencies:

• sanger/#

References This story has a non-blocking relationship with:

• sanger/#

Additional context

This will reduce the need for multiple emails and manual sample checks per sample. Up to 50% of ToL submitted samples (200-400 per month) could require a top-up. The extend is largely unknown as this processing is essentially not happening at present, which means ToL is unable to complete and assemble genomes.

[stevieing]

Volume Tracking:

• Volume is recorded for a library (pool) when a pool is created on Traction.
• As a lab user, we would like to be able to manage the library volume automatically
• The volume would need to be updated on two occasions
• When a run is created i.e. volume is taken from a pool create a complex - this would need to be user specified
• When a pool is made i.e. when volume is taken from 2 or more samples to create a new pool
• Also required is a way to flag a library as exhausted i.e. 0uL volume. (It would be great if this could link with Labwhere. Destroyed location = 0uL or vice versa)
• Note: Library volume may decrease outside of these scenarios e.g. due to evaporation, spillage, loss of sample
• As a lab manager I would like to be able to track these volumes using the MLWH in conjunction with other data to determine sequencing schedules e.g. top up of samples that failed to meet initial coverage
• ToL as a user of long read services would also like to be able to access this volume information via the MLWH to facilitate their top up management system in STS

[stevieing]

Library Volume.pptx

[stevieing]

https://lucid.app/lucidchart/3c12fbb3-5265-49b5-9f6a-97c9a69a59eb/edit?view_items=-C~VhnCRl96t&invitationId=inv_4a6b1f8d-e886-4ffc-b784-40f2135c0679

[stevieing]

From James (02/01)

Question: Hi Steve it looks good - just worth flagging early that it will need a bit of flexibility due to evaporation of sample, minor pipetting errors etc. so it wont always be a clean sum up of used volumes. e.g. 15uL and 15uL might use up a 35uL sample. On the occasions where we: a. have more sample than expected in traction: It would be good if we could mark a sample as 0uL remaining - library exhausted. b. have less sample than expected in traction: Would it be best to have the used volume be accurate i.e. we used 15uL so that is recorded accurately, but then round up any negative values to 0? Or perhaps the simplest option would be to have a manual adjustment volume to bring things in to line if they fall out - like a used volume that can be manually specified? Will be great to have volumes in traction though

Answer: The design I have created is flexible enough to cover all of those scenarios, how we decide to implement them is up to you e.g. if 15uL and 15uL might use up a 35uL sample it might be that you want say that the original volume was 30uL in which case we could exhaust the original sample and modify the volume of the primary aliquot to 30uL. We could then push this data to the warehouse as a new record.

The design itself will enforce correctness so you will not be able to have volumes in the system that do not make sense.

[andrewsparkes]

My comments:

For short read library pools there is already in Limber the functionality to manually record volume (as QC information) against the tube after it has been created. Possibly 'volume' could be set on creation of the library tube by having it as a field in the pooling screens. You could then give it a default value from the purpose config that varies by pipeline, and allow the lab user to modify that default if needed.

For DNA in plate wells earlier in the pipelines uploading information in QC files is probably the only way to do it, it is impractical to manually set volumes on all the individual wells in 384 and even on 96-well plates.

Automatically decrementing volume remaining as transfers are made from plates and tubes in pipelines is a bit risky, as there is no direct connection between the transfer volumes set in liquid handler robot methods and the LIMS tracking. We could only hardcode a transfer volume in the configs for a step and assume it was not been changed. API interactions with liquid handler robots to pull information about what was actually transferred is not implemented. And in any case would only return what the robot was told to transfer, not what was actually physically transferred (e.g. programmed to take 30ul, but there was only 17ul in the well).

As I understand it the initial volumes in stock wells is largely an assumption based on what the supplier tells them, and varies greatly. Whether volume checking can be performed at all also varies by plate type, and is not always possible (opaque wells, deep wells, frozen and don't want to thaw, etc.). Evaporation, loss during transfers with tips, etc. also play a part during high throughput processing as labwares sit open on robots.

I think volume checking is more practical at the library step for short read, once samples are pooled. Tracking the high numbers of DNA/RNA samples in plate wells earlier in the pipelines is more difficult.

[andrewsparkes]

NB. Flagging wells/tubes as 'exhausted' has been requested for 2 pipelines in short read. To make it flexible maybe it is more of an 'unusable' flag with a reason ('exhausted', 'contaminated', etc.). We are thinking for short read that flag would be at receptacle (well/tube) level and prevent any further Submissions for work being created for that receptacle. It could be automatically set (unusable - exhausted) when we know the liquid handler robot is being set to take all the sample, and could also manually be set for specific situations (like in Bioscan where the insect has gone from a well) in a similar way to current well failing functionality.

[stevieing]

Closed as done.