Validation of Chromatography Data Systems

Ensuring Data Integrity, Meeting Business and Regulatory Requirements

2nd Edition
RSC Chromatography Monographs

Series Editor:
Professor R. M. Smith, Loughborough University of Technology, UK

Titles in this Series:

0: Supercritical Fluid Chromatography
1: Chromatographic Integration Methods
2: Packed Column SFC
3: Chromatographic Integration Methods, Second Edition
4: Separation of Fullerenes by Liquid Chromatography
5: Applications of Solid Phase Microextraction
6: HPLC: A Practical Guide
7: Capillary Electrochromatography
8: Hyphenated Techniques in Speciation Analysis
9: Cyclodextrins in Chromatography
10: Electrochemical Detection in the HPLC of Drugs and Poisons
11: Validation of Chromatography Data Systems: Meeting Business and
Regulatory Requirements
12: Thin-layer Chromatography: A Modern Practical Approach
13: High Temperature Liquid Chromatography: A User's Guide for Method
Development
14: High Performance Chelation Ion Chromatography
15: Protein and Peptide Analysis by LC-MS: Experimental Strategies
16: UHPLC in Life Sciences
17: Chromatography of Medicinal Plants
18: Chromatographic Methods in Metabolomics
19: Quantitative In Silico Chromatography: Computational Modelling of
Molecular Interactions
20: Validation of Chromatography Data Systems: Ensuring Data Integrity,
Meeting Business and Regulatory Requirements

How to obtain future titles on publication:

A standing order plan is available for this series. A standing order will bring
delivery of each new volume immediately on publication.

For further information please contact:

Book Sales Department, Royal Society of Chemistry, Thomas Graham House,
Science Park, Milton Road, Cambridge, CB4 0WF, UK
Telephone: +44 (0)1223 420066, Fax: +44 (0)1223 420247,
Email: [email protected]
Visit our website at www.rsc.org/books
Validation of Chromatography
Data Systems
Ensuring Data Integrity, Meeting Business
and Regulatory Requirements
2nd Edition

R. D. McDowall
R.D.McDowall Ltd, Bromley, UK
Email: [email protected]
RSC Chromatography Monographs No. 20

Print ISBN: 978-1-84973-662-6

PDF eISBN: 978-1-78262-407-3
EPUB eISBN: 978-1-78262-980-1
ISSN: 1757-7055

A catalogue record for this book is available from the British Library

© R.D.McDowall, 2017

All rights reserved

Apart from fair dealing for the purposes of research for non-commercial purposes or for
private study, criticism or review, as permitted under the Copyright, Designs and Patents
Act 1988 and the Copyright and Related Rights Regulations 2003, this publication may
not be reproduced, stored or transmitted, in any form or by any means, without the prior
permission in writing of The Royal Society of Chemistry or the copyright owner, or in
the case of reproduction in accordance with the terms of licences issued by the Copyright
Licensing Agency in the UK, or in accordance with the terms of the licences issued by the
appropriate Reproduction Rights Organization outside the UK. Enquiries concerning
reproduction outside the terms stated here should be sent to The Royal Society of
Chemistry at the address printed on this page.

The RSC is not responsible for individual opinions expressed in this work.

The authors have sought to locate owners of all reproduced material not in their
own possession and trust that no copyrights have been inadvertently infringed.

Published by The Royal Society of Chemistry,

Thomas Graham House, Science Park, Milton Road,
Cambridge CB4 0WF, UK

Registered Charity Number 207890

For further information see our web site at www.rsc.org

Printed in the United Kingdom by CPI Group (UK) Ltd, Croydon, CR0 4YY, UK
Preface to the First Edition

Why read or even buy this book?

If you are using a chromatography data system (CDS) in the regulated areas
of the pharmaceutical, medical device, active pharmaceutical ingredient and
contract research organisations, you will need to validate the system.
This book will be your guide through the regulations and jargon. It
provides practical advice that can be used directly by you to meet regulatory
requirements and allow a sustainable validation effort for your chromatogra-
phy data system throughout its operational life.
However, computer validation is more than just a means of meeting regu-
latory requirements. It is a strategic business tool.
  
●● How much money has your organisation wasted on computer systems
that fail to meet initial expectations or do not work? If used correctly,
validation is a means of implementing the right system for the right
job. Computer validation is quite simply good business practice that, if
followed, provides regulatory compliance for no additional cost.
●● In addition, implementing electronic signatures with electronic ways
of working will allow a laboratory to exploit tangible business benefits
from regulatory compliance. This requires more time spent mapping
and analysing the current working process and practices but the pay-
back is reduction of tedious tasks such as checking for transcription
errors in the laboratory and tangible time and resource savings.
  
This book is intended to help the reader to validate their CDS in the
current risk based regulatory climate and is written by a chromatographer

RSC Chromatography Monographs No. 20

Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

v
vi Preface to the First Edition
with extensive experience of validating many different computerised systems
in many different organisations since 1986.
The principles and practices of validation outlined in this book are also
applicable to other types of computerised systems used in laboratories.
Bob McDowall
Bromley, UK
Preface to the Second Edition

The importance of validation of laboratory computerised systems operat-

ing in regulated laboratories has not changed and is indeed become more
important since the publication of the first edition of this book. Since 2005,
there has been detection of increased fraud and falsification involving chro-
matography data systems, as evidenced in FDA warning letters and citations
by other regulatory authorities. Coupled with this, are poor data manage-
ment practices that have also resulted in increased regulatory scrutiny of
these systems as often chromatographic analysis can constitute up to 100%
of a GXP regulated laboratory’s workload. This results in the detailed exam-
ination of the system: the validation, change control as well as the integrity
of the electronic records/raw data generated.
In addition, there have been many regulatory changes since the first
edition:

●● A United States Pharmacopeia general chapter <1058> in 2008 on ana-

lytical instrument qualification (AIQ) and a new version published in
USP XXXX 1st Supplement.
●● The Food and Drug Administration (FDA) has produced guidance
including an updated compliance program guide for pre-approval
inspections where one of the three objectives is a detailed examination
of the laboratory data contained in a regulatory submission as well as
data integrity guidance.
●● In Europe, EU GMP 8 of the 9 main chapters of Part 1 have been revised
plus Annex 11 on computerised systems and Annex 15 on qualification
and validation.
●● Data integrity guidance has been published by the UK regulatory agency
(Medicines and Healthcare Products Regulatory Agency), the World
Health Organisation, the FDA, PIC/S and EMA.
RSC Chromatography Monographs No. 20
Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

vii
viii Preface to the Second Edition
●● GAMP Forum have published the second edition of the good practice
guide on risk based validation of laboratory computerised systems and
an updated electronic records and data integrity guidance.

All of these documents have resulted in changes to validating and operat-

ing computerised systems in general and chromatography data systems in
particular as well as the way of managing the electronic records that these
systems generate and process.
As a result of regulatory changes, the second edition of this book has grown
from 25 to 37 chapters, (about three times the size of the first edition) and the
content of each chapter is greatly expanded with more practical detail to help
the reader in their task of validation and operational control of a chromatog-
raphy data system. Moreover, the sub-title of the book has been amended to
reflect the current regulatory interest in data integrity.
As with the first edition of this book, the principles and practical
approaches described here are applicable to other computerised systems in
regulated laboratories.
Bob McDowall
Bromley, UK
Biography

Bob McDowall is an analytical chemist with over 45 years of experience. After

graduating from the University of Newcastle-upon-Tyne in 1972 he completed
his PhD at the Department of Forensic Medicine, London Hospital Medical
College, University of London in 1977. Then, he worked for two major inter-
national pharmaceutical companies working in bioanalysis for 15 years. In
1990 he was a co-chair of the first Bioanalytical Methods Validation meeting
that was co-organised by the American Association of Pharmaceutical
Scientists and the Food and Drug Administration. He was a co-author of the
subsequent publication that was a major input into the FDA’s Guidance for
Industry on the subject issued a few years later.
In 1993 he set up his consultancy practice. Initially, this was McDowall
Consulting but this entity was replaced by R. D. McDowall Limited, founded
in 1998.
Bob’s interests are process improvement, laboratory informatics, com-
puterised system validation including Part 11 and data integrity, quality
software development, interpretation of GXP regulations and laboratory
automation. He is also a trained auditor working in the GLP, GMP and GCP
areas.
He has published widely for over 40 years including editing the first book
on LIMS in 1987 and for his work in training and advancement of the sub-
ject he was presented with the 1997 LIMS Award by the LIMS Institute. Bob
has written the Questions on Quality column in LC-GC Europe since 1993
and the Focus on Quality column in Spectroscopy since 2000. He is also a
presenter and trainer giving many presentations and short courses in his
subject areas.

RSC Chromatography Monographs No. 20

Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

ix
x Biography
He has been a contributor to the GAMP Good Practice Guides for IT Compli-
ance (2005) and Control and Risk Based Validation of Laboratory Computerised
Systems second edition (2012). Bob was a co-author of a stimulus to the revision
process of United States Pharmacopoeia general chapter <1058> in January 2012
and the final version will be published in USP XXXX 1st Supplement in 2017.
Acknowledgements

I would like to thank Neil Lander, Heather Longden, Loren Smith and Paul
Smith for their help in obtaining figures used in this book. In addition,
I appreciate the review and comment by Chris Burgess and Mark Newton
during the preparation of the text.

RSC Chromatography Monographs No. 20

Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

xi
Contents

Chapter 1 How to Use this Book  1

1.1  urpose and Scope 

P 1
1.2 The Way It Was…  2
1.3 The Way It Should Be…  3
1.4 Book Structure: Life to Death of a CDS  3
1.4.1 Chapter Structure  4
1.4.2 Part 1: Understanding the Basics  6
1.4.3 Part 2: Planning the Work  7
1.4.4 Part 3: Selecting the System  8
1.4.5 Part 4: Risk, Traceability, Configuration,
Installation and Integration  9
1.4.6 Part 5: User Acceptance Testing  10
1.4.7 Part 6: Supporting Documentation and
System Release  10
1.4.8 Part 7: Maintaining the Validation Status  11
1.4.9 Part 8: Records Retention and System
Retirement  12
1.4.10 Part 9: When All Else Fails: Retrospective
Validation of a CDS  12
1.4.11 Ensuring Data Integrity  12
1.4.12 Importance of the Second Person Review in
Ensuring Data Integrity  13
1.5 Use Your Organisation’s Computer Validation
Procedures  13
1.5.1 Terminology Used in this Book  14
1.6 Why Does it Take so Long to Validate a CDS?  14
1.6.1 CDS Validation: The Way It Is  14

RSC Chromatography Monographs No. 20

Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

xiii
xiv Contents
1.6.2 CDS Validation: The Way It Should Be  14
1.6.3 The Core System  15
1.7 Ten Critical Success Factors for Fast CDS Validation  16
1.7.1 Management Involvement and Backing  16
1.7.2 Dedicated Key Project Team Members  17
1.7.3 Use an Appropriate Life Cycle Model  17
1.7.4 Knowledge of the CDS Application  18
1.7.5 Active and Flexible Quality Assurance
Involvement  18
1.7.6 Effective and Compliant IT Participation  18
1.7.7 Use the Supplier Effectively  19
1.7.8 Planning, Planning and Planning  20
1.7.9 Focus on the Core System  20
1.7.10 Get More from Less Testing  21
1.8 Assumptions, Exclusions and Limitations  21

Chapter 2 What is a CDS? The Past, Present and Future  22

2.1 I ntroduction to Chromatography Data Systems  22

2.2 What is a Chromatography Data System?  22
2.2.1 Types of Chromatography Data System  23
2.2.2 Naming Conventions  25
2.2.3 Data Acquisition Files  25
2.2.4 Instrument Control Files  26
2.2.5 Sequence File  27
2.2.6 Acquisition of Chromatographic Data  27
2.2.7 Management of Data: Database or Files?  28
2.2.8 Interpretation of Chromatographic Data  28
2.2.9 System Suitability Test (SST) Calculations  30
2.2.10 Calibration  30
2.2.11 User Defined Analytical Run Parameters  31
2.2.12 Collation of Results and Reports  32
2.2.13 Architecture of a Networked CDS  32
2.3 Evolution of Chromatography Data Systems  33
2.3.1 CDS: Where Have We Come From?  33
2.3.2 The Evolutionary Ages of CDS  34
2.4 Stone Age: Paper Based Peak Measurement
Techniques  35
2.4.1 Cut and Weigh  36
2.4.2 Ruler and Pencil  36
2.4.3 Disk Integrator  37
2.4.4 Summary of Stone Age CDS  37
2.5 Bronze Age: Electronic Peak Measurement  38
2.5.1 Central Data Systems  38
2.5.2 Computing Integrators  38
2.5.3 Summary of Bronze Age CDS  39
Contents xv
2.6 Iron Age: Expansion to Include Instrument Control  40
2.6.1 Standalone PCs: Extension to Instrument
Control  40
2.6.2 PC Client–Server Networks  40
2.6.3 Summary of Iron Age CDS  41
2.7 Technology Age: Electronic Working and
Regulatory Compliance  41
2.7.1 Migrating from Paper to Electronic Records  41
2.7.2 Part 11 Regulatory Compliance Features  42
2.7.3 Compliant Electronic Working Practices  42
2.7.4 Summary of Technology Age CDS  42
2.8 Think When You Use a CDS  43
2.9 Quo Vadis CDS?  43
2.9.1 Networked CDS Architecture  44
2.9.2 Data Management via a Database  45
2.9.3 Independent IT Support  46
2.9.4 Interfaces to Instruments and Systems  47
2.9.5 Open Data File Formats  47
2.9.6 Method Development Function  47
2.9.7 Analytical Procedure Validation  48
2.9.8 Trending Analytical Data  48
2.9.9 Additional Functions for Electronic
Working  50
2.9.10 Laboratory Investigation Module  51
2.9.11 Documenting Configuration Settings  51
2.9.12 Automated Instrument Qualification  52
2.9.13 Securing Metadata for Ensuring Data
Integrity  53
2.9.14 Improved Audit Trail Review  53
2.9.15 Compliance Control in Unattended Analysis  54
References  55

Chapter 3 Laboratory Informatics and the Role of a CDS  57

3.1 Laboratory Informatics Applications  57

3.1.1 Instrument Data Systems  58
3.1.2 Electronic Laboratory Notebooks (ELN)  58
3.1.3 Scientific Data Management Systems (SDMS)  59
3.1.4 Laboratory Information Management
Systems (LIMS)  59
3.1.5 Application Convergence  60
3.1.6 Data Analysis Applications  60
3.2 Islands of Automation in an Ocean of Paper  61
3.2.1 The Current Situation  61
3.2.2 Interfacing Laboratory Informatics
Applications  61
xvi Contents
3.2.3 W hy Interface Laboratory Informatics
Applications?  62
3.2.4 Interfacing in Detail  62
3.2.5 Overview of Interfacing a CDS to a LIMS  63
3.3 The Role of a CDS in Laboratory Informatics  65
3.3.1 The Laboratory Jig-Saw  65
3.4 The Operating Principles of an Electronic
Laboratory  65
3.4.1 Standalone Data Systems Cannot be
Integrated into an Electronic Laboratory  66
3.5 Developing a Strategy for an Electronic Laboratory  67
3.6 Strategic Planning for an Electronic Laboratory  67
3.7 Systems and the Operating Principles of the
Electronic Laboratory  68
3.8 Phased Implementation of Systems  70
3.9 Justification of Individual Systems  72
References  73

Chapter 4 Applicable GXP Regulations and Guidance for CSV  74

4.1 W
 hen All Else Fails Read and Understand the
Regulations  74
4.1.1 Why Read the Regulations?  74
4.1.2 Approach to Regulations in this Book  75
4.2 Regulations and Guidance Impacting
Computerised Systems  76
4.2.1 Scope of Regulations and Guidance  76
4.2.2 Computerised Systems are Often Equated to
Equipment or Apparatus  76
4.3 Good Manufacturing Practice (GMP) Regulations
and Guidance  78
4.3.1 FDA Good Manufacturing Practice (GMP)
21 CFR 211  78
4.3.2 Update of 21 CFR 211: 2007–2008  81
4.3.3 Inspection of Pharmaceutical Quality Control
Laboratories  82
4.3.4 Compliance Program Guidance 7346.832
for Pre-Approval Inspections (PAI)  83
4.3.5 FDA Guidance for Industry: Circumstances
that Constitute Delaying, Denying, Limiting, or
Refusing a Drug Inspection  84
4.3.6 European Union GMP Regulations  84
4.3.7 EU GMP Part 2 & ICH Q7: GMP for Active
Pharmaceutical Ingredients  85
4.3.8 Japanese GMP Regulations  86
Contents xvii
4.3.9 J apanese GMP Guidance for Computerised
Systems  88
4.3.10 PIC/S Guidance on Computerised Systems in
GXP Environments  89
4.3.11 PIC/S Guidance for Validation Master Plans  90
4.3.12 WHO GMP Recommendations  90
4.3.13 FDA Level 2 GMP Guidance Records and
Reports  91
4.3.14 Good Automated Manufacturing Practice
(GAMP) Guidelines  92
4.3.15 GAMP Good Practice Guide for Validation
of Laboratory Computerised Systems  93
4.4 Medical Device Good Manufacturing Practice  93
4.4.1 An Overview of Medical Device Regulations  93
4.4.2 Quality System Regulation for Medical
Devices: 21 CFR 820  94
4.4.3 FDA Guidance: General Principles of
Software Validation  95
4.4.4 ISO 13485 and EN 62304  96
4.5 Good Laboratory Practice Regulations and
Guidance  96
4.5.1 Overview of GLP  96
4.5.2 Aims of GLP  97
4.5.3 GLP Regulations and Guidance Reviewed  98
4.5.4 US Good Laboratory Practice Regulations
for Non-Clinical Studies (21 CFR 58)  98
4.5.5 Japanese Good Laboratory Practice
Regulations  99
4.5.6 OECD Good Laboratory Practice
Regulations  99
4.5.7 OECD GLP Guidance Document
Number 10  100
4.5.8 OECD GLP Guidance Document Number 17  102
4.5.9 WHO GLP Handbook Second Edition 2009  103
4.5.10 Drug Information Association (DIA) Red
Apple Guidance 1988 and 2008  104
4.5.11 Swiss AGIT GLP Guidance Documents  105
4.6 Good Clinical Practice Regulations  107
4.6.1 ICH Good Clinical Practice  107
4.6.2 Good Clinical Laboratory Practice  108
4.6.3 FDA Guidance Computerised Systems in
Clinical Investigations  109
4.7 21 CFR 11 – Electronic Records and Electronic
Signatures Regulation  112
4.7.1 21 CFR 11 is an Integrated Regulation  112
xviii Contents
4.7.2 I nterpret 21 CFR 11 by the Applicable
Predicate Rule  113
4.7.3 The Need for 21 CFR Part 11 Assessment
of Software  114
4.7.4 Current FDA Activities on 21 CFR 11  115
4.8 European Union GMP Annex 11 and Chapter 4  115
4.8.1 Introduction  115
4.8.2 EU GMP Overview  116
4.8.3 Increased Scope of Annex 11  116
4.8.4 Risk Management Throughout the
Life Cycle  117
4.8.5 New Roles and Responsibilities  117
4.8.6 Suppliers and Service Providers  118
4.8.7 Validation  119
4.8.8 Annex 11 Controls for Ensuring Data
Integrity  120
4.8.9 Electronic Signatures  121
4.8.10 IT Support of Validated Computer
Systems  121
4.8.11 Maintaining Validation  122
4.8.12 What has been Omitted in the New
Annex 11?  122
4.8.13 EU GMP Chapter 4: Major Changes  123
4.8.14 Principle: Define Raw Data  123
4.8.15 Generation and Control of
Documentation  124
4.8.16 Dead as a Dodo: My Raw Data are Paper  125
4.8.17 Retention of Documents  125
4.9 United States Pharmacopoeia <1058> on
Analytical Instrument Qualification  126
4.9.1 Overview of USP General Chapters  126
4.9.2 Origins of USP <1058> on Analytical
Instrument Qualification  127
4.9.3 AIQ Life Cycle  128
4.9.4 The Data Quality Triangle  129
4.9.5 Classification of Apparatus, Instruments
and Systems  133
4.9.6 Problems with the Current USP <1058>  134
4.9.7 Progress Updating USP <1058>  136
4.9.8 What has Changed in the In-Process
Revisions of USP <1058>?  137
4.9.9 Is the Proposed USP <1058> Better?  137
4.9.10 Definition of Qualification  137
4.10 GXP Regulations and Guidance Summary for
Computerised Systems  141
References  141
Contents xix
Chapter 5 Concepts of Computer Validation  147

5.1 W
 hy Bother to Validate Your Software?  147
5.1.1 Investment Protection  147
5.1.2 Consistent Product Quality  148
5.1.3 Compliance with Regulations  148
5.1.4 Ensure Data Integrity  148
5.1.5 Protection of Intellectual Property  148
5.2 What is Computerised System Validation (CSV)?  148
5.2.1 Definitions of Computerised System
Validation  148
5.2.2 Key Concepts of Computer Validation  149
5.3 What is a Computerised System?  150
5.4 What Computer Validation is and is not  152
5.4.1 Principles of Computer Validation  152
5.4.2 Computer Validation Assumptions and
Misconceptions  152
5.4.3 Problems with Computer Validation  152
5.5 Corporate Computer Validation Policy  157
5.6 Changing Approaches to CSV Due to Data Integrity
Issues  159
5.6.1 Traditional Computerised System
Validation  159
5.6.2 Process, Process, Process  160
5.6.3 A Validated System with Vulnerable Records
Means Data Integrity Problems  162
5.6.4 Back to the Future?  162
5.6.5 Brave New CSV World?  163
5.6.6 Turning principles into practice  164
References  165

Chapter 6 Understanding Software Categories and System Life

Cycles  167

6.1 W
 hat Do the Regulators Want?  167
6.1.1 EU GMP Annex 11  167
6.1.2 FDA Guidance on General Principles of
Software Validation  168
6.1.3 Regulatory Summary  168
6.2 Business Rationale  168
6.3 GAMP Software Categories  169
6.3.1 Origins of the GAMP Guide  169
6.3.2 GAMP 5 Software Classification Categories  169
6.3.3 Why Classify Software?  171
6.4 Software Classification Changes and their
Laboratory Impact  171
xx Contents
6.4.1 C ategory 1: Greatly Expanded Scope –
Infrastructure Software  171
6.4.2 Category 2: Ignore the Discontinuation of
Firmware Classification – but with Care  173
6.4.3 Software Silos or Software Continuum?  176
6.4.4 Category 3 Software: What’s in a Name?  176
6.4.5 Category 4: Configured Products Refined  177
6.4.6 Category 4 and 5 Software: Configure Versus
Customise – Where is the Line?  177
6.4.7 Category 5: Custom Applications,
Macros and Modules  178
6.4.8 Users and the Software Screw-Up Factor  179
6.4.9 A Modified Software Classification  181
6.4.10 Do Not Use the Term COTS Software  182
6.5 Why is a System Life Cycle Model Important?  182
6.5.1 Overview  182
6.5.2 Using V Life Cycle Models  183
6.5.3 Do Not Forget Validation Control  184
6.5.4 Category 3 Life Cycle Model  185
6.5.5 Category 4 Life Cycle Model – Complex
Version  185
6.5.6 Category 4 Life Cycle Model – Simple
Version  187
6.5.7 System Life Cycle Summary  188
6.6 Defining the Documentation for a CDS Validation  188
6.6.1 A CDS is GAMP Category 4 Software  188
6.6.2 Compliance Health Warning  190
6.6.3 Interpreting the System Life Cycle
Deliverables for a CDS  190
6.6.4 Document Controls  190
References  193

Chapter 7 Ensuring Data Integrity for Chromatography Data

Systems  194

7.1 What the Regulators Want  194

7.1.1 EU Good Manufacturing Practice  194
7.1.2 EU GMP Chapter 4 on Documentation  195
7.1.3 Overview of Regulatory Guidance for Data
Integrity  195
7.1.4 FDA Compliance Program Guide 7346.832
on Pre Approval Inspections  197
7.1.5 PIC/S Guidance Documents  198
7.1.6 FDA Level 2 Guidance  198
7.1.7 Delaying, Denying, Limiting or Refusing an
FDA Inspection  199
Contents xxi
7.1.8 M HRA GMP Data Integrity Guidance  199
7.1.9 WHO Guidance on Good Data and Records
Management Practices  200
7.1.10 FDA Guidance on Data Integrity and
Compliance with cGMP  201
7.1.11 Regulations and Regulatory Guidance
Summary  202
7.2 What is Data Integrity?  202
7.2.1 A Plethora of Definitions  202
7.2.2 What do the Definitions Mean?  202
7.2.3 Criteria for Integrity of Laboratory Data  203
7.3 Chromatography Data Systems in Falsification
and Fraud  204
7.3.1 A Brief History of Data Falsification and
Testing into Compliance  204
7.3.2 Able Laboratories Fraud Case 2005  204
7.3.3 Overview of Regulatory Citations for
CDS in FDA Warning Letters  206
7.3.4 Quality Management System Failures  207
7.3.5 Equipment Citations  208
7.3.6 Citations for Lack of Laboratory Controls  209
7.3.7 Failure to Have Complete Laboratory
Records  210
7.4 A Data Integrity Model  211
7.4.1 The Concept of Data Governance  211
7.4.2 Layers of Data Integrity  212
7.4.3 Focus on the Laboratory Levels of the
Data Integrity Model  213
7.4.4 Foundation Layer: Right Corporate Culture
for Data Integrity  213
7.4.5 Layer 1: Right Instrument and System
for the Job  216
7.4.6 Layer 2: Right Analytical Procedure
for the Job  216
7.4.7 Layer 3: Right Analysis for the Right
Reportable Result  217
7.4.8 Linking the Data Integrity Model to the
Analytical Process  217
7.4.9 Quality No Longer Owns Quality  219
7.5 Environmental Analysis and an Approach to Data
Integrity  219
7.5.1 Background to EPA and Data Integrity  219
7.5.2 NELAC and Laboratory Accreditation  220
7.5.3 NELAC Quality System  220
7.5.4 NELAC Data Integrity Training  222
7.6 Data Integrity Foundation: Data Governance  223
xxii Contents
7.6.1  anagement Leadership and Oversight 
M 226
7.6.2 Data Integrity Policy  226
7.6.3 Regulatory Requirements for GMP Training  227
7.6.4 Data Integrity Policy Training  229
7.6.5 Open Culture  231
7.6.6 Good Documentation Practice Training  231
7.6.7 Data Integrity Training for a Chromatography
Data System: Operational SOPs  232
7.6.8 Data Integrity Audits and Investigations  232
7.7 Establishing Data Criticality and Inherent Integrity
Risk  234
7.7.1 Regulatory Background  234
7.7.2 Spectrum of Laboratory Processes and
Systems  235
7.7.3 The Data Life Cycle  237
7.7.4 Managing the CDS Data: Data Owners
and Data Stewards  239
7.7.5 System Assessment and Remediation  240
7.8 CDS Compliance Commandments  242
7.8.1 Management are Responsible  243
7.8.2 Understand the Applicable Regulations
for Laboratory Records  243
7.8.3 Use a CDS that is Networked and Uses a
Database  246
7.8.4 Document the CDS Application
Configuration Settings  246
7.8.5 Work Electronically  246
7.8.6 Identify Each User Uniquely and have
Adequate Password Controls  246
7.8.7 Separate Roles with Different Access
Privileges  247
7.8.8 Define Methods that Can and Cannot
be Modified  248
7.8.9 An SOP for Chromatographic Integration  248
7.8.10 Control Changes to the System  248
7.8.11 Only Trained Staff Must Operate the System  249
7.8.12 Define and Document Electronic Records
for the System  249
7.8.13 Review the Audit Trail Entries for Each Batch  251
7.8.14 Backup the System Regularly  251
7.8.15 Conduct Data Integrity Audits  252
7.8.16 Control Blank Forms  252
7.9 Audit Trails and an Introduction to Second Person
Review  254
7.9.1 EU GMP Annex 11  254
Contents xxiii
7.9.2 F DA Guidance on Data Integrity and cGMP
Compliance  254
7.9.3 Which Audit Trail Should Be Reviewed?  255
7.9.4 How Regular is a Regular Review of Audit
Trail Entries?  256
7.10 Is The Chromatographic System Ready to Run?  259
7.10.1 “Test” or “Prep” Injections Using
Samples  259
7.10.2 FDA Guidance for Using Actual Samples
for SST Injections  259
7.10.3 Role of System Evaluation Injections  260
References  261

Chapter 8 CDS Validation: Managing System Risk  266

8.1 What Do the Regulators Want?  266

8.1.1 EU GMP Annex 11  266
8.1.2 FDA Guidance on Part 11 Scope and
Application  267
8.1.3 FDA General Principles of Software
Validation  267
8.1.4 PIC/S Guidance on Computerised Systems
in GXP Environments  267
8.1.5 OECD Guidance 17 on Application
of GLP Principles to Computerised Systems  267
8.1.6 Regulatory Summary  268
8.2 Risk Management: Balancing Compliance and
Non-Compliance  269
8.3 Overview of a System Risk Assessment  270
8.3.1 Overview of the Laboratory Risk
Assessment  270
8.3.2 USP <1058> Based Integrated AIQ and
CSV Risk Assessment  271
8.3.3 Risk Assessment Flow Chart  273
8.3.4 Define the Item and the Intended Use  274
8.3.5 Does the Item Carry Out Any GXP Work?  274
8.3.6 Identification of Software, Apparatus,
Instrument or System?  276
8.3.7 Separating Instruments from Systems  277
8.3.8 Group C Systems – Documenting the
GAMP Software Category  277
8.3.9 Group C Systems: Determining the Record
Impact  280
8.3.10 Group C System Sub-Classification  280
References  282
xxiv Contents
Chapter 9 Working Electronically and Using Electronic Signatures  284

9.1 What Do the Regulators Want?  285

9.1.1 EU GMP Annex 11  285
9.1.2 21 CFR 11 Main Electronic Signature
Requirements  285
9.1.3 Signature Requirements in GXP Regulations  286
9.1.4 21 CFR 11 is an Integrated Regulation  286
9.1.5 FDA GMP Regulations: Number of
Signatures and Order of Signing  286
9.1.6 Regulations Summary  287
9.2 Process Redesign is Essential for Working
Electronically  287
9.2.1 Rationale for Using Electronic Signatures  287
9.2.2 Understand the Current Process  288
9.3 Process Mapping and Analysis  288
9.3.1 Importance of Understanding the Process  288
9.3.2 Map the Current Process  289
9.3.3 Other Benefits from Redesigning the
Process  289
9.3.4 Leverage Benefits from Other Laboratory
Applications  293
9.4 Case Study Descriptions  293
9.4.1 Case Study 1  293
9.4.2 Case Study 2  296
9.5 Optimising the Workflow for Electronic
Signatures – Case Study 1  296
9.5.1 The Current Process  296
9.5.2 Basic Process Improvement Ideas  297
9.5.3 The Redesigned Process  297
9.6 Optimising the Workflow for Electronic
Signatures – Case Study 2  298
9.6.1 The Current Process  298
9.6.2 The Redesigned Process  299
9.7 Using the CDS for Automated Compliance  300
9.8 Implementing Electronic Signatures Successfully  300
9.8.1 Understand the Process  300
9.8.2 Electronic Signatures Components  301
References  302

Chapter 10 Writing the User and System Requirements  303

10.1 W
 hat Do the Regulators Want?  303
10.1.1 FDA GMP and GLP Predicate Rules  303
10.1.2 EU GMP Annex 11  303
Contents xxv
10.1.3 P IC/S Guide Computerised Systems in GXP
Environments  304
10.1.4 General Principles of Software Validation  304
10.1.5 Regulatory Summary  304
10.2 Business Rationale for Writing a URS  304
10.3 Contents of a Chromatography Data System URS  305
10.3.1 Writing a URS to Select a CDS and Supplier  305
10.3.2 Link the URS to a Specific Software Version  306
10.3.3 Sections of the URS  306
10.4 Guidance for Writing the Requirements  309
10.4.1 Sub-Divide the Major URS Sections  309
10.4.2 General Guidance for Requirements  309
10.4.3 URS Issues to Consider  310
10.4.4 Making the Requirements Traceable  311
10.4.5 Reviewing the URS  312
10.5 Writing Testable or Verifiable Requirements  312
10.5.1 How Not To Do It  312
10.5.2 Writing Well-Formed Requirements  313
10.5.3 Orphan Requirements  315
10.5.4 Key Criteria for User Requirements  315
10.6 Updating the URS  316
10.6.1 A URS is a Living Document  316
10.6.2 Maintaining Traceability with URS Updates  316
10.6.3 Helping the Reviewers of the Updated URS  316
10.7 Configuration Specification  317
10.7.1 Areas for Application Configuration in a CDS  317
References  318

Chapter 11 Controlling the Validation  319

11.1 W hat Do The Regulators Want?  319

11.1.1 EU GMP Annex 11  319
11.1.2 EU GMP Annex 15 – Qualification and
Validation  320
11.1.3 General Principles of Software Validation  320
11.1.4 PIC/S Guidance Document  320
11.1.5 Regulatory Requirements Summary  320
11.2 Validation Plan or Validation Master Plan?  321
11.2.1 What’s in a Name?  321
11.2.2 Relationship Between a Validation
Master Plan and Validation Plan  321
11.3 Content of the Validation Plan  322
11.3.1 Title of the Validation Plan: Include the
Name and Version of the Application  323
11.3.2 Purpose of the Plan and Scope of the System  324
xxvi Contents
11.3.3  hen to Write the Validation Plan? 
W 324
11.3.4 Do not Include a System Description  325
11.3.5 Project Plan and Overall Timescales  325
11.3.6 One Validation Plan for the System Life
or one for Each Software Version?  326
11.3.7 Roles and Responsibilities  326
11.3.8 Validation Team Considerations  328
11.3.9 Defining Life Cycle Tasks  329
11.4 Defining a Validation Strategy for Some CDS
Systems  330
11.4.1 Validation Strategy for Four Instances of
a CDS  331
References  332

Chapter 12 System Selection  333

12.1 W hat Do the Regulators Want?  333

12.1.1 EU GMP Annex 11  333
12.1.2 PIC/S Guidance PI-011 334
12.1.3 Regulations Summary  334
12.2 Investment Protection Versus Seduction by
Technology  334
12.3 The System Selection Process  335
12.3.1 Write an Initial URS for Selecting the
System  335
12.3.2 Generate a List of Potential Suppliers  335
12.3.3 Determine Selection Criteria and
Evaluation Tests Now  335
12.3.4 Prepare the Invitation to Tender/Request
for Proposal  337
12.3.5 Evaluate the Supplier ITT Responses  338
12.3.6 Testing Systems Against Your Requirements  338
12.3.7 Consider User Training Now!  339
12.3.8 Visit or Talk with Existing Users  339
12.3.9 System Selection and Report  339
References  340

Chapter 13 Assessing the CDS Supplier  341

13.1 W
 hat Do the Regulators Want?  341
13.1.1 EU GMP Annex 11  341
13.1.2 Preamble to 21 CFR 11 Final Rule  342
13.1.3 PIC/S Guide on Computerised Systems
in GXP Environments  342
13.1.4 Regulatory Requirements Summary  342
Contents xxvii
13.2 S oftware Quality and Business Risk  343
13.3 Rationale for a Supplier Assessment  343
13.3.1 ISO 9000: Saint or Sinner?  343
13.3.2 ISO 9001 and ISO 90003  344
13.3.3 Supplier Certificates of Validation  345
13.3.4 Marketing Literature and Contracts  346
13.4 When Do I Assess the CDS Supplier?  346
13.4.1 First, Second or Third Party Assessment
or Audit?  347
13.4.2 On-Site Audit or Remote Assessment?  347
13.4.3 Remote Supplier Audit  347
13.4.4 Remote Assessment with Follow-Up
Conference Call 348
13.5 On-Site Supplier Audits  349
13.5.1 Preparation for an Audit  349
13.5.2 The Scope of an On-Site Audit  351
13.5.3 The Role of an Audit Checklist  353
13.5.4 Software Development – The Move to Agile  354
13.5.5 Writing the Audit Report  355
13.6 Using the Supplier Audit to Reduce PQ Testing  356
References  357

Chapter 14 Negotiating the Contract and Purchasing the System  358

14.1 W hat Do the Regulators Want?  358

14.1.1 EU GMP Annex 11  358
14.1.2 Regulatory Requirements Summary  359
14.2 The Contract and Protection of Rights  359
14.2.1 Rationale for Negotiating the Contract  359
14.2.2 Overview of the Contract  359
14.2.3 Some Key Clauses of a Contract  360
14.3 Purchase Order: Defining the Initial Configuration  363
References  363

Chapter 15 Planning the Installation of the System  364

15.1 W hat Do the Regulators Want?  364

15.1.1 US GMP 21 CFR 211: Subpart D – Equipment  364
15.1.2 EU GMP Chapter 3: Premises and Equipment  364
15.1.3 Regulatory Summary  365
15.2 Business Rationale for an Installation Plan  365
15.3 Preparing for System Installation  365
15.3.1 The CDS System Installation Plan  365
15.3.2 Laboratory Plan  366
References  367
xxviii Contents
Chapter 16 CSV Risk Management Requirements Level Assessment  368

16.1 W hat Do the Regulators Want?  368

16.1.1 EU GMP Annex 11  368
16.1.2 FDA Guidance for Industry: Part 11 Scope
and Application  369
16.1.3 PIC/S Guidance on Computerised Systems
in GXP Environments  369
16.1.4 FDA General Principles of Software
Validation  369
16.1.5 Regulatory Requirements Summary  369
16.2 You Need a Current URS Before Starting the Risk
Assessment  370
16.2.1 Train Key Users  370
16.2.2 Understanding the New CDS System or
Version  370
16.2.3 Stop Here Until You Have a Current URS  371
16.2.4 Revised URS? Update the Risk Assessment!  371
16.3 Risk Management Approach  371
16.3.1 Vocabulary Issues  372
16.3.2 ISO Guide 73 and ISO 14971: Risk
Management Definitions  372
16.3.3 Risk Assessment is a Continuous Process  373
16.3.4 Application of Risk Assessment to a CDS  373
16.4 Risk Assessment at the Requirements Level  373
16.4.1 Outcome of Risk Management  373
16.4.2 Possible Risk Assessment Methodologies  373
16.4.3 Team Approach to Risk Assessment  374
16.5 Functional Risk Assessment (FRA)  375
16.5.1 Risk Analysis of Individual Functions  375
16.5.2 Managing the Mandatory and Critical
Requirements  378
16.5.3 Allocating Requirements to Test Scripts  379
16.5.4 Application of FRA  379
16.6 Failure Mode Effects Analysis (FMEA)  379
16.6.1 Overview of FMEA  379
16.6.2 Conducting an FMEA Risk Assessment  380
16.6.3 An Example FMEA Assessment  382
16.6.4 Limitations of FMEA  384
16.7 Risk Acceptance and Risk Communication  384
References  384

Chapter 17 Importance of the Traceability Matrix  386

17.1 W
 hat Do the Regulators Want?  386
17.1.1 EU GMP Annex 11  386
17.1.2 General Principles of Software Validation  386
Contents xxix
17.1.3 P IC/S Guide PI-011: Computerised Systems
in GXP Environments  387
17.1.4 Regulations Summary  387
17.2 Business Rationale for a Traceability Matrix  387
17.2.1 GAMP 5  388
17.3 A Life Cycle Model Refresher  388
17.3.1 Terms and Definitions  389
17.3.2 Why Bother to Trace Requirements?  390
17.4 Linking Requirements with Their Testing or
Verification  392
17.5 Examples of Requirements Traceability  394
17.5.1 Traceability Between the URS and the
Configuration Specification  394
17.5.2 Traceability Matrix Combined with
Functional Risk Assessment  395
17.5.3 How Detailed Should User Acceptance
Testing Traceability Be?  396
17.6 Using a Spreadsheet to Manage Traceability  398
17.6.1 Evolution and Further Refinement of User
Requirements  400
17.7 The Traceability Treadmill?  401
References  401

Chapter 18 Writing Configuration Specifications  403

18.1 W hat Do the Regulators Want?  403

18.1.1 FDA GMP Regulations  403
18.1.2 General Principles of Software Validation  404
18.1.3 Regulatory Requirements Summary  404
18.2 Business Rationale  404
18.3 Scope of CDS Configuration and Approach to
Documentation  404
18.3.1 Application Configuration Areas of a CDS  404
18.3.2 Never Use Unconfigured CDS Software  405
18.3.3 Ways of Documenting Application
Configuration  405
18.4 Application Configuration Specification  406
18.4.1 Training to Understand CDS System
Settings  406
18.4.2 Prototype the Configured System  406
18.4.3 Document the Configuration  407
18.4.4 Defining User Types and Access Privileges  407
18.4.5 Ensure Linkage Between the URS and
Configuration Specification  408
18.4.6 Confirming the Application Configuration  409
18.5 Controlling CDS Configuration by Procedure  409
References  411
xxx Contents
Chapter 19 Writing the Technical Specification  412

19.1 W hat Do the Regulators Want?  412

19.1.1 EU GMP Annex 11  412
19.1.2 FDA GMP 21 CFR 211  412
19.1.3 Regulatory Summary  413
19.2 Data Gathering for a Technical Specification  413
19.2.1 Input from the CDS Supplier  413
19.2.2 Corporate IT/IS Standards  414
19.2.3 URS Requirements  414
19.3 Initial Platform Design  415
19.4 Writing the Technical Specification  415
19.4.1 Hardware Architecture  415
19.4.2 Connections and Communications  417
19.4.3 Input into the Installation Qualification
Phase  417
References  417

Chapter 20 Installing and Integrating System Components  418

20.1 W hat Do the Regulators Want?  419

20.1.1 US GMP 21 CFR 211  419
20.1.2 EU GMP Chapter 3: Premises and
Equipment  419
20.1.3 EU GMP Annex 11: Computerised Systems  419
20.1.4 PIC/S Guidance PI-011  419
20.1.5 USP <1058> Analytical Instrument
Qualification  420
20.1.6 General Principles of Software Validation  420
20.1.7 Regulatory Summary  420
20.2 Overview of the Whole Qualification Process  420
20.3 Installing and Integrating the System Components  421
20.3.1 Co-Ordinating Suppliers  421
20.3.2 Computer Platform  422
20.3.3 CDS Application Components and
Associated Documentation  422
20.3.4 Qualification of the Laboratory Data Servers  424
20.3.5 Connection and Qualification of
Chromatographs  424
20.3.6 Establish the Initial CDS Configuration
Baseline Now  425
20.4 How Much Value is there in a Software OQ?  425
20.4.1 Positioning of a Software Operational
Qualification  425
20.4.2 Is an OQ Essential for a CDS Validation
Project?  426
Contents xxxi
20.4.3 A
 n OQ Case Study  428
20.4.4 Do You Believe in Risk Management?  428
20.4.5 OQ for Configurable Software?  429
 eferences 
R 430

Chapter 21 Designing the User Acceptance Test Suite  431

21.1 What Do the Regulators Want?  432

21.1.1 EU GMP Annex 11  432
21.1.2 FDA General Principles of Software
Validation  432
21.1.3 Regulatory Requirements Summary  432
21.2 Overview of the User Acceptance Testing Phase of
Validation  433
21.2.1 Who Are You Writing the Test Documents
For?  434
21.2.2 UAT/PQ Test Plan  434
21.2.3 Writing the Test Scripts  434
21.2.4 Executing the Test Scripts  435
21.3 The UAT/PQ Test Plan  435
21.3.1 Format of a Test Plan  435
21.3.2 Test Environment  436
21.3.3 Confirming the CDS Application
Configuration  436
21.3.4 Overview of the Test Suite  436
21.3.5 Further Testing Considerations  439
21.3.6 Implementation Strategy 1: Same System
Multiple Sites  440
21.3.7 Implementation Strategy 2: Single
Instance with Phased Roll-Out  441
21.3.8 Tracing User Requirements to PQ Testing  441
21.3.9 Assumptions, Exclusions and Limitations
of the Test Approach  442
21.3.10 Features Not Tested  443
21.3.11 Test Approach  444
21.4 Authorising the Test Plan and Test Scripts  445
21.4.1 PQ Test Plan  445
21.4.2 UAT Test Scripts  445
References  446

Chapter 22 Writing Test Scripts and Test Cases  447

22.1 What Do the Regulators Want?  447

22.1.1 EU GMP Annex 11  447
22.1.2 FDA General Principles of Software
Validation  448
xxxii Contents
22.1.3 Regulatory Requirements Summary  448
22.2 Principles of Software Testing  448
22.2.1 Essentials of Software Testing  448
22.2.2 White Box and Black Box Testing  448
22.2.3 Understanding How the CDS Application
Works  450
22.2.4 Test Coverage  451
22.2.5 Manual or Automated Testing?  451
22.2.6 Necessity for Pre-Defined Expected
Results and Acceptance Criteria  452
22.2.7 Updating the URS During the UAT Phase  452
22.3 Functional and Non-Functional Testing of a CDS  453
22.3.1 Risk Assessment: Extent of Testing?  453
22.3.2 Functional Testing  454
22.3.3 Non-Functional Testing  455
22.4 UAT Test Script Structure and Contents  455
22.4.1 Purpose of the Test  455
22.4.2 Requirements to be Tested and
Limitations to the Testing  455
22.4.3 Test Preparation  458
22.4.4 Identification of Personnel  459
22.4.5 Test Procedures  460
22.4.6 Collecting and Collating Documented
Evidence  461
22.4.7 Acceptance Criteria  462
22.4.8 Test Execution Log  463
22.4.9 Test Summary Log and Test Script Sign-Off  463
22.4.10 Second Person Review of the Test Script  464
22.4.11 Approval of the Test Script  464
22.5 Designing Tests for Security and Access Control  464
22.5.1 Are the User Requirements Adequately
Specified?  464
22.5.2 Logical Security  465
22.5.3 Access Control  465
22.5.4 Designing the Tests  466
22.5.5 Refining the Test Design  467
22.5.6 Writing Test Execution Instructions and
Expected Results  468
22.6 Some Considerations for Testing Electronic
Signature Use  470
22.7 Execution of Approved Test Scripts  470
References  470

Chapter 23 Executing Test Scripts and Reporting the Results  472

23.1 What Do the Regulators Want?  472

23.1.1 EU GMP Annex 11  472
Contents xxxiii
23.1.2 F
 DA General Principles of Software
Validation  473
23.1.3 Regulatory Requirements Summary  473
23.2 Organising the Test Suite Execution  473
23.2.1 Planning the Test Suite Execution  473
23.2.2 Have a Known Location for Collating and
Reviewing Test Results  474
23.2.3 Test Script Execution Status Board  474
23.3 Executing a Test Script  475
23.3.1 All is Well or Are There Problems?  475
23.3.2 Read the Test Script  476
23.3.3 Preparation for Testing  477
23.3.4 Sign into the Test Script  477
23.3.5 Execute the Individual Test Procedures
and Document the Testing  478
23.3.6 Documented Evidence to Support Testing  478
23.3.7 Collating Documented Evidence  480
23.3.8 Has the Test Passed or Failed?  480
23.3.9 Documenting and Handling Unexpected
Results  480
23.3.10 Check the Test Execution Log  481
23.3.11 Tester Completes the Test Summary
Log and Signs the Test Script  481
23.3.12 Update the Test Script Execution Status  481
23.4 Reviewing the Completed Test Script  481
23.4.1 Role of the Reviewer  481
23.4.2 Correcting Any Mistakes  482
23.4.3 Resolving Any Disagreements  482
23.4.4 Approving the Test Script Execution and
Update the Test Script Execution Status  482
23.4.5 Enter the Test Script Result into the
PQ Section of the Validation Summary
Report  482
References  483

Chapter 24 User Training and System Documentation  484

24.1 What Do the Regulators Require? Part 1  484

24.1.1 EU GMP Annex 11  484
24.1.2 FDA 21 CFR 11  484
24.1.3 FDA 21 CFR 211 GMP  485
24.1.4 FDA 21 CFR 58 GLP  485
24.1.5 Regulatory Requirements Summary  485
24.2 Personnel and Training Records  485
24.2.1 Personnel Involved in a CDS Validation
Project  485
24.2.2 User Training Records  486
xxxiv Contents
24.3 U RS Requirements Define CDS Procedures  487
24.3.1 Proactive Use of Requirements for
Procedures  487
24.3.2 Challenge Existing SOPs with CDS
Procedural Requirements  487
24.3.3 Confirm Accuracy of CDS Procedures
in the UAT Phase  488
24.4 System Documentation from the Supplier  488
24.5 Standard Operating Procedures (SOPs) for a CDS  489
24.5.1 SOPs for a CDS in Relation to a Company
Data Governance Framework  489
24.5.2 Good Chromatographic Practices  491
24.5.3 Good Chromatographic Integration
Practices  492
24.5.4 Good Analytical Data Review Practices  493
24.5.5 Laboratory Deviations and Laboratory
Investigations SOPs  493
24.5.6 Training for Data Integrity SOPs  494
24.5.7 SOP for Laboratory Administration of the
CDS  494
24.6 Managing Custom Calculations, Fields and Reports  495
24.6.1 Development Environment  495
24.6.2 Control of Custom Calculations and Fields  495
24.6.3 Control of Custom Reports  496
24.6.4 Control Changes of Verified Custom
Calculations and Reports  496
24.7 Second Person Review of CDS Data and
Records  496
24.7.1 Importance of the Second Person Review  497
24.7.2 What Do the Regulators Require? Part 2  497
24.7.3 Scope of the Second Person Review  499
24.7.4 A CDS Interfaced with a LIMS  499
24.7.5 Second Person Review in Practice  501
24.7.6 Using the CDS Features to Aid Second
Person Review  504
24.7.7 How Should the Second Person Review
be documented?  504
24.8 Administrative and Procedural Controls Required
for 21 CFR 11 Compliance  507
24.8.1 Verifying the Identity of Individuals  508
24.8.2 Use of Electronic Signatures with Non
Repudiation  509
24.8.3 Uniqueness of Electronic Signatures  509
24.8.4 Password Management  509
24.8.5 Change Control and Configuration
Management  510
Contents xxxv
24.8.6 Date and Time Stamps  510
24.8.7 Backup and Recovery SOP  510
24.8.8 Defining E-Records for the CDS  511
24.8.9 Security and Access Control  511
24.8.10 Remote Access  511
Acknowledgements  512
References  512

Chapter 25 IT Support for a CDS  513

25.1 What Do the Regulators Want?  513

25.1.1 FDA GMP 21 CFR 211  513
25.1.2 21 CFR 11  514
25.1.3 EU GMP Annex 11  514
25.1.4 PIC/S Guidance  515
25.1.5 FDA Perspective on Time Stamps  516
25.1.6 Regulatory Requirements Summary  516
25.2 IT Department Quality Management System  517
25.2.1 Overview of the IT QMS  517
25.2.2 Associated QMS Procedures and Work
Instructions  517
25.3 Service Level Agreement  520
25.4 Backup and Recovery  521
25.4.1 Business Rationale: How Important are
Your Data?  521
25.4.2 What is Backup and Recovery?  522
25.4.3 Roles and Responsibilities  522
25.4.4 Hardware to Help Data Security and
Integrity  523
25.4.5 Options to Consider for Backup  524
25.4.6 Main Backup Activities  525
25.4.7 Hot or Cold Backups?  526
25.4.8 Cold Backups  526
25.4.9 Hot Backups  527
25.4.10 Management of Magnetic Media  527
25.4.11 Restoring Data from Tape  528
25.4.12 Validation of Backup  529
25.5 Time and Date Stamps  529
25.5.1 Time Stamps for Standalone CDS Systems  529
25.5.2 Time Stamps for Networked CDS Systems  530
References  530

Chapter 26 System Description  532

26.1 What Do The Regulators Want?  532

26.1.1 EU GMP Annex 11  532
xxxvi Contents
26.1.2 O
 ECD Application of GLP Principles to
Computerised Systems  532
26.1.3 OECD 17: Guidance on the Application of
GLP Principles to Computerised Systems  533
26.1.4 PIC/S Guidance  533
26.1.5 Regulatory Requirements Summary  534
26.2 Turning Regulations into Practice  534
26.2.1 Single Document or Multiple Documents?  534
26.2.2 Outline for a System Description  534
26.2.3 Keeping Current: Updating the System
Description  535
26.3 Key Sections of the System Description  536
26.3.1 Introduction  536
26.3.2 System Scope  536
26.3.3 Definition of Electronic Records  538
26.4 Do Not be Stupid  538
References  538

Chapter 27 Defining Electronic Records and Raw Data for a CDS  540

27.1 What Do the Regulators Want?  540

27.1.1 US GLP 21 CFR 58 – Raw Data  540
27.1.2 21 CFR 11 – Electronic Records  541
27.1.3 US GMP 21 CFR 211 – Complete Data  541
27.1.4 EU GMP Chapter 4 on
Documentation – Raw Data  541
27.1.5 Regulatory Requirements Summary  542
27.2 Contributions to the E-Records Debate  542
27.2.1 Furman, Tetzlaff and Layloff  542
27.2.2 BARQA Paper on Raw Data  542
27.2.3 How Raw are Your Data? – 1  543
27.2.4 How Raw are Your Data? – 2  543
27.2.5 FDA Part 11 Scope and Application
Guidance for Industry  544
27.2.6 FDA Level 2 Guidance on Records and
Reports  546
27.2.7 EU GMP Chapter 4 – A Requirement to
Define GMP Raw Data  548
27.2.8 GLP Raw Data Definition and
Interpretation  549
27.2.9 Swiss AGIT GLP Electronic Raw Data
Guidance  550
27.2.10 Compliance Policy Guide 7346.832  552
27.2.11 GAMP Good Practice Guide for Validation
of Laboratory Computerised Systems  552
Contents xxxvii
27.2.12 F DA Draft Guidance on Data Integrity
and cGMP Compliance  553
27.2.13 Summarising the Regulations and
Guidance  554
27.2.14 Dead as a Dodo: Raw Data are Paper  555
27.3 Defining the Electronic Records for Your System  555
27.3.1 Static and Dynamic Data  555
27.3.2 Data Acquisition Phase  555
27.3.3 Integration, Calculation and Reporting
Phase  557
27.3.4 Traceability for Data Integrity  558
27.3.5 Common Elements of Raw Data and
Complete Data  558
27.3.6 Controlled Chromatograph with Separate
Data System  560
References  560

Chapter 28 Writing the Validation Summary Report  562

28.1 What Do the Regulators Want?  562

28.1.1 PIC/S Guidance  562
28.1.2 General Principles of Software Validation  563
28.1.3 Regulatory Requirements Summary  563
28.2 Map the Validation Plan to the Validation Summary
Report  563
28.3 Content of the Validation Summary Report  564
28.4 Writing the Validation Summary Report  564
28.4.1 How to Summarise the Work  564
28.4.2 How to Summarise PQ Testing  566
28.4.3 PQ Test Execution Notes  566
28.4.4 Deviations and Departures from the
Validation Plan  567
28.4.5 Validation Package  567
28.4.6 Releasing the System  568
28.4.7 Going Live! Sit Back and Relax?  568
References  568

Chapter 29 Integration in a Regulated Environment  569

29.1 What Do the Regulators Want?  569

29.1.1 US GMP 21 CFR 211 – Laboratory Controls  569
29.1.2 United States and European
Pharmacopoeias  570
29.1.3 FDA Guidance for Industry Bioanalytical
Methods Validation  570
xxxviii Contents
29.1.4 E MA Guidance on Bioanalytical Methods
Validation  570
29.1.5 Regulatory Summary  571
29.2 Why Control Chromatographic Integration?  571
29.2.1 Extracts from FDA Warning Letters  571
29.2.2 Approaches to Controlling
Chromatographic Integration  572
29.3 Back to Integration Basics  573
29.4 How Can Manual Integration Result in
Falsification?  576
29.4.1 Uncovering Manipulation  577
29.4.2 What is Missing?  577
29.4.3 Why is there No Definition of Manual
Integration?  578
29.5 Scope of an SOP on Chromatographic Integration  578
29.5.1 Integration Process Flow and
Decision Tree  579
29.5.2 Manual Intervention versus Manual
Integration  581
29.6 The Four Eyes Principle Applied to
Chromatographic Integration  582
29.6.1 The Primary Objective is Automatic
Integration  582
29.6.2 The Secondary Objective is Manual
Intervention  582
29.6.3 When All Else Fails – Manual Integration  582
29.6.4 Methods that Quantify Both Active
Ingredient and Impurities  583
29.6.5 Procedure and Training for Integration
Consistency and Data Integrity  583
29.6.6 Second Person Review of Integration  584
References  584

Chapter 30 User Account Management  586

30.1 W
 hat Do the Regulators Require?  586
30.1.1 FDA GMP 21 CFR 211  586
30.1.2 FDA 21 CFR 11  586
30.1.3 FDA Guidance: Computerised Systems in
Clinical Investigations  587
30.1.4 EU GMP Annex 11  587
30.1.5 MHRA Data Integrity Guidance  587
30.1.6 FDA Guidance on Data Integrity and
cGMP Compliance  588
30.1.7 WHO Guidance on Good Data and Record
Management Practices  589
30.1.8 Regulatory Summary  589
Contents xxxix
30.2 P rinciples of User Account Management  590
30.2.1 Prerequisites for User Account Management  590
30.2.2 Administration by IT  591
30.2.3 Authorised User  591
30.2.4 Individual User Accounts  591
30.2.5 Cumulative List of Users  592
30.2.6 Staff Security Awareness  592
30.2.7 Regular Review of Accounts  593
30.3 User Account Management in Practice  593
30.3.1 Process Workflow  593
30.3.2 Creation of a New User Account  594
30.3.3 Modification of an Existing User Account  594
30.3.4 Disabling a User Account  595
30.3.5 Maintaining a Cumulative List of Users  595
30.3.6 Periodic Review or Audit of User Accounts  595
30.4 Password Management  596
30.4.1 Technical Implementation and Enforcement  596
30.4.2 Password Paradox  596
30.4.3 Forgotten Password?  597
References  597

Chapter 31 Incident and Problem Management  598

31.1 W hat Do the Regulators Want?  598

31.1.1 EU GMP Annex 11  598
31.1.2 OECD Guidance 17 for Computerised
Systems  598
31.1.3 Regulatory Requirements Summary  599
31.2 Incidents and Problems  600
31.2.1 What is an Incident?  600
31.2.2 What is a Problem?  600
31.2.3 Incident Versus Problem  600
31.3 Coordination of Incident and Problem Management  601
31.3.1 Automation of the Process  601
31.3.2 Help Desk Staff  602
31.4 Incident Management  602
31.4.1 Incident Management Workflow  602
31.4.2 Procedure for Incident Management  603
31.4.3 Periodic Review of Incidents  604
31.5 Problem Management  604
31.5.1 Problem Management Workflow  604
31.5.2 Procedure for Problem Management  605
31.5.3 Problem Management and Regulatory
Compliance  607
31.6 Linking Incident and Problem Management with
Change Management  607
References  607
xl Contents
Chapter 32 Change Control and Configuration Management  608

32.1 W hat Do the Regulators Want?  608

32.1.1 EU GMP Annex 11  608
32.1.2 FDA GMP 21 CFR 211  608
32.1.3 OECD Guidance No. 17 on Computerised
Systems  609
32.1.4 FDA Guidance: General Principles of
Software Validation  609
32.1.5 PIC/S Guidance for GXP Systems  610
32.1.6 Regulatory Requirements Summary  611
32.2 Scope of Changes to a CDS  612
32.2.1 Definition of Terms  612
32.2.2 Separate Infrastructure from Application
Changes  615
32.2.3 Triggers for Change  616
32.2.4 Is it a Change or Normal Operation?  616
32.3 Change Control  617
32.3.1 The Basic Process  617
32.3.2 Types of Change  620
32.3.3 Roles and Responsibilities  621
32.4 Some Typical CDS Changes  621
32.4.1 Scope of Changes to the CDS  621
32.4.2 Regression Testing After a Change  623
32.5 Configuration Management for a CDS  623
32.5.1 Defining the Detail of Configuration Items  624
32.5.2 Defining the System Baseline Configuration  624
32.5.3 Linking Configuration Management
with Change Control  625
32.5.4 Re-Baselining the System Configuration  625
32.6 Automating the Change Control Process  625
32.6.1 Does the Service Desk Software Need to
be Validated?  626
32.6.2 IT Personnel Must Have GXP Awareness
Training  626
32.6.3 Service Management Software as a SaaS
Solution  626
References  626

Chapter 33 Periodic Review of the CDS  628

33.1 W
 hat Do the Regulators Want?  628
33.1.1 EU GMP Annex 11  628
33.1.2 PIC/S Guidance on Computerised
Systems in GXP Environments  629
Contents xli
33.1.3 I CH Q7 GMP for Active Pharmaceutical
Ingredients  630
33.1.4 WHO Guidance on Good Data and Record
Management Practices  630
33.1.5 Compliance Policy Guide Section 130.300  630
33.1.6 Regulatory Requirements Summary  631
33.2 Rationale for a Periodic Review  632
33.2.1 What’s in a Name?  632
33.2.2 Who Performs the Review?  632
33.2.3 How Often Should the Review Occur?  633
33.2.4 Skills and Training of the Auditor  634
33.3 Overview of the Periodic Review Process  635
33.3.1 Objectives of a Periodic Review  635
33.3.2 Planning a Periodic Review  635
33.3.3 Who is Involved and What Do They Do?  636
33.3.4 Schedule for a Review  637
33.3.5 Scope of the Review  637
33.3.6 Reporting the Periodic Review and
Follow-Up  639
33.4 Conducting a Periodic Review  640
33.4.1 Preparation for a Periodic Review  640
33.4.2 Defining the System Scope  641
33.4.3 Types of Periodic Review  643
33.4.4 Are Computerised Systems Designed to
Help Periodic Reviews?  645
33.4.5 Conducting the Periodic Review  646
33.4.6 A Picture is Worth a Thousand Words  647
33.4.7 Death by Checklist?  647
33.4.8 Options for Checklists: Working Smarter
Not Harder  648
33.5 Data Integrity Audit of a CDS  649
33.5.1 Data Integrity at the System Level  649
33.5.2 Data Integrity Audit at the Data Level  652
33.5.3 Data Integrity and an Interfaced CDS  652
33.5.4 Reporting the Audit  655
References  655

Chapter 34 CDS Records Retention  657

34.1 W
 hat Do the Regulators Want?  657
34.1.1 EU GMP Annex 11  657
34.1.2 GLP Regulations: 21 CFR 58  657
34.1.3 US GMP Regulations: 21 CFR 211  658
34.1.4 US Medical Device GMP Regulations:
21 CFR 820  659
xlii Contents
34.1.5  1 CFR 11 Requirements 
2 659
34.1.6 FDA Guidance on Data Integrity  659
34.1.7 EU GMP Chapter 4 Documentation  659
34.1.8 FDA Guidance for Industry Part 11 –
Scope and Application Guidance  660
34.1.9 FDA Inspection of Pharmaceutical Quality
Control Laboratories  661
34.1.10 OECD GLP Regulations  661
34.1.11 OECD GLP Guidance on Establishment
and Control of GLP Archives  662
34.1.12 OECD GLP Guidance on Application of
GLP to Computerised Systems  662
34.1.13 Regulatory Requirements Summary  662
34.2 CDS Data File Formats and Standards  663
34.2.1 Current CDS Data Standards  663
34.2.2 Progress towards a Universal CDS Data
File Format  664
34.3 Options for Electronic Records Retention and
Archive  665
34.3.1 Backup is Not Archive
(Unless You Are the FDA)  665
34.3.2 Organising CDS Electronic Records to
Archive  666
34.3.3 Options for Electronic Archive  666
34.3.4 Can I Read the Records?  667
34.3.5 Impact of a Changed CDS File Format  668
34.3.6 Selection of Off-Line Archive Media  669
34.3.7 Changing CDS – What Are The Archive
Options?  669
34.3.8 Overview of Some Options  669
34.3.9 Assessment of Option Feasibility  670
34.4 OECD Guidance for Developing an Electronic
Archive  670
34.4.1 Definitions  670
34.4.2 Roles and Responsibilities  671
34.4.3 Archive Facilities  672
34.4.4 Archiving Electronic Records  672
References  674

Chapter 35 CDS System Retirement  676

35.1 What Do the Regulators Want?  676

35.1.1 OECD GLP Guidance 17  676
35.1.2 GMP Regulations  676
35.1.3 Business Rationale for System Retirement  676
Contents xliii
35.2 G eneric Process for System Retirement  677
35.2.1 Notification of System Retirement  677
35.2.2 Involvement of Quality Assurance and IT  678
35.2.3 Cessation of Work  678
35.2.4 Shutdown of the System  679
35.2.5 Documenting Retirement and Disposal  679
35.3 Case Study of System Retirement  680
Reference  681

Chapter 36 CDS Data Migration  682

36.1 W hat Do the Regulators Want?  682

36.1.1 EU GMP Annex 11  682
36.1.2 EU GMP Chapter 4 on Documentation  683
36.1.3 FDA 21 CFR 11 and the Part 11 Scope and
Application Guidance for Industry  683
36.1.4 OECD Guidance 17 Application of GLP
Principles to Computerised Systems  683
36.1.5 Regulatory Requirements Summary  684
36.2 Business Rationale for Data Migration  684
36.3 Drivers for Data Migration and System Retirement  685
36.3.1 Internal Drivers  685
36.3.2 External Drivers  685
36.3.3 Data Migration Options  686
36.3.4 Data Migration Between Different
Applications  686
36.3.5 Data Migration Within an Application  687
36.3.6 Validation of Within Application Data
Migration  687
36.4 Generic Data Migration and System Retirement
Process  687
36.4.1 Roles of the Process Owner and Senior
Management  689
36.4.2 Step 1: Inventory of the System  689
36.4.3 Step 2: Carry Out a Risk Assessment  689
36.4.4 Step 3: Write the Retirement Plan  689
36.4.5 Step 4: Detailed Information Gathering  690
36.4.6 Step 5: System Decommissioning and
Data Migration Plan  690
36.4.7 Step 6: Execute Work and Document
Activities  690
36.4.8 Step 7: Write Retirement and Migration
Report  690
36.5 Case Study of Data Migration  691
36.5.1 Design of the Overall Validation Project  691
xliv Contents
36.5.2 O
 verview of the Mass Spectrometry
Systems  692
36.5.3 Data Acquisition and Processing Software
Applications  692
36.5.4 Computing Environments  692
36.5.5 Differences Between the Two CDS Systems  693
36.5.6 Data Migration Strategy  694
36.5.7 Supplier Supplied Data Conversion Utilities  694
36.5.8 Limitation of the Data Conversion Utilities  694
36.5.9 Data Migration Options  695
36.5.10 Evolution of the Data Migration Design  695
36.5.11 Design of the Overall Data Migration
and System Retirement  696
36.6 Data Migration: Key Results  696
36.6.1 Retention Time  696
36.6.2 Instrument Control Parameters  697
36.6.3 Integration Algorithms and Calculated
Results  698
36.6.4 History Logs  699
36.6.5 Data Migration Summary  700
References  700

Chapter 37 Retrospective Validation  701

37.1 What Do the Regulators Want?  701

37.1.1 EU GMP Annex 11  701
37.1.2 EMA Annex 11 Questions and Answers  701
37.1.3 PIC/S Guidance  702
37.1.4 Regulatory Requirements Summary  703
37.2 Literature References to Retrospective CDS
Validation  703
37.3 Gap and Plan for Retrospective Validation  703
37.3.1 Stage 1: Collect Existing Documentation
and Review for Coverage  703
37.3.2 Phase 2: Review Existing Documents for
Adequacy  705
37.3.3 Phase 3: Write the Gap and Plan Report  706
References  707

Glossary and Abbreviations  708

Subject Index  717
Chapter 1

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 chro-
matography 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 phar-
maceutical, 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 regula-
tions. 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 prin-
ciples 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.

RSC Chromatography Monographs No. 20

Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

1
2 Chapter 1
Given the current regulatory interest in data integrity, the use of stand-
alone CDS systems for GXP regulated work is not recommended and should
be avoided. Furthermore, storing the regulated electronic records on stand-
alone workstations is not recommended as they should be stored on a resil-
ient network server and backed up by the IT department.
Chromatography Data Systems (CDS) are used throughout regulated lab-
oratories 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, distribu-
tion, 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 chromatogra-
phy 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 sys-
tem! 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 vali-
dation 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.
How to Use this Book 3
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 support-
ing 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 com-
puter 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 config-
uration 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 elec-
tronic 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.
4 Chapter 1

Figure 1.1 
Outline chapter structure of 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:
  
How to Use this Book 5

Figure 1.2 
Process for a CDS validation from start to go live and linked book
chapters.

Figure 1.3 
Maintaining the validation and system retirement mapped to the book
chapters.
6 Chapter 1
●● 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 ratio-
nale 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 speci-
fication, how this can be achieved and how to avoid some of the com-
mon pitfalls.
  
The intention of this approach is to put the regulatory and business ratio-
nale 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 Informa-
tion 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 opera-
tional 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 regu-
lations 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
How to Use this Book 7
engineering practices with a compliance wrapper and this chapter intro-
duces the key words, abbreviations and concepts for the reader.
●● Chapter 6: Understanding Life Cycles and Software Classification. Com-
puterised 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 nec-
essary 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 gov-
ernance 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 sec-
ond 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 profession-
als 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 follow-
ing 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 docu-
mented before the real work starts.
●● Chapter 9: Designing the System to Work Electronically. Understand-
ing the business process is an important part of implementing and
8 Chapter 1
validating a new CDS – with or without the use of electronic signatures
or implementing electronic signatures in a new version of an applica-
tion. Thus, we consider this question early in the book. It is import-
ant to modify the underlying business process first and plan to make
efficiencies and eliminate as many spreadsheets as possible, then inte-
grate 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 require-
ments 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. There-
fore, 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 proj-
ect 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 cor-
rectly 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?
How to Use this Book 9
●● 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 pro-
tect 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.

1.4.5  art 4: Risk, Traceability, Configuration, Installation

P
and Integration
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 deliv-
ered system with the chromatographs in the laboratory.
  
●● Chapter 16: CSV Risk Management at the Requirements Level. The proj-
ect 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. Regard-
less 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
10 Chapter 1
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.

1.4.6 Part 5: User Acceptance Testing

In a major change compared with the first edition of this book, user accep-
tance 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 require-
ments 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 pre-
sented 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 docu-
ment and handle test problems and deviations is covered.

1.4.7 Part 6: Supporting Documentation and System Release

Five chapters (Chapters 24–28) discuss the supporting documentation
required before the system is formally released at the end of the initial vali-
dation 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 pro-
cedures are essential for training the users. In addition, there needs to
be management leadership for data integrity and the associated train-
ing 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
How to Use this Book 11
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 pres-
ent 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, respec-
tively, 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.

1.4.8 Part 7: Maintaining the Validation Status

The easy job is over but the biggest validation challenge still remains: main-
taining 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 struc-
tured 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 manage-
ment of unique identities and access privileges is a critical part of ensur-
ing 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 prob-
lems 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 main-
taining 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 operat-
ing in conformance with procedures, regulations and that the validated
status is maintained. Although this was a good practice it is now a reg-
ulatory requirement under the current version of EU GMP Annex 11.
  
12 Chapter 1

1.4.9 Part 8: Records Retention 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 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.

1.4.10  art 9: When All Else Fails: Retrospective Validation of

P
a CDS
Existing CDS applications operating in regulated laboratories that have not
been validated will need to comply with applicable regulations retrospec-
tively. 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 con-
duct retrospective validation has been removed.

1.4.11 Ensuring Data Integrity

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, doc-
umented 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.
  
How to Use this Book 13
In addition, other chapters will contain requirements and suggestions for
ensuring data integrity within the system.

1.4.12 I mportance of the Second Person Review in Ensuring

Data Integrity
With the publication of several data integrity guidance documents from
various regulatory agencies, it is clear that increased emphasis and impor-
tance 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 applica-
ble 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 nor-
mal 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 influ-
encing 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.

1.5  se Your Organisation’s Computer Validation

U
Procedures
The approaches outlined in this book need to be tailored to fit with the com-
puter 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 pres-
ent 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?
14 Chapter 1

1.5.1 Terminology Used in this Book

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 func-
tional 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 busi-
ness and regulatory reasons stated at the start of each chapter.

1.6 Why Does it Take so Long to Validate a CDS?

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 sys-
tem and secondly, the users will be working with electronic signatures and
keeping paper output from the system to a minimum.

1.6.1 CDS Validation: The Way It Is

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

1.6.2 CDS Validation: The Way It Should Be

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.
How to Use this Book 15
●● 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 pro-
cedure 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.

1.6.3 The Core System

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 vali-
dated (impacting the ease with which decisions can be taken regarding
configuration of the software and writing custom calculations and cus-
tom 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 lab-
oratory 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
16 Chapter 1
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 per-
formance qualification (PQ) can also be phased and this will be discussed in
more detail in the next section.

1.7  en Critical Success Factors for Fast CDS

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

1.7.1 Management Involvement and Backing

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 unreal-
istic 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 sup-
porting the implementation is a part of each analyst’s overall performance
goals.

Table 1.1 Ten

 critical success factors for rapid CDS validation.
Ten critical success factors for rapid CDS validation
1. Management involvement and backing
2. Dedicated multidisciplinary project team members
3. Use an appropriate life cycle model
4. Knowledge of the application
5. Active quality assurance involvement
6. Effective and compliant IT participation
7. Use the supplier effectively
8. Planning, planning, planning
9. Validate the whole system but focus on the core system
10. Get more from less testing
How to Use this Book 17

1.7.2 Dedicated Key Project Team Members

It is important to understand one of the reasons that CDS validation proj-
ects 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, espe-
cially if there are high priority samples to analyse. Therefore, it is the role of
management to ensure that the project is adequately resourced. The selec-
tion 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 can-
not 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.

1.7.3 Use an Appropriate Life Cycle Model

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 Chap-
ter 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 custom-
isation 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 calcu-
lations 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 calcu-
lations 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.
18 Chapter 1
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 inte-
grated into the CDS so that the system retains its validation status.

1.7.4 Knowledge of the CDS Application

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, con-
figure and test the CDS. Even if they are experienced users at the chromato-
graphic 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.

1.7.5 Active and Flexible Quality Assurance Involvement

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 require-
ments. 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 vali-
dation 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 sys-
tem validation procedure you need to keep QA informed. Working with QA is
infinitely better than working against them.

1.7.6 Effective and Compliant IT Participation

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 vali-
dation project as the software has to run on the network operated by IT. Note
How to Use this Book 19
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, oper-
ating 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 soft-
ware 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 lab-
oratory PCs described above.
Active involvement of IT for user account management and system admin-
istration is essential for data integrity. Giving laboratory users system admin-
istrator 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.

1.7.7 Use the Supplier Effectively

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
20 Chapter 1
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 doc-
uments 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 qualifica-
tion 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.

1.7.8 Planning, Planning and Planning

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

1.7.9 Focus on the Core System

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.
How to Use this Book 21

1.7.10 Get More from Less Testing

Finesse and subtlety are characteristics not often associated with computer-
ised 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.

1.8 Assumptions, Exclusions and Limitations

Owing to the size and scope of this book, there are some assumptions, exclu-
sions and limitations of what can be covered in the validation of chromatog-
raphy 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 excep-
tion is Chapter 20 where the IQ and OQ of the CDS database server(s) is
(are) discussed briefly.
  
Chapter 2

What is a CDS? The Past,

Present and Future

In this chapter we will consider what basic functions a CDS can perform.
Then, we will look at the evolution of CDS from 1970 to the present day and
finally consider what additional functions should be present to enable more
efficient and effective chromatographic operations in the future. Throughout
all of these areas the increased requirement for data integrity will be apparent.

2.1 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 man-
ufacture. Chromatography can be used for the assessment of active ingre-
dients, raw materials, impurities and determining the stability of active in
final preparations and in addition it can be used to determine the concentra-
tion of drugs and potential drugs in biological fluids for bioavailability and
bioequivalence studies. The chromatograms generated by these analytical
methods are acquired, displayed, integrated and results calculated by a soft-
ware application called a chromatography data system (CDS).

2.2 What is a Chromatography Data System?

This section discusses the operation of a chromatography data system
from the perspective of a typical laboratory process or workflow; Figure
2.1 shows the main features of a CDS and Figure 2.2 shows the overall
sequence of events that a typical data system should perform. This is a

RSC Chromatography Monographs No. 20

Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and
Regulatory Requirements, 2nd Edition
By R. D. McDowall
© R.D.McDowall, 2017
Published by the Royal Society of Chemistry, www.rsc.org

22
What is a CDS? The Past, Present and Future 23

Figure 2.1 
Outline configuration of a chromatograph and CDS software installed
on a standalone PC.

Figure 2.2 
Typical process workflow of a chromatography data system.

generalised approach to the operation of a "typical" data system; further

details on the subject are in the Royal Society of Chemistry monograph by
Dyson1 and the book by Fellinger on data analysis and signal processing in
chromatography.2
This understanding is important as detailed knowledge of how a specific CDS
application works is essential to write and maintain a user requirements spec-
ification that documents the intended use throughout the operational lifetime
of any system. In addition, there is too much trust placed by chromatographers
on computer output without questioning how a specific result was achieved.

2.2.1 Types of Chromatography Data System

A CDS can come in one of the following types:
  
●● Integrator (single user and single instrument data acquisition) although
these are getting rarer and have been replaced by PC based systems,
24 Chapter 2
these can still be found in a few laboratories. Integrators will not be
considered as being in the scope of this book.
●● Workstation, typically a single user with a standalone computer that
controls, acquires and processes data from one or two chromatographs.
●● Client–server, a multiple user CDS with instrument control, acquiring
and processing data with using networked storage.
●● Terminal-server, a multiple user CDS with instrument control, acquir-
ing and processing data with using networked storage.
  
Note that the application software and any linked database in the last two
CDS types can be installed on either physical or virtual servers.
The main aim of this book is to describe the practical validation of net-
worked chromatography data systems rather than integrators or CDS oper-
ating as standalone workstations, although the principles are applicable to
them.
The essential elements of a CDS and how it can interact with the gas or
liquid chromatograph is shown diagrammatically in Figure 2.1:
  
●● Establishment and storage of analytical methods including data acqui-
sition and processing parameters.
●● Instrument control of GC, GC-MS, LC and LC-MS instruments used by
the laboratory associated with each analytical method.
●● Sequence file to identify individual samples injected and input of fac-
tors used to adjust the calculated amount of concentration for purity,
water content, dilution of the sample or salt form of the analyte.
●● Acquisition of data from each injection and any user defined chroma-
tography parameters with storage of the data either on a local worksta-
tion or networked server.
●● Processing of standard curves samples to determine the calibration
curve and quantification of the unknown samples.
●● Process the acquired data first into peak areas or heights and then into
analyte amounts or concentrations.
●● Processing of system suitability test (SST) samples and determination
of SST parameters.
●● Quantification of any quality control samples to determination if the
run is acceptable or not.
●● Quantification of the unknown samples to determine the concentration
or amounts of the analytes.
●● Storage of the resultant processed data files and other information
acquired during the run.
●● Interface with LIMS or other informatics solutions for import of data
relating to CDS set-up or export of data for further processing or colla-
tion of results.
●● Regulatory compliance features such as security, access control and
audit trail.
●● Ability to work electronically with the application of electronic signa-
tures at key stages of an analysis.
  
What is a CDS? The Past, Present and Future 25
In addition, some CDS have functions that can document column use,
instrument use logs and whether a chromatograph is still qualified or not.
This chapter is a general introduction to the main functions of a CDS;
Chapter 27 discusses the definition of the electronic records and raw data
including the contextual metadata associated with a system in more detail in
order to comply with regulations.

2.2.2 Naming Conventions

Before starting a discussion of the functions of a CDS; it is important to
understand the need for naming conventions used within a system for proj-
ects, data acquisition files, processing methods, instrument control meth-
ods, sequences, report types and all data files stored within it. This is to avoid
having files named the same or in an unusual manner that make retrieval
difficult. Any CDS must have sufficient capacity for naming all of the files
that would be created by the system over the records retention for the GXP
regulations it operates under. This will aid efficient storage, archiving and
unambiguous identification of these files for easier retrieval later. Therefore,
for efficient management of data files and methods, naming conventions
must be introduced. Any naming convention system must aid users, quality
assurance, and regulatory inspectors.
A naming convention should be based on the workflow undertaken by a
laboratory. This is to allow not only efficient archiving of data but also, just as
importantly, the efficient retrieval of data. Some ideas might be;
  
●● Organise the data around drug products or development projects, as
this is often how the work is structured and how many project teams are
organized. This will help retrieve data to aid regulatory compliance for
ready retrieval of electronic records.
●● Create major subdivisions of each project based around the type of
work done, e.g. method development, method validation, pre-formula-
tion, product strengths or formulation types, etc.

2.2.3 Data Acquisition Files

The start of the data acquisition operation of a chromatography data system
is to build a method file that tells the CDS how to acquire data from each
injection. An acquisition method file should control:
  
●● The run time of each injection.
●● The data sampling rate of the detector signal and the detector signal
outputs to be measured (e.g. specific UV wavelengths, total detector out-
put for flame ionisation detectors or mass/charge for mass spectrome-
ter detectors).
●● Definition of when to change the data collection rate due to peak
broadening.
  
26 Chapter 2
A name, number or a mixture of both should identify individual data
acquisition files within the system. In addition, the CDS should be able to
provide facilities for version control to ensure that control is maintained
over the method for the lifetime of its use. Part of the control function
of the system must be access control to identify the individuals who can
create, modify or delete (if allowed) the acquisition methods. If a method
has been modified, then copies of the modifications must be stored with
or be available to the data processed by that method. This is to provide
an audit trail for the data and results produced by a version of a method.
However, when developing methods, flexibility with acquisition files is
essential and a default method should be available to acquire data and then
develop a specific acquisition method. Any changes made to the file will be
recorded in an audit trail with the name of the person who made the change,
the date and time of the change, the old and new value of the data and a
reason for that change.

2.2.4 Instrument Control Files

The primary interaction of the CDS with analytical instrumentation is with
the output from the detector. However, there are other considerations such
as instrument set up and control. These can vary from system to system and
the following options are available:
  
●● When the same supplier makes the data system and the chromatogra-
phy equipment, control is more sophisticated and more tightly inte-
grated with the data system functions so control of the instrument and
set up of the data system can be achieved from a single workstation.
●● Communication with the auto-sampler to log the vial number being
injected is a good data integrity tool.
●● Remote monitoring of the chromatography system output including the
instrument conditions such as pump pressure.
●● Contact closures for the control of chromatographic valves or associated
equipment such as faction collectors during analysis is usually available
for other supplier’s equipment.
  
Some CDS systems can also list the chromatograph number or items of
instrument such as the pump, detector, etc., used for a particular analysis.
This is a useful function that helps to automate the administrative records
associated with an analysis and to help meet GXP compliance, traceability
and transparency. Other supplier’s CDS software can collect the serial
numbers of the instruments connected to the system but this is typically
restricted to the chromatographs manufactured by the software supplier.
The ability of a chromatography data system to control and monitor any
changes to the instruments being controlled is an advantage within a reg-
ulated environment. When a parameter is changed during an analytical run
such as an increase or decrease of the flow rate of the mobile phase or carrier
What is a CDS? The Past, Present and Future 27
gas, this is usually accompanied by an audit trail entry identifying who made
the change and when it was made, together with the original setting and the
new value. If the software has been configured to do so, the reason for the
change can be input by the user into the audit trail records either as free text
or as a user defined entry.

2.2.5 Sequence File

The sequence file is the run list or order that the samples, standards, quality
control samples and blanks will be injected into the chromatograph. This is
essential as it puts into context the content of the individual data files. Each
injection within a sequence file must be linked to a specific method file to
process the resulting data. For laboratories with large numbers of samples
for a single method, the sequence file will usually be linked with a single
method. Smaller laboratories may need the flexibility to link the sequence
file with several methods during the course of a single analytical run for best
use of equipment resources or to flush the chromatographic column and
possibly turn off the instrument.
Each sample to be analysed should be identified in the sequence file as one
of the following types:
  
●● unknown;
●● calibration standard;
●● quality control;
●● blank.
  
Depending on the data system involved, at least the first two options are
available to a user. There may also be a sample number to link the injection
to the physical sample used for analysis.
Sample identities can either be typed into the sequence file directly by the
user or the information can be downloaded electronically from a Laboratory
Information Management System (LIMS) that will be discussed in Chapter 3.

2.2.6 Acquisition of Chromatographic Data

The signal from the detector needs to be acquired by the CDS. This can occur
in one of two ways. The traditional way is via an analogue to digital (A/D) data
converter. A/D conversion is a process by which a continuously variable sig-
nal (e.g., detector voltage) is converted to a binary number that can accurately
represent the original data. It is necessary to convert the analogue signal to
a digitised form because computer systems only handle numerical informa-
tion in the form of a binary number. A detailed discussion of the principles of
A/D conversion is outside of the scope of this book and the reader is referred
to the book by Dyson1 or the article by Burgess et al.3 For a discussion of more
technical details of the CDS such as data collection rates, bunching factors
and slope sensitivity, the reader is referred to Dyson’s book.1
28 Chapter 2
Alternatively, some chromatographs have digital data acquisition where
the instrument output can be input directly to a data server and can be
manipulated without the need to use an external or internal A/D unit.
To ensure the trustworthiness and reliability of the data generated by the
system, suppliers incorporate a checksum for each data file; if any changes
have been made to the file, the checksum will be wrong and the file will be
unable to be opened by the application. This is one means for ensuring the
integrity of chromatographic data.

2.2.7 Management of Data: Database or Files?

Chromatographic data and associated files such as method, sequence,
results can be stored in one of two main ways: files within the operating sys-
tem directories or within a database. There are many advantages within a
regulated environment for the use of a database. The main reason for this
statement is the disadvantage of the directories within the operating system
used to store chromatographic data files. Users can access files outside of the
application by using operating system utilities such as Windows Explorer to
delete files without any audit trail entry. This is a major issue for ensuring
data integrity, this will be discussed in more detail later in this chapter and
also Chapter 7. In contrast, a database can automatically manage version
control of method files and sequences without operator input if the software
application has been designed appropriately.
One of the ways to get around the problem with file based CDS applica-
tions is to use a Scientific Data Management System (SDMS) that provides
the database functionality on behalf of the CDS. SDMS agents scan the direc-
tories on the CDS workstation at predefined intervals to capture and transfer
the chromatography data files to the SMDS for storage. Processing of the cap-
tured files takes place using the CDS and the reports can also be captured,
stored and managed electronically within the SDMS, if required.

2.2.8 Interpretation of Chromatographic Data

After the method file and the sequence file have been set up, the analytical
run is started and data are collected. A data file containing the A/D data slices
will be obtained for each chromatographic run and sample injected, it will be
plotted as illustrated in Figure 2.3. It is important from scientific and regula-
tory considerations that the data files must not be capable of alteration and
a supplier will usually incorporate a mathematical checksum in the data file
to identify any tampering.
Moreover, the data files must not be overwritten. This is a key area for con-
sideration when validating the chromatography data system; as you must
know what happens to your data files in a regulated environment and how
the records are protected.
The software will interpret each data file, identifying the individual peaks
and fitting the peak baselines according to the parameters defined in the
What is a CDS? The Past, Present and Future 29

Figure 2.3  typical chromatogram of an active substance separation from impuri-

A
ties and degradation products.

CDS method. The data systems should have the ability to identify whether
the peak baselines have been automatically or manually interpreted. This is
a useful feature for compliance with applicable regulations to indicate the
number of times a chromatogram has been interpreted. Chromatographic
integration in a regulated environment is discussed in more detail including
whether automatic or manual integration can be used in Chapter 29.
Most data systems should be able to provide a real-time plot, so that the
analyst can review the chromatograms as the analytical run progresses. In
addition, the plotting options of a data system should include:
  
●● fitted baselines;
●● peak start/stop ticks;
●● named components;
●● retention times;
●● timed events, e.g. integration start/stop;
●● run time windows and user defined plotting windows;
●● baseline subtract.
  
Each of these options should be capable of being enabled or disabled by a
user with the appropriate entries within an audit trail.
An overlay function should be available to enable you to compare results
between samples. This will be used to compare chromatograms from the
same run sequence as well as chromatograms from different sources. The
30 Chapter 2
maximum number of overlays will vary from data system to data system
but a minimum of 6–8 is reasonable and practicable. More overlays may be
technically possible, but the amount of useful information obtained may be
limited. Overlays that can be offset by an amount determined by the user
are more often useful to highlight certain peak information between several
injections. Ideally, the overlay screen should have hidden lines removed and
be able to be printed.

2.2.9 System Suitability Test (SST) Calculations

System suitability samples are then calculated and used to determine if the
analytical run meets the predetermined suitability criteria. There are vari-
ous parameters that can be used to determine the suitability of a method
such as:
  
●● Retention time.
●● Signal to noise ratio.
●● Column theoretical plates.
●● Resolution between two identified peaks (note that there are different
resolution equations used in the United States Pharmacopoeia <621>4
and the European Pharmacopoeia Section 2.2.46 5 that need care when
verifying each calculation).
●● Peak tailing and/or asymmetry.
  
The CDS may be set up to calculate the results as the SST samples are
injected and commit the remainder of the samples for analysis if they are
within acceptable limits. However, if the results are outside of the acceptance
criteria then the CDS can stop the samples from being injected (this feature
obviously requires the CDS to control the chromatograph).

2.2.10 Calibration
Calibration is a weak area with most data systems, as most chromatogra-
phers can use many ways to calibrate their methods as evidenced by the mul-
titude of calibration options available. Often these methods are basic and
lack statistical rigour, as the understanding of many chromatographers is
poor.
The main calibration method types are;
  
●● External standard method: the concentration of the component is deter-
mined by comparing the peak response in the sample with the response
from the analyte in a reference solution.
●● Internal standard method: an equal amount of a component that is
resolved from the substance to be determined and does not react with
it (Internal Standard) is added to the test solution and a reference solu-
tion. The concentration of the analyte is determined by comparing the
What is a CDS? The Past, Present and Future 31
ration of the peak areas (heights) of the analyte to internal standard in
the sample versus the reference solution.
●● Area normalisation: the percentage content of one or more components
of the sample is calculated by determining the area of the peaks as a
percentage of the total areas of all the peaks, excluding those due to
solvents or any added reagents and those below the limit of detection
or a disregard limit.
  
Guidance for the appropriate type of calibration method to be applied to a
specific method of determination is presented in Section 2.2.46 of the Euro-
pean Pharmacopoeia5 and is outside the scope of this book.
There are a number of calibration model options that are available in the
majority of CDS systems that could be used within any chromatography lab-
oratory. The main ones are:
  
●● bracketed standards at one concentration or amount;
●● bracketed standards at two concentration levels;
●● response function;
●● average by amount;
●● multi-level or linear regression;
●● linear regression calibration curves with and without weighting;
●● non-linear calibration method, e.g. quadratic calibration.
  
Within each calibration type, the data system must be able to cope, suffi-
ciently flexibility, with variations in numbers of standards used in a sequence
and types of standard bracketing. The incorporation of a zero concentration
standard into the calibration curve should always be an option.
Each plot of an analyte in a multi-level or linear regression calibration
model must contain an identifier for that calibration line and the analyte to
be determined. The calibration curve should show all calibrating standards
run in any particular assay. In assays containing more than one analyte it
will be necessary to interpret all the calibration graphs before the calculation
of results. Again, this is an area that may be poor for data system as many
only offer a single line fitting method for all analytes in the run resulting in
compromises.

2.2.11 User Defined Analytical Run Parameters

The system should be capable of collating user-defined parameters (e.g.
height, area, ratios, concentrations, etc.) for selected analytes from a sequence
of runs. After collation system defined and/or user defined statistical calcu-
lations will be carried out on the data generated. The type of calculations
required should include mean, standard deviation, analysis of variance and
possibly significance testing. These calculations may be unique to a labora-
tory but all must be documented in the user requirements specification for
the system as discussed in Chapter 10.
32 Chapter 2

2.2.12 Collation of Results and Reports

Ideally, the report following an individual chromatogram should contain
both elements that are user definable and those that are standard. This
should enable the laboratory to customise a report. At the end of the ana-
lytical run, a user defined summary report containing information such as
system suitability results, sample ID, area or height, baseline and calculated
analyte concentration should be created. This report can either be printed
out or transferred to a LIMS for further analysis and interpretation.

2.2.13 Architecture of a Networked CDS

The scope of a typical networked chromatography data system will consist of
several hardware components as shown in Figure 2.4:
  
●● Chromatograph: this is the instrument that performs the analytical sep-
aration and can be a high performance liquid chromatograph (HPLC),
gas chromatograph (GC) or a Capillary Electrophoresis (CE) instrument.
●● Data acquisition and instrument control; several instruments in the
laboratory will be connected to a laboratory data server for instrument
control and data acquisition. Data acquisition can be via an analogue
to digital (A/D) converter from the instrument detector to the CDS that
converts the continuous analogue signal to a number of discrete digital
data readings that are fed into the data server. Often, the laboratory data
server has a buffering capability so that if the network is temporarily
unavailable data can be stored locally before transfer to the network

Figure 2.4 
Schematic diagram of a networked chromatography data system.
What is a CDS? The Past, Present and Future 33
server, this function is to prevent data loss. Data acquisition via a direct
digital link (e.g. LAN) is also an option.
●● Network: transport medium for moving the data from the instrument
and laboratory data server to a network server for secure data storage.
●● Workstation (client): for operating the CDS, setting up an instrument,
checking that the separation is working correctly, interpreting the resul-
tant chromatograms after the run is finished and reporting the results.
  
A data system such as shown in Figure 2.4 can operate in a single labora-
tory, across a number of buildings, a whole site or between sites. The number
of users and instruments can vary from tens to hundreds. The key to suc-
cessful and cost effective validation of these larger systems is the validation
strategy that will be described in Chapter 11.

2.3 Evolution of Chromatography Data Systems

In this section, I will present an overview of how chromatographic peak mea-
surement and analyte quantification in analytical laboratories has evolved
from the manual methods of 1970 to the electronic working possible in
the 21st century. In the 45 years from 1970 to 2015 there have been major
changes in the way chromatographic data and output has changed.1,6 This
is from a simple chart recorder where output that was interpreted and quan-
tified manually, through simple automation of peak measurement, calcula-
tion of standard curves and QC values, instrument control to the networked
chromatography data systems (CDS) of today that are capable of interfacing
with LIMS and other IT applications. The incorporation of electronic signa-
tures to meet regulatory requirements offers a great opportunity for business
improvement and electronic working as we will examine in Chapter 9.

2.3.1 CDS: Where Have We Come From?

Looking back from today’s CDS we will see an evolutionary journey from
manual peak measurement though to an expansion of scope into instru-
ment control, calculation of standard curve parameters, reporting results
and interfacing with informatics applications in the laboratory, such as Lab-
oratory Information Management Systems (LIMS), that manage the studies,
sample management, analytical results and reports.
In the 1970s laboratories analysed relatively small numbers of samples.
Method validation was relatively simplistic, the techniques for quantifica-
tion were, in comparison to today, crude and there was little attempt to run
quality control samples or check analytical run to run variation. In the 1980s
this started to change and larger numbers of samples were generated and in
1990s the start of guidelines for method validation under ICH Q2A and Q2B
and the combined update Q2R1 7 and from the FDA8 and EMA9 for bioanalyt-
ical methods. Furthermore, GXP regulations have all had an effect on chro-
matography data systems used in pharmaceutical R&D and quality control