File- or API-based Integrations: Which is Best for Liquid Handlers?

When you’re automating your clinical lab, one of the first things you should look for is an opportunity to integrate instruments with your laboratory information management system (LIMS). This is a great way to reduce manual processing and boost the lab’s speed, efficiency, and accuracy.

Integrating liquid handlers can provide a high return on investment. These robots are commonly used in labs around the world, from small research outfits to larger commercial operations, and can support a high level of automation. Integrating them with your LIMS is imperative if your lab is high-throughput, or plans to be.

When labs ask us about how to best integrate robotic tools with a LIMS, we recommend they consider the following.

Choose the right integration method

As we’ve mentioned in a previous post, two of the main architectures for instrument integration are file-based or API-based. Each has benefits and limitations.

Type	What you need to know
File-based	This method uses CSV files (called “worklists”) to transfer information between the LIMS and the liquid handler. The file, generated from the LIMS, is a list of comma-separated values that contains information about the samples to be processed by the liquid handler, as well as data like the concentration, volume, and well mappings for transfer. Often, file-based integrations are managed by the lab tech when they’re using the liquid handler’s control software to set up a run. Note that liquid handlers also produce: Log files, which indicate what tasks were performed. Results files, which could be used to drive behavior in the LIMS (although this is a less common direction of operations). CSV worklists are easy to create and read, and are supported by most, if not all, liquid handlers. In fact, the file format is so simple, there’s no requirement for an industry standard. However, there are several downsides. For instance: Files must be transferred manually, or you need to set up a shared network location that can be accessed by the LIMS and the liquid handler. Consequently, it’s possible to inadvertently use the wrong worklist. It’s possible to edit the files produced by the liquid handler and end up with a version that differs from what is tracked in the LIMS—something important to consider if you’re working in a regulated environment. There’s no way to ensure that the user performing the operation on the liquid handler is qualified to work with the samples they are processing (i.e., there’s no way to perform user verification)
API-based	With this method, the liquid handler communicates directly with the LIMS via an application programming interface (API). A huge benefit of this approach is that it allows you to add extra verification steps. For example, you can: Verify that users with appropriate training are performing the operation. Verify that samples are loaded on the deck in the correct positions and are ready for processing. Validate that reagents on the deck are not expired. You can also track exactly what happened on deck and report issues more easily. For example, you could set up the LIMS to broadcast error notifications from the liquid handler to staff so that they can investigate issues. Unfortunately, though, there is no industry standard for API-based communication between a LIMS and a liquid handler. This means the API-based method typically requires more development effort to implement than the file-based approach.

Other things to consider

When you’re building an integration, you also need to consider where you want the programming logic to live in the overall system architecture—in the liquid handler method or in the LIMS? You can either tell the liquid handler what to do or track what the liquid handler has done. Which system do you want to change and which needs to be the most flexible? Take into account the complexity of configuring your LIMS to parse result files.

We also recommend you consider the composition and availability of your informatics team. Do you have dedicated automation engineers who can design liquid handler methods and LIMS engineers who can encode all the behavioral logic into the LIMS? Do they have the bandwidth to build and maintain this integration, or will you need to work with a consultant?

You should also decide on a method of version control. Neither the liquid handler software nor the LIMS can typically handle version control of your integration source code, so you should plan to keep the code in a software configuration management system like Git, ideally on a platform like GitHub. Version control is important because it helps you:

• Track and manage changes, including who made the change, when was it made, and what was modified.
• Roll back to a previous working version if something goes wrong—making the development of new functionality lower risk.

Whichever approach you choose, we highly recommend labs invest in integrations between liquid handlers and the LIMS. If you want to limit errors and improve the lab’s efficiency, one of the best ways you can do that is to reduce manual processing through automation.

Contact us for a free consultation, check out our instrument integration page for other types of integration examples, and read our integration posts.