+91-9849263972 [email protected]

Menu

Laboratory Information Management System

Laboratory Information Management System

A

"Laboratory Information Management System" (LIMS) is computer software that is used in the laboratory for the management of samples, laboratory users, instruments, standards and other laboratory functions such as invoicing, plate management, and work flow automation.


Overview

A Laboratory Information Management system (LIMS) and a Laboratory Information System (LIS) perform similar functions. The primary difference is that LIMS are generally targeted toward environmental, research or commercial analysis, such as pharmaceutical or petrochemical, and LIS are targeted toward the clinical market (hospitals and other clinical labs).

Today's trend is to move the whole process of information gathering, decision making, calculation, review and release out into the workplace and away from the office. The goal is to create a seamless organization where:

  1. Instruments used are integrated in the lab network; receive instructions and work lists from the LIMS and return finished results including raw data back to a central repository where the LIMS can update relevant information to external systems such as a Manufacturing Execution System or Enterprise Resource Planning application.
  2. Lab personnel will perform calculations, documentation and review results using online information from connected instruments, reference databases and other resources using electronic lab notebooks (ELN's) connected to the LIMS.
  3. Management can supervise the lab process, react to bottlenecks in workflow and ensure regulatory demands.
  4. External participants (department, company) can place work requests and follow up on progress, review results and print out analysis certificates and other documentation (perhaps even historically).

In fact, with the advent of SOA and other Web 2.0 technologies, today's (2007) LIMS is being defined as a complete ERP for the laboratory, no longer restricted to sample monitoring and results entry. Although it can be client-server or PC-based, it is increasingly web browser-based and provides a large assortment of functionality.

Common issues for LIMS implementation

Most LIMS products allow the laboratory to; register work requests; print analytical worksheets; monitor and communicate sample/technique backlogs; schedule work; acquire and store analytical data; monitor the quality of all analytical work; approve analytical data for client release; print and store analytical reports and invoices; protect the security of all data; track and locate samples in storage; track and communicate all quality control in the laboratory; provide laboratory management with production and financial statistics and with client information, e.g., names, addresses, sales figures, etc. An appropriately designed and installed LIMS can quickly bring accuracy and accessibility to the flow of samples and data in any laboratory. The real value of a LIMS is the ability to maximize sample throughput and minimize labor costs.

Laboratory throughput is improved in a number of different ways. The most obvious gain in productivity occurs through the elimination of data entry via on-line instruments. Also, there will be a significant decrease in data entry errors. Finally, the up-to-date sample in-flow data available from a typical LIMS allows laboratory supervisors and bench personnel to better schedule analytical work, minimize "downtime" and maximize batch size. Some other effects are that there are better visible quality control checks and centralized data. The ability to monitor, track and communicate data and quality control information gives the laboratory the tools to improve methods and work practices. The end result is that people in the lab able to process more samples per hour worked.

Design/Scoping Process :
The design/scoping stage prior to acquiring our LIMS has involved the review and analysis of available software/hardware packages as well as the definition and documentation of our laboratory's requirements. The error here is could be that bench personnel are excluded from the process. To resolve this problem we have had frequent meetings with the personnel in our lab.

Some laboratories might go into a LIMS program believing that future requirements for bench level supervision will be reduced or eliminated. It has been recognized by many that LIMS is simply a tool and as such cannot manage the laboratory or take the place of personnel supervision. A LIMS will effectively provide current, reliable and complete operational data. The easy access to accurate data allows management to significantly enhance the quality and speed of decision making. Decision making becomes based more on fact rather than instincts.

Many LIMS products tend to function more like accounting or financial databases. This could be related to the educational and work experience of most software professionals. The demand for financial and accounting database packages means that the software industry is more familiar with this type of requirement than with a highly technical application like a LIMS. Thus, the average software professional does not usually have the background to effectively interpret a laboratory's requirements. This communication problem can manifest itself in LIMS systems that do not easily fit into laboratory operations. Often the laboratory must significantly alter procedures and work flow in order to conform to the LIMS. This requirement for wholesale change significantly complicates LIMS installations and it might have poor acceptance and commitment support personnel to the project.

A similar problem often occurs in large organizations with dedicated Information System (IS), departments. Significant conflict and problems can arise when IS personnel recommend the most up-to-date hardware or software architecture regardless of the functionality, fit or overall cost to the laboratory. The end result of this process is that the laboratory must undergo significant change in order to conform to the product purchased. In the extreme case laboratories can wind-up having to increase overhead, e.g., more data handling, in order to use LIMS systems that have been designed not for the laboratory but for the accounting or production departments.

The keys to success are flexibility, adaptability, ease of evolution and support, and most importantly overall system speed. The speed issue is very critical as bench personnel will not use something that is slow or awkward. If the system saves bench personnel time they will quickly "buy into" the project and aggressively move the process forward.

The key in any LIMS development should be to achieve a majority of the desired functionality without compromising system speed. Most laboratories need time to assimilate a LIMS before being able to take full advantage of all of its features. As a result of this 'break-in period' the more complex features can usually be postponed a year or two without affecting the success of the program. This implementation delay may also allow laboratory personnel the chance to provide more input into the critical final stages of system optimization.

Installation Phase:
The goal of any LIMS installation must be to acquire a system that will make the jobs of bench personnel easier and thus increase the efficiency of the organization. In order to be successful, the LIMS system must be accepted and welcomed by the bench personnel. Often the first contact front-line personnel have with the new system is during installation, long after all decisions have been made. This situation often leads to significant software and LIMS configuration problems that require major software re-writes, hardware retro-fits and/or disruptive organizational changes. In addition, analytical and support staff are more likely to resist the new system if they have had little input into it's design and operational characteristics.

The installation phase of a LIMS program is critical to the overall success of the project. It is during LIMS installation that personnel must be taught how to use the product and where the software designers get their first view of how the LIMS will fit into and function in the laboratory. The installation phase of a LIMS project can take from weeks to months depending on the size of the laboratory and the complexity of the project.

The History of LIMS

Originally, LIMS were developed in-house by organizations who wanted to streamline their data throughput and reporting processes. In-house LIMS can take considerable time and resources to implement. The need for a more immediate solution helped drive LIMS to the next stage in the 1970s. During this time, custom-built systems became available. These early custom systems were one-off solutions designed by independent systems development companies to run in specific laboratories.

Parallel to these custom-built LIMS implementations were the initial efforts to create commercial LIMS products. These extensive research efforts resulted in the first commercial solutions that were formally introduced in the early 1980s. Such commercial LIMS were proprietary systems, often developed by analytical instrument manufacturers to run on the instrument the manufacturer manufactured.

These commercial systems, while typically developed for a particular industry (such as the pharmaceutical industry), still required considerable customization to meet a specific laboratory's needs. In particular, laboratories often expect -- and in many cases require -- very specific format and reporting requirements. However, such demands for customization increase the cost of the commercial LIMS and extend the implementation time.

Parallel to the rise in commercial LIMS was the increase in processing speed; the increase in third-party software capabilities; and the reduction in PC, workstation and minicomputer costs. These advantages have been transferred to the laboratory and LIMS environment.

As a result, the migration away from proprietary commercial systems toward an open systems approach is in full swing. Now, commercial LIMS offer increased flexibility and functionality.

Laboratory information system Features

A lab information system (LIS) is a class of software which handles receiving, processing and storing information systems such as hospital information systems (HIS). An LIS is a highly configurable application which is customized to facilitate a wide variety of laboratory workflow models. Deciding on an LIS vendor is a major undertaking for all labs. Vendor selection, typically takes months of research and planning. Installation takes from a few months to a few years depending on the complexity of the organization. There are as many variations of LISs as there types of lab work. Some vendors offer a full service solution capable of handling a large hospital lab's needs, others specialize in specific modules. Disciplines of laboratory science supported by LIS' include hematology, chemistry, immunology, blood bank (Donor and Transfusion Management), surgical pathology, anatomical pathology, flow cytometry and microbiology. This article covers clinical lab which encompasses hematology, chemistry and immunology.

Basic operation:
Laboratory Information Systems are often part of an integrated informatics solution which involve many disparate applications. Use of an LIS is a critical piece of the clinical IT spectrum of systems and contributes significantly to the overall care given to patients. The LIS is used in inpatient and outpatient settings and in many cases is designed to support both. From an outpatient/ambulatory perspective, LIS interaction frequently begins after a physician has arrived at an initial diagnosis. For example, a patient enters the hospital looking pale and complaining of fatigue. The physician, suspecting anemia, might decide to order a complete blood count (CBC). In an inpatient setting when that patient is admitted into the hospital, the system is used to order tests, provide specimen processing assistance, receive the results from analyzers and deliver lab reports to the attending physician.

Order entry and check in:
An order is placed in the system usually by a physician, physician's assistant, nurse, and office clerk or laboratory technologist. The order or lab request contains a list of tests to be performed on one or more patient specimens, for example blood or urine. In many cases, each order is tracked with a unique identifier. This identifier (which is usually a number) is often referred to as an accession. In this hypothetical case, a CBC is ordered which is a panel of sub tests including white blood cell count, red cell blood count and other blood-related tests.

A phlebotomist will be called upon to collect the specimen(s) from the patient. Often, different specimens will be collected, so as to provide a different tubes, with a specific cap color, for each analyzer that will process the samples. In this case, the appropriate specimen (Lavender top tube) is taken from the patient, labeled with a bar code specimen label produced by the LIS. The LIS will print barcoded labels (with the unique accession) for the draw tubes. In some cases, more advanced LIS products will also provide a unique identifier for each specimen. This provides the ability to track, at the specimen level, the chain of custody from the point it is taken from the patient to the point that it gets discarded. The specimen-accession-patient hierarchy is linked in a tree like numeric structure. In other cases, the patient is identified by a Patient-ID, and the Sample-ID is linked to the patient's demographic record through the Patient-ID.

Specimen receiving:
After the specimen is collected, it is sent/brought to the appropriate lab for processing typically in a batch. This event should be recorded in the LIS. Upon reception in the appropriate testing lab, either manual or automated lab work can begin. CBCs are performed by automated anaylzers.

Send test orders to analyzers:
Most LIS systems can be configured to download the specimen data to an analyzer either after the order is placed or when a specimen is received in a testing lab. When the barcoded specimen is read by the instrument, the unique ID is read off the specimen label and matched with the order previously downloaded to the instrument. This system is often called "Batch Download". A more efficient system is called "Host Query", where the instrument reads the barcode on the specimen and "queries" the LIS for the test orders. The LIS will be listening on a communication port for queries and will download the requests only when required. In cases where the LIS transmits data such as test orders or control messages to analyzers the communication is set up to be bi-directional.

Results entry:
When results of lab tests are available, they are entered into the system manually or automatically downloaded from an instrument. Once these results are double checked by the medical technologist or autoverified, they are released. Released results are often automatically printed to lab reports which are delivered to the attending physician. LIS systems often provide additional resulting functions and patient care assistance by providing Delta Checking and Reflex Testing functionalities. Results must be, as soon as possible, verified and medically interpreted for physicians by a Clinical Pathologist.

Lab reporting:
Lab Reports are the final output of all LIS systems and, in many cases, the primary LIS interaction with healthcare professionals outside of the lab. They can either be printed or faxed in paper-based labs, or delivered via email, file or HL7 interface in paperless installations. The degree to which an LIS supports customizable lab reports and flexibility in modes of delivery of results is one major factor in determining its success in the marketplace.