Chromatography is a major analytical technique that is used throughout research, development and manufacturing in the pharmaceutical, medical device and associated industries. To demonstrate fitness for purpose with the applicable regulations, the systems must be validated. Validation of Chromatography Data Systems: Meeting Business and Regulatory Requirements introduces the basics of computer validation. It looks in detail at the requirements throughout the life cycle of a CDS for any regulated laboratory, from its concept, through writing the user requirements specification to selecting the system, testing and operational release, including using electronic signatures. This logical and uniquely organised book provides the background to the regulatory requirements, interpretation of the regulations and documented evidence needed to support a claim that a system is validated. Development of the system, risk management, operation and finally system retirement and data migration are discussed. Case studies and practical examples are provided where appropriate. Validation of Chromatography Data Systems: Meeting Business and Regulatory Requirements is ideal for the chromatographer working in analytical laboratories in the regulated pharmaceutical, contract research, biotechnology and medical device industries seeking the practical guidance required for validating their chromatography data systems in order to meet regulatory requirements. It will also be welcomed by consultants or those in regulatory agencies.
Validation of Chromatography Data Systems
Meeting Business and Regulatory Requirements
By R.D. McDowallThe Royal Society of Chemistry
Copyright © 2005 The Royal Society of Chemistry
All rights reserved.
ISBN: 978-0-85404-969-1Contents
List of Figures, xx,
List of Tables, xxii,
Glosarry, xxiv,
Abbreviations, xxvii,
Chapter 1 How to Use this Book, 1,
Chapter 2 Introduction to Chromatography Data Systems, 9,
Chapter 3 Regulatory Requirements for CDS Validation, 19,
Chapter 4 Concepts of Computer Validation, 33,
Chapter 5 CDS Validation: Managing System Risk, 53,
Chapter 6 Process Redesign to Exploit the Tangible Benefits of Electronic Signatures with a CDS, 61,
Chapter 7 Writing the User Requirements Specification, 76,
Chapter 8 Controlling the Work: The Validation Plan, 87,
Chapter 9 System Selection, 96,
Chapter 10 Auditing the CDS Vendor, 102,
Chapter 11 Contract, Purchase Order and Planning the Installation, 113,
Chapter 12 Risk Assessment and Requirements Traceability, 121,
Chapter 13 Installation Qualification and Operational Qualification, 127,
Chapter 14 Performance Qualification (PQ) or End-User Testing, 136,
Chapter 15 User Training and System Documentation, 159,
Chapter 16 IT Support of the System, 166,
Chapter 17 System Description, 177,
Chapter 18 Validation Summary Report, 182,
Chapter 19 Defining Electronic Records for a CDS, 188,
Chapter 20 Maintaining the Validation Status During Operational Life, 199,
Chapter 21 Periodic Review of the CDS, 212,
Chapter 22 Records Retention, 218,
Chapter 23 CDS Data Migration, 227,
Chapter 24 CDS System Retirement, 243,
Chapter 25 Retrospective Validation, 248,
26 References, 253,
CHAPTER 1
How to Use this Book
1.1 Purpose and Scope
Chromatography is a major analytical technique that is used in almost all analytical laboratories. The days of chart recorders and paper and pencil interpretation have gone and today the chromatography data generated by a method is now acquired, stored, interpreted, manipulated and reported by a chromatography data system (CDS).
When a laboratory operates in a controlled industry, such as the pharmaceutical, biotechnology or medical device along with the allied contract research organisations, the applicable regulations require that the CDS be validated for its intended purpose. However, in today's world where many organisations work in a global market, there are many regulations that are applicable even within a single laboratory.
The purpose of this book is to give readers a practical understanding of how to validate their CDS. The principles outlined here are applicable from single standalone systems to client server systems for a site and to larger terminal served systems operating between sites and over two or more time zones. The reader needs to scale the principles in this book to their specific system and ways of working.
Analytical laboratories working in analytical research and development and manufacturing under Good Manufacturing Practice (GMP) regulations as well as bioanalytical laboratories operating under Good Laboratory Practice (GLP) regulations can use this book. This book also includes validation of mass spectrometry data systems used for quantitative analysis in a regulated environment.
In this book, I want to discuss the prospective validation of CDS software. By prospective validation, I mean undertaking the validation work in parallel with progress through the life cycle of the project from start to finish. Unfortunately, this is not always the case. Usually just before the system goes live someone thinks that perhaps we should validate the system! Taking this approach will add up between 25 and 50% to the validation costs of the project. The main reason is documentation that should have been written at key stages of the project is missing or if written may not be of sufficient quality for laboratories working under regulations such as GMP or GLP. However, some people may approach CDS validation retrospectively and in Chapter 25 there is an outline of what should be done in this situation. However, the main emphasis in this book is on prospective validation.
1.2 The Way It Was ...
In the past, the chromatograph and CDS software was purchased and then just before it was put into operational use someone thought about validation of the system. Some common questions may have been:
• Have we validated the system? No
• Does it matter? Probably
• Will we get caught? Do not even think about answering no to this question
Considering validation at such a late stage of the life cycle will mean a delay in going live, thus failing to gain benefit from the investment in the instrument and releasing the system with no regulatory coverage. This depends on your approach to risk and if can you sleep at night.
This approach to validation had no concept or consideration of a system development life cycle (SDLC) or even testing the system to see if it was capable of supporting the laboratory.
1.3 The Way It Should Be ...
However, a proactive approach to validation is necessary and if done correctly will actually save you money by ensuring that you buy the right CDS for your laboratory to meet the defined and intended role of the system. So we will start at the beginning and look at the first stages of the SDLC (a defined life cycle is one of the foundations of computer validation that will be discussed in more detail in Chapter 4):
• Defining and controlling the validation throughout the whole life cycle (writing the validation plan)
• Specifying what you want the system to do (writing a user requirements specification, URS)
• Selecting the system using the requirements defined in the URS on an objective basis rather than a glossy brochure.
1.4 Book Structure: Life to Death of a CDS
The structure of this book is presented graphically in Figure 1. It contains seven phased themes with the remaining chapters divided amongst them that cover the complete life cycle of a CDS. Each will be described in more detail in the remaining sections of this introductory chapter. You will find this figure a useful starting point when starting or returning to this book. Figure 2 shows how the chapters link with the process for specifying a CDS through to when the system first goes live within a laboratory. Figure 3 shows the chapters related to maintaining the validation of the system throughout its operational life and into system retirement.
1.4.1 Chapter Structure
The majority of chapters in this book are written in the same way:
• The chapter starts with a brief overview why the chapter is important within the overall scheme of CDS validation.
• This is followed by a section of regulatory requirements that are relevant to the chapter; thereby positioning the regulatory rationale for what you are doing.
• Where appropriate, there is also the business rationale for the tasks contained in the chapter.
• Then there is a discussion of how to achieve the objective of each chapter. For example, if you are writing the URS, how this can be achieved and how to avoid some of the common pitfalls. The aim is to give any reader the practical basis and confidence to work on any subject covered by this book.
The intention of this approach is to put...
