A Validation Approach for LIMS

Journal of Validation Technology

Laboratory Information Man-agement Systems (LIMS) arean increasingly important

component of any modern laborato-r y. As these systems become themain source of records for the lab’swork, especially the quality manage-ment aspects of work, they will be anatural target for Food and Drug A d-ministration (FDA) inspections. I naddition, by relying more and moreon these systems instead of paper-based records, a firm is becomingcritically dependent upon their suc-cessful and reliable operation. A n yfailure in these systems could cause aheavy increase in workload in thebest case, and a catastrophic event forthe lab in the worst case. Thus, it isvitally important that a sound ap-proach to validation be taken to ensure that adequatepreparation for any potential inspection has taken place,and that these systems will be reliable enough for con-tinued operations in the laboratory.

The purpose of this paper is to discuss a potentialapproach to validation for LIMS. Any effective valida-tion exercise begins with thorough planning, basedupon a sound approach. However, for pharmaceuticalprofessionals, this is easier said than done for these

types of systems. Although many gen-eral principles are shared with GoodManufacturing Practice (GMP) andprocess validation standards, thenature of software also demands aslightly different approach. A d d i t i o n-al requirements are necessary to en-sure adequate validation – require-ments that non-Information Te c h n o l-ogy (IT) specialists may not be famil-iar with. Compounding this problemis that many IT specialists are notfamiliar with the demanding r e q u i r e-ments of the pharmaceutical/biotech-nology industries. T h e r efore, a freshlook at validation for LIMS, blendingthe best of both traditional FDA-reg-ulated industry validation proceduresand software engineering validationprocedures, is worthwhile for org a n i-

zations, which have or are considering, installation ofthese systems.

What is a Laboratory InformationManagement System?

Before beginning to delve into the specifics of val-idation, a brief review of LIMS is useful. Only byunderstanding the scope of the components in these

6

❝…this paper is to discuss a potential

approach to validation for

LIMS . Any effective

validation exercise beginswith thorough

planning, basedupon a sound

approach. ❞

A Validation Approach forLaboratory Information

Management SystemsBy Douglas S. Tracy

Pfizer Pharmaceutical Group Global Business Technologyand

Robert A. Nash, Ph.D.New Jersey Institute of Technology

❖

November 2002 • Volume 9, Number 1

Douglas S.Tracy & Robert A. Nash, Ph.D.

systems is it possible to create effective validationplans. In addition, since a LIMS itself is often a com-ponent of a much larger information system, valida-tion needs may very well extend beyond the LIMSinto other systems and processes. Thus, what a LIMSis, and how it may fit into the larger information sys-tems landscape is very important when determiningthe complete set of validation exercises required.

Purpose and FunctionalityThe basic purpose of a LIMS is to assist industry

personnel with managing large volumes of informationinside a typical laboratory. These systems first appear-ed in the early 1980s, and were first used to automatethe collection and reporting on stability data.1 A l o n gwith stability testing, LIMS are also used for processcontrol and document management, providing a flexi-ble and easily accessible platform upon which to devel-op and store process steps and documentation. As anadjunct to this function, LIMS are very useful plat-forms for the Quality Control (QC) and Quality A s s u r-ance (QA) functions, as they provide a simple way ofsampling data and utilizing quality management toolsfor process monitoring and improvement. Finally, LIMSare also useful as an integrating mechanism, by beingable to accept inputs directly from many types of lab-oratory equipment and coordinating supplies, sched-ules, etc. with Materials Replenishment Planning(MRP) or Enterprise Resource Planning (ERP) sys-tems used for corporate logistics.

Major Components of a LIMSAs an example of a specific LIMS, the features of

the LabSys LIMS are in Figure 1 (listed by specificmodule).2

In addition to the standard functionality of mostLIMS, there are specialized modules or complete soft-ware packages to meet many other needs. For example,the Matrix Plus LIMS from Autoscribe contains a“Quotation Manager” that “allows laboratory and com-mercial personnel to track the progress of a contract forlaboratory analysis work from initial inquiry to receiptof purchase order and the login of samples into the sys-t e m .”3 LIMS also come in a wide variety of shapes andsizes, from simple MS Access-based programs forsmaller labs, to larg e r-scale, complex relational data-base client-server-based systems for l a rger laboratories.There is even one company, T h e r m o L a b s , which is

7

Figure 1

LabSys LIMS Summary Functions

LIMS for Quality ControlSet-up and A l l ows the system to be configured toConfiguration site-specific requirements

Sample Sample lifecycle, including all theManagement standard functionality normally

associated with a standalone LIMSsystem. It supports many addition-al QA functions

Vendor Monitori n g Controls different sampling plans,and skips lot testing parametersper vendor/product relationship. Ittracks vendor performance andprovides vendor performancereports

ERP Integration Allows data to be interchangedbetween LabSys LIMS and ERPsystems.

Document Allows links to documents and Management Link external document management

systems for tests, samples, prod-ucts, etc.

Process LIMS

In-Process Controls sample testing duringSampling the manufacturing stages of a

batch process.

Batch Tree Full batch traceability with ERPTraceability interface

Stability LIMS

Stability Trial Allows definitions of time-points,Template conditions, and testing to be per-

formed at each stage.

Trial Manage- Used to manage all stability trials,ment and provide reporting on each.

Stability Automatically schedules samplesScheduler for testing when the time-point

arrives.

Instrument Connect

Simple Collects and passes data fromInstruments simple instruments, such as bal -

ances and meters, and can pro-cess this before reporting to LIMS.

Complex Collects and passes data fromInstruments c o m p l ex PC-controlled instru m e n t s,

such as High Performance LiquidChromatography (HPLC) and G a sC h r o m a t o gra p hy (GC). C a n beconfigured to deliver a worklistfrom LIMS to the instrument, andsubsequently upload the resultsfrom the instrument to LIMS.



offering their LIMS via an Application ServiceProvider (ASP) model, where the software is hosted byThermoLabs. The using company hooks up to the sys-tem over a secure Internet connection, and fees are col-lected by ThermoLabs on a monthly rental basis.4

Overall Validation Approach

The key to an overall validation approach is tak-ing a system-level approach to the problem. In otherwords, not to just validate the individual compo-nents of the process – software, hardware, user pro-cedures – but to treat these components as part of anoverall system that needs system-level validation.Thus, we must remember not to get too lost in thedetails, but to focus on the overall outcome for vali-dation, which is in essence a quality assurance pro-cess. As the FDA states in their Guidance on Gen-eral Principles of Process Validation:

The basic principles of quality assurance haveas their goal the production of articles that are fitfor their intended use. The principles may be stat-ed as follows:

1. quality, safety, and effectiveness must bedesigned and built into the product;

2. quality cannot be inspected or tested into thefinished product; and

3. e a ch step of the manufacturing process mustbe controlled to maximize the probability thatthe finished product meets all quality and de-sign specifi c a t i o ns5

Basics of Validation – Other Key Definitions andScope

We should also keep in mind a few key definitions,as these will be vitally important to outlining a specif-ic plan for our LIMS validation. First of all, we needto review the basic definition of validation accordingto the FDA, both in the context of process and soft-ware. In the FDA Guidance on General Principles ofP rocess Va l i d a t i o n, they defines process validation as:

Process validation is establishing documentedevidence which provides a high degree of assur-ance that a specific process will consistently pro-duce a product meeting its pre-determined speci-fications and quality characteristics.5

The FDA also defines software validation sepa-rately in their General Principles of Software Valida-tion guidance document, although in much the samespirit:

F DA considers software validation to be “con-firmation by examination and provision of objec-tive evidence that software specifications conformto user needs and intended uses, and that the par-ticular re q u i rements implemented through soft-w a re can be consistently fulfi l l e d .”6

Another key definition in the General Principlesof Software Validation document is that of softwareverification:

S o f t w a re verification provides objective ev i-dence that the design outputs of a particular phaseof the software development life cycle meet all ofthe specified re q u i rements for that phase6

In addition, the definitions of Installation Qualifi-cation (IQ), Operational Qualification (OQ), and Per-formance Qualification (PQ) are well known to mostpharmaceutical manufacturing personnel, but bear re-peating here as specified by the FDA:

Qualification, installation – Establishing con-fidence that process equipment and ancillary sys-tems are compliant with appropriate codes andapproved design intentions, and that manufactur-er’s recommendations are suitably considered.

Qualification, operational – Establishing con-fidence that process equipment and ancillary sys-tems are capable of consistently operating withestablished limits and tolerances.

Q u a l i fication, process performance – Estab-lishing confidence that the process is effective andre p ro d u c i b l e.

Q u a l i fication, product performance – Estab-lishing confidence through appropriate testing thatthe finished product produced by a specified pro-cess meets all release re q u i rements for functional-ity and safety.7

Finally, we should keep in mind that validationcould become an onerous task if not approached in areasonable manner. One major consulting firm, Ac-

8



centure LLP, estimates that pharmaceutical firmsoften spend twice as much time and cost to completevalidated systems projects – often because of addi-tional requirements imposed by company StandardOperating Procedures (SOPs), and QA personnelthat are not mandated in regulations.8 After all, theFDAin its General Principles of Software Validationrefers to using the least burdensome approach tomeeting the regulatory requirement.6 Thus, while weshould take a very serious and deliberate approach tovalidation, we should focus on assurance of a repeat-able and high quality outcome, and not on trying to“boil the ocean” with unnecessary extensive testingand/or overly detailed documentation.

Validation Master PlansWith these considerations in mind, the key docu-

ment to produce before starting is a Validation MasterPlan (VMP). In this document, we need to outline themajor steps we are taking to validate this particular sys-tem. While we should make use of available companySOPs and templates, this document should be specificto the problem at hand. It should take a risk-basedapproach to ensure that efforts are being focused on themost likely trouble spots, while limiting the overall val-idation effort to one of reasonable size and scope.Although this is similar to what the FDA defines as a“validation protocol,” this document is at a somewhathigher level. Detailed test results and “pass/fail” criteriaare not specified, rather the focus is on the guiding prin-ciples and scope of the validation effort, as well as ahigh-level overview of the tasks, costs, and resourcesrequired for validation. Other supporting documents areused to provide detailed information on test results forspecific validation tasks. Nonetheless, this document isextremely important, for it will provide the baseline forall other validation tasks, and will likely be the first doc-ument that any inspector would like to review.

While this paper is not attempting to provide aspecific outline for a VMP, it will provide the basisupon which to build such a plan. Arguably, the hard-er part of the plan document is determining an ap-propriate approach to validation. Once this is done,it is a relatively straightforward exercise to flesh outthe details and blend in company SOPs, etc. Thus,the remainder of this paper will concentrate ondeveloping the strategic approach in a generic fash-ion, with the understanding that this will need to be

tailored to an individual company’s situation in or-der to be “implementable.”

System Validation

As stated before, the goal of the validation exerciseis to have a complete validated system. It is useless tovalidate part of the system, or the hardware and soft-ware separately, and then to assume that they will worktogether in the end. The validation approach must beholistic, certifying the system as a complete unit –exactly as it is intended to be used operationally.

In this regard, there are several major phases in atypical system validation. One is due to the fact that weare almost always buying an off-the-shelf softwareproduct, e.g. the basic LIMS package. Thus, since weare not building this ourselves, this aspect of validationmust focus on the vendor in an attempt to reasonablysatisfy ourselves that they have a sound software devel-opment process in place. Another phase is the valida-tion of those parts of the system that are either custom-built, or configured for our specific implementation ofthe system. In many cases, the functionality or integra-tion capability of the package may be too generic forour specific purposes – thus we need to have either thesystem vendor or another systems integration firm dosome custom software development work to build thecomplete system we need. In addition, in almost all sit-uations, a LIMS requires some degree of configuration,ranging from designing in specific workflows, to creat-ing templates for standard lab data sheets or QAreports. In either the custom-built or configured situa-tion, validation is required for all of these activities.F i n a l l y, we need to ensure that what we have createdwill work properly in our environment – thus a finalvalidation step to ensure the system works in our envi-ronment is warranted. In summary, we could define oursystem validation goals as follows:

• Did we buy the right product?• Did we add the right features to the product we

bought?• Will this customized/configured product function

correctly in our production environment?

Vendor ValidationAlthough many vendors tout their products as “21

CFR Part 11 compliant” and “fully validated according

9



to FDA standards,” the phrase “caveat emptor” or“buyer beware” should be kept in mind by the org a n i z a-tion. Since these companies are software org a n i z a t i o n s ,the FDAis not inspecting them, and their claims may ormay not be true. In addition, the final responsibility forvalidation rests with the pharmaceutical or biotech com-pany—and not with the software product vendor.According to the FDA, in their Guidance for Industry:Computerized Systems Used In Clinical Tr i a l s:

For software purchased off - t h e - s h e l f, most ofthe validation should have been done by the com-pany that wrote the software. The sponsor or con-t ract re s e a rch organization should have documen-tation (either original validation documents oron-site vendor audit documents) of this designl evel validation by the vendor, and should haveitself performed functional testing (e. g., by the useof test data sets) and re s e a rched known softwarelimitations, problems, and defect corre c t i o n s .9

Thus, the organization has a requirement to con-duct a reasonable amount of due diligence on thevendor for assurance of validation on their product.

So what would be a reasonable approach to validat-ing the vendor entail? Basically what is needed is atwo-pronged approach. One is the validation of theproduct itself, by reviewing the vendor’s documenta-tion on what specific validation tests they conducted.This should include a validation master plan, and asampling of test results – including any known productlimitations or defects. Since software products areextremely complicated, and typically consist of thou-sands, if not millions, of lines of code, some defectsshould be expected. In fact, one should be suspicious ofany vendor that claims their product is “defect free.”This means that they are not sharing all of the informa-tion with you, or worse yet, they have conducted inad-equate testing to uncover the bulk of the defects. T h eother aspect of vendor validation is to look at the ven-d o r’s Software Development Life Cycle (SDLC)process. For this aspect, there are several reasonableapproaches, ranging from having the company’s inter-nal IT department conduct a cursory review, to utiliz-ing a report of an independent auditing group againstan industry standard, such as International Org a n-ization for Standardization (ISO) 9000, Ti c k I T® o rCapability Maturity Model (CMM). Again, we are

only trying to meet a reasonable standard here, sospending an abundance of time on the vendor’s SDLC,or reviewing their testing/validation procedures is usu-ally not warranted. If there are concerns, the best ap-proach is usually to pick another vendor and potential-ly avoid a problem. If there are any lingering concerns,then schedule in more time to the testing phase of thevalidation plan to fully address these issues.

Approaches to Customized System ValidationNow that we have a vendor we are comfortable

working with, we need to consider how we will val-idate the inevitable configuration and/or customiza-tion that accompany all LIMS implementations.Again, there is a range of approaches available, withsome benefits and risks to each approach.

GAMP V-Model: Is 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 tosell their validation consulting services.1 0 This model isillustrated in Fi g u re 2, and is one that is troubling, tosay the least. While the pharmaceutical professionalmay feel comforted by the familiar IQ/OQ/PQ phrase-

10

Figure 2

Good Automated ManufacturingPractice V-Model

UserRequirementsSpecifications

FunctionalSpecifications

OperationalQualification

(OQ)

DetailedDesign

Specifications

System Build

InstallationQualification

(IQ)

PerformanceQualification

(PQ)

Related to

Related to

Related to



o l o g y, the model does not fit together conceptuallywith a logical approach for software system validation.

For example, how does the IQ relate to the DetailedDesign Specifications? The answer is that it really does-n ’t in this context. Looking back to our definition of IQ,we see that this really refers to compliance with appro-priate codes, standards, and design intentions. This isexactly what the user requirements document should bestating. For example, a good user requirements docu-ment states which applicable regulations (21 CFR Part11, etc.) need to be considered for the solution. In addi-tion, the user requirements in their final state shouldreflect the limitations of a particular software package.Although a package is normally selected after the firstdraft of user requirements, we must often adjust some ofthe requirements to reflect what is available and achiev-able with a particular package. If we list out require-ments that cannot be achieved within our cost parame-ters, then we either need to adjust our requirements, orreflect that this will be a custom addition to the selectedpackage. But, in any case, we need to have completetraceability between the user requirements and the finalsolution – thus the need for adjustment.

For this model to be correct, we could possibly sub-stitute Design Qualification (DQ) for IQ, and move theIQ across from the user requirements, but it doesn’tsolve our problem completely, because we still don’thave an equivalent for OQ and PQ. In addition, weneed to think about the need for intermediate testing. Infact, the FDAstates that “typically, testing alone cannotfully verify that software is complete and correct. Inaddition to testing, other verification techniques and astructured and documented development processshould be combined to ensure a comprehensive valida-tion approach.”6 As another reference, the Institute ofElectrical and Electronics Engineers (IEEE), one of thekey standards settings bodies for software engineering,refers to Validation and Verification as complementaryc o n c e p t s .11 Thus, this model is not only flawed withrespect to terminology, it is fundamentally incomplete.

The Software Engineering V-Model: What aboutIQ/OQ/PQ?

With the limitations of the previous GAMP V-model in mind, we can take a look at a standard soft-ware engineering approach to the V-model. Here wesee a much more comprehensive approach taken toverification as a prerequisite to validation. As de-

picted in Figure 3, we see that for each stage ofrefinement from the user requirements, there is averification process.12 What happens in this verifica-tion process is that a review of how well the outputof a particular stage maps back to the previous stagetakes place. This can take the form of a formal archi-tecture/design/code review, or a series of more infor-mal “structured walkthroughs.” In either case, theoutcome is the same, and we are looking for wherethere were potential gaps or poor handoffs betweenthe stages. This is critically important for two rea-sons. The first is that these tasks are often done bydifferent people, and/or sub-teams with specific skillsets, so some miscommunication or misunderstand-ing is likely. Secondly, as we understand more andmore about the solution, it is likely that additionalclarifying questions will be asked about the overallsolution. Some of these questions may prompt amodification to the output of the previous stage.Thus, to keep everything in synch, we need to per-form the verification step.

The other difference from the GAMP model is thatwe now have traceability, along similar levels of detailfor the purposes of designing tests. Specific code mod-ules are tested by unit testing (both a verification and

11

Figure 3

Software Engineering V-Model


High-LevelDesign andArchitecture

DetailedDesign

Specifications

IntegrationTesting

UserAcceptance

Testing

Related to

Verification

Verification

Verification

Unit Testing

Related to

Related to

System Testing

Unit Coding



validation step), the detailed design is tested by in-tegration testing among code modules, and the overallsystem design and user requirements are tested byboth system testing and user acceptance testing (thed i fference being that system testing is conducted bysoftware developers, and is typically more compre-hensive. User acceptance testing is performed by endusers, and is typically somewhat more cursory). T h edanger with this approach, or perhaps the question itraises, is just how far to go with testing. The best wayto gauge this is to take a risk analysis approach. T h u s ,by looking at the risk inherent in failures of variousparts of the system, we can test to a reasonable level,and avoid spending too much time on testing thed e t a i l .1 3

H o w e v e r, even though this model is much morecomprehensive than the GAMP model, it still lackssome final testing and validation. Remember, theoverall goal is to have a system that supports a partic-ular process in a verifiable and reproducible manner.In this model, although the system is tested and ac-cepted by the user, there is no specific equivalent to theOQ and PQ concepts as discussed before. Thus, weneed another level of validation to complete our vali-dation approach.

A Combined V-Model for Pharmaceutical SystemsWhile the two previous models both had their

shortcomings, if we take both of them together, allof the requirements of a comprehensive validationapproach are covered. Both the detailed validationof software development activities (configurationa n d / o r customization), and the overall processaspects are tested and confirmed. Thus, we have amodel (as depicted in Figure 4) that combines theGAMP V-model and the software engineering V-model into one logical flow. The starting point is theuser requirements, as with the Software Engineer-ing (SE) approach, and the flow continues along theSE approach until the User Acceptance Testing(UAT) as before. However, there is one importantpoint of exception. That is, the UAT and the IQ canbe done at the same time, since they are fulfillingsimilar goals, but for slightly different audiences.The UAT is the opportunity for the end users to con-firm that the system fulfills the system expectations,including compliance with appropriate regulations.The IQ is the opportunity for the technical supportstaff to confirm that the system (both hardware andsoftware), can be installed in an operational envi-ronment in a manner that is both repeatable and ver-

12

Figure 4

Extended V-Model for Pharmaceutical System


High-LevelDesign andArchitecture

DetailedDesign

Specifications

IntegrationTesting

UserAcceptanceTesting/IQ

OperationalQualification

PerformanceQualification

Related to

Verification

Verification

Verification

Unit Testing

Related to

Related to

System Testing

Unit Coding



ifiable via testing. A successful conclusion to boththe UAT and IQ is a system that is functionally andoperationally qualified to place in the operationsenvironment. From this point on, a more traditionalOQ and PQ approach applies, as the system shouldbe “stress tested” and confirmed for acceptable op-erations and continuing performance in the actualoperating environment. In addition, although wehave broken out the UAT/IQ from the OQ/PQ, thismay be easily combined into one comprehensive setof testing if the UAT/IQ takes place in the actualoperations environment. This is usually possible ifthe system is going into a “greenfield” environmentwhere it is not replacing another system. However, ifthe system is replacing another, most likely theUAT/IQ will take place in a pilot environment –either to reduce risk or keep the old system runninguntil there is sufficient confidence in the new systemto shut down the old system. In either case, we mustbe vigilant about ensuring the adequacy of final test-ing, as there is a tendency to rush through after theUAT phase. Although everyone is anxious to get thenew system into production, many UATs are notcomprehensive enough to fulfill both functional andoperational testing needs. Therefore, we should bevery cautious about arbitrarily combining the UATand the OQ/PQ into one testing phase. When indoubt, keep the phases distinct to avoid confusionand unnecessary risk in the process.

Preparing for Inspections and Ongoing Validation

While having the basic validation process well inhand is a must, there are a couple of other issuesconcerning validation that are almost as crucial. Oneis the documentation of the approach, plan, andresults of validation in a form that is not only logi-cal, but can easily be presented to any potentialinspector – internal or external. The other is the needfor ongoing validation of changes to the software orprocess. Simply validating the process one time isnever enough. There will always be improvementsto the process, bug fixes to the software, new releas-es of the software, etc. that will require ongoing val-idation for the overall process to remain “qualified.”Thus, a few additional words on these topics are inorder.

Presentation of Validation InformationOne of the goals of validation is to be able to de-

monstrate quickly to an outsider (management, inter-nal auditors, FDA, etc.) that the process/system is in-deed validated. Thus, early on in the process, part ofthe validation approach should be a consideration ofwhat the required documents are, and how they shouldbe organized and stored. This will allow a top-downapproach to documentation, and make it much easierto track through the validation process. In addition,there may be some overall validation eff i c i e n c i e sgained from following such an approach. As noted bythe consulting firm, Accenture, documentation is oneof the key reasons for additional cost with a validateds y s t e m .8 By focusing early on the documentation strat-e g y, including defining the hierarchy of documentsand constructing templates to guide the work, we canavoid some of the cost of excessive documentation,while ensuring that we have adequate documentation.F i n a l l y, we should make sure to implement a goodversion control process on our documentation. Mostpharmaceutical firms have some type of documentmanagement system/process already in hand for thispurpose, and it should clearly be used to store ver-sioned copies of the system validation documentation.

Change Management – The Need for Ongoing Vali-dation

Once we have a validated system in place, thework is not over for our validation approach. Wemust ensure that there is an effective change man-agement process in place both to determine the po-tential benefits/costs/effects of changes, and to en-sure that we test appropriately. From a validation per-spective, there are really three things to keep inmind. First of all, we must test the actual changedcode itself, which is pretty obvious and straightfor-ward. In addition, we must conduct what is referredto as “regression testing” to test system functionali-ty that was not directly changed, but may have beeninadvertently changed as a result of another change.In this area, obviously a great deal of judgment mustbe employed to avoid both over-testing, by redoingall of the tests, and under-testing, by making toomany assumptions about what the change will orwill not affect. One approach to this is to conductboth testing of areas that may be likely to experiencea side effect of the change, and a limited sample of

13



the other tests to confirm that the assumptions wereappropriate. A good reference when developing achange management plan is to review IEEE Std1042-1987, IEEE Guide for Software ConfigurationManagement as a baseline for the change.14

Conclusion

Successful validation of a LIMS is a challengingtask, but one that can be met if a sound approach tothe problem is used. Traditional process manufactur-ing validation techniques are not enough, and soft-ware engineering techniques don’t address all of theconcerns of pharmaceutical manufacturers. However,by bringing together the best of the two into a blend-ed approach, a successful strategy can be formulated.When this approach is combined with a sound docu-mentation plan and ongoing change management, thefundamentals will be in place to not only have asoundly verified LIMS, but one that is able to pass themost demanding FDA inspection as well. ❏

About the AuthorDouglas S. Tracy is the Director, Global Business Te c h-nology for the Pfizer Pharmaceutical Group (PPG). H i scurrent responsibilities focus on systems and info rm a-tion processes within the safety and regulatory affa i r sarea of PPG. He has over 20 years of operational andi n fo rmation technology management in both the publ i cand pri vate sectors. Doug holds a BSEE with honorsfrom the U. S.N aval Academy, an MBA with honors fromD u ke Unive r s i t y, and an MS in Software Deve l o p m e n tand Management from the Rochester Institute of Te c h-n o l o g y. He can be reached by phone at 212-733-5947,or e-mail at Douglas. t ra c y @ p f i ze r. c o m .

R o b e rt A.Nash, Ph.D., is Associate Professor of Indus-t rial Pharmacy at the New Jersey Institute of Te c h-n o l o g y. He has over 24 years in the pharmaceutical in-d u s t ry with Merck, Lederle Labora t o ri e s, and The Pur-due Fr e d e ri ck Company. D r. Nash is co-editor ofP h a rmaceutical Process Va l i d a t i o n, published by Mar-cel Dekker and Co. He can be reached by phone at201-818-0711, or by fax at 201-236-1504.

References1. Brush, M. “LIMS Unlimited.” The Scientist. 2001, Vol. 15,

No. 11. Pp. 22-29.2. LabSys Ltd. System Appreciation Guide 2.1: LabSys LIMS.

http://www.labsys.ie. March, 2002.

3. Autoscribe, Ltd. Plus Points newsletter #2. http://www.auto-scribe.co.uk.

4. ThermoLabSystems, Inc. Pathfinder Global Services GroupO v e r v i e w. h t t p : / / w w w. t h e r m o l a b s y s t e m s . c o m / s e r v i c e s / p a t h f i nder/nautilus-asp, May, 2002.

5 . FDA. Guideline on General Principles of Process Va l i d a t i o n .Division of Manufacturing and Product Quality (HFD-320), Off i c eof Compliance, Center for Drug Evaluation and Research.May, 1 9 8 7 .

6 . FDA. G e n e ral Principles of Software Validation; Final Guidancefor Industry and FDA Staff. Center for Devices and RadiologicalHealth. January 11, 2002.

7 . FDA. Glossary of Computerized System And Software Dev e l o p-ment Te r m i n o l og y. F D AO ffice of Regulatory A ffairs Inspector’sReference. 1994.

8. Accenture LLP. Computer Systems Validation: Status, Trends,and Potential. Accenture LLP. White Papers. 2001.

9. FDA. Guidance for Industry: Computerized Systems Used InClinical Trials. FDA Office of Regulatory Affairs Inspector.April, 1999.

10. Invensys, Inc. Overview of Validation Consulting Services.http://www.invensys.com. May, 2002.

11. Institute of Electrical and Electronics Engineers. IEEE Standardfor Software Ve r i fication and Validation, IEEE Std 1012-1998.IEEE Software Engineering Standard s. Vol. 2. New York: 1998

12. F o r s b e rg, K., Mooz, H., and Cotterman, H. Visualizing Pro j e c tM a n agement – 2nd Edition. John Wiley & Sons, Inc. New Yo r k .2 0 0 0.

13. Walsh, B. and Johnson, G. “Validation: Never an Endpoint: ASystems Development Life Cycle Approach to Good ClinicalPractice.” Drug Information Jo u r n a l. 2001, Vol. 35. Pp. 809-817.

14. Institute of Electrical and Electronics Engineers. IEEE Guideto Software Configuration Management, IEEE Std 1042-1987.IEEE Software Engineering Standards, Vol. 2. New York:1998.

14

ASP: Application Service ProviderCMM: Capability Maturity ModelDQ: Design QualificationERP: Enterprise Resource PlanningFDA: Food and Drug A d m i n i s t r a t i o nGAMP: Good Automated Manufacturing PracticeGMP: Good Manufacturing PracticeIEEE: Institute of Electrical and Electronics

EngineersISO: International Organization for

S t a n d a r d i z a t i o nIQ: Installation Qualification I T: Information Technology LIMS: Laboratory Information Management

Systems MRP: Materials Replenishment Planning OQ: Operational QualificationPQ: Performance Qualification Q A : Quality A s s u r a n c eQ C : Quality ControlS D L C : Software Development Life CycleS E : Software EngineeringS O P : Standard Operating ProcedureUAT: User Acceptance Te s t i n gVMP: Validation Master Plan

Article Acronym Listing

Documents

A Validation Approach for LIMS