LIMS master data: specifications, methods and versions

A specification is updated in LIMS and a historical result automatically receives a different assessment. The measured number has not changed, but the applied criterion is no longer the original one. Master data are more than administrative fields: they can determine which test to perform, how to calculate a result and which decision to propose.

1. Identify the objects that govern the process

List the specifications, methods, units, formulas, materials, test plans and workflows actually used. For each, identify authoritative source, identifier, version, owner and dependencies. Distinguish the approved document from its executable LIMS configuration: the correct PDF does not prove that limits and formulas were configured correctly.

A specification may reference several tests; a formula may serve many materials; a unit may appear in both interface and report. Impact assessment must follow these relationships. Include defaults, inactive entries and copied objects: copying can carry over a rule valid in another context.

LIMS selection should examine these capabilities, but this article concerns control of configured use. The laboratory defines scientific meaning; the system must represent it in a verifiable way.

2. Separate definition, approval and activation

Assign responsibility for proposing changes, checking content and configuration, approving and activating the version. Separation must be proportionate to risk and the quality system; preventing role conflicts does not require an identical organisation chart in every laboratory. Technical administration does not itself confer authority to approve analytical limits.

Approval and effective dates may differ. Also define the event determining which version applies: affected material or batch, protocol, request or another authorised criterion. Do not assume a universal rule based only on receipt or testing date. Applicable regulatory requirements, dossiers and agreements may constrain the transition.

For open samples or studies, document the transition decision before applying it. Retain the version actually used for execution, calculation and assessment. Withdrawing a version from future use must not make it unreadable in historical records.

3. Build a useful change record

The following original matrix connects changed objects to required evidence. It is a working framework to adapt, not an identical approval list for every system.

The record retains request, reason, old and new versions, impact assessment, tests, deviations, approvals and activation verification. A generic “master-data update” comment does not identify which results might be affected.

4. Check rules and dependencies before use

In a separate authorised environment, verify lower and upper limits, inclusive or exclusive operators, units, numerical separators and blank-field handling. For formulas and rounding, prepare expected values independently of LIMS, including boundary cases. Distinguish stored values, displayed values and values used for decisions; do not invent a universal rounding rule.

Test both the individual object and the pathway using it. A correct formula assigned to the wrong material is still a defect. An updated specification with a report reading an older version produces inconsistent information. If units or codes change, check instrument interface mapping too.

Plan how to prevent partial activation: missing dependencies, unapproved versions or incomplete configurations must be recognised and handled before use. Then verify the actual outcome in the authorised environment; editorial examples do not authorise testing production systems.

5. Simulated case: a new specification during open testing

A fictitious programme includes tests started under specification S-04 while S-05 has a future effective date. The new version changes a criterion but does not by itself determine which open activities should adopt it. The owner compares the original requirement, reason for change and applicability, then documents the transition rule and affected records.

If the authorised decision retains S-04 for a defined set, those records remain linked to S-04. If reassessment under S-05 is needed, it is recorded as a separate, justified activity preserving the earlier result, criterion and decision. Do not silently replace S-04 in historical data, or automatically retain the old rule where an applicable requirement demands change.

If a master-data error emerges, restrict use of the affected object under procedure, identify potentially affected versions, time interval and records, and assess impact with responsible functions. Controlled correction preserves history and includes necessary tests. Periodic review considers owners, unused objects, dependencies, errors and regulatory or method changes; frequency follows context and risk.

6. Sources and applicability

Sources checked on 2 October 2026. GMP context for human medicinal products; original design examples, no changes to a real LIMS.

• European Commission — GMP Chapter 4, January 2011, effective 30 June 2011, §§4.1–4.5, 4.9 and 4.13–4.16: document control, effectivity, corrections and specifications.
• European Commission — GMP Chapter 6, March 2014 revision, effective 1 October 2014, §§6.7 and 6.15–6.17: methods, calculations and QC records.
• European Commission — Annex 11, January 2011 revision, effective 30 June 2011, §§4, 6, 9–12: testing, accuracy, history, changes and responsibilities. The 2025 proposals remain distinct from adopted texts.