You are on page 1of 9

A Validation Approach for

Laboratory Information
Management Systems
By Douglas S. Tracy
Pfizer Pharmaceutical Group Global Business Technology
and
Robert A. Nash, Ph.D.
New Jersey Institute of Technology

aboratory Information Man- types of systems. Although many gen-

L agement Systems (LIMS) are


an increasingly important
component of any modern laborato-
❝…this

a
paper
is to discuss
potential
eral principles are shared with Good
Manufacturing Practice (GMP) and
process validation standards, the
ry. As these systems become the nature of software also demands a
main source of records for the lab’s approach to slightly different approach. Addition-
work, especially the quality manage- validation for al requirements are necessary to en-
sure adequate validation – require-
ment aspects of work, they will be a
natural target for Food and Drug Ad- LIMS . Any ments that non-Information Technol-
ministration (FDA) inspections. In effective ogy (IT) specialists may not be famil-
addition, by relying more and more iar with. Compounding this problem
on these systems instead of paper- validation is that many IT specialists are not
based records, a firm is becoming exercise begins familiar with the demanding require-
critically dependent upon their suc- ments of the pharmaceutical/biotech-
cessful and reliable operation. Any
with thorough nology industries. Therefore, a fresh
failure in these systems could cause a planning, based look at validation for LIMS, blending
heavy increase in workload in the upon a sound the best of both traditional FDA-reg-
ulated industry validation procedures
best case, and a catastrophic event for
the lab in the worst case. Thus, it is approach. ❞ and software engineering validation
vitally important that a sound ap- procedures, is worthwhile for organi-
proach to validation be taken to ensure that adequate zations, which have or are considering, installation of
preparation for any potential inspection has taken place, these systems.
and that these systems will be reliable enough for con-
tinued operations in the laboratory. What is a Laboratory Information
The purpose of this paper is to discuss a potential Management System?
approach to validation for LIMS. Any effective valida-
tion exercise begins with thorough planning, based Before beginning to delve into the specifics of val-
upon a sound approach. However, for pharmaceutical idation, a brief review of LIMS is useful. Only by
professionals, this is easier said than done for these understanding the scope of the components in these

6 Journal of Validation Technology


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

systems is it possible to create effective validation Figure 1


plans. In addition, since a LIMS itself is often a com-
ponent of a much larger information system, valida- LabSys LIMS Summary Functions
tion needs may very well extend beyond the LIMS
LIMS for
into other systems and processes. Thus, what a LIMS Quality Control
is, and how it may fit into the larger information sys- Set-up and Allows the system to be configured to
tems landscape is very important when determining Configuration site-specific requirements
the complete set of validation exercises required. Sample Sample lifecycle, including all the
Management standard functionality normally
Purpose and Functionality associated with a standalone LIMS
system. It supports many addition-
The basic purpose of a LIMS is to assist industry al QA functions
personnel with managing large volumes of information
Vendor Monitoring Controls different sampling plans,
inside a typical laboratory. These systems first appear- and skips lot testing parameters
ed in the early 1980s, and were first used to automate per vendor/product relationship. It
the collection and reporting on stability data.1 Along tracks vendor performance and
provides vendor performance
with stability testing, LIMS are also used for process reports
control and document management, providing a flexi-
ERP Integration Allows data to be interchanged
ble and easily accessible platform upon which to devel- between LabSys LIMS and ERP
op and store process steps and documentation. As an systems.
adjunct to this function, LIMS are very useful plat- Document Allows links to documents and
forms for the Quality Control (QC) and Quality Assur- Management Link external document management
ance (QA) functions, as they provide a simple way of systems for tests, samples, prod-
ucts, etc.
sampling data and utilizing quality management tools
Process LIMS
for process monitoring and improvement. Finally, LIMS
are also useful as an integrating mechanism, by being In-Process Controls sample testing during
Sampling the manufacturing stages of a
able to accept inputs directly from many types of lab- batch process.
oratory equipment and coordinating supplies, sched- Batch Tree Full batch traceability with ERP
ules, etc. with Materials Replenishment Planning Traceability interface
(MRP) or Enterprise Resource Planning (ERP) sys- Stability LIMS
tems used for corporate logistics. Stability Trial Allows definitions of time-points,
Template conditions, and testing to be per-
Major Components of a LIMS formed at each stage.
As an example of a specific LIMS, the features of Trial Manage- Used to manage all stability trials,
the LabSys LIMS are in Figure 1 (listed by specific ment and provide reporting on each.
module).2 Stability Automatically schedules samples
In addition to the standard functionality of most Scheduler for testing when the time-point
arrives.
LIMS, there are specialized modules or complete soft-
Instrument Connect
ware packages to meet many other needs. For example,
Simple Collects and passes data from
the Matrix Plus LIMS from Autoscribe contains a Instruments simple instruments, such as bal -
“Quotation Manager” that “allows laboratory and com- ances and meters, and can pro-
mercial personnel to track the progress of a contract for cess this before reporting to LIMS.
laboratory analysis work from initial inquiry to receipt Complex Collects and passes data from
of purchase order and the login of samples into the sys- Instruments complex PC-controlled instruments,
tem.” 3 LIMS also come in a wide variety of shapes and such as High Performance Liquid
Chromatography (HPLC) and Gas
sizes, from simple MS Access-based programs for Chromatography (GC). Can be
smaller labs, to larger-scale, complex relational data- configured to deliver a worklist
base client-server-based systems for larger laboratories. from LIMS to the instrument, and
subsequently upload the results
There is even one company, ThermoLabs, which is from the instrument to LIMS.

November 2002 • Volume 9, Number 1 7


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

offering their LIMS via an Application Service The FDA also defines software validation sepa-
Provider (ASP) model, where the software is hosted by rately in their General Principles of Software Valida-
ThermoLabs. The using company hooks up to the sys- tion guidance document, although in much the same
tem over a secure Internet connection, and fees are col- spirit:
lected by ThermoLabs on a monthly rental basis.4
FDA considers software validation to be “con-
Overall Validation Approach firmation by examination and provision of objec-
tive evidence that software specifications conform
The key to an overall validation approach is tak- to user needs and intended uses, and that the par-
ing a system-level approach to the problem. In other ticular requirements implemented through soft-
words, not to just validate the individual compo- ware can be consistently fulfilled.”6
nents of the process – software, hardware, user pro-
cedures – but to treat these components as part of an Another key definition in the General Principles
overall system that needs system-level validation. of Software Validation document is that of software
Thus, we must remember not to get too lost in the verification:
details, but to focus on the overall outcome for vali-
dation, which is in essence a quality assurance pro- Software verification provides objective evi-
cess. As the FDA states in their Guidance on Gen- dence that the design outputs of a particular phase
eral Principles of Process Validation: of the software development life cycle meet all of
the specified requirements for that phase6
The basic principles of quality assurance have
as their goal the production of articles that are fit In addition, the definitions of Installation Qualifi-
for their intended use. The principles may be stat- cation (IQ), Operational Qualification (OQ), and Per-
ed as follows: formance Qualification (PQ) are well known to most
1. quality, safety, and effectiveness must be pharmaceutical manufacturing personnel, but bear re-
designed and built into the product; peating here as specified by the FDA:
2. quality cannot be inspected or tested into the
finished product; and Qualification, installation – Establishing con-
3. each step of the manufacturing process must fidence that process equipment and ancillary sys-
be controlled to maximize the probability that tems are compliant with appropriate codes and
the finished product meets all quality and de- approved design intentions, and that manufactur-
sign specifications5 er’s recommendations are suitably considered.
Qualification, operational – Establishing con-
Basics of Validation – Other Key Definitions and fidence that process equipment and ancillary sys-
Scope tems are capable of consistently operating with
We should also keep in mind a few key definitions, established limits and tolerances.
as these will be vitally important to outlining a specif- Qualification, process performance – Estab-
ic plan for our LIMS validation. First of all, we need lishing confidence that the process is effective and
to review the basic definition of validation according reproducible.
to the FDA, both in the context of process and soft- Qualification, product performance – Estab-
ware. In the FDA Guidance on General Principles of lishing confidence through appropriate testing that
Process Validation, they defines process validation as: the finished product produced by a specified pro-
cess meets all release requirements for functional-
Process validation is establishing documented ity and safety.7
evidence which provides a high degree of assur-
ance that a specific process will consistently pro- Finally, we should keep in mind that validation
duce a product meeting its pre-determined speci- could become an onerous task if not approached in a
fications and quality characteristics. 5 reasonable manner. One major consulting firm, Ac-

8 Journal of Validation Technology


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

centure LLP, estimates that pharmaceutical firms tailored to an individual company’s situation in or-
often spend twice as much time and cost to complete der to be “implementable.”
validated systems projects – often because of addi-
tional requirements imposed by company Standard System Validation
Operating Procedures (SOPs), and QA personnel
that are not mandated in regulations.8 After all, the As stated before, the goal of the validation exercise
FDAin its General Principles of Software Validation is to have a complete validated system. It is useless to
refers to using the least burdensome approach to validate part of the system, or the hardware and soft-
meeting the regulatory requirement.6 Thus, while we ware separately, and then to assume that they will work
should take a very serious and deliberate approach to together in the end. The validation approach must be
validation, we should focus on assurance of a repeat- holistic, certifying the system as a complete unit –
able and high quality outcome, and not on trying to exactly as it is intended to be used operationally.
“boil the ocean” with unnecessary extensive testing In this regard, there are several major phases in a
and/or overly detailed documentation. typical system validation. One is due to the fact that we
are almost always buying an off-the-shelf software
Validation Master Plans product, e.g. the basic LIMS package. Thus, since we
With these considerations in mind, the key docu- are not building this ourselves, this aspect of validation
ment to produce before starting is a Validation Master must focus on the vendor in an attempt to reasonably
Plan (VMP). In this document, we need to outline the satisfy ourselves that they have a sound software devel-
major steps we are taking to validate this particular sys- opment process in place. Another phase is the valida-
tem. While we should make use of available company tion of those parts of the system that are either custom-
SOPs and templates, this document should be specific built, or configured for our specific implementation of
to the problem at hand. It should take a risk-based the system. In many cases, the functionality or integra-
approach to ensure that efforts are being focused on the tion capability of the package may be too generic for
most likely trouble spots, while limiting the overall val- our specific purposes – thus we need to have either the
idation effort to one of reasonable size and scope. system vendor or another systems integration firm do
Although this is similar to what the FDA defines as a some custom software development work to build the
“validation protocol,” this document is at a somewhat complete system we need. In addition, in almost all sit-
higher level. Detailed test results and “pass/fail” criteria uations, a LIMS requires some degree of configuration,
are not specified, rather the focus is on the guiding prin- ranging from designing in specific workflows, to creat-
ciples and scope of the validation effort, as well as a ing templates for standard lab data sheets or QA
high-level overview of the tasks, costs, and resources reports. In either the custom-built or configured situa-
required for validation. Other supporting documents are tion, validation is required for all of these activities.
used to provide detailed information on test results for Finally, we need to ensure that what we have created
specific validation tasks. Nonetheless, this document is will work properly in our environment – thus a final
extremely important, for it will provide the baseline for validation step to ensure the system works in our envi-
all other validation tasks, and will likely be the first doc- ronment is warranted. In summary, we could define our
ument that any inspector would like to review. system validation goals as follows:
While this paper is not attempting to provide a
specific outline for a VMP, it will provide the basis • Did we buy the right product?
upon which to build such a plan. Arguably, the hard- • Did we add the right features to the product we
er part of the plan document is determining an ap- bought?
propriate approach to validation. Once this is done, • Will this customized/configured product function
it is a relatively straightforward exercise to flesh out correctly in our production environment?
the details and blend in company SOPs, etc. Thus,
the remainder of this paper will concentrate on Vendor Validation
developing the strategic approach in a generic fash- Although many vendors tout their products as “21
ion, with the understanding that this will need to be CFR Part 11 compliant” and “fully validated according

November 2002 • Volume 9, Number 1 9


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

to FDA standards,” the phrase “caveat emptor” or only trying to meet a reasonable standard here, so
“buyer beware” should be kept in mind by the organiza- spending an abundance of time on the vendor’s SDLC,
tion. Since these companies are software organizations, or reviewing their testing/validation procedures is usu-
the FDAis not inspecting them, and their claims may or ally not warranted. If there are concerns, the best ap-
may not be true. In addition, the final responsibility for proach is usually to pick another vendor and potential-
validation rests with the pharmaceutical or biotech com- ly avoid a problem. If there are any lingering concerns,
pany—and not with the software product vendor. then schedule in more time to the testing phase of the
According to the FDA, in their Guidance for Industry: validation plan to fully address these issues.
Computerized Systems Used In Clinical Trials:
Approaches to Customized System Validation
For software purchased off-the-shelf, most of Now that we have a vendor we are comfortable
the validation should have been done by the com- working with, we need to consider how we will val-
pany that wrote the software. The sponsor or con- idate the inevitable configuration and/or customiza-
tract research organization should have documen- tion that accompany all LIMS implementations.
tation (either original validation documents or Again, there is a range of approaches available, with
on-site vendor audit documents) of this design some benefits and risks to each approach.
level validation by the vendor, and should have
itself performed functional testing (e.g., by the use GAMP V-Model: Is this really a workable model?
of test data sets) and researched known software The first approach is usually described as using the
limitations, problems, and defect corrections.9 Good Automated Manufacturing Practice (GAMP) V-
Model, as cited by a number of companies seeking to
Thus, the organization has a requirement to con- sell their validation consulting services.10 This model is
duct a reasonable amount of due diligence on the illustrated in Figure 2, and is one that is troubling, to
vendor for assurance of validation on their product. say the least. While the pharmaceutical professional
So what would be a reasonable approach to validat- may feel comforted by the familiar IQ/OQ/PQ phrase-
ing the vendor entail? Basically what is needed is a
two-pronged approach. One is the validation of the Figure 2
product itself, by reviewing the vendor’s documenta-
Good Automated Manufacturing
tion on what specific validation tests they conducted.
This should include a validation master plan, and a Practice V-Model
sampling of test results – including any known product
User Related to Performance
limitations or defects. Since software products are Requirements Qualification
extremely complicated, and typically consist of thou- Specifications (PQ)
sands, if not millions, of lines of code, some defects
should be expected. In fact, one should be suspicious of
any vendor that claims their product is “defect free.” Related to Operational
Functional
This means that they are not sharing all of the informa- Specifications
Qualification
tion with you, or worse yet, they have conducted inad- (OQ)
equate testing to uncover the bulk of the defects. The
other aspect of vendor validation is to look at the ven-
dor’s Software Development Life Cycle (SDLC) Detailed Installation
Related to
Design Qualification
process. For this aspect, there are several reasonable Specifications (IQ)
approaches, ranging from having the company’s inter-
nal IT department conduct a cursory review, to utiliz-
ing a report of an independent auditing group against
an industry standard, such as International Organ- System Build
ization for Standardization (ISO) 9000, TickIT® or
Capability Maturity Model (CMM). Again, we are

10 Journal of Validation Technology


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

ology, the model does not fit together conceptually picted in Figure 3, we see that for each stage of
with a logical approach for software system validation. refinement from the user requirements, there is a
For example, how does the IQ relate to the Detailed verification process.12 What happens in this verifica-
Design Specifications? The answer is that it really does- tion process is that a review of how well the output
n’t in this context. Looking back to our definition of IQ, of a particular stage maps back to the previous stage
we see that this really refers to compliance with appro- takes place. This can take the form of a formal archi-
priate codes, standards, and design intentions. This is tecture/design/code review, or a series of more infor-
exactly what the user requirements document should be mal “structured walkthroughs.” In either case, the
stating. For example, a good user requirements docu- outcome is the same, and we are looking for where
ment states which applicable regulations (21 CFR Part there were potential gaps or poor handoffs between
11, etc.) need to be considered for the solution. In addi- the stages. This is critically important for two rea-
tion, the user requirements in their final state should sons. The first is that these tasks are often done by
reflect the limitations of a particular software package. different people, and/or sub-teams with specific skill
Although a package is normally selected after the first sets, so some miscommunication or misunderstand-
draft of user requirements, we must often adjust some of ing is likely. Secondly, as we understand more and
the requirements to reflect what is available and achiev- more about the solution, it is likely that additional
able with a particular package. If we list out require- clarifying questions will be asked about the overall
ments that cannot be achieved within our cost parame- solution. Some of these questions may prompt a
ters, then we either need to adjust our requirements, or modification to the output of the previous stage.
reflect that this will be a custom addition to the selected Thus, to keep everything in synch, we need to per-
package. But, in any case, we need to have complete form the verification step.
traceability between the user requirements and the final The other difference from the GAMP model is that
solution – thus the need for adjustment. we now have traceability, along similar levels of detail
For this model to be correct, we could possibly sub- for the purposes of designing tests. Specific code mod-
stitute Design Qualification (DQ) for IQ, and move the ules are tested by unit testing (both a verification and
IQ across from the user requirements, but it doesn’t
solve our problem completely, because we still don’t Figure 3
have an equivalent for OQ and PQ. In addition, we
need to think about the need for intermediate testing. In Software Engineering V-Model
fact, the FDAstates that “typically, testing alone cannot
fully verify that software is complete and correct. In
User Related to User
addition to testing, other verification techniques and a Requirements Acceptance
structured and documented development process Specifications Testing
should be combined to ensure a comprehensive valida-
Verification
tion approach.”6 As another reference, the Institute of
Electrical and Electronics Engineers (IEEE), one of the High-Level Related to System
key standards settings bodies for software engineering, Design and
Testing
refers to Validation and Verification as complementary Architecture
concepts.11 Thus, this model is not only flawed with Verification
respect to terminology, it is fundamentally incomplete.
Detailed Related to Integration
Design
The Software Engineering V-Model: What about Testing
Specifications
IQ/OQ/PQ?
With the limitations of the previous GAMP V- Verification
model in mind, we can take a look at a standard soft-
ware engineering approach to the V-model. Here we Unit
Coding
see a much more comprehensive approach taken to Unit Testing
verification as a prerequisite to validation. As de-

November 2002 • Volume 9, Number 1 11


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

validation step), the detailed design is tested by in- A Combined V-Model for Pharmaceutical Systems
tegration testing among code modules, and the overall While the two previous models both had their
system design and user requirements are tested by shortcomings, if we take both of them together, all
both system testing and user acceptance testing (the of the requirements of a comprehensive validation
difference being that system testing is conducted by approach are covered. Both the detailed validation
software developers, and is typically more compre- of software development activities (configuration
hensive. User acceptance testing is performed by end and/or customization), and the overall process
users, and is typically somewhat more cursory). The aspects are tested and confirmed. Thus, we have a
danger with this approach, or perhaps the question it model (as depicted in Figure 4) that combines the
raises, is just how far to go with testing. The best way GAMP V-model and the software engineering V-
to gauge this is to take a risk analysis approach. Thus, model into one logical flow. The starting point is the
by looking at the risk inherent in failures of various user requirements, as with the Software Engineer-
parts of the system, we can test to a reasonable level, ing (SE) approach, and the flow continues along the
and avoid spending too much time on testing the SE approach until the User Acceptance Testing
detail.13 (UAT) as before. However, there is one important
However, even though this model is much more point of exception. That is, the UAT and the IQ can
comprehensive than the GAMP model, it still lacks be done at the same time, since they are fulfilling
some final testing and validation. Remember, the similar goals, but for slightly different audiences.
overall goal is to have a system that supports a partic- The UAT is the opportunity for the end users to con-
ular process in a verifiable and reproducible manner. firm that the system fulfills the system expectations,
In this model, although the system is tested and ac- including compliance with appropriate regulations.
cepted by the user, there is no specific equivalent to the The IQ is the opportunity for the technical support
OQ and PQ concepts as discussed before. Thus, we staff to confirm that the system (both hardware and
need another level of validation to complete our vali- software), can be installed in an operational envi-
dation approach. ronment in a manner that is both repeatable and ver-

Figure 4
Extended V-Model for Pharmaceutical System

User Related to User


Operational Performance
Requirements Acceptance
Qualification Qualification
Specifications Testing/IQ
Verification

High-Level Related to System


Design and
Testing
Architecture
Verification

Detailed Related to Integration


Design
Testing
Specifications

Verification

Unit
Coding
Unit Testing

12 Journal of Validation Technology


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

ifiable via testing. A successful conclusion to both Presentation of Validation Information


the UAT and IQ is a system that is functionally and One of the goals of validation is to be able to de-
operationally qualified to place in the operations monstrate quickly to an outsider (management, inter-
environment. From this point on, a more traditional nal auditors, FDA, etc.) that the process/system is in-
OQ and PQ approach applies, as the system should deed validated. Thus, early on in the process, part of
be “stress tested” and confirmed for acceptable op- the validation approach should be a consideration of
erations and continuing performance in the actual what the required documents are, and how they should
operating environment. In addition, although we be organized and stored. This will allow a top-down
have broken out the UAT/IQ from the OQ/PQ, this approach to documentation, and make it much easier
may be easily combined into one comprehensive set to track through the validation process. In addition,
of testing if the UAT/IQ takes place in the actual there may be some overall validation efficiencies
operations environment. This is usually possible if gained from following such an approach. As noted by
the system is going into a “greenfield” environment the consulting firm, Accenture, documentation is one
where it is not replacing another system. However, if of the key reasons for additional cost with a validated
the system is replacing another, most likely the system.8 By focusing early on the documentation strat-
UAT/IQ will take place in a pilot environment – egy, including defining the hierarchy of documents
either to reduce risk or keep the old system running and constructing templates to guide the work, we can
until there is sufficient confidence in the new system avoid some of the cost of excessive documentation,
to shut down the old system. In either case, we must while ensuring that we have adequate documentation.
be vigilant about ensuring the adequacy of final test- Finally, we should make sure to implement a good
ing, as there is a tendency to rush through after the version control process on our documentation. Most
UAT phase. Although everyone is anxious to get the pharmaceutical firms have some type of document
new system into production, many UATs are not management system/process already in hand for this
comprehensive enough to fulfill both functional and purpose, and it should clearly be used to store ver-
operational testing needs. Therefore, we should be sioned copies of the system validation documentation.
very cautious about arbitrarily combining the UAT
and the OQ/PQ into one testing phase. When in Change Management – The Need for Ongoing Vali-
doubt, keep the phases distinct to avoid confusion dation
and unnecessary risk in the process. Once we have a validated system in place, the
work is not over for our validation approach. We
Preparing for Inspections must ensure that there is an effective change man-
and Ongoing Validation agement process in place both to determine the po-
tential benefits/costs/effects of changes, and to en-
While having the basic validation process well in sure that we test appropriately. From a validation per-
hand is a must, there are a couple of other issues spective, there are really three things to keep in
concerning validation that are almost as crucial. One mind. First of all, we must test the actual changed
is the documentation of the approach, plan, and code itself, which is pretty obvious and straightfor-
results of validation in a form that is not only logi- ward. In addition, we must conduct what is referred
cal, but can easily be presented to any potential to as “regression testing” to test system functionali-
inspector – internal or external. The other is the need ty that was not directly changed, but may have been
for ongoing validation of changes to the software or inadvertently changed as a result of another change.
process. Simply validating the process one time is In this area, obviously a great deal of judgment must
never enough. There will always be improvements be employed to avoid both over-testing, by redoing
to the process, bug fixes to the software, new releas- all of the tests, and under-testing, by making too
es of the software, etc. that will require ongoing val- many assumptions about what the change will or
idation for the overall process to remain “qualified.” will not affect. One approach to this is to conduct
Thus, a few additional words on these topics are in both testing of areas that may be likely to experience
order. a side effect of the change, and a limited sample of

November 2002 • Volume 9, Number 1 13


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

the other tests to confirm that the assumptions were 3. Autoscribe, Ltd. Plus Points newsletter #2. http://www.auto-
scribe.co.uk.
appropriate. A good reference when developing a 4. ThermoLabSystems, Inc. Pathfinder Global Services Group
change management plan is to review IEEE Std Overview.http://www.thermolabsystems.com/services/pathfin
der/nautilus-asp, May, 2002.
1042-1987, IEEE Guide for Software Configuration 5. FDA. Guideline on General Principles of Process Validation.
Management as a baseline for the change.14 Division of Manufacturing and Product Quality (HFD-320), Office
of Compliance, Center for Drug Evaluation and Research.
May, 1987.
Conclusion 6. FDA. General Principles of Software Validation; Final Guidance
for Industry and FDA Staff. Center for Devices and Radiological
Health. January 11, 2002.
Successful validation of a LIMS is a challenging 7. FDA. Glossary of Computerized System And Software Develop-
ment Terminology. F D AO ffice of Regulatory Affairs Inspector’s
task, but one that can be met if a sound approach to Reference. 1994.
the problem is used. Traditional process manufactur- 8. Accenture LLP. Computer Systems Validation: Status, Trends,
ing validation techniques are not enough, and soft- and Potential. Accenture LLP. White Papers. 2001.
9. FDA. Guidance for Industry: Computerized Systems Used In
ware engineering techniques don’t address all of the Clinical Trials. FDA Office of Regulatory Affairs Inspector.
concerns of pharmaceutical manufacturers. However, April, 1999.
10. Invensys, Inc. Overview of Validation Consulting Services.
by bringing together the best of the two into a blend- http://www.invensys.com. May, 2002.
ed approach, a successful strategy can be formulated. 11. Institute of Electrical and Electronics Engineers. IEEE Standard
for Software Verification and Validation, IEEE Std 1012-1998.
When this approach is combined with a sound docu- IEEE Software Engineering Standards. Vol. 2. New York: 1998
mentation plan and ongoing change management, the 12. Forsberg, K., Mooz, H., and Cotterman, H. Visualizing Project
Management – 2nd Edition. John Wiley & Sons, Inc. New York.
fundamentals will be in place to not only have a 2000.
soundly verified LIMS, but one that is able to pass the 13. Walsh, B. and Johnson, G. “Validation: Never an Endpoint: A
Systems Development Life Cycle Approach to Good Clinical
most demanding FDA inspection as well. ❏ Practice.” Drug Information Journal. 2001, Vol. 35. Pp. 809-817.
14. Institute of Electrical and Electronics Engineers. IEEE Guide
to Software Configuration Management, IEEE Std 1042-1987.
IEEE Software Engineering Standards, Vol. 2. New York:
About the Author 1998.
Douglas S. Tracy is the Director, Global Business Tech-
nology for the Pfizer Pharmaceutical Group (PPG). His Article Acronym Listing
current responsibilities focus on systems and informa- ASP: Application Service Provider
tion processes within the safety and regulatory affairs CMM: Capability Maturity Model
area of PPG. He has over 20 years of operational and DQ: Design Qualification
information technology management in both the public ERP: Enterprise Resource Planning
and private sectors. Doug holds a BSEE with honors FDA: Food and Drug Administration
from the U.S. Naval Academy, an MBA with honors from GAMP: Good Automated Manufacturing Practice
Duke University, and an MS in Software Development GMP: Good Manufacturing Practice
and Management from the Rochester Institute of Tech- IEEE: Institute of Electrical and Electronics
nology. He can be reached by phone at 212-733-5947, Engineers
or e-mail at Douglas.tracy@pfizer.com. ISO: International Organization for
Standardization
Robert A. Nash, Ph.D., is Associate Professor of Indus- IQ: Installation Qualification
trial Pharmacy at the New Jersey Institute of Tech- IT: Information Technology
nology. He has over 24 years in the pharmaceutical in-
LIMS: Laboratory Information Management
Systems
dustry with Merck, Lederle Laboratories, and The Pur-
MRP: Materials Replenishment Planning
due Frederick Company. Dr. Nash is co-editor of
OQ: Operational Qualification
Pharmaceutical Process Validation, published by Mar- PQ: Performance Qualification
cel Dekker and Co. He can be reached by phone at QA: Quality Assurance
201-818-0711, or by fax at 201-236-1504. QC: Quality Control
SDLC: Software Development Life Cycle
References SE: Software Engineering
1. Brush, M. “LIMS Unlimited.” The Scientist. 2001, Vol. 15, SOP: Standard Operating Procedure
No. 11. Pp. 22-29. UAT: User Acceptance Testing
2. LabSys Ltd. System Appreciation Guide 2.1: LabSys LIMS.
http://www.labsys.ie. March, 2002. VMP: Validation Master Plan

14 Journal of Validation Technology

You might also like