Automatic Pooling Based on a Sample UDF/Custom Field
Last updated
Last updated
In some facilities, when samples are initially submitted into BaseSpace Clarity LIMS, it has already been determined which samples are combined to give pooled libraries. In such cases, it is desirable to automate the pooling of samples within the protocol step. Doing so means that the lab scientist does not have to manually pool the samples in Clarity LIMS interface. This automatic pooling saves time and effort and reduces errors.
This example provides a script that allows 'autopooling' to occur. It also describes how the script can be triggered, and what the lab scientist sees when the script is running.
The attached script relies upon a user-defined field (UDF) / custom field, named Pooling Group, at the analyte (sample) level.
This UDF is used to determine the constitution of each pool. This determination makes sure that samples combined to create a pool having the name of the Pooling Group value all have a common Pooling Group value.
For example, consider the Operations Interface (LIMS v4.x & earlier) Samples list shown below. The highlighted samples have a common Pooling Group value. Therefore, we can expect that they will be combined to create a pool named 210131122-pg1.
In this example, the Pooling protocol step is configured to invoke the script as soon as the user enters the step's Pooling screen.
The EPP / automation command is configured to pass the following parameters:
-l
The limsid of the process invoking the script (Required)
-u
The username of the current user (Required)
-p
The password of the current user (Required)
-s
The URI of the step that launches the script - the {stepURI:v2:http} token (Required)
An example of the full syntax to invoke the script is as follows:
When the lab scientist enters the Pooling screen, a message similar to the following displays:
When the script has completed, the rightmost Placed Samples area of the Placement screen displays the auto-created pools:
At this point, the lab scientist can review the constituents of each pool, and then complete the protocol step as normal.
The main methods of interest are autoPool() and getPoolingGroup().
The autoPool() method harvests just enough information so that the objects required by the subsequent code in the method can retrieve the required objects using the 'batch' API operations. This involves using additional code to build and manage the cache of objects retrieved in the batch operations, namely:
cacheArtifact()
prepareCache()
getArtifact()
After the cache of objects has been built, each artifact is linked to its submitted sample. The getPoolingGroup function harvests the Pooling Group UDF value of the corresponding submitted sample.
The script now understands which artifacts are to be grouped to produce the requested pools. An appropriate XML payload is constructed and then POSTed to the ../steps/<stepID>/placements API resource.
The attached file is placed on the Clarity LIMS server, in the /opt/gls/clarity/customextensions folder.
The Python API Library (glsapiutil.py) is placed on the Clarity LIMS server, in the /opt/gls/clarity/customextensions folder. You can download the latest glsapiutil library from our GitHub page.
The example code is provided for illustrative purposes only. It does not contain sufficient exception handling for use 'as is' in a production environment.
autopoolSamples.py:
