hidden hidden hidden hidden hidden hidden hidden hidden
Oxford location
view map

Edmund Cartwright House, 4 Robert Robinson Avenue
Oxford Science Park, Oxford, OX4 4GA, UK

Tel: +44 (0)845 034 7900 | Fax: +44 (0)845 034 7901

Cambridge location
view map

Suite 4, The Mansion, Chesterford Research Park
Little Chesterford, Essex, CB10 1XL, UK

Tel: +44 (0)845 034 7900 | Fax: +44 (0)845 034 7901

Contact us
more

If you have any enquires or questions, feel free to get in touch with Oxford Nanopore.

Follow us on Twitter
  • Technology
GridION™ workflow

The GridION™  system is designed to improve overall workflows. For further information, watch our movies GridION 2: Workflows and GridION 3: Advanced workflows.

Sample preparation
DNA-sequencing applications are designed for simple and low-cost sample preparation with no need for sample amplification. Protein analysis and other sample preparation processes are also designed for ease of use.

Experiment management and informatics
A simple user interface and accompanying bioinformatic software are designed for easy management of experiments. Informatic analyses run as the experiment progresses and provide feedback into the progression of the experiment.

Samples can be run individually on a single node, or shared across multiple nodes, giving flexibility in prioritisation and time-to-result. This means the GridION system is designed to suit any workflow in any laboratory at any scale.

Workflow versatility: no fixed run time

A key feature of the GridION™  system and MinION™ device is that there is no fixed run time; a user can run one or more nodes for minutes or days according to how much data is needed to complete the experiment. A MinION will have a total available run time of hours.  Moreover, real-time analysis means that the user can predetermine an experimental endpoint and run the system for as long as it takes to collect sufficient data to address that question.

During an experiment, each nanopore on the array sensor chip analyses molecules in the sample independently of the other nanopores. Experimental data from each nanopore is streamed in real time.

The shortest time to start collecting experimental data is the time taken for one analyte molecule to successfully interact with one nanopore in the array. This may be as quick as a few milliseconds for a single molecule like a protein. Or, in the case of polymers like DNA, a single molecule may take a period of time to pass through the nanopore, so dependent on fragment length, this first complete read may take milliseconds to seconds. During the run, each nanopore samples many analyte molecules from the surrounding solution, and additional complete reads are collected.

Data analysis takes place in real time as data streams from cartridge to node in parallel from multiple nanopores. Therefore, a longer run enables more data points to be collected, more confidence about an observation to be achieved, more measurement accuracy to be obtained, and a greater range of analyses to occur. For example, running a nanopore sensing experiment for ten minutes would yield ten minutes of measurement data. If the same system was run for a week then this would deliver one thousand times the volume of data; simply a bigger file of analysed data.

A GridION™ system can therefore be run for seconds or days, as required, to complete the experiment for a particular application.
 

Run until... sufficient data

The GridION™  system and MinION™ device are designed to enable users to run an experiment until sufficient data has been collected to reach a predetermined experimental endpoint. In contrast, other molecular analysis systems have a fixed analysis time, or ‘run time’ that delivers a surged batch of data at the end of that run. In such cases the user is forced to design the experiment to fit the machine that the analysis is performed on.

Conversely, by making use of the properties of nanopore sensing and rapid electronic measurement, users can instruct GridION nodes or the MinION to monitor their own data output and look for key application-specific results. These results may be used to alter or optimise the behaviour of the instruments in real time, or simply stop them when the experiment is known to have been completed. For example, a node or a cluster of GridION nodes can be instructed, through on-board software, to Run until... a certain datum has been seen a certain number of times at a specified confidence level. In this way, the experiment is defined by the user, not defined by the machine.

Using the multi-well plate-adapted cartridge allows the system to process a series of experiments autonomously on different samples; the system simply runs one sample from the first well, and once completed, the node can automatically move onto the next sample to run another experiment.

A node or a cluster of nodes can be instructed to Run until... certain user-specified criteria have been met, for example:
•    DNA sequencing: the GridION system may process the sample until they have seen a minimum of tenfold read coverage over specified regions of interest, until a specific mutation has been observed in a sample or until enough sequence data has been collected to reliably assemble a sample against a reference.
•    Protein analysis: the GridION system may process the sample until the presence of a specific analyte has been determined to a certain confidence level, and process the sample further to determine its concentration.
•    Small molecules: the GridION system may process the sample until it has determined that a specific analyte (for example a reactive molecule such as an explosive) was NOT present in the solution, to a pre-set confidence level.

Some of these completion criteria can be set and measured by the on-board software, while others can be programmed into real-time analysis workflows running on separate computing. Because data is streamed from the system in real time, whole end-to-end real-time informatics can be run in parallel to the data generation.

During the experiment, data about the analyte is streamed in real time from the nodes. This can be supplied to software services on the user's system for real-time bioinformatic analyses during the experiment. These analyses can monitor for key success criteria. The system can then feed back, through the node's or cluster's API, to instruct the systems to stop when the application has been successful, or to adapt other settings in order to make it successful.

This has the added benefit that the user can monitor system performance and experimental progress in real time and use this information to make changes to the system during an experiment. It also means there is no wait at the end of the run for a large data file to be processed by a bioinformatics pipeline.

Sample-scheduling and multiplexing

The GridION™  system is designed to allow the user flexibility over how fast they reach the endpoint of their experiment; a sample may be processed on one node or shared across several nodes.

Coupled with 96-well plate-based sample management, a cluster of GridION nodes can dynamically prioritise and re-prioritise the order in which samples are being processed, and the time spent processing those samples.

For example, the system may be instructed to scan a 96-well plate, initially processing a small amount of sample from each well. The GridION system will then have the necessary information to calculate the processing time required for each sample in order to gather enough data to meet the pre-defined experimental endpoint.

This has a variety of implications for efficiencies of workflow. For example:

  • In a core facility operation, users may have attached priority settings to each sample. The system can then re-order the sequence of wells it processes within or across nodes to ensure that users or customers get their data on time, or to a preset schedule.
  • The clustered system will still automatically aggregate and output data from the same sample even when analysed from different wells on different nodes.
  • Different nodes can be used to process 'late-entry' samples, still ensuring that system bandwidth is maximised, while user-prioritisation and application-success criteria can be met.