Liquid handling integration for worklists and sample traceability

A transfer request with incomplete execution

The mapping preserves both the intended preparation and the evidence received. It does not infer success from a worklist.

Request
Preparation PREP-21
Retain the reviewed source-to-destination plan and its identity.
Planned transfer
Source P1/A1 → destination P2/B1
Store requested quantity and units separately from execution evidence.
Vendor execution
Run R-108 / partial
Preserve the source outcome and exceptions at the detail the report supports.
Destination record
P2/B1 / unresolved preparation
Link the evidence and route the incomplete outcome for review.

Agree each direction of exchange separately.

Begin with the data you need to collect: run identity, source and destination containers, steps, outcomes and exceptions available in the vendor output. Verify the installed software, licensed options and report configuration. A generic method file, protocol or input worklist may describe intended work without containing any execution evidence.

If dispatch is in scope, establish the exact supported worklist or import interface before generating files. Define who may prepare, review and submit a request and which software checks the instrument state. A Seal Script can prepare data for an agreed interface; that does not mean every listed instrument accepts arbitrary commands or supports remote start.

Trace containers, wells and material relationships.

A destination well should reference the source material and the run or operation that created the relationship. Preserve container identity as well as well address. If barcodes are available, verify their interpretation against the workflow; a manually entered plate label and a scanned barcode may have different provenance.

Define how pooling, splitting, dilution and repeated transfers affect the receiving records. One destination can have several contributors, and one source can feed several destinations. A single ‘parent sample’ field may be insufficient for a pooled preparation. Keep the transfer-level evidence needed to reconstruct that lineage.

Record actual outcomes at the granularity the source supports.

Keep requested volumes distinct from any executed or reported volumes. Do not invent per-transfer confirmation when the available report only states that a run completed. Capture warnings, skipped steps and failures with the source detail that is actually available. A completed protocol is not, by itself, evidence of extraction yield or another downstream assay result.

Connect downstream measurements through sample identity. For example, a prepared destination plate can later produce a plate-reader result; an extraction can later have a concentration or purity measurement. Those measurements belong to their own method and evidence, while their sample references preserve the connection to preparation.

Design recovery before enabling unattended exchange.

Give each intended request a stable identity and retain the vendor run identifier returned or found in the execution report. An upload retry must not become a second instruction to execute physical work. If dispatch succeeds but acknowledgement is lost, reconcile with the vendor workflow before resubmitting anything.

For result collection, retain source files until delivery and mapping succeed. Distinguish a duplicate execution report from evidence of a deliberate rerun. Decide how partial runs are represented and what requires operator resolution. The receiving record should show the unresolved state, rather than looking complete because one expected file arrived.

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 run stops halfway through a worklist

Twelve transfers were planned. The log confirms eight completed transfers before an interruption.

Expected behaviour: Record the eight confirmed transfers and retain the remaining four as unresolved or not executed, according to the source evidence.
Evidence to keep: The original worklist, per-transfer execution identities and reconciliation of all twelve planned transfers.

A retry repeats part of a transfer log

Recovery delivers previously received transfer events together with new completed events.

Expected behaviour: Match individual execution events, not just the log filename. Avoid recording the same physical transfer twice.
Evidence to keep: Stable event identities, duplicate decisions and the final source-to-destination sample lineage.

More checks for this connection

Compare a simple transfer and a pooled destination against the vendor evidence and resulting sample relationships.
Test a skipped step or partial run and verify that its destination is not marked successfully prepared by default.
Replay a result report and confirm that it does not duplicate transfers or dispatch another physical run.
Simulate an uncertain acknowledgement in a test workflow and verify that recovery requires reconciliation before resubmission.

Before you connect

Does a worklist export prove a transfer occurred?

No. A worklist records requested work. Use the available execution report or other vendor-supported evidence to establish outcomes, and keep the limits of that evidence visible.

Can this connect preparation to a plate-reader assay?

Yes, through a configured mapping of destination container and well identities to the subsequent assay’s sample layout. Test that mapping with a real preparation and assay pair; identical well addresses on different plates are not enough.

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:

The planned worklist, source and destination labware identities.
The execution log, including any skipped or failed transfers.
The sample map before the run and the rules for partial completion and recovery.

Discuss this connection