Chromatography data integration with LIMS and batch records

Reconcile repeated exports and revised analyses

Treat the following as a receiving contract to agree with the installed CDS. The source must establish an analysis and evaluation identity; these labels are illustrative, not vendor column names. Retain each delivery while allowing the scientific result population to grow only for supported new evidence.

Four deliveries represent one repeated export, one revision and one conflict.

Instrument INS-04 exports analysis AN-903 from run RUN-903. The source contract supplies an analysis identity and revision. H-A and H-B are short illustrative content fingerprints, not real cryptographic hashes. Original file bytes are retained.

Scroll across to see every column →

Illustrative connection records
Delivery	Source identity / revision	Content evidence	Import decision
DEL-903-01	INS-04 / AN-903 / r1	H-A	Create the original source revision and its result mapping
DEL-903-02	INS-04 / AN-903 / r1	H-A	Record another delivery of the existing revision
DEL-903-03	INS-04 / AN-903 / r2	H-B	Create a linked revision for review
DEL-903-04	INS-04 / AN-903 / r1	H-B	Hold as conflicting content under the same revision identity

There are four delivery attempts, two identified source revisions and one unresolved identity conflict. The original and revised analyses remain distinguishable. Neither a matching filename nor a shared run number is enough to decide which result a reviewer should use.

Download the source example

Trace the mapping and recovery decisions

Agree the source key with the installed system.

Ask what identifies an analysis, its revision and each row within it. A run can contain several samples and results; using only RUN-903 as the result key can collapse legitimate records. Scope identifiers to the source system or installation when the vendor can reuse them elsewhere. Preserve leading zeros, case or punctuation unless the documented source contract makes them irrelevant.

Some exports supply no revision identity. In that case, define a documented receiving convention and keep the uncertainty visible. Do not imply that a changed byte fingerprint proves a new scientific analysis: a regenerated report may differ only in its export timestamp. Conversely, identical result values do not prove that two independently acquired analyses are the same event.

Use content evidence to detect both repeats and conflicts.

A fingerprint of original bytes helps establish that DEL-903-02 repeats the same retained content. Record the algorithm and the point at which it is calculated. If a connection also computes a normalised-content fingerprint, document what it excludes and retain the original bytes. Removing timestamps, sample labels or result qualifiers during normalisation can erase differences that matter.

DEL-903-04 claims the existing r1 identity but brings different content. Preserve it as a conflict for source review. Do not overwrite r1 or silently relabel the delivery r2 to make the import succeed. Resolution may establish a source export problem, an incorrect identity field or an allowed regeneration; the receiving history should show which evidence supported the conclusion.

Make retries find the result of the original import.

A retry may arrive after the source File was saved but before all destination results were created. Retain an import progress record that identifies the expected result population and the results actually written. Recovery should reconcile those identities and finish missing work under the agreed rules, rather than create a second complete population.

Test concurrent delivery as well as sequential replay. A simple “search, then create” implementation can let two workers both find no prior record. Confirm the connector’s supported mechanism for exclusive identity creation or serialised processing. This needs implementation in the import path; adding an identity Text field to a Seal Template alone does not make the operation atomic.

Count the missing rows after an interrupted import.

Extend AN-903/r1 with four expected result identities: injection 1/main, injection 1/impurity, injection 2/main and injection 2/impurity. Suppose the first attempt retains the file and writes the two injection-1 results before it stops. A useful recovery ledger names all four intended identities, links the two created records and marks the two injection-2 outcomes unresolved. “File uploaded” and “2 rows created” are not enough to decide which work remains.

On replay, query each unresolved identity under the same source revision and mapping revision before creating it. A response may have been lost after a write succeeded. The completed ledger should account for four intended results, four matching receiving records and no unresolved outcomes, while retaining both delivery attempts. If an existing result has conflicting content, report that conflict instead of increasing the expected count or inventing a new revision.

Keep rejected and intentionally excluded rows in the ledger with their reasons. Four parsed rows and three accepted rows can be a correctly reported incomplete import; calling it complete because the file parser returned successfully hides the exact work the laboratory still needs to resolve.

Separate retained evidence from the selected result.

Configure Delivery, Source revision and Import reconciliation Templates in Seal with References between them and the analytical result records. Retain mapping-version evidence so a later parser change can be distinguished from a source-analysis change. The delivery count can then grow during recovery without presenting extra scientific results.

Keep the review decision selecting a result separate from the arrival of a newer file. A proposed result-review Check can require a resolved source identity and completed import reconciliation. Receipt itself must remain recordable for an ambiguous or rejected export, because that evidence is what lets the laboratory resolve the problem.

Inspect the proposed fields and acceptance cases

Adapt these fields to the receiving connection. The cases describe expected behaviour to verify with the configured interface.

Download the field list · Download acceptance cases

Delivery receipt

Retain collection attempts even when they do not create a new analytical result.

Delivery ID — Text: One receiving identity for each collection attempt.
Received at — Time & date: The actual arrival time, distinct from analysis time.
Source system — Reference: INS-04 or the configured instrument-system identity.
Original file — Reference to File: The original delivered bytes and filename.
Content fingerprint — Text: A connection-generated fingerprint under an explicitly defined algorithm.

Source analysis revision

Identify the scientific source record the file claims to represent.

Analysis identity — Text: AN-903 scoped to its source system, rather than a globally assumed name.
Source revision — Text: r1 or r2 when that concept is supplied by the source contract.
Previous revision — Reference: The earlier analysis revision where the relationship is supported.
Delivery evidence — Reference, multiple: All deliveries associated with this source revision.

Import reconciliation

Explain the result of matching a delivery and retain conflicts.

Delivery and source revision — References: The two identities being reconciled.
Decision — Select: New revision, repeated delivery or unresolved conflict in this design.
Mapping revision — Text / Reference: The parser and mapping definition used for the import.
Result records — Reference, multiple: Only the records actually produced or already established.
Conflict evidence — Text / References: Why the content and claimed source identity do not agree.

Two collectors deliver together

Input: Deliver r1 with H-A concurrently through two receiving attempts.

Expected: Both attempts remain attributable while the implemented import contract creates one source-revision identity and one intended result population.

Recovery after partial import

Input: Interrupt an import after some result records exist, then replay the same delivery.

Expected: Recovery identifies existing rows and resolves the missing population without duplicating completed rows.

Changed bytes under an old revision

Input: Send DEL-903-04 claiming r1 with H-B.

Expected: The original r1 evidence and results remain intact. The new delivery is visible as an unresolved conflict.

Apply this to your records

Use a repeated delivery, a supported later evaluation and an interrupted import from the same installed source. Account for delivery attempts separately from scientific results.

Download the blank working review

Write your working notes here

Notes stay in this tab and are not submitted. Download them before leaving to keep a copy. Use record references to identify your evidence.

Source identity contract

Name the source installation, analysis, evaluation/revision and row identities. Explain how the installed export distinguishes a re-export, reprocessing and an independently acquired result. Record any identity gaps.

Delivery and content evidence

List retained delivery files and original-byte fingerprints with the algorithm used. If a normalized-content comparison is used, identify its exclusions. Record same-identity/different-content cases separately from harmless repeat delivery.

Expected-to-received row ledger

List every expected source result identity and its destination record or unresolved outcome. Include rejected/excluded rows with reasons and the mapping revision used. Count parsed, accepted and unresolved rows separately.

Interrupted and concurrent delivery outcomes

Record which rows existed before replay and which exact targets were queried before creation. Test concurrent attempts as well as sequential replay. Identify the actual uniqueness/serialization mechanism; a text field alone does not make creation atomic.

Reconciliation and result selection

State whether the intended population is completely reconciled and identify conflicts or missing outcomes with owners. Record the reviewer’s selected evaluation separately from the arrival of the latest file.

Unanswered sections remain marked ‘Not recorded’ in the download.

Evidence needed to finish

Every intended result is accounted for by identity, all delivery attempts remain attributable and retry does not create another scientific population. Conflicting content is resolved explicitly; import completion and analytical result selection have separate decisions.

Decide whether you need the curve, the peaks or the fractions.

Purification and analytical chromatography need different records. An ÄKTA purification workflow may link a run to a column, collected fractions and subsequent concentration or purity tests. An analytical CDS workflow may link an injection to a sample, method, analytes and evaluated peak results. A single generic ‘chromatography result’ field loses these relationships.

Keep the source export as a File and choose the values people need to compare as typed fields. A peak area, retention time and reported concentration have different meanings and units. Store their labels and evaluation context explicitly. A displayed percentage is not automatically product purity: establish which denominator, integration boundaries and calculation produced it.

Collect completed exports from the chromatography workstation.

Confirm the export or reporting options available in the installed vendor software. The provider guides below describe the relevant source evidence; the exact file layout depends on version and configuration. A PDF can preserve the reviewed report, while a structured result table may be the more suitable input for a mapping Script. Do not assume that every vendor project or archive is a readable results table.

For workstation files, configure Seal IoT to collect a completed export from a dedicated handoff folder. The site computer sends files to Seal; a cloud Script does not read the workstation’s drive. Keep acquisition and evaluation in the vendor software, and test how the export is marked complete before enabling unattended collection.

Map source identities before analytical values.

Use the source system, run or sequence, injection, sample and evaluation revision to resolve the destination record. A filename or sample display name alone can collide across experiments. Where a sample has several injections, retain the injection identity rather than repeatedly overwriting one sample-level result.

For purification, connect fraction identifiers to the run and collection boundaries. Keep whether the curve’s horizontal axis is time or volume, including its unit. Converting between the two requires appropriate flow history. If only a reduced curve is exported, preserve that fact and its coverage instead of presenting it as the complete acquisition.

Make reanalysis and duplicate delivery distinguishable.

A repeated upload of the same export should not create another analytical result. A revised evaluation, however, may legitimately change a peak boundary, identification or calculation. Configure the Script to recognize the original source identity and content, then retain the revision relationship when new evaluated evidence arrives.

Decide how a reviewed result can be superseded in the receiving workflow. Preserve the prior evidence and identify the evaluation used for a report or batch decision. Importing a new value should not silently imply that a reviewer has accepted the change.

Test it with your data.

Use these cases to agree and test the connection’s behaviour. They are proposed acceptance checks, not completed tests or automatic connector features.

The curve and fraction bounds use different axes

The curve is exported against minutes, while fraction collection boundaries are in millilitres.

Expected behaviour: Retain both axes and units. Only align them using an agreed conversion with the necessary flow information.
Evidence to keep: Original coordinates, collection bounds, source units and any documented conversion.

A file is delivered twice

The same source run and evaluation are uploaded again after a connection interruption.

Expected behaviour: Resolve the delivery to the existing analytical evidence under the configured identity rule. Do not count it as another run.
Evidence to keep: The source identity, content comparison, import outcome and unchanged analytical record count.

More checks for this connection

Compare a known run’s exported axes, first and last coordinates and point counts with the vendor view.
Check one fraction or sample with two injections so the mapping cannot collapse them into one result.
Deliver the same file twice, then a revised evaluation. Verify one result for the duplicate and a traceable revision for the change.
Try an unknown sample and an unexpected column layout. Hold the import for resolution instead of guessing the destination.

Before you connect

Can this send chromatography results to an existing LIMS?

Seal can be configured to map the source evidence into its records and exchange agreed result fields with a LIMS through that system’s supported interface. The LIMS write operation, sample identity and result status need a separate mapping and acceptance test; collecting a chromatography file does not establish that downstream connection.

Does Seal replace UNICORN, Empower or another CDS?

This workflow leaves instrument control and chromatographic evaluation in the vendor application. Seal holds connected evidence and selected results for work across samples, experiments and review processes.

Check your system’s connection options.

Confirm the installed version, available exports and permissions. These pages cover the source interface and link to setup instructions.

For configuration: Seal Scripts and local-file collection.

Start with one export.

Bring the source evidence and the records it needs to connect to. For this workflow, a useful starting pack is:

A source export and the report a reviewer uses for the same run.
Run, injection, fraction and evaluation identities relevant to the chosen workflow.
The target sample or experiment and the exact values people need to compare.

Discuss this connection