Skip to content

HTS Bioinf - NIPT Software

Summary

This document describes the NIPT software system.

Responsibility

HTS bioinformaticians are responsible for developing and updating the in-house components of the NIPT software system. Illumina is responsible for the VeriSeq NIPT Solution v2 software.

The NIPT Software has three major components:

  1. Clarity Integration and Automation
  2. VeriSeq NIPT Solution v2
  3. SWL Integration

Clarity Integration and Automation

The Clarity Integration and Automation software is built around Illumina's VeriSeq NIPT Integration v1.0 Clarity module (described in VeriSeq NIPT Integration v1.0 - User & Configuration Guide.pdf). This module comes with a Clarity workflow named "VeriSeq NIPT v1.0" and an automation system installed on a LIMS server.

However, the workflow and the automation system do not fully meet our needs. Thus, we developed a new Clarity workflow, including a companion in-house Clarity automation system, that:

  • Combines the "Clarity batching" approach with an "ad-hoc batching" approach. Officially, one of the two should be used. Each has its own benefits and involves some manual work. The combined approach exploits the benefits of the two individual ones while limiting the manual work to the minimum.
  • Tracks reagent lots and instruments in Clarity LIMS.
  • Allows duplicated samples (containers) in Clarity, e.g. for reanalysis.

VeriSeq NIPT v1.0_EHD Workflow

The original "VeriSeq NIPT v1.0" workflow is composed of one protocol with the same name. The protocol has 2 steps:

  1. Generate Batch & Input Sample Sheet (VeriSeq NIPT v1.0)
  2. AUTOMATED – Data Analysis (VeriSeq NIPT v1.0)

To track instruments such as the Hamilton robot, the PCR machine etc., and sequencing reagents, the original protocol was extended by the additional step "Register NIPT Instruments v1.0 ".

The new protocol comprises therefore 3 steps:

NIPT-1

The following instruments and reagents are tracked in step 2 of the "VeriSeq NIPT v1.0_EHD" workflow:

NIPT-2

In-house Clarity Automation System

In addition to the original automation system that comes with the Illumina VeriSeq NIPT Integration v1.0 module, there is an in-house automation system composed of four modules:

  1. duplicate_handling
  2. ad-hoc_batching
  3. fc_reports
  4. lot_instrument_tracing

Each module is run as a cron job on the LIMS server. Each module monitors one or more reports generated along with the progress of a NIPT batch.

Ad-hoc batching module

The VeriSeq NIPT Solution v2 officially supports two batching approaches which are mutually exclusive.

The "Clarity batching" approach requires that a lab engineer manually assigns all selected samples (e.g., 23, 46 or 92 samples) in Clarity to a batch and goes through the 1st step ("Generate Batch & Input Sample Sheet") of the "VeriSeq NIPT v1.0" workflow manually. Upon completion of this step, a sample sheet text file containing metadata (already in Clarity) for all samples will be generated. This approach requires that the lab engineer picks up exactly the same set of samples from storage to load onto the Hamilton robot.

The "ad-hoc batching" approach allows loading a rack of "random" samples onto the Hamilton robot but the metadata of the samples must be typed in manually on the Hamilton robot's control computer. Alternatively, a pre-made sample sheet containing metadata for all samples can be supplied.

The combined "Clarity ad-hoc batching" approach allows the lab to load a rack of "random" samples onto the Hamilton robot and automatically receive a sample sheet containing all samples and their metadata registered in Clarity.

  • The lab starts with loading a rack of "random" samples.
  • An ad-hoc batch initiation report with barcodes (the same as sample name and container name in Clarity) for all samples will be generated in the "output" share of the VeriSeq Onsite Server (VOS) which is mounted on the LIMS server.
  • The ad-hoc batching module monitoring the "output" share will pick up the batch initiation report and confirm that all samples are in the "Generate Batch & Input Sample Sheet" queue.
  • If not, it waits and tries again later. If yes, the module automatically assigns all samples contained in the report to a batch in Clarity and goes through the "Generate Batch & Input Sample Sheet" step.
  • The sample sheet will then be generated and placed in the "NIPT-Lab" share of the Windows server "Endpoint", which is accessible from the Hamilton robot's instrument control computer for pooling.

This module completes the "Generate Batch & Input Sample Sheet" process and forwards all samples to the 2nd step ("Register NIPT Instruments v1.0") of the NIPT workflow.

The lab completes the 2nd step of the workflow manually where instruments and sequencing reagents are registered. Once this step is completed, the samples will be queued in the 3rd step ("AUTOMATED - Data Analysis").

fcs_reports module

By default, the File Capture Service (FCS) installed on the LIMS server monitors the "output" share of the VOS. FCS detects different types of newly generated reports, such as batch initiation reports, sample invalidation reports, NIPT reports etc., checks if all samples in the report are in the required state in Clarity, and (if yes) triggers an action to move the samples forward in the NIPT workflow.

For example, if a new batch initiation report is detected, FCS verifies that all samples are in the "AUTOMATED – Data Analysis" queue. If yes, the "AUTOMATED – Data Analysis" step is started automatically. If not, it tries again later. However, there is a time limit for all samples to be the required state after a new report is detected. If the time limit is reached, the report will be ignored, causing the NIPT workflow never to complete.

This problem becomes significant with the addition of the "Register NIPT Instruments v1.0" step.

The fcs_reports module solves this problem.

FCS is configured not to monitor the "output" share directly. Instead, the fcs_reports module detects new reports and verifies that all samples in a new report are in the required state in Clarity. If not, it waits and tries again later. If yes, the fcs_reports module copies the new report to another directory which is monitored by the FCS. See an overview in:

nipt-diag-1

Details are in:

nipt-diag-2

lot_instrument_tracing module

The lot_instrument_tracing module monitors new library reagent reports and registers the reagent lots to the corresponding "Generate Batch & Input Sample Sheet" process's UDFs. The following reagent lots are registered:

NIPT-3

Duplicate Handling

Duplicates are handled by the duplicate_handling module together with the fcs_reports module.

NIPT samples are exported from SWL and then imported into Clarity without filtering. So a sample can be exported from SWL and imported into Clarity multiple times giving rise to one or more duplicates in Clarity. This is because a sample will always be exported from SWL unless its analysis is completed.

A duplicate in Clarity causes failure at the 3rd step of the NIPT workflow.

Any sample that has been registered more than once (in different projects) is considered as duplicated. But depending on the specific scenario, the handling approach of a duplicate may differ.

The duplicate_handling module periodically checks if a sample queued in the 1st step of the NIPT workflow is a duplicate and should be deleted automatically:

  1. The sample was included in a previous project, went through the NIPT workflow and passed QC. The queued sample will be deleted.
  2. Multiple instances of the sample (same sample in different projects) are queued in the 1st step. The older one will be deleted.

There are duplicates that cannot be deleted and need to be handled differently:

  1. The sample went through the NIPT workflow and passed QC, but was re-queued or re-added to the NIPT workflow. The queued sample cannot be deleted because actual work was performed on it. Instead, the sample should be removed from the NIPT workflow manually.

  2. The sample was included in a previous project and entered the NIPT workflow but did not go through it or went through it but failed QC (this is typically the case for reanalysis). The fcs_reports module handles such duplicates as follows:

    • If the module is processing a new NIPT report, it renames the containers of all other instances of the sample by appending a "_NIPT" to the container names.
    • If the module is processing a new batch initiation report, it resets the name of the container of the current instance (i.e. it removes the "_NIPT" suffix if any) so that the sample sheet has the original container.

VeriSeq NIPT Solution v2

The VeriSeq NIPT analysis is done by the VeriSeq NIPT Solution v2 Assay Software running on the VOS. Once a sequencing run is finished, the data analysis starts. Once the latter is finished, NIPT report(s) containing analysis results for each sample will be generated and placed in the "output" share of VOS. Details of the software is in veriseq-nipt-solution-v2-software- guide.pdf.

SWL Integration

The SWL integration system contains two components:

  1. SWL Clarity Integration service. This service is supplied by Sykehuspartner and is developed by Nexus (the supplier of SWL). This is not in the scope of this procedure.
  2. In-house swl_integration module.

swl_integration module

The swl_integration module is run as a cron job on the LIMS server. It monitors new NIPT reports, interprets the reports with predefined rules and generates an interpreted NIPT report (.tsv file) in a format compatible with the SWL Clarity Integration service. As a backup solution, the interpreted report is also available as a .csv file which can be opened in Excel.

Details of the predefined interpretation rules and the format of the report are described in:

nipt-diag-3

The interpreted report is put in the "NIPT-Lab" share of the Windows server "Endpoint" and is accessible from the Hamilton robot's instrument control computer. This report is copied to the OUS network with an ironkey to be imported into SWL by the SWL Clarity Integration service.

All in-house software modules are version-controlled in a Gitlab repository.

References

Gitlab repository: https://gitlab.com/DPIPE/variantcalling/nipt

Documentation

  • VeriSeq NIPT Integration v1.0 - User & Configuration Guide.pdf
  • veriseq-nipt-solution-v2-software-guide.pdf
  • whole_workflow_overview.pdf