DPL-702 [RVI] What are the options for consolidation stamping of deep well to shallow well plates?

[andrewsparkes]

Description
As Ewan I would like to consolidate the contents of deep well Heron source plates into shallow well destination plates, primarily to free up freezer space to allow new plates to be stored. The destination plates would later act as the sources for a flexible cherrypicking solution to allow a variety of samples to be picked and sequenced for the RVI project.

What are the options and estimated story costs for the stamping of deep well source plates into shallow well plates?

Who the primary contacts are for this work
Ewan Harrison

Knowledge or Stake holders
Lesley s
Scott T
Andrew S

Additional context or information
This stamping would likely be done on a Biosero robot as simple stamp method (A1->A1, B1->B1 etc.), with 1-4 deep well source plates transferred to 1-4 shallow well destination plates in parallel.

The source plates would be in Mongo as plate map data, either fresh ones coming in via GSU or legacy ones already there. No cherrypicking involved so fit to pick flags irrelevant.

We could drive it from the LIMS and get the source plates created in LIMS as the first step, then have a simple Limber pipeline with one transfer step and one Limber bed verification for 1-4 transfers.

Or we drive it from the robot method and use LIMS API endpoints and pull the sample data from lighthouse and just create the destinations in LIMS as we do in Heron (bed verify just that plates have the right prefixes in the robot method).

Or some other option?

[harrietc52]

Options

1. Similar to existing Heron

• robot scans deep well source plate barcode
• creates a destination plate from the source, picking all wells using the 96-tip head rather than the 8-channel
• calls a Lighthouse Service event to create a destination plate in SS
• shallow well destination plate and samples are created in LIMS with a new plate purpose indicating it's a stock plate ready for cherrypicking (i.e. not an LTHR Cherrypick plate)
• use Limber simple pipeline to stamp

Cons:

• would require a new Biosero method and involve the robot arm, plate hotel and barcode scanner in addition to calling a new method on the Hamilton liquid handler which uses the 96-tip head instead of the 8-channel
• would require new Biosero method code, costing development money and time.
• would require a Cherrytrack database
• would need a version of the LIMS source plate lookup endpoint which returns all wells on the plate to be pickable
• how to avoid a lab mistake of loading a deep well plate intended for Heron?

2. Migration + Crawler

Part 1: (Existing data)

• provided with list of deep well plate barcodes
• create migration to create a Stock Plate in Sequencescape, for each of these plate barcodes
• once created in SS, these barcodes could be accessed in Limber
• a simple Limber pipeline could then be used to do the stamp, with a new "deep well plate purpose" as a the start to do the stamp into new destination shallow well plate using just the Hamilton liquid handler and a standard Limber bed verification step
• assume this would be performed only once, if Part 2 is implemented alongside.

Part 2: (New data)

• an addition to current Crawler method
• when plate maps are received, call and endpoint in Lighthouse Service, to create the plate in Sequencescape
• then use the simple Limber pipeline as mentioned above

Pros:

• No Lighthouse Service involved (Part 1)
• No Biosero development involved, just requires a simple stamp method on the Hamilton that R&D can create

Cons:

• Assume we can be given a list of barcode to generate. Otherwise, if doing the migration for all existing plates, there would be many thousands with potential impact on LIMS performance. (Part 1)
• would need to identify/ flag if incoming plate map is intended for Heron or RVI. If automatically creating the deep well plate in LIMS you would then get sample UUID errors if the deepwell was picked for Heron. (Part 2)
• currently no link from Crawler to Lighthouse (Part 2)

3. Limber

• scan deep well plate barcodes in a new Limber screen
• check that they exist in Lighthouse Service
• check that they do not exist in Sequencescape
• create deep well plate in Sequencescape with stock purpose
• then do the stamp, with the new deep well stock plate purpose as a the start, an auto-submission and one step to do the stamp into new destination shallow well plate using just the Hamilton liquid handler and a standard Limber bed verification step

Pros:

• no Biosero involvement
• just uses Hamilton liquid handler that R&D can develop methods for

Cons:

• doesn't fit Limbers architecture, which expects the first step to scan an existing barcode then offer actions, so may be tricky to implement the starting point

4. Lighthouse UI

PSD Preferred Option
Stories: 1 x L, 1 x M

• scan deep well plate barcodes in new Lighthouse UI screen [size: L]
  • attributes (in config): Study, Plate Purpose?
  • user enters list of deep well Barcodes
• check that they exist in Lighthouse Service (must exist to continue, should be code for that)
• check that they do not exist in Sequencescape (or try create and check if fails because plate barcode or samples duplicated)
• create the deep well stock plate in Sequencescape (avoid the existing behaviour of Sentinel to go directly to SS and instead go via Lighthouse Service)
• (optionally: may need to create submission for stamping pipeline, or SSR manual submission)
• then start a Limber simple Stamp pipeline (with auto-submission at start?) [size: M]

NB. Any plate that is created in Sequencescape via this route cannot be then used for Heron picking on Beckman or Biosero, as you would get the UUID error on trying to create the samples in Sequencescape at the end of the robot run.

Pros:

• similar to the existing Sentinel functionality which is to be removed soon
• does not create plates in SS unnecessarily
• flexible, can be used for legacy plates and any newly arrived plates
• does not require a decision to be made by GSU at the point of receiving the plate maps
• no Biosero development needed, R&D can make a stamp Hamilton method
• design would avoid coupling Lighthouse UI to Sequencescape directly
• simple Limber pipeline for the stamp

Cons:

• users have to remember to use the lighthouse screen prior to doing the stamping in Limber (i.e. 2 applications involved)

[TWJW-SANGER]

Thank you everyone, this is very thorough.

I have couple of questions below.

2. Migration + Crawler
   Q. I'm not clear why there needs to be a call from Crawler -> Lighthouse -> SequenceScape to create the stock plate. Could it be simplified to Crawler -> SequenceScape?

3. Lighthouse UI
   Pendantic Q. Is Lighthouse UI the right name for this application, now that Stuart has branched it for RVI & we are hoping this will be a more generic service?
   Q. Checking if the deep well plates exist in SequenceScape.... Does this need to fail and stop the process? Could it be warn and continue? It's not that important as we're not expecting to receive mixed plates of positives & negatives - but allowing it might provide extra flexibility for a more general solution.

Q. The difference between 4 and 3 seems to partly revolve around the ease or otherwise of checking plates exist in the Lighthouse Service before creating in SequenceScape.
I wonder which option is better from a longer term perspective of a more generic robot picking service?
Is there a sense where this is a service for plate reception that may or may not exist in SequenceScape?

[andrewsparkes]

For option 2 you are tied to GSU setting a flag to indicate if a plate should be created in SS. If it is, that plate cannot be run through the cherrypicking robots as you'd get Sample UUID errors at the end of the run (the samples would have already been created). You would also potentially create many deep well plates in SS that would never be used or stamped into shallow well plates. So it seemed a bit 'shotgun' and hope as an option to us, and could generate extra Heron support RTs.
I think Crawler already interacts with the Lighthouse service, which itself already creates SS plates for Heron, and so we didn't want to re-write that interaction and code and couple Crawler and SS unnecessarily together. I think Stuart had another reason too...

The problem with option 3 is we don't know how to start in Limber with that one. Every other use of Limber involves you scanning a labware that already exists (in SS), then Limber shows you what you can do with that labware next. There isn't really a menu or navigation system. How would the user get to an initial screen that lets them scan unknown GSU barcodes? Maybe the initial bit would then have to be in Sequencescape.
Then, it still has to link to the Lighthouse service anyway, as that is the access route to get at the plate map data, which is in the Mongo database. We'd prefer not to couple more applications together?

The Lighthouse UI route (and yes that needs re-naming) would not be specific to RVI, but the initial version would be specific to plates coming in from GSU into our Mongo database. It couldn't just receive any non-Sequencescape plate. Although you could design it in a flexible way with a 'source' dropdown choice to allow for other sources of plate map data later. It de-couples the source plate import into Sequencescape from the (very) standard stamping step we want to do after in Limber.

We want to do the stamp using Limber for now because it means R&D then just need to create a simple method on the Hamilton robot, and we can build the stamp step easily in Limber and have a standard Limber bed verification for checking the Hamilton labware placements (esp if they want to do 4 at a time). Just some config to set this Limber pipeline up so not a big story.

Future: A stamp is the simplest of cherrypicks. So maybe this would be an option in the more flexible cherrypicking solution we develop later. Have to consider it does use a different 'head' on the robot (96 tips all at once rather than the more flexible 8-channels more suited to custom cherrypicking).