Configuring Bika for Fire Assay

Background

Bika 3 featured sample preparation workflow, originating from DNA/RNA extraction steps and measurements before genetic analysis, and exploited in geochemistry labs as Bika Fire Assay where any number of preparation steps precede analysis by AAS

Sans further sponsorship the preparation workflow became dormant though still lives in Bika fork for Bioinformatics, Baobab LIMS

Fire Assay

Metallurgists have used the Fire assay methods for thousands of years to extract precious metals from ores. It remains the same to this day and considered as the most accurate and reliable method for determining precious metal content in labs

Samples are crushed, pulverised and weighed, then mixed with a lead based flux in a clay crucible and heated at high temperature in a furnace. Droplets of lead collect the precious metal as they descend through the sample

After cooling down, the lead alloy button at the bottom of the crucible is cupellated, heated in a porous cup, and the lead and other impurities removed through oxidation, leaving a metallic bead

The bead is dissolved, in aqua regia most often, and the precious metal concentrations determined by any of AAS, ICP-OES or ICP-MS

Preparation Steps

These are separated in the configuration by setting up the preparation steps in a Preparation Analysis Category with the highest sort order. This will see them always grouped together at the top of sample views and COAs

Sorting these steps in order of execution in the Category gives users a quick overview of how far a sample has been processed

Some preparation steps also have measurements captured like weights and % and particle size distributions

Analysis Specifications can be applied, and e.g. a sample too coarse will be reflected as Out of Range

Preparations that require no measurements are configured with a Results Option of ‘Completed’ or ‘Done’ which the user toggles when the step is completed - the date time and username are captured

Samples for a specific preparation step can also be grouped together on Worksheets for ease of management, say Crushing or Firing a group of samples

Analysis. Keywords

Various factors influence how the prepared sample is analysed, client preference, selected Profile, analyte concentration etc. and the prepared samples proceed along its corresponding route

The result for the same analyte thus, say Au, can be achieved using different methods and are best managed in separate Analysis Services (ASs). They might also differ in price, unit, instrument used etc.

ASs are uniquely identified by instrument importers using their unique keywords, e.g. the wavelength used by the instrument in its results export, Au24280 for Au, and multiple instruments often use the same

This can be resolved in the LIMS through AS keywords that include the AS’ method to differentiate between them, e.g. Au24280_GFAAS, Au24280_ICPMS, Au24280_XRF

Going out from the assumption that the same element will not be requested more than once per Sample, the importers are coded to find the AS on its keyword’s leading characters only, here Au24280

In the rare case that more than one Au24280* Analyses are found, nothing should be imported and the analyst alerted to the duplicate. Labs soon learn to do these tests on two different sample partitions

Configuration

Configuring this number of Analyses in the LIMS is hazardous - imagine the full table of elements analysed in a few different ways, using fire assay, aqua regia or gravimetric methods, and analysed on flame or graphite furnace AAS, ICP-MS, ICP-OES or XRF instruments

At sample registration time these can thankfully be managed using Analysis Profiles for the tests frequently ordered together, and on Worksheets with templates preconfigured for instrument trays, including QC samples

Using the latest setup data upload formats and code, goes a long way and getting out of the blocks is achieved a lot quicker than with traditional LIMS. It is important to get these absolutely right, else all of the ASs will have to be edited manually (or scripted for)

Conclusion

Coded workflow enforcements - sequential state changes for samples in preparation and restrictions on further actions available per state - will improve on the above configuration based solution, testament to Bika’s flexibility

But for analysing ores no? Analysts physically cannot analyse raw samples. In other labs with less tangible Sample material, e.g tubes of clear liquid in different preparation states, it is well required for easier management

Bika inherits Plone’s role based workflow engine which can already be manipulated in the system’s management interface. Surfacing this configuration in a more friendly coded way is well within reach where needed and budget allows. And that does not have to be much

  Demo Access