2ND

Pharmaceutical Computer Systems Validation: Quality Assurance, Risk Management and Regulatory Compliance
Second EDITION
EDITION S E C O N D E D I T I O N
About the book

Pharmaceutical

Quality Assurance, Risk Management and Regulatory Compliance

Pharmaceutical Computer Systems Validation
Since the last edition, a new paradigm for computer validation has emerged, one that considers the benefits
of Quality Management Systems, science based product and process understanding, and the application of a
risk based approach. This new edition has been thoroughly revised to address new and emerging industry
standards, discuss the latest thinking on computer validation and verification principles, and share real-world
experience on how to put these principles into practice. The most comprehensive guide on computer
compliance currently available, this book could make all the difference in ensuring efficient and effective
compliance of your computer systems. Computer
Systems Validation
Other features of the Second Edition include:
• 18 chapters covering organization responsibilities, project implementation, operation and maintenance of
systems (including decommissioning and archiving), practical troubleshooting, handling regulatory
inspections, metrics, and the opportunity for performance improvement

Quality Assurance, Risk Management

• 18 new and updated case studies by industry experts, which demonstrate how these computer validation
principles are put into practice
• Discussion of latest industry GMP guidelines – includes ISPE GAMP®5 guide, ASTM E2500, and ICH Q7, Q8
and Q9
• A focus on regulatory requirements covering GCPs, GLPs, GMPs, and GDPs – complete with recent and Regulatory Compliance
observations from the FDA
• The latest advancements in electronic records and signatures
This book is essential for all those in the pharmaceutical and healthcare industry who work to develop
and validate/verify computerized systems.

About the editor

Guy Wingate, Ph.D. is Quality Director at GlaxoSmithKline. A well-known speaker on computer validation,
Dr. Wingate has over twenty years of experience in the pharmaceutical industry. He is a visiting lecturer at
University of Manchester’s M.Sc. Pharmaceutical Engineering Advanced Training program and Dublin Institute
of Technology’s accredited M.Sc. Validation Science program. Dr. Wingate is an active member of the ISPE and
is the current Chair of GAMP Council, which is responsible for the internationally recognized suite of GAMP
Guides on computer compliance. Dr. Wingate’s extensive list of published work includes the books Validating
Corporate Computer Systems and the previous edition of Pharmaceutical Computer Systems Validation.

H8894

Wingate

Edited by Guy Wingate

Telephone House, 69-77 Paul Street, London EC2A 4LQ, UK
52 Vanderbilt Avenue, New York, NY 10017, USA
www.informahealthcare.com
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Pharmaceutical Computer
Systems Validation
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Pharmaceutical Computer
Systems Validation
Quality Assurance, Risk Management and
Regulatory Compliance
Second Edition

Edited by

Guy Wingate
GlaxoSmithKline
Barnard Castle, U.K.
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
© 2010 by Taylor & Francis Group, LLC
CRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Version Date: 20130129

International Standard Book Number-13: 978-1-4200-8895-3 (eBook - PDF)

This book contains information obtained from authentic and highly regarded sources. While all reasonable efforts have
been made to publish reliable data and information, neither the author[s] nor the publisher can accept any legal respon-
sibility or liability for any errors or omissions that may be made. The publishers wish to make clear that any views or
opinions expressed in this book by individual editors, authors or contributors are personal to them and do not neces-
sarily reflect the views/opinions of the publishers. The information or guidance contained in this book is intended for
use by medical, scientific or health-care professionals and is provided strictly as a supplement to the medical or other
professional’s own judgement, their knowledge of the patient’s medical history, relevant manufacturer’s instructions and
the appropriate best practice guidelines. Because of the rapid advances in medical science, any information or advice
on dosages, procedures or diagnoses should be independently verified. The reader is strongly urged to consult the drug
companies’ printed instructions, and their websites, before administering any of the drugs recommended in this book.
This book does not indicate whether a particular treatment is appropriate or suitable for a particular individual. Ulti-
mately it is the sole responsibility of the medical professional to make his or her own professional judgements, so as to
advise and treat patients appropriately. The authors and publishers have also attempted to trace the copyright holders of
all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has
not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify
in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or uti-
lized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopy-
ing, microfilming, and recording, or in any information storage or retrieval system, without written permission from the
publishers.

For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://
www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923,
978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For
organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for
identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at
http://www.crcpress.com
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

For Sarah, Katherine, Robert, and Edward

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Validation should be viewed as an integral

part of the overall computer system’s life cycle.
It should promote improved process control
and not bureaucracy. Good practice and
common sense should prevail.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Foreword to the Second Edition

It is pleasing to note that the second edition has been significantly enhanced and updated since
2004. It seeks to anticipate some emerging FDA and EU requirements (1–4). It is aligned with
the latest fifth edition of the GAMP Guide (5), explains the latest thinking from ASTM (6) and
DIA (7), and presents developing industry best practice. Regulatory inspection findings and
FDA Warning Letters have been analyzed; risk-based decisions are now considered in more
detail; case studies have been revisited to take account of regulatory and technological trends;
there are additional case studies on databases and spreadsheets, together with new material on
PAT and process control systems to fit with pending new guidance from ISPE/GAMP.
I am happy to repeat the recommendation that I gave in 2004, in support of this book and
its editor and team of collaborating authors: “Whether you are looking for the missing piece of
the jigsaw puzzle for your project guidance on how to meet the regulations in a practical sense,
(whilst making cost-effective use of your investments), this information resource [which puts
principles into practice] is a good place to start! ”

Anthony J. Trill
Senior Inspector
MHRA (Retired)

REFERENCES
1. Food and Drug Administration. Pharmaceutical CGMPs for the 21st Century: A Risk-Based
Approach. Rockville, MD, 2004.
2. International Conference on Harmonisation. Quality Risk Management, Q9 Document, Technical
Requirements for Registration of Pharmaceuticals for Human Use, 2005. Available at: www.ich.org.
3. Food and Drug Administration. 21 CFR part 211. Supplementary information. Rockville, MD, 2008.
4. European Commission. Draft Annex 11. Computerised Systems (EU guideline to Good Manufactur-
ing Practices for Medicinal Products for Human and Veterinary Use), Public Consultation Document.
Brussels, April 2008.
5. International Society for Pharmaceutical Engineering. GAMP15: Risk-Based Approach to Compliant
GxP Computerised Systems. Tampa, Florida, 2008. Available at: www.ispe.org.
6. American Society for Testing and Materials. E2500-07 standard guide for specification, design and
verification of pharmaceutical and biopharmaceutical manufacturing systems and equipment, 2007.
7. Drug Information Association. Computerized Systems used in Non-Clinical Safety Assessment:
Current Concepts in Validation and Compliance (known as Red Apple II), 2008.

Editor’s Note: Tony Trill has written a personal reflection on his career in the MHRA inspecting
computer systems, which can be found online:
“A regulator’s perspective of his GAMP experience,” Anthony Trill, retired senior
MHRA inspector, online exclusive article, Pharmaceutical Engineering. November/December
2008, Vol. 28 No. 6.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Foreword to the First Edition

Computer technology is all pervasive. It hides behind the smallest button on domestic
appliances and is in smart cards and security devices, mobile phones, cash dispensers, PCs,
integrated networks, process plant, automobiles, “jumbo jets, ” and power plants. Automation
is everywhere and is gathering complexity, innovation, and momentum, and we have to rely
on it more and more in our everyday lives. The inexorable rise of automation is also seen in the
corporate strategies of pharmaceutical manufacturers calling for investment in new technology
to improve business efficiency and competitive edge. When such technology is associated with
high-risk public safety projects or the production and control of life-saving medicines or
devices, we (businesses and regulators) need to know that it is reliable, quality assured, and
validated. Easy to say, but the technology (and the terminology) is difficult to understand, let
alone prove and qualify, if you are not an electronic systems engineer or a latent Einstein.
Pharmaceutical and healthcare companies have historically engineered their businesses
to be profitable while ensuring that quality is built into their medicinal products, or devices,
through the observance of GxPs (viz GCPS, GLPs, GMPs, etc.) which essentially require
computerized systems in the pharmaceutical sector to be fully documented, defined as to
functionality, quality assured, and validated. This book considers the requirements of the
various international regulations, guides, and codes in historical perspective and leads the
reader into business and project life cycle issues and activities. This book is invaluable in
bridging the gap between theory and practice and is supported by case studies from
experienced professional practitioners and engineers who have had to face up to the challenges
of proving the quality, structural integrity, and validation of different systems in the “real
world” (process control, utility management, networked control, information and high level
business IT, and integrated real-time application, etc.). The case studies are organized
hierarchically from low-level instruments and PLCs through integration to higher-level
proprietary electronic document and information management systems, and beyond.
Pharmaceutical and healthcare companies that invest in computerized systems need
systems that are delivered on time and within budget and that fulfill business functional and
performance requirements. In their rush to place new products and versions on the market,
however, computer software and systems suppliers rarely delivered error-free products. In
fact, some two-thirds of life cycle costs can be incurred after delivery of the software and
system to the users. Pharmaceutical and healthcare companies do not want lots of downtime,
disruption, and escalating costs once a system has been delivered and implemented (1,2). And,
of course, in GxP applications, any deficiencies will be of particular interest during regulatory
inspections.
Inspectors and investigators working for the different national regulatory bodies have to
apply their national GxPs and regulations when assessing these systems. While these are
published, they are not necessarily up to date and, as we all would acknowledge, they are
often open to interpretation not only by different inspectors, depending on their background
and training, but also depending on the particular computerized system and application.
Regulators need to be satisfied that computerized systems installed in pharmaceutical
companies are fit for their intended purposes by considering the nature of the application,
specifications, quality assurance of the development life cycle activities, qualification,
performance validation, in-use controls, accuracy, and reliability in the context of relevant
GxPs. The increasing complexity of (integrated) propriety computer systems, critical
applications, project validation issues, and inspection findings have been considered before
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Foreword to the First Edition ix

together with the challenge for all parties (as ever) to apply sensible regulations and cost-
effective good computer validation practices (1,3,4).
The pharmaceutical and healthcare industries (including software and system suppliers
and developers) have also reportedly had some difficulty in ensuring that these projects
actually deliver the proposed business benefits and that the systems, as built, actually meet the
specifications and are reliable and validated and quite apart from determining just how much
and what type of validation evidence is required to satisfy the different regulatory bodies,
particularly the FDA. While the GAMP Guide (5) and, to some extent, the PDA 18 report (6)
provide the latest interpretation of acceptable development and project guidance in this field
(to ensure compliance with the needs of the principle regulatory bodies around the world), and
TickIT provides a guide to software quality system construction and certification (using ISA
9001:1994) (7), there has been a lack of papers on practical experiences from pharmaceutical
sector project teams seeking to implement new technology.
Today, both the industry and regulators have a much better understanding (8) of the ways
and means to develop and validate computerized systems. Regulatory inspections now have
more to do with risk-based assessments of what these systems are being used for in the context of
broader GxP requirements rather than software and system validation per se. Inspectors (9) now
rarely concentrate on “simply” inspecting computerized systems as an entity on sites; they are
more often directly concerned with what the systems are being used for and how they are being
used and controlled. Risk-based findings for noncompliances associated with computerized
systems will often be linked with other chapters of the EU or PIC/S GMP apart from annex 11.
However, where a detailed inspection of a computerized system is indicated (from risk
assessments or other inspections), it can be arranged as a specific exercise.
It is interesting to note the ongoing collaboration between ISPE and PDA (10,11) to
publish guidance on electronic records and management and to influence opinion. It is to be
hoped that the technological implementation of electronic records and signature requirements
worldwide will not be frustrated by a lack of understanding and agreement by all stakeholders
of the real issues. Recognition must be given to the need for regulated users to have robust
information security management practices and a risk-based approach applied to important
relevant records and inspection compliance.
I believe that this book will be welcomed by novices and experts, suppliers, developers,
purchasers, and regulators alike in providing insight into the practical aspects of these complex
automation– and life cycle–related projects. Many staff assigned to validation projects could also
benefit from sharing the experience of other practitioners. Whether you are looking for the missing
piece of the jigsaw for your project or guidance on how to meet the regulations in a practical sense,
this information resource (which puts principles into practice) is a good place to start!

Anthony J. Trill
Senior Inspector
MHRA

REFERENCES
1. Stokes T, Branning RC, Chapman KG, et al. Good Computer Validation Practices Common Sense
Implementation. Buffalo Grove: Interpharm Press, Inc., 1994.
2. Wingate GAS. Computer systems validation: a historical perspective. Pharmaceutical Engineering,
July/August 1995, pp. 8–12.
3. Trill AJ. EU GMP Requirements and the good automated manufacturing practice (GAMP) supplier
guide for the validation of automated systems for pharmaceutical manufacturing. Pharmaceutical
Engineering, May/June 1995, pp. 56–62.
4. Trill AJ. An EU/MCA view of recent industry guides to computer validation, including GAMP 1996,
PDA technical report 18, and the validation toolkit. Proceedings of PIC/S Seminar “Inspection of
Computer Systems,” Sydney, Australia, September 1996.
5. International Society for Pharmaceutical Engineering. Good Automated Manufacturing Practice
Guide for Validation of Automated Systems (known as GAMP14), 2001. Available at: www.ispe.org.
6. Parenteral Drug Association. The Validation of Computer Related Systems, Technical Report No. 18.
J Pharm Sci Technol 1995; 49(1).
7. TickIT Guide. A guide to software quality management system construction and certification using
ISO 9001:2000, issue 5.0. DISC/BSI TickIT Office, London, 2000.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

x Foreword to the First Edition

8. Pharmaceutical Inspection Co-operation Scheme. Good Practices for Computerised Systems in

Regulated GxP Environments, Pharmaceutical Inspection Convention, PI 011-1. Geneva, 2003.
9. Medicines Control Agency. “Top 10 GMP inspection issues,” MCA Seminar. Trill AJ. “Computerised
systems and GMP—current issues.” London, September 24, 2002.
10. International Society for Pharmaceutical Engineering/Parenteral Drug Association. Good Practice
and Compliance for Electronic Records and Signatures: Part 1. Good Electronic Record Management
(GERM), 2002. Available at: www.ispe.org.
11. International Society for Pharmaceutical Engineering/Parenteral Drug Association. Good Practice
and Compliance for Electronic Records and Signatures: Part 2. Complying with 21 CFR Part 11,
Electronic Records and Electronic Signatures, 2001. Available at: www.ispe.org.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Preface

This is the second edition of this book, and much has changed in the world of computer
systems compliance since it was first published five years ago. The combination of economic
pressures and the desire to maximize value for money is driving a new mind set. Bureaucratic
practices often associated with validation have been widely challenged rather than accepted
through hearsay that they are driven by the regulations. Practitioners feel empowered to justify
more efficient and effective ways of working. The role of risk management throughout the life
cycle of a computer system is understood not only for the benefit of patient/consumer safety
but also in terms of cost-effectiveness. The next step involves making largely subjective risk
assessments more scientific through utilizing relevant data. Couple this thinking with the focus
on demonstrating that a computer system is fit for purpose through process capability rather
than a compliance cross-check, and it is fair to say that a new paradigm has emerged.
The structure of this second edition remains the same, with the first portion providing
chapters discussing the new paradigm, organization and management of compliance activities,
life cycle requirements stepping through development, verification, operation, and decom-
missioning of computer systems. In addition, there are chapters covering latest developments
in electronic record and signature requirements, new practical guidance on risk-based
decisions, handling regulatory inspections, and improving organizational capabilities to
deliver highly efficient and effective compliance through six-sigma and lean manufacturing
philosophies. Throughout the book, I have included real observations recently made by FDA
on the various topics being discussed.
A series of case studies are provided in the second portion of the book showing how the
principles explained earlier can be put into practice. The real world is rarely as simple and
straightforward as we might hope, and I have been very keen to bring together a group of case
studies to share practical solutions to the many and varied challenges that can face
practitioners. The case studies cover most types of computer systems used today in R&D,
manufacturing, and commercial supply organizations. Original case studies have undergone
significant review and new case studies added to keep the information presented current and
relevant. I have encouraged the contributors to include pertinent checklists on key aspects of
their case studies to complement the more generic guidance provided in the first portion of the
book.
Once again, I am hugely indebted to the large number of contributors each of whom was
invited to participate on the basis of their recognized expertise (see Biographies). In addition, I
would also like to acknowledge friends and colleagues who have provided invaluable
discussions and explorations of computer compliance principles and practices over the years.
In particular, I would like to thank Sam Brooks (Novartis Consumer Healthcare), Ellis Daw
(GlaxoSmithKline), Paul D’Eramo (Johnson & Johnson), Howard Garston-Smith (Gartson
Smith Associates), Jerry Hare (Independent Consultant), Niels Holger Hansen (Novo Nordisk),
Paige Kane (Wyeth Biotech), Scott Lewis (Eli Lilly), Takayoshi Matsumura (Eisai), Karl-Hienz
Menges (German Darmstadt GMP Inspectorate), Gordon Richman (EduQuest), Peter
Roberston (AstraZeneca), David Selby (Selby-Hope), and Sion Wyn (Conformity).
Last but by no means least, I would like to thank my wife Sarah and our children
(Katherine, Robert, and Edward) for their love, patience, and support during the preparation
of this book.

Guy Wingate
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xii Preface

DISCLAIMER
The information contained in this book is provided in good faith and reflects the personal
views of the contributors. These views do not necessarily reflect the perspectives of the
contributor’s respective employers. The information provided does not constitute legal advice
and no liability can be accepted in any way.

PERMISSIONS
ISPE and PDA are thanked for their kind permission to print the following artwork: Figure 1.6
(New 21st Century Paradigm), Table 3.1 (Characteristics of Various Document Types), Fig-
ure 5.4 (Criticality and Impact Analyses), Table 11.1 (Monitoring Plan for Server-Based LIMS),
Figure 11.4 (Data Life Cycle), Figure 13.3. (Electronic Record Life Cycle), Figure 13.4 (Example
Audit Trail), and Appendix 13.C (Procedural and Technological Controls for 21 CFR Part 11).
Specific reference sources are provided in the text where artwork is located. Figure 1.5 is
reprinted, with permission, from ASTM E2500-07 Standard Guide for Specification, Design,
and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and
Equipment, copyright ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA
19428.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contributor Biographies

JOHN ANDREWS (ANDREWS CONSULTING ENTERPRISES)

John is a Director of Andrews Consulting Enterprises Limited. Prior to this, he was the
European IT Consulting Service Manager at KMI, a division of PAREXEL International LLC.
He has been a member of the GAMP Forum Special Interest Group on process control systems;
he also sat on the editorial board for GAMP14. His activities include providing consultancy
and training on computer systems validation and compliance and quality assurance activities
within the pharmaceutical, biopharmaceutical, medical device, and other regulated healthcare
industries. He is currently specializing in the application of GAMP principles to the project
management and validation of process analytical technologies (PAT), PAT data collection
methods, chemometric models, and real-time release strategies. Prior to the above, he held
positions as a site computer system validation manager and a supply chain systems project
manager with GlaxoSmithKline (GSK). Responsibilities there covered process control systems,
business systems, and laboratory system validation. Previous employment includes SmithK-
line Beecham Pharmaceuticals where he held positions as a senior engineering standards
engineer, secondary manufacturing electrical engineer, projects engineer, and electrical
supervisor.
Contact: [email protected]

PETER BOSSHARD, PHD (HOFFMANN-LA ROCHE)

Peter is global Quality Manager for F. Hoffmann-La Roche Limited based at Basel,
Switzerland. He is a pharmacist by education and has spent more than 15 years in the
pharmaceutical industry. His experience covers quality assurance of computerized systems
validation, establishment of policy and guidelines, training of business and IT departments,
audits of the internal implementation of the standards, consultancy for projects and sites, and
external representation of the Roche approach to computer system validation. Currently, Peter
is responsible for all aspects of computerized systems validation, electronic records and
signature interpretation, and change control for global systems within Roche Pharma
Technical Operations.
Contact: [email protected]

ROGER BUCHANAN (ELI LILLY)

Roger is a Computer Quality Consultant for Eli Lilly; before joining Lilly, he was working in
the petrochemical industry (Middle East and the United Kingdom). Roger has been with Lilly
for the last 20 years; his first 10 years was working as a technical support engineer for
biotechnology human growth hormone facilities before moving into IT and computer quality.
It was in this first period with Lilly that he obtained his BSc (Hon) degree via the open
university program. He has spent the last eight to nine years working in computer systems
quality assurance supporting the European and Asia Pacific sites providing training, quality
evaluations, and consultation on computer validation for IT, laboratory, and process
automation systems. He is actively involved with his U.S. consultation group to look at
benchmarking across industry on approaches to computer systems validation. He is an active
member of GAMP and has been involved in a number of special interest groups working on
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xiv Contributor Biographies

building management systems, testing, and, more recently, process control systems. Roger is
currently involved in developing guidance on the application of dose calculators in the
pharmaceutical industry.
Contact: [email protected]

WINNIE CAPPUCCI (BAYER PHARMACEUTICALS)

Winnie is currently Associate Director for Product Supply IT Systems Compliance, North
America. She has worked in the pharmaceutical industry for 39 years and in global roles for the
last 14 years. Ms Cappucci has worked as a business process owner, an IT professional, and,
lastly, as a quality and compliance specialist in a highly regulated environment. In her current
role, Ms Cappucci is responsible for developing and implementing Bayer’s global standards
for computer systems compliance. She is a member of the GAMP Americas Steering
Committee, the GAMP Editorial Board, and cochair of the GAMP special interest group working
on quality and compliance guidance on the topic of outsourcing. She is also a member of the
Parenteral Drug Association (PDA) Industry Advisory Board for Technical Report 32
(Auditing of Suppliers Providing Computer Products and Services for Regulated Operations)
and the Audit Resource Center repository.
Contact: [email protected]

MARK CHERRY (ASTRAZENECA)

Mark is the Integrated Assurance Manager for Global Operations at AstraZeneca where he is
responsible for computer systems validation, risk management and security. Mr Cherry
graduated in Instrumentation and Process Control Engineering in 1987, and worked as a
Project Engineer for Sterling Organics until joining Glaxo in 1990. He was involved in a variety
of process control projects within Glaxo until 1995 when he became the Engineering Team
Manager, responsible for all engineering maintenance activities on a bulk API plant. In 1997 he
was appointed Systems and Commissioning Manager for a major capital project within
GlaxoWellcome, involving the installation of a large DCS system using the S88.01 approach to
batch control. From 1999 to 2001, Mr Cherry was responsible for computer systems validation
for bulk API manufacturing sites within GlaxoSmithKline. Mr Cherry is a Chartered Engineer,
a member of The Institute of Measurement and Control, the International Society for
Pharmaceutical Engineering (ISPE) and of the GAMP European Steering Committee.
Contact: [email protected]

CHRIS CLARK (NAPP PHARMACEUTICALS)

Leaving Lancaster University with a BSc degree in biochemistry, Chris has gained over
30 years’ QA experience within the pharmaceutical and healthcare industries, commencing
with Sterling-Winthrop, then moving to Baxter Healthcare Limited, and finally joining NAPP
in 1993. As head of quality compliance, he is responsible for aspects of the company quality
management system ensuring compliance to current international regulatory requirements for
GMP, GCP, GPvP, and GLP. Chris has been involved in a variety of computer-related projects,
including the local implementation of Oracle1 Applications 11i, an international enterprise
document management system and an international implementation of the Oracle clinical data
management system. As an active member of the ISPE, having formerly held the chair of the
GAMP European Steering Committee and being the current chair of the GAMP Editorial
Review Board, Chris regularly speaks at conferences on developing and implementing science-
based quality risk approaches to computerized systems compliance.
Contact: [email protected]

PETER COADY (PFIZER)

Peter is a computer systems specialist in the global quality operations validation organization
of Pfizer, Inc., based in the United Kingdom. He has over 35 years of industrial experience and
has been employed at senior level by major British companies in the pharmaceutical,
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contributor Biographies xv

petrochemical, chemical, and water sectors. He is a member of GAMP Europe Forum and a
steering committee member and represents the GAMP Forum on the BSI Joint TickIT Industry
Steering Committee. He is a registered lead TickIT and quality management system (ISO9000)
auditor with the International Register of Certified Auditors (IRCA) and works internationally
for Lloyd’s Register Quality Assurance (LRQA) as an independent lead assessor. Mr Coady
has a BSc (Hon) degree and is a chartered engineer. He is a fellow of the Institution of
Mechanical Engineers (FIMechE), a fellow of the Institute of Measurement and Control
(FInstMC), an associate of the Chartered Quality Institute (ACQI), and a member of the
International Society of Pharmaceutical Engineers (ISPE).
Contact: [email protected]

TONY DE CLAIRE (APDC CONSULTING)

Tony is a Director and Principal Consultant of APDC Consulting Limited. The company
provides GxP regulatory compliance and validation consultancy, addressing the broad
spectrum of computer system application and related quality assurance in pharmaceuticals,
biologicals, and medical devices. Following process control and automation career develop-
ment in the chemical and steel industries, he moved into the pharmaceutical sector and
directed major capital and technical programs for new and replacement GxP automated
systems. As an “end user, ” he developed and managed the Manufacturing Automation and
Information Systems Group worldwide for SmithKline Beecham Corporate Engineering.
Moving into computerized system validation consultancy, he worked alongside several
notable former FDA inspectors before setting up an independent consultancy. A contributing
author for the GAMP14, he also produced key sections of the associated supplementary
GAMP Good Practice Guides for “Validation of Process Control Systems” and “IT
Infrastructure Control and Compliance,” and to the ISPE Baseline1 Guide on “Commissioning
and Qualification.” He has lectured on “quality management for software” at the University of
Brighton (U.K.) and contributed material for the process control module of the “pharmaceu-
tical engineering and advanced training” (PEAT) MSc course at the University of Manchester,
U.K. Tony is a member of the Institute of Measurement and Control, a senior member of the
International Society of Automation, a member of the ISPE, and a trained TickIT auditor.
Contact: [email protected]

CHRISTOPHER EVANS (GLAXOSMITHKLINE)

Christopher joined GSK on July 1, 1999 following 27 years of service with ICI PLC. He is now
GSK’s global computer validation manager, responsible for managing resource for compliance
oversight of centrally managed IT projects related to IT manufacturing systems. In addition,
Christopher provides consultancy and inspection support for central systems implemented at
GSK manufacturing sites as part of these IT projects. Christopher has wide international
experience in the establishing and managing teams for validation projects in primary and
secondary manufacturing facilities working for a number of major pharmaceutical
manufacturers in the United Kingdom and Europe including Pfizer, AstraZeneca, Roche,
and Napp Laboratories. Christopher was the lead for the two teams developing revised
guidance on the topics of software and hardware categories and supplier auditing for
GAMP14. He has also been a member of the GAMP Process Control Special Interest Group.
Contact: [email protected]

JOAN EVANS (ABB)

Joan was originally qualified as a chemical engineer at University College Dublin (Ireland) and
has extensive experience in manufacturing industry covering project management, quality
management, line management, and consultancy positions. In 1995 she transferred to the life
sciences group of Eutech (now ABB), and is now part of ABB’s Global Consultancy Group. As
a principal consultant with ABB, Joan has responsibility for the management and technical
leadership of a range of assignments for blue chip companies, specializing in tailored
compliance services for computer systems across the research, manufacturing, and distribution
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xvi Contributor Biographies

spectrum. She is also internal product champion for ABB’s audit and remediation and system
obsolescence management consultancy offerings.
Contact: [email protected]

MARK FOSS (BOEHRINGER-INGELHEIM)

Mark Foss has been Head of Engineering for Boehringer-Ingelheim in the United Kingdom for
the last 10 years. He has worked in both the nuclear and pharmaceutical industries for BNFL,
SmithKline Beecham, as well as Roche Products and Glaxo. He is a member of the GAMP
Industry Board, GAMP European Steering Committee, and is cochair of the UK GAMP Forum.
He chairs the ISPE Good Engineering Practice and Calibration Special Interest Groups, which
have produced ISPE good practice guides. He also previously chaired the GAMP special
interest group that produced the GAMP Good Practice Guide on Validating Process Control
Systems (VPCS).
Contact: [email protected]

ROBERT FRETZ (HOFFMANN-LA ROCHE)

Robert is Head of Process Automation and MES at F. Hoffmann-La Roche Limited based at
Basel, Switzerland. He has a degree in chemical engineering from Swiss Federal Institute of
Technology (ETH Zurich) and joined Hoffmann-La Roche more than 30 years ago. Robert is
presently responsible for process automation and system integration in all chemical,
biotechnical, and galenical manufacturing sites of the Hoffmann-La Roche Pharmaceuticals
Division and leads the corporate manufacturing execution systems (MES) program. He has a
wide international experience in all levels of control and automation projects from
instrumentation to the enterprise level. Many of these projects included computerized system
validation and US CFR Part 11 electronic record and signature compliance. He has also
coauthored the Hoffmann-La Roche corporate guideline on process automation qualification.
More recently, Robert has been concentrating on developing a collaborative system architec-
ture and electronic batch record systems supporting business processes for drug product
release.
Contact: [email protected]

LUDWIG HUBER, PHD (LABCOMPLIANCE)

Ludwig is Director and Chief Editor of Labcompliance, the global online resource for validation
and compliance. Before, he worked for Agilent Technologies for more than 20 years as
compliance program manager. He is author of several computer compliance books including
“Validation and Qualification in Analytical Laboratories” and “Validation of Computerized
Analytical and Networked Systems.” He has published more than 100 papers on validation
and compliance and 21 CFR Part 11 and regulatory contributes to international conferences on
the topic of computer compliance.
Contact: [email protected]

LOUISE KILLA (LOGICACMG)

Louise is a senior IT consultant within the pharmaceutical sector at LogicaCMG, specializing in
the validation of commercial and distribution supply chain applications. Her expertise covers
various aspects of GxP software development and delivery of different computer systems from
R&D through to commercial distribution. She joined LogicaCMG in 1997 and has over 10 years
of experience in software development, quality systems, and project management. She
received a masters degree in transportation from the University of Wales College at Cardiff.
She is an ISO 9001 lead auditor, a member of the ISPE, and an active member of GAMP
Europe. Louise sadly died as this book was being revised.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contributor Biographies xvii

BOB MCDOWALL (MCDOWALL CONSULTING)

Bob has over 23 years experience in the validation of computerized systems in regulated
environments, was the editor of the first book on LIMS in 1987, and is the author of the book on
“validation of chromatography data systems” in 2005. He has written the Questions of Quality
column in LC-GC Europe since 1993 and the Focus on Quality column for Spectroscopy
magazine since 2000. Bob is also the 1997 LIMS awardee for teaching and advances to the
subject. Bob has been principal of McDowall Consulting since 1993, specializing in process
improvement and validation of computerized systems in GxP environments. He has a PhD in
forensic toxicology and fifteen years of experience of analytical chemistry.
Contact: [email protected]

BARBARA NOLLAU (ABBOTT VASCULAR)

Barbara is a Director of Quality Services at Abbott Vascular, responsible for validations,
reliability engineering, supplier quality, microbiology, and document management. She has
26 years of experience and increasing responsibility in the pharmaceutical and medical device
industry, spanning the areas of manufacturing, quality assurance and compliance, IT, and
information services. She holds a BA in communications from Cabrini College and has
completed graduate work in the areas of adult education and pharmaceutical engineering at
Penn State University and California State University, respectively. Barbara is an ASQ-certified
manager of quality and organizational excellence and a member of PDA and ISPE. She is a
member of the GAMP Americas Steering Committee and is serving as a commissioner on the
ISPE Professional Certification Commission. She is a member of the Technology Advisory
Board for LSIT and of the Editorial Review Board of The Journal of Validation Technology and
the Journal of GxP Compliance and has published numerous papers and presented extensively
on validation, 21 CFR Part 11, and related topics.
Contact: [email protected]

ARTHUR (RANDY) PEREZ, PHD (NOVARTIS PHARMACEUTICALS)

Randy Perez currently holds the position of Executive Expert, IT Quality Assurance for Novartis
Pharmaceuticals. His responsibilities at Novartis include a wide range of IT compliance issues,
such as GxP, Sarbanes-Oxley, and data privacy. He serves on several global Novartis teams
dealing with computer systems compliance issues and has authored many of the firm’s global
GxP compliance policies. During his 26-year tenure at Novartis, he has developed a broad
range of experience, working as a chemistry group leader in process research, managing a
chemical manufacturing process validation program, and running a QA validation group for
pharmaceutical operations. Randy was a member of the PhRMA Computer Systems Validation
Committee from 1995 to 1999 and was instrumental in the formation of GAMP Americas when
that group started in 2000. From 2002 to 2008, he was chairman of GAMP Americas and has
been a member of the global GAMP Council since 2002. He initiated and led the GAMP special
interest group who produced the GAMP Good Practice Guide on Global Information Systems
in 2005, and was part of the core team that led the development of GAMP15, published in
2008. Randy has been a speaker and a course leader at numerous conferences in the United
States and Europe and has been published in industry journals and textbooks. In 2005 he was
elected to the ISPE International Board of Directors and was elected to the office of board
secretary in 2008.
Contact: [email protected]

CHRIS REID (INTEGRITY SOLUTIONS)

Chris has worked in life science industries for over 15 years, prior to which he was a
computerized system development engineer. Chris is the Managing Director of Integrity
Solutions Limited, providers of quality and compliance services to life science industries. Chris
currently works with leading global organizations developing and implementing quality and
compliance solutions including defining and implementing strategic quality initiatives,
implementing corporate quality policies and standards, skills development, and system
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xviii Contributor Biographies

validation. Chris works with a variety of organizations and disciplines including IS/IT,
engineering, business, QA, and suppliers. Chris has worked across pharmaceuticals,
biotechnology, medical devices and cosmetic industries, and all regulatory domains including
clinical, laboratories, manufacturing, distribution, and pharmacovigilance. Chris is a current
member of the GAMP European Steering Committee and contributed to the development of
GAMP15 and a variety of GAMP good practice guides.
Contact: [email protected]

TOM RYAN (BOSTON SCIENTIFIC)

Tom is Principal Engineer for validation for Boston Scientific Corporation based in Ireland. He
is an engineering graduate of the University of Limerick and joined Boston Scientific in 1996.
Tom has been involved in several major validation projects from process to product. He is a
member of the ISPE and the Institute of Engineers of Ireland (IEI) and has presented on
validation-related forum topics. He holds an MSc in pharmaceutical validation from the
European College of Validation and in management and technology from the Open University.
Contact: [email protected]

MICHAEL SCHNEIDER, PHD (HOFFMANN-LA ROCHE)

Michael is MES Project Manager for F. Hoffmann-La Roche based at Basel, Switzerland. He is
currently managing a project for the introduction of a MES in a newly built aseptic filling plant.
Previously, he headed the automation and MES user team in the investment project for a large
biotechnology plant. Michael graduated with a PhD degree in chemical engineering of
the Swiss Federal Institute of Technology (ETH Zurich) in 2004. In the same year, he joined
Roche as technical operations trainee where he was responsible for several quality manage-
ment projects.
Contact: [email protected]

ROBERT STEPHENSON, PHD (PFIZER)

After successfully completing a PhD in physics, Rob joined the Boots Company Technical
Services Group in 1977 and, since then, has worked in various roles within the pharmaceutical
and personal product sectors for companies such as Eli Lilly, Unilever and Coty. He joined
Pfizer in 2000 as member of their quality unit operating within the IT group where his
responsibilities included coordinating the manufacturing site’s initiative to achieve 21 CFR
Part 11 compliance and authoring their IT quality management system. Robert is currently
regulatory systems team leader, Sandwich, U.K. During his career, Rob has had experience
with the implementation and operational control of a wide range of applications including
MRPII, document management (EDMS), laboratory management (LIMS and CDMS), and
CAPA/change management systems. He is a member of the GAMP Europe Steering
Committee and has contributed material to GAMP15 and the new GAMP Good Practice
Guide on “A Risk-Based Approach to Operation of GxP Computerised Systems.”
Contact: [email protected]

ANTHONY TRILL (RETIRED SENIOR INSPECTOR, MHRA)

Tony Trill served for 24 years with the United Kingdom’s Medicines Inspectorate [known now
as the Medicines and Healthcare Regulatory products Agency (MHRA)], retiring in July 2008.
His career in the Medicines Inspectorate required him to conduct regular inspections of
companies against requirements of the U.K. Medicines Act and EU directives related to GMP
(manufacturing), GDP (wholesaling and distribution), GMP investigational medicinal
products (IMP) (for clinical trials), and “specials” (industry and NHS). Since 1988 he also
had leadership responsibility within the agency for GMP standards and inspection guidance
relating to computerized systems. Prior to joining the Medicines Inspectorate, Tony had
worked for more than 18 years for three multinational pharmaceutical companies in research
and development, formulation and process development, manufacturing, quality assurance,
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contributor Biographies xix

and technical services in professional, technical, and management roles. His industrial
experience covered a broad spectrum of product types, processes, and responsibilities, and he
has regularly spoken at conferences and published many articles on the topic of computer
compliance. He is a member the GAMP European Steering Committee and led for a time the
Pharmaceutical Inspection Cooperation Scheme’s (PICS) Expert Circle for Computerised
Systems, which developed a guideline for use by regulatory authorities around the world
entitled “Good Practices for Computerised Systems in Regulated ‘GXP’ Environments” (Ref. PI
011-1) adopted in 2003. Most recently, Tony, who holds a BSc (Hon) in pharmacy from the
University of Aston, an MSc in pharmaceutical technology from the University of London
(Chelsea, now Kings College), and an OU diploma in digital computing, led the general GMP
revision process for the Orange Guide and represented MHRA on the revision panel for the
redrafting of GMP chapter 4 (Documentation) and annex 11 (Computerised Systems), which is
still ongoing. He also facilitated a recent EU/PICS regulatory benchmarking audit of MHRA’s
Inspection and Standards Division and assisted with internal quality and systems improve-
ment initiatives. He retains membership of IQA’s IRCA lead assessor/auditor panel and is
eligible as an EC qualified person.
Contact: [email protected]

GUY WINGATE, PHD (GLAXOSMITHKLINE)

Guy is a Senior Quality Director at GSK and has held a range of operational and corporate
roles in GSK’s global manufacturing and supply. These include overall responsibility for
quality for one of GSK largest manufacturing sites (covering topicals, orals, inhalations,
steriles, biopharmaceuticals, and vaccines), responsibility for corporate QA technology
strategy, leading a major revision to the GSK corporate GMP Quality Management System,
and overall responsibility for computer validation standards and implementation. Guy has
worked with a number of regulatory authorities including FDA and MHRA since the early
1990s to help them develop regulatory requirements and inspection strategy (e.g., coauthor of
highly influential ISPE white paper on risk-based approach to electronic records and
signatures, which lead to the proposed revision of U.S. 21 CFR Part 11 regulation). He was the
task team leader for GAMP14 and GAMP15 and has chaired the governing GAMP Council
since 2000. A well-known speaker on computer validation, Guy has previously published three
popular validation books with Interpharm Press. He is also visiting lecturer for the University
of Manchester’s MSc course on pharmaceutical engineering advanced technology (PEAT) and
Institute of Dublin’s MSc course on validation sciences. He is a chartered engineer, a member
of the ISPE, a member of the PDA, and a member of the Institution of Engineering and
Technology (IET). Guy holds BSc, MSc, and PhD from University of Durham in computing,
advanced electronics, and engineering science, respectively. He is widely published in journals
and books and regularly chairs and speaks at validation conferences in the United Kingdom
and Europe. In 2008 Guy was elected to become a member of the International Board of
Directors of the ISPE.
Contact: [email protected]
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Abbreviations

4GL Fourth Generation Language

ABAP Advanced Business Application Program (SAP R/3)
ABB Asea Brown Boveri
ABO Blood Groups: A, AB, B, O
ABPI Association of the British Pharmaceutical Industry
ACDM Association for Clinical Data Management
ACRPI Association for Clinical Research in the Pharmaceutical Industry
ACS Application Configuration Specification
A/D Analog to Digital
ADE Application Development Environment
AGV Automated Guided Vehicle
AIX Advanced Interactive eXecutive, a version of UNIX produced by IBM
ALARP As Low As Reasonably Practical
ANSI American National Standards Institute
API Active Pharmaceutical Ingredient
APV Arbeitsgemeinschaft für Pharmazeutische Verfahrenstechnik
AQAP Association of Quality Assurance Professionals
ASAP Accelerated SAP R/3 application development methodology
ASCII American Standard Code for Information Interchange
ASTM American Society for Testing and Materials
AUI Application User Interface
BARQA British Association for Research Quality Assurance
BASEEFA British Approvals Service for Electrical Equipment in Flammable Atmospheres
BASIC Beginners All-purpose Symbolic Instruction Code
BCD Binary Coded Decimal
BCS British Computer Society
BGA Bundesgesundheitsamt (German Federal Health Office)
BIOS Basic Input Output System
BIRA British Institute of Regulatory Affairs
BMS Building Management System
BNC Boyonet Neil Concelman
BOM Bill of Materials
BPC Bulk Pharmaceutical Chemicals
BPR Business Process Re-engineering
BS British Standard
b/s bits per second
BSI British Standards Institution
CA Certification Agency
CAD Computer Aided Design
CAE Computer Aided Engineering
CAGR Compound Annual Growth Rate
CAM Computer Aided Manufacturing
CANDA Computer Assisted NDA (United States)
CAPA Corrective And Preventative Action
CASE Computer-Aided Software Engineering
CBER Center for Biologies Evaluation and Research, FDA
CCTA Central Computer and Telecommunications Agency
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Abbreviations xxi

CD Compact Disk
CDDI Copper Distributed Data Interface
CDER Center for Drug Evaluation and Research, FDA
CDMS Clinical Database Management System
CDRH Centre for Devices and Radiological Health
CD-ROM Compact Disk — Read Only Memory
CD(-RW) Compact Disk — Rewritable
CDS Chromatography Data System
CE Communauté Européene (EU Medical Device Mark)
CE Capillary Electrophoresis
CEFTC Chemical European Federation Industry Council
CENELEC European Committee for Electrotechnical Standardization
CFR United States Code of Federal Regulation
CGM Computer Graphics Metafile
cGMP Current Good Manufacturing Practice
CHAZOP Computer Hazard and Operability Study
CIM Computer Integrated Manufacturing
CIP Clean In Place
CISPR International Special Committee on Radio Interference (part of IEC)
CMM Capability Maturity Model
CO Costing
COBOL Common Business Oriented Language
COM Component Object Model
COQ Cost of Quality
COTS Commercial Off-The-Shelf
CPG Compliance Policy Guide (United States)
CPP Critical Process Parameter
CPU Central Processing Unit
CQA Critical Quality Attribute
CRC Cross Redundancy Check
CRM Certified Reference Material
CROMERR Cross-Median Electronic Reporting and Record-Keeping
CSA Canadian Standards Association
CSV Computer System Validation
CSVC Computer Systems Validation Committee (of PhRMA)
CTQ Critical to Quality
CV Curriculum Vitae
DAC Digital to Analog Converter
DACH German-speaking countries of Germany (D), Austria (A), and Switzerland (CH)
DAD Diode Array Detector
DAM Data Acquisition Method
DAT Digital Audio Tape
DBA Database Administrator
DBMS Database Management System
D-COM Distributed Component Object Model
DCS Distributed Control System
DDMAC Division of Drug Marketing, Advertising and Communications
DECnet Digital Equipment Corporation Network
DIA Drug Information Association
DLL Dynamic Link Library
DLT Digital Linear Tape
DoH U.K. Department of Health
DOS Disk Operating System
DPMO Defects Per Million Opportunities
DQ Design Qualification
DR Design Review
DRP Distribution Requirement Planning
DSL Digital Subscriber Line
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xxii Abbreviations

DSP Digital Signal Processing

DVD Digital Video Disk
DXF Data Exchange File
EAM Engineering Asset Management
EAN European Article Number
EBRS Electronic Batch Record System
EC European Community
EDI Electronic Data Interchange
EDMS Electronic Document Management System
EEC European Economic Community
EEPROM Electronically Erasable Programmable Read Only Memory
EFPIA European Federation of Pharmaceutical Industry Association
EFTA European Free Trade Association
EIA Electronics Industries Association
EISA Extended Industry Standard Architecture
ELA Establishment License Application
ELD Engineering Line Diagram
EMC Electro-Magnetic Compatibility
EMEA European Medicines Evaluation Agency
EMI Electro-Magnetic Interference
EMS Engineering Management System
ENCRESS European Network of Clubs for Reliability and Safety of Software
EOLC Environmental/Operation Life Cycle
EPA U.S. Environmental Protection Agency
EPROM Electronic Programmable Read Only Memory
ERD Entity Relationship Diagram
ERES Electronic Records, Electronic Signatures
ERP Enterprise Resource Planning
ESD Electro-Static Discharge
ESD Emergency Shutdown
EU European Union
FAT Factory Acceptance Testing
FATS Factory Acceptance Test Specification
FAX Facsimile Transmission
FDA U.S. Food and Drug Administration
FD&C U.S. Food, Drug, and Cosmetics Act
FDDI Fiber Distributed Data Interface
FDS Functional Design Specification
FEFO First Expired First Out
FFT Fast Fourier Transform
FI Finance
FIFO First In-First Out
FM Factory Mutual Research Corporation
FMEA Failure Mode Effect Analysis
FORTRAN Formula Translator
FS Functional Specification
FTE Full-Time Employee
FT-IR Fourier Transform — Infrared
FTP/IP File Transfer Protocol/Internet Protocol
GALP Good Automated Laboratory Practice
GAMP Good Automated Manufacturing Practice
GB Giga-Byte
GC Gas Chromatography
GCP Good Clinical Practice
GDP Good Distribution Practice
GEP Good Engineering Practice
GERM Good Electronic Record Management
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Abbreviations xxiii

GIGO Garbage In, Garbage Out

GLP Good Laboratory Practice
GMA Gesellschaft Me Meb- und Automatisierungstechnik
GMP Good Manufacturing Practice
GPIB General Purpose Interface Bus
GPP Good Programming Practice
GUI Graphical User Interface
GxP GCP/GDP/GLP/GMP
HACCP Hazard Analysis and Critical Control Point
HATS Hardware Acceptance Test Specification
HAZOP Hazard and Operability Study
HDS Hardware Design Specification
HIV Human Immunodeficiency Virus
HMI Human Machine Interface
HP Hewlett-Packard
HPB Canadian Health Products Branch Inspectorate
HPLC High Performance Liquid Chromatography
HPUX Hewlett-Packard UNIX
HSE U.K. Health and Safety Executive
HTML Hyper Text Markup Language
HVAC Heating, Ventilation, and Air Conditioning
IAPP Information Asset Protection Policies
IBM International Business Machines
ICH International Conference on Harmonization
IChemE U.K. Institution of Chemical Engineers
ICI Imperial Chemical Industries
ICS Integrated Control System
ICSE U.K. Interdepartmental Committee on Software Engineering
ICT Information and Communications Technologies
ID Identification
IEC International Electrotechnical Commission
IEE U.K. Institution for Electrical Engineers
IEEE Institute of Electrical and Electronic Engineers
IETF Internet Engineering Task Force
IIP Investors in People
IKS Swiss Agency for Therapeutic Products (also known as SwissMedic)
IMechE U.K. Institution for Mechanical Engineers
INS Instrument File Format
InstMC U.K. Institution for Measurement and Control
InterNIC Internet Network Information Center
I/O Input/Output
IP Index of Protection
IP Ingress Protection
IP Internet Protocol
IPC Industrial Personal Computer
IPC In-Process Control
IPng IP Next Generation
IPR Intellectual Property Rights
IPSE Integrated Project Support Environment
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPX Internet Packet eXchange
IQ Installation Qualification
IQA U.K. Institute of Quality Assurance
IRCA International Register of Certificated Auditors
IS Intrinsically Safe
ISA Industry Standard Architecture bus (also known as AT bus)
ISA Instrument Society of America
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xxiv Abbreviations

ISM Industrial, Scientific, and Medical

ISO International Standards Organization
ISP Internet Service Provider
ISPE International Society for Pharmaceutical Engineering
IT Information Technology
ITIL Information Technology Infrastructure Library
ITT Invitation to Tender
IVRS Interactive Voice Recognition System
IVT Institute of Validation Technology
JAD Joint Application Development
JETT North American Joint Equipment Transition Team
JIT Just In Time
JPEG Joint Photographic Experts Group
JPMA Japanese Pharmaceutical Managers Association
JSD Jackson Development Method
KOSEISHO Ministry of Health and Welfare (Japan)
KPI Key Performance Indicator
KT Kepner Tregoe
LAN Local Area Network
LAT Local Area Transport, a DEC proprietary Ethernet protocol
LC Liquid Chromatography
LIMS Laboratory Information Management System
L/R Inductance/Resistance Ration
MAU Media Attachment Unit
MASCOT Modular Approach to Software Construction, Operation, and Test
MB Mega-Byte
Mb/s Mega bits per second
MC Main cross connect room
MCA Micro Channel Architecture
MCA U.K. Medicines Control Agency
MCC Motor Control Center
MD Message Digital, an algorithm to verify data integrity
MDA U.K. Medical Device Agency
MDAC Microsoft Data Access Components
MES Manufacturing Execution System
MHLW Japanese Ministry for Health, Labor, and Welfare
MHRA U.K. Medicines and Healthcare products Regulatory Authority
MHW Japanese Ministry for Health and Welfare
MIME Multipurpose Internet Mail Extension
MIS Management Information System
MM Materials Management
MMI Man Machine Interface (see HMI)
MMS Maintenance Management System
MODEM Modulator-Demodulator Units
MPA Swedish Medical Products Agency
MPI Manufacturing Performance Improvement
MPS Master Production Schedule
MRA Mutual Recognition Agreement
MRP Materials Requirements Planning
MRP II Manufacturing Resource Planning
MRM Multiple Reaction Monitoring
MSAU/MAU IBM’s Multi-Station Access Unit (Token Ring hubs)
MTTF Mean Time To Failure
NAMAS U.K. National Measurement Accreditation Service
NAMUR Normenarbeitsgemeinschaft fiir Me b- und Regelungstechnik
NATO North Atlantic Treaty Organization
NDA U.S. New Drug Application
NetBEUI NetBIOS Extended User Interface
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Abbreviations xxv

NetBIOS Network Basic Input/Output System

NIC Network Interface Card
NIST National Institute of Standards and Technology
NIR Near Infra-Red
NMR Nuclear Magnetic Resonance
NOS Network Operating System
NPL National Physics Laboratory
NSA U.S. National Security Agency
NT New Technology
NTL National Testing Laboratory
OCR Optical Character Recognition
OCS Open Control System
OECD Organisation for Economic Co-operation and Development
OEM Original Equipment Manufacturer
OICM Swiss Office Intercantonal de Controle des Medicaments
OLE Object Linking and Embedding
O&M Operation and Maintenance
OMM Object Management Mechanism
OOS Out Of Specification
OQ Operational Qualification
OS Operating System
OSI Open System Interconnect
OTC Over The Counter
OTS Off The Shelf
OWASP Open Web Application Security Project
PAI Pre-Approval Inspection
PAR Proven Acceptable Range
PAT Process Analytical Technology
PC Personal Computer
PCI Peripheral Component Interconnect
PCX Graphics File Format
PDA Parenteral Drug Association
PDA Personal Digital Assistant
PDF Portable Document Format
PDI Pre-Delivery Inspection
PhRMA Pharmaceutical Research and Manufacturing Association
PIC Pharmaceutical Inspection Convention
PIC/S Pharmaceutical Inspection Co-operation Scheme
PICSVF U.K. Pharmaceutical Industry Computer System Validation Forum
PID Proportional, Integral, Derivative (Loop)
P&ID Process Instrumentation Diagram
PIR Purchase Item Receipt
PKI Public Key Infrastructure
PLC Programmable Logic Controller
PMA Pharmaceutical Manufacturers Association
POD Proof of Delivery
PP-PI Production Planning — Process Industries
PQ Performance Qualification
PQG Pharmaceutical Quality Group (part of IQA)
PRINCE2 Projects In Controlled Environments 2
PRM Process Route Maps
PSI Statisticians in the Pharmaceutical Industry
PSU Power Supply Unit
PTB Physikalische-Technische Bundesanstalt
PTT Public Telephone and Telecommunications
PV Performance Verification
QA Quality Assurance
QC Quality Control
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xxvi Abbreviations

QM Quality Management
QMS Quality Management System
QP European Union Qualified Person
QS Quality System
QSIT FDA Quality System Inspection Technique
QTS Quality Tracking System
RAD Rapid Application Development
RAD Role Activity Diagram
RAID Redundant Array of Inexpensive Disks
RAM Random Access Memory
RCCP Rough Cut Capacity Planning
RCM Reliability Centered Maintenance
R&D Research and Development
RBE Review By Exception
RDB Relational Database
RDT Radio Data Terminal
RF Radio Frequency
RFI Radio Frequency Interference
RFID Radio Frequency Identification
RFP Request for Proposal
RH Relative Humidity
ROM Read Only Memory
RP German Federal Ministry for Health
RPharmS U.K. Royal Pharmacy Society
RPN Risk Priority Number
RSA Rivest, Shamir, Adleman Public-Key Cryptosystem
RSC U.K. Royal Society of Chemists
RTD Radio Data Terminal
RTF Rich Text Format
RTL/2 Real-Time Language, Version 2
RTM Requirements Traceability Matrix
RTSASD Real-Time System-Analysis System-Design
SAA Standards Association of Australia
SAM Software Assessment Method
SAP Systems, Applications, Products in Data Processing (Company)
SAP R/3 An ERP system developed by SAP
SaRS U.K. Safety and Reliability Society
SAS Statistical Analysis System
SAT Site Acceptance Testing
SATS System Acceptance Test Specification
SCADA Supervisory Control and Data Acquisition
SCR Source Code Review
SD Sales and Distribution
SDLC Software Development Life Cycle
SDS Software Design Specification
SEI Carnegie Mellon University’s Software Engineering Institute
SFC Sequential Function Chart
SGML Standard Generalized MarkUp Language
SHA Secure Hash Algorithm
SHE Safety, Health & Environment
SIP Sterilization In Place
SKU Stock Keeping Unit
SLA Service Level Agreement
SLC System Life Cycle
SM Section Manager
SMART Specific, Measurable, Achievable, Recorded, Traceable
SMDS Software Module Design Specification
S/MIME Simple Multipurpose Internet Mail Extension
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Abbreviations xxvii

SMS Microsoft’s System Management Server

SMTP Simple Mail Transfer Protocol
SNA Systems Network Architecture
SOP Standard Operating Procedure
S&OP Sales and Operations Planning
SOUP Software Of Unknown Pedigree
SPC Statistical Process Control
SPICE Software Process Improvement Capability d’Etermination
SPIN Software Process Improvement Network
SPSS Statistical Product and Service Solutions
SQA Society of Quality Assurance
SQAP Software Quality and Productivity Analysis
SQL Software Query Language
STARTS Software Tools for Large Real-Time Systems
STD Software Technology Diagnosis
STEP STandard for Exchange of Product model data in ISO 10303
STP Shielded Twisted Pair
StRD Statistical Reference Dataset
SWEBOK Software Engineering Body of Knowledge
TC Terminal Cross connect room
T&C Threats and Controls
TCP Transmission Control Protocol
TCP/IP Internet Protocol/Transmission Control Protocol
TCU Temperature Control Unit
TIA Telecommunications Industry Association
TIFF Tagged Image File Format
TIR Test Incident Report
TGA Australian Therapeutic Goods Administration
TÜV Technischer Überwachungs-Verein
UAT User Acceptance Testing
UCITA U.S. Uniform Computer Information Transactions Act
U.K. United Kingdom
UL Underwriters Laboratories Inc.
ULD Utility Line Diagrams
UPC Universal Product Code
UPS Uninterruptible Power Supply
URL Universal Resource Locator
URS User Requirement Specification
U.S. United States (of America)
U.S.A. United States of America
USD United States Dollars
UTP Unshielded Twisted Pair
UV Ultra Violet
VBA Visual Basic
VDS Validation Determination Statement
VDU Visual Display Unit
VMP Validation Master Plan
VMS Virtual Memory System
VP Validation Plan
VPN Virtual Private Network
VR Validation Report
VSR Validation Summary Report
V-MAN Validation Management
WAN Wide Area Network
WAO Work Station Area Outlet
WAP Wireless Application Protocol
WFI Water For Injection
WHA World Health Agreement
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xxviii Abbreviations

WHO World Health Organisation

WIFF Waveform Interchange File Format
WIP Work In Progress
WMF Windows Metafile Format
WML Wireless Markup Language
WORM Write Once, Read Many
WWW World Wide Web
WYSIWYG What You See Is What You Get
XML Extensible Markup Language
Y2K Year 2000
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contents

Foreword to the Second Edition vii

Foreword to the First Edition viii
Preface xi
Contributor Biographies xiii
Abbreviations xx
Contributors xxxii

1. Introduction 1

2. Organization and Management 18

3. Supporting Processes 32

4. Prospective Verification and Validation 55

5. Project Initiation and Compliance Determination 81

6. Requirements Capture and Supplier (Vendor) Selection 103

7. Design and Development 128

8. Coding, Configuration, and Build 154

9. Development Testing 167

10. User Qualification and Authorization to Use 178

11. Operation and Maintenance 203

12. Phaseout and Withdrawal 236

13. Electronic Records and Electronic Signatures 248

14. Regulatory Inspections 276

15. Compliance Strategies 309

16. Capabilities, Measures, and Performance 336

17. Practical Troubleshooting 356

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

xxx Contents

18. Concluding Remarks 362

19. Case Study 1: Computerized Analytical Laboratory Systems 368

Ludwig Huber

20. Case Study 2: Chromatography Data Systems 382

Bob McDowall

21. Case Study 3: Laboratory Information Management Systems 406

Christopher Evans

22. Case Study 4: Clinical Systems 434

Chris Clark and Guy Wingate

23. Case Study 5: Control and Monitoring Instrumentation 449

Peter Coady and Tony de Claire

24. Case Study 6: Process Control Systems 479

Roger Buchanan and Mark Cherry

25. Case Study 7: Manufacturing Execution Systems and Electronic Batch Records 499
Peter Bosshard, Michael Schneider, and Robert Fretz

26. Case Study 8: Building Management Systems 515

John Andrews and Mark Foss

27. Case Study 9: Engineering Management Systems 535

Chris Reid

28. Case Study 10: Desktop Applications Including Spreadsheets 556

Arthur (Randy) Perez

29. Case Study 11: Databases 568

Arthur (Randy) Perez

30. Case Study 12: Electronic Document Management Systems 582

Robert Stephenson

31. Case Study 13: Enterprise Resource Planning Systems 596

Guy Wingate

32. Case Study 14: Marketing and Supply Applications 615

Louise Killa

33. Case Study 15: IT Infrastructure and Associated Services 650

Chris Reid and Barbara Nollau

34. Case Study 16: Internet/Intranet Applications 677

Winnie Cappucci, Ludwig Huber, and Arthur (Randy) Perez

35. Case Study 17: Medical Devices and Their Automated Manufacture 689
Guy Wingate and Tom Ryan
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contents xxxi

36. Case Study 18: Blood Establishment Computer Systems 703

Joan Evans

37. Case Study 19: Process Analytical Technology 716

Guy Wingate

38. Case Study 20: Computer Applications Supporting the Supply

of Biotechnology Products 726
Guy Wingate

Glossary 729
Index 739
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0000_O.3d] [22/1/010/17:2:14] [1–32]

Contributors

John Andrews Andrews Consulting Enterprises Ltd.

Peter Bosshard Hoffmann-La Roche

Roger Buchanan Eli Lilly

Winnie Cappucci Bayer Pharmaceuticals

Mark Cherry AstraZeneca

Chris Clark NAPP Pharmaceuticals

Peter Coady Pfizer

Tony de Claire APDC Consulting Ltd.

Christopher Evans GlaxoSmithKline

Joan Evans ABB

Mark Foss Boehringer-Ingelheim

Robert Fretz Hoffmann-La Roche

Ludwig Huber Labcompliance

Louise Killa LogicaCMG

Bob McDowall McDowall Consulting

Barbara Nollau Abbott Vascular

Arthur (Randy) Perez Novartis Pharmaceuticals

Chris Reid Integrity Solutions Limited

Tom Ryan Boston Scientific

Michael Schneider Hoffmann-La Roche

Robert Stephenson Pfizer

Guy Wingate GlaxoSmithKline

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

1 Introduction

Computer systems support billions of dollars of pharmaceutical and healthcare sales revenues.
The pharmaceutical and healthcare industry has increasingly used computers to support the
development and manufacturing of their products. Within research environments, computer
systems are used to speed up product development, reducing the time between the
registration of a patent and product approval and, hence, optimizing the time available to
manufacture a product under a patent. Computer systems are also used to support routine
supply of medicinal products to improve manufacturing performance, reduce production
costs, and improve product quality. It is important that these systems are fit for purpose from a
business and regulatory perspective. Regulatory authorities treat a lack of regulatory computer
system compliance as a serious GxP deviation. Pharmaceutical and healthcare companies need
a balanced, proactive, and coordinated strategy that addresses short-, medium-, and long-term
and internal and external needs and priorities. This book aims to provide practical advice and
guidance on how to do this on the basis of extensive industry experience and with reference to
the latest regulatory developments and industry trends.

REGULATED COMPUTER SYSTEMS

Computer systems that are used to support regulated processes in the pharmaceutical,
biological, and healthcare industry need to comply with the expectations of the regulatory
authorities overseeing development, manufacture, and supply. Applicable regulations are
commonly referred to collectively as GxP regulations and include but are not limited to

l Good Clinical Practices (GCP)—dealing with clinical trials,

l Good Laboratory Practices (GLP)—dealing with laboratory operations,
l Good Manufacturing Practices (GMP)—dealing with manufacturing of products,
l Good Distribution Practices (GDP)—dealing with distribution and onward ware-
housing, and
l Electronic Records and Electronic Signatures.

The scope of regulated computer systems includes systems used to manage data or
support decisions that are submitted or subject to review by regulated authorities whether they
are being submitted because they are required or used as supporting information.
The list of potential computer system applications that must comply with regulatory
requirements is extensive. Some examples of computer system applications impacted are
illustrated in Figure 1.1. Such diversity, coupled with the increasing scope of applications, has
led to some individual regulators to suggest that a simpler approach would be to declare that
all computer systems used within a manufacturing environment, whatever their application
be, must comply with regulatory requirements.

Business Case
Investments in computer systems are made on the basis of realizing a benefit. Claimed benefits
in the business case might include the following:

l Building in quality controls to ensure that the process is followed correctly, reducing
human error and the need to conduct manual checks.
l Standardization of practices to build consistent ways of working. This is increasingly
important for large multisite manufacturing organizations that are rationalizing their
operations.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

2 Chapter 1

Figure 1.1 Regulated computer system applications.

l Reducing the cost of sales by removing non-value-added activities (e.g., quality

inspections, exception handling, rework, and scrap).
l Speed-up of process cycle times by reducing wait times and by improved scheduling.
l Elimination of duplicate effort by establishing electronic master records and thus
avoiding the need for the presentation of information in various paper formats, each of
which must be controlled.
l Replacing systems that are no longer supported by their suppliers.
l Addressing regulatory deficiencies in processes or existing computer systems.

More than one benefit should normally be delivered. Computer systems should not be
implemented solely for regulatory compliance; operational benefits should always be explored
as well.

Regulatory Compliance
The pharmaceutical industry is subject to GxP regulations such as the World Health
Organization’s (WHO) resolution WHA 22.50; the European Union’s (EU) Directive 2003/94/
EC; the Japanese Manual on Computer Systems in Drug Manufacturing; the U.S. Code of
Federal Regulations Title 21, Parts 210 and 211; and Medicinal Products, Part 1 of the
Australian Code of Good Manufacturing for Therapeutic Goods. Other countries have their
own regulatory requirements, which tend to have aligned expectations, although some specific
differences do exists.
GMP is enforced on the ground by the national regulatory authorities. Well-known GMP
regulatory authorities in the pharmaceutical industry include the U.S. Food and Drug
Administration (FDA), the U.K. Medicines and Healthcare products Regulatory Agency
(MHRA), the Australian Therapeutic Goods Administration (TGA), Health Canada, and the
Japanese Ministry of Health, Labor and Welfare (MHLW). The regulatory authorities can
prevent the sale of any product in their respective country if they consider its manufacture not
to be GxP compliant. To pharmaceutical and healthcare companies, GxP is nothing less than a
license-to-operate matter.
The process of demonstrating GxP has become known as validation and involves

“establishing documented evidence which provides a high degree of assurance that

a specific process will consistently produce a product meeting its pre-determined
specifications and quality attributes (1).”

This definition has been widely adopted, albeit with minor modifications, by the various
GxP regulatory authorities around the world and embraces facilities, equipment, systems, and
processes.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 3

A general awareness within both the industry and the regulatory community of the need
to validate computer systems began to emerge formally in 1979, when the United States
introduced GxP regulatory legislation that specifically referred to automated equipment (2). In
1983 the FDA issued what became known as the “Blue Book” (because of the color of its cover)
guidance to inspectors on what was reasonable to accept as evidence for computer systems
compliance (3). The first widely publicized FDA citation (a formal written regulatory criticism
of a perceived noncompliance with the regulations) for computer system noncompliance was
issued in 1985.
The issue of computer systems validation assumed a high profile in Europe in 1990 when
two European pharmaceutical manufacturers did not satisfy computer compliance expect-
ations and were temporarily prohibited from exporting their products to the United States. EU
requirements for computer systems compliance were issued a few years later in 1993 and can
be found in Annex 11 in the EU GMPs (4). Once formal requirements had been defined,
European regulators started to make significant noncompliance findings at various pharma-
ceutical companies.
Australia and Canada have subsequently adopted Annex 11. Meanwhile, Japan issued its
first computer compliance guideline in 1993 (5). Computer compliance, however, did not
receive the industry profile in Japan that it did in the United States and Europe until the need
for electronic record and electronic signature controls emerged.
The United States was the first country to issue specific requirements for electronic
records and electronic signatures—21 CFR Part 11 was published in 1997 (6). It caused much
debate in terms of whether its expectations were reasonable and practical. The U.S. FDA
subsequently published industry guidance that applied a risk-based approach to controls (7).
Similar expectations were published by PIC/S for use by Australian, Canadian, and EU
regulatory authorities (8). The Japanese MHLW issued electronic record/signature require-
ments in 2005 on the basis of various discussions with industry (9). Both U.S. and EU
regulations are currently being updated to address these developments.
Table 1.1 provides a general summary of regulatory expectations for computer validation
together with prominent regulations for different sectors of pharmaceutical and healthcare
industry.

Cost of Compliance
Computer systems can account for significant capital and operating costs. Such assets deserve
careful management. The cost of compliance will depend on the breadth and depth of work
undertaken.
Current industry good practice suggests that compliance activities should account for not
more than 10% of project delivery costs (10). Anecdotal stories still circulate relating to
examples of excessive cost of validation. The root cause behind such high costs tends to be
poor project management, and when things go bad, people tend to want to find a scapegoat.
The primary factor that has typically driven the amount of validation has been the nature
of the computer system involved [whether standard application, configurable package, or
custom-built (bespoke) application]. This approach has been driven by ISPE/GAMP1,
specifically the use of software categories to derive basic compliance approach. Other factors
have had a limited influence on the amount of compliance work conducted, although risk-
based thinking has started to have an impact.
While current best practice represents a huge improvement in industry practice from the
1990s, there is still much that can be done to reduce costs further. As discussed later in this
chapter, it should be possible to reduce the cost of compliance below 5% of project costs while
at the same time improving the standard of compliance.

Operational Dividend
Compliant computer systems should yield an operational dividend (10). A survey of over three
hundred applications by Weinberg Associates suggests that maintenance savings within four
years generally offset the investment in validation. An example of such a maintenance
dividend is illustrated by a production planning system at ICI that adopted the principles of
validation for about half of its 800 computer programs. Management, halfway through the
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

4 Chapter 1

Table 1.1 Regulatory Expectations Concerning Computer Validation

Industry sector Validation expectation Prominent regulations

Food Requirement for process validation on U.S. Code of Federal Regulations 21 CFR
effective controls at critical points, and Part 110, and EU Directive 93/43/EEC
equipment maintenance. Computer
validation is recommended.
Dietary supplements Requirement for process characterization U.S. Code of Federal Regulation 21 CFR
and equipment maintenance. Part 111, 113 and 114), and EU
Computer validation is recommended. Directive 2002/46/EC
Cosmetics Requirement for computer validation. COLIPA and U.S. Code of Federal
Regulation 21 CFR Part 700, 701, 710,
720, and 740)
OTC medicines Process and computer validation is U.S. Code of Federal Regulation 21 CFR
required. Part 210 and 211, and EU Directive
2003/94/EEC
Prescription Process and computer validation is U.S. Code of Federal Regulation 21 CFR
pharmaceuticals required. Part 210 and 211, and EU Directive
2003/94/EEC
Biological and Process and computer validation is U.S. Code of Federal Regulation 21 CFR
biopharmaceuticals required. Part 600, 606, and 610, and EU
Directive 2003/94/EEC
Blood processing and Process and computer validation is U.S. Code of Federal Regulation 21 CFR
products required. Parts 800 and 820, EU Directive 2005/
02/EEC
Medical devices Process and computer validation is U.S. Code of Federal Regulations 21 CFR
required for medical device and its Part 820 (Quality Systems Regulation),
production. and EU 2007/47EEC coupled with CE
marking.

Abbreviations: COLIPA, European Cosmetic, Toiletry, and Perfumery Association; EU, European Union.

project, abandoned the quality approach because there was no perceived project benefit. The
total operational life of the system was later examined. It was found that maintenance costs for
the software adopting the principles of validation were about 90% less than the comparable
costs for the remainder of the software. Similar data has been found for MRP II/ERP systems.
With poor-quality software typically accounting for 50% to 60% of maintenance costs,
validation really does make good business sense.

Cost of Failure
The failure to comply with regulatory expectations can have significant financial implications.
Noncompliance incidents may lead to delays in the issue of a license or its withdrawal and
thus an embargo on the distribution of their product in the relevant marketplace (e.g., the
United States).
The financial consequences of correcting deficient validation might, at first sight, seem
small compared with the typical investment of US$800,000,000 to bring a new drug to
market (11). The real financial impact is the loss in sales revenue arising from a prohibition to
market the product. For top-selling drugs in production, citations for noncompliance by GxP
regulatory authorities can cost their owner upward of US$2,000,000/day in lost sales revenue.
One FDA Warning Letter cost the pharmaceutical manufacturer concerned over US
$200,000,000 to replace and validate a multisite networked computer system.
The trick is to cost-effectively conduct sufficient work to ensure GxP compliance, but, as
illustrated in Figure 1.2, there is always debate over how much is sufficient to fulfill the
regulator’s expectations. Excessive validation may increase confidence in regulatory compli-
ance, but it does not come cheap. Inadequate validation may actually be cheaper, but, in the
long term, the cost of regulatory noncompliance could be devastating. This book aims to clarify
how much validation is enough and to suggest how it can be cost-effectively organized and
also to discuss areas of debate.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 5

Figure 1.2 How much validation is

enough?

There are numerous stakeholders with an interest in successful GxP inspection outcome.
GxP noncompliance is likely to reduce public confidence in the pharmaceutical and healthcare
industry and the offending company. Political pressures may result in improved industry
practices, influence the inspection approaches and methods of regulatory authorities, and/or
review the acceptability of compliance standards and guides. The standing of regulatory
authorities may be affected if they fail to notice noncompliance that lead directly to
substandard drug products being distributed and used. Associated legal liabilities may arise
for both the regulator and offending company. The company’s corporate reputation may take
years to recover. Drug sales are likely to fall as the consumers of the products, the prescribers,
and their patients, become uneasy about the quality and/or consistency of supply. Market
confidence in the offending company will be reduced, and the brand image will be tarnished.
The reputation of distributors may also be undermined through “guilt by association” with the
offending company. Insurance premiums for the company are likely to increase. As an overall
consequence, the jobs of all those working for the company and associated suppliers will be
less secure.
Pharmaceutical and healthcare companies should beware of persistent regulatory
noncompliance. Repeated failure to address specific topics will deeply concern regulatory
authorities. It is likely that they will escalate the severity of regulatory action taken. Company
reputation will suffer—not just with the regulatory authority concerned but also with industry,
and reputation can take a long time to reestablish. There may be fines too that need to be
considered. In exceptional circumstances, U.S. law allows “disgorgement,” whereby a
percentage of sales revenue can be taken as part of a penalty for persistent and serious
noncompliance that impacts public health.

TRENDS IN TODAY’S COMPUTING ENVIRONMENT

Computer systems share some basic hardware and software characteristics that must be
understood to appreciate the quality and compliance issues discussed in this book.
First, it is important to grasp that the proportion of hardware costs is, on the whole,
reducing as a percentage of the lifetime cost of a computer system, as illustrated in Figure 1.3.
Computer systems are now less reliant on custom (bespoke) hardware than was the case and
now largely consist of an assembly of standard components that are then configured to meet
their business objective. Standard software products are more readily available than ever
before, although these products are often customized with bespoke interfaces to enable them to
link into other computer systems. Software products are also becoming larger and more
sophisticated. With the use of ever larger and more complex software applications, the task of
maintenance has also increased, especially as many vendors of commercial software have
acquired the habit of releasing their products to market while significant numbers of known
errors still remain. The effective subsequent management of defect correction patch
installations and other code changes can be challenging.
Second, while software shares many of the same engineering tasks as hardware, it is
nevertheless different (2). The quality of hardware is highly dependent on design,
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

6 Chapter 1

Figure 1.3 Changing proportions of

software and hardware costs.

development, and manufacture. The quality of software is also highly dependent on design
and development, but its manufacturer consists merely of replication, a process whose validity
can be easily verified. For software, the hardest part is not replicating identical copies but
rather the design and development of software being copied to predetermined specifications.
Then again, software does not wear out like hardware. On the contrary, it often improves over
time as defects are discovered and corrected.
Third, another related characteristic of software is the speed and ease with which it can
be changed. Most applications today are based on configurable networked packages. Changes
are made by super users resetting configuration parameters. This characteristic often gives
users the impression that software problems can be easily corrected. This is true at one level,
but what appear simple changes to address a problem in one part of the application can also
create unwanted changes to the functionality elsewhere in the application. A similar issue
exists with custom-built (also known as bespoke) software applications. These include macros
developed for configurable packages. The complexity of custom software means that even
professional programmers can find modifications to code in one place causing unexpected and
very significant defects to mysteriously arise elsewhere in the program.
Fourth, the scope of different types of computer systems is changing. For instance, more
analytical equipment is being moved from the laboratory to be in-line or at-line with
manufacturing operations. With this move, responsibility has also changed. Typically, produc-
tion and engineering are responsible for these systems once colocated instead of QA when the
analytical equipment was located in a separate laboratory facility. Meanwhile, many process
control applications are now residing on IT platforms and as a consequence IT is responsible
rather than engineering for their upkeep. At the same time, some functionality once commonly
found as an integral part of IT applications has shifted and is now supported by IT infrastructure.
A good example is security access and password control. Many organizations now have a single
user log-on and shared password control for multiple applications, which is facilitated through
the desktop environment.
Finally, focus is now being put on the capability of an automated process rather than the
computer system itself. This emphasis promotes a better understanding and control of
business processes, which, in terms of developing, manufacturing, and supplying drug and
healthcare products, also supports the principal aim of GxP regulations to ensure product
safety, quality, and efficacy.

PROBLEMS IMPLEMENTING COMPUTER SYSTEMS

Industry Experience
The Standish Group have been reviewing trends in success rates of computer projects for
almost 15 years. Currently, about one-third of computer system projects are on-time, without
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 7

Figure 1.4 Project outcomes. Source: From Ref. 12.

overspend, with all planned functionality present, and almost one-fifth of applications are
never delivered at all (Fig. 1.4). Even if a project appears superficially to have been successful,
that does not imply that the application it delivered will be used long enough to repay the
investment. Many business cases for new software-related products require a return on
investment within three years, but in practice, a high proportion of systems have a shorter life
than this. Computer technology and business IT strategies tend to be very dynamic. In such a
changing environment, applications tend to be quickly labeled as inflexible and/or redundant,
requiring their replacement by new and more sophisticated systems long before they have
paid for themselves. And so the challenge to more robustly implement and exploit computer
systems continues.
Quality management systems (QMSs) must be mature and robust to mitigate the risk of
unsuccessful projects. Factors that critically determine the likelihood of success of computer
projects are summarized in Table 1.2. Lack of user input can almost be guaranteed to result in
an incomplete user requirement specification, a foundation of sand on which only the shakiest
edifice can be built. Those with only general skills should not be deployed on critical tasks such
as quality assurance, testing, and project management. Specific technical expertise and proven
competence are also required for handling new technology. Good team communications are
also vital. Ineffective supplier management and poor relationships with subcontractors
aggravate an already weak technical base. Software upgrades are often conceived to rectify
hardware deficiencies rather than seeking a more appropriate hardware solution. Teams often
mistakenly focus on innovation rather than on containing cost and risk.
Gaining acceptance of quality management is vital (13). Both the heart and the mind of
senior management must be behind the use and benefits of QMSs. There is more than enough
evidence around to make the case that QMSs work. Without clear leadership at an executive
level, however, it will be almost impossible to overcome statements like “We do not have time
for paperwork,” “We cannot afford the luxury of procedures,” “Too structured approach will
undermine flexibility, slow projects down, and increase costs,” and “The concept is good, and
we hope to use it some day but not just yet.”
Simply monitoring quality performance is just not adequate. The effectiveness of QMSs
should be actively managed, and performance improvement opportunities should be seized.
Business benefits should more than compensate for any investment in quality. Senior

Table 1.2 Factors That Affect Project Success Based on Standish 2006 Data

Successful project Unsuccessful project

User involvement Lack of user input

Executive management support Lack of executive support
Unrealistic schedule pressure
Clear statement of requirements Changing requirements
Proper planning Lack of project management expertise
Routine use of standard tools and infrastructure Lack of structured methodology
Assignment of competent staff Lack of resources
Technological incompetence
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

8 Chapter 1

management, system owners, project managers, and anyone else involved with computer
projects need to appreciate this. This book will help explain what needs to be done to
successfully achieve quality and compliance of computer systems in the pharmaceutical and
healthcare industries.

Regulatory Observations
There has been a steadily decreasing number of computer noncompliance observations during
regulatory inspections since the turn of the millennium. Indeed, in recent years, computer
systems–related issues are no longer even in top ten issues cited by regulators as compliance
deficiencies (14). This is a complete reversal of the trend seen in the 1990s when concern
around computer compliance was stoked by anxiety regarding electronic records, electronic
signatures, and Y2K millennium bugs.
It has been suggested that the steady decline in computer noncompliance observations is
in part due to the loss of experienced inspectors with expert knowledge in computer systems
from the major regulatory authorities. This might be true in part, but probably a bigger impact
is down to a change in approach and focus during inspections.
Computer systems rarely come under targeted and detailed inspection these days
without a specific reason (sometimes referred to as a “for cause” inspection). This is because
FDA and other regulatory authorities are adopting “quality systems”–based inspections that
are focused on examining processes rather starting from the bottom up looking at particular
SOPs, pieces of equipment, and physical systems. A recent legal challenge has affirmed that
noncompliant computer systems do not automatically compromise the safety of medical
products so long as an effective quality approach is taken (15). Similar feedback had been
given to FDA in response to a computer compliance–related Warning Letter (16).
Nowadays, there is also a general acceptance of a risk-based approach to better
understand the potential risk posed to patients and consumers. While some regulatory
authorities have been operating this way for many years, it is a much newer concept for others.
The real risk posed by computer systems may have been overestimated in the past because due
account was not taken of other controls that would detect and stop any adverse impact
reaching patients and consumers.
Finally, there is much more conscious attempt to link noncompliance observations on
computer systems back to actual regulatory requirements (sometimes referred to as predicate
rules). This has stopped personal interpretation by individual inspectors and encouraged a
much more consistent approach to identifying noncompliances.
Current noncompliance observations for computer systems tend to be made in one of
four following areas:

l Access control: lack of security to prevent unauthorized access or use by untrained

personnel
l Data integrity: lack of controls to preserve data integrity including, where appropriate,
use of audit trails for electronic records
l Change control: during projects but also perhaps more importantly during operation
and maintenance of computer systems
l General validation: missing or deficient specification and verification of computer
systems

These reflect basic good practice deficiencies. These regulatory requirements are not new,
and due diligence should ensure that they are addressed. Senior management have no excuse
not to provide sufficient resource and time to validate computer systems that need it.

LATEST INDUSTRY EXPECTATIONS

A significant shift came into effect in 2003 with the prominence given to the acceptability of
risk-based approach to quality and compliance. The aim was to improve the effectiveness and
efficiency of activities by ensuring that controls were commensurate with the risk posed to
patients. It was also hoped that this new emphasis would promote early adoption of new
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 9

Figure 1.5 Specification and verification model. Source: From Ref. 19.

technological advances (17). Early examples of specific regulatory guidance mentioning risk
management for computer systems include

l FDA Final Guidance on Scope and Application for 21 CFR Part 11 Electronic Records;
Electronic Signatures (8) and
l PIC/S Good Practices for Computerized Systems in Regulated GxP Environments (9).

Early attempts at risk management were not particularly sophisticated. Risks were often
oversimplified, and their management was based on opinion rather than scientific knowledge.
Perhaps most crucially, risk management did not typically take into consideration the ultimate
impact risks posed to patients. The need for further regulatory guidance was clear. In response,
in 2005 the ICH published the consensus expectations from U.S. FDA, European EMEA, and
Japanese regulatory authorities for quality risk management (18). The general principles and
process presented were consistent with medical device practices and directly applicable to
computer systems. Q9 was incorporated into U.S., EU, and Japanese GMPs in 2006.
The impact of taking a risk-based approach to facilities, equipment, and systems was
subsequently explored by ASTM and resulted in the publication of high-level guidance in 2007
(19). ASTM promoted the model in Figure 1.5 that emphasized risk management as occurring
throughout the life cycle and not just as a discrete activity. The work also drew attention to the
need to remove non-value-added activities (such as repeating supplier testing and creating
unnecessary documentation) that had emerged over the past decades as part of industry
custom and practice.
Although GAMP14 Guide (20) provided some basic guidance on risk management for
computer systems, it was not until 2008, when GAMP15 was published (21), that detailed
practical guidance became available, showing how to adopt and exploit a risk-based approach.
GAMP has emerged through its various editions as the unofficial consensus standard for
computer compliance between regulators, pharmaceutical companies, and suppliers around
the world. GAMP guidance covers IT applications, analytical laboratory applications, process
control systems, and IT infrastructure (networks and desktop environments) governed by GxP
regulations. The main GAMP15 Guide is complemented by a number of Good Practice Guides
providing further guidance on particular topics:

l Electronic data archiving (22)

l Testing GxP systems (23)
l Global information system and compliance (24)
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

10 Chapter 1

l IT infrastructure control and compliance (25)

l Laboratory computerized systems (26)
l Risk-based approach to electronic records and signatures (27)
l Legacy systems (28)
l Process control systems (29)
l Calibration management (30)

Another key industry update to occur in 2008 was the publication of the second edition
of the Red Apple Report first published 20 years earlier (31). Although the document is titled
for computerized systems used in nonclinical assessments, it effectively provides general
GCP/GLP guidance. The contents cover full life cycle requirements including electronic
records management but does not deal with risk management.
A number of regulatory updates are in progress to remove inadvertent dependencies that
constrain use of new technology, ensure that controls for electronic records and signatures are
practical, and facilitate the use of a risk-based approach. U.S. GMPs (21 CFR 211) for finished
pharmaceutical were updated in 2008 to allow the second person checks to be replaced by
automated verification. The U.S. regulation on electronic records and signatures (21 CFR 11) is
expected to be updated to align to FDA industry guidance issued in 2003 (32). Amendments
have also been proposed to EU GMPs to clarify requirements for handling records and
documentation and the introduction of particular requirements for electronic records (33).
A summary of regulatory authority expectations and industry guidance is presented in
appendixes 1 and 2, respectively.

NEW 21ST CENTURY PARADIGM

This book explains how to implement the new paradigm that has emerged over recent years
that will lead to a step change reduction in the cost of computer compliance while at the same
time improving compliance (35–37). The paradigm is based on a combination of reinforcing
well-established principles along with the introduction of new principles that may have been
implied in the past but never formally stated and exploited. GAMP15 endeavors to define
these principles (21), and these are summarized in Figure 1.6.
The focus of regulated organizations should be on having a fundamental understanding
of their products and the pharmaceutical science behind them. They cannot be experts in every
aspect of their operations including the use of computer systems. QMSs should exist to govern
supply chain activities for medicinal products and suppliers. The management and control of
these activities can be scaled using science-based risk management appropriate to the
medicinal product concerned. Regulated organizations need to leverage supplier expertise in

Figure 1.6 New 21st century paradigm. Source: From Ref. 21.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 11

the products and services used. After all, the focus of supplier organizations is to have a
fundamental understanding of the computer systems and associated services they offer to
customers.

Process and Product Understanding

Efforts to ensure a computer system is fit for its intended purpose should focus on criticality to
patient/consumer safety, product quality, and data integrity. An understanding of the process
being automated is fundamental to the determining system requirements. Manufacturing
this will involve the identification of critical quality attributes (CQAs) and critical process
parameters (CPPs). It is only through this understanding that we can have complete
confidence in identifying critical functionality and data. Incomplete process understanding
will hinder effective and efficient compliance. Less critical computer systems, or aspects of
those systems, will have to be treated as critical (and incur otherwise unnecessary attention)
because it is not possible to distinguish between them from more critical systems.
The GAMP15 Guide suggests that effort is focused on computer systems that support
the following critical processes (21):

l Generate, manipulate, or control data supporting regulatory submissions

l Control critical parameters for preclinical and clinical, development, and manufactur-
ing
l Control or provide information for product release
l Control information required in case of product recall
l Control adverse event or complaint handling
l Support pharmacovigilence

It is important to appreciate the context in which a computer system is automating a

business process. For instance, manufacturing control systems are more critical in sterile
manufacturing compared with production of topical ointments. Both are important in their
own right, but one has a much greater potential patient impact.

Science-Based Quality Risk Management

Quality risk management should be based on clear understanding and potential impact on
patient safety, product quality, and data integrity. Risks are relative and very difficult to
quantify in an absolute sense. High risks might be defined as having the potential for severe
harm to users of medicinal products (e.g., death, hospitalization, long-term effects impeding
daily life). Low risks might be defined as having potential for inconsequential impact on
patient safety. A computer system cannot pose a greater risk than the business process being
automated.
Risk assessments need to use structured and repeatable processes that are data driven. It
is no longer acceptable to just organize a team or committee meeting to discuss and announce a
risk assessment outcome. Such meetings were acceptable but could not be relied on to
reproduce the same decisions. Reliance on good judgement in the absence of any data is not
acceptable.
Risk management must reduce risks to an acceptable level. Quantitative and qualitative
techniques may be used. It is important to realize that it may not be possible or practical to
eliminate a risk. This is quite acceptable so long as the efficacy, safety, and quality of medicinal
products are not compromised. Implemented controls must be monitored to verify their
sustained effectiveness.

Life Cycle Approach Within Quality Management System

The complete life cycle of a computer system from conception to system retirement should be
subject to management and control. It is well known that procedures must be established to
ensure that a consistent approach is taken. Implied, but not explicitly stated before, is the
expectation that these procedures exist within a QMS. A separate QMS should exist for
computer systems, rather a single QMS should exist, which covers all activities of an
organization including the development and use of computer systems.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

12 Chapter 1

The QMS should promote a holistic approach to compliance. An integrated approach

should be taken to computer systems with the equipment and facilities they manage and
control. Common processes such as change control and CAPA should not have separate
procedures for computer systems but rather be governed by shared procedures. Pharmaceu-
tical and healthcare companies should also ensure that their QMS expects and aligns to a
complementary QMS in use within their supplier organizations.
A healthy QMS must promote continuous improvement. For computer systems, this is
achieved through determining root cause of incidents and deviations (with emphasis on using
data to support investigations), implementing corrective and preventative actions, and
conducting regular periodic reviews. Improvements can only be implemented under suitable
change management.

Scalable Activities
Compliance activities through a computer system life cycle should be scaled where it makes
sense to stop otherwise redundant work. The degree of scaling will depend on the attributes of
an individual computer system.
Scaling has conventionally almost always been limited to just considering system
novelty. However, there are several other important factors worthy of consideration. Key
attributes to take account of include

l Impact of system and its data on quality, safety, and efficacy of medicinal product
taking into account severity of potential harm to patient/consumer that could result,
l System complexity (size and architecture),
l System novelty (degree of standardization and number of other organizations actively
using the system), and
l Supplier capability (project management, technical, and level of reliance on temporary
staff and third-party organizations).

Scaling may not always be practical. The time and effort to determine and implement
scaling may outweigh the benefits of just validating the whole system to a higher-than-needed
level for simple computer systems. No adverse regulatory comment will be received in these
situations provided the computer systems are compliant.

Leveraging Supplier Involvement

Pharmaceutical and healthcare companies should recognize and exploit the capability of
supplier organizations. There is no need to duplicate supplier activities and documentation
unless they fall short of basic good practice standards.
On the whole, there has been insufficient recognition of supplier competence despite
industry guidance on the topic. This has resulted in pharmaceutical and healthcare companies
unnecessarily rewriting system development documents provided by the supplier and
repeating verification activities conducted by the supplier. The reason given is typically
founded on the perceived need for records to conform to their document conventions (e.g.,
layout, format, style, and approvals).
Planning must clearly define the respective responsibilities of pharmaceutical and
healthcare companies and their suppliers and how these responsibilities fit together into an
integrated approach. The degree of reliance on supplier activities and documentation must be
justified. This is usually done by leveraging the outcome of supplier assessments, which may
include supplier audits depending on risk.
Pharmaceutical and healthcare companies cannot abdicate their accountability for
compliance. In additional formal contracts, some form of monitoring supplier performance is
expected. Integrated plans, shared responsibility for risk mitigation, and common escalation
processes for issues will all improve the effectiveness of customer-supplier relationships. If
activities and documents are substandard, then the issues must be resolved in a timely
manner. It may be necessary in extreme circumstances to replace suppliers and ensure that
they are not used again. Incompetent suppliers should, of course, not be selected in the first
place. The compliance of a computer system must not be compromised.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 13

Subject Matter Experts

Roles should be performed by those with appropriate skills, training, and experience. In this
context, individuals are referred to as subject matter experts (SMEs) because of their
knowledge and capabilities. Departmental responsibilities should not take precedence over the
capabilities of staff to perform various roles. The only exception is the quality unit, which,
according to regulatory requirements, must provide impartial oversight of compliance
activities.
Too often in the past, roles have been aligned to departments even if the staff in those
departments were not capable of fulfilling those duties. The same situation often existed in
relation to suppliers. Suppliers can perform the role of SMEs.

Terminology
The choice of terminology to describe these principles must not interfere with effective
implementation of these principles. While it is up to individual companies to agree to their
own lexicon, it is important to recognize the benefits of using industry standard terminology to
promote common understanding between pharmaceutical companies, suppliers, and regula-
tory authorities.
This book uses established regulatory definitions for computer validation that are
consistent with the key principles behind the 21st century paradigm. GAMP15 has introduced
a framework of specification and verification to act as umbrella terms for the various activities
involved in defining a computerized system and the various review and testing activities
involved in qualifying a computerized system as fit for its intended purpose. This framework
aligns both with established use of qualification and validation terminology and also the use of
specification and verification championed by ASTM (19).

GOOD PRACTICE
Quality Assurance
The achievement of quality in a product should be based on the adoption of good practices.
Neither these, in relation to computer systems or not, nor the concept of quality were invented
by the pharmaceutical and healthcare industry. Good computer practices existed long before
pharmaceutical and healthcare industry regulations required their application. The basic
underlying premise is that quality cannot be tested into computer systems once developed. On
the contrary, it must be built in right from the very start. Defects are much cheaper to correct
during the early stages of system development compared to leaving them to be weeded out
just before release or, perish the thought, by disaffected customers. The additional cost
generated by ensuring that the system is sound at every stage in its development from
conception to testing is far less than the cost and effort of fixing the computer system
afterward, not forgetting the hidden losses suffered through customer disaffection. So do not
wait until the end of the project to put things right!
Sir John Harvey-Jones, Chairman of the former industrial chemicals giant ICI, summed
this up pithily, “The nice thing about not planning is that failure then comes as a complete
surprise.” This said, it is important to appreciate that planning does not come naturally to
many people, and the temptation to jump into code development before the groundwork of
properly defining requirements has been completed often proves irresistible. This tendency
can be exacerbated by managers expecting too much too soon. A degree of self-discipline is
required as shortcutting the quality process will almost certainly wreak havoc later on.

Duty of Care
Like other financial governing bodies around the world, the London Stock Exchange requires
pharmaceutical and healthcare companies to comply with laws and regulations including
those dealing with GxP and consumer protection (38). Collectively, these are often portrayed as
the exercise of a “duty of care” through operating in a responsible and reasonable manner.
This duty of care embraces the use of computer systems because of the crucial role they play in
determining the quality of drug and healthcare products. Failure in this duty of care implies, at
best, negligence or incompetence; at worst, it may infer fraud and may subject senior personnel
to prosecution and legal penalty. However, the net of responsibility falls wider than the
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

14 Chapter 1

pharmaceutical or healthcare company involved. It may jointly or individually include

equipment hardware suppliers, software suppliers, system integrators, and system users.
Notwithstanding this, GxP regulators hold pharmaceutical and healthcare companies solely
accountable for GxP compliance despite the unavoidable supplier dependencies. Examples of
matters where such accountability may be cited include deficient design, defective construc-
tion, weak or inadequate inspection, incomplete, ambiguous, or confusing user instructions
provided by supplier, software installed on an inappropriate hardware platform, inappropri-
ate use of a system, or neglect of operational instructions.

Buyer Beware
Regulatory authorities do not approve computer systems, neither do they agency certify
suppliers or consultants. Pharmaceutical and healthcare companies have always been and
remain accountable for compliance of the computer systems they use. Audits and
certifications, however rigorously applied and conscientiously implemented, are no substitutes
for validation.

WIDER APPLICABILITY
Validation is recommended for all computer, control, and laboratory systems that have the
potential to seriously affect safety, health, and environmental (SHE) conformance and
adherence to other regulatory requirements (e.g., Data Protection Act and financial control
legislation such as Sarbanes-Oxley).

REFERENCES
1. FDA. General Principles of Validation. Rockville, MD: Food and Drug Administration, Center for
Drug Evaluation and Research, 1987.
2. FDA. General Principles for Software Validation. Final Guidance for Industry and FDA Staff, Food
and Drug Administration, Centre for Devices and Radiological Health, 2002.
3. FDA. Guide to Inspection of Computerised Systems in Drug Processing. Technical Report, Reference
Materials and Training Aids for Investigators. Rockville, MD: Food and Drug Administration, 1983.
4. European Union. EU GMP Annex 11 Computerised Systems. Guide to Good Manufacturing Practice
for EU Directive 2003/94/EC, Community Code Relating to Medicinal Products for Human Use, Vol
4, 2003.
5. Japanese Ministry of Health and Welfare. Guideline on Control of Computerised Systems in Drug
Manufacturing. Manual for Control of Computerised Systems in GMP, Audit Manual for
Manufacturers of Pharmaceutical Product with Computer Systems, 1993.
6. FDA. Preamble to Electronic Signatures and Electronic Records. Code of Federal Regulation Title 21,
Part 11. Rockville, MD: Food and Drug Administration, 1997.
7. FDA. 21 CFR Part 11 Electronic Records; Electronic Signatures—Scope and Application. Guidance for
Industry. Rockville, MD: Food and Drug Administration, 2003.
8. Pharmaceutical Inspection Co-operation Scheme. Good Practices for Computerised Systems in
Regulated GxP Environments. Pharmaceutical Inspection Convention, PI 011-1, Geneva, 2003.
9. Japanese Pharmaceutical Manufacturers Association. Guideline for the Application of ERES in
Production Control and Quality Control for Human Drug Manufacturing, 2002.
10. Wingate GAS. Computer Systems Validation: Quality Assurance, Risk Management and Regulatory
Compliance for Pharmaceutical and Healthcare Companies. Boca Raton, FL: Interpharm Press, 2003.
11. Faiella C. Pharmaceutical Industry Report: the Next Pharmaceutical Agenda. Ernst & Young, 2002.
12. Standish Group. Sixth Chaos Report. Available at: www.standishgroup.com, 2006.
13. Bennatan EM. On Time, Within Budget: Software Project Management Practices and Techniques.
New York: Wiley Press, 2000.
14. BioQuality. US Versus EU Inspection Results. 2008; 13(1).
15. BioQuality. Validation and Compliant Handling Court Decision Allows Increased Flexibility. 2005;
10(11).
16. Wingate GAS. Computer Compliance: Expectations & Experiences. FDA Process Analytical
Technologies Sub-Committee Meeting, Washington, October 23, 2002.
17. FDA. Pharmaceutical CGMPs for the 21st Century: a Risk-Based Approach. Rockville, MD: Food and
Drug Administration, 2004.
18. ICH. Quality Risk Management. Q9 Document, Technical Requirements for Registration of
Pharmaceuticals for Human Use, International Conference on Harmonisation (ICH). Available at:
www.ich.org, 2005.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 15

19. ASTM. E2500-07 Standard Guide for Specification, Design and Verification of Pharmaceutical and
Biopharmaceutical Manufacturing Systems and Equipment. American Society for Testing and
Materials, 2007.
20. ISPE. GAMP1 Guide for Validation of Automated Systems (known as GAMP14), Tampa, FL:
International Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2001.
21. ISPE. GAMP15: Risk-Based Approach to Compliant GxP Computerised Systems. Tampa, FL:
International Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2008.
22. ISPE. GAMP1 Good Practice Guide: Electronic Data Archiving. Tampa, FL: International Society for
Pharmaceutical Engineering. Available at: www.ispe.org, 2007.
23. ISPE. GAMP1 Good Practice Guide: Testing GxP Systems. Tampa, FL: International Society for
Pharmaceutical Engineering. Available at: www.ispe.org, 2005.
24. ISPE. GAMP1 Good Practice Guide: Global Information System and Compliance. Tampa, FL:
International Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2005.
25. ISPE. GAMP1 Good Practice Guide: IT Infrastructure Control and Compliance. Tampa, FL:
International Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2005.
26. ISPE. GAMP1 Good Practice Guide: Validation of Laboratory Computerized Systems. Tampa, FL:
International Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2005.
27. ISPE. GAMP1 Good Practice Guide: Risk-Based Approach to Electronic Records and Signatures.
Tampa, FL: International Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2005.
28. ISPE. GAMP1 Good Practice Guide: Legacy Systems. Tampa, FL: International Society for
Pharmaceutical Engineering. Available at: www.ispe.org, 2003.
29. ISPE. GAMP1 Good Practice Guide: Validation of Process Control Systems. Tampa, FL: International
Society for Pharmaceutical Engineering. Available at: www.ispe.org, 2003.
30. ISPE. GAMP1 Good Practice Guide: Calibration Management. Tampa, FL: International Society for
Pharmaceutical Engineering. Available at: www.ispe.org, 2001.
31. DIA. Computerized Systems Used in Non-Clinical Safety Assessment: Current Concepts in Validation
and Compliance (known as Red Apple II), published by Drug Information Association, 2008.
32. FDA. 21 CFR Part 211 Supplementary Information—Code of Federal Regulation. Rockville, MD: Food
and Drug Administration, 2008.
33. European Commission. Draft Annex 11—Computerised Systems (EU Guideline to Good Manufactur-
ing Practices for Medicinal Products for Human and Veterinary Use), Public Consultation Document,
Brussels, April 2008.
34. Wingate GAS. GAMP15 Drivers, Objectives and Benefits. Launch of GAMP15, ISPE US Conference
on Manufacturing Excellence, Florida, February 25–28, 2008.
35. Selby D. Validating Complex Computer Systems. ISPE Turkey Annual Meeting, Istanbul, March 28,
2008.
36. Daw E. Case Study—Effective & Efficient Compliance. Launch of GAMP15, ISPE European
Conference on Innovation, Copenhagen, Denmark, April 7–10, 2008.
37. The Institute of Chartered Accountants in England and Wales. Internal Control: Guidance for
Directors on the Combined Code. ISBN 1-84152-010-1, 1999.
38. ISO. ISO 90003: Software Engineering—Guidelines for the Application of ISO 9001:2004 to Computer
Software. Geneva, Switzerland: International Organization for Standardization, 2004.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

16 Chapter 1
Appendix 1: Body of Knowledge: Regulatory Authority Expectations
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0001_O.3d] [21/1/010/13:54:7] [1–17]

Introduction 17
Appendix 2: Body of Knowledge: Industry Guidance
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

2 Organization and Management

INTRODUCTION
This chapter suggests an approach to the organization and management of computer
compliance that satisfies the regulatory accountabilities. However, in presenting this offering,
we do not purport to suggest that this is the only acceptable approach. The needs of each
pharmaceutical and healthcare company will vary since these depend on many different
factors, including company culture, how much work there is to do, and the availability of
suitably skilled company and contract staff.

ORGANIZATIONAL RESPONSIBILITIES
Structure and Management
The organizational structures in the enterprise, whatever its size, must be defined and
documented. GxP regulatory authorities expect to see an organizational chart with the various
roles of different departments clearly specified. Of critical importance in these is the position of
quality staff whose role and reporting relationships must not compromise their ability to
discharge their responsibilities including the escalation and resolution of quality and
compliance issues. Quality departments are typically independent of other functions to
ensure impartiality. This will prove crucial if things go awry later on.
Senior management is responsible for ensuring that personnel assigned to compliance work
are competent to fulfill their role and for arranging any supplementary training requirements.
Evidence that individuals have sufficient education and experience to enable them to undertake
their assigned functions will need to be collected and kept ready for presentation when required.
Role descriptions for individuals should be prepared and kept up-to-date.
It is not acceptable for senior managers to rely on individuals to fulfill their role without
management support. Individuals must be given sufficient authority to fulfill their duties.
Duties may be delegated to designated deputies with satisfactory levels of competence. It is
recommended that deputies are assigned for critical roles so that working practices are not
hamstrung when key staffs are absent.

Quality and Compliance Roles

Pharmaceutical and healthcare companies should appoint a senior management representative
with specific responsibility for ensuring that computer compliance requirements are
implemented and maintained. This individual, who is often graded as a Director, must
wholeheartedly champion the cause of GxP. The authority and responsibility of this senior
position should be clearly defined and recorded.
It is very important that this senior manager has the authority to block the release of drug
product on the grounds of noncompliance, since this can compromise the quality of drug and
healthcare products. Without such a level of authority, the individual will have to rely solely
on his or her powers of personal persuasion with others, who may themselves be under acute
production or sales pressures to permit the release of drug product. Bitter experience shows
that this will seldom be enough. As a result, it has long been taken for granted in the industry
that quality managers must have the authority to place an embargo on drug products that they
deem to be substandard. The senior manager responsible for GxP must possess a similar level
of empowerment; many companies achieve this by placing their GxP personnel within their
quality control/assurance management hierarchy.
The senior manager responsible for regulatory compliance is expected to recruit
appropriately qualified and experienced staff and ensure that the work conducted is properly
and effectively carried out (1). In many organizations, the senior manager responsible for GxP
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 19

may also have other duties. The company must formally acknowledge and concede that these
other duties do not excuse or relieve his or her responsibility for compliance to the GxP regulatory
authorities. In the phrase forever associated with President Harry S. Truman, the buck stops here!

Sufficient Resources
Senior management must ensure that an adequate number of personnel are available with the
necessary qualifications and practical experiences appropriate to their responsibilities.
Insufficient personnel will attract regulatory criticism, since this is likely to lead to individuals
being burdened with excessive responsibilities and workloads and subjected to inordinate
pressure. The consequential risk is that quality will then be compromised in some way. In the
worst case situation, senior company executives are subject to potential prosecution if they fail
to meet such regulatory expectations (2). Blaming a lack of competent personnel on corporate
challenge for minimum staffing levels or reduced training budgets will not be accepted by the
regulatory authorities for whom public health comes above company profits.

Governance
The expected role of senior managers is defined by the ISO 9001 standard, which states that
management shall

define and document [the company’s] policy and objectives for, and commitment
to, quality and ensure that this policy is understood, implemented and maintained
at all levels in the organization. (2)

While this is useful, more practical guidance is available. An interpretation of the ISO
requirements based on work by Teri Stokes is presented below (3).

1. Establish a work group to define company policy, including a statement of

commitment to such policies and objectives, and any associated company plans.
2. Establish a company steering committee to set the company computer compliance
strategy, approve the compliance policy, provide oversight, and agree funding models.
3. Establish local site steering committees to prepare an inventory of systems, set
priorities, establish site master plans, approve procedures, assign resources, and
monitor progress.
4. Develop an awareness/education program for all senior managers and their employees.
5. Monitor progress, priorities, resources, and funding against company objectives and
strategy.

Company steering committees should be multidisciplinary teams with representatives

from research, production, engineering, quality control/assurance, and business support. Site
steering committees should also be multidisciplined with representatives from technical
operations, IT, laboratory management, engineering, and quality. Members of both steering
committees and supporting work groups should be trained via internal or external courses so
that they gain an understanding of the basic principles of computer compliance. Alternatively,
members might attend external conference or training event where they could also meet
practitioners from other companies. Major conferences are regularly organized by Interna-
tional Society of Pharmaceutical Engineering (ISPE), Parenteral Drug Association (PDA), and
Institute of Validation Technology (IVT) throughout Europe and the United States. External
consultants with specialist knowledge and experience may also be engaged to support the
steering committees and work groups, perhaps assisting with internal training courses.

Recent Inspection Findings

Inadequate organizational structure to ensure quality system requirements met (Food

and Drug Administration (FDA) 483, 2002)
Failure to have a quality control unit adequate to perform its functions and
responsibilities, as required by 21 CFR 211.22, as demonstrated by the number and
type of inspectional observations (FDA Warning Letter, 2002)
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

20 Chapter 2

No standard operating procedure (SOP) delineating QA oversight duties and

responsibility for computer systems, networks, and associated servers/workstations
(FDA 483, 2006)

COMPLIANCE STRATEGY
Organizational Capability
From the outset the aim must be to achieve compliance in a manner as cost-effective as
practicable. Many pharmaceutical companies who have rushed into the remediation of
computer systems have subsequently discovered to their cost that inefficient compliance
programs are hugely expensive, involving much more work than is really necessary.
Figure 2.1 illustrates three basic compliance strategies by comparing the cost associated
with compliance (prospective validation) against the cost associated with noncompliance (the
combined impact of retrospective validation and business disruption).
Point A in the graph denotes the breakeven point where the cost of noncompliance
equals the cost of compliance. This may appear to indicate the ideal amount of compliance
effort, an effort that just delivers compliance but constrains cost by going no further. Is this
really the ideal that should be aimed at? Compliance requirements enforced by the various
regulatory authorities are interpretative, not prescriptive. Further, regulatory inspections are
never exhaustive; practical limitations of time and resources mean that inspections can only
ever examine a proportion of a company’s operation. Therefore, they cannot ensure the
exposure of all noncompliances. Assessing where point A really is thus inspired guesswork,
something of an art rather than a science. Aiming at point A but missing it will mean either that
compliance is not achieved or that money has been wasted! An alternative strategy that is often
adopted after a serious noncompliance has been revealed by a regulatory authority is to aim
for point C. This point represents an exhaustive (risk-averse) compliance effort in a climate of
zero tolerance of any regulatory criticism, however minor. The cost that this point implies is
exorbitant and adding little value to the business or indeed to the likelihood of regulatory
compliance—most of it is unnecessary overhead. It is useful, then, to consider a third
compliance strategy, the middle way, whereby a more balanced approach to compliance is
adopted. It has been claimed that this type of approach can lead to 40% to 50% cost savings
when compared with those incurred at point C while still maintaining a sustainable level of
regulatory compliance (4). Point B can be viewed as a common sense approach, erring on the side
of caution by being more conservative than that represented by point A. There is a broad
consensus on the wisdom of setting compliance effort at this point. Its precise location can only
be determined by surveying industry practice and monitoring regulatory expectations.
Benchmark exercises are not readily available, so a more ad hoc collation of information
derived from consultants, new recruits, industry associations, and informal regulatory contacts
is often used. As long as the quality of information is adequate, not being tainted by hidden
political agendas, it should be possible to arrive at point B relatively easily.

Figure 2.1 Compliance strategy.

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 21

Members of the group establishing a compliance strategy must appreciate the

implications of their policy on working practices. For instance, point B should not be
determined solely on the basis of the cost of compliance but also on its effectiveness, by
examining the standards and practices to be employed. Inefficient practice can inflate project
overhead costs by up to 30%. This could entirely undermine the potential cost savings
associated with adopting a compliance strategy based on point B.

Outsourcing and Offshore Partnerships

The outsourcing of systems and services (irrespective of whether it is onshore or offshore) does
not change the basic regulatory expectations for computer compliance. Senior management
may have an expectation that compliance becomes simpler and less likely to come under
inspection. Whether or not this is true is subject to debate. What is clear, however, is that the
capability of the outsource partner in terms of appreciating regulatory expectations and
implementing robust quality practices will have a significant impact on the level of
management and control required by the pharmaceutical company to establish and maintain
a state of compliance. The same basic economic model still holds.

POLICY AND PROCEDURES

Establishing Policy Framework
Compliance policies vary greatly between different companies. There are no set rules
governing their content or structure, but it will typically cover the following:

l A definition of the overall principles to achieve and sustain compliance

l The scope of policy application
l A statement of commitment
l A definition of who is to be responsible
l A glossary defining the terminology to be used

Both prospective and retrospective validation must be considered for new and existing
computer systems, respectively. Figure 2.2 outlines the relationship between prospective and
retrospective validation. New systems must be authorized for use, while the continuing use of
existing systems must be justified. Once validation is achieved, it must be maintained despite
any changes that are made to it. All such changes must be scrutinized through change control
and the revised system specifically authorized for use. Periodic reviews must also be
performed to ascertain whether an overall revalidation is required, as a result of cumulative
system changes over time, regulatory developments, or organizational changes that impact
company standards. If the use of a computer system cannot be justified, then it should be
decommissioned through a premature retirement. Computer systems will require decom-
missioning at some time anyway once they reach the end of their useful life.

Figure 2.2 Relationship between

prospective and retrospective valida-
tion.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

22 Chapter 2

Key principles for computer systems compliance policy are presented in Appendix 2.A.
These principles have been prepared to address the basic requirements of the following
regulatory authorities:

l U.S. FDA
l U.K. Medicines Healthcare products Regulatory Authority (MHRA)
l Japanese Ministry of Health, Labour and Welfare (MHLW)
l Australian Therapeutics Goods Administration (TGA).

Experience has shown that a clear, concise compliance policy for computer systems can
be achieved within a 5- to 10-page document and produced in a couple of man-months.
Typically, most of the effort is spent in consultative meetings to secure a consensus on the
content of the policy that should, in any event, confine itself to high-level statements of
principle. It should, by its nature, be relatively stable. Nevertheless, it should be periodically
reviewed and kept up-to-date.

Standard Operating Procedures

SOPs should be drafted by experienced practitioners who have experience in developing such
procedures. The number of SOPs that are required will depend on organizational complexity
and the number of the systems that need to be addressed. It may be necessary to hire an
external consultant to fulfill this role. He or she should join a team of operational procedure
end users as a ghostwriter to aid the development of the procedures. The aim here is not to
impose a set of generic procedures that might be in some way foreign to the organization. The
goal is rather to tailor the end user’s current working practices into compliant procedures with
a minimum of change. The end user’s personal involvement should ensure that they and their
colleagues will readily adopt the procedures without resentment.
About 20 to 25 generic procedures will be needed to cover the life cycle for a computer
system. The following list is based on GAMP15 (5).

Management
l Validation planning
l Supplier audit
l Risk management
l Design review and traceability analysis
l Quality planning
l Validation reporting
l Change control (project and operational)
l Configuration management
l Document management

Project
l User requirements specification (URS)
l Functional specification
l Hardware design specification
l Software design specification
l Software controls
l Testing (qualification/verification)

Operation
l Periodic review
l Service level agreements
l Security
l Performance monitoring
l Record retention, archive, and retrieval
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 23

l Backup and recovery

l Business continuity planning
l Decommissioning

Managing electronic records and electronic signatures may be handled with separate
SOPs or integrated into the above. An abridged set of procedures will be appropriate for small
systems, but supplementary procedures will be needed for larger ones.
Management must approve procedures and any subsequent changes made to them.
Approval signatures will be required from at least two individuals representing a quality and
technical perspective. Management must then ensure that any deviation from these procedures
is properly authorized and documented. Deviations will often be associated with corrective
actions arising from internal audit findings; these must also be documented together with the
evidence that demonstrates their resolution.
The effort to produce these procedures may require about 40 days from an experienced
consultant. Use should be made of industry guidance when developing procedures, for
example, GAMP15 example procedures and IEEE standards. Where existing procedures are
being revised to achieve compliance, this estimate of effort could be reduced by about two
days per procedure. As recommended above, this should be supplemented with about 20 days
of effort across all the procedures, shared among a team of end users. The individuals should
contain the core users who are involved in all the procedures, to ensure consistency. Other end
users on the team, however, can be seconded for the development of particular procedures in
which they have a specific interest, or can contribute a particular skill or competence. For
instance, an end user quality representative may wish to be seconded for the development of
the security procedure.
To make the preparation of these procedures easier, many organizations are developing
document templates and tools to assist practitioners prepare, review, and approve documents
in a rapid, quality-conscious fashion.
Many pharmaceutical and healthcare companies find it beneficial to also tailor particular
sets of procedures to different types of systems. This may also help ownership and adoption
since different types of systems are usually supported by QA/laboratory, engineering, and IT
departmental functions. From a technical standpoint too, it is very difficult to make a single set
of procedures easy to use while providing a practical level of detail to address the various
technical characteristics of different types of computer systems—one size does not readily fit
all. As a consequence, typically, there might be four sets of procedures.

l Laboratory applications (e.g., analytical, measurement)

l Control systems (e.g., PLC, SCADA, DCS)
l IT systems (e.g., ERP, MRP II, LIMS, EDMS)
l Computer network infrastructure (e.g., servers, networks, clients)

An additional set for desktop applications (e.g., spreadsheets, databases, and web
applications) may be needed, but more typically, these are included within the general scope of
IT systems.
There are inevitable interfaces between the application areas of the various sets of
procedures and the computer systems to which they apply, as indicated in Figure 2.3. Client-
server technology is typically the deciding factor in determining whether control system and
laboratory application projects would be better served by IT system procedures. Another
example might be that robotic systems used to automate laboratories would be better served
by control system procedures.

Recent Inspection Findings

No evidence that the quality policy has been implemented, understood, and maintained
by all levels of the organization (FDA Warning Letter, 2001)
Quality system procedures not implemented (FDA 483, 2002)
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

24 Chapter 2

Figure 2.3 Mapping procedures to

computer systems.

COMPUTER SYSTEMS INVENTORY

An inventory of computer systems should exist and may be requested during regulatory
inspections. All computer systems that are subject to GxP regulatory compliance requirements
should be listed. When determining whether or not a computer system has a GxP impact, it is
useful to reflect on the advice given by Sam Clark, a former FDA investigator: “If it looks like a
duck, flies like a duck, and sounds like a duck, then it’s probably a duck”! In other words, use
your common sense (Fig. 2.4).
It is important to consider the effort to maintain increasing numbers of fields when
designing the system inventory. The greater the number of fields the more maintenance will be
required, and the harder it will prove to keep it up-to-date. Remember that there may be many
thousands of computer systems in use on larger pharmaceutical and healthcare manufacturing
sites.
The inventory should be periodically reviewed and approved by a QA representative.
When reviewing the inventory, it is important to remember that the compliance status will also
have to be periodically checked to determine whether revalidation is required. Revalidation
may be triggered by cumulative effect of changes made to the computer system or by new
regulatory requirements.

Recent Inspection Findings

There is no list of all systems that are subject to validation (FDA 483, 2004).
Unvalidated systems have not been identified (FDA 483, 2004).

SYSTEM LIFE CYCLE MANAGEMENT

The management of compliance can be considered as a cyclical process, as shown in Figure 2.5.
The cycle begins with GxP assessments surveying the compliance requirements of computer
systems in readiness for preparing validation (master) plans. Supplier assessments consider
the capabilities of suppliers providing computer systems and associated services. Compliance
activities are then conducted according to any prevailing priorities. Once validation is
completed for individual computer systems, its operational compliance must be maintained.
Throughout the compliance management process, there should be formal opportunities
to review practices. The status of compliance work is likely to change; some existing systems
may be decommissioned, new systems may be planned, and the priorities on the current
inventory work may vary because of changing company needs. Compliance policy and
supporting procedures may change as a result of new regulatory requirements or feedback
from project experience.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 25

Figure 2.4 Determining a validation requirement.

Figure 2.5 Compliance management.

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

26 Chapter 2

Getting Started
There are two main obstacles to be surmounted here. One is a lack of compliance experience, and
the other, an absence of focus and determination. Weak compliance experience is often
characterized by questions like “Why are we doing this anyway?” and “What are the
fundamental principles we should follow?” Education and training, and managing the learning
curve are both key issues. Managers and sponsors, as well as practitioners, need a practical
appreciation of compliance requirements (trends, constraints, areas of flexibility, and benefits). It
must be understood that initial work will require more effort, because practitioners will not be
familiar with the new way of working. It is wise to avoid large work packages as the starting
point for adopting the new quality-assured mode of working, since the scale of inefficiency might
shock an organization, is tempting it to abandon the quality-assured approach altogether. It is
better to begin with smaller work packages and watch costs reduce as practitioners improve their
understanding and efficiency. The learning curve will eventually flatten out to a plateau.
However, herein lies another danger. If key staffs move on and leaning has not been captured in
the corporate memory (policies, procedures, guidance, training, and succession planning),
learning and efficiency will be lost. Hopefully avoiding these pitfalls, there is still a need to pace
the introduction of the new way of working in case progress is not forthcoming. The best course is
to build on success and extend the new ways of working based on a proven track record.

Risk Management
Risk management is very important if appropriate resources are to be deployed in a timely
fashion to mitigate or reduce the potential effect of identified risks. It is recommended that a
risk map be produced showing where computer systems are used to support the various
process streams of operational activity.
Determining which operational aspects are most critical requires an understanding of the
potential impact on drug or healthcare product safety, quality, and efficacy. The Canadian
Health Products and Food Branch Inspectorate have already identified a number of high-risk
issues that are likely to result in noncompliant drug product and present an immediate or
latent public health risk (6). A similar identification of high-risk issues can be achieved by
applying International Conference on Harmonisation (ICH) Q9 regulatory guidance (7). These
high-risk issues are applied here to computer systems and aligned to the six operational areas
identified by FDA quality system-based approach (8).

Quality Systems
l Document management

l SOP administration

l Security access controls (e.g., user profiles and password management)

l Change control records

l Customer complaints

l Adverse event reporting

l Review/audit/corrective actions management

l Training records

Facilities and Equipment Systems

l HVAC controls and alarm handling

l Critical equipment and instrumentation (calibration and maintenance)

l Change control records

Materials Systems
l Traceability of material handling

l Raw material inspection/testing/quarantine management

l Storage conditions

l Containers usage and cleaning management

l Distribution records and recall management

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 27

Production Systems
l Recipe/formulation management

l Batch manufacturing instruction and records

l In-process testing

l Yield calculation

l Purified water

l Aseptic filling

Packaging and Labeling Systems

l Labeling information

Laboratory Control Systems

l QC raw data
l Stability testing
l Sterility testing
l QC analytical results
l Quality disposition
l Out of specification investigations

Workflow analysis using flowcharts marking critical decision points and information
flows is an effective way of pictorially mapping risks. The use of computer systems should be
identified on the maps. Other relevant supplementary information can be added as deemed
appropriate. A balance has to be struck on the amount of information included so that the
process can be mapped in a manageable number of pages. Producing the risk map on A3 size
paper can help given a better overview.
The rigor of validation for computer systems supporting these critical operational aspects
of the processes should take account of their composite custom (bespoke) software,
commercial off-the-shelf (COTS) software, and supporting computer network infrastructure.
The risk map and supporting rationales will form the basis of validation master plans that are
discussed in more detail later in this book.

Life Cycle Approach

The life cycle approach has attracted broad acceptance across the pharmaceutical and
healthcare industry and can be refined to meet the needs of particular applications. Different
organizations use variants of the life cycle, but the methodology of dividing a life cycle into
phases remains the same. For instance, some companies develop the subphases that are
indicated in the phase descriptions above as distinct phases in their own right. The specific life
cycle model chosen does not really matter. Its constituent phases must, however, be clearly
defined in advance, with entry and exit criteria for each phase, and appropriate verification
procedures to ensure the controlled completion of constituent phases.
Figure 2.6 presents a set of life cycle phases that summarizing the approach typically
used within the pharmaceutical and healthcare industry. Life cycle phases may be known by
alternative names in different organizations. There is no standard glossary throughout the
industry relating to naming conventions or groupings of phases. It is important, however, that
all the activities covered by this chapter are included in any alternative scheme.
The life cycle is consistent with guidance provided by the Australian, European,
Japanese, and U.S. GxP regulatory authorities (9–13). It is also consistent with guidance
provided by the GAMP15 and DIA Red Apple (5,14).
The steps in the life cycle are not necessarily executed in the order indicated. Rather, the
steps are usually executed as an iterative process, where various functions may be carried out
concurrently. If necessary, steps may be repeated. For instance, the validation master plan may
be developed after or concurrently with the URS rather than before as indicated. Equally, a
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

28 Chapter 2

Figure 2.6 Computer systems life cycle.

supplier selection often involves a series of steps beyond assessment to include corrective
actions that may not be complete until well into the project.
Some of the steps in the life cycle will not be needed in some projects. For instance, the
use of preferred suppliers for software and hardware products or services removes the need
for repeated supplier appraisal and selection.
For systems that have been in use for some time, a compilation and review of
documentation, and a review of historical data supplemented by a series of functional tests
may be adequate to demonstrate that the system performs its intended function. Evidence that
the software is structurally sound may be provided by a formal evaluation of the supplier’s
software development and testing procedures and by an analysis of historical, system-related
data. Where historical, system-related data is not available, for whatever reason, additional
functional testing may be required.

MANAGEMENT REVIEW
A management review will usually be conducted periodically to draw out lessons from the
compliance work conducted to date, to consider the impact of any regulation developments,
and to report any recommendations. It should also effectively address any inspection issues
raised by regulatory authorities concerning the company’s computer systems. The overall aim
is the continuous improvement of the company’s compliance capability (policy, strategy,
procedures, training, etc.).
Projects can provide a central focus for applying and refining policies and procedures.
Feedback from practical experience is vital if a cost-effective compliance approach is to be
established. An external consultant may be seconded to provide an independent perspective,
to comment on current industry practices, and to provide updates on topical regulatory issues.
Compliance does not have to be unduly expensive if the issues involved are managed in a
timely manner.
It is recognized that senior managements in pharmaceutical and healthcare companies
are faced with multiple and changing priorities: for example, customer service, quality, and
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 29

financial performance. Nevertheless, it is very important that the level of support given to
compliance is sustainable. Should it falter, the organization will face pendulum swings of
compliance investment and compliance underfunding. Such feast and famine nearly always
leads to a serious noncompliance sooner or later, as practices try to adapt to the level of
prevailing financial support. Senior management should beware of making arbitrary cuts and
rather work on cost-effectiveness improvements. Equally, throwing money at compliance does
not necessarily result in it becoming “solved.” Senior management must avoid the notion that
compliance is a one off project type activity. Inspection readiness results from maintaining the
ongoing compliance of legacy systems that must be properly supported; otherwise their
compliance will be compromized over time.

Recent Inspection Findings

No management review procedures and no documented management reviews (FDA

Warning Letter, 2001).
Quality audits did not verify effectiveness in fulfilling quality system objectives (FDA
483, 2002).

REFERENCES
1. Organisation for Economic Co-operation and Development Environmental Directorate. The applica-
tion of the principles of GLP to computerised systems. No. 10 OECD Series on Principles of Good
Laboratory Practice and Compliance Monitoring, GLP Consensus Document, Environmental
Monograph No. 116. Paris, 1995.
2. International Organisation for Standardisation. ISO 9001: International Standard: Quality Manage-
ment Systems—Requirements. Geneva, 2008.
3. Stokes T. The role of senior management in computer systems validation. In: Stokes T, Branning RC,
Chapman KG, et al., eds. Good Computer Validation Practices: Common Sense Implementation.
Buffalo Grove: InterPharm Press, 1994.
4. Bruttin F, Dean D. A risk-based approach to reducing the cost of compliance in pharmaceutical
manufacturing. Pharm Technol Eur 1999; 36–44.
5. International Society for Pharmaceutical Engineering. GAMP15—Risk-Based Approach to Compliant
GxP Computerised Systems. Available at: www.ispe.org, 2008.
6. Canadian Health Products and Food Branch Inspectorate, Good Manufacturing Practices—Risk
Classification for GMP Observations, 2000.
7. International Conference on Harmonisation. Quality risk management. Q9 document, technical
requirements for registration of pharmaceuticals for human use (ICH). Available at: www.ich.org,
2005.
8. U.S. Food and Drugs Administration. Quality systems based approach for pharmaceutical current
Gmp regulations, guidance for industry. Rockville, MD, 2006.
9. Therapeutic Goods Administration. Australian Code of Good Manufacturing for Therapeutic Goods.
Medicinal Products—Part 1, Woden. Australia, 1990.
10. European Union. EU GMP Annex 11 Computerised Systems. Guide to Good Manufacturing Practice for
EU Directive 2003/94/EC. Community Code Relating to Medicinal Products for Human Use 2003; 4.
11. Japanese Ministry of Public Welfare. Guideline on computer systems in drug manufacturing in
manual on computer systems in drug manufacturing, 1993.
12. U.S. Food and Drugs Administration. Guide to inspection of computerised systems in drug processing.
Technical report, Reference Materials and Training Aids for Investigators. Rockville, MD, 1983.
13. Pharmaceutical Inspection Co-operation Scheme. Good Practices for Computerised Systems in
Regulated GxP Environments. Pharmaceutical Inspection Convention, PI 011-1, Geneva, 2003.
14. Drug Information Association. Computerized Systems Used in Nonclinical Safety Assessment:
Current Concepts in Validation and Compliance (known as “Red Apple II”), 2008.

APPENDIX 2.A: KEY PRINCIPLES FOR COMPUTER SYSTEM COMPLIANCE

These principles apply to computer systems that can affect the quality of drug and healthcare
products. Such computer systems include laboratory systems, process control systems,
spreadsheet and database applications, business systems, and associated computer network
infrastructure.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

30 Chapter 2

Founding Principles
1. Validation requires establishing documented evidence that provides a high degree of
assurance that a computer system will consistently perform according to its
predetermined specifications. A key consideration is the protection of the integrity,
authenticity, and security of data relating to the quality of drug and healthcare
products and/or supporting regulatory submissions.
2. Decisions on the extent of validation and data integrity controls should be based on a
justified and documented risk assessment. Factors to consider include business and
regulatory criticality of the process the system is to support, the potential risks to
product quality or safety the system could pose, and the source of the system (custom
written or COTS).
3. It is essential that there is the closest cooperation between key personnel involved
with the development, management, and use of computerized systems such as users,
system administrators, quality assurance, and technical staff. Persons performing
such roles should have the appropriate and documented training, technical expertise,
and experience to carry out their assigned duties.
4. Electronic records may be signed electronically or by applying a handwritten
signature to a printed copy of the record. Electronic signatures are expected to be
legally equivalent to handwritten signatures, linked to their respective record, and
include the time and date they were applied. Hand-signed printed copies should
provide indisputable linkage with the electronically held record.

Management Requirements
5. All new systems requiring validation must be validated prospectively. Existing
systems that require validation but have not already been validated must be
retrospectively validated.
6. Validation must be planned, executed, and reported. Validation encompasses the
entire life of the computer system, from planning through development and
implementation, and use and operational support to decommissioning. Responsi-
bilities and accountabilities must be defined and documented.
7. Computerized systems must have documented authorization to be used in their
operating environments. Any restrictions impacting use must be recorded and
authorized.
8. Validation must employ predefined procedures and plans designed to build in
quality during all stages of the computer system life cycle. The effectiveness of these
procedures must be assessed periodically, and improvements must be made as
required.
9. System requirements must be traceable throughout specification, verification, and
subsequent change control records.
10. Suppliers of computer systems and associated services must be managed to assure
that the software, hardware, and/or related services they supply are fit for purpose.
11. Enhancements and modifications to computer systems and associated documenta-
tion must be implemented under change control, and, where appropriate, config-
uration management. Changes affecting the compliance status of a computer system
must be approved before they are implemented.
12. Those involved in the development and implementation, use and operational
support, and decommissioning of computer systems must have the documented
education, training, and experience to fulfill their duties.
13. Rationales must be developed and documented to justify compliance decisions not
supported elsewhere.

Project Requirements
14. User requirements and design must be specified, documented, and approved.
15. Software controls must be used to manage programming.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0002_O.3d] [22/1/010/17:2:55] [18–31]

Organization and Management 31

16. Development testing of computerized systems must be documented and cover

structural and functional attributes.
17. Design reviews (also known as design qualification) must be conducted and
documented to verify that user and regulatory requirements are satisfied in the
wider system context including equipment, processes, and manual interaction.
18. User/site acceptance testing of computerized systems (known as qualification) must
cover installation, operation, and performance in the wider system context including
equipment, processes, and operator interaction (i.e., installation qualification,
operation qualification, and performance qualification).
19. Data migration must preserve the integrity and security of original data. Processes
and methods used to load data (manually and automatically) must be defined and
validated with supporting documentation before they are used.

Operation Requirements
20. The performance of computer systems must be monitored against predefined
requirements to demonstrate acceptable operational service.
21. Preventative maintenance and calibration, where required, must be planned,
conducted, and documented.
22. Software changes and upgrades must be conducted according to defined procedures
and documented.
23. Records must be established to demonstrate data integrity being maintained.
24. Backups of software, configuration, and data must be planned, conducted, and
documented. Backup data must be readable and therefore retrievable.
25. Archiving of software, configuration, data, and associated documentation must be
planned, conducted, and documented. Storage media must be retained for a
predefined period at a separate and secure location under suitable environmental
conditions, be protected against willful or accidental damage, and be periodically
checked for durability and restoration. Archived materials must not be destroyed
until this retention period has expired.
26. The procedures to be followed if the computerised system breaks down and is
unavailable must be documented and periodically verified.
27. Access to computerized systems and associated functionality must be restricted to
authorized persons, and documented.
28. Formal agreements regarding operational support (e.g., contracts and service level
agreements) must be established by defining responsibilities and accountabilities.
29. User procedures must be established and trained out to ensure that computer
systems are consistently used.
30. The compliance status of computerized systems and the cumulative effect of change
must be periodically reviewed, and any required revalidation must be conducted.
31. Decommissioning of computer systems must be planned and conducted in
accordance with defined procedures.

Responsibilities and Accountabilities

System owners/users are accountable for assuring that computer systems used by them
or on their behalf by other organizations are compliant with pharmaceutical regulatory
requirements.
Developer and operational support organizations are responsible for the technical
delivery and quality of work of their associated compliance activities. These activities must
fulfill regulatory expectations. Developer and operational support organizations have a mutual
responsibility to ensure that project handover activities are appropriate and completed.
Quality and compliance are responsible for establishing necessary policies and
procedures to manage compliance activities and for approving compliance work. They must
be able to demonstrate their independence to the system owner/user and to developer and
operational support organizations.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

3 Supporting Processes

INTRODUCTION
Successful validation depends on the satisfactory operation of a number of underlying
supporting processes. Among these are training, document management, change control,
configuration management, requirements traceability, self-inspections, and managing devia-
tions. Compliance is fundamentally flawed without them, and so they are discussed here.

TRAINING
All personnel (permanent staff, contractors, consultants, and temporary staff) developing,
supporting, or using a GxP computer system must be trained so that they acquire the necessary
level of competency before they may be allowed to perform their designated duties. To this
end, all personnel involved in any aspect of compliance should have (1)

l A role description,
l Appropriate qualifications that have been documented, and
l Plans and records for training, both prospective and retrospective.

Qualifications
When recruiting, pharmaceutical and healthcare companies should try to verify the details of
the education, training, and experience claimed by the candidates. Copies of their certificates
should be requested and retained. Personal references should also be taken up, although their
value should be weighed with care, remembering that the commendations given can be
presented in a politically correct fashion that carries a hidden, subliminal, and rather less
favorable implication! For example, consider the following embarrassingly flattering accolade

You write to ask me for my opinion of XXXX, who has applied for a position in
your department. I cannot recommend him too highly, nor say enough good things
about him. The validation he conducts is the sort of work you don’t expect to see
nowadays. His documentation clearly demonstrates his complete capabilities. His
understanding and appreciation of regulatory requirements will surprise you. You
will indeed be fortunate if you can get him to work for you.

Curricula vitae (CVs) for permanent staff are usually kept by the Human Resources
department. This is not necessarily the case for contractors, consultants, and temporary staff.
Their CVs, typically retained by the responsible manager, can be easily lost when individuals
move on to new contracts. One way to systematically capture such training records for
contractors, consultants, and temporary staff is to attach them as appendixes to validation
plans or validation reports.
The profile suggested for a computer compliance practitioner is given in Ref. 2 and
comprises

l Technical background involving computer systems,

l Technical qualifications associated with computer systems, and
l Two or more years of Gxp experience, not necessarily involving computer systems.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 33

Compliance practitioners must have a measure of tenacity and self-discipline so that they
stay the course, progressing work through to completion without constant supervision. This is
not to say, however, that they should be discouraged from seeking advice but rather that they
should have sufficient judgment and regulatory knowledge to make some basic decisions
themselves. Practitioners should be flexible in their approach, so that when the inevitable
problems arise, they do not instinctively resist exploring new solutions.
Managers are likely to be qualified by experience, perhaps supplemented by training.
Personal attributes, and especially attitudes, are of crucial importance, but there is insufficient
space to develop this theme here. Educational attainment alone does not ensure that a manager
has the competencies required to manage effectively.

Training Plans and Records

Training plans should be used to manage the development of staff, and subsequent training
should be conducted in accordance with approved procedures. All personnel should be aware
of the principles of GxP affecting them, and receiving initial and continuing training relevant
to their job responsibilities. This includes those developing, supporting, and using computer
systems including electronic records and signatures. It is important to recognize that necessary
training must be provided prior to the need for the use of the associated competency arising,
rather than when the lack of such competency has already been painfully demonstrated!
Training records must be maintained. Some pharmaceutical and healthcare companies
make use of questionnaires to try to verify in a formal way that personnel have understood
their training and really acquired the intended competence. Authorized assessors should be
engaged to mark such miniature examination papers. If personnel fail to pass such a
competency test, some supplementary training is required. Care should be taken not to simply
default to repeating the original training and the examination. Perhaps the training materials
or delivery were at fault, and they may require improvement. There may be a systematic
reason why individuals have not understood what they have been taught.
The performance of personnel should be periodically reviewed to identify any refresher
training requirements. Some pharmaceutical and healthcare companies achieve this through
an audit or a periodic review of training records, which must be updated to reflect the training
received. Marked competency questionnaires or test papers should be attached to training
records where possible.

Recent Inspection Findings

No written procedures describing training given to those who use the computer system
(FDA 483, 2004).
No records to document that the information technology (IT) service provider staff
personnel have received training that includes current good manufacturing practice
regulations and written procedures referred to by the regulations (FDA 483, 2000).
No documentation to indicate that users are trained in the software and its applications
(FDA Warning Letter, June 2000).
No documentation that a qualified person reviewed the training records (FDA Warning
Letter, 2000).
No assurance that adequate training was given on how to use the (computer) system
software (FDA 483, 2002).
Corrective action to noncompliance with SOPs consists of retraining in the same manner
as initially trained. There is no limit to the frequency of retraining (FDA 483, 2000).
There is no evidence that the training provided during 2000 and 2001 to your analysts is
adequate as evidenced in the following events. The efficiency and adequacy of the
training program are questionable in that numerous training sessions are performed
during the same day (a specific list of eight training sessions a particular employee
received on the same day was then made) (FDA 483, 2002).
The current training procedure for employees does not determine the proficiency or
comprehension at the end of training. Your response to this letter should include
(your) plan for establishing a system of training and evaluation to ensure that
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

34 Chapter 3

personnel have the capabilities commensurate with their assigned function (FDA
Warning Letter, 2000).

DOCUMENT MANAGEMENT
Documentation of research, development, and manufacturing practice is vital to pharmaceu-
tical and healthcare companies because unless they do this, they have no way of demonstrating
compliance to the various GxP regulatory authorities. Examples of documents include policies,
procedures, plans, reports, and operational data. Regulatory inspectors will expect to see
document management procedures established covering preparation, review, approval, issue,
change, withdrawal, and storage. This is especially important for contractual documents and
documents endorsed by the pharmaceutical or healthcare company’s QA organization.

Document Preparation
Documentation standards should be defined so that there is consistent document layout, style,
and reference numbering. Documents should be clearly marked as draft until they are formally
released. Version control should be apparent. The version identifiers should distinguish
documents under development (drafts) from those that have been issued formally. Documents
should include a document history section to log the changes made in successive issued
versions of the document.
Individual documents should have the following controls:

l Document title
l Document number
l Version number
l Page x of y
l Date of issue
l Copy number

Some organizations include a date for the next routine review of the document. This
ensures that even if no changes have occurred, the document will still be examined to verify
that it is still relevant and accurate.
Documentation has progressed enormously from the days when word processing
represented the apex of efficiency and automation in this arena. Special considerations for
more sophisticated document types are given in Table 3.1. In some instances, it is
recommended that the document type should be stored with or within the document to
make ongoing document maintenance easier. This also applies to some types of embedded
documents.

Document Review
Documentation should be subject to review prior to its formal release. Such a review might
assume a number of forms ranging from the evaluation of the document and collection of
comments through to its inspection within formally convened review meetings. The reviewers
should be identified in advance within the validation plan, the project and quality plan, or the
document management procedures. Many firms give staff guidance on how to decide the most
appropriate reviewers for different documents.
The review can be recorded using a template or by simply recording meeting minutes in
the traditional manner. In either case, the date of the review and the names of the reviewers
should be noted. It is recommended that a multidisciplinary team that includes technical and
quality representatives review documents. Each reviewer, however, does not necessarily have
to be an authorizing signatory for the document under inspection as long as his or her
comments are included in the review records.
For the review process to be effective, reviewers must come prepared. Copies of the
documents under review should be distributed and scrutinized prior to the meeting. A
chairperson for the review meeting should be nominated beforehand. Similarly, remote
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 35

Table 3.1 Characteristics of Various Document Types

Document Examples of
type Characteristics application area Special precautions

ASCII text The simplest document type Memos, master production Specify file format,
document to manage. Typically and control records, application, version,
created in a word SOPs, deviation reports, and language.
processor, it consists of validation protocols,
only characters belonging batch documentation, etc.
to the ASCII or ANSI sets
(text and symbols). Such
documents can be viewed
by the originating word
processor or by file viewer
programs commonly
available in most
computer systems.
Portable A homogeneous document All sorts of documents Documents must be
format type created from many including more complex stored in “neutral” file
document other types of document ones such as integrated format. Specify file
but stored in a standard batch documentation, format, application,
or proprietary file format. illustrated SOPs and version. Special
The international printer drivers may be
standard is SGML. necessary.
Proprietary formats
include Adobe’s PDF
format. A semiportable
format is HTML, which is
used on the Internet. Files
cannot be edited without
special editing software.
Graphical A homogeneous document CAD drawings, SOP Specify file format,
document type stored in a standard illustrations, scanned application, version,
graphical file format. paper documents, label and language.
Includes scanned paper pictures for batch
documents. Many file documentation
formats exist, from bit-
mapped pictures (e.g.,
TIFF, PCX, GIF, JPEG)
to highly complex
vectored drawings in a
CAD environment (e.g.,
CGM, DXF). Many
proprietary formats exist.
Some CAD formats
include product database
information.

reviews will require the appointment of an individual to coordinate and collate the review
feedback.
The review must systematically cover each section of the document. If a section attracts
no comments, this should be indicated in the records. Any corrective actions identified in the
review must be assigned to a named individual with a completion date. The progress of
individual actions should be tracked through to closure. Care must be taken to ensure that
associated documents are also reviewed and updated as necessary.
Sometimes in the absence of any consensus, a compromise on the content of a document
will have to be reached. Such compromise positions should be agreed before approval is
sought to avoid delaying the approval process. Normally, the document author has the
responsibility for resolving these issues. Often this is not simple, especially when reviewers
have entrenched and opposing views! An escalation route to resolve any impasse should
therefore also be defined and agreed beforehand.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

36 Chapter 3

Speakers at conferences have expressed the opinion that in their experience, 80% of
review comments might relate only to format and style. In spite of this, over 80% of the
problems arising from poor documentation could be attributed to omissions and accuracy!
Something is wrong here. Reviewers need to bear these statistics in mind and strive to make
their reviews as effective as possible in identifying the defects in documents, defects that will
cost time and money later on.
Once the agreed changes have been incorporated into the document, it is ready for
approval. The document history should be created to record the changes made. There is no
need for the document history to affirm what remained the same. Document histories are
usually written in the form of a summary at the beginning or end of a document.
Review records should not be destroyed, at least until the document is approved and
formally issued. Many projects have a policy of retaining all document review minutes and
records until computer system is handed over and commissioned into use. Even then the
project files containing the review records may be retained for a few years, just in case some
question or defect arises in the future.

Document Approval
Just like the reviewers, document approvers should be identified in advance within the
validation plan, the project and quality plan, or the document management procedures. Again,
many firms guide staff on the most appropriate choices of personnel for the sensitive and
important task of document approval.
The number of signatures on individual documents should be monitored. There are
usually four principal signature roles (all not required for each document).

l Technical approval where relevant

l Regulatory compliance
l Compliance with corporate procedures (including format)
l Authorization to proceed

There is no reason why one individual cannot fulfill more than one role provided he or
she has appropriate competencies. There is one prohibition, however; no single individual
should represent both quality and technical roles. The minimum requirement is for two
signatories, representing quality and technical roles, respectively.
Documents with up to 10 signatures are common where the number of signatories is not
controlled. During a survey at one European pharmaceutical company, a document was found
bearing no less than 18 signatures! Was this really necessary? Indeed, too many signatories will
retard the release of documentation, while some practitioners have argued that many
signatures leads to less effective document scrutiny rather than more. It is not hard to see
why—human nature being what it is. The temptation to believe that the effort of an effective
review is pointless as so many others have already endorsed it becomes almost irresistible
(a phenomenon also known as the rubber stamp effect)! Furthermore, what personal price will
be exacted for questioning the combined wisdom of so many colleagues? There is thus some
truth in the cynic’s maxim that the quality of a document is inversely proportional to the
number of approval signatures.
The rationale for the presence of each approval signature should be unambiguous and
documented—signatories should know why they are signing the document! Example approval
signatures include technical authority, QA compliance, and user acceptance. Regulatory
authorities normally require key compliance documents to have formal signatures from two or
more authorized persons. Signatures should be written in black or blue ink as the pigments
and dyes in them render the signatures more resistant to fading. Approval signatures should
be dated and accompanied by the name of the person signing, as the identities of some
signatures are indecipherable (a weakness normally associated with the medical profession
and its prescriptions but also all too evident during regulatory compliance activities).
Interestingly, in some countries such as Japan, it is legally admissible to use as a signature a
mark or stamp that does not identify the person’s spelled name.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 37

Document Issue
Document Distribution
Approved documents should be made available in accordance with defined distribution
procedures. Many organizations use document management systems including intranet that
allow users to download copies of master documents. Such copies may be used for GxP
purposes provided users check that they are using the correct version of the document (i.e.,
verify current version number) before using the copy. It may be necessary for pharmaceutical
and healthcare companies to establish confidentiality agreements with suppliers who receive
copies of their documents as well as ensure that suitable security access controls are in place so
that only authorized persons can access documentation.
Some organizations define and record an “effective date” and “expiry date” on
documents. The effective date is usually defined to allow a period for dependent activities, for
instance, the distribution and training implied in the associated SOPs. The expiry dates of
different document types should take account of their change frequency. SOPs might have an
expiry date equivalent to their next planned periodic review. Master documents that have
passed their expiry date must be clearly marked as superseded. Where effective and expiry dates
are deployed, they should be prominently displayed on the document’s frontispiece.

Document Changes
All changes to released approved documents must be subject to change control. The revised
document should be clearly marked as a draft and managed accordingly, as described above.
Modifications to approved documents should be reviewed and approved by the same
functions/organizations that performed the original review and approval unless specifically
designated otherwise. Despite changes in individual signatories, there should be a consistent
allocation of responsible review and approval roles.

Document Withdrawal
From time to time, documents must be withdrawn from use, having perhaps come to the end
of their useful life or being superseded. Some firms send an e-mail to relevant portions of their
organization notifying them of withdrawn documents. Document keepers can be asked either
to notify the central distribution group that they have destroyed their copies of withdrawn
documents or to return specially printed copies to the central distribution group for disposal.
Safeguards should be instituted to prevent the retention and use of superseded or withdrawn
documents. Many firms use audits to this purpose.

Document Administration and Storage

It is wise to keep the organization and administration of documentation as simple as can be
conceived. Complex systems are much harder to manage successfully. Centralized versus
distributed administration of documentation has advantages and disadvantages. Centralized
administration offers economies of scale and easier control of master documents as the latter
are held in one location. Distributed administration, meanwhile, offers more “ownership”
because it is closer to its users, and it is easier to plan for busier periods. Most organizations
tend to centralize administration on a site basis, but either approach can be adopted as long as
it is controlled. In theory, the best of both worlds is available through the implementation of an
electronic document management system (EDMS). Such systems must of course be validated!
Master copies of documentation should be stored in a safe and secure location according
to defined procedures. These master copies should be stored with

l Approval signatories,
l Document history,
l Change control records,
l Document distribution records where applicable,
l Superseded versions, clearly marked as such, and
l Withdrawn documents, clearly marked as such.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

38 Chapter 3

Stored documents should be protected against accidental and malicious damage. They
must be retrievable in a legible format throughout their predefined retention period. This
usually means that a minimum of two copies are retained, each in a separate place, just in case
of accidents. Once the retention period has expired, a decision can be taken whether or not to
destroy the master copies. A record of destruction, evidence that the document once existed
but has since been destroyed, should be made and retained for a further period.
A document index should be maintained to log documentation by reference/title,
version, and physical storage location. As the status of a document changes, the document
index needs to be updated.

Quality of Documentation
The quality of documentation must be assured. Poor documentation is often marred by
rambling, unfocussed, and verbose text, with omissions in some areas and excessive detail in
others (Appendix 3.A). This impedes its use as well as undermines the goal of achieving GMP
compliance. Those preparing documentation and records should therefore ensure that
documents meet the six virtuous Cs, that is,

l Concise,
l Complete,
l Consistent,
l Comprehensible,
l Correct, and
l Controlled.

Wherever possible, keep documents short (preferably fewer than twenty pages) and
avoid the duplication of information.
Basic regulatory expectations include

l Mistakes being altered correctly: single strike, initialed and dated, with a brief reason
for the correction (or a reference to a change control number if appropriate),
l Avoiding use of dittos or arrows, as FDA consider them insufficiently descriptive
where actual values with corresponding signatures are needed,
l Avoiding transcriptions even if the original document/record looks messy, and
l Ensuring that white opaque correction fluid is never used, as it hides the original
information.

Regulatory authorities will search documentation for certain vague words that, in their
experience, are often associated with imprecise documentation.

l Calculate: the actual calculation intended to be used specified?

l Automatic: the degree of manual intervention specified?
l Typically, usually: exactly how often is meant here?
l Normally: what is normal, what is abnormal?
l Appropriate: what is appropriate, what is not appropriate?

A simple word search can be used on word processors when a document is being written
to identify the use of these words, which should then either be replaced with alternative
phrases or be clarified to alleviate the uncertainty.

Recent Inspection Findings

QA has failed to ensure that all appropriate computer validation documents are
identified and controlled (FDA 483, 2004).
Lack of appropriate documentation procedures (FDA Warning Letter, 2001).
Lack of procedures to ensure that records are included with validation documentation,
maintained, and updated when changes are made (FDA Warning Letter, 2001).
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 39

SOPs do not clearly describe who must approve documents or what each type of
approval represents (FDA 483, 2002).
Significant deficiencies regarding documentation controls were reported. Documents
were not dated, lacked a documentation control number, were missing, or were
reported in pencil on uncontrolled pages, or dates were crossed out without initials,
dates, or explanation (FDA Warning Letter, 2001).
Errors on batch production, control, and laboratory records must not be erased or
overwritten (interpret as no whiteout). A line must be drawn through an incorrect
entry and the corrected figure or word written neatly and initialed. Significant data
must not be discarded without explanation. To discard significant data, the data must
be crossed out and initialed, and a valid reason for discarding the data must be
explained (FDA Warning Letter, 2001).
Numerous instances of lack of control of official controlled documents were observed:
use of incorrect version of testing forms, incorrect data sheet used because old sheets
are not replaced with new, incorrect log sheets were used (FDA 483, 2002).
Several pages were missing in printouts (FDA Warning Letter, 2000).
Two pages of a laboratory notebook were written in pencil and erased. Your abbreviation
for . . . could be read on one of the erased pages (FDA Warning Letter, 2000).
Values in at least two laboratory records were altered. Altered values were written under
computer-generated values . . . . and used in potency calculations. Review of the
electronic data confirmed the incorrect values, which were part of your submission to
the drug master file (FDA Warning Letter, 2000).

CHANGE CONTROL
The following maxims of change are based on work by Lehman and Belady (2).

l First maxim of change: change will happen

Computer systems do not have static requirements. A system that is being used will
almost certainly undergo continuing change either because its requirements were not
fully understood in the first place or because the use of the system is changing.
Change will only stop when the system’s functionality becomes obsolete or it is
judged more cost-effective to reengineer the system or replace it by a completely new
version.
l Second maxim of change: change breeds change
Programmers often find it hard to resist adding unsolicited functionality.
l Third maxim of change: change increases complexity
Software subject to change becomes less and less structured and thus becomes more
complex. Extra effort is required when implementing changes to avoid increasing
complexity.
l Fourth maxim of change: documentation eases change
The quality of documentation associated with computer systems is a limiting factor to
the ease of implementing change over its operational life. Faster rates of change
typically indicate the dominance of developing functionality over documenting the
change. Slower rates of change may indicate that system modifications are being
hindered by previous changes not being fully documented or that developing
functionality is being fully documented.
l Fifth maxim of change: more resource does not imply faster change
There is an optimum level of resource for change. Applying more people to
implement a change does not imply that the change will be achieved faster. Indeed, it
can quite often add management complexity and slow change down.

These maxims should raise awareness of the need for effective change management.
Quality and compliance has to be preserved.
All changes to regulated computerized systems must be reviewed, authorized,
documented, tested (if applicable), and approved before implementation. Software cannot
be partially verified. When a change (even a small change) is made to a software program, the
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

40 Chapter 3

Figure 3.1 Change control process.

compliance status of the entire software system should be reconsidered, not just the individual
change (3). Retrospective validation and reverse engineering of existing software are very
difficult but may be necessary to properly document and verify changes.
The procedure for change control can be divided into four phases (Fig. 3.1).

l Request for change

l Change evaluation (impact analysis) and authorization
l Testing and implementation of the change
l Change completion and approval

Request for Change

A system owner should be (have been) appointed for every system. This should be laid down
in the system documentation (or validation plan). A proposal for a change should be directed
first to the system owner, who shall be responsible for ensuring that all changes to the system
are reviewed, authorized, documented, tested (if applicable), approved, and implemented in a
controlled manner. The system owner may delegate this responsibility if permitted to do so
and the delegation is documented.
Any proposed change should be requested and recorded by submitting a change request
form. An example of such a form is given in Figure 3.2. The change request part should at least
include the following items:

l Requester name
l Origination date
l Identification of component or software module to be changed
l Description of the change
l Reason for the change

Unique reference number is to be assigned by the system owner or his delegate using a
logging mechanism.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 41

Figure 3.2 Example of change control form.

[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

42 Chapter 3

Change Evaluation and Authorization

Each change request raised must be reviewed, and a judgment must be made (accepted or
rejected). For system changes with a scope wider than that solely of the department that owns
it, the change request should be circulated to all the departments affected by the change. These
should be identified by the system owner or his delegate, and they must be obliged to review
the change request with their appropriate technical, management, QA, and user personnel.
Once the impact of the proposed change has been assessed, the system owner or his delegate
must decide whether to accept or reject the proposed change.
In principle, for systems used for GxP-related activities, QA should be involved in the
decision-making process. Future QA involvement in the rest of the change process will depend
on the compliance status of the computer system and the nature of the change being
implemented. Authorization by QA is required at several stages when the change is regarded
as GxP relevant.
Changes may be implemented separately or collected into bundles for implementation.
Consideration should be given in either case as to whether or not revalidation of the whole system
is required. As more and more changes are applied, revalidation becomes increasingly appropriate.

Testing and Implementation of the Change

After evaluation and acceptance, the change can be effected, tested (if applicable), and formally
commissioned into use. This principle applies equally to hardware and software; in the case of
the latter, code redevelopment and testing should follow the same procedure as newly
developed software. It is wise if possible to develop and test such changes in an isolated test/
development environment before applying the change to the operational system.
Testing is necessary to determine whether the change(s) work(s) properly and has (have)
not compromised the system’s functionality. The scope of testing should be based on the
impact analysis. Where potential impact on other system functionality or other applications is
identified, testing must be extended to include affected areas. This is sometimes referred to as
regression testing.
Testing should be performed according to a test plan and all testing should be fully
documented (e.g., test description, test items, acceptance criteria, results, date of test, and
names and signatures of persons who performed the test). While testing is of course necessary,
it is vitally important to understand a critical principle where software changes are concerned.
This is that the assurance of the safety of the change should rest far most heavily on a review of
the change to the design of the software. If reliance is confined to test results alone, serious new
flaws consequential on the change but quite unanticipated may be overlooked.
After implementation of the change (in the operation environment), the system owner
should formally accept the change. This formal approval can be made on the basis of the test
results, or the system owner might decide to perform some separate acceptance test.

Change Completion and Approval

Finally, all the documentations concerning the change and all documents required for
operation with the change need to be completed. It is important to identify and satisfy any
training needs. The change request form shall be completed and passed to the system owner
for final review and approval. Depending of the GxP relevance of the system, or the impact of
the change, QA should review and endorse the implementation of the change. QA should
always be informed about the change by being sent a copy of the completed change request
form. The users should be informed (and trained if applicable) about the change. The system
owner gives the final approval of the change and releases the system.

Recent Inspection Findings

The quality unit failed to put in place procedures to ensure that design documentation is
updated when program code changes are made (FDA 483, 2007).
Changes were made to macro in process control software but change control process was
not used, instructions on how to use the software were not modified, and changes
were not validated (FDA 483, 2006).
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 43

Firms change control procedure does not include software changes (FDA 483, 2003).
There was no evaluation of impact of software changes on other parts of the program
(FDA 483, 2003).
There is no system in place to ensure that parameter adjustments, which are executed in
the during production runs, are made by authorized personnel (FDA Warning Letter,
2002).
Changes to in-house written templates used in QC laboratory computer system not
controlled (FDA 483, 2003).
Failure to establish test plan/protocol for approved hardware changes (FDA 483, 2001).
Change control records were found signed off by the quality unit that had not been
properly annotated in the code (FDA 483, 2001).
The firm failed to document review and approval of test records supporting program
modification (FDA 483, 2001).
In managing change, personnel will receive their appropriate XXXX via an e-mail that
has been sent from an e-mail distribution list. The firm has failed to implement
controls to document that these distribution lists are maintained updated with the
current approved listing of users (FDA 483, 2001).
Software “bug” that could result in erroneous release not scheduled for correction (FDA
483, 2002).
Computer program change requested to prevent shipping error has not been addressed
(FDA 483, 2003).
The vendor edited the software and configuration, but there is no documentation of the
vendor’s evaluation (of the problem), description of root cause, or recommendation for
correction (FDA 483, 2009).
Computer enhancement was identified as needed to correct labeling deviation but not
implemented over one year later (FDA 483, 2002).
No record of review of software fix and correction of incorrect electronic records (FDA
483, 2002).
Documentation regarding system and software changes not fully available (FDA 483, 2004).

CONFIGURATION MANAGEMENT
Configuration management refers to the overall task of managing the use of varying versions
of the various components (hardware, software, and documentation) that comprise a complex
computer system. Both ISO 90003 and GAMP15 promote configuration management as a
recommended and necessary discipline. The level of formality needed is greater for an
operating system compared with, say, a system in its early development, but the principles are
the same. The use of configuration management tools can considerably ease the effort required
here, especially in the case of larger systems where the level of complexity grows
exponentially, rather than in a linear fashion.
Configuration management consists of the following activities:

l Configuration identification (what to keep under control)

l Configuration control (how to perform the control)
l Configuration status accounting (how to document the control)
l Configuration evaluation (how to verify that control)

Configuration management should be planned and conducted in accordance with

defined procedures. This should include specified roles and responsibilities. Configuration
management activities are normally specified with the validation plan or project and quality
plan, although the complexity of larger projects implies the desirability of a separate
configuration management plan.

Configuration Identification
Configuration management begins with the system assembly. The task here is to identify and
document the build configuration by ensuring that the mix of software, hardware, and
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

44 Chapter 3

documentation, all in their various versions, is unambiguously known and coordinated.

Clearly, if this is not done, chaos rapidly ensues. It is important to be able to establish the exact
composition of a particular system build that can act as a baseline, or known reference point,
against which any subsequent changes or behavior can be referred to. Key configuration
management records include

l Document index (approved documents including key documents provided by

suppliers such as user manuals),
l Hardware unit index (clients, servers, communication interfaces, printers, etc.), and
l Software program index (source code, executables, configuration files, data files, and
third-party software such as operating system, library files, and drivers).

Configuration Control
All documents, hardware units, and software programs must be uniquely identified. It is not
necessary to violate warranty seals to uniquely identify subcomponents. However, in
situations where hardware units and software programs do not have a unique identification,
physical labels and software header information can be added retrospectively. Unique
identification should include the model number for hardware and the version number for
software (e.g., MS Vista Service Pack 2). Current approved versions of source codes must
correspond to current approved versions of software documents, object code, and test suites.
All source codes should have associated documentation.

Configuration Status Accounting

Documentation showing the status and history of configuration items should be maintained.
Such documentation may include details of changes made, with the latest version and release
identifiers.

Configuration Evaluation
A disciplined approach must be sustained to maintain the integrity of configuration
management. It can be tempting to relax configuration management just to release resources
and reduce costs. Consequential problems that often arise include

l Only partial backups/archives of data made in a rush or on insufficient storage

media,
l Items labeled unclearly or ambiguously labeled with poorly handwritten labels that
cannot be understood by anyone other than author,
l Ambiguous version numbering nomenclatures, particularly for software where
media might be labeled by date rather than by the version of the software carried,
l Supplier’s notification of serial numbers that do not match the actual serial numbers
delivered, and
l Documentation not fully synchronized with system changes, often because documen-
tation was accorded a lower priority than the physical implementation of a change.

It is therefore recommended that the configuration status and practices should be

regularly checked. Periodic reviews should include configuration management. It is important
to demonstrate that

l The configuration management plan is up to date,

l Recorded configuration is consistent with physical status,
l Naming and labeling conventions are being followed,
l Software version controls are being applied,
l System is in the intended baseline state in accordance with defined milestones (e.g.,
for supplier testing, at installation, for user acceptance testing, and for use), and
l Change management is effective.
[Shaji][7x10 Tight][D:/informa_Publishing/WINGATE_2400029/z_production/z_3B2_3D_files/
978-1-4398-1879-4_CH0003_O.3d] [25/1/010/10:10:28] [32–54]

Supporting Processes 45

The fundamental challenge to configuration management record keeping is whether it

can make a full system rebuild possible by relying solely on these records. A good test is to
assess the measure of confidence the responsible person has that the system could be
successfully restored on a first attempt. At a practical level, this capability is the foundation of
disaster recovery, directed at the effective support of business continuity plans.

Recent Inspection Findings

The firm has failed to adequately control software configuration (FDA 483, 2003).
System configuration documentations were found to be obsolete (FDA 483, 2004).
The firm has failed to establish an overall revision control system for the program
throughout its software life cycle (FDA 483, 2001).
The computer system is not validated in that . . . configuration management. The firm
failed to document all sites, departments, or connections on the network ... The firm
has failed to document external program interfaces . . . The firm has failed to define or
describe the various used for the development, test, and production environments
(FDA 483, 2001).
Networked system can only support four interfaced systems but had up to five systems
attached. There was no validation showing this configuration to be acceptable (FDA
483, 2000).
The vendor edited the software configuration, but there is no documentation of the
vendor’s evaluation (of the problem), description of root cause, or recommendation for
correction (FDA 483, 2009).

REQUIREMENTS TRACEABILITY
Traceability is a fundamental in terms of demonstrating regulatory compliance. In ISO
terminology, traceability demonstrates that design input is linked to design output and has
been verified. For example, does the functional specification fulfill the user requirements
specification?

Principles

l It should be possible to explicitly link specifications forward where there is

appropriate design, testing and subsequent changes. Likewise, it should be possible
to trace from testing backward through to specification.
l The linkage between specification, design, and test is not necessarily limited to a 1:1:1
relationship. Multiple requirements can be covered by a single test. Multiple tests can
be required to cover one requirement.
l It should be possible to measure coverage of design and testing in fulfilling user
requirements. Focus should be placed on the traceability of critical requirements.
Criticality can then be cascaded through design to testing.
l Traceability should be maintained throughout system operation and deal with any
changes made to the system.
l Traceability should not force a single stream of sequenced activities. Many activities
can be conducted in parallel; only approvals and key dependencies need to be
sequential.

Benefits of Traceability
Establishing a robust means of traceability brings many benefits. During the project
development, it can be used as a means to

l Identify and control critical aspects of system,

l Identify and challenge user qualification duplicating development tests,
l Demonstrate testing percentage coverage of system specification, and
l Determine scope of testing to address design revisions.