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