PHARMA LAB · PL-06-025

Laboratory Software and Cloud Suppliers: Qualification and Responsibilities

Qualify the service the laboratory will actually use: from samples and metadata to record retrieval when the contract ends.
Technical illustration of laboratory and IT specialists reviewing a digital service and evidence for the data to be retained.

A supplier may manage its infrastructure well without knowing how the laboratory uses a result to decide on a batch. Qualification must connect the purchased service with the activities and records it supports. For a cloud-hosted LIMS, the practical question is whether samples, methods, results, reviews and history remain controllable during use and after leaving the service.

A platform name, certificate or demonstration does not resolve that question. Relevant evidence, assigned responsibilities and intended-use checks are needed. This article proposes technical assessment criteria; actual agreements require review by the appropriate company functions.

Qualify a defined service, not a brand

Describe processes, users, data and dependencies before requesting documents. Distinguish application software, hosting, instrument gateway, maintenance and archiving. Identify the contractual supplier and subcontractors performing relevant tasks: LIMS support and infrastructure operation may involve different organisations.

Define data locations and pathways, configurations controlled by the laboratory and those dependent on the service. SaaS, PaaS and IaaS labels help describe the model but do not assign every task. Assess network connectivity, authentication, licences, local instruments and availability needed by the QC workflow.

A planning-only service does not necessarily have the same impact as one retaining the only native-data copy. Document criticality and the rationale for assessment depth, including direct verification and remaining information gaps.

Examine competence, development and evidence

Request examples relating to the proposed service and version: requirements, development, tests, defects, releases and changes. Check how issues are communicated to customers and what evidence is available for differently configured functions. Supplier tests can contribute to validation of laboratory use, but alone do not prove local workflows and interfaces correct.

For certificates and attestations, check issuing body, period, scope, exclusions and customer-dependent controls. Infrastructure assurance does not automatically cover the application, tenant configuration or integrity of a result. Restrictions on evidence access must be assessed, not offset by a generic “GMP cloud” statement.

Assign tasks along the sample pathway

The matrix must distinguish who performs a task, who assesses the outcome and who decides. These assignments are illustrative: confirm them against the actual service and translate them into consistent agreements and procedures.

Activity or controlResponsibility to defineEvidenceCommitment to agreeReview
Instrument–LIMS transferGateway operator and application supplier execute; laboratory reconcilesSample, units, versions, errors and repeated messagesSupport boundaries and rejection handlingInterface changes or defects
Roles and support accessCustomer authorises users; provider manages its personnelEffective rights and attributable privileged activityLimited access, notification and revocation under defined conditionsPersonnel, risk or service changes
New method versionLaboratory approves; service preserves links and historyResult linked to the version usedAvailability and integrity of historical versionsData-model or configuration changes
Dataset recoveryProvider performs agreed recovery; customer checks usabilityRecovered signals, metadata and relationshipsRestore scope, objectives and responsibilitiesTests and dependency changes
Incident and software releaseProvider communicates; customer assesses QC impactEvent, affected data, release notes and actionsChannels, relevant times, evidence and emergency handlingIncidents and communication quality
Service exitProvider returns data; laboratory reconciles and retainsComplete export, readability, audit trail and linksFormats, residual access, support, costs and termination conditionsExport trials and service changes

A “shared” cell without an executor or evidence may conceal work nobody does. For example, a provider’s database copy may exclude native files stored on a local gateway: the laboratory must identify and cover that boundary.

Verifiable agreements and record continuity

Agreements should clarify data scope, outsourced activities, subcontracting, communications, change management and evidence availability. Define how laboratory, IT and quality assess incidents and releases affecting acquisition, calculation, audit trails, signatures or retention. Advance notice without necessary information may not enable useful assessment.

Verification opportunities should match risk and applicable obligations, including access to relevant information and audits of outsourced activities. A completed questionnaire is not proof that controls work. Retain conclusions and conditions under which the service is accepted.

Before becoming dependent on the service, test an exit strategy. Which objects can be exported, with which formats, relationships, viewers and licence conditions? Who enables access after termination, and for how long under the agreement? The CDS and LIMS migration article explores reconciliation of content and meaning. Do not plan source deletion before an authorised, verified solution exists.

Simulated case: exported results, missing history

During LIMS assessment, the laboratory requests an export for test sample C52, containing a corrected result, its previous version and the reason for change. The file received includes only the latest value and sample identifier; history, authorship and the applicable specification link are missing.

The result count matches, but the export cannot reconstruct the decision. The team records the gap and requests a complete-export demonstration or a documented retention and access solution. It verifies the new package in a separate environment with people who do not depend on the author’s memory.

If the solution remains insufficient, that critical requirement is unmet: the service is not accepted for intended use merely because the demonstration works. The case is simulated and does not describe a real supplier’s defect.

Review the service during operation

Follow relevant indicators: record-related incidents, recovery outcomes, interface defects, notification quality and action closure. Set review frequency according to criticality and performance; reassess changes to subcontractors, architecture or service. Availability percentages and support speed are useful but cannot replace data completeness.

EU GMP Chapter 7, revision 1, effective 31 January 2013, addresses outsourced activities, responsibilities, agreements and record accessibility. Annex 11, January 2011, §3, addresses suppliers and service providers. PIC/S PI 041-1, 1 July 2021, §10, develops data-integrity considerations for outsourced activities.

Sources consulted 2 October 2026 in the human-medicinal-product GMP context. Acceptance should remain linked to demonstrated capabilities, agreed responsibilities and the laboratory’s conditions of use.

Technical content for informed decisions; it does not replace the approved procedure, applicable requirements or the instrument manual.

Continue exploring