The Q-Line GridION™ is a compact benchtop sequencing system with integrated real-time data processing allowing up to five assays to be run either concurrently or individually.

This document provides guidance for the configuration of the Q-Line GridION device. It is intended for laboratory managers and IT administrators responsible for installing and maintaining IT infrastructure and equipment in your organisation. In most cases, the operations described here require the user to be logged in to a user account with IT administrator or Laboratory manager permissions, as specified in the relevant section introductions. Some procedures may also require access to local IT infrastructure or support from your organisation’s IT department.

For guidance on routine laboratory use of the device, refer to the Q-Line GridION user guide.

*Devices that have been upgraded from previous versions may have different technical specifications. Please refer to the original device user guide.

This table outlines the minimum requirements for installing the Q-Line GridION.

Recommended:

• Anti-malware: Install in accordance with institutional policy; ensure scans do not coincide with sequencing runs. Ensure that CPU-intensive activities such as system scans do not occur during sequencing and that files written during the sequencing process are not being checked at time of production.

• Laboratory information management system (LIMS): LIMS integrations are available. Refer to the Managing data section.

The shipment will contain:

• Q-Line GridION device
• 5 country-specific C13 cables
• 5 configuration test cells (CTCs)
• DisplayPort to HDMI adapter
• Quick Start Guide

Packaging:

The components of the Q-Line GridION:

The connections and ports available on the Q-Line GridION:

The Sequencing Software collects telemetry information if the Q-Line GridION is connected to the internet. This allows monitoring of device performance and enables remote troubleshooting. Some of this information can come from free-form text entry fields when errors are logged. Therefore, it is important that no personally identifiable information is entered into the sample sheet. No sequence data is collected by Oxford Nanopore Technologies. If you are running the Q-Line GridION offline and require troubleshooting, you will be able to send telemetry to Oxford Nanopore Technologies via an alternative route.

Nanopore sequencing data is stored in FASTQ, BAM or POD5 file types.

• FASTQ is a text-based sequence storage format, containing both the sequence of DNA/RNA and its quality scores. By default, nanopore sequencing experiments save up to 4000 DNA sequences in one FASTQ file.

• BAM files are output if you perform alignment or modified base calling on the basecalled dataset.

• POD5 is an Oxford Nanopore-developed file format for storing nanopore sequencing data in an easily accessible way.

The volume of data produced by an assay run will vary considerably depending on the assay being run. Please refer to the documentation for each assay for further details.

The Q-Line GridION has sufficient SSD disk space for multiple runs to be carried out, with data stored as FASTQ or BAM files. To prevent successive runs from terminating due to insufficient storage space you will need to transfer data to external storage by manual or automated means.

The Q-Line GridION runs on Ubuntu and can mount multiple filesystem types. We recommend storage presented as NFS or CIFS. Instructions on how to configure output locations and set up automatic offload to a network drive are included in this guide. You can also transfer data to USB drives. Only use trusted USB drives with the device. Instructions on mounting a USB drive are included in the Q-Line GridION user guide. Instructions on configuring USB mounting settings are included in this guide.

No specific network bandwidth is needed to continue sequencing. The bandwidth available for offload will need to be sufficient to keep up with the throughput of your device, which will depend on the assay you are running and the frequency at which you are running it.

On delivery of your Q-Line GridION, the initial installation will be carried out by an Oxford Nanopore Technologies representative. You may wish to refer to these instructions in the future if you need to reconnect or relocate the device.

Ensure that all items listed under Package contents above are present, and that IT requirements are met.

• Place the device on a strong, clean laboratory bench with 30 cm clearance to rear and sides of the device

• Ensure Ethernet and power connectors are in close proximity

• Ensure power socket is easily accessible should a disconnection be required in case of emergency

• Maintain a room temperature of +18°C to +25°C when operating the device

• Do not cover any ventilation grilles

Every time you boot up your Q-Line GridION, you will need to decrypt the device’s hard drive and log into a user account. The Q-Line GridION is shipped with a default encryption passphrase and account credentials; after the first time you log in, you will be prompted to change the password for the GridION user account. It is also highly recommended to change the passphrase and to begin working with an alternative IT administrator account in your own name.

The encryption passphrase is entered to decrypt the device’s hard drive. You will need to do this every time you start up your Q-Line GridION. We recommend changing the encryption passphrase when setting up your Q-Line GridION and using a different passphrase per device if you have multiple devices. Ensure that the encryption passphrase is safely retained.

Note: An account with IT administrator permissions is required to complete the actions in this section.

Note: An account with any permission level can be used to complete the actions in this section.

We advise you to run a position check to ensure your Q-Line GridION functions as expected. If an Instrument Performance Verification (IPV) and Operational Qualification (OQ) process has already been conducted, running a position check is not necessary.

Note: An account with any permission level can be used to complete the actions in this section.

Note: An account with IT administrator or Laboratory manager permissions is required to access user account settings. These accounts can only create and assign permissions to accounts at the same or lower permission levels.

Note: An account with IT administrator or Laboratory manager permissions is required to access user account settings. These accounts can only create and assign permissions to accounts at the same or lower permission levels.

Note: An account with IT administrator permissions and access to your organisation’s directory service (typically provided by your IT department) are required to complete the actions in this section.

You may only join one domain at any given time; the Q-Line GridION does not support multiple domains.

The tool /opt/ont/platform/bin/ont-platform-security-ad is used to connect (join) the system to an Active Directory (AD) or a Lightweight Directory Access Protocol (LDAP) domain. After the join is complete, domain accounts will be recognised by the platform, although logins using domain accounts are not enabled by default.

To join a system to a domain, you need to know the domain name, a domain administrator account and password. Depending on site requirements, you should know what type of user ID mapping will be used, if and how Windows SIDs from the domain are translated into Unix uid/gids, and whether all domain logins are allowed.

By default, no domain users will be able to log in until explicitly allowed. If you want to permit login access for all domain accounts, this must be specified when joining the domain. If you do not permit access for all domain users, you can allow individual domain accounts later.

Note: If the integration with Active Directory fails, reconnect to the domain again using the following instructions.

Connecting to an LDAP or AD domain can lead to errors due to configuration errors. The main items to check are:

• Time synchronisation is configured and active.
• DNS (Domain Name System) is configured and using an AD/LDAP domain server.
• The username used for the connection has domain administration rights.

These configurations account for most of the problems encountered when joining a domain.

To ease the process, ont-platform-security-ad --join will perform configuration checks automatically upon a join attempt. If the join fails, execute these checks manually.

The following advanced use cases are considered here:

• User ID mapping strategy differs from the default.
• The platform joins the domain within an OU inside the domain and not at the top level. All domain logins are permitted after joining the domain.

Using POSIX/RFC2307 user IDs

To use POSIX user attributes from the domain, in step 4 use the option --id-mapping-strategy POSIX

sudo /opt/ont/platform/bin/ont-platform-security-ad --join example.local --username john.smith --id-mapping-strategy POSIX

You will see an output similar to the one below. Enter your password when prompted:

Attempting to join domain example.local with username john.smith 
Password for john.smith:
SUCCESS! This system is now a member of the domain example.local

To join the platform to a specific organisational unit (OU):

To join to a specific OU within the domain, use the --ou option. Note that the order in which OU hierarchy is specified is bottom-to-top, i.e. specify the OU with the lowest level first, highest last.

For example, if the system should be added to the 'Research' OU within ‘Computer’ and the OU hierarchy is DOMAIN -> Computers -> Research, the OU argument should look like this:

--ou "OU=Research,OU=Computers"

Quote marks are essential if any of the OU names contain spaces.

Example command:

sudo /opt/ont/platform/bin/ont-platform-security-ad --join example.local --username john.smith --ou "OU=Research,OU=Computers"

You will see an output similar to the one below. Enter your password when prompted:

Attempting to join domain example.local with username 'john.smith'
Password for john.smith:
SUCCESS! This system is now a member of the domain example.local

This section will describe how to synchronise your AD or LDAP groups with the user account groups on the Q-Line GridION, including the native ont_it_admin , ont_lab_manager, and ont_lab_user groups.

Synchronisation can be carried out using either sync, which can add or remove users, or add which will only add users.

• add causes users in the AD group to be added to the Unix group. In this mode, if a user is removed from the AD group they will not be removed from the local group.
• sync maintains complete synchronisation between an AD and local group.

For example, users in the AD group will be added to the local group when they first appear and will be removed from the local group when they are removed from the AD group.

To use the feature, create a configuration file in /opt/ont/etc/ont-platform-security-group-sync.conf. For each group you want to sync, the configuration file should include a line in the format: <AD Group name or Group ID>:<the group name on the machine>:<either sync or add>

An example of the text from a configuration file is given below:

# Active directory group name:local group name:sync|add
Nanopore_Lab_User:ont_lab_user:sync
Nanopore_Lab_Manager:ont_lab_manager:sync
Nanopore_Lab_users:ont_it_admin:sync

Note: Only AD Groups without spaces are allowed. If your desired group has a space, use the Group ID instead. The AD and Local Group names must be different.

Once the configuration file is ready, run sudo /opt/ont/platform/sbin/ont-platform-security-group-sync to activate the synchronisation. To ensure that the correctly mapped group appears for your user, run: groups <Your AD Username>

The network parameters for your Q-Line GridION must be suited to your local network. The device should only be connected to a secure network.

Note: Your IT department should complete these instructions to configure your network, and will require an account with IT administrator permissions.

The Q-Line GridION uses a 1 x 1 Gbps copper interface to connect to your local infrastructure. This interface has a single port. By default, the IP address is configured to DHCP. However, static IPs are configurable. This connection will be used for:

• Sending telemetry* information to Oxford Nanopore Technologies.
• Receiving critical software updates to the device (optional; must be initiated manually).
• Streaming biological sequence data to your local storage infrastructure.

You will need 1 Gbps Ethernet cable on your device to connect to your Ethernet port, your device and your Local Access Network (LAN).

^{* The Sequencing Software collects telemetry information during sequencing runs per the Terms and Conditions to allow monitoring of device performance and enable remote troubleshooting. Telemetry contains metadata about the settings and conditions of a sequencing run. Nothing specific about the genomic content of individual reads is included—only generic information, such as sequence length and Q score, is logged. Some of this information comes from free-form text entry fields, therefore no personally identifiable information should be included.}

If the device name (hostname) is changed, a mismatch between the new device name and the entry recorded in /etc/hosts may cause an internal service (Slurm) to fail to start correctly on the next reboot. To correct the /etc/hosts configuration and restore normal operation, run the following command: sudo /opt/ont/platform/bin/ont-update-hosts-file

Note: An account with IT administrator permissions is required to complete the actions in this section.

The tool ont-platform-security-firewall is used to start, stop, enable, disable, and configure the firewall.

By default the firewall is enabled and SSH is disabled. When SSH service is allowed, all other ports are disabled.

Individual services may be enabled and disabled by using their service name or port number. In addition to the service names defined in /etc/services , the tool recognises the name "samba" which, when used, will enable or disable all the ports required by Samba: 137/udp ,138/udp ,139/tcp , 445/tcp. All rules apply to both IPv4 and IPv6.

Enable the firewall with the currently defined set of services allowed:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --enable

Disable the firewall with currently defined set of services allowed:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --disable

Deny incoming SSH connections:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --deny ssh

Allow incoming traffic on port #123, as if for an NTP server:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --allow 123

Allow ports required by Samba, as if for a Samba server:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --allow samba

Disable the firewall:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --disable Configuring syslog

Show the current status of the firewall, including configured and allowed services:

sudo /opt/ont/platform/bin/ont-platform-security-firewall --status

Output:

\--- Configuration options:
ENABLE: YES
DEFAULT\_SERVICES: ssh
ALLOWED\_SERVICES: ssh
\--- Current firewall status:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To                         Action      From
\--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)
Configuration is unchanged, no action taken.

These are optional procedures to be carried out as required.

Note: An account with IT administrator permissions is required to complete the actions in this section.

1. Find the correct timezone name by typing the command:

	sudo timedatectl list-timezones

2. Change the timezone using the following commands:

sudo su -
Timezone="Europe/London"
timedatectl set-timezone $Timezone
systemctl restart systemd-timesyncd

Note: this requires NTP/port 123 access if using an external internet time server.

1. Enter the following commands:

sudo su -
printf "[Time]\nNTP=ntp.ubuntu.com\nFallbackNTP=pool.ntp.org\n" | tee /etc/systemd/timesyncd.conf
timedatectl set-ntp false
timedatectl set-ntp true
systemctl restart systemd-timesyncd.service
hwclock --systohc
timedatectl set-local-rtc 0

2. You can check that the process has worked by typing:

timedatectl status

Note: it may take several minutes to sync with the NTP server.

Note: IT administrator permissions are required to modify the USB device mounting settings.

Removable USB storage devices can be used to transfer data to and from the Q-Line GridION. Do not insert unknown USB devices into the device.

By default, the system will detect inserted USB storage devices and will require the user's account password to mount them. Refer to the Q-Line GridION user guide for instructions on mounting a USB device with the default settings. An account with any permission level can be used to mount an inserted USB storage device.

The following commands can be entered in a Terminal window to modify the USB mounting settings. IT administrator permissions are required to make these changes.

To prevent USB devices being visible in the system file browser or mounting automatically:

sudo /opt/ont/platform/bin/ont-platform-security-usb-disks --disable

To automatically mount any inserted USB devices:

sudo /opt/ont/platform/bin/ont-platform-security-usb-disks --enable

To reset to the default settings (requiring password entry to mount a USB device):

sudo /opt/ont/platform/bin/ont-platform-security-usb-disks --prompt

Note: An account with IT administrator permissions is required to complete the actions in this section.

Note: An account with any permission level can be used to complete the actions in this section.

If data offload has been configured, the Run log screen will include an Offload status panel. This will indicate if the offload is active, or will report any issues. If there is a temporary loss of connection to the offload location, the status will be displayed as Reconnecting and there will be an option to stop the offload.

Ongoing offloads can be reviewed in the Overview screen.

A bar at the top of the screen indicates if data offload is in progress. New experiments can still be started while offload from a previous run continues.

Note: An account with IT administrator permissions is required to complete the actions in this section.

You can integrate your LIMS with your Q-Line GridION through the Sequencing Software’s REST API. The API serves as a secure communication channel (middleware) between the device and the LIMS. It provides the following features:

• Passing sample details from the LIMS to the Sequencing Software
• Passing supporting files from the LIMS to the Sequencing Software
• Monitoring runs from the LIMS
• Transfer of results to the LIMS

Before you can connect your LIMS to your device, follow the instructions below to enable the device’s LIMS interface so that the device can communicate with the LIMS. This is disabled by default for security. It is important to note that this process ensures the device is visible to the LIMS but does not represent a complete LIMS integration, which should be handled separately by the IT department of your institution.

Enabling the device to integrate with the LIMS requires you to:

• Generate an API key in the Sequencing Software.
• Edit a configuration file to include the Sequencing Software API key and any client API keys needed for the LIMS to connect to the Sequencing Software.
• Start the REST API service.

From there, the LIMS can be configured to the REST API for device integration in the LIMS. Once your LIMS and GridION are integrated, you can streamline your workflow further by printing the Library ID as an optical barcode and using this to select your sample sheet during run setup.

To enable your LIMS interface for a given device, complete the following steps.

a. The LIMS sends sample details for a library as a sequencing software-compatible sample sheet to the REST API. Supporting files for analysis the run can also be uploaded using the REST API. The sample sheet is then made available during run setup. The API returns a unique sample sheet ID to the LIMS that can be used to track the library.

b. Using the sample sheet ID, the LIMS queries the REST API to determine the status of that library. If a run has started, the API will return a unique run ID.

c. The run ID can be used to query the REST API for the status of that run from time to time. If it is still in progress, information will be provided about the whole run and individual samples.

d. When the run completes, results can be acquired using the run ID. Results are available in reports as HTML and sometimes also PDF or directly as structured JSON data.

Note: An account with IT administrator or Laboratory Manager permissions is required to complete the actions in this section.

Note: An account with IT administrator or Laboratory Manager permissions is required to complete the actions in this section.

Sequencing on the Q-Line GridION is performed in the context of assays. The system groups together the stages of a complete assay that are performed on the device – sequencing and analysis of sequencing data – so that you can start the process and allow the device to complete it without further interaction. The system’s representation of an assay includes configuration for sequencing and any bioinformatics workflow that is needed. The configuration file for an assay can be exported and, if necessary, edited as a .toml file.

Note: An account with IT administrator or Laboratory manager permissions is required to complete the actions in this section.

Note: An account with IT administrator or Laboratory manager permissions is required to complete the actions in this section.

Some assays may require you to provide supporting files. These can be alignment references, BED files, configuration files for an analysis workflow, or another type of file required for bioinformatic analysis. Depending on the assay, you may need to reference them in the sample sheet. On other occasions, the file might be stable across multiple runs and you will need to assign the file to an assay by creating a duplicate of that assay.

Instructions for importing supporting files can be found in the Q-Line GridION user guide.

To delete supporting files that are no longer required, follow the instructions below.

Note: An account with IT administrator or Laboratory manager permissions is required to complete the actions in this section.

When permanent changes to an assay are required, use this process. For temporary changes, it is recommended to modify the sample sheet instead.

Note: An account with IT administrator permissions is required to complete the actions in this section.

Sequencing Software updates

The Q-Line GridION is not intended to have regular updates. When updates are available, installation instructions will be provided by your technical support representative, or the installation may be performed during an on-site visit. After installing an update, you may need to perform an Instrument Performance Verification (IPV) and any additional procedures necessary to revalidate the system. Release notes provided with each update will help you decide the extent of revalidation required.

System updates

You may want to perform regular updates to the operating system of the device. The following command will update the system without affecting the Sequencing Software itself:

sudo /opt/ont/mooneye/bin/ont-mooneye-software-update --os

The frequency with which you perform operating system updates should be decided by your IT department.

Note: An account with any permission level can be used to complete the actions in this section.

Open the System menu and click Device information.

The software version will be displayed.

Note: An account with IT administrator permissions is required to complete the actions in this section.

The following Terminal commands can be used to configure auto-lockout. The tool ont-platform-security-auto-lockout enables, configures, and disables automatic account lockout on failed logins. It may also be used to reset user accounts that have been locked due to too many failed login attempts.

Configurable options include setting the number of failed attempts after which an account will be locked and a time period after which a locked account will be automatically unlocked.

By default, any accounts locked by auto-lockout will be re-enabled at system boot time. This behaviour can be changed using the configuration option:

--reset-on-boot NO

Note: IT administrator accounts are never locked out.

Usage examples:

Enable auto-lockout after three failed attempts:

sudo /opt/ont/platform/bin/ont-platform-security-auto-lockout --enable --deny-count 3

Enable auto-lockout after five attempts and prevent re-enabling at reboot time:

sudo /opt/ont/platform/bin/ont-platform-security-auto-lockout --enable --deny-count 5 --reset-on-boot NO

Reset failure counters for the user ID ‘john’. This will permit this user to log in again if the account had been locked as a result of too many login failures:

sudo /opt/ont/platform/bin/ont-platform-security-auto-lockout --reset john

Disable auto-lockout:

sudo /opt/ont/platform/bin/ont-platform-security-auto-lockout --disable

Display the status of auto-lockout:

sudo /opt/ont/platform/bin/ont-platform-security-auto-lockout --status

To unlock a locked user account, navigate to the User account management page and locate the locked account from the list. Click Unlock on the account you would like to unlock.

Note: An account with IT administrator permissions is required to complete the actions in this section.

The Linux Audit system provides a framework to track security-sensitive information by recording events and mapping them to users as they occur. These events are recorded locally and can be sent, as they occur, to remote log destinations using syslog RFC 5424: The Syslog Protocol

Auditing is enabled by default on the Q-Line GridION.

Audit does not provide additional security to the platform; rather, it can be used to discover violations of its security policies.

The following events are explicitly recorded:

• All processes started by any logged-in user
• All file deletions, renames, ownership, permissions and attribute changes
• All commands run with elevated privileges
• Hostname changes
• System clock changes
• The kernel module loads and unloads
• All user logins and privilege level changes
• Configuration changes related to user identities and elevated privileges (sudo)
• Configuration changes related to user login access and the recording of logins
• Changes to attributes (a.k.a. permissions and ownerships) and writes to the files in the following directories:
  • /opt/ont/minknow
  • /opt/ont/gourami
  • /opt/ont/gourami-local-auth
  • /opt/ont/guppy
  • /opt/ont/mooneye
  • /opt/ont/nanoxint
  • /opt/ont/platform
  • /opt/ont/reception

Note: Audit log procedures should be performed by your IT department.

The tool ont-platform-security-audit is used to enable, disable and configure auditing.

Important: While Linux Audit is enabled at the time of installation, it will not log to syslog until enabled by this tool.

After being enabled, Audit will log to its own log file (/var/log/audit/audit.log ) and to syslog. Syslog may be configured to send audit and other messages to a remote syslog server using the Oxford Nanopore Technologies tool ont-platform-security-syslog.

Usage examples:

Enable auditing and lock the setting to enabled. The lock means that audit will remain active until it is disabled

Note: A reboot is required after disabling the audit tool.

sudo /opt/ont/platform/bin/ont-platform-security-audit --enable --lock

Unlock the audit and disable it on the next boot. For the change to take effect, reboot the system after this.

sudo /opt/ont/platform/bin/ont-platform-security-audit --disable --unlock

Display the current status of the audit subsystem:

sudo /opt/ont/platform/bin/ont-platform-security-audit --status

Syslog is a widely used standard for message logging. It is used for various tasks, including system management and security auditing. On the GridION, syslog is implemented via the subsystem rsyslogd and configured using the tool ont-platform-security-syslog. Syslog is enabled by default and stores messages locally in the file /var/log/syslog.

For effective system management and auditing, we recommend that syslog messages be sent to a remote syslog server to store them and to apply additional filtering and monitoring. This remote store is considered an essential security measure within many organisations.

Syslog is enabled during system installation and can be configured to send logs to a remote syslog server, as outlined in the examples below. The remote server must have been configured to receive these messages, and the network between the two must be capable of propagating the messages. The transport protocol (UDP/TCP) can be configured, and the port number can be specified. By default, port #514 and TCP transport protocol will be used.

Usage examples:

To configure syslog to send messages to the remote server 192.168.1.10:

sudo /opt/ont/platform/bin/ont-platform-security-syslog --enable --server 192.168.1.10

To configure syslog to send messages to the remote server 192.168.1.10 using the UDP and on port number #765:

sudo /opt/ont/platform/bin/ont-platform-security-syslog --enable --server 192.168.1.10 --protocol udp --port 765

To configure syslog to send messages to the remote server 192.168.1.10 and to schedule the cronjob to run six times per hour:

sudo /opt/ont/platform/bin/ont-platform-security-syslog --enable --server 192.168.1.10 --cronjob 6

To disable syslog sending to the current remote server:

sudo /opt/ont/platform/bin/ont-platform-security-syslog --disable

To disable the scheduled cronjob:

sudo /opt/ont/platform/bin/ont-platform-security-syslog --cronjob 0

Audit reports can be generated to show a record of system and user activity over a defined time period, including events such as sequencing runs, user logins, software updates, and hardware checks. The system events which are recorded are outlined in a table at the end of this section. You may require audit reports when investigating security incidents, monitoring system usage, or demonstrating regulatory compliance.

Recorded system events are retained for a minimum of 3 months. To retain a record for longer periods, export and archive audit reports as required.

The table below outlines the system events recorded in the audit reports.

Encryption is supported via LUKS (v1 and 2) for local drives. Please note that drive encryption only protect data at rest.

For network drives to access the platform, both NFS and SMB (via Samba) protocols are supported. Data encryption on data transfers is only supported in SMB3. NFSv3 does not provide encryption on data transfer, whereas encryption for authentication requests is standard for SMB protocol versions 2 upwards. We recommend that SMB version 1 be disabled. NFS supports authentication encryption in NFSv3 with GSS and in NFSv4.

System updates are normally via ISO images supplied by Oxford Nanopore Technologies. Online updates for individual and batch updates of Linux are available, though these may introduce compatibility issues for the installed version of the Sequencing Software. For those cautious of security, automatic system package updates can be set up, with the understanding that there may occasionally be compatibility issues with the installed Sequencing Software version.

Ensuring the device is secure from both an operational and data privacy perspective is the responsibility of the organisation using the device. We recommend that users refer to applicable standards (e.g. ISO27001:2022 or IEC 80001-1 Edition 1.0 2010-10 or IEC 81001-5-1 Edition 1.0 2021-12) and use relevant technologies and policies (such as hardware firewall, anti-malware software, limiting internet use on the device, and disabling all ports and services to the sequencer which are not defined in this document) to provide risk controls suitable to their organisation. Data backup, restoration and business continuity protocols are the responsibility of the organisation using the device. We can provide an industry standard MDS2 form to enable users to be fully briefed on the security profile of the device. Anti-malware software should be installed on the device, and internet use should be limited.

Note: An account with Laboratory Manager permissions is required to complete the actions in this section. Support from your Oxford Nanopore representative is required to configure a custom assay.

The Sequencing Software uses assay definition files to run each chemistry and assay type. The files provide the software with values for key sequencing parameters. If you have designed your assay on Q-line products and want to run it in a production environment, adjustments may be required to match your configuration.

You can only export, edit, and re-import assay definition files using an account with Laboratory manager permissions.

To add a new supporting file (such as an alignment reference that is used every run) to an existing assay, refer to the instructions in the Managing supporting files section.

To customise an assay, contact your Oxford Nanopore Technologies representative for support.

Note: You should test your custom assay definition file to ensure it works before proceeding to scale or use high-value samples.

Note: An account with IT administrator or Laboratory manager permissions is required to complete the actions in this section.

When troubleshooting, technical support may ask you to share logs or telemetry. These can be exported from the Sequencing Software.