Why are lab automation integrations hard to do well?

When digitalising your lab by integrating lab automation with your inventory to produce a smooth data flow, it is common to ask “why does it take so long?”

If you choose a quick solution, it is also common to wonder why it doesn’t do everything you want!

How “good” an integration is depends on five key factors. They are:

  1. What level of functionality is included
  2. Who plans and develops it
  3. How it is tested
  4. How robust it is
  5. What kind of support it has

Each of these have misconceptions that can cause frustrations for both the lab team and the software developer. We review a different point in each part of this blog, aiming to help you understand what might work best for you. Finally, we look at what can happen if you just want a quick integration.

We hope you find the information useful.

tsl276-integrations-are-hard_social_v2

1: What level of functionality do I need?

Efficient laboratory workflows speed up assay cycles and underpin rapid research. It is a huge help to scientific teams – and to your business efficiency – to have software that integrates lab instrumentation and sample processing with your inventory and audit trail to provide a real time, error free data flow.

Ideally, this integration between sample management software and lab automation will also automate and manage workflows to reduce operator workloads and human error.

However, there are different levels of integration which have different capabilities and take different amounts of work to achieve. So:

  • An integration that transfers results data to inventory will not automate a process unless it is also designed to do that.
  • Results may not be transferred to inventory in real time, unless that is a requirement of the integration.
  • Automation engineers will still need to write your instrument protocols unless a direct 'driven' integration is specified.

How do you know what is needed or included when specifying your integration? It helps if you understand the levels of integration available, which are:

Level 1: Simple integration using file import

File import, where data flows one way, is the most common type of integration and the simplest. Existing work protocols are manually set up by instrument operators. Once the instrument protocol has been run, the results are incorporated into a file to be imported to inventory. Because this file updates inventory data, it is a potential source of errors if it was not created correctly or the instrument protocol contains mistakes. Titian believe it is essential that file import data is verified before any changes to your inventory are made, even though adding these checks will mean the integration takes longer to complete.

File import is the loosest level of integration and thus fastest to achieve at lowest cost, but it does not often reduce the workload on the instrument operator. Creating results files can be time consuming and error prone. File types may be incompatible between systems, which is hard to test and troubleshoot. Also, the process of importing results files is often partly manual so that inventory data is not necessarily updated in real time and may not be suitable for fully audited environments.

Level 2: Workflow-led integration by verified file exchange

When your sample management software or LIMS has a workflow, this allows for a two-way integration where instrument operators get guidance from the LIMS of what actions are required next, in clear workflow steps. Expert operators still need to write the protocols for instrumentation. A verified file exchange process with the sample management software, which is frequently automated, creates sample pick list files for the work protocols and then imports results data in real time to provide auditable updates to the inventory.

This medium level of integration can reduce operator workloads, not only by providing guidance but by performing automatic calculations that also reduce human error. However the integration is still not very flexible as it requires instrument experts to write or update protocols for any change in the workflow.

Level 3: Driven instrument integration

A direct or driven integration is where your sample management software ‘drives’ instrumentation directly through the equipment’s Application Programming Interface (API) and creates the work protocols required for you. The two-way data transfers are automatically managed and verified to update inventory and audit trail in real time. This level of integration frees operators from having to learn how to write protocols for each individual instrument and means runs can easily be performed by less experienced operators.

Driven integration makes processing highly efficient but is complex to write, as it often brings equipment from different automation vendors into one seamlessly managed system with a single interface. For this reason, it costs more and takes longer, but it brings swift returns on investment for busy labs through error reduction as well as efficiency.

Titian Software offer a guide to the pros and cons of the various levels of integration for different lab equipment in the white paper: ‘Integration Strategies for Digitising your Lab’. You can download it here.

2: Who should develop my integration? 

Many companies have experience of older lab equipment where they have been able to write simple .csv file import integrations for themselves. These work on the small scale, even if they tend to be manual, laborious and error prone. Difficulties arise when scaling up, when files become huge. Any change to the process means changing the file and then retesting it. Building and editing the integration files is a big burden on operators – and very easy to introduce human error.

Beyond this, there are two common paths to greater lab integration, each with strengths and weaknesses:

  1. Create or commission a one-off bespoke integration, either using in-house resources or outsourced software expertise.
  2. Using or adapting the ready-made integrations that come with sample management software such as Titian’s Mosaic.

A bespoke integration will be designed to your specification, which may be essential if you have an unusual process. However, it will take considerable time and commitment from you to manage successfully – this is especially the case if your software team do not have a background in laboratory automation and so are not aware of the equipment, regulations and processes that you work with daily.

Buying into a LIMS software vendor’s integration solution might not match all of your requirements, so it may not seem ideal at first. These integrations have to satisfy multiple customers so are designed to work for everyone. Planning these integrations to cover a variety of needs takes longer but it makes the results particularly robust. It also means you get best practice as part of the package as vendors pool knowledge from industry to inform their software.

Lab automation integrations often need more than a simple file transfer. Liquid handlers usually have a very instrument-specific protocol or script to set up and write for each process, whether it is for a Tecan Evo or a Beckman Coulter Echo. For each instrument, the integration will need to define how to transfer things from where to where, how to handle tips and so on. Any changes in the workflow, or to apply the workflow to a different instrument, will need to create new versions of these scripts.

A team writing a bespoke integration will work directly towards delivering software to cover the specified processes. The result is likely to be quicker but unlikely to be easy to adapt to process changes or new versions of the automation control software . A bespoke software team may not be familiar with sample management automation, so this could be a learning curve.

Sample management software product vendors are very familiar with lab automation. They usually have good relationships with vendor companies and are likely to have integrations at least part developed already. Extending their core software product to meet your requirements may not be seen as a bespoke development, but viewed as product enhancement and thus charged at a reduced fee. Delivering the integration may take longer but it will cover all the  most common cases robustly and provide a consistent user experience across automation from multiple vendors.

Another difference is how finished a product you receive. A bespoke integration development will be focussed on reaching particular milestones but may be unfinished in other areas. A software product vendor needs the result delivered to be complete and rounded, including the preparation of software releases, testing, documentation and training so users can work effectively with it.

 

3: Why does it matter how my integration is tested?

Another aspect that makes lab integrations difficult is the need to develop and test against lab hardware. It is straightforward to test simple file import integrations in isolation. However, when integrating with more complex lab automation through sophisticated APIs, then there is no substitute for factory testing as well as simulator testing.

If your software development team hasn’t got the hardware to hand then they have to try to test against simulators using mocked up data. Creating suitable test data is quite difficult. Some automation vendors have good simulators but these are never quite the same as testing against the real machine – for example, simulators don’t provide error cases.

Titian Software has a good relationship with automation and software vendors and has often done integration testing at factories, against the real instruments. To minimise errors, Titian also goes to a lot of effort to reduce the number of clicks and user interactions needed, as well as providing guidance for operators and carefully validating files. The result is a much smoother and more efficient workflow as well as greater reliability. These attributes save time and costs over the working life of the integration.

 

4: How robust does my integration need to be?

In order to support your lab and keep production going, an automation integration needs to be robust. This is only possible if the integration software has anticipated errors that could arise and has mechanisms for recovering from them.

For example, potential error cases for a store integration might include:

  • What should an automated store do when it can’t read a tube barcode? If it just stops, it means the store is effectively blocked as the other racks scheduled to load won’t go in, which could have serious consequences for sample integrity.
  • What should happen if a tube is missing when a rack comes to be picked? Should the whole rack be prevented from going for further processing, or the operator alerted to say that a sample is missing?

Adding the level of logic and planning to investigate and cope with such interruptions adds time and cost to the development of an integration . However, it significantly reduces delays and improves efficiency once the integration is in use.

An existing sample management software product is likely to have much of this error management already incorporated from earlier developments. Titian’s Mosaic attempts to understand what might block an automated store and when the problem can be put to one side, so the user is not held up unnecessarily while the problem is fixed.

This kind of tracking and management is particularly important for liquid handling workstation integrations – both for error handling and to take advantage of instrument capabilities that optimise transfers. For example:

  • Error handling
    If a liquid handling run is interrupted, without sophisticated error tracking and recovery the choice is either to throw the whole run away or to laboriously calculate and program by hand all the recovery steps needed. Using software that has a workflow and tracks every step makes it easy to get going again. Mosaic compares completed steps against the workflow so it can generate recovery scripts on the fly. Simple transfer failures caused by a missing source tube or air bubbles are also recorded so they can be tracked in the data flow afterwards.
  • Instrument capabilities
    If your liquid handler can handle many tips you might want to optimise a job by doing many transfers together as a single block transfer, rather than doing each individually. With the right pattern of tips on the head these could be performed in a single step. To automatically calculate the most efficient way of doing the transfers requires sophisticated integration software. This requires a lot of sample management experience and is time-consuming to build into a bespoke software integration.

Mosaic software's driven integrations are able to take advantage of advanced liquid handler features like source survey data and use this to update the inventory. It can dynamically fine tune a workflow based on inputs from the liquid handler. This is not possible with a simple file import integration. Without this dynamic input processes have to stay very general – which might waste consumables, solvent, tips and time.

5: Does my integration need support?

To maximise the benefits from an integration it is important to consider its use in the longer term, which means it will need updates and support.

A bespoke software developer usually has a high turnover of staff and projects; meaning that when you need an update or something goes wrong, the original team with the knowledge of your system is unlikely to be available. Similarly, the drive for efficiencies across many companies has significantly reduced in-house development teams, or relocated the work to a different country, which means the next time you need a change the system knowledge is no longer there. Many of Titian’s customers have approached us after their internal development teams have gone.

Software product vendors need to keep system knowledge in house even when personnel change. Code is designed to be easy to maintain and support as products are constantly updated. Titian thinks a lot about diagnostics and reporting, not just error handling, to help the support team access information and resolve issues. Titian also has a shared code base, including standard components that can be reused across Mosaic. This drives a cross pollination of features and enhancements across the whole software as they are added to individual software integrations.

Because sample management software product vendors usually have good relationships with several automation vendors, they get advance notice of upcoming product updates, interface changes and new features. This allows software vendors to keep their integrations in step with changes as they happen. When an instrument eventually becomes obsolete or the customer needs to change it, the integration for the replacement may already be part of the product.

Titian Software is vendor agnostic, which means that one integration can easily be adapted to work with similar instruments from other vendors while retaining a familiar user interface.

What happens if I just want to write a quick integration?

The speed an integration can be done is determined by the simplicity or complexity of the process and the equipment to be integrated, and also whether the appropriate level of integration is chosen for the task.

Imagine a case where a company chose an automated liquid handling workstation but didn’t want to buy an off the shelf software module with the appropriate driver to integrate it with their inventory. Instead, they asked an external company for a bespoke file transfer integration. After a year and a half, the liquid handler vendor no longer wished to continue to provide advice, which had become an uncosted resource. After two and half years the integration is still not in production.

File transfer integrations work at a simplified level and are not suitable for complex scheduling required by workstations for moving plates, deciding when to change tips, which liquid class to use, and so on. The liquid handler in the case above has an API that allows an integration to take advantage of all the workstation’s capabilities but it needs an optimised low-level integration to do this.

Conclusion

The depth of experience and support needed for good lab automation integrations often gets overlooked. This is in part because a ‘proof of concept’ (PoC) integration is usually based on a spreadsheet file import and a simple process with no error cases. PoCs are a great tool for visualising what can be achieved, but they are a long way from a robust and finished product that can run consistently. Unfortunately, they have a side effect of making integration look quick and easy to do.

To provide value for money, a good integration is one that is easy to use and provides daily efficiencies by running reliably, removing errors from your processes and mitigating any problems that do occur. To ensure your system can adapt to meet future needs, you should look for good support alongside the system flexibility to allow process or instrument changes.

There are several factors that make integrations highly efficient as well as good, including:

  • Having a reliable partner that understands best practice, has good relationships with vendors, and provides support and upgrades
  • Understanding lab equipment and processes in depth to provide optimisations, managing errors that might occur, and minimising workload for operators
  • Maximising data integrity through validating data, performing automatic calculations, giving guidance to operators and reducing data entry
  • Testing against real equipment and with real data
  • Providing training and materials that ensure your integration is running optimally

If these are not already part of the solution you choose, then it is worth costing them in.

We hope this blog has gone some way towards to explaining why producing a good integration is not easy.

Tags: compound management, integration, lab automation, inventory management, lab management, sample management