Skip to main content

LabWare Sample Login & Test Assignment: CSA Validation Guide

How to validate the LIMS function that determines everything downstream — specification-driven test plan assignment, sample identity binding, chain-of-custody timestamps, and the controls separating routine, retest, and stability sample login.

Written by: Sundar, Director, GoVal
GAMP 5 Category 4 CSA · FDA Final Guidance 2025 21 CFR Part 11 21 CFR Part 211 IQ / OQ / PQ
The Core Scope Question

Why does sample login carry more downstream validation weight than any other LIMS function?

Sample login is where the system decides what tests will be performed and against which specification — every downstream result, OOS evaluation, and CoA inherits this decision. A wrong test plan assignment at login is invisible until someone notices a missing test weeks later. Validation must focus on the specification-to-test-plan binding logic and sample identity controls, not just confirming the login screen saves data correctly.

The Failure Mode Unique to Sample Login

An Incorrect Test Plan Assignment Doesn't Generate an Error — It Generates a Complete, Internally Consistent, Wrong Record

Most LIMS validation failures other modules guard against are detectable: a result outside specification triggers a flag, an audit trail gap is visible on inspection. A test plan assignment error at sample login is structurally different — if the system links the wrong specification version or an outdated test plan, every subsequent step (testing, results, review, CoA) proceeds normally and produces a complete, professional-looking record that is simply testing against the wrong requirements.

This is why specification-to-test-plan binding logic deserves disproportionate validation attention relative to how simple the login screen itself appears. The risk is not in the transaction — it's in the configuration table behind it.

The Distinction Most Validation Plans Miss

Routine, Retest, and Stability Login Are Three Different Risk Profiles — Not One

  • Routine QC login — Risk centers on correct specification binding and sample identity. Standard OQ coverage usually addresses this adequately.
  • Retest/reanalysis login — Risk centers on traceability back to the originating OOS investigation and preventing selective reporting. This needs dedicated test cases most validation packages skip entirely.
  • Stability program login — Risk centers on protocol-driven scheduling logic rather than static specification binding. Treating it as a minor variant of routine login misses the schedule/timepoint validation it actually needs.

Where Sample Login Risk Concentrates

Three points determine whether sample login produces a reliable foundation for everything that follows.

Specification & Test Plan Binding
High

Superseded specification version selected at login — If specification version control is not correctly configured, a sample can be logged against an expired specification while a current, revised version exists. Testing proceeds against outdated acceptance criteria with no system-generated warning.

High

No active test plan mapped to specification — If a specification exists without a corresponding test plan mapping (a configuration gap, often from incomplete master data setup for a new product), the system may allow login to proceed with an undefined or partial set of tests, silently producing an incomplete testing record.

Sample Identity
High

Duplicate or reused sample ID — If the sample ID generation logic allows duplication or manual reuse of a previously assigned ID, results from two different physical samples can become co-mingled in the system record, creating a traceability failure that is extremely difficult to detect after the fact.

Medium

Sub-sample splitting losing parent linkage — When a sample is split for parallel testing (e.g., microbiology and chemistry on the same physical sample), the sub-samples must retain a traceable link to the parent sample ID. Without this, the chain-of-custody record fragments at exactly the point where multiple analysts begin handling the same original material.

Retest & Exception Login
High

Retest login with no link to originating investigation — If a retest sample can be logged as a standalone entry without a mandatory reference to the OOS investigation that justified it, the system provides no structural barrier to undisclosed retesting — a significant data integrity exposure that inspectors actively probe for.

Medium

Manual test plan override not visibly flagged — A manually modified test assignment that looks identical to a standard specification-driven assignment in the review screen makes it difficult for a QA reviewer to identify and verify that a deviation from standard testing was authorised.

Sample Login OQ: What to Test

These tests target the configuration logic behind the login screen — not the screen itself, which is the lower-risk part of this function.

OQ — Operational Qualification

Mandatory Sample Login OQ Test Cases

OQ-LG-01Current Specification Version SelectionAlways Required

Log in a sample for a product with two specification versions in the system — one expired, one current. Confirm the system automatically binds the sample to the current version's test plan. Then attempt to manually select the expired version and confirm this is either blocked or requires elevated authorisation with an audit trail entry.

OQ-LG-02Login Blocked for Specification Without Test Plan MappingAlways Required

Attempt to log in a sample for a specification that has no associated test plan configured. Confirm the system blocks login or clearly flags the gap rather than allowing the sample to proceed with an undefined test set.

OQ-LG-03Unique Sample ID GenerationAlways Required

Generate multiple sample IDs in sequence and confirm no duplicates occur. Attempt to manually enter an already-assigned sample ID for a new sample and confirm the system rejects it. Confirm the printed barcode label content matches the system record exactly.

OQ-LG-04Sub-Sample Parent-Child TraceabilityAlways Required

Split a logged sample into two sub-samples for parallel testing. Confirm both sub-sample records maintain a visible, queryable link back to the original parent sample ID, and that this linkage is retained through to final result reporting.

OQ-LG-05Retest Login Requires Investigation ReferenceAlways Required

Attempt to log a retest sample without entering a reference to the originating OOS or investigation record. Confirm the system blocks completion of login until this reference is provided. Confirm the retest result is distinguishable from the original result in any subsequent report or CoA generation.

OQ-LG-06Manual Test Plan Modification Authorisation and VisibilityAlways Required

Attempt to manually add or remove a test from the assigned test plan using a standard analyst role — confirm this requires elevated authorisation. Complete the modification with an authorised role and confirm the change is flagged distinctly in the review screen, with an audit trail entry capturing the reason.

OQ-LG-07Stability Protocol Schedule-Driven LoginRequired if Stability Program Configured

Log a sample pull against an active stability protocol. Confirm the system assigns the correct pull-point test plan based on protocol timepoint. Attempt to log a pull outside the scheduled timepoint window and confirm the system flags it or requires justification.

Questions Validation Teams Ask About LIMS Sample Login

How do you validate that LabWare automatically assigns the correct test plan based on product specification at sample login?

This is governed by the specification-to-test-plan linkage configured in the product/specification master data. Validation must confirm: when a sample is logged for a given product and specification version, the system automatically proposes the test plan tied to the currently effective specification — not an expired or superseded version. The OQ test must include a scenario where two specification versions exist for the same product to confirm the system selects the current one. A second test must confirm that if a specification has no active test plan mapping, the system blocks login rather than allowing it to proceed without defined tests.

What sample identity binding controls need OQ testing in LabWare to prevent sample mix-up?

Sample identity binding refers to system controls ensuring a physical sample is unambiguously linked to its LIMS record throughout the testing lifecycle, typically enforced through barcode or unique sample ID generation at login. The OQ must confirm: the system-generated sample ID is unique and cannot be manually duplicated or reused, the printed barcode label matches the system record exactly, and any attempt to log results against a non-existent or disposed sample ID is rejected. A frequently missed test is confirming sub-sample splitting maintains traceable linkage back to the parent sample.

Does LabWare's chain-of-custody timestamp at sample receipt satisfy 21 CFR Part 11 data integrity expectations?

The system-generated timestamp satisfies Part 11 expectations only if captured automatically at the moment of login — not manually entered, and not editable afterward without a documented audit trail entry. The validation must test: the login timestamp cannot be backdated during initial entry, any subsequent correction generates a change document with the original value, and the system clock is synchronized to a validated time source — particularly important for multi-site labs where chain-of-custody sequencing must be unambiguous.

How should retest and reanalysis sample login be validated differently from initial sample login?

Retest logins carry higher data integrity risk because they follow an OOS or anomalous result and are scrutinized closely during any investigation. The validation must confirm: a retest login requires a documented reference to the originating investigation record, the system distinguishes retest results from original results in reporting so a CoA cannot inadvertently present only the favorable retest value, and the retest workflow enforces any approval gate required by the OOS procedure before testing begins. A LIMS allowing unrestricted, untracked retest login is a significant audit finding risk.

What is the validation risk in allowing test assignment to be manually modified after sample login?

Manual modification of the assigned test plan is sometimes operationally necessary but creates risk if uncontrolled. The validation must confirm: any manual addition or removal of a test requires elevated authorisation beyond standard sample login access, the change generates an audit trail entry with a reason, and the modified test plan is clearly distinguishable from the original specification-driven plan in any review screen — so a QA reviewer can immediately identify and verify the deviation was authorised.

Does LabWare sample login integration with an external sample management or LIS system require separate validation?

Yes — if sample metadata is received electronically from an upstream system rather than entered manually, this interface requires its own qualification. The validation must confirm: transferred data arrives accurately and completely, a failed or partial transmission does not create an incomplete testable sample record, and any mapping logic translating upstream codes to LIMS product codes is tested for all in-scope products, not just one example. Interface failures here are particularly dangerous because they affect test plan assignment downstream.

How do you validate sample storage condition and stability-indicating sample login differently from routine QC samples?

Stability program samples carry additional requirements because their test plan and timing are driven by a stability protocol rather than a static specification. The validation must confirm: the system correctly assigns the protocol's pull schedule and associated test plan at login, samples pulled outside the scheduled timepoint window are flagged or require justification, and storage condition metadata is retained and traceable for the life of the study. A common gap is treating stability login as a minor variant of routine login when the protocol-driven scheduling logic needs its own dedicated test cases.

LabWare LIMS — Full Module Scope

GAMP 5 classification and CSA approach across the full LabWare LIMS deployment.

LabWare Results Entry & OOS

Result calculation, specification limit testing, and OOS workflow validation.

LabWare Instrument Interfaces

Analytical instrument data transfer qualification and failure-mode testing.

Data Integrity for GxP Systems

ALCOA+ principles and audit trail requirements for computerised lab systems.