laboratory information and management system: a tool to increase laboratory productivity

46

Introduction

The modern laboratory exists in an environment that produces a large amount of data. With the advent of new technologies, both the quality and quantity of informa-tion is increasing exponentially. This increase of data can cause significant problems and methods are needed to manage it. One such method used is a Laboratory Information Management System (LIMS) (1).

A LIMS provides a way of automating part of the laboratory system. In a traditional laboratory 75% of the total cost comes from manpower. Removing the need for some human interaction can significantly reduce overheads. The primary function of most laboratories is to provide validated information under some sort of time constraint and then, based on that information, allow customers to make decisions (2). Nowadays, traditional record keeping solutions are simply not up to the task. A LIMS can be of great importance in integrating laboratory operations with the laboratory itself. One of the most important aims of a LIMS is the integration of many different sub-processes, bringing together and

consolidating the efforts of potentially many individuals and consequently speeding up the whole process.

LIMSs can save considerable amounts of time and dramatically improve the level of data access for all stakeholders of any given project. This is where a LIMS can become extremely beneficial. The sooner the user is notified of a problem, the sooner that problem can be fixed and the less the solution will cost (1–3). The ideal LIMS should help provide the documentation to ensure that a laboratory and all of its operations exist in compliance. LIMSs have been used for over 20 years, and the technology has been considerably evolved during this time.

LIMS: Basic information

A LIMS is a computer application designed for the ana-lytical laboratory that is designed to administer samples, acquire and manipulate data, and report results via a database. It automates the process of sampling, analysis, and reporting (4) (Figure 1).

REVIEW ARTICLE

Laboratory information and management system: A tool to increase laboratory productivity

Sunil K. Dubey, Amit Anand, and Hemanth Jangala

Department of Pharmacy, Birla Institute of Technology and Science, Pilani, Rajasthan

Abstract‘Information is a crucial capital asset of any business and its commercial prospect is directly related to successful management of its information resources’. Laboratory Information Management System (LIMS) is software that is designed to administer samples, acquire and manipulate data, and report results via a database. It automates the process of sampling, analysis, and reporting. This paper discusses components, sample workflow, application, and validation of LIMS. The contents of this paper are easy to understand. The objective of this paper is to discuss how LIMS works and its application, and to discuss a potential approach to validation of the LIMS. A literature search was conducted in various journals. Based on title and abstract, 30 papers were identified. Extraction of useful information was done after thorough study of selected papers. Components of LIMS, how it works, its application, and potential approach of validation of LIMS was compiled in an easy-to-understand way. In conclusion, LIMS is a critical component of successful commercial laboratory in quality control, process control, and R&D environment.

Keywords: LIMS, database, reporting, decision, quality control, management tool, validation, GAMP V model

Address for Correspondence: Sunil K.Dubey, Birla Institute of Technology and Science, Pilani, Rajasthan. Tel: 9887146578. E-mail: [email protected]

(Received 03 April 2012; accepted 04 May 2012)

Clinical Research and Regulatory Affairs, 2012; 29(2): 46–56© 2012 Informa Healthcare USA, Inc.ISSN 1060-1333 print/ISSN 1532-2521 onlineDOI: 10.3109/10601333.2012.692689

Clinical Research and Regulatory Affairs

Apr032012

May042012

1060-1333

1532-2521

© 2012 Informa Healthcare USA, Inc.

10.3109/10601333.2012.692689

Laboratory information and management system

S. K. Dubey et al.

29

2

46

56

2012

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.

mailto:[email protected]

http://informahealthcare.com/doi/abs/10.3109/10601333.2012.692689

Laboratory information and management system 47


In the generic sense, the LIMS is how a laboratory tracks and manages its information resources, particu-larly the data that represents the laboratory product (5).

LIMS environment

In reality a LIMS is more complex than just a single appli-cation and, hence, the term LIMS environment can be described as at least two of the following elements:

• LIMS application;• Analytical instruments interfaced directly with the

LIMS;• Laboratory data systems and computer systems

interfaced with the LIMS (chromatography data systems, scientific data management systems, elec-tronic laboratory notebooks, etc.); and

• Applications outside of the laboratory that are also interfaced to the LIMS (enterprise resource planning systems) This is a short scope of the computerized

system that could be validated within a LIMS project and is shown in Figure 2.

Designing the LIMS environment means that you need to consider all the other systems in the laboratory that must interface with the LIMS. This includes other applications such as scientific data management systems, Chromatography Data System (CDS), and electronic lab notebooks (ELN), as well as various data systems that may be attached to those or run independently. It also includes analytical instruments, chromatographs, and laboratory observations shown in the lower half of Figure 2. Data can be transferred to the LIMS by a variety of means:

• Direct data capture from an instrument connected directly to the LIMS;

• Data capture from an instrument with analysis and interpretation by the attached data system and only a result is transferred to the LIMS;

• As above, but the results or electronic records are transferred to the LIMS via a Scientific Data Management System; and

• Laboratory observations can be written into a note-book then entered manually into the LIMS or cap-tured electronically via an Electronic Laboratory Notebook (ELN) and transferred electronically to LIMS. To summarize, the five key actions of LIMS are

• Data are captured or entered into the system. This data may be entered manually or captured electroni-cally through such mechanism such as file parsers,

• The data are analyzed and organized. This process typically includes adjusting for the significant digits and checking against the limits,

• Data are reported, and• LIMS provide support for the lab management functions

such as sample tracking and workload assignment (6).

Once the laboratory side of the LIMS environment has been designed, the LIMS needs to be integrated in the organization. Some of the systems to construct the LIMS environment here and interface with the system are:

• Email for transmission of reports to customers or keeping them aware of progress with their analysis;

• LIMS web servers for customers to view approved results;

Figure 1. A LIMS has two targets. A LIMS sited at the interface between a laboratory and an organization. Samples are generated in the organization and received in the LIMS followed by laboratory analysis. The data produced during analysis are reduced within the LIMS environment to information which is transmitted back into the organization. This represents the ideal placement of the LIMS: both the organization and the laboratory benefit via the system. The line dividing the organization and the laboratory shows that the LIMS is of equal benefit to both. There are other versions of this diagram that can be implemented that provide virtually little benefit to the laboratory and the organization.

Abbreviations

CDS, Chromatography Data System

CFR, Code of Federal Regulations

EBRS, Electronic Batch Record System

EDMS, Electronic Document Management System

ELN, Electronic Laboratory Notebook

ERP, Enterprise Resource Planning

FDA, Food and Drug Administration

GAMP, Good Automated Manufacturing Service

GMP, Good Manufacturing Practices

IQ, Installation Qualification

IT, Information Technology

LIMS, Laboratory Information Management Systems

MRP, Material Replenishment Planning

OQ, Operational Qualification

PQ, Performance Qualification

QA, Quality Assurance

SE, Software Engineering

UAT, User Acceptance Testing

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.

48 S. K. Dubey et al.


• Applications maintaining product specifications;• Enterprise Resource Planning (ERP) systems for

linking the laboratory with production planning and batch release;

• Electronic Document Management Systems (EDMS); and

• Electronic Batch Record Systems (EBRS): these are just a few of the possible applications that a LIMS could be interfaced to; the list of potential candidates will be based on the nature of the laboratory and the organization it serves (7,8).

How it works

It acts as a core unit for the distribution and analysis of data generated in laboratories from different sources and act as an interface between different systems and tools used in laboratories. It streamlines the data flow within the organi-zation and centralizes the information into one database.

Once the sample is logged into the LIMS package, it automatically takes over the further operations and generates the work sheet/protocol sheet/analytical work record. The work sheet contains all the tests required to be carried out for the sample (Figure 3).

While carrying out the actual testing, the readings and observations are noted down in the work sheet. After completing the tests all data are fed into the LIMS pack-age. It automatically calculates the results, compares the findings with the standards, and also decides about the compliance with the standards. After this it prints out the certificate of analysis in the prescribed format that is already fed into the software. It is the LIMS that

decides about the conformance and non-conformance of the sample with the standard and not the analyst. The analyst just has to enter the required inputs (read-ings/observations); the desired output format can be selected, and results can be generated in desired options without giving any external formulae for calculation (9).

Application

• All the product specifications, standard tests pro-cedure, standard operating procedures, calibration procedures, etc. may be efficiently maintained using LIMS.

• It also serves as an important management tool. It generates various reports including the quality con-trol, productivity report, analyst performance report, samples pending for the sampling, samples under analysis, lab performance, etc.

• Keeps track of the due dates for re-sampling and also generates a report at regular intervals—informing well in advance about the materials due to be tested.

• LIMS has emerged as the most appropriate tool to assist toward compliance with GLP principles. LIMS can make a major contribution in improving the quality, efficiency, and competitiveness of a labora-tory.Thus enables the laboratory to achieve its qual-ity goals (10) (Figure 4).

Benefits of LIMS

A LIMS provides benefits for many of the users of a labo-ratory. However, a LIMS does represent an expense that

Figure 2. Diagram of a LIMS environment. This figure shows the interfacing of LIMS with different systems.

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



must be considered. This expense will almost certainly have to be justified by a level of higher management. The following is a brief outline of several of the main benefits identified and realized from current users of LIMS (11).

(1) Information can be obtained with the click of a but-ton rather than having to dig through files.

(2) Years of data can be kept easily without the need for traditional archiving.

(3) The improvement of business efficiency. (4) Improvement of data quality (all the instruments

are integrated).

(5) Automated log-in, tracking, and management. (6) Automated customer reports (Turnaround Time,

Work Load). (7) Automated Integration of Hand-held LIMS devices. (8) Automated Quality Control. (9) Daily Quality Reports.(10) Easily accessible data via the web.

Selection of LIMS

It is said that a successful LIMS implementation is closely linked to the selection process. Selection and implemen-tation of the LIMS is a complex process (12). It is very important to select the right product, as this will have a major impact on the success of the LIMS project. The selection process should be thought of as an official part of the LIMS implementation process.

There are many steps involved in the selection process. One of the most important (and frequently missed) steps in LIMS selection is a method known as WPE (Work Process Evaluation). WPE is used primarily to define the role of LIMS within the organization. Requirements must be clearly specified, concise, and well understood. Once these requirements have been clearly defined, the selection process can enter the ‘Purchase Process’. This process should include viability studies:

• What is the state of financial health of the company supplying the products? Will they be around in 2 years when you need to upgrade?

Figure 4. Various applications of LIMS.

Figure 3. Sample work flow diagram.

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



• What are the future plans for the company? Are they planning on shifting business strategies, rendering your purchase obsolete?

Portability

It is imperative that laboratory information be avail-able both inside and outside of the lab. This availability of information is critical for improving both the quality of the products and the productivity of the users. One of the methods is using an interactive application (13). This requires the Pocket PC to be connected to the net-work at all times. This can be achieved by either an IEEE 802.11 broadband wireless network connection or by using a cellular telephone connection (General Packet Radio Service). The Pocket PC may act as a browser to a much larger LIMS elsewhere. In this situation, data is always current as it is constantly being downloaded and uploaded, so as to provide a more vigorous system. This scenario does rely on being connected to the network at all times. As a result, the system will not function in areas where the network is not available.

Customization

LIMS can save vast amounts of time and dramatically improve productivity within the workplace (14). However, inevitably no two laboratories are going to be the same. Work practices, management structure, strategy, expec-tations, and human involvement are all going to differ. How can a LIMS be produced so as to satisfy this gantry of differing criteria? The answer is simple. It cannot. The solution is to provide the users with a LIMS, which they themselves can customize and alter to their own ends. This removes the need for the LIMS developer to include specific functionality, rather providing the means for LIMS users to provide their own. As a result, the overall potential functionality for the system is greatly increased.

One point to note is that customization does not sim-ply involve passing on a shell of a working program to a customer. It may involve extensive testing and analysis of the stakeholder’s requirements. User feedback can help a developer produce a new, more efficient process, auto-mating as many activities as possible.

There are two main ways of providing customization to a LIMS. The first is to include a scripting language with the LIMS. LIL (Laboratory Interface Language) from Lab Manager is an embedded high-level language with which the user can write their own methods and rou-tines to automate repetitive tasks (1). With a language, such as LIL, users can combine parts of the system, uti-lizing available additional functions supplied with LIL. This approach is not unique to Lab Manager. Most LIMS developers provide some sort of scripting language in order to allow the user to customize, develop, and prog-ress their laboratory system.

Another means of customizing a LIMS is to provide a packaged customized LIMS to the customer right from the start. This is usually advantageous for laboratories conducting research on fairly generic subjects. For example, consider the problem of integrating molecular genetics analysis capabilities into a LIMS. gtLIMS is a pre-customized LIMS that specializes in this area (15). gtLIMS contains the basic building blocks found in a nor-mal LIMS. However, additional features have been added in order to create gtLIMS and make it more specialized to its target domain.

LIMS specification

Localized standards are emerging such as LECIS (Laboratory Equipment Control Interface Specification) (16). This technology is concerned with providing a specification to provide a robust standard for commu-nicating between equipment from different control-lers and platforms. The problem is that developers are inherently more concerned with improving their core capabilities rather than their interfaces and engineering standard. This can often result in poorly designed device interfaces, which can be very inconvenient for imple-menters. LECIS aims to define the interactions between the devices and the controllers in order to achieve some level of operation. The degree of flexibility pushes LECIS into more of a specification-type category, although, in 1999, LECIS was balloted through ASTM and has become standard E1989-98.

Safety, security, and reliability

For a LIMS to exhibit these three attributes, it is necessary to look closely at two important areas; the LIMS imple-mentation programming language and the LIM operat-ing system (17). The programming language should be capable of defensive programming. Functions such as exception handling, variable typing, and garbage collec-tion should be present in a viable LIMS programming language. The OS should be completely robust. It should monitor and regulate all resources under its control, ensuring that they are not being illegally accessed, mali-ciously or otherwise. The system must be secure at all points. This means considering dual processor machines, uninterruptible power supplies, network clusters, and hot-swappable components.

Validation of LIMS

Significance of validationValidation is an important and mandatory activity for laboratories that falls under regulatory agency review. Such laboratories produce data upon which the government depends to enforce laws and make decisions in the public interest. Examples include data to support approval of new drugs, prove marketed drugs meet specifications, enforce environmental laws, and

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



develop forensic evidence for trial. This also extends to LIMS used in environmental laboratories. In some cases these systems may need to be interoperable with CLIMS and computer-based patient records (CPR) for reporting environmental exposures and clinical laboratory testing for biologic measures of stressor exposure. The enormous financial, legal, and social impacts of these decisions requires government and public confidence in laboratory data. To ensure this confidence, government agencies regularly review laboratories operating under their rules to confirm that they are producing valid data. Computer system validation is a part of this review. This guide is designed to aid users validating LIMS and incorporating the validation process into their LIMS life cycle.

Validation must provide evidence of testing, train-ing, audit and review, management responsibility, design control, and document control, both during the development of the system and its operation life (18).

Typical documentation for a LIMS validationDocument Name, followed by sub-bullets indicating Outline Function in Validation

(1) System risk assessment

a. Documents the decision to validate the LIMS or not and the extent of validation work to be undertaken

(2) Validation plan

a. Documents the scope and boundaries of the validation effort

b. Defines the life cycle tasks for the systemc. Defines documentation for validation packaged. Defines roles and responsibilities of parties

involved

(3) Project plan

a. Outlines all tasks in the projectb. Allocates responsibilities for tasks to indi-

viduals or functional unitsc. Several versions as progress is updated

(4) User requirements specification (URS)

a. Defines the functions that the LIMS will undertake

b. Defines the scope, boundary, and interfaces of the system

c. Defines the scope of tests for system evalua-tion and qualification

(5) System selection report

a. Outlines the systems evaluated on paper or in-house

b. Summarizes experience of evaluation testingc. Outlines the criteria for selecting chosen

system

(6) Functional risk assessment and traceability matrix

a. Prioritizing system requirements: mandatory and desirable

b. Classifying requirements as either critical or non-critical

c. Tracing testable requirements to specific PQ test scripts

(7) Vendor audit report

a. Defines the quality of the software from sup-pliers perspective (certificates)

b. Confirms that quality procedures matches practice (audit report)

c. Confirms overall quality of the system before purchase

(8) Purchase order

a. From supplier quotation selects software and peripherals to be ordered

b. Delivery note used to confirm actual delivery against purchase order

c. Defines the initial configuration items of the LIMS

(9) Configuration specification

a. Defining the configuration of the system policies

b. User types and access privilegesc. Default entries into the audit trail defined

(10) Software module specifications

a. Specifying a custom module and how it will integrate within the LIMS

b. Coding and documenting the module to pre-defined standards

c. Informal developer testing and correction of the module code

(11) Technical architecture (technical specification)

a. IT platform(s) defined, e.g. terminal serv-ers, database server together with resilience features

b. Operating systems and service packsc. Operating environments: production, valida-

tion etc.

(12) Installation qualification (IQ)

a. Installation of the components of the system by the IT and the LIMS supplier after approval

b. Testing of individual componentsc. Documentation of the work carried out

(13) Operational qualification (OQ)

a. Testing of the installed systemb. Use of an approved suppliers protocol or test

scriptsc. Documentation of the work carried out

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



(14) LIMS application configuration

a. Configuration of the LIMS application according to the configuration specification data base population

b. Controlled input of methods to the LIMSc. Controlled input of raw material, interme-

diates, and in process control sample and finished product specifications to the LIMS Module

(15) Testing and integration of custom software

a. Formal testing of the module against the soft-ware design specification

b. Integration testing with the LIMS application

(16) Data migration

a. Identification of the data elements and fields to migrate from an old LIMS, e.g. specifica-tions, results, on-going stability studies

b. Planning and executing the workc. Confirming the successful data migration

(17) User acceptance test (e.g. PQ) test plan

a. Defines user testing on the system against the URS functions

b. Highlights features to test and those not to test

c. Outlines the assumptions, exclusions, and limitations of approach

(18) PQ test scripts

a. Confirmation of software configurationb. Test script written to cover key functions

defined in test planc. Scripts used to collect evidence and observa-

tions as testing is carried outd. Documents any changes to test procedure

and if test passed or failed

(19) User training, SOPs, and system documentation

a. Procedures defined for users and system administrators including definition and vali-dation of custom calculations, input of speci-fications, account management, and logical security

b. Procedures written for IT-related functionsc. Practice must match the procedure

(20) Service level agreement (SLA)

a. Agreement between the laboratory and IT for IT and infrastructure services for the LIMS User Training Material

b. Initial material used to train super users and all users available

c. Refresher or advanced training documentedd. Training records updated accordingly

(21) Validation summary report

a. Summarizes the whole life cycle of the LIMSb. Discusses any deviations from validation

plan and quality issues foundc. Management authorization to use the systemd. Release of the system for operational use

(19,20).

Validation of LIMS installed at customer siteThe customer shall validate their use of the LIMS, indepen-dent of any vendor audit, in the operational environment in which the LIMS will be residing. The fact that a vendor’s LIMS development process has been validated by the ven-dor or other organizations has little bearing on validating the organization’s LIMS application. Further, the fact that a vendor’s LIMS software has been validated by one of their other customers does not obviate the need for an organiza-tion to validate their implementation of the application.

As key functional requirements are identified and eval-uated during the product evaluation phase, their results should be recorded. These results may be used in develop-ment, execution, and documentation of the official LIMS test protocols. Any testing done during development of the LIMS test protocols or overall validation plan should be further refined once a specific LIMS has been selected. It should be noted that the level of testing and evaluation done during the evaluation and selection process gener-ally will not contain enough detail to replace the test pro-tocol used in the validation plan documentation.

The LIMS validation team may begin to identify additional resources to test the LIMS. Any new indi-vidual’s selected should be familiar with the laboratory’s requirements and its operation. Further, they should be knowledgeable about cGMP, GMP, GLP, GALP, or other requirements that the laboratory shall follow.

The LIMS typically is delivered as an empty database, that is, devoid of site-specific data. Configuration data and fixed laboratory information must be entered before the system can be validated. At this point, the organization starts to model their laboratory practices in LIMS. This includes test and workstation definitions and laboratory and customer personnel data. It should be noted that during this step the laboratory may encounter additional functional requirements that were not captured initially. If the organization chooses to implement such functionality, the LIMS requirement document shall be revised to reflect these changes. Further, during this step the organization may uncover requirements that the LIMS cannot meet. The organization should document these facts and include what actions, if any, they will take to solve this problem. There are several strategies that can be used to validate a LIMS. These include, but are not limited to, the following:

• Configure the LIMS specifically for testing with only enough configuration data to permit testing. In this case, the test system is identical to the production system; specifically, it is functioning in the same

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



operational environment as the production system. Generally, this means that it is operating on the same computer on which the production system will reside. The configuration used in the test system shall exactly match the production system. Specifically, all reports, entry screens, queries, etc., must be identi-cal. Furthermore, all features that are to be used in the production LIMS shall be checked for proper operation in the test system.

• Configure the LIMS for regular operations, then is- late it from normal service while testing it. A system configured for use is called the production system. This can be accomplished by copying the production database to the test system. The LIMS program executables are the same; for example, the validation data may be part of a separate set of database tables that use the same program executables as the production LIMS, or the validation data may be part of a different data group that uses the same database tables and executables as the production LIMS. The difference is in the sample data tables. If there are no problems, this approach saves time. The LIMS does not have to be configured twice, once for testing and again for production. If problems are found, partial or complete reconfiguration may be required after repairs are made. Documentation verifying that the production system is equivalent to the test system shall be provided, and the data generated during the validation process should be retained and identified as validation data.

A separate computer system may be used for testing. The separate computer may be configured specifically for validation. If a separate computer is used, it should have identical hardware, software, and operating sys-tem. The operating environment shall be identical to the one used for the production system. Instrument interfaces may be difficult to install on such a test sys-tem, but if they are part of the production system, they must be part of the test system as well. Ultimately, the test system could provide backup hardware for the pro-duction system.

The production and test systems may exist on the same computer, if it is sufficiently powerful, running independently. In this case, both software systems may have access to the instrument interfaces.

A sub-set of tests is needed when the test system is con-verted to the production system. These tests are used to confirm that the system still functions properly in produc-tion mode. No artificial data needs to be loaded into the active system. This sub-set of tests may consist of vendor-supplied diagnostic routines and little more, as long as they reliably test all parts of the proposed system. While some vendors supply these types of tools, many do not. There is no standard for their construction and execution. The use of such tools should not be the only means of test-ing the LIMS, but rather augment a more rigorous set of

test protocols. In some cases the organization may require the tools themselves be validated prior to their use.

Parallel testing may be used. For a new LIMS, the manual systems can be used simultaneously with the LIMS and the results compared. If the new LIMS is a replacement, both old and new systems can be used in parallel for some period of time to compare them. The existing validated system is the production system, while the new LIMS is the test system. Validating interfaces to instruments are an issue with a parallel testing approach, since they cannot usually be connected to both systems at the same time. In this case, the organization shall develop an approach that allows for the testing of these interfaces. The organization may want to connect these interfaces to the system undergoing validation after all other tests have been executed and just prior to the devel-opment of the final validation report. Another approach is to incorporate these interfaces as their own validation project conducted after the initial validation has been concluded.

Response to errorsError handling and acceptance criteria shall be defined and described in the validation protocol and followed during the testing and reporting of results. The definition shall include criteria to be used to assess severity of errors.

Critical errors, such as system crashes or fatal errors, located during validation tests should be corrected or repaired immediately, before additional testing is done. Often the correction of such errors requires that most or all of the validation tests be run again. These are errors for which there is no work-around. These errors seriously threaten the integrity of the LIMS data.

Non-critical errors should be accumulated during the validation tests. When testing is complete, the team may decide these errors do not compromise the integrity of the information. These are errors which could result in the possibility that unacceptable result data would be accepted by the LIMS. There may be an acceptable work-around for such errors (21).

The validation team may wish to use an error grading system that helps to take action when errors are encoun-tered. Each error would be identified by grade, and a decision would be made on what follow-up, if any, is necessary. The following are examples of grades and the errors that fall into those grades (22).

• Grade 0—Typographical errors and other errors not related to the computer system.

• Grade 1—Minor errors such as the use of upper and lower case letters used in fields not constructed for them.

• Grade 2—Tolerable errors that must be communi-cated to the vendor.

• Grade 3—Major errors that must be immediately reported to the vendor and the QA manager. All validation efforts should be suspended until QA has discussed the problem.

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



• Grade 4—Disastrous errors such as relational errors in the database. These are reported the same as Grade 3 but the validation effort should be aborted. QA could still decide if the effort continue after thor-ough discussions.

Standard operating procedures (SOPs)SOPs are necessary for validation and on-going operation of an organization’s LIMS. These documents cover several areas, from the operation of the LIMS application through to the hardware on which the application resides. The SOPs formalize the procedures used to maintain the LIMS in a validated state by describing specific procedures to be followed. These procedure help ensure that the organization maintains a quality operation.

Approaches to customized system validation

We need to consider how we will validate the inevitable configuration and/or customization that accompanies all LIMS implementations. Again, there is a range of approaches available, with some benefits and risks to each approach.

GAMP V-modelIs this really a workable model? The first approach is usually described as using the Good Automated Manufacturing Practice (GAMP) V-Model, as cited by a number of companies seeking to sell their validation consulting services. This model is illustrated in Figure 3, and is one that is troubling, to say the least. While the pharmaceutical professional may feel comforted by the familiar IQ/OQ/PQ phraseology, the model does not fit together conceptually with a logical approach for soft-ware system validation (23,24) (Figure 5).

For example, how does the IQ relate to the Detailed Design Specifications? The answer is that it really doesn’t in this context. Looking back to our definition of IQ, we see that this really refers to compliance with appropriate

codes, standards, and design intentions. This is exactly what the user requirements document should be stat-ing. For example, a good user requirements document states which applicable regulations (21 CFR Part 11, etc.) need to be considered for the solution. In addition, the user requirements in their final state should reflect the limitations of a particular software package. Although a package is normally selected after the first draft of user requirements, we must often adjust some of the require-ments to reflect what is available and achievable with a particular package. If we list out requirements that can-not be achieved within our cost parameters, then we either need to adjust our requirements, or reflect that this will be a custom addition to the selected package. However, in any case, we need to have complete trace-ability between the user requirements and the final solu-tion—thus the need for adjustment.

The software engineering V-modelWith the limitations of the previous GAMP V-model in mind, we can take a look at a standard software engi-neering approach to the V-model. Here we see a much more comprehensive approach taken to verification as a pre-requisite to validation. As depicted in Figure 4, we see that for each stage of refinement from the user requirements, there is a verification process. What hap-pens in this verification process is that a review of how well the output of a particular stage maps back to the previous stage takes place. This can take the form of a formal architecture/design/code review, or a series of more informal ‘structured walkthroughs’. In either case, the outcome is the same, and we are looking for where there were potential gaps or poor handoffs between the stages. This is critically important for two reasons. The first is that these tasks are often done by different people, and/or sub-teams with specific skill sets, so some mis-communication or misunderstanding is likely. Secondly, as we understand more and more about the solution, it is likely that additional clarifying questions will be asked about the overall solution. Some of these questions may prompt a modification to the output of the previous stage.

Figure 5. Good automated manufacturing process V-model. Figure 6. Software engineering V-model.

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



Thus, to keep everything in sync, we need to perform the verification step (25,26) (Figure 6).

A combined V-model for pharmaceutical systemsWhile the two previous models both had their shortcomings, if we take both of them together, all of the requirements of a comprehensive validation approach are covered. Both the detailed validation of software development activities (configuration and/or customization), and the overall process aspects are tested and confirmed. Thus, we have a model (as depicted in Figure 4) that combines the GAMP V-model and the software engineering V-model into one logical flow. The starting point is the user requirements, as with the Software Engineering (SE) approach, and the flow continues along the SE approach until the User Acceptance Testing (UAT) as before. However, there is one important point of exception. That is, the UAT and the IQ can be done at the same time, since they are fulfilling similar goals, but for slightly different audiences. The UAT is the opportunity for the end users to confirm that the system fulfills the system expectations, including compliance with appropriate regulations. The IQ is the opportunity for the technical support staff to confirm that the system (both hardware and software) can be installed in an operational environment in a manner that is both repeatable and verifiable via testing. A successful conclusion to both the UAT and IQ is a system that is functionally and operationally qualified to place in the operations environment. From this point on, a more traditional OQ and PQ approach applies, as the system should be ‘stress tested’ and confirmed for acceptable operations and continuing performance in the actual operating environment (25,26) (Figure 7).

In addition, although we have broken out the UAT/IQ from the OQ/PQ, this may be easily combined into one comprehensive set of testing if the UAT/IQ takes place in the actual operations environment. This is usually pos-sible if the system is going into a ‘green field’ environ-ment where it is not replacing another system. However, if the system is replacing another, most likely the UAT/IQ

will take place in a pilot environment—either to reduce risk or keep the old system running until there is suffi-cient confidence in the new system to shut down the old system. In either case, we must be vigilant about ensur-ing the adequacy of final testing, as there is a tendency to rush through after the UAT phase. Although everyone is anxious to get the new system into production, many UATs are not comprehensive enough to fulfill both func-tional and operational testing needs. Therefore, precau-tion should be taken about arbitrarily combining the UAT and the OQ/PQ into one testing phase. When in doubt, keep the phases distinct to avoid confusion and unnecessary risk in the process.

Conclusion

LIMS is a critical component of successful commercial laboratory in quality control, process control, and R&D environment. A full function LIMS has low ownership cost than a quality management module of an ERP.LIMS enables lab throughput to be increased and improve data accuracy. This helps the lab to gain productivity because the technician can concentrate on sample processing. Customer satisfaction is also improved because custom-ers are sent real time results. The ideal LIMS should be managed by the lab for the lab and should be configured by lab technician to meet their own needs and those of the customer.

Successful validation of a LIMS is a challenging task, but one that can be met if a sound approach to the problem is used. Traditional process manufactur-ing validation techniques are not enough, and software engineering techniques don’t address all of the concerns of pharmaceutical manufacturers. However, by bringing together the better of the two into a blended approach, a successful strategy can be formulated. When this approach is combined with a sound documentation plan and ongoing change management, the fundamentals will be in place to not only have a soundly verified LIMS, but one that is able to pass the most demanding FDA inspec-tion as well.

Figure 7. Extended V-model for pharmaceutical systems.

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.



Declaration of interest

The authors report no declarations of interest.

References 1. Boeijen FPM. The total qualified laboratory. Scientific computing

and instrumentation online. 1999. Available online at: www.scamag.com

2. Mcdowall RD. A matrix for the development of a strategic laboratory information management system. Anal Chem 1993;69:896A–901A.

3. Hunkapiller T, Hood L. LIMS and the Human Genome Project. Bio/Technol 1991;9:1344–1345.

4. Mahaffey RR. LIMS applied information technology for the laboratory. New York: Van Nostrand Reinhold; 1990.

5. Avery G, McGee C, Falk S. Implementing LIMS: a “how-to” guide. Anal Chem 2000;57:A-62-A.

6. ASTM LIMS Guide. In 1994 Book of ASTM standards; American Society for Testing and Materials 1994; Vol. 14.01.

7. McDowall RD, Mattes DC. Architecture for a comprehensive laboratory information management system. Anal Chem 1990;62:1069A–1076A.

8. Sullivan F. Strategic Analysis of US Laboratory Information Management Systems markets. Pharmaceutical Technology Europe; 2009. p 31–32.

9. Kalani S, Gupta D. Good laboratory practices: compliance using lims. Pharma Times 2010;42:41–43.

10. Steele TW, Lauiger A, Falco F. The Impact of LIMS design and functionality on Laboratory quality achievements. Presented at European Conference on Quality Revoluation in Clinical Laboratory QRCL; Belgium, 1995.

11. Webber J. A survey of LIMS satisfaction. Scientific Computing and Instrumentation Online. 2000. Available online at: www.scamag.com

12. Miller S. A practical approach to LIMS selection. Scientific Computing and Instrumentation Online. 2001. Available online at: www.scamag.com

13. Verost W. Strategies in Hand-Held LIMS. ScientificComputing and Instrumentation Online. 2001. Available online at: www.scamag.com

14. Bartow G. Custom LIMS help maximize laboratory productivity. Scientific Computing and Instrumentation Online. 1998. Available online at: www.scamag.com

15. Ganjei JK, Bergen AW. LIMS customization for biomedical research. Scientific Computing and Instrumentation Online. 2001. Available online at: www.scamag.com

16. Redman J. The laboratory equipment control interface specifi-cation. Scientific Computing and Instrumentation Online. 1999. Available online at: www.scamag.com

17. Staab TA. Next generation LIMS. Scientific Computing and Instrumentation Online. 1999. Available online at: www.scamag.com

18. McDowall RD. Practical computer validation for pharmaceutical laboratories. J Pharmaceut Biomed Anal 1995;14:13–22.

19. FDA. Guideline on general principles of process validation. Division of manufacturing and product quality (HFD-320). Office of Compliance, Center for Drug Evaluation and Research; 1987.

20. FDA. General principles of software validation; Final guidance for industry and FDA Staff. Center for Devices and Radiological Health; 2002.

21. Grigonis GJ Jr, Subak EJ Jr, Wyrick M. “Validation Key Practices for Computer Systems Used in Regulated Operations,”. Pharma-ceutical Technology, June 1997.

22. Segalstad SH, Synnevåg MJ. A practical guide to validating LIMS, chemometrics and intelligent laboratory systems. LIMS 1994;26: 1–12.

23. GAMP. Good practice guide, validation of laboratory computerized systems. Tampa, FL: International Society for Pharmaceutical Engineering; 2005.

24. Grigonis GJ Jr., Wyrick M. Computer system validation: auditing computer systems for quality. Pharmaceutical Technology; 1994.

25. IEEE Standard 1233–1998. Guide for developing software requirements specifications. Institute of Electronic and Electrical Engineers; 1998.

26. IEEE Standard 829–1998. Software test documentation. Institute of Electronic and Electrical Engineers; 1998.

Clin

ical

Res

earc

h an

d R

egul

ator

y A

ffai

rs D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y T

he U

nive

rsity

of

Man

ches

ter

on 1

0/11

/14

For

pers

onal

use

onl

y.

www.scamag.com

www.scamag.com

www.scamag.com

www.scamag.com

www.scamag.com

www.scamag.com

www.scamag.com

www.scamag.com

www.scamag.com