Validating an ELN-LIMS integration under GAMP 5 is not the same as validating the ELN or the LIMS. The integration is a separate software system — a Category 4 or 5 system depending on how much of it is custom — and it requires its own validation package: its own URS, its own risk assessment, its own IQ/OQ/PQ protocols, and its own change control process. Teams that validate the ELN and LIMS but leave the integration between them unvalidated have a compliance gap at the highest-risk point in their data flow.
Step 1: Define the URS for the integration
The User Requirement Specification for an ELN-LIMS integration defines what the integration must do, not how it does it. The URS should cover: which ELN record types transfer to which LIMS entities (and in what direction — ELN-to-LIMS only, or bidirectional?); the trigger for each transfer (event-driven on ELN approval, scheduled batch, manual initiation?); the data fields transferred for each record type; the quality checks applied at the integration layer before acceptance by the LIMS; the handling of failed transfers (retry logic, alerting, manual fallback); and the performance requirements (maximum transfer latency, minimum throughput). Each URS requirement gets a unique identifier that will link through the risk assessment and into the test cases. GxP Copilot supports URS authoring with structured requirement capture.
Step 2: GAMP 5 classification of the integration
The GAMP 5 classification determines the depth of the validation programme. Category 4 (configurable, no custom code): a vendor-supplied connector between two validated systems, configured through a UI or configuration file, with no bespoke transformation logic. Validation depth: IQ (installation and configuration verification), OQ (functional testing of each data flow type), no unit tests or code review required. Category 5 (custom): any integration with bespoke code — Python scripts, custom APIs, home-built transformation logic. Validation depth: full software development lifecycle evidence — unit tests for every custom function, code review records, source control history, IQ, OQ, PQ. The classification decision belongs to the validation team and should be documented in the validation plan before a line of code is written.
Step 3: Risk assessment for the integration
The interface risk assessment identifies the failure modes for each data flow type and scores each against severity, probability, and detectability. Critical failure modes for an ELN-LIMS integration include: silent transfer failure (high severity — QC data missing from LIMS without alert); incorrect field mapping (high severity — wrong value in release-critical LIMS field); duplicate transfer (medium severity — duplicate records in LIMS cause reconciliation failure); schema mismatch (high severity if undetected — values arrive in wrong format and are silently accepted). For each failure mode, the risk assessment documents the existing controls (schema validation, delivery receipts, monitoring) and the residual risk. The risk assessment drives the OQ test case coverage — high-risk failure modes get multiple test cases covering boundary conditions and error paths.
Step 4: IQ — Installation Qualification
The IQ for an ELN-LIMS integration verifies that the integration infrastructure is installed and configured correctly before any functional testing begins. IQ checklist: integration server software version matches the validated version; connector version matches the validated version; configuration parameters (API endpoints, credentials, field mappings, transfer schedules) match the approved configuration document; message queue infrastructure (if present) is installed and accessible; monitoring and alerting are configured and tested; network connectivity between ELN, integration layer, and LIMS is verified with documented test results. The IQ is executed in the target environment (staging or production qualification environment, not development). All IQ results are signed by the executing engineer and reviewed by QA.
Step 5: OQ — Operational Qualification
The OQ for an ELN-LIMS integration tests the functional requirements against the URS. OQ must include: happy path tests for every data flow type (ELN result record transfer, method transfer, sample metadata transfer); field mapping verification for every field in every record type (not just a spot check — every mapped field must be verified to arrive in the correct LIMS field with the correct value and data type); error condition tests for every identified failure mode (LIMS unavailable — does the message queue hold and retry? Schema mismatch — is the record rejected with an alert rather than silently accepted? Duplicate delivery — is the idempotency check working?); and performance tests (can the integration handle the peak expected transfer volume without exceeding the latency requirement?). Each OQ test is a formal protocol step with expected results, actual results, and pass/fail disposition.
Step 6: PQ — Performance Qualification
The PQ tests the integration in the actual operational environment with real or representative operational data. For an ELN-LIMS integration, PQ typically runs over a defined period (two to four weeks) in production or a production-equivalent environment, monitoring: total records transferred vs total records expected; error rate (target: zero missed transfers, with documented handling for any that occur); transfer latency (every transfer completes within the URS-defined SLA); data integrity checks (a sample of transferred records is manually verified against the source ELN records). PQ exit criteria should be stated in the validation plan and agreed with QA before PQ begins — not defined after the results are in hand.
Step 7: Ongoing change control and periodic review
Post-validation, the integration must be maintained under the same change control discipline as the systems it connects. Changes requiring formal change control: API version upgrade in either the ELN or LIMS; addition of a new data flow type; change to a field mapping; change to a quality check threshold or logic; upgrade of the integration software or connector version. Periodic review (at least annual): confirm the validation remains current given any changes to the integration, the connected systems, or the regulatory environment; review the integration monitoring logs for anomalies; confirm the transfer record completeness for the review period. GxP Copilot handles change control and periodic review for the ELN and LIMS systems; the integration layer is handled by our data integrity (ALCOA+) team.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.