Professional Documents
Culture Documents
1 INTRODUCTION
Today it seems that everything has automation hiding in it somewhere!The
focus of this chapter on computer validation compliance, however is what
we will term the application-based computer-related system (CRS), as
opposed to computer-controlled process equipment. Examples of a CRS
may include laboratory information management systems (LIMS), supervi-
sory control and data acquisition (SCADA) systems, document control sys-
tems, calibration data management systems, and any other of the myriad
systems that mate a portable software application to commercially available
computer hardware. This is di¡erent, for example, from a modern water-
for-injection still that employs computer software and hardware but is inex-
tricably linked to specialized mechanical process equipment.The validation
testing for such equipment is typically focused on the mechanical perfor-
mance of the equipment, rather than on the performance of the software
itself. Many of the concepts discussed in this chapter (validation plans, speci-
¢cations, etc.), however have analogous counterparts related to equipment
validation, and the goal is the same: veri¢cation that a system consistently
performs its intended function throughout its usable life.
223
2 GAMP GUIDE
The most prominent and widely recognized guide to CRS validation prac-
tices is the Good Automated Manufacturing Practices (GAMP) guide [1].
While the concepts surrounding software testing and quality assurance have
been discussed for years (in fact, a seminal book in the ¢eld was published
in 1979) [2], the GAMP guide is a crucial reference because it is written from
the speci¢c perspective of the regulated pharmaceutical industry. The
GAMP guide was ¢rst published in Europe in 1994, and was written by a
small consortium of European professionals in response to European regu-
latory agency concerns. It did not take long for industry professionals world-
wide to appreciate this publication and recognize the industry’s need for it.
The GAMP guide has since become an international collaboration between
pharmaceutical industry validation and compliance professionals. The
guide has gained acceptance worldwide as the pharmaceutical industry
guideline on the validation of software and automated systems. While of
course one size never ¢ts all, the GAMP guide is an indispensable resource
for discussion of validation strategies.While this chapter will not extensively
review information already available in the GAMP guide, the following are
some highlights of what can be found in the GAMP guide:
should develop a vendor audit checklist. The checklist should be your plan
for proceeding through a thorough audit.
Elements should include
General company information
Standard operating procedures (SOPs)
Customer support
Quality management/standards
Software/system development methodology
Testing methods/veri¢cation and validation
Technical personnel
Change control, con¢guration, and distribution management
Security features
Documentation
21 CFR Part 11 compliance assessment
report as an integral part of the validation plan, test protocols, and Part 11
remediation and assessment plan.
4.3 Training
Ensure training requirements are addressed within the VMP. De¢ne the
training that must be performed and documented before the system can be
put o⁄cially into use. Determine how training will be documented. Refer to
organizationwide training policies that are applicable. Be sure to require
veri¢cation that CRS user security administration (if any) accurately re£ects
the training documentation. For example, untrained users may have been
allowed access to the CRS for testing purposes. These users must be inacti-
vated before the system is initiated into GMP uses.
VMP for its successful execution. Reference the location of each deliverable
and provide the detail necessary for retrieval at a later date (e.g., SOP and
protocol numbers). Identify any conditions surrounding the use of the sys-
tem. Were some features of the system found to be unsatisfactory for use?
Clearly state what aspects of the CRS are not approved for use until they are
re-engineered and tested and what formal controls are in place to enforce
this (SOPs, security programming, etc.). Design the VMP so that approval
of the MVS document is the end point that releases the CRS for GMP use
by appropriately trained users. This end point is called system acceptance
and signals the transition to the validation maintenance phase of the system
life cycle.
5 SYSTEM SPECIFICATIONS
System speci¢cations are essential to the CRS validation process. This does
not mean, however, that the process of creating speci¢cations need be an
onerous one. In fact, the speci¢cation creation and approval process can be
one of the most valuable aspects of the system life cycle, as it spurs everyone
involved to understand and agree upon what the system is ultimately
expected to do. Regardless of how well-thought-out a system may be in the
preliminary design stages, di¡ering perceptions are always brought to light
once speci¢cations are put in writing.
In contrast to the VMP, system speci¢cations are typically created by
the end user(s) and system engineering organizations. Since the system spe-
ci¢cations will be the basis for much of the validation testing, validation and
quality representatives should be brought into the speci¢cation development
process whenever possible. If these representatives are left out of the speci¢-
cation process, the result will often be speci¢cations that are only intelligible
to the design engineers and principal end users because much of the wording
in the speci¢cations will be based on perceptions that have not been written
into the documents. When validation and quality systems’ representatives
are excluded from developing speci¢cations, extensive revisions are likely
to be needed in order to make it suitable for the validation.
Speci¢cations typically required for a custom-designed application are
known as the URS, functional requirements speci¢cation (FRS), and the
detailed design speci¢cation (DDS). A description of each speci¢cation and
its function follows.
User requirements speci¢cationThe URS is an overview of the system
functionally from the perspective of the end users’ needs. This docu-
ment is often the ¢rst document generated to kick o¡ a new CRS
design and implementation project. It can be drafted early on by a
key individual or group and used to help clarify the business needs to
toplevel management. Once the system concept has the necessary
management support it can be used to introduce the project to a
wider audience and solicit additional user input as to the desired fea-
tures of the system. If an outside ¢rm will do system engineering, the
URS can be used as the de¢ning document for the engineering ser-
vices bid process. If the engineering will be performed internally, the
engineering group can use the URS to project estimated resources
needed to support the system development and implementation pro-
cess. The requirements in the URS will typically be used as the basis
for PQ testing. A typical statement in the URS might be ‘‘The system
must allow simultaneous use of di¡erent system features by multiple
material handlers.’’
Functional requirements speci¢cationThe FRS is a detailed descrip-
tion of required system functionality from the end users’ perspective.
This document should discuss all required functionality by the end
user since it will be used by the engineering team to establish the sys-
tem design. While the URS may be written entirely with end user
input, the FRS is typically a collaborative e¡ort involving both end
user representatives and engineering team representatives.The FRS
must address the users’desired functionality, but must also take into
account what functionality can be feasibly designed into the system
given the constraints of the schedule, budget, and development plat-
form. The requirements in the FRS will typically be used as the basis
for OQ testing. A typical statement in the FRS might be: ‘‘The user
must be required to enter a control code for the raw material lot that
is being dispensed; the system must verify that this control code is
valid and that the lot disposition status allows dispensing of this
material.’’
Detailed design speci¢cationThe DDS is a detailed description of how
the requirements identi¢ed in the FRS will be met from the perspec-
tive of the system design engineer. This document must be descrip-
tive enough to facilitate a consistent programming e¡ort across the
entire (potentially large) team of engineers. This document is typi-
cally drafted by engineers who understand the programming plat-
form that will be used to create the system. While this document
may be very technical, end user review is still necessary to help
ensure that the requirements of the FRS have been properly inter-
preted by the engineering team. Design information contained in the
DDS may include such things as
User interface screens
Database names and ¢eld de¢nitions
6 SPECIFICATION NOMENCLATURE
The speci¢cation names used here are one example, but there are many ways
to refer to the same documents. The URS might instead be called the busi-
ness requirements speci¢cation (BRS).The FRS might be functional speci¢-
cation (FS) or the system requirements speci¢cation (SRS). The DDS might
be a design speci¢cation (DS) or an engineering speci¢cation (ES). The
intended purpose of the speci¢cation must be delineated in the document to
avoid confusion.
7 COMBINING SPECIFICATIONS
What if the project is small and the speci¢cations are not very complex? Can
these documents be combined? Absolutely. On simpler projects, it is not
unusual for the goals of the URS and FRS to be incorporated into one user-
focused document with a separate engineering-focused design document. It
is also not uncommon for the user to generate the high-level URS and submit
it to design engineers familiar with the process for creation of a combined
FRS/DDS document.
8 OFF-THE-SHELF/COTS APPLICATION
What if you are implementing a commercially available application (com-
mercial o¡-the-shelf, or COTS application) rather than designing a custom
application? Do you still need these documents? Yes, but probably not all of
them. The FDA has made it clear [3] that URS are expected, even for COTS
applications.Without a URS, there would be no de¢nition or required system
functionality on which to base initial validation activities. The COTS URS
will typically end up as a blend of the URS and FRS, as described previously.
This blend of requirement types is appropriate for the COTS situation, in
which you are specifying what is necessary for your business operations but
do not need to write speci¢cations su⁄cient to actually design the applica-
tion from scratch. After selection of the application, additional speci¢cation
and OQ have been planned for the system, a second OQ should be prepared
that repeats some portions of the OQ that were performed on the pilot
system.
If the system being implemented is replacing or upgrading an existing
critical system, use of a pilot system for validation testing can pay o¡ with
greatly reduced downtime for the critical system, as less testing needs to be
performed on the critical system before it is put back into GMP use. If the
system being implemented is entirely new, validation testing on a pilot sys-
tem can pay o¡ by shortening the validation schedule as testing and ¢nal
hardware procurement and installation activities are allowed to run in paral-
lel rather than consecutively.
degree. Do not use the lack of a fully compliant solution as the reason for not
implementing any solution. The near-term goal for legacy systems is
improvement, not perfection.
understand that user rights are disabled. Additionally, all system history
related to that former user should be maintained.One might consider if there
are training implications associated with changes. Are all users aware of the
change? Will SOPs need updating? Pay particular attention to changes of
systems used in product manufacture or that generate, analyze, archive, and
report data to be used in submissions to the FDA.
In the ¢rst observation noted here, the ¢rm was clearly cited for not
adhering to its own computer systems SOP. In such cases, it is helpful
to evaluate whether the ¢rm wrote an unnecessarily stringent SOP
and developed a habit of not following it or whether the SOP is rea-
sonable and was ignored. This citation may o¡er some of both. All
computer systems that handle GMP electronic records should have
a written security policy and written security procedures, as made
clear by 21 CFR Part 11, Section 11.10’’Such procedures and con-
trols shall include the following: (d) Limiting system access to
authorized individuals.’’ It is quite possible, however that virus pro-
tection is not necessary on every GMP computer system at the ¢rm,
and that this was an excessive requirement that the ¢rm put on itself
and subsequently did not follow. The ¢rm needs to write a procedure
for security controls on this system and consider whether or not
virus protection is an appropriate SOP requirement for all of the
computer systems in the scope of this policy.
The second observation involves either lack of attention to or misinter-
pretation of the electronic records requirements. The FDA de¢nes
that 21 CFR Part 11 applies to ‘‘records in electronic form that are
created, modi¢ed, maintained, archived, retrieved, or transmitted,
under any records requirements set forth in agency regulations’’
(Section 11.1 b). Since the ¢rm feels the need to print out and retain
these records, the records are presumably ‘‘created under require-
ments set forth in agency regulations,’’ therefore the electronic
records on the computer system are bound by 21 CFR Part 11
whether or not the ¢rm feels the need to retain them. Ignoring the
state of the electronic records and relying on the paper printout is in
violation of at least one other clearly stated requirement of 21 CFR
Part 11, Section 11.10: ‘‘Such procedures and controls shall include
the following: (c) Protection of records to enable their accurate and
ready retrieval throughout the records retention period.’’ This ¢rm
needs to implement a secure backup system for these electronic
records.
FDA warning letter citation: ‘‘Your ¢rm failed to establish and main-
tain procedures . . . in order to ensure that speci¢ed design require-
ments are met. For example, the software designed by your ¢rm was
developed without design controls.’’
This citation talks to a core concept of computer systems validation:
development procedures and system speci¢cations. Note that the ¢rm
was not cited for lack of validation testing of the software but for lack
of design controls. E¡ective design controls would have included writ-
ten design procedures. Adherence to these procedures would have
12 WORDS OF WISDOM
Purpose
To plan and describe the validation activities for the deployment of the very
useful system (VUS) at a particular manufacturing site.
Scope
Describe the scope of the VUS validation e¡ort. What are the boundaries?
Are there interfaces to other systems included in this validation e¡ort? (This
is very important to identify and de¢ne.)
System Description
Provide a clearly worded description of theVUS and its purpose in the orga-
nization. Also describe the makeup of the VUS (multiple servers, networks,
software packages, etc.). This does not need to be technically in depth, but
should provide a basic framework for understanding the system concepts.
Consider including an explanatory diagram.
Responsibilities
List all parties who have responsibilities for actions or deliverables described
in the VUS validation plan. Describe their responsibilities in general terms
(e.g.,‘‘will review and approve all system speci¢cations’’).
Developer Acceptance
If an outside developer is being utilized (whether developing custom soft-
ware or providing a packaged COTS product), describe the steps taken to
qualify the software developer. If an audit was performed, brie£y state the
results and reference the audit report.
Specifications
List theVUS speci¢cations that must be developed in order to properly con-
trol system development and implementation. See Sec. 5 for a discussion of
speci¢cation types.
Training
Describe the training requirements for the VUS. Reference any appropriate
SOPs.
Change Control
Describe or reference the change control system that will be used to main-
tain the validated state of theVUS after the initial quali¢cation.
Validation Methodology
Describe in clear, concise terms the steps that will be taken to qualify the
VUS for use in the manufacturing environment.
System Acceptance
Describe the process by which VUS acceptance for use will be achieved. If
the VUS will be phased in and accepted on a modular basis, describe the
acceptance procedure for each phase.
Traceability Matrix
Here is an example of a traceability matrix as de¢ned by the IEEE. By
de¢nition, a matrix records the relationship between two or more pro-
ducts of the development process; for example, a matrix that records the
relationship between the requirements and the design of a given software
component (Std. 610.12^1990).
As commonly used in CRS validation, a traceability matrix veri¢es the
relationship between system speci¢cations and testing protocols. The goal
of matrixing is to establish the adequacy of protocols. More speci¢cally, all
speci¢ed system characteristics and functionality should correspond to ver-
i¢cation and quali¢cation testing in protocols.
This example uses a small portion of a traceability matrix for valida-
tion of a database application, here named ‘‘your CRS.’’
Installation
specification
section number
(for COTS)
Functional or detailed design Protocols
requirements specification Security
specification section number specification IQ OQ Comments/
section number (for non-COTS) section number section number section number Conclusion
Cite specification Cite specification Cite specifi- Cite protocol Cite protocol Does the protocol
section number(s) section number(s) cation section number section number contain verification
and title or not and title or not section and title. and title. or qualification
applicable (N/Ap). applicable (N/Ap). number(s) Consider Consider testing to provide
and title or not stating test stating test documented
applicable (N/ objective. objective. evidence that
Ap). The objective of The objective each specified
May be this column of this column system feature
multiple is to verify that is to verify that will be adequately
specific the ‘‘specific the specific tested?
citations. system feature’’ system
(such as system requirement
hardware) will be (report printing)
verified as will be verified
installed per the as functional
installation per the functional
specification or requirements
design
247
specification
BIBLIOGRAPHY
Food and Drug Administration. Guidance for Industry. 21 CFR Part 11. Electronic
Records; Electronic Signatures.Glossary of TermsDraft Guidance.Washington,
D. C., Aug. 2001. (Later withdrawn by the FDA.)
Myres, G. J., The Art of Software Testing, New York: Wiley, 1979
ICH. Harmonized tripartite guideline. Good Manufacturing Practice Guide for Active
Pharmaceutical Ingredients. ICH Steering Committee. Nov. 10, 2000.
IEEE. Standard Glossary of Software Engineering Terminology. IEEE Std 610.12-1990.
IEEE, Sep. 28, 1990.
ISPE/GAMP Consortium. GAMP 4 Guide, Validation of Automated Systems.
Tampa, FL: ISPE, 2001.
Validation of computer-related systems technical report no. 18. PDA Committee on
Validation of Computer-Related Systems. PDA J Pharm Sci Tech 49 (1; supple-
ment): Jan.^ Feb. 1995.
INTERNET REFERENCES
Freedom of Information Act warning letters are available on the FDA Website
(currently linked at http://www.fda.gov/foi/warning.htm).
Informative FDA documents and communications related to 21 CFR Part 11
compliance are posted to public dockets on the FDA Website (currently linked at
http://www.fda.gov/ohrms/dockets/dockets/dockets.htm). The relevant dockets are
00D-1538 through 00D-1543.
REFERENCES
1. ISPE/GAMP Consortium. GAMP 4 guide. Validation of automated systems.
Tampa, FL: ISPE, 2001.
2. G. J. Myers. The Art of SoftwareTesting. New York: Wiley, 1979.
3. Food and Drug Administration. Guidance for Industry. 21 CFR, Part 11. Electro-
nic Records; Electronic Signatures validation. draft issues. Sept. 2001. (Later with-
drawn by the FDA.)