LIMS for QC Laboratories: Requirements and Selection Criteria

To select a LIMS for a QC laboratory, turn actual work into testable requirements before comparing proposals. Describe how a sample enters the laboratory, which specifications apply, who generates and reviews the result, and what happens when a step fails. Then ask the supplier to demonstrate these paths using representative test data, including exceptions and recovery. The number of available modules does not establish suitability for your laboratory; a successful demonstration is not validation of the system as configured and used in GMP.

This article provides an original matrix of twelve requirements and a simulated case involving two laboratories. It focuses on LIMS selection, from the need to the evidence and a sustainable cost. It is neither a brand ranking nor a complete validation plan.

1. Define the problem and who needs to solve it

Collect representative pathways from the current laboratory: routine receipt, urgent sample, incomplete request, result requiring investigation and report review. Identify manual steps, delays, duplication and dependencies on people or systems. Record the available evidence about problems; do not promise percentage reductions in time or errors without an observed baseline.

Involve analysts, sample reception staff, method owners, reviewers, QA, IT and owners of connected systems. Assign a process owner and a system owner, clarifying who decides on requirements, configurations and acceptance. Annex 11 requires collaboration, defined responsibilities and user requirements linked to risk and GMP impact. [1] A list compiled solely by the IT purchaser may overlook the decisions that make a result valid.

Set the initial scope: which sites, sample families and activities must the first release support? Distinguish mandatory needs from desirable improvements. Deferring a function may be reasonable if the process remains adequately controlled; postponing an essential control because a proposal costs less does not resolve the requirement.

2. Follow the sample and the responsibility

Define identification, relationship to the batch or request, aliquots, containers, locations and status. A unique code is insufficient if an aliquot loses its link to the original sample or the system allows testing to begin on rejected material. Ask to see receipt, discrepancy handling, assignment and transfer, with explicit roles and conditions for moving between steps.

For each status, clarify its meaning and permitted actions: “received”, “awaiting clarification” and “available for analysis” must not become synonyms. The workload view should show who is responsible for the next step. WHO good practices for QC laboratories address sample requests, identification, receipt and documentation. [3] Adapt the actual model to your organisation without automatically importing every national laboratory workflow.

During the demonstration, introduce two similar requests and a mismatched container. Observe whether the operator can correct the association under control and whether the history can still be reconstructed. Avoid assessing reception solely by counting the seconds needed to print a label.

3. Govern methods, specifications and reference data

Master data describe materials, methods, specifications, units, calculations and authorised workflows, among other things. Assign ownership, revision, approval, effective date and relationships. Ask which information is copied into the sample record and which remains linked to a versioned object. A change made today must not make the rule applied to yesterday’s result incomprehensible.

Use a concrete scenario: a sample is already being processed when a new specification takes effect. The system must support the approved business rule for deciding which version applies while preserving the context of the decision. Do not assume a universal rule based on receipt or analysis date: this depends on the process and applicable requirements.

Check apparently secondary data too: incompatible units, decimal separator, rounding, method code or an empty field. EU GMP Chapter 4 and Chapter 6 provide the framework for controlled QC documents and records. [2] [6] Selection must show how the LIMS enables the rules to be applied, not merely how it stores a PDF of the specification.

4. Capture, calculate and review results and exceptions

Describe where the data originate: manual entry, instrument transfer, CDS import or an external laboratory result. Define necessary checks for critical data and the relationship to original records, metadata and calculations. A final value without context may be insufficient to reconstruct the work. FDA Data Integrity guidance explains the role of complete data and metadata in the CGMP context. [4]

Demonstrate a pathway involving an out-of-specification result, a justified correction and review. The LIMS must support the applicable investigation procedure, preserving data and statuses; it must not make a sample “acceptable” by deleting an unwanted result or automatically choosing a new favourable value. Clarify what completing a test means compared with approving its result.

If electronic signatures are planned, define who signs, what content they sign, the meaning of the signature and its link to the record. Availability of a signature function does not establish compliance on its own. Part 11 applicability depends on the electronic records and relevant FDA obligations; it does not arise simply from buying a LIMS. [5] Selection identifies capabilities and gaps; regulatory assessment and validation remain project activities.

5. Test transfers, especially when they fail

For each interface with instruments, CDS, ERP or other systems, specify the data, identifier, unit, version, status and responsibility. Decide which system is authoritative for each piece of information. If the CDS retains the original chromatographic record, the LIMS must maintain a reliable link and the necessary context; an imported number does not automatically replace that record.

Ask what happens when a message arrives twice, fails to arrive, contains an unknown identifier or is rejected. The demonstration should show error detection, an appropriate block or status, notification, an owner and documented recovery. A green indicator saying “interface active” does not prove transfer completeness. Annex 11 addresses checks on electronic exchange and preservation of value and meaning during migration. [1]

Agree who manages mappings, technical credentials, format changes and updates to both systems. Include operating the interface in the cost, not just building it. The normal pathway should be straightforward for the user; the abnormal pathway must remain visible and recoverable without uncontrolled data changes.

6. Require continuity, accessibility and sustainable support

Define role-based access, separation of responsibilities, administrator management and removal of authorisations. Require audit trails useful for review, with relevant events, context and search capabilities. Do not assess the function merely by asking “is there an audit trail?”: have a relevant change located and reconstruct who made it, when and why.

For availability and performance, use the expected workload: concurrent users, record sizes, volumes and times required by the process. Specifying “fast” or “always available” does not create a test criterion. Agree justified targets and measurement methods; assess alternative activities during downtime and subsequent reconciliation. Annex 11 distinguishes backup, continuity and archiving. [1]

Request a demonstration of restoration and export of a complete record, including relationships, metadata and information needed to interpret it. A CSV list of results may be insufficient. Assess retention, readability, access after contract termination, support, updates and hosted-service responsibilities. WHO also addresses control of systems managed off site. [3] Cloud hosting does not remove the need to clarify these boundaries.

7. An original matrix of twelve demonstrable requirements

This matrix is a GuideGxP starting point for selection, to be converted into approved local requirements. Its criteria are not universal regulatory limits. For every scenario, retain the product version, configuration, test data, observed outcome, gap and agreed action. Use synthetic or authorised data for the demonstration, avoiding unnecessary samples or confidential information.

8. Compare proposals and evidence, not just answers

Send the same scenarios to candidates and ask them to distinguish standard functionality, configuration, custom development, external dependency and unavailable functionality. Record observed limitations. “Possible” is not equivalent to “demonstrated in the proposed version”; a future promise must remain an explicit dependency, with its impact on the decision.

Before assigning scores, check mandatory requirements. An essential gap cannot be offset by better graphics or numerous secondary modules. For criteria that can be graded, define justified weights agreed before the demonstration, separating expected benefit, available evidence and necessary effort. Avoid decimal scores that lend false precision to poorly documented judgements.

Compare the cost of the entire scope: licences or subscription, configuration, master-data cleansing, interfaces, migration, validation, training, support, updates and exit. Include the internal staff required. Do not commit the laboratory to a schedule that assumes data are already ready and resources have been assigned when they have not. The decision must make both parties’ dependencies and responsibilities visible.

9. Simulated case: two laboratories, different priorities

Laboratory A performs many repetitive tests on a few product families at a manufacturing site. Laboratory B provides QC services to several clients, with variable requests, different methods and specific reports. This case is simulated: it attributes no real performance or savings to any system.

A gives greater weight to rapid identification, recurring test plans, queue management and controlled exchanges with manufacturing systems. Its demonstration tests a peak in sample receipts and an interrupted interface. It checks that recovery does not create two samples or leave a result without a status, as well as measuring performance against the agreed workload.

B gives greater weight to request review, segregation of client information, method versions and controlled report generation. Its scenario involves two clients with similar requests but different specifications, followed by an authorised change. The reviewer must retrieve the rule actually applied and the correct report without confusing the contexts.

Both retain record integrity, appropriate access, review and recoverability as mandatory requirements. Functional weights change, not the need for relevant controls. A solution may require too much customisation for A yet serve B well, or vice versa. The comparison documents why a compromise is sustainable within the laboratory’s own process, without declaring a universal winner.

Operational conclusion

Conclude selection with identified requirements, evidence, gaps, responsibilities and comparable costs. Carry open questions into the project and contractual arrangements instead of deleting them from the demonstration minutes. The selected proposal becomes a testable starting point for configuration and validation; it does not make the software “GMP certified” or automatically authorise its use.

Continue in the Digital Lab and Data Integrity HUB. To define boundaries with other systems, see LIMS, ELN, CDS and SDMS: Laboratory System Roles and Boundaries.

Sources and applicability

Sources checked on 30 September 2026. The January 2011 revision of Annex 11 remains the text listed in the EU GMP index consulted; proposed revisions are not treated as requirements already in force. WHO TRS 1052 Annex 4 is the 2024 guidance for pharmaceutical QC laboratories, with scope exclusions for biological products and microbiology. FDA references apply within their regulatory context; guidance does not itself create new legal obligations. The matrix, scenarios and comparison are original GuideGxP work to be adapted and approved locally.

1. European Commission — EU GMP Annex 11, Computerised Systems. Revision 1, January 2011; effective from 30 June 2011.
2. European Commission — EU GMP Chapter 4, Documentation. January 2011 revision, effective from 30 June 2011.
3. WHO — Good practices for pharmaceutical quality control laboratories. WHO Technical Report Series 1052, Annex 4, 2024; sections 3.3–3.6, 6.2, 6.4 and 6.10.
4. FDA — Data Integrity and Compliance With Drug CGMP: Questions and Answers. Final guidance, December 2018.
5. FDA — Part 11, Electronic Records; Electronic Signatures — Scope and Application. Final guidance, September 2003; scope and relationship to predicate requirements.
6. European Commission — EU GMP Chapter 6, Quality Control. Revision effective from 1 October 2014.