PHARMA LAB · PL-06-009
Instrument-to-LIMS integration: data mapping, errors and reconciliation

In this article
The interface reports “transfer successful”, but the LIMS assigns the value to the wrong unit. The connection worked; the data lost their meaning. Integrating instruments and LIMS requires evidence of the entire path from source to a result usable in the process, including exceptions.
1. Define source, destination and responsibilities
Map the actual flow: instrument or CDS, any intermediate component, LIMS and the systems retaining records. For each object, establish the authoritative source and who may modify it. The LIMS may govern the sample while the CDS retains the signal and processing history: transferring a result does not automatically make the LIMS the archive of all original data.
The laboratory systems map helps avoid implicit responsibilities. Identify the process owner, system owners, interface maintainer, error reviewer and change approver. If nobody owns rejected transfers, automation can accumulate invisible work.
Define the event authorizing transmission and the meaning of each confirmation: file delivered, message received, structure accepted, data associated and application status updated are different steps. Successful transport does not establish process acceptance or analytical approval.
2. Write a mapping that preserves meaning
For each field, document type, format, mandatory status, origin, transformation, destination and check. Consider compound identifiers, leading zeros, decimal separators, precision, units, qualifiers such as “below the limit”, statuses, timestamps and versions. A blank field must not silently become zero; a qualified value must not become an ordinary number.
The original matrix below is a design example. Actual rules must be approved and verified for the specific interface; this is not a universal LIMS schema.
| Source field | Planned transformation | Destination | Check | Error handling |
|---|---|---|---|---|
| Sample and test | Explicit mapping; preserve identity | Correct sample/test | Unique correspondence | Traceable rejection if unknown or ambiguous |
| Value and qualifier | Declared conversion preserving the qualifier | Result and meaning | Comparison with source | Block unexpected format |
| Unit | Authorized conversion of number and unit together | Method-expected unit | Quantity equivalence | No silent default unit |
| Precision | Documented representation/rounding rule | Stored and displayed value | Before/after comparison | Flag unplanned loss |
| Result status | Mapping of permitted statuses | Provisional, reviewed or other defined status | Authorized transition | No automatic promotion |
| Timestamp | Explicit format and time zone | Correct event time | Distinguish event from receipt | Reject or control ambiguity |
| Method and version | Historical relationship retained | Result method/version | Relationship verification | Do not substitute current version |
| Message identifier | Stable key and comparable content | Recognizable transaction | Detect repeat or conflict | No blind duplication or overwrite |
A valid transformation may change representation while preserving the quantity; an identical character copy may change meaning. Reconciliation must assess both aspects together with record context and status.
3. Handle failures, duplicates and retries
Plan for rejected messages, partial sends, lost acknowledgements, out-of-order data and interruption followed by recovery. Preserve source, identifier, mapping version, attempts, outcomes and rejection reason in protected records. Assign who intervenes and when; an unassigned alert does not resolve the error.
If acknowledgement is missing, do not assume the LIMS received nothing. Check transaction status before retrying. By idempotence here, we mean that repeating the same transmission does not create a second result or additional process effect. Demonstrate it in the application configuration instead of inferring it from the protocol name.
A message with the same key but different content is a conflict to handle, not a duplicate to ignore. A new authorized version must retain its relationship to the previous one. Define how late messages are identified and prevented from applying to an obsolete state. Avoid direct database corrections that bypass authorizations and history.
4. Test transfer, reconciliation and recovery
Use synthetic data and an isolated, authorized environment. For each requirement, define initial conditions, expected source and destination data, action, expected outcome and retained evidence. Cover correct transfers and negative cases: unknown identifier, incompatible unit, missing mandatory field, unexpected decimal format and repeated message.
A lost-acknowledgement test must verify that subsequent handling creates no duplicates. A recovery test must reconcile data already accepted, pending and rejected. Demonstrating service restart or matching record counts is insufficient.
Compare identity, value, unit, status, times and version relationships. If a transfer includes a set of results, define what happens when only part is accepted. Record deviations and close required conditions before releasing the interface for its defined use.
5. Simulated case: correct number, wrong unit
The source produces 1.25 mg/L for a synthetic sample. The message arrives, but the LIMS records 1.25 µg/L because it applies a default unit. Both systems have one record and the number looks identical, yet the quantity is one thousand times smaller. If conversion to µg/L were required, the equivalent value would be 1250 µg/L.
Semantic comparison detects the error. The responsible team preserves the message, assesses any impact, corrects the mapping under change control and repeats relevant tests. Correction of any affected records follows the authorized process and retains history; simply editing the displayed unit to clear the alert is insufficient.
After release, monitor expected, accepted, pending and rejected messages, exception age and discrepancies. Changes to methods, export format, software version or master data require assessment of mapping impact. Original-data and metadata retrieval remains necessary even when the interface works.
6. Sources and applicability
Sources checked on 1–2 October 2026. GMP context for human medicinal products; editorial examples, no work on real systems.
- European Commission — Annex 11, January 2011 revision, in operation from 30 June 2011, §§4.7–4.8, 5, 10 and 13: testing, data meaning, interfaces, changes and incidents. The 2025 proposal is distinct from the adopted text.
- PIC/S — PI 041-1, final 1 July 2021, §9.4: correct and complete transfer; GMP/GDP inspectorate guidance.
- FDA — Data Integrity and Compliance With Drug CGMP, final December 2018, Q1 and Q3: context and intended use; nonbinding drug CGMP guidance.
- IETF — RFC 9110, HTTP Semantics, June 2022, §9.2.2: idempotence of HTTP requests. Technical standard, not a GMP requirement or a prescribed LIMS protocol.
Continue exploring
PL-06-012
Laboratory result review: responsibilities and digital evidence
A consistent report can still be incomplete. Review must reconstruct the pathway from sample to decision, including changes and exceptions.
Read the articlePL-06-011
LIMS master data: specifications, methods and versions
LIMS master data drive testing, calculations and assessments. Updates must preserve the criteria applied to records and control dependencies.
Read the articlePL-06-010
Sample lifecycle in LIMS: identification and chain of custody
A readable code cannot tell the whole sample story. Relationships, custody transfers and decisions must remain traceable through closure.
Read the article


