Y25-401 - Store pooling information in MLWH #798
Description
User story
As the Data QC team, I would like pooling information entered by lab staff to be visible in the MLWH, so that it can be shown in NPG software - see parent story for more context.
Who are the primary contacts for this story
Katy, Marina (NPG), James M (Data QC)
Who is the nominated tester for UAT
We could show it to James M so he knows how to query it directly until NPG manage to get it into their software (although perhaps they'd prefer to keep using the Sequencescape UI to find the information, until then).
Make sure NPG are happy too.
Acceptance criteria
See Additional Context for discussion of design.
To be considered successful the solution must allow:
- A way to show a certain sample on a flowcell is "under-represented".
- (Optional) A way to show a pooling weighting (number between 0 and 1) against a sample on a flowcell.
- (Optional) A way to show equivolume pooling was used.
Dependencies
If the design is agreed beforehand, the following issues do not need to be blockers:
- Y25-396 - Mark wells as under-represented limber#2427
- Y25-398 - Transfer pooling info from SS to MLWH sequencescape#5034
Additional context
There has been some discussion with NPG about the best way to store this data. My (Katy) suggestion would be a new generic 'comments' table, which links to iseq_flowcell somehow (1 iseq_flowcell : many comments), and has free text information.
- The main advantage of this is that it can cope with all types of pooling information, as well as having the potential for storing other types of information from the lab in future. It could also be built so that it could be linked to different tables for different platforms - iseq_flowcell for Illumnia, eseq_flowcell for Element Aviti, Ultima, Long Read.
- The main disadvantage of this is that we can't treat the different types of information differently - in NPG's UI, or if they needed to be manipulated somehow. The original (parent) story doesn't ask for them to be treated differently, so I'm assuming this is OK for now. We could always move some information into a separate typed field in future if needed, or add a 'category' field to the comments table.
As an alternative, the simplest way to implement just this story would be to add a new Boolean column (default 'false') to iseq_flowcell called "under-represented".
Various designs were discussed with NPG in Slack thread - feel free to discuss further.
Should also talk to Steve about cross-over with 'annotations' in Traction, and possibly 'flexible pooling'.
Deployment notes
Add any details that should be noted when deploying this feature. For example, is a database migration needed, a specifc rake task or other script that needs to be run, a dependency on another application or service that needs to be released first etc?
These notes are intended to ensure the developers releasing the feature know what needs to be done.
Add any other context or screenshots about the feature request here.