Lab Automation: This Checklist Could Save You $100,000s

---

Laboratory automation devices are expensive, so choose wisely!

Important decisions you make today can save you from major financial headaches as you grow. This article will give you some insight into the journey of lab automation for the typical biotech laboratory, and will conclude with a checklist of features that discerned laboratories always insist upon.

Automation experts: sure, skip the background and go straight to the list. We’d love to know what you think!

Automation novices: read on to understand the reason why some laboratory automation devices are more scalable than others.

Small or startup labs: a focus on ease-of-use and flexibility.

You’re a small team, each of you juggling a lot of different things. You’ve recognised some of your major bottlenecks and you’re keen to automate them to free people up and increase reproducibility.

Your choice of automation workstation needs to be approachable and easy to learn. Ideally, 90% of the software should be learnable in 10 minutes and should guide any new users through to success. Choose from a company who values User Experience (UX), and considers your ‘journey’ from unpacking, all the way to the use of advanced functionality for flexibility.

Given your staff might come and go over time, approachable devices with good UX will reduce your training burden and team resilience. No lab wants their expensive automation tools gathering dust in the corner because they’re quirky or because nobody knows how to use them!

Growing labs: require reliability, reproducibility and access to data

As your lab grows and throughput increases, reliability, reproducibility and access to data is becoming more important.

If two different people are using the same tool for the same job but applying different settings, then reproducibility and downstream analysis will be affected. It’s important to be able to lock down a device’s settings in order to standardise workflows, increase reproducibility, and help you compare apples with apples during analysis.

Analysis also requires good access to data. Think about how you want to get your data off your laboratory automation. Can you specify data formatting for export? Can the device be networked? If networking isn’t permitted, is there good access to a USB port? What’s the access like if your device is in an environmental chamber?

As throughput increases, reliability will become more important. Equipment downtime can ruin a big, expensive batch of experiments. Make sure you choose well-engineered hardware, from a company that offers fast support in your geography should you need it. And from a company that looks like it’ll be around for years to come. No lab wants a ‘white elephant’, an expensive automation device gathering dust because of reliability issues or because it’s no longer supported.

Scaling labs: automation requires extensibility, open architecture and deeper support

As your lab scales, you might want to automate your analysis pipelines, and further increase your throughput and the ‘walkaway time’ of your lab workflows.

To integrate your lab automation with LiMS, a Laboratory information Management System, or data analysis software, you’ll want access to a well documented and well written Application Programming Interface or API. While data exports to specific file locations can be used to trigger automation pipelines, it’s not a robust or scalable solution.

To increase the walkaway time of your lab automation, you might want to ‘integrate’ it with robotic arms and other equipment. On the hardware and safety side of things, make sure your automation device has plate-holding mechanisms that support robot gripper access, and apertures or doors that support robot arm access while maintaining safety. If it isn’t robot-friendly as a base model, is it upgradable?

On the software side of things you’ll need to communicate to the device from some scheduling software. Given the complexities of integration, this will likely be provided by another company that acts as your Integration Provider. Have the two companies worked together before? Have they already written a ‘device driver’ to facilitate communication between the scheduling software and the product API? What functionality is accessible through the API, and how much functionality does the device driver expose?

Furthermore, you’ll want to know about the stability of the API over time. If the device manufacturer makes changes to the API as part of a software update, it can completely cripple an entire integration (think CrowdStrike as a worst-case scenario!). Choose a vendor who unit-test, QA and QC their software updates and places a great emphasis on backwards compatibility.

So, choose lab automation products with a well-tested and stable API, from a vendor that provides and supports their API to you or your integration provider as part of their standard support package.

Avoid Costly Reinvestment and Revalidation

If your lab automation devices don’t support the journey above, then you’re going to have to reinvest as your lab grows. Let’s say, for example, your automation device doesn’t have an API. Not only will it be financially painful to buy new hardware that does have an API, it could be even more costly to have to re-develop, re-optimise and re-validate your workflows.

Lab Automation Checklist

To summarise, choose your investment in lab automation devices wisely to avoid major financial headaches as your lab grows. Here’s a checklist of features that we recommend you should insist upon:

• Ease-of-use: Make sure you get a full demo and/or get hands-on!
• Flexibility: Is the advanced functionality easily accessible?
• Reliability: Is it well engineered by a trusted manufacturer?
• Standardisation: Can you save settings ‘profiles’?
• Access to data: USB access? Networked? Is the data structure configurable?
• Upgradable: Can it be upgraded to be robot-friendly and support integration?
• Open API: Is the API free? Is it supported as standard? Ask to have a look at the API documentation to check what functionality is exposed.
• API Stability: How are software updates handled? What does release quality control look like? Is there a policy of backwards compatibility?