Y24-106 Tube Rack Support for additional Plate barcodes

[yoldas]

User story As PSD, we would like to support for printing an additional plate barcode for the versioned tube racks proposed in Reuse of TubeRacks document.

Who are the primary contacts for this story Abdullah, Katy, Andrew

Who is the nominated tester for UAT TBD

Acceptance criteria To be considered successful the solution must allow:

• [ ] Allow generating and printing an additional Plate barcode for a TubeRack.

Dependencies This story is blocked by the following dependencies:

• 1482

References This story has a non-blocking relationship with:

• 1388

• 1715

Additional context The versioned tube rack model is researched in DPL-1011 Re-use of tube racks and the model is summarised in the Google Document DPL-1011 Re-use of tube racks

This story is part of re-implementation of DPL-914 Create tube rack containing banked PBMC tubes (Defrosting) using the versioned tube rack model.

Story relationships are shown in the Lucidchart diagram TubeRack Stories .

It is not possible to release the implementation of this story in isolation.

Note that there should not be a need for generating and printing a Plate barcode for a TubeRack because it has already an etched barcode. However, the existing story, DPL-914, implements the LRC PBMC Cryostor TubeRack as a Plate and printing a Plate barcode is part of the process. When it is implemented using the TubeRack, if an additional (Plate) barcode is required, there is no UI to generate an additional barcode.

[KatyTaylor]

I think this should work already?

[KatyTaylor]

How are you imagining this would look in the UI?

I think, when the epic Y24-113 is released, we could get the users to start using the etched barcodes rather than printing out plate barcode labels and sticking them on the rack - so we wouldn't need this story.

Another alternative is that for the first iteration, we don't save the etched barcode against the tube rack (when implementing Y24-104 Tube Rack Defrosting Uploads) - we keep using the plate barcode - and then there is no change for the user. We could then do a small story to save the tube rack barcode, which we could coordinate with the user.

Let me know what you think. Just trying to avoid having to make a UI change in the generic printing form, for a transient requirement.

[yoldas]

If we are always generating an additional Plate barcode for this case, it can be done programmatically. If it is on demand, I imagined a simple form to generate an additional barcode in Sequencescape. My preference is not to generate an additional Plate barcode at all.

I think, we can put this story directly on hold instead of deleting because it is capturing an existing use case and it needs coordination with the user.

If we have two barcodes in LIMS (etched and plate): I experimented this a little bit on UAT before. I created a new barcode using Baracoda (SQPU-85894-D) and then added to an existing TubeRack (SA00834180) on UAT for thinking. Simply, the Labware with id 26471204 has two barcodes. I did not test which one will be printed. If we are printing the latest barcode always, there would not be any change to printing form.

If we have one barcode in LIMS (plate) If we did not use the etched barcode, we would continue with the Plate barcode, but we would have an exceptional case in the versioning logic where we assign the plate barcode to the latest version of tube racks. We would be carrying the Plate barcode to the new versions instead of the etched one. Again, there would not be any change to printing form.

[KatyTaylor]

Yep, my preference is to move away from using Sanger barcodes for these tube racks, and to start using the etched barcodes - that's one of the benefits of doing this chunk of work.

So we can mark this story as 'won't do' or something. And we just need to remember to coordinate with the users before releasing Y24-113, because it will require a change in lab protocol.

[yoldas]

I have added the On Hold label to this story following Katy's comment.