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.

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.

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.

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.

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.

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.

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.

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.

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.

The URS should be updated after system selection or if upgrading an existing CDS installation to document the features of the CDS to be installed in the laboratory. Chapters 16–20 cover the detail of carrying out a risk assessment on the requirements, the traceability matrix, documenting the IT system and the software configuration used and installation and integration of the delivered system with the chromatographs in the laboratory.

• Chapter 16: CSV Risk Management at the Requirements Level. The project team needs to document the risk assessment to determine where the greatest risk is and how it is to be mitigated. Two ways of doing this will be demonstrated in this chapter.

• Chapter 17: Requirements Traceability. If the URS is the most important document in the validation suite, the traceability matrix is the second most important document, provided it is written early in the project and not as an academic afterthought at the end.

• Chapter 18: Writing the Configuration Specification. Software settings or configuration of the CDS can be documented either as an appendix of the URS or as a separate but linked configuration specification. Regardless of the approach taken, the important message is that the software configuration is formally documented as a project deliverable as it and the URS defines the intended purpose of the CDS.

• Chapter 19: Writing the Technical Specification. This document records how the IT servers will be set up and established for the system. If required, it may specify if a training instance will be used or not and if physical or virtual servers will be used for any instance of the CDS.

• Chapter 20: Installing and Integrating the System Components. This phase can also be considered the installation qualification (IQ) and operational qualification (OQ) of the components and will be divided into a number of phases: IT components, CDS software, data servers in the laboratory, chromatographs plus the integration and checkout to show that the overall system works from the perspective of the supplier. The use of a CDS supplier’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 supplier’s qualification materials match your written requirements.

In a major change compared with the first edition of this book, user acceptance testing or performance qualification (PQ) is expanded from just a single chapter to three chapters (Chapters 21–23).

• Chapter 21: Designing the Test Suite. The requirements to be tested need to be organised into related functional areas that will comprise the test scripts in a test suite. Thought needs to be given to making the test suite as efficient as possible where data acquired under one test script can be used for another purpose to test different requirements with the overall aim of speeding up the testing phase of the validation.

• Chapter 22: Writing Test Cases. The ways to write test cases will be presented in some depth to gain the best understanding of this process including any preparation for executing the test. One key question is how much detail is required in the test instructions for trained users to execute and this will be debated in this chapter.

• Chapter 23: Executing Test Scripts. How test scripts are executed, paper and electronic documented evidence collated and how tests meet pre-defined acceptance criteria are discussed. In addition, how to document and handle test problems and deviations is covered.

Five chapters (Chapters 24–28) discuss the supporting documentation required before the system is formally released at the end of the initial validation and goes live:

• Chapter 24: User Training and System Documentation. Procedures for using the CDS as configured for your laboratory are essential and they will document how the system will be used in the laboratory. These procedures are essential for training the users. In addition, there needs to be management leadership for data integrity and the associated training of staff. Most importantly, this chapter deals with more detail of the second person review that was started in Chapter 7, see Section 1.4.12 for more details.

• Chapter 25: IT Support. There will be IT support procedures required for the CDS such as backup/recovery, change control, database administration and server performance monitoring. Some of the key topics have their own chapters later in this book, such as user account management, change control and configuration management, incident and problem management.

• Chapter 26: System Description. Critical systems under the revised EU GMP Annex 11 require a system description and this chapter will present what should be covered in such a document.

• Chapter 27: Defining CDS Raw Data and Electronic Records. Both FDA and EU GMP Chapter 4 require that electronic records/raw data, respectively, should be defined and this chapter will present how this should be undertaken.

• Chapter 28: Validation Summary Report. The whole validation effort is reported in a summary report along with a release statement signed by the system owner and, if appropriate, quality assurance.

The easy job is over but the biggest validation challenge still remains: maintaining the validation throughout the operational life of the system, which may be many years. Figure 1.3 shows how the remainder of this book is structured and Chapters 29–33 present the following topics:

• Chapter 29: Integration in a Regulated Environment: This is a key aspect of data integrity with a CDS as there have been many citations for lack of an SOP for integration or manual integration. This chapter explores the poor regulatory requirements for and lack of any accepted definition of manual integration and proposes a logical approach to the problem.

• Chapter 30: User Account Management. The assignment and management of unique identities and access privileges is a critical part of ensuring the data integrity of the CDS. To prevent reuse of user identities any old ones need to be disabled and not deleted. Administrators for the CDS will be needed in both the laboratory and the IT department and the chapter explores how these two roles should be split.

• Chapter 31: Incident and Problem Management. Incidents and problems with the operational CDS need to be documented, investigated and resolved where appropriate. Occasionally this may require the changes to the system that is the subject of the next chapter.

• Chapter 32: Change Control and Configuration Management. No system retains the initial configuration for long once operational as changes will occur in all layers of the system. Controlling these changes and managing the overall system configuration is essential for maintaining the validation status of the CDS.

• Chapter 33: Conducting a Periodic Review. An independent periodic review of the CDS is essential to ensure that the system is still operating in conformance with procedures, regulations and that the validated status is maintained. Although this was a good practice it is now a regulatory requirement under the current version of EU GMP Annex 11.

The final stages of the life cycle of a CDS are data migration and system retirement; these topics are covered in Chapters 34–36:

• Chapter 34: CDS Records Retention. The various options for retaining the records produced by a CDS are discussed.

• Chapter 35: System Retirement. If your system is obsolete and needs to be retired you may need to migrate the data to a new system or select an alternative approach. Afterwards, the components of the system are formally retired.

• Chapter 36: Data Migration Options. How critical are your CDS data? If on-going data (e.g. validation records, stability studies) are required in a new CDS this chapter will look at the options for ensuring that records can be transferred to a new system and produce similar results.

Existing CDS applications operating in regulated laboratories that have not been validated will need to comply with applicable 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, 37, 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. Note that since 2011 the regulatory ability under EU GMP Annex 11 to conduct retrospective validation has been removed.

The addition of data integrity to the sub-title of this book means that the subject is covered in a number of specific chapters:

• Chapter 7 for an overview of the topic.

• Chapters 8–23 in validating the system for intended use including ensuring that controls for electronic records integrity are enabled, documented and validated.

• Chapter 24 ensuring that users are training both in the system and good data integrity practices.

• Chapter 30: User account management to ensure the separation of administration accounts from user accounts to avoid potential conflicts of interest and ability to falsify data.

• Chapter 33: Under the umbrella of a periodic review there will be data integrity audits of the system and the data generated.

In addition, other chapters will contain requirements and suggestions for ensuring data integrity within the system.

With the publication of several data integrity guidance documents from various regulatory agencies, it is clear that increased emphasis and importance is being placed on the second person review process. This is not only to ensure that data are complete, consistent and accurate and that all applicable procedures have been followed but that data have not been falsified. For the latter, the use of technical controls within the CDS that prevent any normal user from deleting data, changing a processing method or saving data in a different area of the system to hide test injections must be implemented throughout the system. This can help focus the reviewer on the data checks at hand rather than searching throughout the system.

In this book the focus on the second person review is in four main chapters:

• Chapter 7 on data integrity looks at risk based audit trail reviews. In many systems there are two audit trails one focused on system level events and one on data events. The latter should be the main focus of a second person review. The type of work performed is also a factor influencing whether or not to review audit trail entries.

• Chapter 9 looks at electronic working and highlights the use of database filtering to highlight areas where a second person review should occur. If the process is validated, then the audit trail review can be undertaken by exception. Only where there is a change should the second person look in more detail.

• Chapter 24 is focused on training and documentation for the system. There is a discussion on the second person review that requires the background of Chapters 7 and 9 to understand fully.

• Chapter 33 covers periodic reviews and data integrity audits, there are areas in the latter topic that can be applied to a second person review.

The approaches outlined in this book need to be tailored to fit with the computer validation procedures 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 to or further away from yours?

It is inevitable that the terminology that I use in this book may not be the same as used by all readers. For example, there will be no mention of a functional specification in this book but we will present and discuss technical and configuration specifications. From my perspective, it matters less what a reader and the author call a document, what is important is that the content of a document described here is part of a CDS validation project for the business and regulatory reasons stated at the start of each chapter.

The problem with validation of a chromatography data system used for either GLP or GMP in the pharmaceutical industry is that it always takes too long. Why is this? We will look at ten critical success factors for reducing the time to validate a core system to around 3 months without compromising the quality of the system. This is achieved by managing regulatory risk effectively and resourcing the project adequately.

Here, I would like to focus on what is needed to ensure a rapid validation of a CDS while maintaining the overall quality and managing regulatory risk. I’ll look at how CDS validation is typically conducted today, what we should aim to achieve in a rapid validation project and my ten critical success factors for such a project. Before we discuss these areas, I am assuming two things that I will not discuss further. First, the CDS is a multi-user networked system and secondly, the users will be working with electronic signatures and keeping paper output from the system to a minimum.

Typically, many CDS validation projects take between six months (if you are lucky) and 18 months (if you are not) to validate the core system and then roll out the system to the rest of the user base in the laboratory. This means that in the worst case when you have finished the current validation, the CDS supplier has probably released another version of the software for you to implement and validate. In the current economic environment, it may be a way of preserving validation jobs. Owing to the time and resource to validate each release, at best a laboratory will only implement every other release of CDS software, which makes it difficult for a supplier to offer effective support when there could be up to five supported releases in the customer base at any one time.

In an ideal world, a CDS validation should be fast and efficient. Here is an outline example:

• A laboratory would have written down their user requirements and have a good reason for the purchase of a particular system.

• The project team would be trained and have access to the CDS from the first days of the project so that they could understand the nuances of the way the software works and how it will be configured (including custom calculations and custom reports). In this way the user requirements would be refined to fit the purchased system rather than a generic CDS.

• Risk management would work in conjunction with what the supplier has done to focus testing down to show that the system works in your environment.

• Work on configuring the system with input of calculations and report templates will continue after the system has completed its validation and therefore as this aspect is, in my opinion, best controlled by procedure it allows the process to be decoupled from the validation of the application software.

• Test the system based on the process flows defined in the software and reflected in the URS and configuration specifications.

An aggressive timescale for validation of the core system could be 3–4 months. This is an achievable target but depends on a number of factors that will be discussed below.

In any CDS validation, especially of larger systems, we should aim for the validation of a core CDS to have an achievable target to aim for the validation. Therefore, from this we have an implicit statement that we will be staging the validation in a number of phases. So what constitutes the core system? To give the classic consultant’s response – it depends. The factors influencing this are:

• The range and complexity of chromatographic analysis carried out by the laboratory requiring custom calculations and reports to be input to the new CDS.

• The experience that the laboratory has with the data system to be validated (impacting the ease with which decisions can be taken regarding configuration of the software and writing custom calculations and custom reports).

• Training needs of the user base – experienced users would obviously require much less than those who were completely new to the system.

• How big is the laboratory where the CDS will be implemented? Users of the new CDS will be less productive until they are fully acquainted with the system compared to when they operated the old system. As the laboratory will not be able to stop work, then committing the whole laboratory to the new system is not an option usually considered by laboratory management.

Therefore, the core system could vary in size from about five to twenty chromatographs. This gives the project team the phase 1 validation target to aim for but they must also consider the whole system. Reducing the size of the initial target to hit means that the user acceptance testing (UAT) or performance qualification (PQ) can also be phased and this will be discussed in more detail in the next section.

Ten critical success factors (CSFs) are for a rapid CDS validation are listed in Table 1.1 and will be discussed in more detail below under each heading. There is no particular priority order of these CSFs in the table and the text of this article.

Laboratory management can make or break any validation project by either refusing to resource it adequately (expecting the users to still carry out their normal duties as well as working on the project) or by unrealistic demands (I want it tomorrow, sorry yesterday). In either case the project will suffer and the laboratory will end up with a poor and rushed validation.

Therefore, this CSF has two aspects to it. First, management must set realistic and achievable goals, deadlines and expectations for the project team to achieve and keep to it. Secondly, management have to get out of their offices and talk publically to the chromatographers who will be user base to ensure positive support for the system and to support the CDS validation project team. Ideally, management should change individual’s objectives to ensure that their role working on the project team or supporting the implementation is a part of each analyst’s overall performance goals.

It is important to understand one of the reasons that CDS validation projects take more time than anticipated is that the people working on the project are trying to do two jobs: their normal one and the CDS project. Something has to give and it is usually the CDS validation project, especially if there are high priority samples to analyse. Therefore, it is the role of management to ensure that the project is adequately resourced. The selection of the people to work on the project is a critical success factor and requires experienced chromatographers who, in my view, should work on the project full time if an aggressive 3-month time schedule is to be met. If these chromatographers have experience of using the selected CDS so much the better as these people can provide other project team members who have little or no experience help. Depending on the size of the system to be implemented and the number of users this can vary typically between two to seven members. One option for laboratory management to consider is the use of temporary staff to cover for project team members or the use of contract laboratories for some of the analytical work normally performed in-house.

Always remember that a CDS project requires a multi-disciplinary approach: IT and QA are also involved and the laboratory on their own cannot deliver a successful CDS validation project. QA and IT individuals on the project will not be full time but need to be kept involved with the progress of the project, asked for input to key activities and notified when documents will be available for comment and approval.

CSV requires a life cycle model and typically the pharmaceutical industry uses a classical V model approach as we shall look at in more detail in Chapter 6. However, the classical V model does not reflect what you will be doing on a CDS validation project as there is no extensive configuration or customisation of the system. For a typical CDS validation project you will not need to write a functional specification or a design specification as the software does not require any custom code to perform their function as most of what you need comes out of the box (e.g. instrument control, data acquisition and data processing). What you do need to document is the configuration of the software how you want the application to work with electronic signatures, user account management (user types and access privileges), custom calculations and reports. Thus, a simplified life cycle model is essential to reduce the number of documents needed in the validation which we will discuss in Chapter 6.

Further easing of the way a system is validated is that some tasks can be adequately controlled though procedures. Custom reports and custom calculations are a case in point, these can be procedurally controlled as they will continue to be developed long after the whole system has been validated. However, the SOP needs to include the specification and testing of each report or calculation in enough detail so that it can be tested and then integrated into the CDS so that the system retains its validation status.

As mentioned above, this is a critical success factor that will determine the (non-) progress of the whole project. We have looked at the general user base earlier but I want to focus on a specific group here. Project team members from the laboratory will likely become local application administrators for the laboratory and will be the first line for resolving problems with the system (e.g. power or super users to use some terminology). Therefore, they need to have a good technical understanding of the application to help specify, configure and test the CDS. Even if they are experienced users at the chromatographic level, further training will be needed to understand the technical level of the CDS to ensure that they can contribute fully to the project and beyond. If there is a time problem, then outsourcing of custom calculations or laboratory reports to the CDS supplier could be one option to keep the project on time.

The role of Quality Assurance (QA) is often maligned and misunderstood; they are the guardians of quality but are often seen as ultra conservative. However, you must have QA on your side if you want to get the CDS validation project through in tight timescales. Key project documents must be reviewed and approved by QA to see that they meet company and regulatory requirements. If you want to modify the validation approach and omit one or two stages of work that would normally be done, how would you approach QA if there was an antagonistic atmosphere?

You must get QA on-side with the project and communicate and explain why you want to do tasks a certain way that is different from a typical validation project. This is especially important at the start of the project when the initial planning takes place to define both the overall timelines but also when key documents are expected to be available for QA review. If you do not inform QA that a document is to be reviewed around a certain date, do not be surprised if you are told the document goes to the back of the queue. If the project wants to do something different to the normal computerised system validation procedure you need to keep QA informed. Working with QA is infinitely better than working against them.

The words IT and compliant in the same sentence can often seem strange and can be met with scepticism, but this is an essential part of the CDS validation project as the software has to run on the network operated by IT. Note also that there is the word effective in the CSF. It is no good being compliant but the network is slow or the hardware is delivered late or is unreliable. The project needs to have technical input from IT on the design phases of the project, to carry out the installation and qualification of the servers, operating system and the database but also operate the system when the CDS is released for operational use.

If the CDS has over 25 or so users then the technical architecture could benefit from the use of terminal emulation. Instead of installing the CDS application software on each PC in the laboratory and qualifying it, the software is installed once on a terminal emulation server (typically running Citrix) and it is qualified once. Users in the laboratory will then log onto the system via an applet running on their PCs but apart from that there is little difference in the way that they interact with the CDS.

The benefit from using terminal emulation from the project’s perspective is that there is a single software installation followed by a single installation qualification and operational qualification. For a core system this may not have much of an impact but if the overall installation is greater than 50, then the use of terminal emulation will save much time and effort. The other side of the coin is that the IT department needs to have the expertise to install and operate a terminal emulation system. The alternative is the classical client-server installation and qualification of the CDS application on all laboratory PCs described above.

Active involvement of IT for user account management and system administration is essential for data integrity. Giving laboratory users system administrator privileges can be seen as a conflict of interest by regulatory agency inspectors. To avoid this, IT should administer the application as discussed in Chapter 30. This is another reason for IT staff to be involved with the project from the early stages.

The supplier of the CDS software has a role to play in the project from provision of technical advice (server and disk size for the laboratory), training (both regular users but also administrators), quality system development and support of the CDS application, supply of qualification documentation and professional services. Training has been discussed in earlier CSFs above and technical advice is an area where there can be very useful input from the CDS supplier in the technical architecture that needed to run their product efficiently. However, I would like to focus here on two aspects, first, the quality development and support of the CDS application and secondly, the supply of qualification documentation for the project.

During the development of the software, the supplier will test the software many, many times. If these functions are not configured when the software is installed why do you need to retest them? The problem is how to justify a reduced testing approach? This is where a supplier can help the validation project. If a summary of the in-house testing of the CDS could be available to the project, it would provide the documented evidence to justify a reduced testing approach in some areas. Note that this is not a carte blanche to not test anything as the project will still have to demonstrate fitness for purpose in the laboratory environment.

The other specific area that a supplier can be useful is the provision of qualification documentation for the CDS. This is a two edged sword and it really is an issue of caveat emptor (buyer beware). There are very specific regulatory requirements in US and EU GMP for review and approval of documents used in any validation and use of supplier supplied documentation could mean that the laboratory generates non-compliances. Why, you may ask? The reason is that the laboratory must review and authorise qualification documentation before it is executed, but there is not often any space for you to do this. The supplier’s engineer pops into the laboratory executes the protocols and leaves them for one of the project team to review and approve. This is wrong and suppliers must be more responsible and professional in this area.

To cement all the different disciplines and tasks together it is essential to have effective project planning. The project needs to be broken down into the component tasks that when completed will deliver the validated core system. One problem in project planning is to break the project down into enough detail but not too much or too little. For each task allocate the individuals who will be responsible for each one, e.g. for writing the URS, there would be a responsible individual who would need to coordinate the writing of the document and liaison with IT and QA to ensure that the inputs from these groups are elicited. Also, if there is a document required to support the validation, the review personnel need to be known and the approximate time when the draft will be available so that each individual’s work can be synchronised.

Often, projects plans can be compared with major works of artistic fiction, so to avoid this label, project plans need to be refined and updated to allow for change time or the addition or elimination of tasks. The timetable for the validation of the core system will be aggressive but the allocation of time for each one must be realistic.

Once the overall system has been specified in the URS, the project team then needs to concentrate on the validation of the core system to ensure that the timescales of the project can be achieved. Otherwise, looking at the core and well as the whole system will be a major cause of delay in delivering the core system.

Finesse and subtlety are characteristics not often associated with computerised system validation, however, it is in the design of the overall test suite for the performance qualification (PQ) or user acceptance testing that they need to come to the fore. Leverage as much of the supplier’s testing as possible and focus the laboratory testing to demonstrate that the system works under actual conditions of use and for specific your specific configuration. This will be discussed in much more detail in Part 6 covering user acceptance testing.

Owing to the size and scope of this book, there are some assumptions, exclusions and limitations of what can be covered in the validation of chromatography data systems.

• 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 Chapter 1.4.10 and Chapter 4 but do not discuss the detail of computer validation policies 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 20 where the IQ and OQ of the CDS database server(s) is (are) discussed briefly.