WET Lab and Bioinformatics Integration for NGS Labs

In complex molecular and genomics workflows, answering it can require reconciling records across multiple systems and handoffs. CAP materials emphasize the need for positive specimen identification, specimen tracking, chain-of-custody procedures, quality management, and records that support traceability across laboratory activities.

CAP’s Laboratory Accreditation Program standards and CAP specimen-handling guidance describe the importance of traceable specimen records and chain-of-custody information.

The WET lab may have the plate map. The LIMS may have the accession record. A run-level metadata file may have the sample and barcode mapping. Bioinformatics may have the FASTQ files and pipeline run IDs. Quality staff may have QC decisions in another application or spreadsheet.

Each team has part of the story.

The problem appears when a sample fails QC, an index is suspected to be wrong, a library needs to be re-pooled, a case must be re-run, or a final report needs a traceable path back to the specimen and run. The lab then has to reconstruct the chain through emails, file names, shared drives, spreadsheets, and staff memory.

This is not only a data-management issue. It affects traceability, rework, turnaround time, release confidence, and the ability to investigate an exception.

CAP describes its accreditation checklists as “living blueprints” used by laboratories and inspectors to support quality and patient safety. Its 2025 checklist summary includes specimen collection and handling, quality management, chain-of-custody specimen collection and handling, specimen transport and tracking, and result reporting.

CAP Accreditation Checklists and the CAP 2025 Checklist Summary identify these as relevant laboratory quality areas.

The Handshake Fails When the Data Objects Do Not Match

Most labs do not lose the connection between the WET lab and bioinformatics because a single system stops working.

They lose it because the systems use different representations of the same sample.

The WET lab may identify a specimen by accession number and plate position. Bioinformatics may use a sample ID, lane identifier, barcode sequence, run folder, and FASTQ filename. The reporting workflow may use a clinical case ID. The ordering system may use a requisition or EHR order identifier.

Those identifiers can all be correct. They can still fail to resolve to one reliable case record.

A shared data model defines the objects, identifiers, relationships, and status events that both the WET lab and bioinformatics team use.

A run-level sample sheet or sequencing metadata file is often the bridge between these worlds. It links the library or sample identifier to barcode or index information and to the files or run context that the pipeline will process.

Independent published work on demultiplexing describes the same core principle. Multiplexed NGS analysis separates raw data into sample-specific files using sample-specific barcodes. Ultraplex, published in BMC Bioinformatics, describes demultiplexing as the splitting of raw sequencing data into separate files through sample-specific barcodes.

The technical detail matters because a barcode is not merely a technical setting. It is part of the lab’s evidence chain.

A Plate Map Cannot Be Treated as a Spreadsheet Artifact

Plate maps often begin as a practical WET-lab tool. They show where samples, controls, libraries, and blanks sit in a plate or batch.

That is useful. It is not enough.

For clinical or high-complexity testing, a plate map should be treated as a governed workflow record. It needs to connect:

• The specimen or accession
• The plate ID
• The well position
• The library preparation batch
• The barcode or index pair
• Control and blank positions
• The assay or panel version
• The operator and relevant timestamp
• Any QC event or override
• The sequencing run
• The analytical case and report status

The point is not to add unnecessary complexity. The point is to prevent the lab from reconstructing these relationships after a problem occurs.

A plate map that exists only as a static spreadsheet creates several risks:

• A sample may be repositioned without a downstream update.
• A library may be re-pooled without a clear record of the original and revised assignment.
• An index may be corrected in the run metadata but not in the LIMS.
• A failed control may be visible to the WET lab but not reflected in the pipeline worklist.
• A sample may be excluded from analysis without a clear operational reason attached to the case.

A shared data model makes these changes first-class workflow events rather than undocumented edits in separate systems. In practical terms, the lab should represent a re-pool, well reassignment, index correction, sample exclusion, re-extraction, re-sequencing, or QC override as a linked event with its own identifier, timestamp, owner, reason, affected objects, and downstream status.

For example, if a library in Plate P-104, Well C07 is re-pooled after low yield, the workflow should not simply overwrite the original plate-map entry or sample-sheet value. It should preserve the original library assignment, create a linked re-pool event, identify the new pool or run assignment, record the reason and approver, and update the affected bioinformatics work item. The pipeline should then receive the approved current input state while the lab retains the history needed to explain how the sample moved from its original preparation record to the final analytical output.

To make this work in the toolset, define a common event structure across the LIMS, plate-management workflow, sample-sheet generator, interface layer, and pipeline orchestration system. At minimum, each event should include:

• The affected object, such as specimen, accession, library, plate, well, index pair, sequencing run, pipeline run, or clinical case
• The event type, such as re-pool, re-sequence, index correction, QC hold, QC release, sample exclusion, or re-analysis
• The previous state and approved new state
• The reason, supporting QC observation, or deviation reference
• The user, system, or role that created the event
• The reviewer or approver when the workflow requires one
• The timestamp and applicable assay, sample-sheet, pipeline, or report version
• The downstream actions required, such as hold analysis, regenerate a sample sheet, rerun demultiplexing, relaunch the pipeline, notify clinical review, or update reporting status

This is the operating difference between a shared data model and a collection of loosely connected files. The model does not merely store identifiers. It preserves the relationship and change history between physical laboratory work, sequencing metadata, computational processing, and case status.

Barcode Metadata Needs the Same Governance as Patient and Specimen Data

In multiplexed sequencing, each sample or library is associated with barcode or index information. That information allows raw reads to be assigned back to the relevant sample during demultiplexing.

Published NGS workflows describe using a mapping file that connects sample identifiers to barcode and primer information. Those files then drive demultiplexing and generate sample-level sequence files for downstream analysis. The GBSX study in PLOS ONE describes a tab-delimited parameter file with sample names and associated barcode information, followed by demultiplexed FASTQ files per barcode for use in analysis pipelines.

For a lab, this means index metadata should have the same governance expectations as other case data.

It should be:

• Versioned
• Validated before the run
• Linked to the applicable plate, well, library, and sample
• Preserved with the run record
• Reconciled with the pipeline input
• Protected from silent manual edits
• Available during deviation review and re-analysis

This is especially important when the lab supports multiple assay types, high sample volumes, multiple sites, or different teams handling sample preparation and analysis.

A sample sheet should not become a hidden source of truth. It should be generated from, reconciled with, or governed by the lab’s source records.

QC Events Need to Travel With the Sample

A common gap appears when WET-lab QC and bioinformatics QC operate as separate streams.

The WET lab may record DNA concentration, library yield, fragment-size distribution, contamination observations, plate-control status, or a manual hold. Bioinformatics may later record read count, coverage, contamination signals, duplication, mapping rate, uniformity, or variant-calling quality thresholds.

Both sets of signals matter. They should affect the same case state.

If a library fails a WET-lab QC gate, the pipeline should not process it as if nothing happened. If bioinformatics identifies a run-level or sample-level concern, the WET lab needs to see whether a re-pool, re-extraction, or re-sequencing action is required.

The shared model should link every relevant QC event to:

1. The object being assessed, such as a specimen, library, plate, run, or analysis output
2. The assay and workflow version
3. The rule or threshold applied
4. The measured result or observation
5. The decision was made
6. The person or system that made it
7. The downstream impact

This is not an argument for fully automated quality decisions. Clinical labs need defined policies, qualified review, and appropriate oversight.

It is an argument for making QC visible across the workflow. A QC event should not disappear once it leaves the team that created it.

The Pipeline Input Should Be Reproducible From Laboratory Records

A pipeline should not depend on a manually edited folder, an undocumented CSV file, or a naming convention that only one person understands.

A practical engineering pattern is to treat the sample sheet, run manifest, or equivalent run-level metadata package as a controlled workflow artifact rather than a manually maintained file.

The exact file format, schema, sequencing platform, and pipeline implementation will vary by assay, instrument, laboratory workflow, and bioinformatics stack. The underlying requirement is stable:

Pipeline input should be reproducible from governed laboratory records, not assembled from undocumented files or manual edits.

For a sequencing lab, that means the sample sheet or equivalent run-level metadata package should be generated from, reconciled with, or controlled by the laboratory’s authoritative records. It should preserve a traceable connection between the accession, specimen, library, plate and well, barcode or index pair, sequencing run, approved sample list, and pipeline input.

A controlled pipeline input package should also capture the version of the applicable assay configuration, sample-sheet logic, pipeline workflow, reference data, and approval state at the time the run is launched. This gives the laboratory a defensible way to answer a basic but important question later:

“What exactly did the pipeline process, and why was this sample included?”

This is NonStop’s engineering recommendation for building traceable WET-lab-to-bioinformatics workflows; laboratories should adapt the control design to their assay, intended use, quality system, and validated procedures

As a practical engineering recommendation, a sequencing laboratory’s analytical run package should include or reference the following:

• Run ID
• Assay and pipeline version
• Reference build and relevant annotation version
• Sample and accession IDs
• Input file checksums or immutable file references
• Plate, well, and library metadata where relevant
• Barcode or index metadata
• QC status at the time of launch
• The approved sample list
• Any exclusions, exceptions, or overrides

This does not mean every file must be duplicated in every system. It means the lab must retain enough linked evidence to show what entered the pipeline and why.

Build the Handoff Around Exceptions, Not Only the Happy Path

Most workflows are designed around a clean case:

1. The specimen arrives.
2. The sample is prepared.
3. The library is placed in a well.
4. The plate map is correct.
5. The run completes.
6. Demultiplexing assigns reads correctly.
7. The pipeline runs.
8. QC passes.
9. The case moves to review and reporting.

Real labs spend significant time on the exceptions:

• The wrong sample is assigned to a well.
• A sample requires re-extraction.
• The index pair is corrected after a review.
• A control fails.
• A library is re-pooled.
• One lane produces insufficient coverage.
• A pipeline input is incomplete.
• The case is removed from a run after the sample sheet is generated.
• Bioinformatics flags a sample that the WET lab marked as acceptable.

The handoff works only when these exceptions become first-class workflow events.

That means each exception should have:

• A case, sample, library, plate, or run relationship
• A defined category
• A timestamp
• An owner
• A decision or next action
• A resolution record
• A downstream impact on pipeline, review, reporting, and TAT status

What a Lab Should Review Before Adding Another Tool

Adding a new LIMS module, workflow app, or pipeline dashboard will not solve a broken handoff unless the lab first identifies which relationships are missing.

Start with a recent run that required manual reconciliation.

Trace the case from the original specimen to the final output. Then ask:

• Can the lab link the specimen to the accession, plate, well, library, barcode, run, and pipeline output?
• Can the lab identify the source of each identifier?
• Can the lab see every QC event that affected the sample?
• Can the lab distinguish a re-run from a re-analysis?
• Can the lab show which pipeline version processed the sample?
• Can the lab identify which test or assay version was applied at the time?
• Can the lab explain why a sample was included, excluded, held, re-pooled, or re-sequenced?
• Can the lab trace an output back to the physical and clinical source record?

The answers show whether the lab needs better configuration, an integration layer, a shared data model, or a broader custom workflow capability.

The Handoff Becomes Reliable When the Lab Shares One Case Story

A sample moves through physical and digital states.

The WET lab sees the physical work. Bioinformatics sees files, metadata, and computational jobs. The clinical team sees a case and a report. Operations sees queues and TAT. Each view is valid.

The lab needs them to describe the same story.

NonStop engineers the data and workflow layer that connects WET-lab operations, LIMS records, bioinformatics pipelines, clinical review, reporting, and result delivery.

NonStop builds custom lab workflow systems for sample accessioning, instrument integration, and report management. NonStop also designs the integration layer that connects those systems to clinical genomics workflows and cloud or HPC infrastructure. NonStop’s genomics infrastructure and integration services cover lab-system integration, pipeline engineering, cloud infrastructure, and clinical-genomics workflow requirements.

Map the WET-Lab and Bioinformatics Breakpoints Before They Affect Reporting

The right next step is not automatically a replacement project.

It is a workflow review that traces sample identity and QC evidence from specimen receipt to final output.

A focused review should identify:

• Where plate maps, sample sheets, LIMS records, and pipeline inputs stop matching
• Which identifiers need a durable crosswalk
• Which QC events are isolated from downstream workflow decisions
• Which exceptions depend on manual reconciliation
• Which metadata must be versioned and preserved
• Which WET-lab and bioinformatics systems should remain authoritative
• Which workflow layer, integration, or custom capability is needed to close the gap

Frequently Asked Questions