When initiating the execution of a program on an instrument, it is common to supply a list of samples intended for processing during the run as part of the StartProgram() method’s input arguments. Samples within this context are typically identified and tracked using their unique sample identifiers. These sample identifiers can take various application-specific or domain-specific formats, serving as representations of the materials (such as fluids, solids, cells, etc.) to be processed.

However, in most cases, the sample identifier itself cannot be directly associated with the sample, but rather it may be linked to a sample container. This container, whether it's a vial or a multi-well plate, encapsulates one or more samples and can be identified using human- and/or machine-readable codes like barcodes, QR codes, RFID, and similar technologies.

In real-world scenarios, there isn't always a straightforward one-to-one correspondence between a container's code and the sample identifier of the contained sample. Several variations exist, such as:

A single identifiable container containing multiple samples, including additional fluids like calibration standards or reagents. An example is a multi-well plate.

Certain processing steps within a workflow using a specialized instrument might require one sample to be divided among several containers due to volume constraints, with the possibility of pooling these samples back together at a later stage.

To address these diverse scenarios, the SampleInfoType offers multiple properties that can be better understood through illustrative examples provided in the subsequent sections.

image025.jpg

Figure 21 – Typical multi-well plate

Figure 23 illustrates a commonly used 96-well format multi-well plate—utilized in numerous laboratory processes and instruments. Each plate, functioning as a sample container, possesses a distinct identifier, such as the barcode visible on its front surface. The wells within the plate, designated to accommodate the samples, are differentiated by their respective row and column positions. This grid-like arrangement is akin to the cells in a spreadsheet, albeit with a reversed schema where rows are denoted by letters and columns by numbers.

An example is provided below, presenting an instance of a Samples list that serves as an argument for the StartProgram() method. In this scenario, each well contains an individual sample, as detailed in the subsequent table:

Table 149 – Example multi-well plate with individual samples

Array Index

ContainerId

SampleId

Position

CustomData

0

1118642

S0815001

A1

Sample

1

1118642

S0815002

A2

Sample

..

..

..

..

..

95

1118642

S0815096

H12

Sample

As all samples are housed within a single container, each element within the Samples list shares the identical container identifier. Nonetheless, individual samples are distinguishable through their unique sample identifiers, coupled with the respective well positions they occupy within the container. In this example the implementor decided to utilize the SampleInfoType structure’s CustomData property to communicate the role of the fluid within each well from the application to the instrument. The specific usage of this attribute, however, extends beyond the scope of this LADS specification. Detailed specifications are likely to be outlined in a complementary specification utilizing LADS. Such specifications could potentially furnish more detailed information, possibly conveyed in formats like JSON.

The next example depicts a situation in which individual samples needed to be distributed across multiple wells to accommodate volume limitations. Additionally, calibration standards are introduced in this context.

Table 150 – Example multi-well plate with partial samples

Array Index

ContainerId

SampleId

Position

CustomData

0

1118642

S081500A

A1

Sample

1

1118642

S081500A

A2

Sample

2

1118642

S081500B

A3

Sample

3

1118642

S081500B

A4

Sample

..

..

..

..

..

94

1118642

Cal0

H11

Standard

95

1118642

Cal1

H12

Standard

image026.jpg

Figure 22 – Typical conical tube

Figure 23 illustrates a typical conical tube commonly employed for various purposes such as sample storage in freezers or during processes like centrifugation. These tubes are designed for singular sample use. A distinct container identifier can be assigned during manufacturing or applied later using a printed label provided by the user. In cases where a label is used, it might also directly display the sample identifier of the contents, although this isn't always guaranteed.

Table 151 – Example Samples list with conical tubes

Array Index

ContainerId

SampleId

Position

CustomData

0

eB0000031725

S0815042

1

Sample

1

eB0000031726

S0815043

2

Sample

..

..

..

..

..

31

eB0000031856

S0815073

32

Sample

The table shows an example of a Samples list as it might be used to initiate a separation run on a centrifuge. Each tube is accompanied by its unique container identifier and individual sample identifier. Given the vital role of balanced mass distribution in a centrifuge's rotor for optimal functioning, the orchestrating application (e.g., LIMS or ELN) for this process step recommends specific tube placement within the rotor. This recommendation is founded on the application's knowledge of the individual sample weights.

It's important to highlight that the precise meanings and formats of the Position and CustomData properties fall beyond the scope of the LADS Companion Specification. However, forthcoming companion specifications utilizing LADS might delve into these aspects in greater detail.