MES LIMS Integration: Linking Batch Execution and Lab Results

MES LIMS integration is the controlled exchange of sample requests, specification references, laboratory results and processing statuses between a manufacturing execution system and a laboratory information management system, linking laboratory evidence to the correct manufacturing batch and execution step.

Also called lims mes integration or a mes lims interface, it connects manufacturing execution with laboratory work without making either system responsible for everything.

Typically, MES supplies manufacturing context: batch, material, operation and sampling point. The laboratory information management system manages laboratory work and result records. The interface maintains associations between them. Ownership remains field-specific: a separate specification-management system may control limits and effective versions, while another master-data service owns material identifiers. Define those owners before mapping messages; a copied field does not become authoritative merely because it appears in both applications.

The example workflow used here is a design pattern, not a mandatory sequence: MES requests a sample against an execution step; LIMS registers the sample and returns its identifier; subsequent exchanges carry results and their processing statuses back to that context. Instrument acquisition, laboratory investigations and batch disposition remain outside the interface’s own decision-making authority. Authorized people retain review and release responsibilities. Continue with interface patterns and recovery.

Start with the product, jurisdiction and record obligation—not the presence of MES and LIMS. The table is an applicability-screening framework, not a declaration that pharmaceutical rules govern every interface. Identify the governing product and record requirements before extending a pharmaceutical control model to supplements, devices or chemicals.

For a US drug-manufacturing assessment, check the current text of 21 CFR 211.68 for scope and applicable equipment-control provisions. This is a scope check, not an interface specification.

21 CFR 211.194(a) requires laboratory records to include complete data from all tests necessary to assure compliance with established specifications and standards. That legal obligation is distinct from the architectural choice of which records to copy into MES. Identify where the complete laboratory record resides before choosing the exchange payload.

21 CFR 11.1(b) covers electronic records created, modified, maintained, archived, retrieved or transmitted under agency record requirements. Apply this as a record-level scope question, not a blanket rule for manufacturing interfaces; the Part 11 overview provides context.

For conventional food, 21 CFR 11.1(i) excludes records required by Part 117. However, records also required under other applicable statutory provisions or regulations remain subject to Part 11. This is not a food-industry exemption.

EU GMP Annex 11 is official GMP guidance for medicinal products, distinct from US binding regulations; check its current text for the applicable manufacturing context. MHRA GxP data integrity guidance informs pharmaceutical data governance, not software certification.

Document the scope decision separately from site-selected engineering controls. Detailed control design belongs in the validation and traceability section.

Define an interface contract: the relationships, meanings and ownership rules exchanged between systems—not an application database schema. The following is a proposed practice model; field ownership and storage location remain site-specific design decisions.

Business identifiers describe samples, tests and results; transport identifiers describe exchanges. A message ID must not substitute for a result ID or revision. Preserve a stable reference to the authoritative LIMS record, connecting it to the relevant batch execution history.

Represent numeric, categorical and qualified results explicitly rather than forcing all three into one numeric field. Numeric values need units and basis; categorical values need a controlled vocabulary; qualified values need a separate qualifier. Define precision, applicable specification limits, inclusive or exclusive boundaries, method version and review state so the receiver can interpret the result without guessing. Connect version ownership to specification and method governance.

Worked unit comparison

Assume 0.125 mg/mL, inclusive limits of 100–150 mg/L, the same analyte and sample basis, and an approved conversion: 0.125 mg/mL × 1,000 mL/L = 125 mg/L. The converted value lies within those limits. Preserve the original value, original unit, conversion rule and compared value. Assign rule ownership to Quality and derivation ownership to the converting service. This example involves no density or potency conversion.

Synchronous APIs, asynchronous events and controlled file exchange are possible implementation patterns. Choose according to latency, coupling and support needs; none establishes compliance or correctness by itself.

For medicinal-product GMP systems, official guidance in Annex 11 section 5 recommends built-in checks for correct and secure entry and processing when computerized systems exchange data electronically. The following are engineering choices supporting data integrity by design, not prescribed field names.

An example envelope contains message_id (unique transmission identity), correlation_id (workflow link), source_system (origin), schema_version (payload contract), business_key (sample/test identity), result_version (revision) and occurred_at (source event time with timezone). Preserve message_id during retries; use result_version, not arrival time, to order revisions.

The consumer should deduplicate using source_system and message_id. An identical repeat returns its recorded outcome without reapplying the result; the same identifier with a changed payload is a conflict. Apply version-aware updates so stale revisions cannot overwrite newer results. Persist processing state durably with the business update so a crash cannot leave an applied result eligible for duplicate application.

Retry temporary outages with bounded attempts and delays. Quarantine semantic rejections—unknown units, samples or specification versions—in an exception queue with a named owner, reason and resolution history. After correction, authorize controlled replay while preserving the original failure record. Use the state distinctions in the next section and measure recovery through business reconciliation, not protocol success alone.

Treat lifecycle mapping as a site-defined operating model, not a translation of similar display labels. Keep sample state, test state, result-review state, interface-processing state and batch disposition as separate dimensions. Illustrative sample labels include requested, collected, received, testing, awaiting review, reviewed, cancelled and invalidated; they must not imply that every associated test or result shares that status.

Read the seven-step workflow through the sample-to-result relationships. Assign each transition an owner and entry criteria:

1. Requested: manufacturing identifies the sampling requirement and batch context.
2. Collected: the sampler records collection and sample identity.
3. Received: laboratory intake confirms the sample login handoff.
4. Testing: analysts progress individual tests, retaining separate test states.
5. Awaiting review: analysts submit identified result revisions for review.
6. Reviewed: an authorized laboratory reviewer records the result decision.
7. Applied: the receiving application records business acceptance; quality separately assesses batch disposition.

Model cancellation and invalidation as explicit branches, with authorized owners, reasons and affected records—not as deletion or successful completion.

A transport acknowledgement confirms receipt; business acceptance confirms that the receiving application applied the message; laboratory approval concerns the result; batch disposition is a separate human quality decision. Software does not make a site compliant, and the interface must not be described as automatically approving or releasing batches.

Worked case 2: an amendment overtakes delivery

Assume R17 revision 1 was approved and applied at 10:01. At 10:05, revision 2 records an amendment and returns the result to review. A delayed revision-1 delivery arrives at 10:06. All times use the same time zone. The receiver should preserve history, reject the stale state transition and flag manufacturing decisions relying on revision 1 for authorized reassessment through the batch execution history. Revision order—not arrival order alone—determines current state.

Can production continue during testing?

Distinguish an approved process hold point from an informational result dependency. At a hold point, follow the approved criteria and authorization route before proceeding. An informational dependency is not general permission to continue: assess the affected operation under the site's approved process and quality responsibilities.

Map the binding controls to interface checks

In the US, two sets of rules bear directly on the interface. 21 CFR 211.68(b) requires that “Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy”, with the degree and frequency of that verification “based on the complexity and reliability of the computer or related system”. Where the exchanged sample, specification and result records are electronic records required by predicate rules, 21 CFR Part 11 adds the controls below. Part 11 treats a system as closed or open depending on whether access is controlled by the people responsible for its content; an interface that carries records across an organisation boundary, such as to a contract laboratory, should be assessed against the open-system duty in 11.30.

EU GMP guidance separates application validation from infrastructure qualification: the Annex 11 Principle says the application should be validated and IT infrastructure qualified. Under section 1, the extent of validation and data-integrity controls should follow a justified, documented risk assessment. These are distinct activities; interface testing should not substitute for infrastructure qualification.

Keep migration separate from routine exchange. Annex 11 section 4.8 addresses checks that migration to another format or system does not alter data value or meaning. Plan GMP data migration checks separately from recurring message-processing tests.

Build a traceable test baseline

As an engineering practice, connect intended use and risk assessment to mapping specifications, test cases, expected outcomes, execution evidence, discrepancies and approval in a CSV traceability matrix. Record versions of both applications, middleware, configuration and message schemas. Define acceptance by business outcomes, not successful API responses: every expected result must be correctly associated and interpreted, or explicitly rejected and reconciled, with no unexplained omissions or duplicates.

Reuse the two earlier worked cases as regression fixtures rather than repeating their arithmetic or chronology. Use the failure-mode matrix below to select additional negative tests.

Define what the evidence proves

Transport logs explain message handling; business change history explains record provenance. As a practical evidence design, retain traceability for original and amended values, responsible actors or services, relevant timestamps, change reasons and links to review decisions. A payload hash supports comparison; it does not prove the underlying laboratory result is correct.

For upgrades, assess change impact and select targeted regression across the interface, including the unchanged application: unchanged code can still receive changed data or behaviour.

Binding US requirement: where applicable, 21 CFR 211.194(b) requires complete records of modifications to established testing methods. This recordkeeping obligation is distinct from the recommended interface version-management design below.

Recommended practice: assign named business owners, not just system administrators, to each shared data domain:

• Material-data steward: material codes and approved MES–LIMS code crosswalks within material master data.
• Manufacturing process owner: sampling-point identities and their production context.
• Laboratory owner: test identifiers, units, result qualifiers and method versions.
• Specification owner: specification versions and their material applicability; quality approves governed changes.

For each change, define effective dates, approve the crosswalk and record change approval before deployment. Assign interface owners compatibility tests covering old and new versions, including changed units or qualifiers. Preserve the specification and method associations used for each execution in batch execution history; never silently substitute the newest specification when displaying or reprocessing historical results.

Official EU GMP guidance: for outsourced integration or related computerised-system services, Annex 11 section 3.1 calls for formal agreements between the manufacturer and third parties, including clear statements of third-party responsibilities.

A change between sample collection and review needs a version-selection decision under the site's approved change rules and execution context; effective dating alone may not settle it. The specification-change FAQ addresses that decision. For applicability, return to product and record scope.

Recommended practice is to reconcile expected business keys and result revisions, not counts alone. Compare expected, received, applied, quarantined, superseded and cancelled items against a declared source cutoff and receiver snapshot time. Traverse every page using a stable snapshot or watermark. Identify late arrivals separately and allow a documented in-flight interval before classifying missing items. Preserve supersession and cancellation relationships rather than silently removing records. Use the sample lifecycle for status definitions.

Worked case 3: delivery is not application

Assume a fixed observation window with 118 expected unique approved-result events, each for a different test execution, and no amendments or cancellations. Two events arrive twice: 120 deliveries. The receiver applies 117 unique events, quarantines one for an unknown specification version and suppresses two duplicate deliveries.

• Deliveries: 117 + 1 + 2 = 120.
• Unique events: 117 + 1 = 118.
• Transport receipt: 120/120 = 100%.
• Unique-event application: 117/118 × 100 = 99.15%, rounded to two decimal places.

One business exception remains.

Keep measures separate

Use a process event log to retain clock endpoints. Set thresholds from process risk and approved service expectations, not generic targets.

As risk-based engineering practice, use distinct service identities, least-privilege access, controlled credential rotation, protected transport and separated production and test environments. Restrict configuration changes to authorized personnel. Keep human approval permissions separate from message-processing permissions; an interface account should not approve results. Build these boundaries into data integrity by design.

Assign an outage owner and escalation route. Document restart procedures, recovery-time and recoverable-data-loss objectives, and post-recovery reconciliation according to business risk. Rehearse interruption and restart, including who authorizes resumption and resolves records left pending.

An outage does not itself authorize manual result entry. Where a controlled manual fallback is approved, EU GMP guidance in Annex 11 section 6 recommends an additional accuracy check for critical data entered manually. Define the check, including independent witnessing where selected, before fallback begins.

Decide how fallback entries are identified and matched against queued deliveries when automation resumes, so reconciliation prevents duplicate business records. For contract-laboratory results, define external sample identity, method and specification references, review evidence and controlled entry into the same result lifecycle. Revisit the system boundaries described above wherever responsibility for entry, checking or recovery is unclear.

Use this practice-based matrix with the identifier, versioning and reconciliation controls described above. Assign named recovery owners through the site's responsibility matrix; the roles below are starting points.

Avoid repairing a failed transaction by editing the receiving database without retaining its relationship to the original message and correction decision. Use controlled correction and replay instead. Select laboratory ownership for result meaning, manufacturing ownership for batch or sample context, and technical ownership for transport or processing faults. Record the decision and confirm the corrected business record through reconciliation.

For outage-related gaps, use the security and recovery controls described earlier.

Use this suggested checklist before implementation approval and during ongoing review; it is not a prescribed regulatory approval sequence.

• Define intended use, affected products, decisions supported and system boundaries.
• Assign field ownership; approve identifier, unit and transformation mappings.
• Document specification versions, result revisions and permitted lifecycle transitions.
• Define business acknowledgements, rejection handling and accountable exception owners.
• Record risk-based tests and acceptance criteria in the validation plan.
• Review service access, outage procedures, recovery tests and fallback reconciliation.
• Retain reconciliation evidence showing expected, accepted, rejected and unresolved records.
• Record authorized go-live or change approval, including conditions and outstanding actions.

Schedule reviews and trigger additional assessment after schema changes, application upgrades, repeated exceptions or changed manufacturing dependencies. Record the review outcome, action owners and due dates. Use the eight FAQs below to investigate specific gaps.

As a practical review objective—not a compliance promise—can a reviewer trace a selected manufacturing decision to the applicable sample, test, specification version, reviewed result revision and interface-processing history?

Which requirements should the interface assessment start with?

Start with the product, jurisdiction, intended use and records supporting the manufacturing decision—not the interface protocol. Use the regulatory applicability map to distinguish binding obligations from official guidance and site-selected controls. As a practical scoping rule, assess each use separately when one connection serves several product families. For example, a result used only for process trending and the same result used to support disposition need separately documented decision impacts. Record who approves that assessment and revisit it when manufacturing begins relying on a previously informational field.

Is a matching batch number enough to accept a result?

Treat a batch-number match as one check, not the acceptance decision. A practical rule is to reject or quarantine an association when the sample, test or manufacturing context remains ambiguous. For example, two samples from one batch may represent different sampling points; accepting either result into the same field could conceal that distinction. Follow the sample login handoff through to the receiving record, then check result meaning. Include units, qualifiers and conversion rules in that check. A numerically plausible value should not bypass an unresolved identity or unit mismatch.

Should a delivered result clear a manufacturing hold?

Use the decision conditions defined under state synchronization, rather than treating message arrival as permission to proceed. Consider a result delivered successfully while its laboratory review remains pending. The receiving workflow should follow the configured pending-review path, with an accountable person resolving any mismatch between systems. Test the point where a user attempts the manufacturing action, not just the screen displaying the result. Include stale status information in the scenario: an earlier accepted message should not substitute for the current state needed by the authorized human decision-maker.

How should a corrected result affect an earlier decision?

Make the correction visible without silently rewriting the history of the earlier decision. A useful review rule is to identify every affected decision and assign an owner to assess its continued validity. For example, revision two may arrive after a manufacturing step was authorized using revision one. Preserve which revision supported that authorization, route the new revision for assessment and document the outcome. Apply the revision relationships described in version governance. Test that the revised record remains distinguishable from a duplicate resend of the original, including when messages arrive out of order.

What evidence shows that a retry was handled correctly?

Look for evidence at the business-record level, not merely another successful transport response. Suppose the receiver commits a result but the acknowledgement is lost. A useful acceptance test resends the same transaction and demonstrates one intended result revision, a recorded duplicate-handling outcome and a recoverable acknowledgement. Distinguish that retry from a genuinely corrected result. Link sender attempts, receiver processing and the resulting manufacturing record in the test evidence. The change-validation approach should also cover interrupted recovery, so restarting an interface does not leave an apparently successful but unresolved transaction.