Modern laboratories typically rely on a Laboratory Information Management System (LIMS) or a Laboratory Information System (LIS) to streamline and enhance their daily laboratory operations. They are crucial for tracking the lab’s primary subjects – whether samples or patients – through the entire workflow, from an ordered test to final results. By providing a centralized platform for managing vast amounts of data, these systems ensure accuracy, efficiency, and compliance with regulatory standards. In addition to workflow management, some LIMS and LIS also handle various other laboratory activities, including inventory and resources management. For simplicity, we will refer to both as LIMS in this blog.
This article is intended for laboratories, laboratory equipment manufacturers, and software developers responsible for determining the LIMS integration strategy for their software. Whether you are tasked with selecting the integration approach or planning a LIMS integration for the first time, this guide will equip you with the insights needed to make informed decisions. Understanding the various integration options is crucial for ensuring that your software aligns with a laboratory’s infrastructure, enhances operational efficiency, and supports robust data management.
To fulfill its purpose, a LIMS requires both data input and output. Although these tasks can be performed manually, this approach is often time-consuming and error-prone. To address this, LIMS systems typically incorporate several methods to streamline the process:
APIs (Application Programming Interfaces)
A LIMS may either expose its own API or access the API of another application. This setup enables direct communication between the LIMS and other applications running on the same computer, allowing for seamless data transfer and the execution of operating instructions. While many LIMS systems provide standard APIs, such as REST, SOAP, and RPC, which adhere to industry-standard web service protocols, there are instances where systems offer proprietary APIs. In such cases, integration requires writing custom code, which adds quite a lot of complexity to the process.
Direct database access
A LIMS may also allow applications to directly access its database or the database of another application. While this is a powerful method for system interaction, it can be problematic without a comprehensive understanding of the system’s inner workings, as it carries the risk of data corruption or security breaches. In this case, developers can write custom SQL queries to pull data from the LIMS database or push data from external systems to the LIMS. This method requires technical expertise and strict data governance to prevent unauthorized access or data corruption.
Files
Many LIMS platforms support file-based integrations, where data is exchanged using files in standard formats such as CSV, XML, or JSON. These files can be imported or exported manually, or automated workflows can be set up to handle file transfers between the LIMS and other systems. File-based integration is often used in laboratories that need to interface with instruments or legacy systems that do not support modern API-based communication. Using file transfer protocols like FTP or SFTP, data can be transferred securely between systems at scheduled intervals.
LIMS vendors generally offer multiple integration methods to facilitate seamless data exchange with other systems. Beside APIs, file-based and direct database access integrations, many also in addition provide off-the-shelf (OTS) modules designed specifically for integration purposes. These modules often come with pre-configured connectors for widely used systems such as ERP systems, Electronic Lab Notebooks (ELNs), or even cloud platforms like AWS, and communication tools like Gmail. These connectors allow for straightforward setup and minimize the need for custom development.
Considering all the options mentioned above, it might seem like developing a new piece of software that integrates with LIMS should be easy. However, the challenge lies in details. Each LIMS implements only a subset of the above options, and even that subset is often implemented in a way that is incompatible with other LIMS systems. Moreover, different instances of the same LIMS are often customized to meet the needs of end users, which can interfere with integrations developed for the ‘basic’ version of the same LIMS system.
At this point, many might argue that a standard way of interfacing with LIMS should be defined. And you would be correct – having a universally accepted standard would certainly simplify the process. However, this assumes that all laboratories require and send the same data to their LIMS and that their workflows are compatible. Furthermore, all LIMS developers would have to agree to this standard and implement it. Therefore, there is no general standard, and it very likely won’t be very soon. There are a few standards in commercial use, for example, HL7 (Health Level Seven International) for LIS and Sila2 or OPC UA for LIMS integrations, but they are used only by some.
How standards proliferate (Source: xkcd)
Tailoring LIMS Integration: Balancing specific needs with broad usability
Considering all this, how should you approach developing a new application that you hope to integrate with one or more LIMS? The answer, as with most things, is: “It depends.” The first aspect to consider is your target audience—who will be using your software?
If the application is being designed for a specific organization that uses only a single LIMS or a limited number of different LIMS systems, then direct integration with that LIMS may be a viable option. However, even in this scenario, caution is advised. Overcommitting to integration can be risky since it may require significant effort – both in researching the integration options and in the actual development process.
If, on the other hand, the application is being developed for more general use, then any fully implemented integration will only cater to a small percentage of end-users. In this case, two alternatives should be considered instead of full integration with just a few select LIMS systems:
Implement your own API
While this option does contribute to the ‘path of infinite standards,’ it is also the path that can be taken when the data in your application is too extensive and too complex to be exported in a common file format or when a LIMS may need to use your application for additional data processing before final export.
If you choose this route, it’s crucial to extensively document the API. You should also either develop middleware to link the customer’s LIMS with your application or at least support the customer’s developers in producing their own integration solutions.
Before taking this approach, consider the application’s importance. Laboratories or larger organizations are unlikely to fund the development time needed to connect to an API for a small, “nice-to-have” application. An API only makes sense if it is likely to be used and if its use will be cost-effective in the long term.
Export the data in a simple file format
Your application should be able to automatically output results into a specified folder and in an easy-to-parse file format. A common approach is to output the results in a CSV file using a single predefined locale for number formatting. Many LIMS systems offer the option to “watch” the contents of selected folders and automatically import data based on simple column-to-data field mapping rules. The main advantage here is that no software developers need to be involved in the integration; a user familiar with the terms used to describe the values both in the LIMS and the application can accomplish the mapping on their own. However, the downside is that the results you are trying to export need to be relatively simple.
Use middleware
When you have multiple instruments with differences in their protocols, formats, or interfaces that need to be integrated with a single LIMS or other software solution, the best approach can sometimes be to use middleware. Middleware is a software layer that acts as a bridge between different systems, applications, or components to facilitate communication and data exchange. You can create your own middleware or use an off-the-shelf solution. Some LIMS platforms offer seamless integration with third-party integration middleware solutions, which simplifies the process.
To summarize
Before attempting to integrate your new application with a LIMS, consider the following key questions:
1. How many and which LIMS systems are your target users likely to be using?
The cost of integration will increase with the number and diversity of LIMS systems you aim to support.
2. How many resources are you prepared to devote to developing and supporting integrations?
Integrations require ongoing maintenance and support, so be prepared for this investment.
3. Is your application significant enough within the laboratory to justify integration efforts?
An integration that is difficult to use could diminish the worth of your software rather than enhance it.
4. Are your results too complex for CSV files?
Simple solutions are usually the best.
By carefully addressing these questions, you can determine the most effective approach for integrating your application with LIMS, ensuring that the solution is both practical and valuable for your target users.
If you are still considering which LIMS is the right for your organization, we recommend reading our article on the topic of traps and challenges of LIMS and ELN selection.
Ready to integrate your software with a LIMS?
If you’re navigating the complexities of LIMS integration, you don’t have to do it alone. At BioSistemika, we specialize in custom software solutions that seamlessly connect your systems, optimize your workflows, and ensure data integrity.
Whether you need to develop APIs, implement file-based integrations, or use middleware, we have the expertise to tailor the perfect solution for your needs.
