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 the regulatory and business rationale for performing a task at the reader's fingertips. It also allows an individual chapter to stand alone if a quick reference on a specific topic is all that is required.
1.4.2 Understanding the Basics
Chapters 2–4 are used to introduce the topic of CDS validation and set the scene for the remainder of the book:
• Introduction to CDS
• Regulatory requirements for CDS validation
• Key terms and concepts of computer validation
If you are new to the subject, these chapters are intended to give you an understanding of the topics and to lead to further reading if necessary.
1.4.3 Planning the Work
Planning any validation is critical and Chapters 5-8 cover, respectively:
• CDS validation: managing risk
• Exploiting the business tangible benefits of electronic signatures with a CDS
• Writing the URS
• Controlling the validation: the validation plan
The first question to be asked is do I need to validate the system or not, therefore we start our validation journey by asking this fundamental question. Once decided we need to plan the work, this is the foundation for the overall quality of the validation. Quality is designed and not tested into a system. The whole process must be controlled and a clear idea of what will be expected at the end of the validation is documented before the real work starts.
Understanding the process is an important part of implementing and validating a new CDS – with or without the use of electronic signatures or implementing electronic signatures in a new version of an application. Therefore, we consider this question early in the book. The choice of writing the URS before the validation plan reflects the practical situation found in many laboratories, the requirements are written before selecting the system which will then be validated. Therefore, the URS comes before the validation plan in this book.
1.4.4 Selecting the System
Chapters 9–11 cover the system selection phase:
• System selection
• Auditing the CDS vendor
• Contract, purchase order and planning the installation
The aim of these chapters is to have the right tool for the right job that has been correctly developed by the right vendor. Make sure that there is sufficient emphasis at this stage of the life cycle as once the system has been purchased there will be no opportunity to change for a long time.
If your CDS has already been purchased and you are validating an upgrade to the system, then this section of the book can be omitted if required.
1.4.5 Installing and Testing the System
A major part of the life cycle before the system goes live is the installation and testing of the system covered in Chapters 12–15:
• Risk assessment and requirements traceability
• Installation qualification and operational qualification (IQ and OQ)
• Performance qualification (PQ) or end-user testing
• Training and system documentation
Deciding what user requirements to test and where they are tested is based on risk assessment and traceability matrix, respectively. Then the system components must be correctly installed and work as described in the URS to demonstrate fitness for intended purpose. The use of a CDS vendor's material for IQ and OQ must be assessed critically to see the value for money that you will be obtaining and if you can reduce any PQ testing if the vendor material matches your written requirements.
There is a detailed discussion of what is PQ or end-user testing and how to design and execute test procedures. A vital part of the validation is to ensure all users are correctly trained and there are written procedures available to follow.
1.4.6 Support and Release of the System
Three chapters (16–18) discuss the supporting documentation required before the system goes live as well as what you do if you have an existing system to validate (Chapter 19):
• IT support and maintenance
• System description
• Validation summary report
Critical functions of all CDS systems will require backup and restore plus other IT functions; how are these controlled? As a system description is required for regulatory reasons, a chapter provides how this is can be written. The whole validation effort is reported in a summary report along with a release statement signed by the system owner.
1.4.7 Maintaining the Validation and Upgrading the System
The easy job is over and the biggest validation challenge remains: maintaining the validation throughout the operational life of the system which may be many years. Chapters 19-22 present:
• Defining electronic records for a CDS
• Maintaining validation status during operational life
• Records retention
In preparation for inspections, how can you define and document the electronic records that your CDS will produce and also the steps you must take to maintain the validation status through its operation life. The various options for retaining the records produced by a CDS are discussed.
1.4.8 Data Migration and System Retirement
The final stages of the life cycle of a CDS are data migration and system retirement; these topics are covered in Chapters 23 and 24:
• CDS data migration
• System retirement
How critical are your CDS data? If your system is obsolete and needs to be retired you need to migrate the data to a new system or select an alternative approach. Afterwards the components of the system are formally retired.
1.4.9 Retrospective Validation of a CDS
Existing CDS applications operating in regulated laboratories that have not been validated will need to comply with regulations retrospectively. As the concept of computer validation in the pharmaceutical industry has been discussed since the early 1980s, there should not be many systems that fall into this category. However, from experience this is not the case. Therefore, the final chapter in this book briefly covers retrospective validation and shows how to perform a gap and plan analysis and links back to the other chapters in this book for the detail of how to carry out the remedial activities.
1.4.10 Use Your Organisation's Computer Validation Policy
The approaches outlined in this book need to be tailored to fit with the computer validation policy of the reader's organisation. Some organisations are more conservative than others and therefore more work will be done than outlined here. In contrast, some companies may want to do less than I present in the following chapters. The choice is yours. Computer validation has some elements that are given and are not open for discussion. In other areas, there is a degree of interpretation; is my interpretation closer or further away from yours?
1.5 Assumptions, Exclusions and Limitations
Owing to the size and scope of this book, there are some of the assumptions, exclusions and limitations of what can be covered in the validation of CDS.
• I assume that your organisation has a corporate computer validation policy available. You will need to interpret the approach outlined here for your specific corporate requirements. We discuss the principles of a CSV policy in Sections 1.4.10 and 4.8 but do not discuss the detail of computer validation policies or validation master plans any further.
• Network infrastructure is assumed to be qualified and under control within your organisation and therefore will not be covered. The exception is Chapter 13 where the IQ and OQ of the CDS database server is mentioned briefly.
• In this book, I make few references to the Good Automated Manufacturing Practice (GAMP) guidelines apart from Appendices M3 and M4 (risk assessment and validation strategies for different classes of software, respectively).The issue is that GAMP provides an overall framework for validation of automated manufacturing equipment as well as software applications. Note here the use of the word 'framework'. In my opinion, there is not enough detail in GAMP to really provide sufficient practical advice to help you validate a CDS. Institute of Electronic and Electrical Engineers (IEEE) software engineering standards, on the other hand provide much more detail and therefore selected and relevant IEEE software engineering standards that are referenced in preference, where appropriate, to GAMP within this book.
• The chromatographic equipment interfaced to a CDS will not be discussed in detail and is assumed to be qualified and working correctly.
CHAPTER 2
Introduction to Chromatography Data Systems
Chromatography is an analytical technique used in virtually all sectors of the pharmaceutical, medical device and biotechnology industries to detect or quantify compounds during the course of product development and manufacture. It can be used for the assessment of active ingredients, raw materials, impurities and determining the stability of active in final preparations. The chromatograms generated by these analytical methods are displayed, integrated and results calculated by a software application called a chromatography data system (CDS).
2.1 What is a Chromatography Data System?
This section discusses the operation of a CDS from the perspective of a typical laboratory process or workflow. Figure 4 shows the main features of a CDS and Figure 5 shows the overall sequence of events that a typical data system should perform. This is a generalised approach to the operation of a "typical" data system; further details on the subject are the Royal Society of Chemistry monograph by Dyson, the book by Fellinger on Data Analysis and Signal Processing in Chromatography and in the chapter and articles by McDowall.
This understanding is important as detailed knowledge of how a specific CDS application works is essential to write and maintain a user requirements specification throughout the operational lifetime of any system.
2.1.1 Types of Chromatography Data System
A CDS can come in one of the following types:
• integrator (single user and single instrument data acquisition)
• workstation (typically a single user with single instrument data acquisition and control)
• client–server (multiple user and multiple instrument data acquisition with an option for control)
• terminal server (multiple user via a terminal server farm with multiple instrument data acquisition with an option for control)
