GPL-674 Prevent merger PCR plates into pool with different barcode sets

[rl15]

User story GPL-674 | As R&D (Lesley) I would like to prevent the merger of LTHR Lib PCR 1 and LTHR Lib PCR 2 plates into a LTHR Lib PCR pool plate, which are tagged with different barcode sets. This will prevent samples being deplexed incorrectly post sequencing.

Who are the primary contacts for this story Lesley S

Acceptance criteria

Token for conversation to have

To be considered successful the solution must allow:

• [ ] add a list of acceptance criteria here
• [ ] ...

Dependencies This story is blocked by the following dependencies:

• sanger/#

Additional context Discussed in stand up on 2nd October. This issue impacts on the 96 tailed workflow 'blue light' pipeline. Agreement can roll out to production without it - risk managed via process SOP until GPL-674 released.

[JamesGlover]

We should be able to detect this behaviour at the point where a tag plate is selected, rather than at the point of pooling. This would avoid wasting a tag plate, and any material that was transferred into it.

A lot of the necessary infrastructure to support this is already in place, mainly to support the behaviour of ensuring that we don't use the same tag set twice.

app/assets/javascripts/tag_by_tag_plate.js:68-74 sets up the tag plate validation:

        new validator(function(t) { return t.qcable.state == 'available'; }, 'The scanned item is not available.'),
        new validator(function(t) { return !t.template.unknown; }, 'It is an unrecognised template.'),
        new validator(function(t) { return t.template.approved; }, 'It is not approved for use with this pipeline.'),
        new validator(function(t) { return !(t.dualIndex && t.template.used && t.template.dual_index); }, 'This template has already been used.'),
        new validator(function(t) { return !(t.dualIndex && !t.template.dual_index); }, 'Pool has been tagged with a UDI plate. UDI plates must be used.'),
        new validator(function(t) { return !(t.dualIndex == false && t.template.dual_index); }, 'Pool has been tagged with tube. Dual indexed plates are unsupported.')

In particular new validator(function(t) { return !(t.dualIndex && t.template.used && t.template.dual_index); }, 'This template has already been used.') adds the behaviour to detect duplicate uses.

The new behaviour isn't an inverse, as: 1) t.dualIndex indicates that the plate is a cross-stock-plate pool (ie. will be pooling two plates with different libraries), and we'll need to enable template clash detection. In this case dualIndex is false. 2) We won't have any templates used on the first plate, so need to make sure we approve our template if none have been used. (This is a little trickier, as we currently just set a flag on each of the approved templates.) 3) We probably don't care if t.template.dual_index we just want it to be the same.

Where t.template comes from

• A bit of abstraction going on here to support both UDI plates and i5 tubes. (The latter may no longer be needed. Last time I checked with operations they were exceedingly rare, but discontinuation depended on resolving some issues with the UDIs which I think have now been resolved)
• When we fetch a template we look it up in either: SCAPE.tag_plates_list or SCAPE.tag_tubes_list as appropriate.
• We look up the template not the tube itself
• SCAPE.tag_plates_list is currently a global namespace (ugh) populated through the erb file itself. app/views/plate_creation/tagged_plate.html.erb
• And the actual data to go in here comes from app/models/labware_creators/tagging/tag_collection.rb (The creator itself has delegate :used?, :list, :names, to: :tag_plates, prefix: true in case you were wondering)

[KatyTaylor]

@Lesley84 or @JamesGlover can I just clarify the requirements please? See screenshot below. I initially thought the requirement was to verify that when specifying the tag plate on this screen, the "template" chosen is the same, for Lib PCR 1 and Lib PCR 2? (i.e. 'TSsc384') But I don't think that's quite right?

[JamesGlover]

That was my understanding as well, or at least this is the point where it takes would make most sense. Hope my comment didn't cause confusion.

Edit: Ahh, there's a 96 well version as well, which has more available templates.

[Lesley84]

Hi both, yes that's correct. The 384 only has one option at the moment for the tag set (TSsc384) so different tag plates being applied to PCR 1 and 2 can't happen, but there are multiple options for the 96 line, which could cause this issue. I hope that makes sense.

[KatyTaylor]

Ah got it thanks, yes I was confused because I saw that TSsc384 was the only option for the 384 version, didn't look at the 96.

[KatyTaylor]

Struggling to figure out what an all-encompassing rule can be for this extra validation. Currently I've got:

When choosing a tag plate for Lib PCR 1 or Lib PCR 2:

• It looks at the 'submission pools' for your plate
• It looks at any tag plates already used on the other plates in the submission pools
• Errors if the tag plate you are currently trying to use is different from those already used

It seems to work OK for this scenario, but I think it will break the existing validation around trying to prevent tag clashes. @JamesGlover did you have any ideas as to what the filter should be? Is dual_index relevant? Not sure I quite understand what's going on there.

[JamesGlover]

Its probably safer to explicitly toggle the behaviour by a configuration option for the Lib PCR 1/Lib PCR 2 plate specifically (ie. a purposes.yml config option or even a separate creator class).

I think you could also turn it on in the event dualIndex was false, and not mess up any critical-path flows, but you could end up triggering the behaviour accidentally. (Say if a user of another pipeline initially used the wrong template, then went back and changed their mind)

t.template.dual_index indicates if a template contains both i5 and i7 tags. It isn't especially relevant in this scenario. It dates from when we had two potential means of introducing i5 tags: 1) From a single tube, where a single i5 got applied to the whole plate, wherea the i7 came from a plate 2) From UDI plates (the current approach) where both i5 and i7 tags were in the plate together.

The two processes ran together in parallel for quite a while. I'm assuming the i5 tubes are no longer used, although last time I tried to get confirmation Jamie didn't want the functionality stripped out just yet. (This was about a year and a half ago though)

We do have a potential issue in future if we ever face the following workflow

  p1     p2
 /  \   /  \
p    p p    p
|    | |    |
t    t t    t
 \  /   \   /
  p1'    p2'
    \   /
    Merged

As then submission pool becomes insufficient, and we'll need much finer grained information. But I can't see a simple way of handling that at the moment, so I guess we'll wait to see if its ever needed.

[KatyTaylor]

OK thanks I'll have a look at the configuration route options.

Think I get what you mean by your bunny ears diagram. Is the following correct? So you'd have to ensure the same template within the bubbles but different templates between the bubbles?

       p1                             p2
 /              \               /              \
p                p             p                p
|                |             |                |
t (template1)    t (template1) t (template2)    t (template2)
 \              /                \             /
       p1'                             p2'
           \                       /
                      Merged

[JamesGlover]

Yes, exactly.

[KatyTaylor]

@Lesley84 Hi, this story is in UAT now. Would you be able to check it works as expected? Do you need any help setting up data or anything?

Thanks very much