Skip to main content

Search

Search for categories and products

Mining LIMS buying guide

6 sections · 9 min read

A practical checklist for mine-site labs, QA/QC teams and procurement, from instrument data to approved assay certificates.

Definition

A mining laboratory information management system (LIMS) manages sample identities and laboratory work from receipt and preparation through analysis, quality checks and authorised result release. For this buying guide, its boundary is the laboratory workflow, with approved assays handed to downstream geological or operational records.

Last updated

A mine-site lab should choose a LIMS by testing whether it can trace the buyer's own samples from receipt and preparation through instrument results, assay QA/QC and authorised certificate release. Ask each supplier to demonstrate the site's LECO and ICP workflows, failed quality controls, sample handovers and corrected results, then document deployment, support, integration and data-export responsibilities before signing. A software claim about compliance is not evidence that the laboratory is accredited.

01

What a mining LIMS needs to cover

Exploration, grade-control, plant and environmental lab workflows

Write a separate route for each job you need: exploration batches, urgent grade-control samples, plant streams, environmental testing or quarry work. Specify priorities and turnaround expectations rather than assuming one sample queue suits every department. Include the crushing and pulverising preparation route, fire assay work and the ICP or LECO methods you actually run. Keep methods that do not share preparation steps separate.

Start the identity check before lab receipt. Use the exploration drilling workflow checklist to define the field-to-lab handoff, including the core shed's dispatch record.

LIMS, accreditation evidence and geological databases do different jobs

Write separate acceptance criteria for laboratory work, accreditation evidence and the transfer of approved assays to the geological database. A shared sample ID is not enough if a later certificate correction cannot reach the receiving system.

ISO's overview of ISO/IEC 17025 describes requirements for laboratory competence, impartiality and consistent operation, and says accreditation bodies use the standard to assess laboratories. Evaluate how software supplies evidence for your lab's procedures. Do not treat the purchase as laboratory accreditation.

Sample and data handovers from drill rig to laboratory QA/QC and authorised assay certificate.
Illustrative workflow, not a universal lab procedure. Solid arrows show physical movement; dashed arrows show data movement. Failed QA/QC returns to analysis with the original result retained.
02

Buying factors to specify before a demonstration

Give suppliers a requirements sheet with normal and peak sample loads, methods, instrument models, ID formats, handover points and release roles. Mark each requirement as essential or optional. Agree what evidence would constitute a pass before the demonstration starts.

Sample identity, splits, preparation and chain of custody

Require links from the field sample to each coarse reject, pulp and analytical aliquot. Test relabelling, a moved rack and an unmatched bag. Distinguish tracking a location from documenting custody: ask who handed material to whom, when, and with what receipt exception. In JORC Code 2012 Table 1, page 28, sample security is a reporting consideration. This custody checklist is our proposed test, not a prescribed software requirement.

LECO and ICP instrument connections that preserve context

For each LECO model and ICP-OES or ICP-MS workflow, request a serial, file-based or API transfer demonstration. Check IDs, units, dilution factors, detection-limit qualifiers, method versions and flags against the raw source. Include a wrong unit and repeated import. Do not accept a connector count as proof that your exact output is covered.

Assay QA/QC, failed batches and re-assays

JORC Code 2012 Table 1, page 27 asks about quality controls including standards, blanks, duplicates and external laboratory checks, and whether acceptable accuracy and precision have been established. Set test limits using your laboratory's approved rules, not universal insertion rates invented for a software demo. Show a failure and follow the re-assay without hiding the first result.

Certificates, result amendments and downstream data ownership

Agree certificate contents with the lab manager for the work in scope. Test the approver's authority, certificate version, amendment reason and correction notification. Table 1, page 27 also addresses primary-data documentation, verification, storage and assay adjustments. Use that context to request a traceable export; it does not establish mandatory certificate fields.

03

Deployment and configuration choices

Allocate responsibilities in the contract. Neither hosting location nor a local gateway proves offline operation or security. Extend the checks with the mining software vendor security checklist.

Deployment trade-offs to test, not assumed capabilities
ApproachPossible arrangementBuyer check
Cloud or hosted serviceProvider takes agreed server maintenance duties.Confirm connectivity needs, outage procedures, data location, service terms and export access.
On-premise operationSite retains control of local infrastructure.Name owners for patching, backups, restoration and after-hours support. Witness a restore.
Local instrument gatewayA local queue, if supplied, buffers instrument output.Interrupt transfer. Reconcile recovered records and document any manual steps.

Configuration, custom code and migration

Ask which workflows are repeatable configuration and which need custom code. For each custom change, name its maintainer and agree upgrade testing and charges. Rehearse migration with old IDs, retired methods and amended certificates. Reconcile record counts and relationships, then have a lab approver inspect exceptions. Keep unresolved historical data distinguishable from accepted records.

04

Run a demo using your own samples

Build a small, representative test pack

Use permission-cleared, preferably de-identified dispatch records and representative instrument files. Agree scope with the lab manager. Keep demo results out of production decisions. Agree a finish date and run this script.

  1. Receive. Import normal samples, a reference material, blank and duplicate. Include a missing bag and duplicate ID. Retain original IDs, receipt exceptions, operator, timestamps and custody handovers.
  2. Prepare. Split a sample into coarse reject, pulp and analytical aliquot. Move it and change priority. Retain parent-child links, label checks, locations and handover history.
  3. Capture. Import the site's LECO and ICP exports with a dilution, an over-range or below-detection qualifier, a wrong unit and a repeated file. Retain raw sources, mappings, rejected values and repeat-import handling.
  4. Challenge QA/QC. Deliberately fail a reference material or blank and a duplicate against the lab's precision rule. Retain visible failure, release restrictions, original results and the documented re-assay route.
  5. Interrupt. Disconnect the gateway or network during transfer, then restore it. Record queue behaviour, recovery and reconciliation. Investigate every unexplained lost or duplicated result.
  6. Release and amend. Let an analyst attempt unauthorised release, then have an authorised approver issue a certificate. Correct a result afterwards. Retain permissions evidence, approval history, certificate version, amendment reason and downstream correction.
  7. Exit and recover. Export samples, methods, units, results, qualifiers, QA/QC, audit history and certificates in agreed usable formats. Reconcile them against the pack and witness a restore exercise.

Retain evidence, including failed tests

For every step, keep a written pass or fail with a timestamp and named lab approver. Attach exports or screenshots and log manual interventions. Give unresolved gaps an owner and retest date. These tests are an editorial proposal; no software has been demo-tested for this guide.

05

Questions to ask vendors before signing

Which exact instrument models and outputs are included in the quote?

List makes, models, firmware and output formats. Name who builds, tests and maintains each connector, including after an instrument or software upgrade. Ask for a witnessed transfer using your own files before accepting connector coverage.

Can you demonstrate a failed batch using our quality rules?

Use your standards, blanks and duplicates. Require visible failures, restricted release and a re-assay path that retains the original result. Record any manual work and have the lab manager approve the evidence.

Can we trace a missing bag, every split and each handover?

Start with the core-shed dispatch and investigate a receipt mismatch. Follow the pulp and coarse reject separately. Retain operator, time, location and exception records rather than accepting a final status alone.

Who can change methods, release results and amend certificates?

Demonstrate analyst, approver and administrator permissions. Change a method and correct a released result. Check what history survives and who receives the correction downstream.

What works during an outage, and who restores service?

Separate a lost site link from a failed instrument gateway or server. Witness recovery and reconcile queued records. Document where data and backups are held and who answers an after-hours call.

Which implementation costs and acceptance gates are contractual?

Itemise modules, connectors, sites, users, migration, training, validation, upgrades and support. Assign each deliverable an owner and acceptance evidence. Agree which payments depend on unresolved failures being fixed.

Can we export usable records when the contract ends?

Specify formats, timing, charges and access after termination. Reconcile exported sample, method, result, qualifier, QA/QC, audit and certificate records against your test pack, including linked raw files.

Can a comparable laboratory show us its workflow with permission?

Ask about the reference lab's methods, sample load and support arrangements. Ask whether references or reviews were invited by the supplier. Treat their experience as context, not proof that your own acceptance tests will pass.

Implementation cost worksheet

Fill every blank with buyer-agreed scope and quoted amounts. Identify currency, tax basis and the costing period. No prices or savings estimates are assumed here.

Buyer-supplied costs and responsibilities
Cost itemOne-offRecurringOwner and acceptance evidence
Licence, modules, sites and users_______________
Instrument connectors and upgrades_______________
Workflow and report configuration_______________
Custom code and maintenance_______________
Data cleaning and migration_______________
Training and staff backfill_______________
Validation and acceptance testing_______________
Hosting or local infrastructure_______________
Backup and restore exercises_______________
Support and after-hours cover_______________
Version upgrades and retesting_______________
Data export and contract exit_______________
Total for agreed period_______________
06

What the MSR directory documents today

The laboratory information management software listings contain 3 products from 2 suppliers in this category, checked 2 November 2026. That is a directory count, not a census of the market or evidence of suitability. Every review currently in this category is for one product and was invited by its supplier, so the number of reviews here says nothing about how products compare.

Use these buyer questions alongside the listings: can we trace our samples, preserve instrument context, hold a failed batch and notify a corrected assay? Check each answer against your demo records. This guide makes no product-capability claims. Review volume is not an acceptance criterion.

Ready to compare?

See how 3 laboratory information management (lims) products stack up side by side.

Compare 3 Products

Updated · Mining Software