How to Use this Book

This introduction provides an overview of how this book is structured and in which chapter to find information that you require. It also discusses why it takes so long to validate a chromatography data system and provides ten critical success factors that will help manage CDS validation projects.

1.1 Purpose and Scope

Chromatography is a major analytical technique that is used in almost all analytical laboratories in regulated healthcare organisations and contract manufacturing and research companies that support them. 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 or manufacturing organisations, the regulations require that the CDS be validated for its intended purpose according to applicable regulations. However, in today's world where many organisations work in a global market, there are many regulations from different regulatory authorities 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 and to meet all regulatory requirements. The principles outlined here are applicable from small installations to large client server systems for a site and to larger terminal server 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.

Given the current regulatory interest in data integrity, the use of standalone CDS systems for GXP regulated work is not recommended and should be avoided. Furthermore, storing the regulated electronic records on standalone workstations is not recommended as they should be stored on a resilient network server and backed up by the IT department.

Chromatography Data Systems (CDS) are used throughout regulated laboratories in the pharmaceutical and allied industries. The role of a CDS in research and development and production (GMP) can be for determining the impurities of raw materials and finished products, in process control and stability testing, whilst in GLP development laboratories a system can be used for the measurement of a drug and their metabolites in biological fluids from non-clinical and clinical studies to determine the absorption, distribution, metabolism and excretion (ADME) of the compound. Regardless of the role of the regulated laboratory, there is a need to validate to show that the CDS, including LC-MS and LC-MS-MS data systems, are fit for their intended use as required by the applicable GLP or GMP regulations as well as 21 CFR 11 (electronic records; electronic signatures rule) and EU GMP Annex 11.

In this book, I want to discuss the prospective validation of chromatography data system software. By prospective validation, I mean validating the system properly and in advance of it being released for operational use. That is undertaking the validation work in parallel with progress through the life cycle of the project from start to finish and then releasing the system for operational use. 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 between 25-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 adequate quality for laboratories working under GXP regulations. However, some people may approach CDS validation retrospectively and in Chapter 37 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 and 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.

• Data integrity? Do not worry – paper is our raw data.

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 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 life cycle (SLC) 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. If done correctly validation will actually save you money by ensuring that you buy the right CDS for your laboratory to meet the defined and intended use of the system. So we will start at the beginning and look at the first stages of the systems development life cycle (a defined life cycle is one of the foundations of computer validation that will be discussed in more detail in Chapter 6):

• Understanding and optimising the underlying business process.

• 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).

• Selecting the most appropriate system using the requirements defined in the URS on an objective basis rather than a subjective approach using a glossy brochure.

• Updating the user requirements specification and specifying the configuration of the system to reflect the purchased CDS.

• Prototyping to check how you will work electronically rather than on paper.

• Installing and testing the system according to the requirements in the specification documents.

• Writing user procedures and training to use the system.

• Formal release of the system via a validation summary report.

The focus in this book is implementing a CDS with electronic workflows and using electronic signatures.

The use of any CDS as a hybrid system (electronic records with signed paper printouts) is stupid in today's business environment. A CDS with electronic workflows is faster, more efficient and will be better at ensuring data integrity. However, a hybrid CDS may be coupled with use of spreadsheets to perform calculations that could be performed in the CDS but are not because laboratory staff are too lazy to implement them in the CDS.

1.4 Book Structure: Life to Death of a CDS

The structure of this book is presented graphically in Figure 1.1. It comprises nine parts with the remaining 36 chapters divided amongst them that cover the complete life cycle of a validated chromatography data system. 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 1.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 1.3 shows the chapters related to maintaining the validation of the system throughout the operational life and into system retirement.

1.4.1 Chapter Structure

The majority of chapters in this book are structured and written in the same way:

• A 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 or guidance 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 user requirements specification, how this can be achieved and how to avoid some of the common pitfalls.

The intention of this approach is to put the regulatory and business rationale for performing a task at the reader's fingertips and it also allows an individual chapter to stand alone if a quick reference on a specific topic is all that is required. Overall, the aim is to give any reader the practical basis and confidence to perform any of the topics covered by this book.

1.4.2 Part 1: Understanding the Basics

This part has been greatly expanded compared with the first edition of this book and now consists of six chapters that are used to introduce the topic of CDS validation and set the scene for the remainder of the book:

• Chapter 2: Introduction to Chromatography Data Systems. This provides an introduction to the main functions of a chromatography data system, how they have evolved over the past forty years and how they need to evolve in the future for better efficiency and regulatory compliance.

• Chapter 3: Laboratory Informatics and the Role of a CDS. A CDS should not be implemented as a system operated on its own but interfaced and integrated with other informatics systems such as Laboratory Information Management Systems (LIMS) or Electronic Laboratory Notebooks (ELN) to produce an electronic environment and eliminate paper from the laboratory as much as possible.

• Chapter 4: Applicable GXP Regulations and Guidance. Understanding the applicable GMP and GLP regulations in conjunction with regulatory and industry guidance is important to get the balance right between business efficiency and adequate regulatory compliance of the operational system. This is the first stage in that journey and provides the overview of regulations that could be applied to a CDS in an individual laboratory operating to a specific GXP regulation. However, many regulations are complementary and one aim of the chapter is to collate the requirements of different regulations to provide a holistic approach to validation of a CDS.

• Chapter 5: Concepts of Computer Validation. Although confusion may be the first thought when faced with a CDS validation project, it is important to realise that validation is nothing more than good software engineering practices with a compliance wrapper and this chapter introduces the key words, abbreviations and concepts for the reader.

• Chapter 6: Understanding Life Cycles and Software Classification. Computerised System Validation today is based upon two main elements a defined life cycle that varies according to the risk posed by the type of software that is being implemented and the process automated. This chapter looks at the life cycles possible, the documented evidence necessary to support one and all this is dependent on the classification/risk posed by the CDS software.

• Chapter 7: CDS Data Integrity and Security. Since the first edition was published there have been an increasing number of instances where the integrity and security of data generated and stored in CDS systems have been compromised by fraudulent, lazy or incompetent laboratories. This chapter is intended to highlight the key elements from data governance at the corporate level to the detail required to ensure integrity and security of CDS data. It is placed at the front of the book because of the importance of the topic and because many laboratories overlook the issues until noticed by an inspector. The chapter covers data integrity from the boardroom to the laboratory bench and covers items such as data governance, data integrity training and the importance of the second person review. Although there are other references to data integrity throughout this book, the aim of this chapter is to provide the reader with a succinct overview. In addition, this chapter begins the discussion on risk based second person review by looking at which audit trails and the types of work that should be reviewed. This is continued in Chapter 24 and Section 1.4.12.

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. It also provides a current refresher for experienced computer validation professionals who want an update to the subject.

1.4.3 Part 2: Planning the Work

Planning any validation project is critical and Chapters 8-11 cover the following topics in this area:

• Chapter 8: CSV Risk Management – System Risk. 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. Having decided that validation is required 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.

• Chapter 9: Designing the System to Work Electronically. Understanding the business 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. Thus, we consider this question early in the book. It is important to modify the underlying business process first and plan to make efficiencies and eliminate as many spreadsheets as possible, then integrate and configure the CDS application to obtain the biggest business benefit for the investment of time, money and human resources in the overall project.

• Chapter 10: Specifying User and System Requirements. The user requirements specification (URS) is the most important document in the whole validation suite. Requirements defined here will be used to select the most appropriate system and once the URS is updated to reflect the selected system the document will be the basis for user acceptance testing. The choice of writing the URS before the validation reflects the practical situation found in many laboratories, the requirements are written before selecting the system that will then be validated. Therefore, the URS comes before the validation plan in this book.

• Chapter 11: Controlling the Validation. The Validation Plan defines the scope of the system to be validated, the life cycle to be undertaken together with the documented evidence to be produced as the project proceeds. In addition, it defines the people to be involved with the project and what they do.

1.4.4 Part 3: Selecting the System

Chapters 12–16 cover the CDS selection phase. The aim of these chapters is to have the right tool for the right job and that the software has been correctly developed by the right supplier. It is important to 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 the system for a long time. Furthermore, with current GXP regulations, once the system has been selected you may be locked in to the supplier for a long time as transferring data files including the associated metadata from one supplier's system to another can vary from difficult to impossible.

• Chapter 12: System Selection. The aim of the system selection process is to find the right tool for the right job. For this you will need to have documented user requirements so that the selection team does not get seduced by technology and selects the most appropriate system and supplier based on the business and regulatory needs of the laboratory.

• Chapter 13: Auditing the Supplier. The best time to audit a CDS supplier is before the selected system has been purchased. This can be done in several ways and these are discussed in this chapter. If any issues or problems are found it enables the laboratory to seek resolution before the purchase order is generated. In addition, how can the supplier's development and testing work be leveraged into your validation?

• Chapter 14: Contract, Purchase Order and Purchasing the System. Although this appears to be outside of the role of the laboratory this process is important as you want to ensure that the contract terms protect your organisation as well as the supplier and that responsibilities and payment terms are agreed and equitable.

• Chapter 15: Planning the Installation. Many CDS validation projects do not plan where the components of a new CDS will be located and find that there are problems when the system is delivered. This chapter aims to ensure that the project team and hence the supplier and their agents know where items will be located and that you have the space and an adequate number of network points to have a smooth installation of the system.

If your CDS has already been purchased and you are validating an upgrade to the system, then Part 3 can be omitted by a reader.