LIMS and CDS validation: risk, testing and release

The supplier delivers a complete test package, but the laboratory has changed its approval workflow and connected a new instrument. Which evidence remains valid? Answering requires comparison of intended use, actual configuration and test coverage. LIMS and CDS validation must support a documented decision on the suitability of the laboratory’s system for its intended use.

1. Define the system and the decisions it supports

Start with the process: sample receipt, acquisition, processing, transfer, review, approval and retention. Identify records and metadata, users, instruments, interfaces and required services. Understanding the roles of LIMS, CDS, ELN and SDMS helps allocate responsibility without leaving gaps.

Record versions and configurations, modules, local rules and infrastructure dependencies. Define who owns the process, maintains the system, provides technical support and approves evidence under the quality system. Software validation does not replace instrument qualification or analytical method validation: these are connected activities with different objects and evidence.

Assess regulatory applicability against products, activities, records and markets. Annex 11 concerns computerised systems used in GMP activities; applicable US requirements do not arise simply because a computer is present. The final February 2026 FDA CSA guidance addresses medical device production and quality management system software: it does not abolish pharmaceutical CSV or automatically extend its scope to every LIMS.

2. Connect requirements, risk and supplier evidence

Write testable requirements: the result or behaviour needed, the conditions and the acceptance criterion. Consider consequences of incorrect results, incomplete data, unauthorised approvals or unrecoverable records. Priorities follow risks to product quality, patients and data integrity, not the number of screens.

Examine supplier competence and quality systems, available documentation, tested versions, environment, coverage and known defects. To reuse a test, identify its covered requirement, why its evidence is reliable and whether local configuration or dependencies could change the outcome. A generic certificate or compliance statement does not demonstrate the laboratory’s specific workflow.

Document what can be accepted, supplemented or needs local verification. There is no reason to repeat every reliable test indiscriminately; neither is inheriting an outcome justified merely because a function has the same name. Configurations, custom code, interfaces and operational controls may require different checks.

3. Build a matrix that reaches a decision

This original matrix is an example to adapt to the scope. Each test has predefined data and criteria; compare the actual result with expectations, retaining evidence and addressing differences. Execute activities in authorised environments with identifiable test data.

Do not test only the successful path. Challenge errors, interruptions and plausible combinations that could produce an incorrect decision. Interface checks must reach the meaning of data at the destination: instrument–LIMS mapping and reconciliation provides a focused treatment.

4. Resolve deviations and authorise release

Record executed tests with requirement, version, environment, data, executor, outcome and evidence reference. Screenshot volume does not measure coverage. The verified behaviour and why it supports acceptance must be reconstructable; test tools and the environment also require assessment of suitability.

A failure against criteria does not become acceptable by deleting the test or retrospectively changing expectations without justification. Document the deviation, assessed cause, impact, correction and subsequent checks. Link a successful repeat to the initial failure without removing it.

Before release, review requirements coverage, deviations and residual risks, final configuration, procedures, training, support, access and recovery. The authorised function identifies the approved scope, any restrictions and responsibilities. Conditional permission to enter a subsequent phase does not automatically permit routine use of an unproven critical function.

5. Simulated case: a custom workflow changes coverage

The supplier package demonstrates that a reviewer can approve a complete result in the standard workflow. The laboratory adds an instrument import and an “awaiting verification” state. In a local test, an incomplete message leaves the unit blank but still permits transition to approved.

The standard test remains useful evidence for what it demonstrates; it does not cover this combination. The team records the deviation, checks the new state’s rules and interface, corrects the behaviour and tests complete, incomplete and repeated messages with the intended roles. It also checks that events, version and decisions remain reconstructable. Release depends on the documented outcome, not the size of the supplier dossier.

During operation, changes to configuration, versions, interfaces, roles and intended use require impact assessment and relevant controls. Periodic evaluation also considers incidents, performance, security and recoverability. Frequency and depth need justification: initial validation does not maintain the validated state by itself.

6. Sources and applicability

Sources checked on 2 October 2026. Human medicinal product GMP context; original matrix and scenario, with no testing on production systems.

• European Commission — GMP Annex 11, revision 1, January 2011, effective 30 June 2011, principle and §§1–4, 7, 9–14: validation, suppliers, testing and state of control.
• European Commission — GMP Annex 15, March 2015 revision, effective 1 October 2015, principle and §§1–2: planning, external evidence, deviations and authorisation; refers to Annex 11 for computerised systems.
• FDA — Data Integrity and Compliance With Drug CGMP, final December 2018, Q2–Q3: proportionate controls and functions validated for relevant use; nonbinding guidance.
• FDA — Computer Software Assurance for Production and Quality Management System Software, final 3 February 2026, sections I and III: medical device scope and 21 CFR Part 820; supersedes September 2025 guidance, not medicinal product GMP requirements.