Developer Documentation/inventory/
Contents |
Inventory Subsystem Documentation
General use of Master, Detail and Control Table
Into ATiM, a lot of objects have information recorded both into a master table and a detail table.
In general, we build this kind of structure when a part of the fields of an object can only be attached to this object and the other part of the fields can be attached to a parent object being the same than many children objects.
For example, when we talk about storage (ex: box, freezer, incubators) we decided that barcode, temperature, parent_id, etc are fields attached to the storage parent object. These fields are recorded into the master table (storage_masters table).
In the case of box, we don’t have to track specific information, so we don’t use a details table, but in the case of an incubator, we could track specific information like the percentage of oxygen, the percentage of carbonic gaz. In this case we record the additional set of data into a details table (std_incubators).
Note: ‘std_’ for storage details.
According to the type of a children object, the ‘_controls’ table will be used to define both: - Which details table should be used to record specific children object field. - Which form alias should be used to build an application form.
Ex: See storage_controls table, fields detail_tablename, form_alias.
Inventory
General structure
The inventory data are stored in 3 levels:
- Collection to gather general information attached to all samples collected at the same time for the same participant (ex: collection date, site, etc).
- Sample to track general information of a same set of aliquots containing exactly the same product (ex: 5 heparine tubes containing the same blood (same participant, collection date, same tube type) or 5 tubes of the same DNA extraction). At the sample level, we record information that could be attached to all aliquots (ex: creation date, parent sample for a derivative, used SOP, Person who created the derivative, etc).
- Aliquot to record information specific to one aliquot. For example, if we split a DNA extraction (one sample) into 2 tubes and we add water in one of these 2 tubes, the concentrations will be different. So same sample but 2 different aliquots information.
As defined in the first part of the doc, we use a sample_controls table for sample and an aliquot_controls table for aliquots.
Sample, Specimen and Derivative
Note: In the past we decided that all products taken directly from human body (like tissue, blood, ascite, etc) will be called Specimen and all products created from another product will be called Derivative (ex DNA extraction). Both Specimen and Derivative were called Sample. Actually, we decided to Specimen to Sample and keep Derivative for Derivative. This change as been done on data displayed in screen, but the old definitions have been kept in code and DB: That could be confusing and should be kept in mind.
DB - Code Form
Sample Specimen Sample
Derivative Derivative
So into the sample model we consider 2 categories of sample: Specimen and Derivative.
Both specimens and derivatives can have details information meaning that sample model is split as follow: Sample Details is a children object of either a derivative or specimen object being children objects of a sample master object.
This model explains we have: - sample_masters table, - specimen_details or derivative_details table - sd_spe/der_xxx tables for details information.
Note: sd_spe_ for details of a specimen sample and sd_der_ for details of a derivative sample.
Derived_sample_links and sample_aliquot_control_link
To be sure that no user will be able to create a cell culture from plasma, we record data into derived_sample_links table to define which derivative sample type could be created from a parent sample type. (Each arrow displayed into the following diagram match a record into the table defined above.)
Same think for aliquot, we limit the type of aliquot a user could create for a sample type recording information into sample_aliquot_control_link.
All new relation that should be created for a new bank should be first created in CTRNET ATiM application and then used by the bank.
Storage
Storage model uses also masters, controls and details table.
According to the type of storage we define additional properties recorded into storage_controls used to define the layout of the storage (ex box having position from 1A to 9I), to define if we talk about surrounding temperature (box, etc) or set temperature (ex: freezer).
Note 1: There is an additional field called form_alias_for_children_pos to define the form the system should display to set the position of a children storage stored into the storage. This field accept values: NULL, std_1_dim_position_selection, std_2_dim_position_selection.
Note 2: There is no control on the parent children links meaning that user can store a freezer into a box. It’s actually the responsibility of the user to create correctly the storage
Layout
Managed by fields: - Coord_x_title è Title of the 1st dimension (column, shelf, etc) - Coord_x_type è Type of the value (integer, alphabetical, list) - Coord_x_size è Size of the values list - Coord_y_title, è Title of the 2nd dimension (row, etc) - Coord_y_type è Type of the value (integer, alphabetical, list) - Coord_y_size è Size of the values list
X for first dimension, Y for second dimension. Note 3 dimensions is not currently supported.
Supported type-size combinations:
_type _size Comment
NULL NULL Un-existing dimension.
List NULL User will define it’s own allowed storage coordinate value using the coordinate tab displayed for a selected storage (Good if user adds or remove shelves all the time into a freezer).
Integer Value Will allow system to build automatically list of integers (ex: Integer-9 for value from 1 to 9).
Alphabetical Value Will allow system to build automatically list alphabetical values (ex: Alphabetical-9 for value from A to I).
Temperature
See set_temperature field.
Short label and selection label
A short label is a readable set of letters and numbers written on a storage (ex:22).
The selection label is the concatenation of the short labels from the root storage to the last children storage.
| Storage | Short Label | Selection Label |
|---|---|---|
| Room | R1 | R1 |
| ->Freezer | F1 | R1-F1 |
| ->->Rack | 1 | R1-F1-1 |
| ->->->Box | 22 | R1-F1-1-22 |
| ->->->Box | 23 | R1-F1-1-23 |
| ->->Rack | 2 | R1-F1-2 |
| ->->->Box | 24 | R1-F1-2-24 |
