DPL-812 Transfer PBMC bank data to BioResource team

[KatyTaylor]

User story As a BioResource team member receiving a FluidX tube rack with PBMC cells for banking, I would like to receive information about the contents of those tubes, so that I know what I've got in storage.

Who are the primary contacts for this story Laura L, Katy

Who is the nominated tester for UAT Laura L, Lesley

Acceptance criteria

• [ ] Data should include:
  • donor
  • parent barcode (vacutainer)
  • fluidx barcode (tube that it's being transferred in)
  • extraction & freeze date (both should be the same) - creation date of the fluidx tube
  • which tubes are destined for sequencing vs contingency
  • cell count
  • viability
  • volume
  • study (needed for when uploading into Titian)
  • collection site

Dependencies This story is blocked by the following dependencies:

• https://github.com/sanger/limber/issues/1310
• https://github.com/sanger/limber/issues/1314

Outstanding questions UX of telling SS what tubes you want the report for.

• Copy paste list from manifest?
• Batching?
• Scan individually? (will be scanning each anyway to do activity logging ("delivered") and maybe recording Labwhere location.

Additional information This story was written but never implemented for Cardinal, with the same intentions: https://github.com/sanger/limber/issues/878

[LauraLetchford]

We'll also need cell count per tube, and viability. And we possibly need volume (unless it is a fixed volume every time)? And ideally study and site (collected by?), we could look these up in Titian based on parent barcode but it would be easier if they are in the data from LIMS. We may be able to drop the rack and position in rack data dependent on the logistics of the freezing process (taken out of racks and put in coolcells?) and the handover of these from SeqOps to BioResource. This needs to be discussed more, probably with Fran and Sameena in the discussions.

[KatyTaylor]

@LauraLetchford thanks, you said on https://github.com/sanger/limber/issues/1313 that you need cell count to send that info back to the collaborators - is that also the reason that you need to record viability and volume?

This might be more a question for Lesley, but how would we (Limber) know the volume? If it's not fixed, would it be that the robot transfers a fixed volume from each source well, so we could do "transfer volume x number source wells"?

If you dropped rack and position, would you just be going off the tube barcode? I guess you don't need it anyway because you've got the tube barcode - it's just for time-saving?

[KatyTaylor]

@LauraLetchford oh sorry a couple more questions! How would we calculate the viability - the average of the source wells or something? And when it says "parent barcode" - that refers to the original vacutainer tube barcode that the blood arrived on site in, right?

[LauraLetchford]

Yes collaborators ideally want to know viability and volume too, we also have to enter a volume in Titian Mosaic when we create the tubes (although we can put an estimate). I think the Cellaca file should contain viability (%) as well as cell count. It would probably make most sense to average the viability across the wells that go into the tube. Yes we'd just go off tube barcode if we dropped rack and position, and if we did keep rack and position it would possibly be timesaving but also allow more auditing of the data when it goes between systems. You're right parent barcode is the original vacutainer tube barcode.

[KatyTaylor]

Update on whether the tubes will be stored in tube racks or cool cells for the transfer to BioResource (email from Abby, 15/08/23):

When the samples are stored in the Bioresource team they will be in tube racks. We haven’t quite determined the handover process yet. I think if we end up using 1ml fluidX tubes the cool cells become more feasible, otherwise the ones we currently have aren’t the best fit for the 0.3ml tubes to be physically handed over in. Cardinal were storing the tubes in their freezer temporarily in cool cells then racking them and passing the rack to the Bioresource team. This means they had to pass over a scanned rack layout. I think we still need to discuss whether we would do the same or let Bioresource scan tubes into a rack from the cool cell as we originally envisioned.

[andrewsparkes]

The tubes now have 2 values stored in their custom_metadata: tube_rack_barcode -> the barcode of the rack the tube was in at the point of transfer from the PBMC Bank plate tube_rack_position -> the position of the tube within the rack at the point of transfer from the PBMC Bank plate

So you can fetch the rack barcode and position from the tube custom_metadata

[KatyTaylor]

@StephenHulme notes based on our discussion just now:

• https://github.com/sanger/limber/issues/1331 was intended to make this story easier, by moving some of the relevant data onto the child tube rather than the parent plate.
• @andrewsparkes raised a potential issue with https://github.com/sanger/limber/issues/1331 - if they repeat QC (Cellaca cell counting) on the PBMC Bank plate, after creating the child tubes in Limber, the tube metadata will contain the old QC values, not the new QC values (cell count, viability).
• Because of above, when generating the report, it might make more sense to pull the (latest) QC data directly from the qc_results table against the parent plate, rather than using the data saved in https://github.com/sanger/limber/issues/1331
• Also, based on recent discussion with Lesley in Slack, volume can be hardcoded to 135ul, even though it might occasionally be a bit lower if they've had to repeat QC.
• Therefore, I think a new approach for this story is best:
  • Pull cell count and viability data directly from qc_results table against parent plate
  • Hardcode volume to 135ul in this report
  • This will make https://github.com/sanger/limber/issues/1331 obsolete and the code will be removed
• If the above proves v tricky, we can also revert to previous approach.