LIMS has really grown up. When I started (more than 20 years ago, a depressingly long time...), LIMS was virtually unknown. In fact, it took me months to drum up the courage to ask what the letters LIMS stood for. 'L' is obviously 'Laboratory', and 'I' is probably Information, 'M' might be 'Management', but what was 'S'? Anyone that even mentioned LIMS talked about 'LIMS Systems', so the 'S' couldn't be 'System'. Perhaps 'Software'?
Well, it turned out that it was 'System' after all. Laboratory Information Management Systems (LIMS, for those in the know) have been around a while, in many different forms. In some cases, it is an Excel spreadsheet that contains some lab data. In other cases, it is some software that was written by the company itself. Nowadays, the norm is to use LIMS products provided by specialised vendors; these systems tend to provide more functionality and more possibilities for upgrades and future- proofing.
What is LIMS, after all? It is probably best described as a program that watches everything that happens within the laboratory, and helps everyone that works there. It does this by storing important information within a database, and by performing everyday (and relatively tedious) operations such as calculations and reporting. If you think of the laboratory as a business, then LIMS is the Enterprise Resource Planning system of the lab.
Example of LIMS to PCS interfacing
Island mentality?
Laboratories themselves have evolved a lot in the last 20 years. It used to be the case that labs were almost a separate part of the business, an island within the organisation. Laboratories were generally considered as internal services, which generated no money and were run by scientists in white coats. In this environment, a main business objective associated with the lab was to control costs, so luxuries such as dedicated LIMS software were not a priority. Today, the lab has become an integral part of the whole business. Laboratory managers tend to have business backgrounds (or at least, an understanding of the 'bigger picture'), and one can even find labs that generate money by providing external services.
LIMS has evolved in tandem with the labs. In the days when the lab was an island, LIMS was also an island. LIMS would usually not communicate with other business systems (such as Material Requirement Planning and Process Control Systems) and the end-users of LIMS were normally just the chemists and other lab personnel. Nowadays, a mainstream LIMS should offer a wide variety of interfaces, and LIMS is used by many people who are not working in the lab. LIMS has become part of the enterprise.
One example of this change is that LIMS is one of the few business systems that is used from the very beginning to the very end of a product's lifecycle, the so-called 'cradle to grave'. For example, when a company is developing a new product, LIMS is used to test the prototype materials. When the product development is complete, LIMS will be involved in testing the scaling up of the manufacturing. As the product is manufactured, LIMS will manage the testing and release to market. Later on, LIMS can be used to test any complaint samples. In fact, in some industries, LIMS is used for testing samples for many years after the product was made and shipped, generally as a legal requirement. The following chart gives an indication of the main business systems used during the phases mentioned above.
It's good to talk
Interfacing systems are the latest 'must-have' in the software world. It is no longer acceptable to invest in several different software solutions that do not speak to each other. In fact, the expectation is that interfacing should be completely automatic, and that the end-user should never have to transfer information manually from one system to another. The reality can be a little different; even in cases of a single, large software solution from one vendor, the interfaces between the modules of that system can be less than ideal. The good news, at least, is that the situation is improving.
LIMS has had an unusual position within business systems, since it has needed to interface to other systems from the outset. Since laboratories are rarely income-generating, one way of getting money for a LIMS is to tack it onto another project, such as a process control system. Of course, once the LIMS is installed and running, it had better talk to the other systems!
As corporate management realised that LIMS was holding lots of valuable information, it became critical to ensure that all other applicable business systems were interfaced to the LIMS. In many ways, LIMS is the hub of data activity within organisations.
These interfaces can be generally categorised as 'downwards' and 'upwards'. Examples of downward interfaces are connections from laboratory instruments to LIMS. In some cases, an 'instrument' is not just a piece of hardware such as an analytical balance, but an entire software application. One of the most common applications of this kind is Chromatography Data Systems (CDS), which are used in practically every industry. An emerging technology is Electronic Laboratory Notebooks (ELN), which promises to do for pen and paper what an asteroid allegedly did for the dinosaurs.
The overall nature of these downwards interfaces is that LIMS will send a message to the other system, telling that system that there are some samples to test. When the instrument is run, the data is sent back electronically to LIMS for processing. This processing can include trend analysis and specification checking.
An example of an upwards interface is the connection of LIMS to an ERP system. These systems are usually not specific to one department, but rather are owned by the entire business. Within this scenario, LIMS is typically viewed as a service. When the business decides to make some batches, the quality module of the ERP would send a message to LIMS so that the laboratory can get ready to grab some samples. During manufacture, any unexpected laboratory results can be passed on to production immediately, in order to correct any problems. When a batch is completed, LIMS can generate the required Certificates of Analysis, and inform the ERP system electronically that the batches can be sold.
It is expected of upwards interfaces that LIMS data should be instantly available on a console screen, such as the ones supplied with process control systems (see figure below).
In this example, results from the laboratory are displayed in real-time on a mimic screen, so that production operators can react to the information as quickly as possible. These operators may not even realise that there is such as a thing as a LIMS running within their organisation. In some cases, it is even possible to drill down on the data by double-clicking it, in order to see more details.
A key element in 'uniting the islands' is to get other departments to value laboratory data. This can usually be accomplished by simply creating awareness of the other systems. Many modern software solutions allow a 'tourist' mode, where a user can see information within that system without being a full-fledged user of it. For example, a production operator can view LIMS reports via a simple web browser.
A typical modern full-featured LIMS
LIMS and ERP Systems: A Marriage of Convenience
A question usually asked is: 'Do we need a LIMS, if we have a powerful quality module in our ERP system?' It would be handy if a single system could handle all the production information as well as the laboratory activity. This view fits well with the production department, but less so with the lab. Laboratories have special terminology and workflows, which differ (and sometimes even conflict) with production. An example of this is the very nature of a 'sample'. From production's perspective, a 'sample' is a jar full of some liquid, powder, or solid that is sent to the lab; from the lab's perspective, a 'sample' is a collection of tests to be done. One jar can easily lead to many LIMS samples, such as aliquots and subsamples. Equally, LIMS samples are sometimes created from composites of several production samples.
Laboratories have detailed workflows covering the processing of samples. These workflows include basic elements such as: sample login; and result entry; as well as more complex elements, such as sample sequencing and data review.
Another justification for using a LIMS rather than relying on an ERP system is that laboratories are very dynamic, with frequent workflow changes. Large-scale ERP systems can be updated to reflect these changes, but these updates tend to have an effect on non-lab related activities. Since LIMS is primarily a laboratory system, it can be updated and reconfigured to address workflow changes without affecting the rest of the business. Another issue is that the lab may perform testing to see how well the lab methods are working.
The mechanics of interfacing
Since interfacing is such a standard offering of many business systems, most have published interfaces. In some cases, the published interface is only the importing side; in others, the interface is outgoing as well.
The first element is the data-transport mechanism. These include well-established ones like file transfers and database message queues, as well as more recent ones such as e-mail and OLE for process control (OPC). The strengths and weaknesses of each mechanism is for a different article, but they all work in the same general way. An application prepares a message and gives it to the transport mechanism. The receiving application reads the message and processes it. In some cases, the receiving application might send a confirmation or failure message back to the sending application. However, this is usually not necessary, since current transport mechanisms are very reliable.
Once the transport mechanism has been determined, the next step is to decide the message format. For historical reasons, the dominant format is the use of text files, usually in the format known as 'comma-separated values' (CSV). These are easy to create and read, and can even be simulated by using a basic text editor. A more flexible (and currently very trendy) format is XML, which is widely used over the internet.
Next, the contents of the message have to be determined. Of course, the message must contain the mandatory elements (such as a batch name, and product ID), but it is common to send additional information. For example, a message from an ERP to a LIMS regarding the creation of a batch might also contain the actual product limits and specifications, even though these are already in LIMS. This would allow LIMS to compare its own product specifications with those stored within the ERP system.
The last piece of the puzzle is to decide whether this message will be 'pushed' or 'pulled' (or both). Should the message be sent (pushed) the instant that the data is created, or should the receiving application check (pull) to see if there is any data to process? The norm in the software industry is to push data, but certain circumstances warrant a pull. For example, if LIMS needs more information from ERP, it can fetch it without requiring an ERP operator to send it.
Hindsight is 20/20
Once an interface has been set up, it becomes clear that there is usually a better way of approaching it. With this in mind, a number of hints and tips are on offer:
- KISS: Keep It Simple, Stupid. Low-tech is generally more reliable than hi-tech (although less fun). The main objective of an interface is to be able to trust it.
- Use the application's published interfaces, if convenient. This will usually translate to a quick and reliable connection, which would be supported by the application's vendor. On the other hand, create your own mechanism if the published one is not appropriate.
- Treat each direction of an interface as a separate problem. There is no rule that states that the same mechanisms need to be used for both the incoming and outgoing messages.
Create a simulator that tests the interface without the use of the sending application. It is usually difficult to set up an interface if one or both of the systems are in live use, since test data can interfere with real data. With this in mind, a simple program can be used to simulate the sending of the message; examples include the use of simple text editors like Notepad.
Use human-readable text in the message. This will allow review of the message without actually importing it into the receiving system. It also allows the message to be slightly modified without re- sending. This may also mean that some additional information may be included in the file that is not used by the receiving application. For example, if release codes are used from LIMS to an ERP, then the actual meaning of the code ('Approved for use', 'Quarantine', etc.) can be included in the message. This will aid the long-term management of the interface.
Allow data overlap. It can be hard in certain cases to determine which system 'owns' the data, as the same information may exist in both systems. The classic example of this is product specifications, which are usually defined both in ERP as well as in LIMS. The main trick is to find technical or even procedural ways of keeping this data synchronised.
But the single best piece of advice is... Get the vendors of both systems to sort out the interfacing. It is usually in the software vendor's interest to have working interfaces to other systems, as this leads to more sales, a better technical reputation and, most importantly, satisfied customers. Vendors are quite accustomed to working with other vendors, sometimes even with competitors!
Closing the gap
In our modern age, companies are dependent on (and at the mercy of) the software applications they run. These programs hold large amounts of the company's knowledge and history. These same companies invest millions of dollars annually in ensuring that their personnel communicate (weekly meetings, conference calls, etc.) Isn't it time to do the same with their software?
Interfacing system A to system B is much easier than most people realise, and the benefits are enormous. These benefits are particularly important when using a LIMS, as the majority of the organisation's QA/QC data is stored within it. Creating a global village (rather then islands) of information will result in a truly enterprise LIMS solution.
Mark Gonzalez is technical director, LabWare Europe
