DPL-968 Research - intermediate plates as input plates

[KatyTaylor]

Description
At the 2nd and 3rd entry points to the pipeline, we will want a plate to be both an intermediate plate in the broader pipeline, and an input plate to the next step in the pipeline. This has been an issue in the Bioscan project. Research is needed to decide how to configure these plate purposes.

Who the primary contacts are for this work
Katy

Knowledge or Stake holders
Andrew

[KatyTaylor]

There was a similar decision in the BioScan project - a plate coming in part way through the pipeline from a different source, and whether to represent that as the same plate purpose as the one in the pipeline, or a new plate purpose. Illustrated below:

In BioScan, the decision was made to use the same plate purpose for both plates. Pros and cons of this approach listed out below:

Pros	Cons
Simpler pipeline config - less branching.	In Bioscan the plate had to be marked as 'stock plate' true but 'input plate' false which caused complications with determining plate state.
Makes sense as we want to treat them the same way.	Harder if need to treat them in different ways in the LIMS in the future, if needed.
Makes bed verification easier when combining plates of both types, as current bed verification code does not allow a list of types as sources in a bed.	Can't differentiate between these plates (visually, or for reporting), which have actually come from different sources.
In Bioscan it was less confusing for the user to have a single plate purpose (for SOPs, training etc.). The two routes created a physically identical lysate plate, one made by faculty manually, one made with the help of robotic automation.	We wanted to have an automatic submission for Bioscan on the same plate, but found it to difficult to implement that extra functionality on an already complex plate.
In Bioscan the plate is quad-stamped in the next step, so only having one purpose as the sources kept that simple and standardised.	Limber displays multiple suggested action, bed verification and file export buttons on this plate, which is confusing for the user (might not all be relevant to the route by which this plate was created).

Technically, the plate state issue turned out to be a big challenge. The plate purpose had to be configured as stock_plate true and input_plate false, with a special new plate purpose class called PlatePurpose::AdditionalInput. This class determines plate state differently depending on whether the plate has ancestors (the plate has been created via the Beckman robot route where it is an intermediate plate) or not (it was made manually by faculty).This was done to solve issues with the plate state, because:

• Intermediate plates are created with a labware creator (the Bioscan one adds control wells)
• Intermediate plates are regarded as 'passed' when the transfer requests into them are 'passed'.
• Input plates are created via sample manifests
• Input plates become 'passed' once a Submission has been created on them (their wells all have active requests)
• In Bioscan we needed the plate state to be determined differently depending on whether the plate had come through the previous automation assisted Lysate prep pipeline steps, or whether it had come directly from faculty having been made manually. And the next step in the library prep pipeline is a quad stamp step combining 4 plates (created either by either route).
• Submission templates are typically linked to one plate purpose (although a list is possible) and the state of the plate is a factor for submission creation

In 007c, the decision has been made that plates coming from different routes will not be combined together (unlike in BioScan). Because of this, and weighing up the pros and cons, I think we should create two separate purposes for them.

• The new plates coming into the pipeline should be configured as input plates - this will mean that they are in a 'passed' state (ready to progress down the pipeline) when they have active requests on their wells.
• The plates coming from previous pipelines should not be configured as input plates - this will mean that they are in a 'passed' state when the transfer from the previous plate into them has been completed.