How to Mitigate Three Common Liquid Handler Robot Problems

Liquid handling robots (LHRs) are commonly used by labs working at scale. Because they reduce the need for manual processing, they can be hugely beneficial or even essential for labs with high throughput. However, LHRs also bring the potential for catastrophic errors. If lab staff walk away from the equipment — which automation should allow — they might not realize immediately when a problem occurs.

Integrating LHRs with the laboratory information management system (LIMS) can lower the risk, by enabling labs to anticipate potential problems and respond to them before they become a much bigger issue. This, in turn, can save labs time and money.

Three common LHR problems 

Whether lab staff are present or not, common problems can arise with automated LHRs. The longer LHRs are left to run without intervention when these problems occur, the longer it will take staff to rerun the processes, and the more costly the loss of time for the lab. Three common problems are:

Problem 1: A transfer of liquids may not occur as expected

There are many reasons why the transfer of liquids might not occur correctly. One example is if there’s a loose or missing pipette tip on the processing head, which affects one or more transfers. Regardless of the reason, if any transfer fails either partially or wholly, it’s covered by Problem 1.

Problem 2: Containers are in the wrong deck positions

At times, the correct containers might be loaded onto the LHR deck, but in the wrong positions. Multi-well containers are often identified by 13-digit identifiers. With so many digits to remember, it’s fairly easy for the operator loading the deck to inadvertently place a container in the wrong location. For example, they might place container 0000056300000 in the position where container 0000066300000 should be (or vice versa). 

Problem 3: Wrong containers are on the deck

Similarly, the wrong containers might be loaded onto the LHR deck, because the operator locating the source container from the freezer transposes numbers in the 13-digit ID. For example, they might retrieve container 0000006350000 when they should be retrieving 0000003650000.

Whether a problem is the result of equipment failure or human error, each can have significant implications at scale. Fortunately, there are programmatic ways of limiting the damage.

Integration patterns to address these problems

At Semaphore, we use integration patterns to reduce the risk that these problems will occur. Three patterns that address the problems described above are:

Integration Pattern 1: LIMS produces a ‘driver file’ for the LHR to consume

This is the oldest and simplest integration. The LIMS generates a ‘driver file’ that can be imported into the LHR management software to define the transfer requirements from source to destination. This driver file can be a simple table in a format consumable by the LHR software, such as in Table 1.

Source Container Barcode	Source Container Well	Destination Container Barcode	Destination Container Well	Transfer Volume (uL)	Buffer Volume (uL)
S000111	A1	D222333	A1	5	1.2
S000111	B1	D222333	B1	4	3.2
S000222	A1	D333444	A1	5	1.2
S000222	B1	D333444	B1	5	2

Table 1

When this pattern is used, the LHR operator:

1. Loads the LHR deck with the source and destination containers.
2. Downloads the driver file from the LIMS.
3. Imports the file into the LHR.
4. Presses ‘Go’ on the LHR.

This pattern is cost-effective and easy to achieve. It assumes that the virtual transfer has occurred in LIMS first.

How does this pattern relate to the common LHR-based problems?

• Problem 1 (liquid transfer error): If this problem occurs, the LIMS information is now out of sync with reality.
• Problem 2 (containers in the wrong positions): This may or may not be a problem, depending on whether the LHR is capable of performing a barcode-based scan of the deck’s contents before it begins processing. If it can scan the barcodes, then where the operator loads the containers on the deck is not crucial because the LHR can establish the container locations on the deck.
• Problem 3 (wrong containers): This is a problem. How big a problem depends on whether the LHR is capable of carrying out a barcode-based scan of the deck’s contents prior to beginning processing. If it can scan the barcodes, then the issue of the ‘wrong container’ can be detected by the LHR and communicated to the operator.

Integration Pattern 2: LIMS consumes a log file produced by the LHR

Most LHRs have the ability to produce a log file of the transfer operations that occurred during processing. This log file can be parsed by the LIMS, and is used as the credible source of truth concerning what did happen versus what should have happened. Some LHRs have the ability to detect if a transfer didn’t occur properly (via pressure, capacitance, or optical sensing). The log file (like that in Table 2) can also tell the LIMS which transfers failed.

Source Container Barcode	Source Container Well	Destination Container Barcode	Destination Container Well	Transfer Volume (uL)	Buffer Volume (uL)	ERROR
S000111	A1	D222333	A1	5	1.2	NO
S000111	B1	D222333	B1	4	3.2	NO
S000222	A1	D333444	A1	5	1.2	YES
S000222	B1	D333444	B1	5	2	NO

Table 2

When this pattern is used, the LHR operator:

1. Loads the LHR deck with the correct source and destination containers.
2. Presses ‘Go’ on the LHR.
3. Imports the log file into the LIMS, where it is processed.

How does this pattern relate to the common LHR-based problems?

• Problem 1 (liquid transfer error): Generally mitigated. Since the LIMS is being updated based on what did occur during LHR processing, a failed transfer can be represented in LIMS to show that the transfer did not occur or that it did occur, but problems were encountered and any subsequent results should not be relied on.
• Problem 2 (containers in the wrong positions): Not mitigated. If the values for the container’s barcodes in the log file are generated by the LHR, and can be relied on, we have an accurate record of what occurred. However, if this problem did occur, the log file confirms that the wrong containers were used — but it doesn’t help the lab catch the problem prior to incorrect processing.
• Problem 3 (wrong containers): Not mitigated. If the values for the container’s barcodes in the log file are generated by the LHR, and can be relied on, we have an accurate record of what occurred. However, if this problem did occur, the log file confirms that the wrong containers were used — but it doesn’t help the lab catch the problem prior to incorrect processing.

Integration Pattern 3: LHR carries out a pre-flight check

Within most LHR management software, it is possible to incorporate a set of initial preprocessing validation tasks into the LHR methods before any transfers take place. These validations might include checking that:

• Containers loaded on the deck are in the expected positions.
• Containers loaded on the deck are the correct containers.
• Any reagent-based containers contain the correct reagents and the reagents have not expired.

Collectively, we call these types of validations a ‘pre-flight check,’ and we make the assumption that if any of the components of the pre-flight check fail, then no transfers will occur and the operator will be notified.

Validations can be implemented in one of two ways. The LHR management software can be configured to contact the LIMS directly to get the required information. Or, if this is not possible, the LHR management software can be configured to call an external utility script that will communicate with the LIMS and report back to the LHR management software to tell it whether the pre-flight check passed or failed.

When this pattern is used, the LHR operator:

1. Loads the deck of the LHR machine with the source and destination containers.
2. Presses ‘Go’ on the LHR.
3. Takes corrective actions if the pre-flight check fails.

How does this pattern relate to the common LHR-based problems?

• Problem 1 (liquid transfer error): Not impacted. This pattern does nothing to mitigate this problem.
• Problem 2 (containers in the wrong positions): Fully mitigated. The pre-flight check should entirely solve this problem.
• Problem 3 (wrong containers): Fully mitigated. The pre-flight check should entirely solve this problem.

Current best practices

Combining all three integration patterns reduces the occurrence of common LHR-based problems and is our recommended approach to integrating LHR systems with the LIMS.

We advise the following order of sequence of operations:

1. The LIMS generates a driver file of the expected transfers, but does not record those transfers as having occurred yet — Pattern 1.
2. The LHR operator loads the LHR deck with the source and destination containers.
3. The operator imports the driver file into the LHR.
4. The operator presses ‘Go’ on the LHR.
5. The LHR performs the pre-flight check — Pattern 3.
6. If the pre-flight check fails, the operator takes corrective actions.
7. When the transfers are complete, the operator imports the log file into the LIMS, where it is processed – Pattern 2.
8. The LIMS records the transfers.

However, because this integration approach is likely to incur the greatest cost and longer timelines, we suggest that some labs take a phased approach instead. This involves applying the most valuable pattern(s) first so that the lab gains some integration benefits quickly.

In our next post, we’ll share some things to consider when choosing which integration patterns to leverage that best meet your lab’s unique requirements. In the meantime, if you’re experiencing these common LHR problems and need help solving them, contact us.