International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries

P1: OTE fm JWBK188-Segalstad October 3, 2008 17:34 Printer: Yet to come International IT Regulations and Complianc...

Author: Siri H. Segalstad

188 downloads 860 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34

Printer: Yet to come

International IT Regulations and Compliance

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


International IT Regulations and Compliance Quality Standards in the Pharmaceutical and Regulated Industries

SIRI H. SEGALSTAD SEGALSTAD CONSULTING AS, NORWAY

A John Wiley and Sons, Ltd., Publication

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


This edition first published 2008 C 2008 John Wiley & Sons Ltd Registered office John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com. The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought. The Publisher and the Author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of fitness for a particular purpose. The advice and strategies contained herein may not be suitable for every situation. In view of ongoing research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the Author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. No warranty may be created or extended by any promotional statements for this work. Neither the Publisher nor the Author shall be liable for any damages arising herefrom. Library of Congress Cataloging-in-Publication Data Segalstad, H. Siri. International IT regulations and compliance : quality standards in the pharmaceutical and regulated industries / Siri H. Segalstad. p. cm. Includes bibliographical references and index. ISBN 978-0-470-75882-3 (cloth : alk. paper) 1. Pharmaceutical technology–Standards. 2. Pharmaceutical industry–Standards. 3. Pharmaceutical industry–Quality control. 4. Drugs–Standards. I. Title. RS192.S44 2008 615 .19–dc22 2008027452 A catalogue record for this book is available from the British Library. ISBN 978-0470-758823 Typeset in 10/12pt Times by Aptara Inc., India Printed and bound in Great Britain by Antony Rowe, Ltd, Chippenham, Wiltshire

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


Contents

Preface and Acknowledgements

xiii

1

Quality Standards 1.1 What Quality Is 1.2 Mandatory and Voluntary Standards 1.3 Pharmaceutical Industry Regulations 1.4 US GxP Regulations 1.5 European GxP Regulations 1.6 Other GxP Regulations 1.7 Good Manufacturing Practice 1.8 Good Laboratory Practice 1.9 Good Clinical Practice 1.10 Medical Device Standards 1.11 IT Systems in the GxP and Medical Device Regulations 1.12 GAMP 1.13 Mandatory Quality Standards in Other Industries 1.14 Legal Issues 1.15 The ISO 1.16 The ASTM 1.17 The IEEE 1.18 Tasks References

1 1 2 3 3 4 4 4 5 6 6 8 10 10 12 12 13 14 14 15

2

Regulatory Requirements for IT Systems 2.1 Introduction 2.2 US Requirements 2.3 EU Requirements 2.4 21 CFR Part 11

19 19 20 21 21

P1: OTE fm

JWBK188-Segalstad

vi

October 3, 2008

17:34


Contents

2.5 The ‘Part 11 Project’ 2.6 EU GMP Annex 11 2.7 The PIC Document PI 011 Recommendation on Computerized Systems in Regulated ‘GxP’ Environments 2.8 GAMP 2.9 The ISO 9000 Series 2.10 A Comparison between the Standards 2.11 Conclusion 2.12 Tasks References

30 32

3

IT Security 3.1 Introduction 3.2 Continuous Connections – Wireless Networks 3.3 Threats 3.4 The Security Policy 3.5 Tasks References

51 51 52 52 53 54 55

4

Quality Management Systems 4.1 An Introduction to QMS 4.2 Definitions 4.3 Principles for Quality Management 4.4 Quality Management System Levels 4.5 Creating a QMS 4.6 Roles and Responsibilities 4.7 Work Processes 4.8 Controlled Documents 4.9 The Quality Policy 4.10 The Quality Manual 4.11 Standard Operating Procedures 4.12 The Art of Writing an SOP 4.13 Tasks References

57 57 58 59 60 61 61 63 63 65 67 68 69 73 73

5

IT Integrated in the QMS in the User Organization 5.1 Introduction 5.2 How to Integrate IT Systems in the QMS 5.3 Generic Standard Operating Procedures 5.4 Procedures for Each System 5.5 Tasks References

75 75 76 77 89 97 97

6

IT Integrated in the Supplier’s QMS 6.1 Introduction 6.2 Which Standards Should Be Used?

41 43 45 45 47 47 47

99 99 100

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


Contents

6.3 6.4 6.5 6.6 6.7

The Quality Management System System Development Models Documents for Software Development The Customer–Supplier Relationship Tasks References

vii

101 103 111 115 116 117

7

Organization for an IT System 7.1 Introduction 7.2 Roles and Responsibilities for a Live System 7.3 Groups in the IT System Organization 7.4 Roles and Responsibilities for an IT Validation Project 7.5 Outsourcing 7.6 The Service Level Agreement for Outsourcing 7.7 Consultants References

119 119 119 121 121 122 122 124 126

8

The Legal Implications of an IT System 8.1 Introduction 8.2 Pharmaceutical Regulations 8.3 Financial Systems 8.4 Patent Systems 8.5 Human Resources Systems 8.6 Healthcare Systems 8.7 Systems for Legal Information Reference

127 127 128 128 128 129 129 129 132

9

Advanced Quality Management Systems 9.1 Introduction 9.2 The Live QMS is a Good QMS 9.3 Changes 9.4 How to Keep the QMS Updated 9.5 Training and Understanding 9.6 How to use a QMS Effectively as a Tool in the Organization – Not as a Straightjacket 9.7 Tasks References

133 133 134 134 135 135

Audits 10.1 Introduction 10.2 The ISO 9000 Series 10.3 TickIT 10.4 Why Audit? 10.5 Audit in a Risk-Based Environment 10.6 Audit Scope 10.7 Supplier Audit Preparations

141 141 142 142 143 144 145 146

10

136 139 139

P1: OTE fm

JWBK188-Segalstad

viii

October 3, 2008

17:34


Contents

10.8 10.9 10.10 10.11 10.12 10.13 10.14 10.15

During the Audit What to Look For Other Issues Findings/Discrepancies The Closing/Wash-up Meeting The Audit Report Conducting an Audit from the Receiving Side of the Table Tasks References

149 149 152 153 153 154 154 155 155

11

Validation of IT Systems 11.1 Introduction 11.2 External Requirements for Validation 11.3 Internal Requirements for Validation 11.4 The Validation Cost 11.5 Inspectors 11.6 The Validation Scope is Changing 11.7 A Computer Validation Project 11.8 Which Hardware and Software is To Be Validated? 11.9 The Network 11.10 Software 11.11 Risks and System Categories 11.12 Qualifications 11.13 Development Qualification 11.14 Installation Qualification 11.15 Operational Qualification 11.16 Process/Performance Qualification 11.17 The Validation Master Plan 11.18 The Validation Plan 11.19 The Validation Report 11.20 Tasks References

157 157 157 158 160 160 161 162 163 163 164 164 164 166 166 167 167 167 169 174 174 178

12

Risk Assessment and Risk Management 12.1 Introduction 12.2 Addressing Risks 12.3 Risk Assessment Tools 12.4 Risk Assessment 12.5 Risk Management 12.6 Tasks References

179 179 181 181 182 185 187 187

13

Development Qualification 13.1 Introduction 13.2 The User’s Point of View 13.3 The Supplier’s Point of View

189 189 190 191

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


Contents

13.4 13.5 13.6 13.7

Project: A New System in the User Organization The Four Assessments of System Selection The Functional Specification and System Implementation Tasks Acknowledgment References

ix

191 192 201 203 203 204

14

Installation Qualification 14.1 Introduction 14.2 IQ Organizational Issues 14.3 The IQ Plan 14.4 IQ Testing 14.5 The IQ Report 14.6 Tasks

205 205 206 206 207 207 207

15

Operational Qualification 15.1 Introduction 15.2 The OQ Framework 15.3 What if the Supplier has Done OQ? 15.4 The OQ Plan 15.5 OQ Testing 15.6 The Documentation of Testing 15.7 The OQ Report 15.8 Tasks Reference

209 209 209 210 210 212 214 214 214 214

16

Process/Performance Qualification 16.1 Introduction 16.2 The PQ Plan 16.3 PQ Test Plans 16.4 Documentation during Testing 16.5 The PQ Report 16.6 Ongoing PQ 16.7 Tasks

215 215 216 216 223 224 224 224

17

Laboratory Instrument Systems 17.1 Introduction 17.2 Instruments 17.3 Analytical Instruments in the Laboratory 17.4 Raw Data and Meta Data 17.5 Devices 17.6 Biometric Devices 17.7 Electronic Lab Notebooks 17.8 Validation of Computerized Instrument Systems 17.9 Pure Computer Systems 17.10 Computerized Instruments that Can Run ‘Barefoot’

225 225 225 226 229 230 230 231 231 232 232

P1: OTE fm

JWBK188-Segalstad

x

October 3, 2008

17:34


Contents

17.11 Integrated Computerized Instruments 17.12 Qualification of Laboratory Instruments References

233 233 235

18

Laboratory Information Management Systems 18.1 Introduction 18.2 Should You Build or Buy a New LIMS? 18.3 The Real Cost of a LIMS 18.4 Differences between Commercial LIMS Systems 18.5 Static and Dynamic Data 18.6 Static Data 18.7 Dynamic Data 18.8 LIMS Functionality 18.9 Types of Production 18.10 Analytical Methods 18.11 Calculations in Analytical Methods 18.12 Specifications and Limits 18.13 Standards, Solutions, and Chemicals Used in the Laboratory 18.14 Instrument Connections and Definitions 18.15 Instrument Information 18.16 Do We Store the Data in the Instrument System or in the LIMS? 18.17 Stability Studies and Stability Testing 18.18 Pharmacokinetic Studies and Testing 18.19 Dissolution Testing 18.20 Information on Animals or Patients 18.21 Customer Information 18.22 Bar-Coded Labels 18.23 Radio Frequency Identification 18.24 The Chain of Custody 18.25 Sample Scheduling and the Workload 18.26 Status 18.27 Security 18.28 Specifying and Choosing the New LIMS 18.29 The Traceability Matrix 18.30 A List of SOPs for a LIMS 18.31 Tasks References Further Reading

237 237 238 241 242 244 244 244 245 245 246 249 250 253 255 256 256 258 259 259 260 261 261 261 262 262 263 264 265 266 266 266 270 270

19

Building Management Systems and Heating, Ventilation, and Air Conditioning 19.1 Introduction 19.2 BMS Systems 19.3 Programmable Logical Controllers 19.4 SCADA 19.5 Control Parameters and Instrumentation

273 273 274 276 276 276

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


Contents

19.6 19.7 19.8 19.9 19.10 19.11 19.12 19.13 19.14 19.15 19.16

Sterile Facilities Regulatory Requirements and Validation Enforcement Validation of Old HVAC/BMS Systems New Systems Risk Assessment Electronic Records in the BMS Validation Installation Qualification Operational Qualification and Process/Performance Qualification Standard Operating Procedures Tasks References

xi

277 277 281 281 282 283 284 285 286 286 286 286

Appendix 1 Regulation comparisons

289

Appendix 2 Terminology

295

Index

315

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


Preface and Acknowledgments

In 2003–2006, I was a part of an EU Leonardo da Vinci project, where the goal was to create a complete curriculum for a Master’s Degree in IT Validation. The education was to be based on existing books. I was in charge of four classes. Several books on the market include valuable information, but I found that there were no books that covered everything I wanted to include in my classes. The solution was to write this book, which I hope will be useful for students as well as for people working with Quality Assurance and validation of IT systems. Many relatives and friends have encouraged me and helped me while I have been working on this book. I would like to thank my son Eric V. Segalstad for his valuable insights on writing a book and help with editing, and my daughter Anita S. Hurlburt for editing most of the chapters. Eric has a Masters in Journalism and Anita has a Bachelor’s with English major, and they both know the English language better than I do. I would also like to thank my father, Johan Fuglesang, who read through several of the chapters – despite his mature age of 80, he has not forgotten his Quality Assurance or his translator’s English. Anders Bredesen suggested including the chapter on Building Management Systems, and offered valuable comments about the text that I wrote. Our friend Josh Hunter is the great artist who produced the book cover. Finally, I would like to thank my husband, Tom V. Segalstad, who has encouraged me the whole way.

P1: OTE fm

JWBK188-Segalstad

October 3, 2008

17:34


P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


1 Quality Standards

This chapter discusses the following: r What quality is r Which mandatory and voluntary quality standards various industries use r What these standards say about IT systems

1.1

What Quality Is

Quality is defined in the International Organization for Standardization (ISO) standard 8402 [1] as ‘The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.’ Quality is defined in the Concise Oxford Dictionary [2] as ‘possessing high degree of excellence, concerned with maintenance of high quality (Quality Control).’ There will always be subjectivity involved when defining whether something has good, not so good, or bad quality. As ISO states, it also has something to do with ‘implied needs,’ which definitely will change over time. Forty years ago, a quality car had good seats, a working engine, and room for the luggage in the back; cars did not have air conditioning, seat belts, or airbags at that time. Today, any ‘quality car’ has all of these features as standard, and new inventions such as GPS may be considered a quality feature. In 10 years’ time, this will probably be standard quality, while the new development will be electronics to prevent collisions. So how do we define quality, apart from the definition of the word itself? There are many standards around the world that govern quality and define what is needed in order to have a quality product. Some are mandatory to specific industries, while others International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c01

JWBK188-Segalstad

2

October 1, 2008

11:11


Quality Standards

are optional. Some are international; others are national; some are based around a political entity, such as the European Union (EU) or the Organization for Economic Cooperation and Development (OECD); and some are independent, such as the International Organization for Standardization. Each company or organization will need to have a quality system to explain exactly how it wants to work in order to create and produce quality goods or services according to the standard that it needs to follow. The lack of proper standards can result in large costs when batches or studies have to be reproduced or redone. Philip B. Crosby [3] has written: ‘Quality is free. It is not a gift, but it is free. What costs money are the unquality things – all the actions that involve not doing jobs right the first time.’ The way to avoid these costs is not to cause them in the first place, and that implies creating systems to explain in detail how to work in order not to make costly mistakes. Quality assurance isn’t something to learn in a week-long class and read about in ISO, GMP, GLP, GCP, or other quality standards. Unfortunately, it is also rarely taught in schools and universities, but today at least people recognize the expression. It takes a long time to become a good Quality Assurance person. Knowledge of the standards is of course necessary, but even more so is the acquired feel for the ‘quality way’ of thinking, understanding, and seeing. The good QA people know the art of writing good Standard Operating Procedures (SOPs) and other quality documents, know ways of expressing themselves, and understand the consequences of the lack of quality. They are also able to see what is missing and what could be done better in any quality system. Quality assurance has grown to be a part of the person.

1.2

Mandatory and Voluntary Standards

Some industries are required to follow specific standards, while others may follow standards if they want to. Some examples are given below: r The regulated industries include the pharmaceutical and nuclear sectors: Both are important in terms of public health and safety. Several of the standards that they follow are international. The controlling organs include the EU for products/production in the European market and the United States for products/production in the US market. The authorities require the industries to follow these standards, and can punish companies if they fail to do so. If a pharmaceutical company isn’t in compliance with the standards, it can lose the license to sell its products; this, of course, is financially devastating to the company r Semiregulated industries include healthcare, where there are large differences between the various countries. The controlling organs are national control bodies r Nonregulated industries may want to follow a standard because it gives them a competitive edge. They may want to obtain a certification or accreditation to prove that they follow the standard. The controlling organs are accreditation and certification bodies

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


US GxP Regulations

1.3

3

Pharmaceutical Industry Regulations

Three good practices cover the pharmaceutical industry: r Good Manufacturing Practice (GMP), which covers manufacture and Quality Control of the products r Good Laboratory Practice (GLP), which covers nonclinical testing of the products r Good Clinical Practice (GCP), which covers clinical testing on humans The acronym GxP is quite often used to cover one, two, or all three of GMP, GLP, and GCP. It would be relatively easy to follow these standards if there were only the three GxPs, but there’s more than one of each. The EU, the United States, Japan, Australia, and the OECD – just to mention a few – each have their own set of GxPs. Each company has to comply with the GxP in each market where it wants to sell its goods. So even if the company is manufacturing in Europe, it will need to comply with the US regulations when trading in the US market. Companies marketing world-wide must comply with all standards world-wide. Many countries are trying to harmonize the standards. Europe has been able to get rid of the Nordic, German, British, and other GxPs and has replaced them with a European GxP. The United States, Japan, and the EU are working together in the International Conference on Harmonisation (ICH). The ICH is a cooperative effort between the drug regulatory authorities and the pharmaceutical organizations to reduce the need to duplicate the testing conducted during the research and development of new medicines, while at the same time maintaining the quality, safety, and effectiveness of those medicines. Additionally, the authorities – not to mention the companies themselves – would like to see that once one agency has finished inspection, the others will accept this and not reinspect. The EU has established the European Medicines Agency (EMEA) (www.emea.eu.int). The EMEA has worked for a Mutual Recognition Agreement with Canada and Japan in its Work Program (December 2004), and the United States is currently working its way into this cooperative venture.

1.4

US GxP Regulations

All products on the US market must be made and tested according to the US regulations, regardless of the production site or country where the organization is legally registered. Chapter 21 of the Code of Federal Regulations (21 CFR) describes the laws and regulations covering the pharmaceutical industry, which are numbered as ‘Part xxx.’ All regulation documents and guidance documents can be downloaded from the FDA homepage (www.fda.gov). Due to the US Freedom of Information Act, the inspection results are also available to the public and can be found on the FDA home page. The ‘warning letters’ say a lot about what the inspectors are looking for and how they interpret the regulations at any given time. Below is a list of regulations, but there are many more; these are outside the scope of this book. Some cover New Drug Approval (21 CFR Parts 312, 314, and 511), while others cover how to set up and conduct clinical trials, ensuring patient safety in clinical trials, and more.

P1: OTE c01

JWBK188-Segalstad

4

October 1, 2008

11:11


Quality Standards

1.5

European GxP Regulations

All products on the European market must be made and tested according to the European regulations, regardless of the production site or country where the organization is legally registered. The regulations cover all countries in the European Union as well as the European Economic Area (EEA) countries Norway, Iceland, and Liechtenstein. Switzerland is a large producer of pharmaceutical products, so even though it isn’t a member of the EU or the EEA, the European regulations apply because Swiss products are exported to the EU. The EU regulations can be downloaded from the Web (http://www.pharmalaw.org/ eu laws.htm).

1.6

Other GxP Regulations

Both Japan and Australia have started mutual recognition discussions with the EU through the EMEA and the ICH.

1.7

Good Manufacturing Practice

Good Manufacturing Practice (GMP) covers requirements for the manufacturing and quality testing of products. This includes everything from raw materials and production, through laboratory testing, to labeling and packaging. 1.7.1

US GMP

The latest GMP issued features one major change: the use of a risk-based approach so that the organization can analyze risks and determine where it needs to add effort and control. This has also made it possible to use Process Analysis Technology (PAT) to help the organization understand its processes. The risk management is based on the ICH Draft Consensus Guideline Q9 Quality Risk Management [4]: 21 CFR Part 210 21 CFR Part 211

Current Good Manufacturing Practice in Manufacturing, Processing, Packing, or Holding of Drugs; General [5]. Current Good Manufacturing Practice for Finished Pharmaceuticals [6].

There are several more detailed parts to the GMP. The list below is not complete: r Active Pharmaceutical Ingredients: ICH Q7A Guidance to Industry GMP for Active Pharmaceutical Ingredients [7] r Draft Guidance to Industry Quality Systems Approach to Pharmaceutical Current Good Manufacturing Practice Regulations (draft, September 2004) [ [8] r Parts covering New Drug Approval, GMP for Blood and blood components, and others

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


Good Laboratory Practice

5

r The FDA has also teamed up with the ASTM to create a Standard Guide for Specification, Design and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment [9] 1.7.2

EU GMP

Volume 4 – Good Manufacturing Practices – Medicinal Products for Human and Veterinary Use [10].

1.8

Good Laboratory Practice

Good Laboratory Practice (GLP) covers the nonclinical testing of the products, but not the production-quality laboratory. Nonclinical testing includes the testing done on animals. Whether people agree with the practice or not, animal testing is required before the company can obtain a license to sell the product. The GLP has strict requirements for how the animals are to be treated and how data is to be secured and handled. 1.8.1

US GLP

21 CFR Part 58 Good Laboratory Practice for Nonclinical Laboratory Studies [11]. This document does not include the word ‘computer’ or any of its synonyms. However, there is a chapter on equipment. It is easy to see that computer systems are included in the expression ‘equipment,’ and that they need to be validated (appropriate design/function according to protocol/testing). Additionally, it is quite obvious that when a computerized system handles data for GLP, the requirements for the data will also apply to the system: Equipment used in the generation, measurement, or assessment of data and equipment used for facility environmental control shall be of appropriate design and adequate capacity to function according to the protocol and shall be suitably located for operation, inspection, cleaning, and maintenance. . . . Equipment shall be adequately inspected, cleaned, and maintained. Equipment used for the generation, measurement, or assessment of data shall be adequately tested, calibrated and/or standardized.

1.8.2

EU GLP

EU GLP EU GLP

Council Directive of 7 June 1988 on the Inspection and Verification of Good Laboratory Practice (GLP) (88/320/EEC) [12]. Council Directive – of 24 November 1986 – 86/609/EEC – on the approximation of laws, regulations, and administrative provisions of the Member States regarding the protection of animals used for experimental and other scientific purposes [13].

P1: OTE c01

JWBK188-Segalstad

6

October 1, 2008

11:11


Quality Standards

1.9

Good Clinical Practice

Good Clinical Practice (GCP) covers the clinical testing of the product: the testing on humans. The testing required before the company can obtain a license to sell the product is divided into three phases (I, II, and III), each of which expands the number of patients included in the previous phase. Some of the testing is also required for a period after the product has received its license, and this is called phase IV. 1.9.1

US GCP

Clinical trials are covered in a number of parts of 21 CFR. Here are the most important ones: 21 CFR Part 50 21 CFR Part 54 21 CFR Part 56 21 CFR Part 312

Human Subject Protection (Informed Consent) [14]. Financial Disclosure by Clinical Investigators [15]. Institutional Review Boards [16]. Investigational New Drug Application [17].

On the FDA web page, 21 CFR Part 11 Electronic Records; Electronic Signatures [18] is also listed for GCP regulations. 21 CFR Part 11 is discussed below. 1.9.2

EU GCP

EU GCP EU GCP

1.10

Directive 2001/20/EC relating to the implementation of good clinical practice in the conduct of clinical trials on medicinal products for human use [19]. Directive 2001/20/EC of April 4, 2001 on the approximation of the laws, regulations, and administrative provisions of the Member States relating to the implementation of good clinical practice in the conduct of clinical trials [20].

Medical Device Standards

Medical devices are categorized by their impact on the body. The lowest class I is comprised of items used externally – such as band-aids – and the highest class III is comprised of items used internally, to keep a person alive – such as pacemakers. It has also been suggested that cigarettes should be defined as medical devices ‘used for inhaling poisonous smoke,’ in order to regulate the tobacco industry in the United States, but this hasn’t happened yet. Whether or not this was meant to be a joke isn’t known. According to EU Council Directive 93/42/EEC of June 14, 1993 [21], a medical device is defined as follows: (a) ‘medical device’ means any instrument, apparatus, appliance, material or other article, whether used alone or in combination, including the software necessary for its proper application intended by the manufacturer to be used for human beings for the purpose of:

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


Medical Device Standards – – – –

7

diagnosis, prevention, monitoring, treatment or alleviation of disease, diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap, investigation, replacement or modification of the anatomy or of a physiological process, control of conception,

and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means; (b) ‘accessory’ means an article which whilst not being a device is intended specifically by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device; (c) ‘device used for in vitro diagnosis’ means any device which is a reagent, reagent product, kit, instrument, equipment or system, whether used alone or in combination, intended by the manufacturer to be used in vitro for the examination of samples derived from the human body with a view to providing information on the physiological state, state of health or disease, or congenital abnormality thereof;

The EU classification system for medical devices has three classes as defined in EU Council Directive 93/42/EEC of June 14, 1993: Class I: Non-invasive devices Class II: Surgically invasive devices intended for transient use Active therapeutic devices intended to administer or exchange energy Implantable devices and long-term surgically invasive devices Devices used for contraception or the prevention of the transmission of sexually transmitted diseases Class III: Invasive devices Devices incorporating, as an integral part, a substance which, if used separately, can be considered to be a medicinal product, and which is liable to act on the human body with action ancillary to that of the devices. Contraception or the prevention of the transmission of sexually transmitted diseases if they are implantable or long-term invasive devices.

Note that this is not a complete list; please see the directive for additional details. The US classification system for medical devices has three classes, as defined in 21 CFR 860 [22]: A device is in class I: . . . the device is not life-supporting or life-sustaining or for a use which is of substantial importance in preventing impairment of human health, and which does not present a potential unreasonable risk of illness of injury. A device is in class II: . . . use in supporting or sustaining human life . . . A device is in class III: . . . the device is life-supporting or life-sustaining, or for a use which is of substantial importance in preventing impairment of human health, or if the device presents a potential unreasonable risk of illness or injury.

P1: OTE c01

JWBK188-Segalstad

8

October 1, 2008

11:11


Quality Standards

1.10.1

The US Medical Device

There are several parts of 21 CFR that cover medical devices. The most important ones are listed below. 21 CFR Part 803 21 CFR Part 806 21 CFR Part 820 21 CFR Part 821 21 CFR Part 860

Medical Device Reporting. Medical Device Reports of Corrections and Removals. Medical Devices Quality Systems Regulations [23]. Medical Device Tracking Requirements. Medical Device Classification Procedure.

For more information, check the FDA web page. 1.10.2

The EU Medical Device

The EU has two main Council directives covering medical devices: Council Directive 93/42/EEC of June 14, 1993, concerning medical devices. Council Directive 90/385/EEC of June 20, 1990, on the approximation of the laws of the Member States relating to active implantable medical devices [24].

1.11

IT Systems in the GxP and Medical Device Regulations

IT systems may have a direct or indirect impact on product quality in various ways. Such IT systems are generally called GxP systems. Systems may have an indirect impact if they handle the quality system and the Standard Operating Procedures, or a more direct impact if they handle production and validation documents. GxP systems with a direct impact include, but are not limited to, the handling of raw materials used in the production, production planning, and control systems; laboratory systems; and clinical systems. The GxPs themselves don’t say very much about IT systems, so the authorities have created amendments and/or added standards to make companies understand how they are expected to handle IT systems. In an old version of the EU GCP in the early 1990s, the only requirement for computer systems was that ‘Computer systems shall be validated and error free.’ The next version had removed the requirement ‘error free . . .’. The current version doesn’t even mention computers. IT systems for medical devices are used in two entirely different ways. The first is when the IT system is used for the development, production, and control of the medical device – just as it is for any pharmaceutical company. It must then be handled in the same way as IT systems are handled in GxP. The second is when the IT system is the medical device itself. Some medical devices – for example, pacemakers – are implanted in the body. Others are used for in vitro (outside of the body) testing – for example, testing for allergies – where the test instrument is regarded as a medical device. An IT system is often regarded as a quality challenge. In the industry, people have their degrees and training in biology, chemistry, and pharmacy, with specialization in production processes, analytical laboratory work, and so on. An IT system is regarded as a tool to

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


IT Systems in the GxP and Medical Device Regulations

9

help the scientists do the work that they understand. While the scientists understand what the system does, they don’t know how it has been programmed or how it works, and they find it difficult to handle from the point of view of Quality Assurance. The object of this book is to make non-IT people able to handle IT systems even without programming knowledge. 1.11.1

US IT Regulations

Guidance for Industry on Computerized Systems Used in Clinical Trials [25]: 21 CFR Part 11

Electronic Records; Electronic Signatures.

In the 1990s the pharmaceutical industry wanted a guideline for electronic signatures. The FDA created the 21 CFR Part 11 Electronic Records; Electronic Signatures. The first draft was made public and received a lot of comments, some of which were contradictory, but all were included in the preamble of the final rule when it was published on March 20, 1997. The FDA expected that the industry should be able to comply with the rule within four months – by August 20, 1997. The industry was surprised to see that very little of the regulation actually covered the electronic signatures, while the majority of the text covered electronic records. However, that does make sense: You can only trust the electronic signature if the electronic records can be trusted. For more details on 21 CFR Part 11, please refer to Chapter 2. 1.11.2

EU IT Regulations

Details of the EU regulations for IT systems can be found in Chapter 2. What follows is only a short overview. GMP: The EU GMP added Annex 11 to explain what the regulators thought was needed for computerized systems. Annex 11 has 19 clauses covering what the inspectors expect from the industry, but it isn’t very useful as a tool to understand how thee requirements can be accomplished. Annex 11 originated as PIC GMP Annex 5 in 1991 and was later adopted by the EU GMP as Annex 11. As of January 2008, the GMP Annex 11 is still the current requirement for IT systems – considering the speed at which technology has improved since this document was created, it is about time for Annex 11 to be revised. The Pharmaceutical Inspection Cooperation Scheme (PIC/S; see www.picscheme.org) is the organization for inspectors from a total of 31 countries, including most of the European countries, Australia, and Canada, but not the United States. The inspectors also thought that it was about time to revise Annex 11, especially after the FDA had created the 21 CFR Part 11, with its detailed requirements. The PIC/S finalized their document under the name PI 011-01 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments. The current version is now PI 011-03 [26]. There is a precedent for PIC/S documents to be included in the EU GxP, as we have seen with PIC/S GMP Annex 5, which became EU GMP Annex 11, so we can expect this document to become an annex to the GxPs in the future. When the inspectors get together and create a document like this, it is worth paying attention to it.

P1: OTE c01

JWBK188-Segalstad

10

October 1, 2008

11:11


Quality Standards

GLP has long used the OECD Monograph 116 [27] for the pharmaceutical industry, which contains more detail than the old GMP Annex 11. The new PIC/S document also covers GLP. GCP has adopted the GMP Annex 11, but the new PIC/S document also covers GCP.

1.12

GAMP

Good Automated Manufacturing Practice (GAMP) was started as a private initiative to explain to the pharmaceutical industry what was needed of IT systems validation in order to fulfill the regulatory requirements, since these requirements were very hard to translate into ‘what do we actually do to validate our computer system.’ More than 10 years later, GAMP is now an industry standard, endorsed by the FDA. This has transformed GAMP from a guideline to a more or less mandatory standard. The current version is GAMP 5 Good Automated Manufacturing Practice [28]. The GAMP organization is a voluntary body, in which many people around the world take part in preparing various standards and good practices under the International Society for Pharmaceutical Engineering (ISPE) umbrella. The result is that GAMP has issued several guidelines as answers to the new regulatory initiatives: r the Part 11 risk-based approach to validation [29] r the laboratory instruments guide [30] r the testing of GxP critical systems [31] r global information systems [32] r calibration management [33] r the infrastructure guide [34] r process control systems [35] r the archiving of electronic data [36] GAMP is currently working on several new guides. There are also smaller guides called Position Papers, which include a guide for Building Management Systems [37]. Standards usually cater to one specific type of organization. For example, the ISO 9000 series is meant for manufacturers; the GxP standards are meant for pharmaceutical development, testing, and production; and the PIC/S standards are meant for pharmaceutical inspectors. GAMP is the only standard that caters to them all. It has chapters for the developers of the system – that is, the suppliers – on how to develop the system in a GxP environment; chapters for the QA inspectors, so that they will know what to look for when doing a supplier audit; and chapters for the end-users, so they will know what to do with, for example, validation of their system.

1.13

Mandatory Quality Standards in Other Industries

The nuclear industry is often thought of as the nuclear power industry, but also other industries can also fall into this category. There are nuclear research facilities, and nuclear pharmaceuticals for use in diagnostics and cancer treatment. The production facilities of these industries are also covered in the nuclear regulations, in addition to the GMP.

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


Mandatory Quality Standards in Other Industries

11

Transport of nuclear material is also a potential health hazard, which is covered by health, environmental, and other safety regulations. In the United States, the nuclear industry is covered in 10 CFR, and governed by the US Nuclear Regulatory Commission (www.nrc.gov). Healthcare is a national activity and is governed by national laws. In the United States, most healthcare facilities – such as hospitals – are private. The governmental US Occupational Safety and Health Administration (OSHA; see www.osha.gov) has requirements for how these are to be handled. In many European countries, the hospital system is governmental, and quality requirements are rarely as strict when it is the government that has to pay for compliance, rather than private organizations. The laws governing healthcare are mainly national laws. In most countries, there are also regulations for how patient data is to be treated to maintain confidentiality.

1.13.1

The Food Industry

The US FDA covers both food and medicines in its GxP standards. The FDA also has its own Center for Food Safety and Applied Nutrition (CFSAN). Their web page (www.cfsan.fda.gov) includes all regulations for foods and cosmetics. In Europe, the EU has created an integrated approach to food safety that aims to assure a high level of food safety, animal health, animal welfare, and plant health within the European Union. The food regulations are managed by the European Food and Safety Authority (EFSA). More information can be found on their web page (http://www.ec.europa.eu/food/ index en.htm). 1.13.2

GALP – The Environmental Standard in the United States

The US Environmental Protection Agency (EPA) has issued standards for Good Automation Laboratory Practices – GALP [38]. GALP is mandatory for all industries in the United States, but is only relevant for industries that are actually producing in the United States. More information can be found in a book on GALP written by Dr Sandy Weinberg [39].

1.13.3

Health, Environment, and Safety

The employees’ health, safety, and work environment are also mandatory issues in many countries. These are legal obligations, which are usually governed by national laws rather than international laws. The IT systems taking care of these issues also need to be subject to control. National standards and laws cover requirements for the health, environment, and safety of employees. These include requirements on health issues, such as a smoke-free work environment, the internal environment temperature, humidity, light and access to daylight; protection from chemicals and other harmful substances; and protection from physical hazards such as falling building materials in the construction industry or wet floors in a production environment.

P1: OTE c01

JWBK188-Segalstad

12

October 1, 2008

11:11


Quality Standards

The EU initiative for a directive for Registration, Evaluation, Authorization and Restriction of Chemicals (REACH) [40] (http://www.ec.europa.eu/enterprise/reach/ index en.htm) covers chemicals and their transportation, labeling, and use, to mention a few. When it is implemented, the directive will hopefully have a positive impact on chemicals on health, the environment, and safety.

1.14 1.14.1

Legal Issues Finance

Regardless of the type of industry, there will normally be legal issues that have to be dealt with correctly. One is finance, where tax authorities have their say. IT systems taking care of book-keeping and financial transactions are also subject to scrutiny by the authorities – even if they don’t form part of a GxP system. Financial issues may be national or international, and include financial planning and reporting, economy and book-keeping, and taxation issues. IT systems are generally used for these purposes, and they need to be handled so that they yield correct results. However, there are no legal requirements to prove that the systems are correct. 1.14.2

Patents

Patents are important in the pharmaceutical, biotechnology, and medical device industries, as well as in other industries. While projects in early phases are not a part of the GxPs, it is important for companies to have their systems dealing with patent issues under control, to provide proof of discovery for patents. Electronic Lab Notebooks (ELN) are increasingly used in the work done prior to the patent application. When used correctly, these will provide better security for data than a paper laboratory notebook, as it is more difficult to be fraudulent. The ELN is described in Chapter 18.

1.15

The ISO

The International Organization for Standardization (ISO; see www.iso.org) is an international body that creates standards for the industry to use on a voluntary basis. It is possible to use some of the standards for accreditation and certification purposes, while others are guidelines or describe other issues. Several national standards use translated ISO standards as their local standards. The ISO also implements good national standards as ISO standards. One example of that is the British Standard BS 7799 on IT security, which has been adopted as international standard ISO 17799 [41]. An organization can obtain a certification to show that it follows a quality standard. In many cases, this is an ISO 9001 certification, which proves that the organization has a quality system as described in ISO 9001 and that it is following it. The certification is issued by a ‘certification body,’ which has been accredited to do so by a national ‘accreditation body,’ such as the UK Accreditation Service (UKAS), Swedish Accreditation (Swedac),

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


The ASTM

13

and Norwegian Accreditation (Norsk Akkreditering), to mention a few. Most countries have one accreditation body and several certification bodies. The ISO standards are named using the format ISO [standard number]:[approval year]. The newest version must always be used, but the certifications/accreditations may relate to an older version. However, the company must update to the newest version before the next certification/accreditation inspection. The most commonly used ISO standards are the following: r ISO 9000 [42] r ISO 9001 [43] for certification r ISO 9004 [44] r ISO 14001 [45] ISO 9000 describes requirements for a quality management system in a quality-managed organization. ISO 9001 describes how to develop, manufacture, and test products, and covers relations between customers and suppliers. ISO 9001 is a certifiable standard. This means that a company that chooses to comply with the standard can get a certification body to assess its compliance and issue a certificate to prove that it is following the standard. ISO 9001 is useful for developing and manufacturing tangible things, but more difficult to use for intangible items such as software programs. ISO 90003 [46] is a guideline to ISO 9001 that explains how software can be developed according to ISO 9001. When IT suppliers want a certification for their system development, they will apply for an ‘ISO 9001 under the TickIT scheme.’ This basically uses ISO 90003 as a standard for the development of the system. ISO 9004 offers guidance for the continuous improvement of a quality system. ISO 14001 ‘specifies requirements for an environmental management system to enable an organization to develop and implement a policy and objectives which take into account legal requirements and other requirements to which the organization subscribes, and information about significant environmental aspects,’ to quote the scope of the standard. It is closely linked to ISO 9001, to make it possible to create one quality system that covers both the environmental aspects and the quality-business aspects. ISO 14971:2007 covers risk assessment for medical devices [47]. Accreditation is more than a certification, as the standards for accreditation also require competence in the process. One of the accreditation standards is the Laboratory accreditation standard ISO 17025 [48].

1.16

The ASTM

The American Society for Testing Materials (ASTM; see www.astm.org) is a standards organization that was started more than 100 years ago. Members volunteer to take part in creating, assessing, and maintaining standards within their field of expertise. Each standard is approved by member consensus and therefore reflects the current thinking in the industry. The ASTM has several standards for laboratories and healthcare providers and producers, as well as for numerous other industries, including safety of toys and carousels, and quality and standards for steel alloys.

P1: OTE c01

JWBK188-Segalstad

14

October 1, 2008

11:11


Quality Standards

The most interesting standards in this context are those of Section 14 – General Methods and Instrumentation, which cover Healthcare Informatics, Computerized Systems, Chemical and Material Information, Forensic Sciences, Chromatography, and Laboratory Apparatus, just to mention a few. The Laboratory Information Management System (LIMS) standard E 1578 [49] covers, among other things, terminology, the concept model, functions and workflow, database technology and structures, hardware platforms, and the life cycle. While this standard contains a lot of valuable information, there are also chapters that are rather outdated, given the nearly 15 years since it was first created. The functions defined as advanced in the document are standard features in almost every LIMS today.

1.17

The IEEE

The Institute for Electrical and Electronics Engineers (IEEE; see www.ieee.org) is another standards organization. The IEEE has many very good standards for software development and testing, among which are standards for: r software verification and Validation Plans [50] r software design descriptions [51] r software reviews [52]

1.18 1.18.1

Tasks Retrieve Standards

Retrieve the following standards from the US FDA web page (www.fda.gov): r r r r r r

21 CFR Part 210 21 CFR Part 211 21 CFR Part 820 21 CFR Part 58 21 CFR Part 11 with guidance document GCP Retrieve the following standards from www.pharmacos.eudra.org:

r r r r

EU GMP EU GLP EU GCP EU GMP Annex 11 Retrieve the following standards from www.picscheme.org:

r PI-011-03 (or current version)

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


References

15

1.18.2 What do the Standards Say about IT Systems? r Read through the various US GxP standards and see what these say about IT systems. Don’t include 21 CFR Part 11 in this research r Read through the various EU GxP standards and see what these say about IT systems. Don’t include GMP Annex 11 or PI-011-03 in this research

1.18.3

A Comparison between the EU GMP and the US GMP 211

Compare the EU GMP and the US GMP and note similarities and differences.

1.18.4

What Must be Included in the QMS?

A QMS should cover all parts of the organization that will have an impact on the product quality. Discuss whether the following items have an impact on product quality and therefore should be included in the QMS: r r r r r r

the process of employing new personnel the training and training records for the personnel equipment calibration equipment use internal environmental issues – for example, temperature and humidity in the offices internal environmental issues – for example, air pressure, temperature and humidity in sterile facilities r safety issues – for example, how to handle chemicals r personnel issues – for example, assessment of employees or salaries r purchasing and invoicing

References 1. ISO 8402-1989 (1989) Quality Terminology, International Organization for Standardization, Geneva, Switzerland (this standard has been withdrawn). 2. The Concise Oxford Dictionary of Current English (1988) 7th edn, Clarendon Press, Oxford, ISBN 0-19-861131-5. 3. Crosby, P.B. (2000) Quality is Free, Mentor, New York. 4. ICH (2006) Q9 Quality Risk Management, ICH, www.ich.org. 5. US FDA (2005) 21 CFR Part 210 Current Good Manufacturing Practice in Manufacturing, Processing, Packing, or Holding of Drugs; General, US Food and Drug Administration, Rockville, MD, www.fda.gov. 6. UD FDA (2005) 21 CFR Part 211 Current Good Manufacturing Practice for Finished Pharmaceuticals, US Food and Drug Administration, Rockville, MD, www.fda.gov. 7. ICH (2000) Q7 Guidance to Industry GMP for Active Pharmaceutical Ingredients, ICH, Geneva, Switzerland, www.ich.org. 8. US FDA (2004) Draft Guidance for Industry Quality Systems Approach to Pharmaceutical Current Good Manufacturing Practice Regulations, US Food and Drug Administration, Rockville, MD, www.fda.gov.

P1: OTE c01

JWBK188-Segalstad

16

October 1, 2008

11:11


Quality Standards

9. ASTM E2500-07 (2007) Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment, www.astm.org. 10. European Union (1998) Good Manufacturing Practices – Medicinal Products for Human and Veterinary Use, Vol. 4, pp. 153 (incl. Annex 11 covering computerized systems). 11. US FDA (2005) 21 CFR Part 58 Good Laboratory Practice for Non-Clinical Laboratory Studies, US Food and Drug Administration, Rockville, MD, www.fda.gov. 12. European Union (1988) Council Directive of 7 June 1988 on the Inspection and Verification of Good Laboratory Practice (GLP) (88/320/EEC). 13. European Union (1986) Council Directive – of 24 November 1986 – 86/609/EEC – on the approximation of laws, regulations and administrative provisions of the Member States regarding the protection of animals used for experimental and other scientific purposes. 14. US FDA (2006) 21 CFR Part 50 Human Subject Protection (Informed Consent), US Food and Drug Administration, Rockville, MD, www.fda.gov. 15. US FDA (2006) 21 CFR Part 54 Financial Disclosure by Clinical Investigators, US Food and Drug Administration, Rockville, MD, www.fda.gov. 16. US FDA (2006) 21 CFR Part 56 Institutional Review Boards, US Food and Drug Administration, Rockville, MD, www.fda.gov. 17. US FDA (2006) 21 CFR Part 312 Investigational New Drug Application, US Food and Drug Administration, Rockville, MD, www.fda.gov. 18. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 19. European Union (EU) (2001) Directive 2001/20/EC relating to the implementation of good clinical practice in the conduct of clinical trials on medicinal products for human use. 20. European Union (2001) Directive 2001/20/EC of 4 April 2001 on the approximation of the laws, regulations and administrative provisions of the Member States relating to the implementation of good clinical practice in the conduct of clinical trials. 21. European Union (1993) Council Directive 93/42/EEC of 14 June 1993 concerning medical devices. 22. US FDA (2006) 21 CFR Part 860 Medical Device Classification Procedures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 23. US FDA (2005) 21 CFR Part 820 Medical Devices Quality Systems Regulations, US Food and Drug Administration, Rockville, MD, www.fda.gov. 24. European Union (1990) Council Directive 90/385/EEC of 20 June 1990 on the approximation of the laws of the Member States relating to active implantable medical devices. 25. US FDA (1999) Guidance for Industry Computerized Systems Used in Clinical Trials, US Food and Drug Administration, Rockville, MD, www.fda.gov. 26. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org. 27. OECD (1995) OECD Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 10 GLP Consensus Document, The Application of Principles of GLP to Computerized Systems. Environmental Monograph No. 116, OECD, Paris, www.oecd.org. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based 28. GAMP Approach to Compliant GxP Computerized Systems, 5th edn (February 2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. R Good Practice Guide: A Risk-Based Approach to Compliant Electronic Records and 29. GAMP Signatures, 1st edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. R Good Practice Guide: Validation of Laboratory Computerized Systems, 1st edn (2005), 30. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-39-7, www.ispe.org.

P1: OTE c01

JWBK188-Segalstad

October 1, 2008

11:11


References

17

R Good Practice Guide: Testing of GxP Systems, 1st edn (2005), International Society 31. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. R Good Practice Guide: Global Information Systems Control and Compliance, 1st 32. GAMP edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-43-5, www.ispe.org. R Good Practice Guide: Calibration Management, 1st edn (2001), International Society 33. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, US version ISBN 1-931879-25-7, German version ISBN 1-931879-26-5, www.ispe.org. R Good Practice Guide: IT Infrastructure Control and Compliance, 1st edn (2005), 34. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-42-7, www.ispe.org. R Good Practice Guide: Validation of Process Control Systems, 1st edn (2003), Interna35. GAMP tional Society for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org. R Good Practice Guide: Electronic Data Archiving, 1st edn (2007), International Society 36. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org. R Special Interest Group (2005) Use of building management systems and environ37. GAMP mental monitoring systems in regulated environments, in Pharmaceutical Engineering, 25, 28–78. 38. US EPA (1995) 2195 Good Automated Laboratory Practice (GALP), US Environmental Protection Agency, Washington, DC, www.epa.gov. 39. Weinberg, S. (1994) GALP Regulatory Handbook, CRC Press, Boca Raton, FL, ISBN 1-56670025-6. 40. European Union (2006) Directive 2006/121/EC of the European Parliament and of the Council of 18 December 2006 amending Council Directive 67/548/EEC on the approximation of laws, regulations and administrative provisions relating to the classification, packaging and labelling of dangerous substances in order to adapt it to Regulation (EC) No 1907/2006 concerning the Registration, Evaluation, Authorisation and Restriction of Chemicals (REACH) and establishing a European Chemicals Agency. 41. ISO 17799:2005 (2005) Information Technology – Security Techniques – Code of Practice for Information Security Management, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 42. ISO 9000:2005 (2005) Quality Management Systems – Fundamentals and Vocabulary, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 43. ISO 9001:2000 (2000) Quality Management Systems – Requirements, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 44. ISO 9004:2000 (2000) Quality Management Systems – Guidelines for Performance Improvements, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 45. ISO 14001:2004 (2004) Environmental Management Systems – Requirements with Guidance for Use, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 46. IS ISO 90003:2004 (2004) Software Engineering – Guidelines for the Application of ISO 9001:2000 to Computer Software (formerly ISO 9000-3), International Organization for Standardization, Geneva, Switzerland, www.iso.org. 47. ISO 14971:2007 (2007) Medical Devices – Application of Risk Management to Medical Devices, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 48. ISO/IEC 17025:2005 (2005) General Requirements for the Competence of Testing and Calibration Laboratories, 2nd edn, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 49. ASTM E1578-93 (1999) (reapproved 1999) Standard Guide for Laboratory Information Management Systems (LIMS), American Society for Testing and Materials, West Conshohocken, PA, www.astm.org.

P1: OTE c01

JWBK188-Segalstad

18

October 1, 2008

11:11


Quality Standards

50. IEEE 1012-2004 (2004) IEEE Standard for Software Verification and Validation, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 51. IEEE 1016-1998 (1998) IEEE Recommended Practice for Software Design Descriptions, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 52. IEEE 1028-1997 (1997) IEEE Standard for Software Reviews, Institute of Electrical and Electronics Engineers, New York, www.ieee.org.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


2 Regulatory Requirements for IT Systems

This chapter discusses the following: r 21 CFR Part 11 – the US FDA regulation for IT systems r EU GMP Part 11 – the EU regulations for IT systems in the GMP area r The Pharmaceutical Inspection Cooperation Scheme (PIC/S) Document PI 011 – the equivalent to 21 CFR Part 11 r A selection of the requirements for each of the above, with an explanation of what the requirement means and how to comply with it

2.1

Introduction

Computer systems used for generating or storing regulatory data, including raw data, calculated data, or other data, are regarded as regulatory systems if they are used instead of manual systems in the regulated industries. Such systems have to be treated as explained in the regulations; the transfer of data between these systems must be validated as well. Computer systems used as additions to a complete manual or to another regulatory computer system are not regarded as regulatory systems and do not need to be treated as such. Examples of nonregulatory computer systems are those used for: collecting and querying information across manual files or computer files; giving better and more accessible overviews; keeping track of resources such as personnel, equipment, and the workload; and word processing. Accounting systems are also regarded as nonregulatory systems for the pharmaceutical industry, but may have to comply with additional regulatory rules from a business or economic perspective. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c02

JWBK188-Segalstad

20

2.2

September 30, 2008

9:53


Regulatory Requirements for IT Systems

US Requirements

Before 1997, there were mainly the FDA’s ‘Blue book’ [1], named for its cover color, and the DIA’s ‘Red Apple book’ [2], which described how to handle IT systems in the US pharmaceutical regulations. While requirements for validation of computer systems were first introduced in these books, the FDA did not do much to publish formal requirements. Several FDA employees wrote publications about the FDA’s views [3, 4] and the FDA started to enforce the requirements that it had not formally stated. The requirements in the GxPs are used as the basis for the inspection of the IT systems. The GxPs are called the ‘predicate rules,’ as these give the basic requirements. If the GxP dictates control over a process, then the IT system controlling that process also needs to be under control. Inspectors issue discrepancy reports based on the text in the relevant predicate rule, and maybe, additionally, state that the GxP or IT system isn’t in compliance with 21 CFR Part 11. It is important to understand that this document does not replace any other requirements for computer systems; it is an addition and a clarification to other regulations such as the GxPs. Even if the document does cover electronic records and electronic signatures, there are few suggestions for how to get in compliance. 21 CFR Part 11 is nicknamed ‘Part 11.’ People who have worked with IT systems in the pharmaceutical industry in the roles of key personnel, validation experts, Quality Assurance, and so on know a lot about 21 CFR Part 11 already. Numerous publications [5], and also books [6, 7], have been written about the requirements and how to comply with Part 11; however, the interpretations of the requirements vary quite a bit. The FDA also added to the confusion by first issuing a number of draft guidance documents making the regulations more and more strict, and then suddenly withdrawing them all in 2003, and replacing them with one new guidance document for a risk-based approach to 21 CFR Part 11 [8]. This document leaves it up to the discretion of each organization to assess the importance of its computer systems, and to handle the high-risk systems carefully and the lower-risk systems a bit more leniently. The risk assessment itself must be documented. The document from the FDA covers risk assessment, but does not even mention risk management – how to handle the risks. The actual requirements in 21 CFR Part 11 cover only about two pages of the 45page document. The rest is a preamble, which discusses the reasons behind the rule in greater detail. While it certainly was tedious to read through all this text, it was useful to understanding the requirements, especially before people knew how the FDA would interpret Part 11. Now it is possible to check with the FDA web page (www.fda.gov) and find the current interpretation in the warning letters. A lot of the preamble consists of comments from people and companies made before the document was finalized, and some of the comments are contradictory. The preamble should not be used as a guide to what needs to be done, but the comments should be taken into consideration. While the interpretation of Part 11 was extremely strict as to which systems had to be compliant, the new guideline added the ‘risk-based approach’ as a new dimension. If risk assessment shows that a system does not represent a high risk for the data, less validation and less stringent requirements apply. There may be discussion about whether adding the risk assessment reduces the total amount of work, but at least each company has the possibility of reducing some of the validation activities and some of the technical requirements stated in Part 11.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


21 CFR Part 11

21

As with all compliance issues, it is important that each company documents what it is doing and why it is doing it, as well as why it thinks that this is the correct thing to do. Applying common sense never hurt anybody. Also, copying what another company is doing may turn out wrongly if this conflicts with other procedures in your own company. The document has three types of requirements for IT systems: built-in functionality, procedural requirements, and validation. It has two main sections: one on electronic records and one on electronic signatures. There is no requirement for using either, but if IT systems are used, they need to be in compliance with the electronic records requirements; and if electronic signatures are used, they must also comply with the requirements. 21 CFR Part 11 is not to be read instead of the GxPs, but in addition to them. One example is the chapter on electronic signatures, which does not say anything about where or when signatures are needed. The user must find this in the applicable GxP. Then, if the computer system in question is to be used for e-signatures, the Part 11 requirements apply. Another example is that Part 11 does not state that the user must give a reason for data changes in the system. This is covered well in the GxPs. 21 CFR Part 11, with its current guidelines for a risk-based approach, forms the basis for how to handle IT systems in the FDA-regulated industry. However, this isn’t really all there is: Laws are one thing, and current interpretation is another. The best way to keep updated on what the US inspectors think of as current good practice is to check the FDA web site and read the warning letters issued to companies that do not comply with the regulations. Because of the Freedom of Information Act, all warning letters are available to the public through this web site or may be requested directly from the FDA. Several of the warning letters cover IT systems. These spell out in detail what inspectors had expected to find, but did not, during their audit. Thus, the current interpretation can be found under ‘warning letters’ on the FDA web page.

2.3

EU Requirements

The EU requirements to be discussed here are the EU GMP Annex 11 [9] and PIC/S PI 011-03 [10]. As the EU does not have the same requirements for freedom of information as the United States, there is no web page where the equivalent to the FDA’s warning letters can be found. It is therefore more difficult to know what the current interpretation is. On the other hand, the PI 011 is much more detailed than Part 11, making interpretation less necessary. It is relatively safe to say that the European standards can be used while also looking into the US interpretation.

2.4

21 CFR Part 11

21 CFR Part 11 has three types of requirements: r Technical requirements; that is, functionality that must be built into the system by the supplier r Procedural requirements; that is, procedures that the organizations must have in their quality systems

P1: OTE c02

JWBK188-Segalstad

22

September 30, 2008

9:53



r Validation requirements, only stated in Section 11.10(a). All functions stated in the User Requirements Specification (URS) must be validated, as must all the technical requirements in Part 11 itself. Ideally, these should be a part of the URS This following section describes what each requirement of 21 CFR Part 11 means and how to comply with each requirement. 2.4.1

Electronic Records

The 21 CFR Part 11 defines the closed system: Closed system means an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system.

Electronic records in closed systems, as described in the 21 CFR Part 11, have several requirements in place to ensure the authenticity and integrity of data. Please refer to the document for the full text of the requirements. §11.10(a) Validate the system Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

Validation includes all stages of the system, from the first planning of the system requirements to retirement of the system. In addition to validating the system functions, based on the User Requirements Specification, all technical Part 11 requirements must also be validated. Validation is described in Chapters 11–16. §11.10(b) Records The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records.

Human-readable records can be created in two ways: 1. The nicest looking ones are made using a report generator, where a good layout makes the report easier to read. The valid regulatory report will have to be validated/qualified as well, and this is, of course, described in the company’s SOPs. The trained user can quickly make reports using a good reporting tool to make ad hoc reports in a humanreadable format. However, until they are qualified these must be used with care, as they may not show the correct data. 2. Screen dumps may be an alternative, but these are generally based on the data for only one item (sample, analysis, sequence, etc.). Electronic records may only be readable while the system is live and in working order, but the data will probably still be needed when the system is no longer available. There are several options available: r It is clear that the investigators want the ability to make electronic copies. This could be a flat file (see next bullet point) or a .pdf file. The FDA themselves are heavy users of .pdf files

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


21 CFR Part 11

23

r Another solution may be to generate a flat file from a database table; the flatter the better – that is, with as little structure as possible. The flat file uses a semicolon or another character as a separator to generate the division between the sets of data. If the flat file is in ASCII format, it should be a useable and readable format at least for a while into the future. However, we also thought that way about the punch cards used 30 years ago, and now punch card readers are virtually unavailable, even though the cards themselves are still technically readable r XML is also a solution, and this is probably the most elegant way of functionality imitating the system. Hopefully this will stay as a standard for a while §11.10(c) Records protection Protection of records to enable their accurate and ready retrieval throughout the records retention period.

Data security isn’t an easy issue. It must be described, tested, and documented: r Perform backups on a regular basis, and test the retrieval of the backup to make sure that the data is retrievable if needed r Ensure that it is impossible for anyone to write, amend, edit, or delete records in the operating system, the database, or any of the program files belonging to the system through the ‘back door.’ (See also comments on audit trail.) r Define the retention period for records, and take all precautions to protect records against loss. Perform periodical tests to guarantee the ready retrieval of the records r Move the data into the new system to replace the old, if necessary. This is a tedious process, and heavy validation will be needed to make sure that the data is still correct The ‘back door’ is, for example, through the operating system, the database (if applicable), or through any of the program files. The operating system must not allow users any access to the files; access meaning writing, executing, or deleting. The database and the system’s program files must be likewise protected. Other external aspects of data security, such as virus protection, are described in Chapter 3. §11.10(d) System access Limiting system access to authorized individuals.

No system should ever be set up with generic accounts for several users, such as ‘lab technician,’ ‘lab manager,’ and so on. Each user needs to have his or her own user account, which uniquely identifies the person as a user in the system. Whether the full name or an abbreviated ID is used as the account name doesn’t matter. However, you must know how to deal with users who happen to have the same name, as they will need to have different user IDs in the system. The system needs to have private user accounts for each user. Protect access to the accounts by using passwords or other means of protection to ensure that only the authorized users have access to the system: r User accounts must never be used by more than one person r The accounts must be protected by passwords or other types of protection; for example, biometric devices or identity card swipes

P1: OTE c02

JWBK188-Segalstad

24

September 30, 2008

9:53


Regulatory Requirements for IT Systems §11.10(e) Audit trail Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

An audit trail is a secure, computer-generated record. Ensure that the system has this built in as an automatic function. It contains a set of information, which includes the following: r Who did it (user stamp)? r When it was done (time stamp, including date and time)? r Why the change was made. The reason for the modification isn’t mentioned in 21 CFR Part 11. This is, however, mandatory in applicable predicate regulations for the change of existing data r Old data must never overwritten or physically deleted. They must, instead, be given a tag with an old version number, or a status indicating that this is old data and that newer data exists §11.10(f) Operational checks Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.

This part is only mandatory if sequencing is necessary for the task to be done, as defined in the company’s SOPs or in the system’s functionality; for example, it’s necessary to log samples before results are entered. §11.10(g) Authority checks Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.

Closed systems have access control, where all users of the system have their own user IDs and passwords, or an alternative secret part of a two-component access. People not defined as users in the system must be refused access. Additionally, access to commands and data must be limited to the user’s level of authority. Ensure that there are procedures in place to limit system access to authorized users only. §11.10(h) Device checks Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.

For security reasons, it may be necessary to check which device has been used, especially if only a few are legitimate sources of input. The device check typically interrogates the source of input to ensure that only an authorized device is used.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


21 CFR Part 11

25

§11.10(i) Training Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.

Create an SOP to cover user training and training records. Information is included in Chapter 5, and must explain how users will be given training and access: r As a general rule, users shall not be given access before they have been properly trained. Training shall preferably be done on a separate training system r Training records must show that the following have received sufficient training: – the users of the system – the IT department that maintains the system – the developers of the system (can be checked during a supplier audit) §11.10(j) Procedures for personal responsibilities The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.

Users must understand that they are liable for signing in the system. This can be done by: r Creating a written policy, and having each person read and sign that they are aware of this policy r Ensuring that the system’s security features do show who made which changes at which time, so that users can’t say, ‘I didn’t do it’ or ‘someone else changed it after I did it’ §11.10(k) System documentation Use of appropriate controls over systems documentation including: 1. Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance. 2. Revision and change control procedures to maintain an audit trail that documents timesequenced development and modification of systems documentation.

Controlled documents have always been a part of system validation. What is new are the clearly stated requirements about time-sequenced development and modifications to the system documentation. This would also apply to validation documentation and tasks: Plans shall be written, approved, and authorized before testing is carried out; testing shall be done before reports are written; and reports shall be written, approved, and authorized before the system can be taken into use. For details of the various validation documents needed, please see Chapters 11–16. The 21 CFR Part 11 defines the open system: Open system means an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system. §11:30 Open systems Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to

P1: OTE c02

JWBK188-Segalstad

26

September 30, 2008

9:53


Regulatory Requirements for IT Systems the point of their receipt. Such procedures and controls shall include those identified in § 11.10, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality.

The requirements for open systems include all of the closed systems requirements, plus additional requirements, such as the following: r document encryption r additional digital signature standards to ensure record authenticity, integrity, and confidentiality The easiest and probably the best way to comply with the requirements for open systems is not to have open systems at all; instead, set up all systems as closed systems. If a system can’t be closed, make sure that the access is encrypted, using the best possible encryption methods. The tools used for complying with the requirements need to be thoroughly validated. §11.50 Signature manifestation (a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following: 1. The printed name of the signer; 2. The date and time when the signature was executed; and 3. The meaning (such as review, approval, responsibility, or authorship) associated with the signature. (b) The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout).

When users utilize electronic signatures, both their identity and what they do must be clear. The requirement for the ‘printed name of the signer’ implies that the full name must be seen on the screen. There may be several people in a company with the same name, and they must have separate login names/IDs. When defining the users in the system, you should include information on both the ID and the full name. If you do that, you are in compliance. If users are identified only with their ID in the system, you may state somewhere that the ID is unique and that this is regarded as the ‘full name.’ §11.70 Link between electronic records and electronic signatures Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.

Linking electronic records and handwritten signatures in a foolproof way is probably the most difficult requirement in Part 11. For example: You have done all your analyses, and printed out a Certificate of Analysis (CoA). Then you realize that something has gone wrong somewhere, and you do a reanalysis. How do you ensure that the CoA is updated? The easiest way is to use electronic signatures in the system, provided that the system is capable of doing this in a compliant way. If not, create procedures to ensure that the paperwork with the signatures is updated whenever the data is updated.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


21 CFR Part 11

2.4.2

27

Electronic Signatures

§11.100(a) Electronic signatures Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.

Never, ever reuse a user ID in the company! Often, it is the Human Resources (HR) department that issues user IDs to new employees. This means that the HR department also has to be in compliance, which it isn’t used to, and training is needed. You need procedures in place to make sure that the issuing of IDs is handled correctly. §11.100(b) Electronic signatures Before an organization establishes, assigns, certifies, or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual.

The identity of the individual employee must be securely established. How this is done varies from country to country. In Norway and Denmark, each person has an individual ‘Person number,’ consisting of the birth date and a five- or four-digit number, respectively. These numbers can be found on driver’s licenses and on tax papers. No one can get paid until the tax papers have been issued. It is difficult to falsify these numbers, and companies have decided that the use of these numbers is sufficient as proof of identification. In the United States, Social Security numbers, consisting of nine digits, are relatively easy to obtain by giving the name and providing the birth certificate for someone who may even be dead. Social security numbers may not be regarded as safe for establishing identity, but each organization must decide for itself what proof of identity is sufficient. §11.100(c) Electronic signatures Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. 1. The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the Office of Regional Operations (HFC-100), 5600 Fishers Lane, Rockville, MD 20857. 2. Persons using electronic signatures shall, upon agency request, provide additional certification or testimony that a specific electronic signature is the legally binding equivalent of the signer’s handwritten signature.

Electronic signatures are still optional. If the company wants to use them, the company has to send a letter to the FDA that explains that the company understands that it is equally liable for electronic signatures as it is for handwritten signatures. An example of such a text is [11] the following: ‘This is to certify that (my company) intends to use electronic signatures and understands that all electronic signatures executed by our employees, agents, or representatives, located anywhere in the world, are the legally binding equivalent of traditional handwritten signatures.’ It may be wise to ask all employees using electronic signatures to sign a document to the effect that they understand that electronic signatures are legally binding and have the same meaning as their handwritten signature – see 11.10(j). Send one letter to the FDA; you don’t need to send a letter for each of the computer systems where you use electronic signatures. The letter covers all your systems. You can

P1: OTE c02

JWBK188-Segalstad

28

September 30, 2008

9:53



decide later which systems you want to use electronic signatures in, usually based on the system’s functionality for e-signatures. §11.200(a) Requirements for a non-biometric signature electronic signature (a) Electronic signatures that are not based upon biometrics shall: 1. Employ at least two distinct identification components such as an identification code and password. (i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. (ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.

An electronic signature must be made so that it is only the genuine owner who can use it. An electronic signature comprises of two distinct and independent components. The first one is usually the login ID/name of the user. This is generally not a secret within the company. The second one, usually a password, should be a secret that only the particular user knows. In many systems, the system/application manager sets the password, but there should be an automatic feature that requires the users to set their new and secret password the first time they log in. There should be no need to mention that passwords should never be written down and left for someone else to find. Create unique user IDs and require each user to change the preset password immediately to a secret password. Several password systems require this to be a complex code, and not a word that you can find in a dictionary. The users must log in with both ID and password before they are given access to the system. When signing, they must do the act of signing and then enter the secret part (the password) afterwards. In this way, it isn’t possible for an unauthorized individual to sign for something just because the user already logged in has left the computer unlocked. §10.200 Biometric signatures (b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.

Biometric signatures use a unique feature of the users to verify that they are who they say they are. There is a difference between really identifying the user and verifying that the user is who he claims to be by comparing the feature with the information that is stored for this user. When a system identifies a user, it finds the identity in a database based on the input from an unknown person. When the system verifies the identity, it checks that the input belongs to the already identified user. Biometric identification may consist of one or more of the following: r r r r

fingerprint scans retina scans hand measurements other measurements

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


21 CFR Part 11

29

Biometric identification isn’t used very much in the industry as yet. You can use keyboards with fingerprint scanners; they exist, and the price is reasonable. Other equipment is relatively expensive. Validation of biometric identification/verification is tedious. This is described in more detail in Chapter 17. §11.300 Controls for identification codes and passwords, § 11.300(a) Unique identification code Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include: (a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.

The uniqueness of the ‘combined identification code and password’ must be in the user identification, not in the password. To have the system check if a password is unique defies the purpose of uniqueness. Just imagine that you have five users on the system, one of whom is told that he or she can’t use a certain password because it is already in use. How hard would it be to check who has this password by trying to log in as the other user? Create unique IDs that are never reused. Have a system to make sure that passwords are complex; for example, upper/lower case, at least x digits whereof at least y differ from a letter. Train people to understand how they should create passwords. §11.300(b) Maintain ID and passwords Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).

Every company must ensure that only the intended people have access to the premises or the computer systems. Passwords should automatically age after a certain period of time. Too long a period might compromise the secrecy of the password, while too short a period might make it difficult for the users to remember all of their passwords. A common compromise is three months. Whenever people stop working for the company, their access to premises and computer systems must immediately be barred. This is a matter of procedure. Quite often, the HR department is in charge of dismissals and other personnel changes, and it needs to inform everyone else of who has stopped working for the company. §11.300(c) Loss management (c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.

Devices may be used instead of passwords, but these are not very common, as it is too easy to lose them, mislay them, or steal them. If you do use such devices, create procedures in order to comply with this requirement.

P1: OTE c02

JWBK188-Segalstad

30

September 30, 2008

9:53


Regulatory Requirements for IT Systems §11.300(d) Unauthorized access and use Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.

There is a combination of built-in functionality in the system and procedures. The functionality must include the following: r refusing access to individuals who try to get into the system with wrong IDs or passwords r sending a message to ‘someone’ that a user is trying to get in r preferably also creating a log for people who try to gain access without permission The ‘someone’ must have a procedure that explains what to do when such a message is received. Make sure that the functionality is included in the URS for the system and built into the system (and switched on, as in several systems this feature is optional), and make a procedure that covers what needs to be done if someone tries to hack into the system. §11.300(e) Devices Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.

Devices, if used, need to be validated and periodically tested in the best possible manner. For more information on validation, see Chapter 14.

2.5

The ‘Part 11 Project’

There are still companies that have not assessed their IT systems for Part 11 compliance, even though most companies have done so. If systems have not been assessed and handled according to the requirements in 21 CFR Part 11, this needs to be done. The FDA does look into computerized systems during their inspections, and companies with systems that are not in compliance will certainly receive a ‘483,’ which is the number of the form filled in to show inspection findings. 2.5.1

Open or Closed?

First, assess whether the system is open or closed. This is a matter of access and security. Data security is important, and it makes ‘life’ easier if the system can be defined as a closed system: r The system is closed if the system owner has authorized access for each user and no one else can access it r The system is open if there is any possibility whatsoever for unauthorized users to access it. This could include users accessing the system via the Internet, via modems without extra access control, or via the ‘back door’ in the system

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


The ‘Part 11 Project’

31

If you face deficiencies such as any of the points listed below, you will need a plan to solve the defects: r r r r

The system has only one user account, but more than one user The user accounts have no passwords or other secure protection Anyone can gain access through the ‘back door’ of the system The audit trail isn’t available for all parts of the system. This includes the setup of static data such as analyses, specifications, sequences, or whatever the system needs, as well as the dynamic data; that is, values measured during testing and subsequent calculated and otherwise manipulated data r The system managers have too much access. Having one system account with two passwords, so that two different people will need to use their passwords at the same time to gain access, can protect the system access to the system account. However, that may create more practical problems than it solves 2.5.2

Is the System an Electronic Records System?

Computer systems are obviously systems with electronic records. But there are some, such as the word processor, that may or may not be, depending on how they are used: r Not an electronic records system: The company has SOPs that are printed out, signed, and copied to all users. The files are on the server, but the current SOP is always the copy of the signed SOP. Technically, the files are electronic. But it has no relevance whether the next version of the SOP is edited from the file, or created by a typewriter for that matter, as long as the valid version of the document is the paper one r Electronic records system: The company has SOPs that are printed out, signed, and the original is stored in an archive. The files are on the server, and the user of an SOP prints it from the server the same day the SOP will be used. In this case, the file is actively used as the current SOP 2.5.3

What if the System Is Not in Compliance?

Using the checklists based on the 21 CFR Part 11 requirements will show whether the system in question is in compliance with the requirements for electronic records or electronic signatures. The problems start when it is found not to be in compliance. A major concern is that many corporations have replaced secure operating systems such as VMS with Windows. Older versions of Windows are definitely not in compliance on the security and access side. Newer versions of Windows are better, but they still have a lot of deficiencies compared to VMS. Restricting user access to certain directories does help, but the system administrators still have access to files to which they should not have access. Word processors, spreadsheets, and most databases have no audit trail. They are not in compliance, and this should be addressed and resolved quickly. 2.5.4

What Options Exist?

After ruling that the system isn’t in compliance, a written plan for solving the problems must be drawn up. This will prove that the company is taking the problems seriously, and

P1: OTE c02

JWBK188-Segalstad

32

September 30, 2008

9:53



may well be accepted as a preliminary solution until a real solution is in place. Assess the risk of noncompliance, based on the computer system’s impact on product quality: r Replace the system: The most correct solution is to replace the system with one that is in compliance. If this means a new project, it is generally costly, and it takes time. The project includes User Requirements Specifications, supplier selection, implementation, and validation activities before the system can be taken into use. It also leaves the problem of what to do with old data r Add a system on top: The application of a document management system can solve the problem with the word processor and spreadsheet files. A document management system adds an audit trail, and the version control is good. With this in place, there is no doubt that the document is the current version, and not one that has been tampered with r Move the tasks to another system: Spreadsheets are used in many laboratories to do the calculations. The calculations in the spreadsheet may have been validated and the formula cells closed, but the spreadsheet still has no audit trail. However, if the spreadsheet isn’t saved, it isn’t an electronic record, and it’s equivalent to using a calculator. But it makes for less work, and produces more accurate and better-secured data, to let other systems do the calculations, if that is possible. A Laboratory Information Management System (LIMS) or a production management system (MRP/ERP) may be used to do the calculations, which eventually belong in that system. These systems are more likely to be in compliance with the electronic records requirements

2.6

EU GMP Annex 11

EU GMP Annex 11 was first created by PIC/S as Annex 5 to their GMP and then later adopted as the EU GMP Annex 11. EU GMP Annex 11, or just ‘Annex 11,’ is basically a list of things that must be in place for computerized systems used in the pharmaceutical industry. It can’t be used as a tool for what to do, as it includes no guidance and no details of what is expected. It can be used as a checklist for an organization to see if it complies, but only if the organization understands what is behind the words in the document. It also contains obvious and needless information such as ‘The software is a critical component of a computerized system.’ – What computer systems don’t include software in one way or another? The EU GMP Annex 11 gives a 19-section description of what is needed to keep a computer system in a validated state. Annex 11 has also been adopted for use for GLP and GCP purposes. This section presents those sections (as displayed quotations below), with details of how to interpret them for the pharmaceutical industry. Each section in the document is cited below, with an explanation of how IT systems may be handled to be in compliance. For years, people thought that the word ‘validation’ meant a one-time-occurring planned test. Now they have discovered that it is a word that covers the whole system’s life cycle, from the first planning phases of a new system through the retirement of the system. The definitions, however, are still the same, and vary according to where the word is defined.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


EU GMP Annex 11

33

This following section describes what each requirement EU GMP Annex 11 means and how to comply with each requirement. Principle The introduction of computerized systems into systems of manufacturing, including storage, distribution and Quality Control does not alter the need to observe the relevant principles given elsewhere in the Guide. Where a computerized system replaces a manual operation, there should be no resultant decrease in product quality or Quality Assurance. Consideration should be given to the risk of losing aspects of the previous system by reducing the involvement of operators.

Annex 11 also refers to the rest of the GMP. Computerized systems are regarded as equipment. Every time the expression ‘equipment’ is used in the GMP, this is also a requirement for the IT systems: ‘The use of IT equipment must not result in reduced knowledge and understanding of the process of the previous manual, mechanical, or electronic system that the equipment has replaced.’ This point is important, as it is too easy to reduce a manual operation to a command in a computer system. §1 Users It is essential that there is the closest co-operation between key personnel and those involved with computer systems. Persons in responsible positions should have the appropriate training for the management and use of systems within their field of responsibility which utilises computers. This should include ensuring that appropriate expertise is available and used to provide advice on aspects of design, validation, installation and operation of computerised systems.

The personnel using the computer systems must have adequate training for their level of use and responsibilities for the system. People responsible for the system must have in-depth knowledge of the system, but users must know what they need to know to use the system. Training can be differentiated accordingly. All training, and the extent of that training, must be documented in the personnel training records. People with responsibilities for validation and other aspects of the IT systems shall similarly have adequate training, and records must be kept to prove that the training has been completed. Each system must have an SOP describing training routines for the system. This SOP must include the extent of the training, who is responsible for giving the training, and how it is to be documented. It may be wise to include descriptions of how the application manager and users will know when training is needed, and what the extent of that training should be. This may be documented by using a standard form that the users’ team leaders have to fill in. The form should contain fields for user name, department, extent of access to the system, date, and signature. The document shall be filed in the system’s file. The leader is responsible for sending this form to the application manager, who is responsible for providing the training. A new form must be filled in whenever there is change of access for the user. The changes may or may not result in additional training. The training SOPs are covered in Chapter 5. The company should have SOPs that explain how computer systems must be taken care of in the company. The SOPs must contain the requirements for the content of the systemspecific SOPs. It is an advantage to have these SOPs high up in the organization, to cover as many departments as possible.

P1: OTE c02

JWBK188-Segalstad

34

September 30, 2008

9:53


Regulatory Requirements for IT Systems §2 Validation The extent of validation necessary will depend on a number of factors including the use to which the system is to be put, whether it is prospective or retrospective and whether or not novel elements are incorporated. Validation should be considered as part of the complete life cycle of a computer system. This cycle includes the stages of planning, specification, programming, testing, commissioning, documentation, operation, monitoring and changing.

The extent of the validation depends on how the system is used. If the organization does not use all the functions of the system, there is no need to validate all of the functions. Nevertheless, all functions that are in use must be validated. If functions are being put to use at a later stage, these need to be validated separately before use. A retrospective validation will normally be less comprehensive than a prospective validation. For both, you need to collect all system documentation, test documentation, logs, correspondence about the system, and so on. An old system usually has less documentation available from the early stages than a new one. The testing may be reduced or omitted if other documentation exists to show that the system has operated properly during its operational life. This could include comparison testing between an older system and the current system, and calibration or control data, among other documentation. Please remember that Annex 11 was written in the early 1990s and that validation has been a requirement for a long time. Today, there is hardly any excuse to have nonvalidated systems that will need retrospective validation. A prospective validation normally has more project-related documents. Validation is described in Chapters 11–16. §3 Siting of equipment Attention should be paid to the siting of equipment in suitable conditions where extraneous factors cannot interfere with the system.

Equipment that is subject to ‘extraneous factors,’ such as large variations in temperature or humidity or an unstable electrical voltage, does not function properly. Unauthorized people are also regarded as extraneous factors. You must always ensure that you locate equipment where it can’t be interfered or tampered with. Servers and mainframes should preferably be stored in air-conditioned rooms where the temperature and humidity are under control. Most equipment has operating conditions requirements, with stated temperature ranges. These should not be exceeded. Many places, even in larger cities, have occasional problems maintaining a stable voltage in their power supplies. Voltage stabilizers may be added for the equipment. Uninterrupted Power Supplies (UPS) are almost a must for servers. They will kick in whenever there is a problem with the power supply, and will make it possible to take the servers down in a controlled manner – if needed. The physical access to the system must be secured, so that only authorized personnel can enter the premises. Security should include both physical access and logical access. The logical access is normally restricted to system-defined persons who use an ID and a password, or preferably other more secure means of identification in order to gain access to the system. This has been described by Erin English [12]. Security is described in Chapter 4.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


EU GMP Annex 11

35

§4 Configuration management A written detailed description of the system should be produced (including diagrams as appropriate) and kept up to date. It should describe the principles, objectives, security measures and scope of the system and the main features of the way in which the computer is used and how it interacts with other systems and procedures.

The system’s configuration at any given time must be kept updated. Old versions must be kept in historic files. Configuration includes both hardware and software. This is described in Chapter 5. Everything used directly or indirectly for the system must be kept under configuration management. If the responsibilities for the various pieces lie with different people or different parts of the organization, a written description of the responsibilities must be created to ensure the configuration management update. It doesn’t matter if the configuration management files are kept by electronic means or in a paper-based system, as long as it is possible to retrieve the information later. Hardware includes mainframe/terminals, clients/servers, printers, and networked items, as well as A/D converters needed for a data-collection chromatography system, to mention a few. The software information must include name and version numbers for network software, operating systems, databases, and the system-specific software. Interactions between the computers must be described. This is especially important if data is moved between systems. A graphical view of the hardware gives an easy overview, as does a graphical view of the directories and the subdirectories for the system. §5 System development The software is a critical component of a computerized system. The user of such software should take all reasonable steps to ensure that it has been produced in accordance with a system of Quality Assurance.

The system life cycle includes all stages from the early planning to the retirement of the system. However, most often systems are bought ‘off the shelf’ and not programmed especially for the user. The quality of the system development must then be checked through a supplier audit. If the system is programmed especially for the user, the user can state his or her requirements before the start of the programming project and make sure that they are followed during the development stage. ‘All reasonable steps’ may imply that it is sufficient if the supplier has an ISO 9001 TickIT [13] or other type of certification, which will not be awarded unless the supplier has adequate Quality Assurance systems. However, until recently the FDA has not regarded a third-party certification or audit as sufficient; the users must perform the audit themselves. Some regulations and standards have absolute requirements for performing an audit, while others leave it to the user organization, based on a risk assessment. The risk-based approach makes it possible for the organization to decide whether or not to perform a supplier audit. Supplier audits are described in Chapter 10. §6 Correct entry of data The systems should include, where appropriate, built-in checks of the correct entry and processing of data.

P1: OTE c02

JWBK188-Segalstad

36

September 30, 2008

9:53



The question of what is ‘appropriate’ for the different types of systems may be discussed at great length. In many databases and other types of systems, it is possible to predefine lists or ranges of allowed entries. These are used for verifying each entry before committing it to the database, which is appropriate for certain types of entries such as pH values, colors, absorbance units for analytical systems, and adverse effects for clinical systems; but not for other types, such as batch numbers, patient data, and most numerically measured values. In some clinical data systems, double entry is possible, where two people enter the same data, which is subsequently compared. If it matches, it is assumed to be correct. Before buying systems off the shelf, you should check out the possibilities for checks and controls. Before contracting systems, you should also ensure that the Requirements Specification also covers which entries shall have checks and which entries shall not. Generally, there isn’t much you can do about this point unless it has been built into the system. When controls are missing, SOPs must describe the correct way of using the system. §7 IQ, OQ, validation Before a system using a computer is brought into use, it should be thoroughly tested and confirmed as being capable of achieving the desired results. If a manual system is being replaced, the two should be run in parallel for a time, as part of this testing and validation.

The general GMP states the need for Installation Qualification (IQ), Operational Qualification (OQ) and Process/Performance Qualification (PQ) for equipment. The installation must be done according to the procedure and then tested – and the testing documented. This will assure that the system has been installed correctly and that it works correctly. The OQ/PQ must be verified against the requirements and documented. If equipment – for example, instruments – is to be connected to a system, the same procedures for IQ and OQ can be used throughout; these will include testing to ensure that the piece of equipment is communicating with the system. During the testing, there is no need to test every instrument of the same type extensively. The first one needs thorough testing, while the next ones may only need IQ if they have all been installed the same way and function in the same way. The connection of new clients to a client–server system or new terminals to a mainframe has to follow the same procedures. Validation is covered in Chapters 11–16. §8 System access Data should only be entered or amended by persons authorized to do so. Suitable methods of deterring unauthorized entry of data include the use of keys, pass cards, personal codes and restricted access to computer terminals. There should be a defined procedure for the issue, cancellation, and alteration of authorization to enter and amend data, including the changing of personal passwords. Consideration should be given to system allowing for recording of attempts to access by unauthorized persons.

The system should have a means of identifying which people have access to it. A one-user system is insufficient if more than one person will be using it. It should be possible to configure a complex system such that named users can have different levels of access to it. Not every user should be allowed to do everything in the system. Computerized systems must have built-in secure tools for this purpose. Needed functionality not included in the system must be explained in the SOP. The SOP should also explain how to decide which users shall have what kind of access (see Section 1),

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


EU GMP Annex 11

37

electronically, physically, or legally. This is no different from a totally paper-based system, where many people have physical access to sign a sheet of paper, but only certain signatures are valid. This needs to be explained in an SOP or in that person’s job description. §9 Entry of critical data When critical data are being entered manually (for example the weight and batch number of an ingredient during dispensing), there should be an additional check on the accuracy of the record which is made. This check may be done by a second operator or by validated electronic means.

Statistics have shown that when a person enters values manually, the error rate is approximately 3%, while electronic systems have a rate an order of magnitude lower [14]. The manually entered values must be checked: the 3% error rate can be fatal. The manual entry can be checked by peer review, either while the work is carried out or at a later approval stage, if raw data is available. When electronic entry is used, the system and transfer of data have to be validated like any other computerized system used for regulatory purposes. For example: A balance that is transferring measured values to a system must be subject to IQ/OQ/PQ as described in Section 7, and it must be checked that the transferred values are identical to the values on the display. Additionally, there must be an SOP for the balance itself, which explains maintenance and calibration, and a log to show that this has been done as prescribed. §10 Audit trail The system should record the identity of operators entering or confirming critical data. Authority to amend entered data should be restricted to nominated persons. Any alteration to an entry of critical data should be authorized and recorded with the reason for the change. Consideration should be given to the system creating a complete record of all entries and amendments (an ‘audit trail’).

The automatic audit trail is dependent on having each user defined in the system. A good audit trail will ‘stamp’ each entry with the user ID and the date and time when the entry or change has taken place. The audit trail should also prompt for reasons for updating a value, preferably to be selected from a predefined list of common reasons (a system in which it is possible to leave the reason to be defined by the user will invariably get ‘Monday morning’ and ‘Friday evening,’ which are not regarded as very good excuses). Also, an updated value should not overwrite the existing one, but should amend the new one to the old one. Technically, this is often done by giving a new version number and new status to the values. When querying the values, the system will show the valid one plus information that older versions exist. Even a perfect audit trail is easily breached if the users do not log out of the system when they are done, and other users use the system without logging in separately. Very few systems or companies have included secure identification of their users, such as biometric recognition that identifies fingerprints, the retina, and so on, or mechanical identification that the user carries, such as ID cards or ID buttons to be read by the system. The state of the art in identification systems is described in journals such as the Automatic ID News [15]. The SOP should also include descriptions of the security measures, such as logging out immediately when done. Part of this requirement is differentiated user access, as explained in Section 8. The system must have a built-in automatic audit trail that logs all activities done by the users.

P1: OTE c02

JWBK188-Segalstad

38

September 30, 2008

9:53


Regulatory Requirements for IT Systems §11 Change control Alterations to a system or to a computer program should only be made in accordance with a defined procedure which should include provision for validating, checking, approving and implementing the change. Such an alteration should only be implemented with the agreement of the person responsible for the part of the system concerned, and the alteration should be recorded. Every significant modification should be validated.

Any and every change to the system should be made according to a change control procedure. There are many examples of disastrous changes made without investigation of implications; for example, upgrading the operating system may cause one or more of the applications using it to collapse. A change control SOP is important. This could be written in a generic way to cover all systems in the company. Additionally, a system-specific change control SOP could be made for changes in the system, such as new/changed specifications to a sample type, new/changed studies, and new/changed production. The change control SOP must describe what to do before the change is done, how to do the change, and what to do after the change. It must define which changes shall be subject to the change control procedure. Acute problems may have to be excluded for the prechange phase, but will have to catch up with the change control procedure after the problem has been solved. The SOP must describe who can suggest changes; who shall assess the implications of the change and suggest approval/denial; who shall assess the need for testing/revalidation; and who shall authorize the change to be done. Further, it must set out who shall make, test, and document the change – and, finally, who shall make the actual change. The whole process must be documented. For more on change control, see Chapter 4. §12 Printed copies For quality auditing purposes, it shall be possible to obtain meaningful printed copies of electronically stored data.

The printing of copies is of course possible with the current system, but is it possible for the data created three versions ago, or two systems ago? In most systems available today, it is possible to print meaningful copies by using direct queries, file printing, or reporting tools. In the pharmaceutical industry, the combination of rapid changes in hardware and software and the need to store data for years poses some very difficult requirements. The owners of each system must define and document the definition of what is raw data in their system. They must also decide if paper copies are to be printed out and kept with the batch/study documentation instead of, or in addition to, the electronic storage. The decision of what to do with the data of an obsolete system should be taken long before the system is obsolete. See also the comments to 21 CFR Part 11 Section 11.10 for more details. §13 Stored data Data should be secured by physical or electronic means against wilful or accidental damage, and this in accordance with item 4.9 of the Guide. Stored data should be checked for accessibility, durability and accuracy. If changes are proposed to the computer equipment or its programs, the above mentioned checks should be performed at a frequency appropriate to the storage medium being used.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


EU GMP Annex 11

39

Security in and around the system must be considered, as explained in Sections 1, 3, and 8. Archived data (taking old data out of the system and storing it separately) should be stored on a safe medium and in a safe location. Old data, which it is unnecessary or inconvenient to have on-line or in the database, must be taken out of the system and stored separately from the backup. The use of optical media such as CDs or optical disks for such long-term storage may be wise, as they are considered more stable than magnetic media such as tapes and disks/diskettes. The archived data should be rolled back and tested occasionally. The testing must be documented and filed. A customary view has been that the durability of magnetic media is about five years, while it is now claimed that optical media have a durability of 100 years. Even allowing for accelerated studies, that period of time is hard to take seriously. It will be useful to test the data occasionally. Chapter 5 explains in greater detail about long-term storage of data and its restoration. §14 Backup Data should be protected by backing-up at regular intervals. Back-up data should be stored as long as necessary at a separate and secure location.

Backup should be performed at a regular basis and the backup media must be stored in a different, secure location. Most companies have good backup routines, with systems for backup of new data every day, all data every week, and programs and data every month, or another scheme with which they feel comfortable. They also have systems for reusing the backup media (often tape). A ‘regular’ interval should be defined with reference to the amount of work that the company is willing to redo if its data is lost. Each system owner must ask to have the backup rolled back to check that this is possible. There are examples of backup routines that have backed up the program files only and not the data files. It would be disastrous not to discover that until the rollback is needed. Chapter 5 provides more information about backup and retrieval. §15 Disaster recovery procedures There should be available adequate alternative arrangements for systems which need to be operated in the event of a breakdown. The time required to bring the alternative arrangements into use should be related to the possible urgency of the need to use them. For example, information required to effect a recall must be available at short notice.

A tested disaster recovery procedure for the system must be available; it is too late to start working on that when the disaster has already struck. Disasters may include program failure, system failure, network problems, and server problems, fire, flooding, and electrical problems, and even rats chewing cables. The disaster recovery procedure may stipulate that work must not be done when the system is down, or that the work may be done in a different way. The latter is often called a business continuity procedure. It should also explain what to do to get a new system up and running. It is far easier to get a new PC-based system than a new mainframe, where the delivery time may run into weeks. Some mainframe suppliers offer a subscription service for mainframe rentals, which is like an insurance policy. A PC can usually be bought on the same day in the nearest PC store and, with adequate backups, it can be ready for normal operation within one or two days.

P1: OTE c02

JWBK188-Segalstad

40

September 30, 2008

9:53


Regulatory Requirements for IT Systems §16 Testing of disaster recovery procedures The procedures to be followed if the system fails or breaks down should be defined and validated. Any failures and remedial action taken should be recorded.

All the procedures mentioned in Section 14 must be tested and validated. This has to be done well before there is a need for the procedures. For recalls and other result-oriented disasters, there could be a prewritten report or query to see which batches will have to be recalled, and who has received them. This report or query must also be subject to validation. Disaster recovery and business continuity during disasters are described in Chapter 5. §17 Error handling A procedure should be established to record and analyze errors and to enable corrective action to be taken.

Error handling is closely related to change control, but has more urgency. It is important to keep all of the records. When a system has been in use for some time, people will start to recognize the errors, and it is advantageous to be able to find out what was done to solve the same problem last time. Error logs are handy. If they are kept in a paper-based system, it may be easy to maintain a logbook, with key words and references to where the rest of the documentation is to be found. An electronic error log is much easier to query if the same key words are used to describe the same problems, but it should not be stored inside the same system. That would not be very useful if the system were to crash. Errors may result in changes in the system or in the way it is operated. Such changes are to be subject to change control as described in Section 11. Suppliers should have a system in which program errors are received, acknowledged, and corrected, and other users are immediately informed of those errors. §18 Outsourcing When outside agencies are used to provide a computer service, there should be a formal agreement including a clear statement of the responsibilities of that outside agency (see Chapter 7).

The responsibilities have to be clearly described in a Service Level Agreement (SLA). It may be wise to look at the whole organization around the system as a supplier–customer relationship. This should include internal vendors or suppliers such as the IT/IS department, and internal customers such as the users of the system’s data. In this system, outsourcing may be internal or external. Any outsourcing of the system requires rigid agreements and requirements for responsibilities. This has been described by Siri H. Segalstad [16]. Outsourcing and SLA are also described in Chapter 5. §19 Batch release When the release of batches for sale or supply is carried out using a computerized system, the system should recognize that only an Authorized Person can release the batches and it should clearly identify and record the person releasing the batches.

Sections 8 and 10 also cover these items. The authorized person releases the batch electronically in the system using electronic signatures – or has the system print out the certificate or release document – which is then signed. Electronic signatures were not

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


The PIC Document PI 011 Recommendation

41

invented when Annex 11 was written. For more details, look into the requirements in Part 11 or PI 011.

2.7

The PIC Document PI 011 Recommendation on Computerized Systems in Regulated ‘GxP’ Environments

This document is the inspectors’ counterpart to Part 11. While Part 11 has a couple of pages of text, PI 011 has more than 50, though it is a lot less compact than Part 11’s pages. PI 011-3 was finalized in September 2007, with only minor changes compared to the previous version PI 011-2. A version 4 was said by PIC/S to be available in January 2008, but it isn’t on their web page; nor was there any reference to it when checked in January 2008. Apparently, the only change from the previous version was the name of the chairman. Below are some of the issues discussed in PI 011. PI 011 has references to the ISO (www.iso.org), the IEEE, the ISPE (www.ispe.org) and GAMP (www.ispe.org/gamp), in addition to Part 11 and Annex 11. It encourages the use of the other standards instead of giving the same advice. But it is also critical of standards and, in one place, warns that no standard should ever be followed without understanding how one’s own organization works. I think it is refreshing to see a standard that encourages us to think. However, it is surprising that the references to the ISO standards include the 1995 versions and not the 2000 versions, which were available four years before the PI 011-2 document was finalized. It is quite obvious that Part 11 has been scrutinized when creating this document. A lot has been done to make it a better and more useful document than Part 11. Basically, PI 011 covers the same items as Part 11, but details are spelled out much more clearly than in its US counterpart. A lot of the requirements include advice on what to take into consideration when implementing and validating a computerized system. The PIC/S PI 011 is a long document, so it isn’t possible to make a complete list of each of the requirements for this document in the same way as for the two previous documents described in this chapter. As the documents cover so many of the same items, it would be a waste of time and space to go into all the details of PI 011. Basically, it contains the same information as 21 CFR Part 11, but often described in more detail. The PI 011 is also copyrighted material and is therefore discussed below without any text from the standard. Please read the document to see the details. There is a distinction in the typeface of the document to indicate whether the text is explanatory (normal) or what the inspector expects to see (italic). The purpose of the document is to explain what the inspectors expect to see as goodpractice handling of computerized systems: r New technologies are supported and encouraged r A risk-based approach to validation is recommended, and the creation of a URS is essential in order to select the right system. The document also stresses cooperation between the various actors in the process. GAMP is referenced as the definition of best practices r The life-cycle approach is emphasized, covering both the suppliers’ part of the development and the users’ part of the life cycle

P1: OTE c02

JWBK188-Segalstad

42

September 30, 2008

9:53



r The supplier needs to build quality into the system, as it isn’t possible to test quality into the finished software r Schematic identification of the various parts of the hardware and software is also called configuration management. The supplier is responsible for the configuration of the delivered system, while the user is responsible for the system in use r The document has references to ISO 9000, ISO ISO/IEC 12207, ISO 9004, ISO 10005, ISO 10007, ISO 9126, IEEE 1298, and GAMP r The validation policies are stated either as policies per se, and/or as parts of the procedures in the organization. Exactly where they should be depends on how the company has built its quality system. The inspectors expect to see this documented, which means that this can be regarded as mandatory r While management can leave the responsibility for the practical work to someone else, they can’t relieve themselves of the responsibility: The overall responsibility is theirs, and they need to be involved in the work. Active participation is the only solution, and it must be documented in the quality system and its use r The URS is the single most important document to create before selecting a new system. It is also vital to validation, as the URS forms the ‘correct answers’ to the testing of the system during validation/qualification r While the URS forms the overall requirements for the system, the FS is the detailed functional description that tailors the URS to the chosen system r The development/supplier chapter also includes the so-called ISO V-model, as this explains the relationships between plans and testing. But it is also clearly stated that there are several different acceptable models. This is also true in ISO 90003, from where the model is taken. Basically, the V-model states that there shall be requirement plans in several layers, which are more detailed for each successive layer, and test plans for each layer which will prove that the system fulfills the requirements. The document refers to several quality standards – ISO 9001, ISO 9126, IEEE 1298, and GAMP 4 – and explains why a supplier would want to use them r Testing is the best way to prove that the system does what it purports to do, which is to comply with the stated requirements. A traceability matrix between the URS/FS and the test scripts will indicate whether the requirements have been tested r The validation chapter repeats the GAMP 4 software categories and what should be done in terms of validation effort for each of them. It also offers some cautions if planning to use GAMP directly r While GAMP is a great tool, it isn’t forbidden to think! In fact, each organization must assess the risks for each of the systems, and then subsequently apply the GAMP categories. Since the PI 011 document was written, GAMP has added a risk-based approach guide and a laboratory guide as well as GAMP 5 which may add further help in assessing the organization’s IT systems r Retrospective validation is also covered. All systems need to be validated, and with new systems this is expected to have been done before the system is taken into live use. Old (= legacy) systems that have been used will need retrospective validation. It is increasingly difficult to convince inspectors that there is a good reason for not having validated existing systems, as the requirement for validation has been in force since the early 1990s. The document explains what the inspectors expect to be done with legacy systems

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


GAMP

43

r Basically, these are the same requirements for system security and audit trails as stated in 21 CFR Part 11, but some of the requirements are spelled out in more detail than Part 11, such as the procedure for prohibited passwords, and the requirement that systems should have functionality for enforcing password changes r More details are given for change control, user access, passwords, backups, and longterm storage than in Part 11. The text about external access is equivalent to the Part 11 description of open systems, though the expressions ‘closed’ and ‘open’ are not used in this document. Legally binding electronic signatures also have their counterpart in Part 11, but there is no requirement to send a letter to the EU regulatory agencies to confirm that electronic signatures will be used by the organization r Electronic signatures can only be used if the basic security criteria of the system have been fulfilled. There is also more detail given on how an electronic signature works in an IT system r Personnel shall be trained, be security cleared, have clear responsibilities, and so on, and all this shall be documented. Training includes general training programs, as well as life-cycle training r Training must be described in the company’s procedures, and the description must include how training will be planned according to needs, how training plans will be made and documented for each person, and how training will be recorded. Responsibilities are often described against roles. Each person will normally be assigned more than one role r The end of the document explains what the inspectors will look for when inspecting and also includes checklists used during inspection. As such, this is good when preparing for an inspection, but it is also useful to look into during the validation processes. All of these items are explained in various chapters of this book

2.8

GAMP

Good Automated Manufacturing Practice (GAMP) was started as a private initiative guideline to explain to the pharmaceutical industry what IT systems validation was and how to comply with the regulatory requirements, as these requirements were very hard to translate into ‘what do we actually do to validate our computer system.’ The first version of GAMP was introduced in 1995, and now, more than a decade later, it is an industry standard endorsed by the FDA and European agencies. This has transformed GAMP from a guideline into a more or less mandatory standard. The current version is GAMP 5 [17]. The GAMP organization is a voluntary body, in which hundreds of people around the world take part in preparing various standards and good practices under the International Society for Pharmaceutical Engineers (ISPE) umbrella. The result has been that GAMP has issued several guidelines as answers to the new regulatory initiatives. Each of the guides has detailed suggestions for how to handle the items in question. r the Part 11 risk-based approach to validation [18] r the laboratory instruments guide [19] r testing of GxP critical systems [20]

P1: OTE c02

JWBK188-Segalstad

44

r r r r r

September 30, 2008

9:53



global information systems [21] calibration management [22] the infrastructure guide [23] process control systems [24] archiving of electronic data [25]

GAMP is currently working on several new guides. Smaller guides are called Position Papers. These include a guide for Building Management Systems [26]. GAMP 4 [27], as well as the new GAMP 5, and their associated Good Practice Guides all cover various aspects of validation. These various guides reflect EU and US regulatory requirements and expectations, and give good practical advice on what needs to be done. The GAMP guides are great tools, but none of them should ever be used directly, in a copy-and-paste manner. Each organization works differently, and you must make sure that you still assess your organization and your way of working. In other words: Thinking is still encouraged. The main difference between GAMP 4 and GAMP 5 isn’t what is expected to be done, but who is to do what.

2.8.1

GAMP 4

GAMP 4 basically says that you need to audit the supplier of the category 4 or 5 system to see whether the software has been created in a quality environment. You will have to do a complete IQ/OQ/PQ in your organization – even if, for example, the supplier has already tested OQ during development. The depth, however, depends on your risk analysis.

2.8.2

GAMP 5

GAMP 5 takes a radically different approach to the question of who is to do what testing. The approach is based on pragmatism and risks, and aims to avoid duplication of testing. In GAMP 5, it is accepted that you leave it to the supplier do a lot of the testing, and that you do not have to repeat this yourself. Any decent supplier will create and test their software in an organized way, as explained in their quality system. How this should be done is described in Chapter 6. Testing here will, of course, include checking that all functions work as intended. This is generally also what the user retests in his OQ. In my opinion, this approach is fully acceptable only if you have extremely competent people to do a very thorough supplier audit. If this competence is absent, you may not pick up or understand what they have omitted to do. This is what you will need to do yourselves in your organization. There is a good chance that a lot of organizations will not have the necessary audit competence; and that at the same time they will leave testing to the supplier and do less internally. A void can easily open up between what should have been done and what has been done. Organizations tend to take the easy way out, as it is cheaper and requires fewer resources. Audits are described in Chapter 10. Even with this approach, each organization must do a PQ, as its workflow through the system is always unique and can’t possibly be fully tested by the supplier.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


A Comparison between the Standards

45

As GAMP 5 was been finalized when this text was written, minor changes may be made to the document, even if the approach seems to be fixed. It will also take some time to find out how the approach works out in real life once organizations start to use it.

2.9

The ISO 9000 Series

The ISO 9000 series documents are not pharmaceutical standards, but are still useful for pharmaceutical companies. ISO standards can be purchased from the national standards organizations, often in the native language in addition to English. ISO 9001 [28] is easy to use for companies producing tangible items. Software is an intangible product, and ISO 9001 isn’t equally good for software. The ISO organization has created a guideline to ISO 9001 to explain how to deal with software. This was originally called ISO 9000-3, and as such it has been published in several editions. In its newest edition, it is renamed as ISO 90003:2004 [29]. ISO 90003 explains how a software supplier must plan, program, test, and support software. When a software company wants to be ISO 9001 certified, it is normally done ‘under the TickIT Scheme’; that is, the TickIT Guide [30] and ISO 90003 are followed. A pharmaceutical company will quite often perform a supplier audit on its major software suppliers, and the ISO 90003 standard explains what to expect from the supplier. Publications have also been written on this issue [31, 32]. The TickIT Guide is very useful as additional reading for what to expect. In principle, there is no difference between what is normally done in a pharmaceutical company and what a software supplier should do: Plan what to do, do what you plan, and document what you have done. GAMP also covers supplier audits in an appendix, but the appendix is a bit thin and lacking in substantial information. ISO 90003 gives a more thorough basis for understanding what needs to be included in the checklist.

2.10

A Comparison between the Standards

There are no contradictions in the requirements in the three standards 21 CFR Part 11, EU GMP Annex 11, and PI 011-3, but there is a large difference in how much they actually tell the reader. Annex 11 is short and concise, but very difficult to use unless you actually understand what to do. Part 11 is a bit longer, and has been interpreted differently over the years. Some of this has a root cause in warning letters from inspections; some in what an inspector has said in public, which has immediately been understood as the interpretation of the requirement; and in other cases there have been various interpretations, where the pendulum has swung from one extreme to the other. An example of the latter was the question of whether word processors should be Part 11 compliant. SOPs and other documents are written using word processors, and even if a paper printout and its controlled copies were to be defined as the valid SOP, the word processor would either need or not need to be in compliance, depending on the point of view. If the SOP is used electronically, it is an electronic record that will normally be

P1: OTE c02

JWBK188-Segalstad

46

September 30, 2008

9:53



regarded as a GxP record. In a risk-based approach, organizations can define it as they please, provided that there are valid arguments for their opinion. PI 011 is a lot bigger and includes discussions of several of the items. Many of these discussions have references to further reading in other standards, and GAMP 4 is one of them. The risk-based approach is heavily emphasized. There is also a distinction in typeface to indicate whether the text is explanatory (normal) or what the inspector expects to see (italic). Even people in US companies will do well to make themselves familiar with this document, as it gives a lot more detail, whereas Part 11 only states expectations. 2.10.1

Differences

The differences between the standards are in the words and the level of detail, and not in the requirements or interpretation. Standards generally cater to one specific type of organization: The ISO 9000 series is meant for manufacturers, regardless of whether they make safety pins or cars; the GxP standards are meant for pharmaceutical development, testing, and production; and different standards are meant for pharmaceutical inspectors. Part 11 and Annex 11 have the end-users as their primary focus. PI 011 also has a section on some of the suppliers’ responsibilities for creating the software in a quality environment, and suggests the use of a few standards for that purpose as well as inspectors’ expectations. GAMP has chapters for the system developers – that is, the suppliers – for how to develop the system in a quality environment; chapters for QA auditors, so that they will know what to look for when doing a supplier audit; and chapters for the end-users, so that they will know how to validate their systems. GAMP is the most detailed document. It is also the only one that explains in detail how to fulfill requirements, instead of just stating the requirements. Probably the most significant difference is in the level of detail in validation descriptions. While Part 11 mentions the word ‘validation’ once in Section 11.10(a), detailed requirements and expectations of the validation effort are described throughout the PI 011 document. Annex 11 includes a short description, and GAMP’s 200+ pages are dedicated to all practical aspects of validation. One item not mentioned in Annex 11 is electronic signatures. This is most likely due to the old age of that document. Electronic signatures were barely invented in the early 1990s, and definitely not something anyone would dare to use. Risk assessment/risk management is included in the draft guidance to industry for Part 11, and is also in PI 011. GAMP has a separate guide to the risk-based approach to validation of computerized systems. GAMP 5 completely embeds risk-based approach. 2.10.2

Similarities

When looking at the three documents – Part 11, Annex 11, and PI 011 – we can see that there are few requirement differences. The words may be different, and the level of detail is certainly different, but the content is basically the same. None of the documents have requirements that can’t be read into each of the other two documents, with the exception of electronic signatures, which are not mentioned in Annex 11. The risk-based approach has been adopted by both the US FDA and the European authorities, and is now the current way of thinking.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


References

47

Appendix 1 gives a selected overview of the various standards’ coverage of some of the requirements.

2.11

Conclusion

Companies have done a lot of work over recent years to make sure that their systems are Part 11 compliant; if they are Part 11 compliant, they are also likely to be compliant with the EU requirements set forth in PI 011 and Annex 11. PI 011 contains a lot of suggestions and details that US users can also benefit from. It might be useful to take a look at this document, even if your organization does not have to comply with it. GAMP and its guides all cover various aspects of validation. As both the US and the EU inspectors endorse the methodology, it is worth using the GAMP guides to understand what should be done. The GAMP guides are great tools. But none of the guides should ever be used directly, on a copy-and-paste basis. Each organization works differently, and you must make sure that you still assess your organization and your way of working. In other words: Thinking is still to be encouraged.

2.12

Tasks

2.12.1 A Comparison between GAMP and the Standards r If GAMP 4 or GAMP 5 is available: Who is the target audience for this standard? r Compare it to the GxPs and note similarities and differences 2.12.2

Compare the Standards

Compare the standards/guidelines ISO 9001:2000, EU GMP Annex, and GAMP: r r r r r

For whom has the standard been written? What is the purpose of the standard? Which standard is best for creating a quality system? Why is this standard better than the others? May ISO 9001:2000 be used in the pharmaceutical industry? Explain your answer

References 1. US FDA (1983) Guide to Inspection of Computerized Systems in Drug Processing (Reference Material and Training Aids for Investigators) ‘Blue book’, US Food and Drug Administration, Rockville, MD. 2. DIA (1988) Computerized Data Systems for Nonclinical Safety Assessment – Current Concepts and Quality Assurance, ‘Red Apple book’, Drug Information Association (DIA), P.O. Box 3190, Maple Glen, PA, 19002. 3. Motise, P.J. (1984) Validation of computerized systems in the control of drug processes: an FDA perspective. Pharmaceutical Technology, 40–45.

P1: OTE c02

JWBK188-Segalstad

48

September 30, 2008

9:53



4. Masters, G. and Figarole, P. (1985) Validation principles for computer systems – FDA’s perspective. Pharmaceutical Technology, 44–46. 5. Segalstad, S.H. (2000) The WWW (Who-Why-What) of 21 CFR Part 11 electronic records and electronic signatures. European Pharmaceutical Review, 5 (2), 69–74. Part of this chapter is based on this publication. 6. Lopez, O. (2004), 21 CFR Part 11: Complete Guide to International Computer Validation Compliance for the Pharmaceutical Industry, CRC Press, Boca Raton, FL, ISBN 0-8493-2243X. 7. McDowall, R.D. (2005) Validation of Chromatography Data Systems, The Royal Society of Chemistry, Cambridge, UK, ISBN 0-85404-969-X. 8. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 9. European Union (1998) Volume 4 – Good Manufacturing Practices – Medicinal Products for Human and Veterinary Use, pp. 153, incl. Annex 11 covering computerized systems. 10. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org. 11. Huber, L. (2000) Moving a LIMS from handwritten signatures to 21 CFR Part 11: compliant e-records and signatures. LIMS conference abstract. 12. English, E. (1994) Don’t even think you can fool ID-007. Computer Fraud and Security Bulletin, 7. 13. TickIT DISC Office, P.O. Box 4033, Milton Keynes MK14 6LE, UK. 14. McLelland, A.S. (1991) UK clinical chemistry information systems: coping with resource management in the national health service. Chemometrics and Intelligent Laboratory Systems: Laboratory Information Management, 13, 43. 15. Automatic ID News, Europe, Advanstar House, Park West, Sealand Road, Chester CH1 4RN, UK. 16. Segalstad, S.H. (1996) Outsourcing work in the pharmaceutical business – a challenge to quality. European Pharmaceutical Review, 1 (4), 59. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based Ap17. GAMP proach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. R Good Practice Guide: A Risk-Based Approach to Compliant Electronic Records and 18. GAMP Signatures, 1st edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. R Good Practice Guide: Validation of Laboratory Computerized Systems, 1st edn (2005), 19. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-39-7, www.ispe.org. R Good Practice Guide: Testing of GxP Systems, 1st edn (2005), International Society 20. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. R Good Practice Guide: Global Information Systems Control and Compliance, 1st 21. GAMP edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-43-5, www.ispe.org. R Good Practice Guide: Calibration Management, 1st edn (2001), International Society 22. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, US version ISBN 1-931879-25-7, German version ISBN 1-931879-26-5, www.ispe.org. R Good Practice Guide: IT Infrastructure Control and Compliance, 1st edn (2005), 23. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-42-7, www.ispe.org. R Good Practice Guide: Validation of Process Control Systems, 1st edn (2003), Interna24. GAMP tional Society for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


References

49

R Good Practice Guide: Electronic Data Archiving, 1st edn (2007), International Society 25. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org. R Special Interest Group (2005) Use of building management systems and environmental 26. GAMP monitoring systems in regulated environments. Pharmaceutical Engineering, 25, 28–78. R R 4 Good Automated Manufacturing Practice (GAMP ) Guide for Validation of Auto27. GAMP mated Systems, 4th edn (2001), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-17-6, www.ispe.org. 28. ISO 9001:2000 (2000) Quality Management Systems – Requirements, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 29. ISO 90003:2004 (2004) Software Engineering – Guidelines for the Application of ISO 9001:2000 to Computer Software (formerly ISO 9000-9003), International Organization for Standardization, Geneva, Switzerland, www.iso.org. 30. TickIT (2001) The TickIT Guide Using ISO 9001:2000 for Software Quality Management System Construction, Certification and Continual Improvement, Issue 5.0, TickIT Office, 389 Chiswick High Road, London W4 4AL, UK, ISBN 0-580-36743-9, www.tickit.org. 31. Segalstad, S.H. (1996) Vendor audits for computer systems: an ISO 9000-9003 approach. Laboratory Automation and Information Management, 32, 23. 32. Segalstad, S.H. (1996) Supplier auditing and software. European Pharmaceutical Review, 1 (3), 37.

Acknowledgement Parts of this chapter reproduced from: How to use and misuse a consultant, Segalstad, Scientific Consulting LIMS, Issue January 2003 (14–19) and Standards for LIMS, Segalstad, Scientific Computing and Instrumentation, January 2007 (1–2 and 19–24), with permission.

P1: OTE c02

JWBK188-Segalstad

September 30, 2008

9:53


P1: OTE c03

JWBK188-Segalstad

September 15, 2008

11:26


3 IT Security

This chapter discusses the following: r r r r

Aspects of IT security outside of the IT system Threats to security Security policy The disaster plan

3.1

Introduction

The last chapter discussed the security for data as defined in 21 CFR Part 11 [1] and PI 011-3 [2]. These two regulations cover each IT system and its functionality, as well as procedures and validation. Security in a broader perspective needs to be taken into consideration as well. There are numerous threats that the organization must be aware of and must take measures to eliminate. Symantec has issued a book [3] about IT security. A lot of the information in this chapter is based on this book. Permission has been given to use the information. Virus threats are well known, and most people have experienced viruses. But there are other dangerous threats as well, that both the organization and the people working there need to be aware of. Internet and Internet-based applications are attractive to use, but they do open up the possibility of attacks. The technical ease of mobility gives us fantastic opportunities, but it also opens up greater risk for the company. The use of a wireless laptop in the open is also a risk. Obviously you are using expensive equipment, and it is easy for a thief to map your movements and find a way to steal the PC – with all the stored valuable information. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c03

JWBK188-Segalstad

52

September 15, 2008

11:26


IT Security

Even the PC, with all its USB components and USB gadgetry, poses a threat. Experts claim that everything can be connected via USB, including the installation of undesired software and viruses, with all their implications. Wireless connections are also risk factors. This isn’t limited to PCs, but also applies to mobile phones and smart phones, as the radio signals to and from them can be picked up by others. So how can we make a secure IT environment while utilizing the fantastic possibilities that the technology has to offer?

3.2

Continuous Connections – Wireless Networks

Remote access is easy with ADSL or other kinds of broadband, especially when there are also wireless access points available. More and more coffee shops, parks, and whole downtown areas have wireless access. These facilities are, of course, used by employees, but the company must have clear procedures for how to use them in order to avoid security risks. PCs have wireless network cards that make it possible to send documents to printers and to connect to other PCs. The WAN uses radio signals that can be picked up and used from as far away as 100 m unless the WAN is secure. Employees can connect to the company via remote access. It is vital that a computer used for this purpose has every possible kind of security, such as a firewall and a continuously updated antivirus program. The currently best solution is a Virtual Private Network (VPN), which creates a secure tunnel to the connection between the office and the remote user. Factors to consider for wireless networks are as follows: r Never use the standard settings r Activate the Wired Equivalent Privacy, which is a security protocol for WANs, and change the encryption key frequently r Place the access points in the middle of the building r Limit the physical access to the access points r Limit the connections between the WAN and the normal network, and install an extra firewall r Keep an eye on the guests. A handheld computer with WLAN is easy to hide r Train the users r Prohibit illegal access points, and punish those who don’t follow the rules

3.3

Threats

There are basically three internal threats against the IT environment: r employees r low priority for IT security r new computers

P1: OTE c03

JWBK188-Segalstad

September 15, 2008

11:26


The Security Policy

53

Important information in the wrong hands will damage the company, with possible financial consequences. The threats are not always attacks. Sometimes the employees themselves are the ones who cause the threats, when they don’t use the PC as intended. Some people let their kids use the work computer. Some people use the work PC for surfing on the Internet and downloading files. Many people don’t really understand how to treat their PCs properly. The executives in the company generally spend their time prioritizing the business and the costs, and downplay the important aspects of IT security. It is very easy to wait a little longer to create a policy for IT security – after all, nothing has happened so far, so it can’t be so important. New computers are bought to replace the old ones. The old ones are often given to schools and other charities. But is the hard disk completely erased before it is given away? Using the ‘delete’ command only erases the disk’s table of contents, not the content itself. The data isn’t deleted unless it has either been overwritten with new data or erased magnetically, usually by professionals. The best thing is to install a brand new hard disk before giving the PC away. External threats come from several different areas. Some are directed against one particular company, while others are more general and the instigators hope that someone will fall into their trap. In the early days, hackers broke into computers and created viruses just for the fun of it, and to prove that they could do it. Now, they are becoming more sophisticated, and the goal is often a financial benefit. Viruses will infect the computer, but the threat is generally under control due to companies who continuously update antivirus software, which is downloaded to their customers every few days. Most worms spread via e-mail and are activated when people open attachments in which they are hiding. They can also spread though networks without human interference. They reproduce by copying their code to other computers and they take up a lot of resources, which slows down other traffic. Trojans don’t reproduce themselves. People are lured to download and install a program that seems to be interesting, but is something entirely different. It opens up a back door to the computer and leaves it open for attack via the Internet, so that the imposter can take control of the computer.

3.4

The Security Policy

A Security Policy should be prepared and, of course, followed by all employees. Training and understanding is necessary to make people adhere to this policy. The policy is normally an overview, and should be followed up with procedures that provide more details. The policy needs to describe the basic protective measures to be applied with regard to storage and transmittal of the company’s information. Additional security measures must be considered for systems that contain sensitive information and for systems that are of vital importance to daily operation.

P1: OTE c03

JWBK188-Segalstad

54

September 15, 2008

11:26


IT Security

The policy should aim to: r Protect secrecies – that is, the company’s information – from unauthorized access. Contractors must sign a nondisclosure agreement r Protect integrity and quality; that is, protect the information from undesired modification r Ascertain the availability and accessibility of the information when needed r Protect facilities and equipment from damage or loss The policy should also include information about and responsibilities for: r Securing hardware and software infrastructure r Providing and implementing IT security tools for virus protection, backup and restore operations, and encryption; and initiating risk analyses and consequence analyses from a security point of view. In addition to risk analysis, an analysis of the consequences of the loss of IT services should be performed regularly (how often?) or in the event of major changes in the IT environment. The purpose is to determine the economic damage that the company would suffer in the case of loss of service, and also to serve as a basis for disaster planning r Setting up and maintaining plans for disaster recovery r Coordinating and supporting security activities, standards, and guidelines r Issuing and revising the Security Policy and related instructions r Auditing the compliance with the Security Policy r Security policy training r Restricting access to machine rooms and server rooms. Only the people who need to be there should have access. Appropriate locks and alarms must be installed r Disaster recovery procedures and business continuity procedures in case of fire, flooding, power supply disruption, and other problems r Access to information due to access to the company’s premises and systems r Password rules: how many characters, what is a good password, and how often it should be changed r Blocking of access to systems in case of wrong log-on attempts, and logging of these attempts r Rules for the use of portable computers. Everyone who is using a portable computer or working externally needs to have the correct security installed. This must include virus protection, a firewall, and secure remote log-ins to the company’s network. Maintaining confidentiality is also important, as the files often contain confidential information

3.5 3.5.1

Tasks The Disaster Plan

Create the key points for a disaster plan with the following elements: r Membership: Who is to be a member of the disaster group? r Objectives: What is the goal for the plan – Protection of data or other resources? Maintaining business processes? Other? r An overview of the IT tools in the company needed to reach the goal

P1: OTE c03

JWBK188-Segalstad

September 15, 2008

11:26


References

55

r Risk analysis for the company and its customers, as well as details of which threats will have an impact on which departments r How to teach the employees about the plan and make them understand the importance and their own role 3.5.2

The Business Continuity Plan

Create a business continuity plan based on the points that you included in the disaster plan.

References 1. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 2. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org. 3. Symantec Nordic AB (2007) Et Sikkert IT Miljø (A Safe IT Environment), Symantec Nordic AB, Stockholm, Sweden, ISBN 978-91-9768811-1-7.

P1: OTE c03

JWBK188-Segalstad

September 15, 2008

11:26


P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


4 Quality Management Systems

This chapter discusses the following: r How to create a Quality Management System (QMS) by using the three levels Quality Policy, Quality Manual, and SOP r Roles, responsibilities, and workflows in the organization r How to write an SOP

4.1

An Introduction to QMS

Why would anyone want to have a quality management system? Regardless of which standards organizations have to comply with or want to comply with, they all have requirements for a QMS. The newcomer’s answer to ‘why do we need a quality system’ is that some person or another, such as the regulatory agency or the boss, requires the organization to have a QMS. To more experienced, quality-conscious persons, the answer is that a QMS is a great tool for everyone in the organization. A good QMS will give an overview of the work processes in the organization. It is a benefit just to get processes documented by writing them down, rather than having the knowledge stored in various people’s heads. When the information is available to everyone, the result is that the organization is less vulnerable; the organization isn’t dependent on just one or two people to retrieve the knowledge. Quality is defined in ISO 8402 [1] as ‘The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.’ It is difficult to understand what quality is by just looking at the definition. There are many good ways to create a good quality system, and there are also many ways that are not good. When it International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c04

JWBK188-Segalstad

58

September 15, 2008

11:12


Quality Management Systems

comes to Quality Assurance, the problem is that there are few specific rules for how to do anything. The standards focus on requirements for what to include, but not how to include those requirements. The descriptions in the quality system need to include details for how things are to be done, so that the users obey the external requirements, which are fairly static. At the same time, the descriptions must set out exactly what is actually done in the organization. How to do things varies a lot between supposedly similar organizations. The organization has to comply with external requirements, and the goal is to understand quality and to understand whether what is done is good enough. ‘Gut feeling’ is often a misused expression, but if a person does understand quality, their gut feelings may be used. If that person feels that what is done is sufficient, it may actually be sufficient. However, gut feelings are no good when people don’t understand what is needed. And gut feelings should never be used as a guideline for taking shortcuts. It is impossible to move a ‘perfect’ quality system from one company to another. It will not be as good in the next organization, because each organization is different. Each organization’s culture is different, just as things are done differently, and this requires each organization to have a different quality system. The creation of templates for a quality system is useful only to the extent that the users understand what to change and what can be used. The questions ‘Is this good enough?’ or ‘Can it be done this way?’ are often asked. Unfortunately, all too often the answer is ‘It depends . . .’ And it does depend – on the organization, the way the organization works, the workflows, and the external and internal requirements, among other factors. It also depends on what the organization is actually trying to achieve. In some industries, the quality management system’s goal is to assist in enhancing customer satisfaction. In the pharmaceutical industry, the goal is safety for the patients, who are the end-users of the products. In essence, customer satisfaction is also what the pharmaceutical industry is aiming at.

4.2

Definitions

Before starting to describe the QMS, some definitions are required. Across various standards there are unfortunately different definitions for the same words, and there are the same definitions for different words. A complete list of definitions is given in Appendix 2. Quality is defined in ISO 9000 [2] as the ‘Degree to which a set of inherent characteristics fulfils requirements.’ It is worth noting that the word ‘inherent’ is used, as opposed to ‘planned.’ Quality Assurance (QA) is defined by the FDA Glossary [3] as follows: 1. The planned, systematic activities necessary to ensure that a component, module, or system conforms to established technical requirements. 2. All actions that are taken to ensure that a development organization delivers products that meet performance requirements and adhere to standards and procedures. 3. The policy, procedures, and systematic actions established in an enterprise for the purpose of providing and maintaining some degree of confidence in data integrity and accuracy throughout the life cycle of the data, which includes input, update, manipulation, and output.

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


Principles for Quality Management

59

4. The actions, planned and performed, to provide confidence that all systems and components that influence the quality of the product are working as expected individually and collectively. The role of QA is to be responsible for the quality system by authorizing documentation and performing internal or external audits; see [4] above. Quality Control (QC) is defined by ISO 9000 as the ‘Part of quality management focused on fulfilling quality requirements’. It is important to understand the difference between QA and QC. While QA is responsible for the quality system, QC uses this to control the output of the products. For example: Quality assurance is to create procedures for how to produce and test the products, while quality control uses the procedures to manufacture and test that the products have the quality that they are required to have. While QA is independent of the manufacturing/testing part of the organization, QC is usually a part of that organization. Regulatory is defined here as the external requirements for the organization; for example, GxP for pharmaceutical companies, ISO for accredited/certified companies, GALP for environmental requirements in the United States, and so on, as discussed in Chapters 1 and 2. Controlled document means that there is complete version control for the document. Documents must be signed (handwritten or electronically) and dated during authorization, and old/obsolete versions must be removed, but stored in a historic archive for retrieval when needed. Access to editing and approval/authorization is limited to certain people/roles, as described in the quality system.

4.3

Principles for Quality Management

ISO 9000 and ISO 9001 [4] are good to refer to when you create a quality management system, regardless of the type of industry; they cover fundamentals and vocabulary, as well as principles for good quality management. ISO 9000 has identified eight quality principles that management uses in order to lead the organization toward improved performance: 1. Customer focus: Customers are necessary for being in business, and it is important to understand their needs and expectations. 2. Internal leadership, so that employees know what the organization’s objectives and directions are. 3. Involvement of people, so that all employees utilize their abilities to benefit the organization. 4. A process approach to achieve a desired result more efficiently. 5. A system approach to understand and identify interrelated processes. 6. Continual performance improvement as an overall objective for the organization. 7. A factual approach to decision making based on analysis of data and information. 8. A mutually beneficial supplier relationship, which enhances the value for both parties.

P1: OTE c04

JWBK188-Segalstad

60

4.4

September 15, 2008

11:12



Quality Management System Levels

A QMS has several levels, and each organization determines how many levels it wants. It is fairly normal to have three levels, but two, four, or even five levels are perfectly acceptable. A three-level QMS is shown in Figure 4.1. The two mandatory levels in any QMS are the Quality Policy (QP) and the Standard Operating Procedures (SOPs). Additionally, a Quality Manual (QM) usually exists, with a detail level between that of the policy and the SOPs. SOPs may exist on two or more levels – for example, one global level for the whole organization, and a more detailed level for each of the subparts of the organization – or as SOPs and ‘work instructions.’ The main problem with having more than one level is deciding what belongs in which level. Unfortunately, many a QMS starts as local initiatives in different parts of the organization. The consequences of localized efforts often manifest themselves as nonuniform procedures coexisting within the same entity. At other times, the result is contradictory procedures. One disadvantage of starting in several places in the organization instead of at the top is the inefficiency of having many people writing more or less the same procedure.

Figure 4.1

A three-layer quality management system.

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


Roles and Responsibilities

4.5

61

Creating a QMS

When creating a new QMS, it is easiest to start at the top and then move downward to add the level of detail. Organizations must determine for themselves how many levels they want in the QMS, as well as the desired level of detail in each of the system’s levels. Since an effective QMS is recognized by consistent documents, it makes sense to create it from the top level, as the level below requires more detail than the parent level, without any accompanying contradiction. A QMS can be created in various ways, and there is no correct solution to how to do it as long as everything is included in a logical fashion. This makes it difficult to write a QMS. Some items and details may be found in the Quality Manual or in procedures, or even in the documents that are needed according to the QMS. Usually, every generic question such as ‘Is it OK to include the item here?’ can be answered with ‘it depends.’ And it depends on many factors. For example: r The definition of an expression may be included in an SOP where it is used, but only if it is not in a list of definitions in the quality manual or somewhere else r Having the definition in two or more places makes it necessary to update the definition in each of these places when changes are made r It is a fair guess that no one will know where else the definition has been included r The same applies to instructions for how to do something. Refer to where the instructions have been set out, rather than repeating what has already been written r It saves a lot of time and effort if things are as high up in the quality systems as possible, instead of being repeated for every department r Include all general items in either the Quality Manual or in SOPs that cover the whole organization The organization must define the roles and responsibilities before creating the QMS. It must also have a good understanding of its workflows. The workflows may currently be documented formally, or they may be informal – such as ‘this is the way we usually do it.’ They need to be formally documented in a QMS.

4.6

Roles and Responsibilities

Before writing the QMS, you must have an overview of which roles exist in the organization, and what each of these roles is responsible for. One person can be assigned one or several roles. Which roles are there in the organization? The obvious answer is secretary, CEO, analyst, and laboratory manager, just to mention a few. Interviewing is a way to find out which types of work are done in the organization. The list of responsibilities may have several common denominators, which can be extracted as separate roles. When looking more closely, you can see that even the analysts do different work: While two people do laboratory work, one might additionally be responsible for an instrument and the other might additionally be responsible for purchasing chemicals for the laboratory. In that case, it is useful to divide this into three roles: Both have the role ‘Analyst,’ which is used when they do the laboratory analyses. Create additional roles such as ‘Purchaser’ and

P1: OTE c04

JWBK188-Segalstad

62

September 15, 2008

11:12



‘Person responsible for instruments,’ and assign that role to each person as appropriate. The ‘Person responsible for instruments’ role is probably also shared with other people, both in the laboratory and in the production facility.

4.6.1

Quality Assurance

Quality Assurance (QA) is a role that every organization with a quality system needs to define. The QA role can belong to one person or a group of people. In a larger organization, the QA unit has several people, each with a specialist field of knowledge. The QA people must understand both quality itself and the practical parts of the field for which they are responsible. QA is responsible for approving the QMS items, such as SOPs, plans, and reports. The role of QA is not to know every little detail of how work is to be done, but to make sure that the descriptions in the procedures are in accordance with the requirements in the QMS. This means controlling in a formal way to ensure these are done correctly, and are in place where needed. A QA person responsible for production must be independent of the production work. The task of QA is to oversee the quality, and nothing else. In small organizations with few employees, the QA role is a difficult one. Usually, one person has a part-time operational role and a part-time QA role. If you are in this situation, you must be very clear on which hat you are wearing at any given time: You must never wear the QA hat for something with which you have been directly involved in your operational job. The procedures in the organization must also address this issue, so that conflict of interest is minimized. The golden rule for any quality system is that you must never approve or authorize the work you have been involved in yourself.

4.6.2

Management Involvement and Commitment to Quality

Both the ISO standards and the pharmaceutical standards require that top management is involved in the QMS. But there is also a practical aspect to that: Without management involvement, the QMS will probably not function. A management that does not endorse the QMS will not assign resources to the QMS work. People will quickly get the notion that the quality system is optional, and that there are no consequences if it isn’t followed. The inevitable result is poorer quality. The main tasks for the management are to establish the Quality Policy and the quality objectives for the organization, to conduct management reviews, and to ensure that resources are available. One of the management’s tasks is to review and assess the QMS for suitability and effectiveness. For example, while quality audits are often conducted by QA, addressing findings in internal audits is the management’s responsibility. Findings must be followed up by improvements in the quality system, so-called preventive actions. Top management is rarely involved in the daily work of Quality Assurance and the quality management system, so including the head of QA in the organization’s leader

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


Controlled Documents

63

group is a way for management to stay informed. QA personnel will find it easier to raise issues when they are members of the management group. Continual improvement of the quality system is one of the goals in the ISO system; in the GxP, rather, the goal is to be in compliance with the regulations.

4.7

Work Processes

It is important to understand the work processes in order to handle them well in the quality system. This understanding is used for assessing business risks and quality risks in the processes. It is also used for describing how the work must be done. Flowcharts are good tools to visually show how things are done in the organization. It is usually easy to describe how things are normally done, but how do you handle the things that are not straightforward? The flowcharts and processes also need to include the abnormal things that inevitably happen in daily life. For example, if Quality Control detects that the product is not according to specification, do you reanalyze, reprocess the batch, or discard the batch altogether?

4.8

Controlled Documents

In any quality system, documents need to be under control. That means that the document must: r Have a unique document name, so that it can be identified r Usually be approved by a person with knowledge and understanding of the content of the document r Be authorized by a person with a role to authorize such documents, based on formal requirements in the QMS. This is often a QA person r Have version control, stated either using version numbers or a valid-from date, or both. Documents must not be changed without approval/authorization r Be distributed in a controlled manner, to ensure that users always have the latest version r Be archived, so that all current and historic versions are available It isn’t only the QMS documents that need to be controlled. The QMS system must include details of which documents must be under control and how to control them. The various plans, reports, and other documents required by the QMS also need to be under control, as these documents prove that the QMS system has been followed. Organizations must discuss whether the QMS is to be paper-based or electronic, since both options have their advantages and disadvantages. The decision needs to be documented and the process needs to be explained in detail. The one variation that isn’t an option is to have a paper-based and signed QMS, which is used electronically from files outside of a document management system. Such files, in a word-processing or HTML format, can easily be tampered with so that they are not identical to the signed paper versions. Due to the lack of audit trail and control features, these can never be controlled documents unless they are taken care of by a document management system.

P1: OTE c04

JWBK188-Segalstad

64

4.8.1

September 15, 2008

11:12



Paper-based QMS

A paper-based QMS is distributed and used on paper. Typically, the QMS is written using a word processor and stored as a document file, but a paper version is generated and distributed. The general flow for a paper-based system is as follows: r Write and edit the document until you are satisfied with it r Send it out for review and collect comments, which will have to be incorporated or disregarded. Question to be discussed: Are all comments stored, or just the final version? r Print the document and date/sign it using a handwritten signature, according the description in the QMS. Depending on the requirements, there might be one or more signatures on the document (author/approver), but at least the document will have the signature of the person authorizing it r File the master document with original signatures in a safe place, and file outdated versions in a historic file r Distribute copies of the document according to a plan, and keep an overview of who has authorized copies. Question to be discussed: How do we handle unauthorized copies when people ‘just need a copy?’ r Distribute new versions of the document and ensure that every person on the copy list replaces the old version with the new version. Question to be discussed: Shall the old copies be handed in and accounted for, or shall the receivers be trusted to destroy old copies and replace them with the new ones? r Ensure that only a few authorized people have access to the document files. Otherwise, it is impossible to keep an overview of who has copies 4.8.2

Electronic Storage and Use of Documents

Files are created electronically these days, but it is very difficult to have controlled documents in word processing files when they are readily available in directories. If people can read the documents, they can usually also edit them and save the changes that they have made. Even if access is limited to read-only for most users, there may still be one or more people who have access to editing the document. It is well known that most word processing systems do not automatically keep track of who has changed what and when, and unauthorized editing will jeopardize the content of the document. Electronic documents are difficult to control unless they are stored in a secure Document Management System (DMS). A DMS stores all versions, there is a limit to what one can do in the system (e.g., only certain people are allowed to approve/authorize/write/ change/delete documents), and it has a complete audit trail (who/what/when/why for every entry) so that everything done to a document will be visible. A well set up DMS is ideal for the purpose of writing, reviewing, approving, and distributing controlled documents. As users can be assigned a variety of roles in the system, they will be able to do what they are allowed to in the system – and nothing more. The general workflow for an electronic system is as follows: r Write and edit the document until you are satisfied with it. The system functionality and/or audit trail will say who wrote it

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


The Quality Policy

65

r Use the DMS to send it out for review and collect comments, which will have to be incorporated or disregarded. All input can be stored, and it is also easy to compare new versions with old versions r Approve/authorize the document electronically. The audit trail also includes the time in addition to the date, as well as an electronic signature for the authorization r No old-fashioned filing: There’s no paper to file, because everything is in the DMS r No distribution of new documents: People use the electronic document and are always assured that only the current version is used. Question to be discussed in the SOP: A lot of people still like to read the text on paper and perhaps make notes. How do we handle paper printouts? One option is that every piece of paper printed out is printed with today’s date and that the document is only valid on the printing day r When a new version of the document is authorized, it automatically replaces the old version, which becomes obsolete and unavailable r A disadvantage of an electronic system is that it is inaccessible when the system or the network is down

4.9

The Quality Policy

The Quality Policy (QP) is a political statement and is meant to describe the company’s quality goals. The Quality Policy must include a commitment to reach the goal, but must not be a description of how to reach the goal. The Quality Policy provides a framework for the quality objectives. The quality objectives may cover both the quality system itself and the quality of the products. Quality objectives must be stated in such a way that when they are met, they will have a positive impact on the general quality of the products, the financial results, and customer satisfaction. The Quality Policy has value only if the content and goals are communicated in the organization and the management is committed to letting the organization work according to the policy. In some organizations, the Quality Policy is a short mission statement with big words and not much substance. In others, it runs to several pages, with more substance. Examples of quality policies are shown in Table 4.1. Some organizations have separate policies for their products, their IT systems, their security, and/or health and safety and environmental concerns. If there is a separate Quality Policy for IT systems, the following should be included, if appropriate: r Reference to the regulations and regulatory bodies that apply r How the regulatory systems are defined r Requirements for the framework for the regulatory systems r The roles and responsibilities defined for the regulatory systems r If electronic signatures are used in any regulatory system, there should be a statement that signing in such a system is legally binding in the same way as any handwritten signature is legally binding

P1: OTE c04

JWBK188-Segalstad

66

September 15, 2008

11:12



Table 4.1 Quality Policies Nycomed Pharmaceutical Company Found on their web site (www.nycomed.com) in January 2006. Mission: Our mission is to improve healthcare. We focus on Europe to get closer to the needs of people and the medical professionals that serve them. Our commitment is to be closer:

r to healthcare professionals: respect them for the work they do and value their experience with our products

r to patients: see the person behind the patient and provide the choice, quality and usability that are fundamental to healthcare

r together: to be a big company run like a small company where everyone can make a r r r r

difference to business partners: working together to make every product a success to our owners: justify the trust we receive to authorities: recognize that we have a common goal to provide medicines that fit Europe to society: understand our role in an ever changing Europe and act according to our responsibilities

LabWare Laboratory Information Management System Vendor Found on their web site (www.labware.com) in January 2006. LIMS Quality Statement Purpose: The purpose of this statement is to establish LabWare’s position regarding the compliance of LabWare LIMS with generally accepted practices for development of GXP or Validated software products. Statement: LabWare LIMS is intended for use in regulated laboratories and is consistent with the principles outlined by GLP, GALP, cGMP and ISO 9000. LabWare LIMS is designed in accordance with GAMP and ISO 9000-3 guidelines and operates in such a way that:

r r r r r r r r

allows configuration instead of programmed customizations contains internal configuration-change-control auditors all raw data modifications are audited configuration can be centrally maintained permits language and terminology translations without compiling source code supports database configuration changes without compiling source code conforms to the requirements for a ‘Closed System’ as defined by 21 CFR Part 11 GAMP 3 Guidelines define as a ‘Category 4 – Configurable Software Package’

Novo Nordisk Pharmaceutical Company Found on their web site (www.novonordkisk.com) in January 2006: ‘Novo Nordisk is committed to quality in everything we do’ – this is the foundation of Novo Nordisk Quality Policy. People in the Quality organization facilitate that this Policy is shared by everybody at Novo Nordisk, resulting in high quality products and services to patients.

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


The Quality Manual Table 4.1

67

(Continued)

Across the company, we must have an in-depth understanding of all requirements of the Health Authorities in every market. We apply the newest technologies to reach the highest standards. We implement quality in the practical work at production sites, laboratories, distribution channels and administrative units. We monitor all critical processes, preventing potential problems. Much of our work is about communication – discussing, training and planning with colleagues in all areas. Other tasks deal with documentation, review, test and control of equipment, processes and products. Our quality thinking gets broader and deeper in all parts of Novo Nordisk. This is seen in the constant improvement of technologies, work processes and measurements. We actively participate in quality sessions and training, in setting quality targets and reviewing performance. We expand the quality system from the traditional areas of development, production and distribution into functions such as human resources, marketing and finance. Most of the Novo Nordisk organization is covered by an ISO 9000 certification – setting standards for management commitment, improvement cycles, measurements and other quality systems elements. We were one of the first pharmaceutical companies to work for and obtain ISO 9000 certification – connecting our company better, making sound business and preparing us well for the future.

4.10

The Quality Manual

In most organizations, the second level from the top is the Quality Manual (QM); in some, the Quality Manual is a more detailed description of what to do, but not as detailed as the procedures; in some, the QM is the complete collection of procedures; in others, there is no separate QM at all. Provided that there is a QM, it adds detail to the policy, but it does not interfere with how things are done at the local level. The QM must, of course, comprise the whole span of work done in the organization, through the life cycle of the products and through the work processes. It does not make sense to have separate Quality Manuals or systems for nonregulatory issues if these are mandatory, such as health–environment–safety issues and financial issues. Include these issues in the same system. The QM includes the following: r definitions r guidelines for how to do projects, work processes, risk assessment, and validation, to mention a few r requirements for which SOPs must be in place; for example, for IT systems, organizational issues, and other relevant subjects The QM is also to cover requirements for the following issues for IT systems: r r r r r

the IT system life cycle, from inception through to retirement risk assessment and risk management for regulatory computerized systems roles and responsibilities how the organization around the systems shall be created and how it shall function validation

P1: OTE c04

JWBK188-Segalstad

68

r r r r

September 15, 2008

11:12



security issues electronic records and signatures requirements for which items shall be covered in SOPs for the regulatory systems maintenance activities in the IT department

4.11

Standard Operating Procedures

The Standard Operating Procedures (SOPs) have a detailed description level. It has been said that they should be written so that you could take any person from the street and that person would be able do the correct thing by following the SOP. However, this isn’t right: In order to be qualified to do anything in the industry, training is mandatory. Thus, the SOP must be written so that a trained person will know how to do the correct thing. People who experience their first QMS in the organization usually complain that they are losing their flexibility in the way they do their work. The reason is that many new quality systems include SOPs that have not been written in a good way. There is an art to writing SOPs so that work is done correctly when they are followed, while at the same time maintaining flexibility. The QMS isn’t complete without documentation to prove that it’s actually being followed. SOPs need to include requirements for how to document what has been done. For example: The SOP requires people to be trained in order to do a task. Therefore, the SOP must include a description of where and how to document training. The training records themselves will be proof that the SOP has been followed. 4.11.1

An SOP for SOPs

Any SOP system needs to have an ‘SOP for SOPs’. This might seem like a bureaucratic joke, but it is in fact quite a necessary tool in the SOP-writing process. This SOP will explain how to write SOPs in general: r What the headers and footers look like r How the SOPs shall be named and numbered, and how to keep track of which numbers have been issued and which are still being written r Which formats to use for font types and font sizes r Who shall write the SOPs, approve them, and authorize them r How often the SOPs shall be reviewed for possible renewal r Which chapters are mandatory (usually scope, responsibilities, and application) r The description of the work to be done and which roles are responsible for that work r How the SOP history shall be described r How the SOPs shall be distributed and filed, and how to handle outdated/obsolete SOPs r How appendices shall be included, and what information can be presented in the appendix 4.11.2

SOPs for IT Systems

General SOPs for regulatory IT systems can be created to cover all IT systems, regardless of the type of system, along the following lines:

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


The Art of Writing an SOP

r r r r r r r r r r r r r r

69

procurement (acquirement) of new systems backup security issues system categorization – for example, according to GAMP, as described in Chapter 5 – and what to do with validation of the different categories, including laboratory/manufacturing instrument with embedded computers risk assessment and risk management roles and responsibilities, and organization around the systems validation, qualification, and testing error handling change control configuration management training electronic records and electronic signatures requirements for SOPs for each system other subjects as needed

There will most likely be a need for more detailed SOPs for each of the IT systems. Some of the SOPs mentioned above may need to be elaborated on for this specific system: r r r r

training error handling change control configuration management

Some of the generic SOPs do not even begin to cover each particular system. Separate SOPs will definitely be needed for the following: r daily use of the system (target: end-users) r how to enter static data in the system (target: key personnel for the system) Details of each of these SOPs are described in Chapter 5.

4.12


There is an art to writing SOPs. An SOP must be written so that people reading it will be able to follow it provided that they have the required competence. This does not mean that the SOP should be written so you can take people in from the street and they will be able to do the correct thing just by following the SOP. One can assume that the readers have been trained to do the right thing. For example: An SOP explaining how to do something in the IT system requires the readers to be trained and to have access to that system. Names of individual persons must never be included in any SOP. The one exception is the signature page, where the author usually signs as such, the approver signs as such, and the QA authorizes as such. Others with responsibilities are listed with a role, which means that new people can take over the responsibilities by adding that role to their prescribed roles in the organization.

P1: OTE c04

JWBK188-Segalstad

70

September 15, 2008

11:12



The following section covers how you must write the SOP to show who is responsible for what. The first question is who shall carry out the task. 4.12.1

Name

The SOP must include information on who is responsible for doing what in the process that is described by the SOP. If the SOP states that ‘Peter shall do xxx,’ the organization is actually out of compliance when Peter isn’t there and someone else needs to take over his work. Also, if Peter leaves the company or changes responsibilities within the organization, all of the SOPs in which his name shows up will have to be revised. Conclusion 1: Never use people’s names in an SOP. 4.12.2

Title

The work to be done resides within a role. But writing ‘The lab manager shall do. . .’ is also a problem when the manager has a day off from work. If someone else does the job, the company is still out of compliance, as the SOP states that the laboratory manager will do it. If there is an appointed substitute for the laboratory manager somewhere, the company isn’t out of compliance provided that this person does the job. The problem is that there are rarely appointed stand-ins or substitutes for all of the tasks or roles in the company. If several people have a particular role, it is perfectly sound to write that a task must be done by someone in that role. For example: When a laboratory technician has completed a job in the laboratory, the result must be entered into the laboratory information system. If one technician isn’t there, another does the job in the laboratory, and thus it’s the next person’s responsibility to enter the data into the system. Conclusion 2: Never state that a task must be done by a specific person or role if there are few people who have that role. If there are many people with the same role, it is acceptable to use the name of the role. 4.12.3

Responsibility

The key word in getting the task done is responsibility. The text should say: ‘The lab manager is responsible for getting xxx done.’ Provided that you, the laboratory manager, have a trained person who can take over when you are not there yourself, the organization is still in compliance when you ask that person to do the job. Conclusion 3: State who is responsible for getting the task done. The next question is what shall be done. 4.12.4

Flowchart

If the workflow described in an SOP is complicated and includes many roles, it might be useful to start by making a flowchart that explains the workflow for how things must be done. Each box in the workflow can have a number corresponding to the numbered chapter in the SOP describing the task, so that it is easy for readers to find the information that they need. Figure 4.2 shows an example of a flowchart for change control. Please note that this isn’t the definitive flowchart for change control; it’s only an example that is used by one company.

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12



5.1 Initializing change

Notification

71

5.1 Receipt of Change request

No

5.2 Change Assessment Yes

5.2.1 Minor

5.2.2 Major

5.2.1 Change approval

5.2.2 Change approval

6 Change Implementation

6 Change implementation

6.1 Change Documentation Legend Documentation Workflow 6.1 Filing

Figure 4.2

Change control.

Others may have different approaches that are more suitable for their organization’s way of working.

4.12.5

What to Do

The most common objection to SOPs and quality systems is that they restrict the freedom to decide how to do things. But what a good SOP actually does is to restrict the freedom to make mistakes. What to do must be described with great care, so that it accurately describes the task without being too restrictive. The SOP must be written so that it doesn’t include restrictive details wherever that isn’t necessary. For example, if the SOP covers data entry in an IT system, it must not tell you to use the second menu to the left, go down

P1: OTE c04

JWBK188-Segalstad

72

September 15, 2008

11:12



three steps, and choose the item there, and then go down one step to get to the correct screen. As qualified and trained employees using the system, the users must know their way through it, whether they prefer to use the menu road or a shortcut to get there. If you include the system manual in the SOP, you are certain to face a lot of work in updating the SOP whenever a new version of the system adds different menus or commands. Instead, include the ‘how-to-get-there’ instructions for the help function in the system or include the manuals separately; do not include that information in the SOP itself. The SOP must, however, include information on which data must be entered where in the system. It is difficult to compare data, to trend data, or to create reports that automatically pick up all variations if the same data is entered in different places in the system. If the SOP states exactly where data of a particular kind must be entered, it is much easier to enter the same types of data in the same places. Sometimes, it is also important to specify the data format. I once implemented a Laboratory Information Management System (LIMS) in an organization where everyone worked in project groups. It very quickly became apparent that each group had developed its own culture of how to do things. We found 12 different ways of writing the measure unit weight/weight percent. This included ‘w/w%,’ ‘%w/w,’ and ‘% W/W, which meant that they included ‘%’ before or after the other letters, and that they placed a blank space between the ‘%’ and the ‘w,’ or between the ‘w’ and ‘W,’ in various combinations. We had to change 11 of these variations and let the twelfth be the standard. While people, of course, are able to understand that these 12 variations mean the same thing, computer systems are not. Eleven groups of people thought that the LIMS was a stupid system, since it could not accept their way of writing the units. Conclusion 4: Include what data must be entered where in the system and also the type of format, if applicable. Don’t include how to do it. 4.12.6

Documentation

The SOP must also include requirements for how to document what has been done. To cite an FDA inspector: ‘There is one thing worse than not having SOPs, and that is to have one and not use it.’ And to cite another FDA inspector: ‘If it ain’t documented, it is a rumor.’ As I did not hear them say so myself, even the citations may be rumors, but at least the comments are valid: You can’t prove that you’ve followed the SOP unless you can document that you’ve done so. Always ensure that you keep the documentation. A lot of data is documented by the fact that it is now in the computer system. But some data needs to be documented separately. One example is when a user needs new or changed access to a computer system. Technically, this is done by a key system person who knows how to provide that access in the system. But that person is rarely the one to permit the user this access: Permission is usually given by the user’s manager. The company will need to have documentation to prove that this user is granted a certain access to the system, as well as documentation that the person has technically been given such access. This documentation must be archived for the same period of time as the rest of the data. The length of time is usually determined in the GxP, or in other external or internal requirements. Conclusion 5: Include requirements for how to document that the work has been done, and create a file for this documentation.

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


References

4.13 4.13.1

73

Tasks Write a Procedure for Making a Peanut Butter-and-Jelly Sandwich

This sandwich has two layers of bread with peanut butter and jelly/jam between. Ask another person to follow the description exactly, and check if the result is what you expected. 4.13.2

Roles

Interview three people who work side-by-side in the organization to find out what they do, both every day and once in a while. They are likely to have some common tasks and some unique tasks. Make lists of key words from their answers, and create roles from that list. Assign roles to each of the people. 4.13.3

Create an SOP for SOPs

Create an SOP for SOPs using the guidelines described in this chapter. Include a flowchart for the SOP process. In a separate document, describe the roles that you use in the SOP. 4.13.4

The Change Control Flowchart

Look at the change control flowchart: r Can this be used for any changes in the company; for example, in the manufacturing process, the QMS system, the laboratory analyses, or the IT systems? r Will you need to have additional or different change control procedures for any of these? r In that case: What makes it necessary to have specific change control for some categories of change? 4.13.5

How Can QA and Management Benefit from a Quality System?

Explain how the quality assurance group and the management in a company can benefit from a QA system. These two groups may have differing needs.

References 1. ISO 8402-1989 (1989) Quality Terminology, International Organization for Standardization, Geneva, Switzerland (this standard has been withdrawn). 2. ISO 9000:2005 (2005) Quality Management Systems – Fundamentals and Vocabulary, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 3. US FDA (2006) Glossary, US Food and Drug Administration, Rockville, MD, www.fda.gov. 4. ISO 9001:2000 (2000) Quality Management Systems – Requirements, International Organization for Standardization, Geneva, Switzerland, www.iso.org.

P1: OTE c04

JWBK188-Segalstad

September 15, 2008

11:12


P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9


5 IT Integrated in the QMS in the User Organization

This chapter discusses the following: r How to integrate IT systems in the user organization’s QMS r Generic procedures for IT systems r Procedures for each system

5.1

Introduction

It is easy to handle and validate production processes, autoclaves, and laboratory analytical methods; after all, that’s what we were trained in when we got our degree. We understand these issues. In most organizations, IT is a tool used by many people. It is common to think that handling IT systems and validating IT systems are difficult, because we don’t understand the underlying programming of IT systems. This isn’t quite true. IT systems help do things electronically that used to be done manually in the old days. It isn’t necessary to understand programming in order to use these systems. It’s equivalent to driving a car without understanding what all the parts do inside the engine or knowing how to fix problems. Sure, it does help to know that the reason for a high temperature may be that there isn’t enough coolant in the radiator, or that if the car seems to want to go left all the time it might be because there’s little air in the left front tire. But it is possible to run the car without knowing that, just as it’s possible to run a computer system without knowing about the bits and bytes. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c05

JWBK188-Segalstad

76

September 15, 2008

13:9


IT Integrated in the QMS in the User Organization

People with a background in production understand what the production system does: It controls production and collects production measurements. Equally, people with a laboratory background understand what the laboratory system does: It keeps track of instruments, collects results, compares the results with specifications, and says whether or not everything is satisfactory. It isn’t necessary to understand how the system is programmed with tables and fields to store the data, or how it compares data with other data. IT systems are integrated in almost everything that is done in a company. However, IT systems need to be handled somewhat differently, as they are very stupid and have no imagination. A person can easily see that the measurement unit ‘% w/w’ is the same as the measurement unit ‘w/w%.’ The systems themselves don’t understand that at all.

5.2

How to Integrate IT Systems in the QMS

In today’s organization, IT systems are nothing special. They are integrated in almost everything we do, and should therefore also be integrated in the quality system. This is especially true where the IT systems are an integrated part of the workflow. Typically, organizations have made a big fuss about IT systems when people began to realize that the systems needed to be under a certain amount of control, because they were important in the work that was being done. When 21 CFR Part 11 [1] was due to be implemented in quality systems, there were typically a lot of procedures created for how to comply with Part 11. Today, most of the content of these procedures should be an integral part of other procedures. For example: Part 11 has several technical requirements for IT systems. The response within organizations was to create a list of the technical requirements and to add this as an appendix to the User Requirements Specification (URS) when sending the URS to potential suppliers. We can see now that it makes more sense to include the requirements in the URS, but the requirements may be given a reference to Part 11 – if desired. Another example is change control. Companies have change control procedures for aspects of the work done, but these do not always fit the purpose for IT systems. A separate change control procedure is drawn up for IT systems in general, and perhaps even other separate procedures for each system. Could the generic change control procedure be edited, perhaps, so that it also covers the IT systems? There will be a need for procedures that are specifically tailored to IT systems. These are divided into generic procedures that cover all systems, and system-specific procedures that handle each system in detail. This chapter covers the elements that need to be included in the procedures, but it is up to each organization to determine how to include them. The suggestions below must be tailored to your organization’s way of working. Items have to be added or changed, and the sequence will vary. It may also be necessary to have several SOPs for each item; for example, one SOP on configuration management for hardware and one for software, and maybe also one for a specific system. Validation is also a very big SOP, and it may be necessary to divide it into one overview SOP and several detailed SOPs for each qualification. The solution might be to include some of the items in existing procedures, have generic procedures for all systems, or have separate procedures for each system. Again, it depends . . .

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9


Generic Standard Operating Procedures

77

Some SOPs are closely linked to each other and should refer to each other. One example is the error handling, change control, validation, and configuration management SOPs. Another example would be the access, security, and training SOPs. SOPs include requirements for what to do, how to do it, and how to document what has been done. While the regulations say that things must be documented, they rarely say how that documentation is to be prepared. Documentation can take the form of manual entries in a logbook or records in a computerized logging system. A book is available in only one place at a time, but it is available even when the network or the systems are down. A computerized system may be available to several people at the same time, but it isn’t available at all when the network or the system isn’t working. It’s your choice, but don’t use both alternatives at the same time, as people won’t keep both updated. If you want both, this may be solved by having the computerized system print out the electronically stored log, for information only.

5.3


The Standard Operating Procedures (SOPs) are listed alphabetically according to content. 5.3.1

Backup and Recovery

Backup is necessary in case data is lost, but it has no value unless we know that the right data has been backed up and that we can restore it to the system. Data is most often backed up to tape, which can easily be stored in a different location. As tapes are relatively expensive, it is common to reuse the tapes after a period. There may be computerized systems that are not networked in the organization. These often include computers that control instruments in the laboratory. The backup of these computers is usually infrequent and outside of control. The data is often backed up to a CD or DVD, which is thrown in the drawer underneath the computer, and is poorly marked. Such systems must be networked and data must be stored on the server instead of on the local computer. Only that will ensure a good backup of important data. There are several different types of backup software available. The chosen one needs to be configured to fit the backup procedure. It is also important to have change control to make sure that new computerized systems and their data are included in the backup schedule and the configuration of the backup software. Backup is only useful if it is possible to restore the data that has been backed up. This has to be tested, and the testing must be documented. A new test has to be carried out at least every time there is a change in system versions. It is necessary to store backup outside the premises where the servers in question are located; a backup tape stored in the same place as the system has no value if there is a fire. The system for backing up data varies, and one way of doing this is described here. Other solutions may work better in your organization. Daily backup is done on between five and seven days a week, and covers data that has been changed since the last backup. This could either be since the last daily backup or since the last weekly backup. One tape or set of tapes is used for each day and reused the next week.

P1: OTE c05

JWBK188-Segalstad

78

September 15, 2008

13:9



Weekly backup is done once a week and can replace the daily backup that day. It covers all data in the system, whether or not the data has been changed during the past week. There are four sets of backup tapes, one for each week of the month. The use of these is ‘rolled’ every month; that is, they are reused the next month in the same sequence. Monthly backup is done every month and covers both data and system files. There are 11 or 12 sets of backup tapes, one for each month. These are rolled every year. If new system versions have been added, the ‘monthly’ backup should be done even between the schedules for monthly backups. Yearly backup is done once a year. The backup is placed on a monthly tape that is stored instead of being included in the rolling set of tapes. This system will ensure that all data is backed up: the last monthly tape will include the programs, the last weekly tape will include all the data for that week, and each of the daily backups will add data that has been changed since the last weekly backup. Include in the SOP: r When shall backup be performed? r What shall be backed up? r If there are different types of backup, when shall each be done? r How shall backup be done? r How shall backup media be handled? r Who is responsible? r How shall backup be documented? r How shall backup be tested and how shall the testing be documented? And how often?

5.3.2

Categorization of Systems

References for more information: r GAMP 4 [2] and GAMP 5 [3] describe categories r The GAMP guide for validation of computerized laboratory systems [4] describes more categories in finer detail There are large differences between operating systems, databases, office systems, and configurable systems. Some are widely used, while others are not so common. Some are used for GxP data and others are not. It can be difficult to assess how to handle each of these. The categorization, together with the risk assessment, will help determine the validation approach for each particular system. The risk assessment SOP is described separately. Systems may be categorized according to GAMP, or according to your organization’s own categorization. Your organization is free to create its own categories. The important issue is which categories exist and how each of them is to be handled. GAMP 5 Appendix M4 defines five categories: 1. Infrastructure software: Layered software and software used to manage the operating environment. For example: Operating systems, database managers, and others; but not the applications developed using these packages. 2. This category is no longer in use.

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



79

3. Non-configured products: Off-the-shelf products used for business purposes. Included both systems that cannot be configured and systems that use default configuration. 4. Configured products: Products configured to meet the business processes, for example: LIMS, SCADA, MRP BMS and others. 5. Custom applications: Software designed and coded to suit the business process. The validation approach for each category is suggested in the same GAMP appendix. The GAMP laboratory guide has seven categories of systems, labeled A–G. This may be a bit too many for your liking, but it can help you to define your own categories. Include in the SOP: r Which categories exist? r What characterizes each category? r How do we determine which category the system belongs to? r Which validation activities shall be carried out for each category? Alternatively, make a reference to a validation SOP in which this is described r Refer to the SOPs for validation and risk management

5.3.3

Change Management

A validated system is validated only until the first uncontrolled change has been made. Change control/change management assures that the changes are controlled and well documented. Changes may be the result of errors, or may start as requests for change from various sources. The change control process can be explained in a flowchart. One example is shown in Figure 5.1. This needs to be adjusted to cover each organization’s change management process. Each of the boxes in the flowchart must be explained with ‘who,’ ‘what,’ and ‘how,’ and the documentation requirements. It might be useful to number the boxes in the flowchart and use the numbers as references to the tasks described in the text. Another example of a change control workflow is shown in Figure 4.2.

Change Request Information to requestor

Assessment

No

Yes Change No Test OK?

Figure 5.1

Yes

Document

Change Control.

P1: OTE c05

JWBK188-Segalstad

80

September 15, 2008

13:9



Determine whether a new software or hardware installation will have an impact on the production application(s) running on the current platform and document the decision in the log (see also Section 5.3.4). If there is an impact, include a risk assessment, which is described in Chapter 12. Include in the SOP: r Refer to the error SOP for changes that are initiated by an error r Who can suggest a change and how is this done? r Who shall receive the change request? r How shall it be documented and by whom? r How shall the change request be assessed and by whom? r Impact must be addressed before a change is made. How shall this be done? r What happens if the change request is turned down? Can the requester get a second opinion from somebody? r Depending on the assessment, how shall the change be handled? r How shall the change be documented? r Refer to the SOP for validation/qualification for changes that require testing r Refer to the SOP for configuration for changes that will change the configuration

5.3.4

Configuration Management

Configuration is defined in GAMP 4 as ‘The documented physical or functional characteristics of a particular item or system. A change converts one configuration into a new one.’ This includes hardware as well as software. It is common to include all the layers of software used for a computer system; that is, the operating system, database, application, network, and so on. Hardware includes servers, clients, printers, and the physical network, to mention a few. The organization needs to map all these and to keep the map updated at any given time. This is called configuration management. There are software tools to help with this, but the SOP should explain how to keep the information updated. Changes in configuration are usually a result of change management. The configuration will usually be in two SOPs: one for the external configuration of the system (hardware servers and clients, the operating system, databases, and system versions) and one for the internal configuration of each specific system (the data in the system). The latter are explained below, in the sections about system-specific SOPs. The organization must define what is to be subject to configuration management. At the very least, all GxP systems need to be included, but it might be easier to include all systems than to define which ones can be exempted. There are probably several borderline systems that handle both GxP and non-GxP, and non-GxP systems may eventually also include GxP data. Include in the SOP: r Are both GxP systems and non-GxP systems to be included in configuration management? If not, how are the borders between them to be defined? r How shall configuration management be handled? r Who can change the configuration?

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



81

r How shall it be documented? r Reference to the change control SOP r Reference to the validation SOP 5.3.5

Decommissioning – Retirement

Decommissioning is the same as retirement. Both software and hardware will eventually be retired, but data will usually have to be available even after retirement. The decommissioning needs to be done in a structured way, to ensure that applications data can be taken care of, or thoroughly deleted in the case of disks and storage media. Include in the SOP: r How are hard disks, backup tapes, and other media destroyed to avoid it being possible to read them? r How is the decision to retire a computer system made? r What alternatives exist? r Will the current system be replaced with other systems? r What shall be done with hardware, software, data, and documentation? r How can data be taken care of after the system has been retired? r Access control to a retired system may still be an issue 5.3.6

Disaster Recovery and Business Continuity

Disaster recovery and business continuity are two aspects of the same issue. The objective of disaster recovery is to get systems back into an operative state; this is normally the responsibility of the IT group. Business continuity involves how to work until the systems are running again; this is more often the responsibility of the key people for the specific system or the department managers for the users where the system is being used. The SOP may have to be divided into one SOP for disaster recovery and one SOP for business continuity for each of the applications, as they have very different target audiences. Disasters include ‘minor problems’ such as disks or servers that don’t work, or network problems. These are usually quickly fixed by repair or the purchase of new hardware. Disasters also include major events such as fire, flooding, longer periods of power outage, and other happenings that take a longer time to fix. These are sometimes totally out of the organization’s control. It is obvious that any organization will need Uninterrupted Power Systems (UPS) to make sure that it can close its systems down in a controlled way when the power fails. Normally, UPS do not have the capacity to replace the normal electric power supply requirements for protracted periods, so additional generators, based on other fuels that can be stored, will also be needed. The business continuity plan will depend on how long the systems are likely to be down. The plan should reflect various scenarios. For a relatively short period, the best solution might be to take a break, go home, or do other things. For a longer period, when that isn’t an acceptable solution, it will be necessary to work in a different way to get the job done. It may even be necessary to revert to paper-based work instead of electronic work. It is only possible to do this if there are detailed plans for how it shall be done. How is the border between the shorter period and the longer period defined? How shall the business continuity

P1: OTE c05

JWBK188-Segalstad

82

September 15, 2008

13:9



plan be invoked and by whom? The next question is how the paper documentation is to be handled when the system is running again. Should that data remain outside the system? Should it be entered later, together with a reference to the original paper record, which must then be archived as raw data? The plans must be tested to see if they work, and the testing must also be documented. It’s too late to find out that the scheme doesn’t work after disaster has struck. Include in the SOP: Disasters: r Definitions of disasters r Disaster recovery plans for various types of disaster and different systems. These could be included in the SOP or referenced to a separate plan r How and when is the disaster recovery plan to be invoked? r How shall the plan be tested and how shall the completed testing be documented? Business continuity: r Business continuity plans for various problems r How and when should the business continuity plan be invoked? r How shall the plan be tested and how shall the completed testing be documented? 5.3.7


Electronic signatures may have their own SOP, explaining the circumstances in which they can be used in computer systems. People who are to sign electronically must first sign a paper where they state that they understand that electronic signatures are legally binding, just as handwritten signatures are. This is a requirement in 21 CFR Part 11. This document shall be archived with the employee’s file in the Human Resources (HR) department. Include in the SOP: r All persons are to sign on paper to the effect that they understand that electronic signatures are legally binding r Where shall this be archived? r The document to be signed can be included in the SOP

5.3.8

Environmental Conditions

Ensure that the location selected for the installation of the hardware is suitable with regard to environmental conditions, power conditions, and security. If renovation work is required, schedule the work according to company procedures and ensure that it is completed prior to the installation of equipment. Schedule hardware installation for a time subsequent to verification that the location is suitable, and that renovation has been completed, if needed. Consider the impact on operational aspects if the installation is to be carried out on existing hardware. Include in the SOP: r Security and access to premises, provided that this isn’t covered in a security SOP r Environmental control and monitoring, including documentation r How out-of-spec values for environmental monitoring shall be handled and documented

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



5.3.9

83

Error Handling

Errors are inevitable, but they originate in different ways and therefore have different solutions: r User errors happen because people don’t know how to use the system. They discover what they think is a system error, but investigation will show that the user has done something wrong, or hasn’t understood how the system works. The solution is explanation or training r Operating systems and databases may have errors, which will show up in the application. The solution is most likely to report this to the supplier of the application, if it hasn’t already been reported on the web site. There might be a need for a patch or a work-around to get this fixed r The application may have errors, which result in unexpected features in the system. The solution is most likely to report this to the supplier of the application, if it hasn’t already been reported on the web site. There might be a need for a patch or a work-around to get this fixed r There may be errors in the system’s static data that cause problems for the dynamic data. The solution is to change the static data A reported error needs to be assessed to determine the error type; this also includes assessing the seriousness and the impact of the error. The error may have to be reported to the supplier, to key people, or to all users. Sometimes a work-around will have to be created until the error has been fixed. If the error will create a change, this must be handled according to the change control procedure. Include a reference to that procedure. Error handling can be a generic SOP, but there may also be a need for system-specific error-handling SOPs. Corrective Action – Preventive Action As a preventive action naturally follows a corrective action, the term Corrective Action – Preventive Action is often referred to as CAPA Corrective action is the same as correcting errors. ISO 9001 [5] defines this as ‘Action to eliminate the cause of a detected nonconformity or other undesirable situations.’ The next step in error handling is to assure that it does not happen again. This is called preventive action: ISO 9001 defines this as ‘Action to eliminate the cause of a potential nonconformity or other desirable potential situation.’ Examples of CAPA: Problem: Correction: Corrective action: Preventive action: Problem: Correction: Corrective action: Preventive action:

Include in the SOP:

Backup did not work due to use of old and worn tapes. Use another tape and make a new backup. Replace tape and use this from now on. Include in the SOP that tapes need to be replaced every × time period. LIMS did not spec check the batch. Manually ask LIMS to spec check the batch. Connect the appropriate spec with the sample/batch type in the static data. Include in the SOP that static data shall be qualified before use.

P1: OTE c05

JWBK188-Segalstad

84

September 15, 2008

13:9



r r r r

Who can report an error and how is this done? Who shall receive the error report? How shall it be documented and by whom? How shall the error be assessed and by whom? Describe the characterization of seriousness, impact, and other factors. Don’t include details or types of errors that will make the SOP difficult to use if previously unknown errors are found r How shall the error be handled? This depends on the assessment r Refer to the SOP for change control if changes are needed r What preventive actions are needed to avoid the error being repeated? 5.3.10

Glossary

People working with IT systems have their own language. The same words are defined differently in some standards, and different words are defined in the same way in others. It is important that each organization has the same understanding of the words. It can be useful to create one SOP for the glossary, rather than having parts of the glossary in each SOP. The glossary included in this book as Appendix 2 can be a start for your own, but you are free to define the expressions differently. Include in the SOP: r The word or expression, the definition, and where the definition originates, if possible 5.3.11

IT System Organization for the System Project and the System Live Phases

Reference for more information: r Organization around IT systems is described in Chapter 7 Include in the SOP for the project phase: r r r r r

What background should the project leader have? User/IT/professional project leader? How many project members are needed? What background do they need? Who shall be the sponsor/owner group? How do we accomplish Quality Assurance? What are the responsibilities for each of the people/groups in the project? Include in the SOP for the live phase:

r r r r r

What background should the system manager/application manager have? User/IT? How many key people/super-users are needed? What background do they need? Who shall be the sponsor/system owner group? How do we accomplish Quality Assurance? What are the responsibilities for each of the people/groups in the system’s live phase?

5.3.12

Procurement – The Process for Acquiring a Computer System

References for more information: r The project group is described in Chapter 7 r The project plan is described in Chapter 11 r The URS, and the assessment of answers to the URS, are described in Chapter 13

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



85

In order to get the right system for your needs, you must complete a procurement process in a structured way. Include the following in the SOP: r Somebody sees a need for a new system. Who shall the suggestion for a new system be sent to? r Who assesses the need for a feasibility study? r Who assesses budgets, and/or includes the cost in new budgets? r Who approves the suggestion and gives the project the go-ahead? r Who assigns the project leader and the project group? r Who shall be included in the project group? Normally this consists of future users, and maybe also people from IT. The project’s QA contact person shall also be assigned (refer to the SOP for IT organization) r Who assigns the sponsor/owner group for the project/system? r Who shall be included in the owner group? What are their responsibilities? r The project leader shall create a project plan, but who shall approve the plan? r The project group shall create a feasibility study, but who shall approve the study? r The project group creates a URS. There might be an SOP or a template for the URS. If not, the procurement procedure needs to include the basic requirements for the URS. This includes all of the technical requirements in 21 CFR Part 11, in addition to the organization’s functional requirements for the system r How are suppliers preselected? What is the selection based on? Preselection may be based on answers to a letter, with a few major requirements for particular modules or other specifications. It may also include reference checks, site visits to other users, or demonstrations of the system r What shall be included in a Request for Proposal (RFP)? In larger companies, the purchasing department usually has some standard RFP or covering letters that can accompany the URS r How are the answers from the suppliers to be assessed? How are systems to be ranked based on those answers? r If supplier audit is a factor in the decision to buy this system, audit the highest ranked supplier first. Refer to the SOP for supplier audit r If the audit result is bad, audit the next supplier on the list r Select the system based on the answers and the audit results. What should you do if supplier 1 has a good system but poor quality, while supplier 2 has a not-so-good system but good quality? r The contract between the vendor and the organization involves the purchasing department

5.3.13

Risk Assessment and Risk Management

References for more information: r Risk assessment and risk management are described in Chapter 12 r GAMP has more information on risk assessment and risk management r ICH Q9 [6] has more information on risk assessment and risk management

P1: OTE c05

JWBK188-Segalstad

86

September 15, 2008

13:9



Risk assessment and risk management are important parts of the GMP [7, 8], in 21 CFR Part 11, and in PIC/S 011-3 [9], all of which require a risk-based approach. Include in the SOP: r r r r

Which standards shall be used for risk assessment? Which systems shall be assessed? When in various processes (procurement/validation) shall systems be assessed? People need appropriate training to carry out the risk assessment, but what is appropriate training? r How shall risks be managed? r How and when shall reassessment be done? 5.3.14

Security and User Access

References for more information: r IT security (external to a system) is described in Chapter 3 r system security (internal to a system) is described in Chapter 2 and Chapter 18 Security includes both physical security and logical security. This may call for two or more different SOPs. Physical security includes access to buildings, areas in buildings, or special rooms such as the server room. The logical security includes access to operating systems, databases, files, and each system. For each item, include in the SOP: r Who shall have access? r Which prerequisites shall be in place for giving access? Training may be one of them. Refer to the SOP for training r Who shall give access? r How often shall access be reassessed? r How can withdrawal of access be secured, so that no one has access for longer than they need it? r Who is entitled to have remote entry to the systems? r How is remote entry secured so that only approved users can access the systems? r How are passwords managed? What should they include in terms of number of characters, upper/lower case, or numbers and special characters? What should the change frequency be? How should they be reset? r How are the systems protected against viruses? How is the virus protection updated? r How are the systems protected against hackers? 5.3.15

Service Level Agreements

Reference for more information: r Service level agreements are described in Chapter 2 Whether suppliers are internal or external to the company, it is wise to create a formal Service Level Agreement (SLA) in order to know who is responsible for what.

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



87

Include in the SOP: r In which cases are SLAs needed? r The role of the customer: system owner, system manager, super-user, or end-user r The role of the supplier: the roles depend on what is covered in the SLA r What shall an SLA cover? r Which mandatory deliverables are included? r Who is responsible for what? Base this on the defined roles r How shall change management of the SLA be carried out? r How shall the SLA be announced in the organization? r How shall the SLA be archived? 5.3.16

The System Description and Log

Requests for new hardware/applications should include a system description. This needs to be established when a new item is being planned (system description), and kept updated during the life of the item (log). Tools used for electronic logs should be validated. Include in the SOP: The system description shall include: r the hardware/program/application name r the system owner r the system/application/platform supplier r a short description of the application and its purpose r the required platform environment, including operating systems, database requirements, and third-party tools r the license conditions r the interface with other programs, applications, or devices r identification of the sites that will use the application, including the usage pattern r the statement of GxP relevance In addition, the following information could be included: r r r r r

the project name/project sponsor access rights for personnel training requirements key personnel for all involved parties the requested installation date

Establish a log for each new hardware and software item installed. The log should contain information that includes, but is not limited to, the following: r The initial baseline configuration, including a description of the components (supplier, part #, serial #, etc.) – all hardware components should be identified and consistent information maintained for each r the date of installation r Installation information and Operational Qualification test results r preventive and corrective maintenance information r backup, archive, and restore operations

P1: OTE c05

JWBK188-Segalstad

88

September 15, 2008

13:9



r the impact on the application and the need for validation r all decisions regarding the platform and changes to the platform r New baseline The system description will become harder to read when several changes have been made, and there may also have been changes that have not been thoroughly documented. The SOP should include a requirement for how often system descriptions need to be checked. During this, a new baseline can be created. The baseline is defined as a new, updated system description. 5.3.17

Training

Organizations should have SOPs describing requirements for and documentation of the training that employees need to have. This could also include training in the use of IT systems, but the description is basically that people need to undergo training before being given access to the system. How much training each user needs may have to be described for each system. Include in the generic SOP for training: r Users need to be trained according to system-specific SOPs before being given access to a system r Users may need to be retrained when their need for access is changed r Refer to the SOPs for system-specific training 5.3.18

The Validation and Qualification of IT Systems

References for more information: r Validation is described in Chapters 11–16 r The expressions are explained in these chapters, and also in Appendix 2 The reason for validation and qualification is well known. Qualification of infrastructure is also to be included in the SOP. This SOP may have to be divided into several SOPs for validation/IQ/OQ/PQ/testing, depending on the level of detail as well as the size of the SOPs. Include in the SOP: r How your organization divides validation into different phases. These may involve DQ/IQ/OQ/PQ or any other division r Define each phase with requirements for input to the phase, what is done during the phase, and the output of the phase/how the phase is defined as finalized r Include information on which documents shall be created during the phase as well as the content of these documents. It may be useful to create templates for the various documents r Describe who is responsible for which activities, including writing, approvals/ authorizations, and how the documents shall be archived (electronic in a document management system/printed out and stored in archiving cabinets) r List the requirements for test plans, testing, and how tests shall be documented

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9


Procedures for Each System

5.3.19

89

Supplier Audit

Reference for more information: r Supplier audit is described in Chapter 10 A supplier audit may be required for GxP systems, but your organization can determine criteria for inclusion and exclusion based on risks. Include in the SOP: r Which types of systems need a supplier audit before they are purchased? Usually this will be GxP systems, but the SOP can describe details based on risk (refer to the risk SOP), categories (refer to the system category SOP), the importance of the system, and the number of users or departments to use the system, to mention a few r Which standard(s) shall be used for the audit? r The audit process: How to inform the supplier that the auditors will visit, how to set a date, and how to carry out the audit r Who shall be in the audit team? r A checklist based on standard(s) can be included in the SOP. Otherwise: How to create a checklist r The audit report: How to write, what to include, the definition of major/minor deficiencies, and how to distribute the report r Expected supplier actions. How to communicate this to the supplier; how to follow up r Under what circumstances does a reaudit take place?

5.4


The SOPs are listed alphabetically according to content. 5.4.1

Access Control and Security Issues

Basically, this SOP contains the same information as the security and user access SOP described in the generic SOPs section. The system-specific SOP is more detailed. It can be defined in a system that users have access to some, but not all, of the functionality. Data can be divided into data groups, which makes it possible to let some users see/enter/edit some data while other users have access to other data. The data groups are based on organizational divisions such as departments, by projects or products, or by other natural divisions in the organization. This is described further in Chapter 18. It should never be possible for users to have access to the system through the ‘back door,’ directly to the database or system files. Unfortunately, this is possible in several systems. Validation should test the back door access, and if that access exists, the SOP must set out who can do what. Preferably, no one should have any access through the back door. If this isn’t possible, access should be given on an extremely strict, need-to-have, basis. An absence of back-door access is called ‘referential integrity.’ A user needs new or changed access to a computer system. Technically, this is done by a key system person who knows how to provide that access in the system. But that person is rarely the person to say that the user can have this access. This permission is given by the

P1: OTE c05

JWBK188-Segalstad

90

September 15, 2008

13:9



user’s manager. The company will need to have documentation to prove that the particular user is granted a certain access to the system, as well as documentation that the person has technically been given such access. This documentation must be archived for the same period of time as the rest of the data. The length of time is usually determined in the GxP, or by other external or internal requirements. Access control is closely linked to training. All users are to be trained before being given access to the system. You may choose to combine the training and access SOPs. Include in the SOP: r Who shall have access? r What prerequisites shall be in place for giving access? Training may be one of them. Refer to the SOP for training r Who shall give access? r How often shall access be reassessed? r How can withdrawal of access be secured, so that no one has access for longer than is needed? r Who can have remote entry to the system? r How is remote entry secured so that only approved users can access the systems? r How are passwords managed? What shall they include in terms of number of characters, upper/lower case, or numbers and special characters?? Change frequency? How are they reset? r Describe access given based on functionality to the various roles r Describe access given to data groups based on how you divide this access r If there is no referential integrity, the access through the back door must be described thoroughly

5.4.2

Change Management

There might also be a need for a detailed change management procedure for the system. This can describe which changes are ‘normal’ and do not need to follow the procedure listed. The others need to follow the SOP. The change management for each system follows the same process as described in the generic SOP for change management. Include in the SOP: r Refer to the error SOP for changes that are initiated in error r Who can suggest a change and how is this done? r Who shall receive the change request? r How shall it be documented and by whom? r How shall the change request be assessed and by whom? r Before a change is made, the impact must be addressed. How shall this be done? r What happens if the change request is turned down? Can the requester get a second opinion from somebody? r Depending on the assessment, how shall the change be handled? r How shall the change be documented? r Refer to the SOP for validation/qualification for changes that require testing r Refer to the SOP for configuration for changes that will change the configuration

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



5.4.3

91

Configuration Management for Data in the System

The system-specific SOP for configuration management covers the internal configuration of data in the system. Include in the SOP: r Which static data/template data need to be under configuration management? Which does not? r Which dynamic data/daily-use data need to be under configuration management, if any? r How shall configuration management be carried out? r Who can change the configuration? r How shall it be documented?

5.4.4

Decommissioning – Retirement

Check whether the generic decommissioning SOP covers systems like yours. If not, you need to create one for your system, even if you are just about to begin using the system. Simply state the following: ‘When the system is ready for retirement, plans must be made for its decommissioning and for how to preserve the data in the system. If a new system is to replace the current system, the process must follow the current procurement SOP.’

5.4.5

Daily Use

How to use the system during normal use may be divided into several SOPs for different user groups, different products, or different parts of the organization, as appropriate. Include in the SOP: r What this SOP covers and potential reference to other similar SOPs r What information shall be entered where in the system. Include mandatory and optional entries, workflow, or whatever is appropriate for your choice of coverage of the SOP r Do not include how things are to be done, as the users will have been trained

5.4.6

Error Handling

Error handling is a generic SOP, but there may also be a need for a system-specific errorhandling SOP. This SOP will cover how errors in this system are to be handled. The SOP should not list the errors that may happen; there will always be some new ones. Focus instead on how errors in the system should be handled and who is responsible for doing what. For example, first-line handling may be done by the super-users; the next level will be the application manager. The latter is the person who should contact the supplier, if needed. Include in the SOP: r Who can report an error and how is this done? r Who shall receive the error report? r How shall it be documented and by whom?

P1: OTE c05

JWBK188-Segalstad

92

September 15, 2008

13:9



r How shall the error be assessed, and by whom? Describe the characterization of seriousness, impact, and other factors. Do not include details or types of errors that will make the SOP difficult to use if previously unknown errors are found r How shall the error be handled? This depends on the assessment r Refer to the SOP for change control if changes are needed r What preventive actions are needed to avoid the error being repeated? 5.4.7

Instances

Production instances of the system must be segregated from test and development instances, to ensure that the development and test operations do not impact the operation of the live system. Instances used for formal testing or development must be segregated from instances used for, for example, informal testing or training. It is recommended to have a minimum of three different instances of the system: 1. The ‘sandbox’ instance (‘play’ system), to do informal testing and create the necessary scripts. 2. The formal ‘test’ instance, where controlled testing (qualification/validation) is performed. 3. The ‘live’ production system, where the application will be running when released as fit for use. Additionally, there may be a fourth instance that is used for training. If this doesn’t exist, the sandbox system is recommended for this purpose. The ‘sandbox’ instance is uncontrolled and you can play with it as much as you like. The sandbox is a test system to perform informal testing, with the purpose of gaining knowledge about the software. This process can’t substitute for a validation. Upgrading of the system and the creation of static data may be played with in the sandbox before being moved to the test instance for formal validation, and then to the live instance for daily use. Dynamic data may be copied from live instance to the others, in order to have data that can be used for informal testing or formal validation. Often, the sandbox instance is totally uncontrolled; the other two have controlled systems and data. The ‘test’ instance and the ‘live’ instance are both controlled instances that need to be managed under change control. The controlled data in the test is validation/qualification data. The controlled data in the live instance is the live, real data. Additionally, there may also be a training instance where the system is controlled, and data is cleaned, cleared, or added whenever it gets too cluttered or too outdated. You can organize your instances as you want to, but make sure that you have control where it matters. Include in the SOP: r How are the instances defined? r Which servers are used? r How are they controlled? r How are the system and data controlled for each of them? r Who can access each of them? r How can data be moved from one to the other?

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9



5.4.8

93

Long-Term Archiving of Data (External to the System) – And Retrieval of this Data

There is a very big difference between backup and archiving. Backup media are usually reused, so that data is eventually overwritten. This isn’t ideal if data is to be archived. The purpose of archiving is to remove data from the system for long-term storage outside of the system. For this purpose, the media must not be overwritten. This SOP should be written even if you have no plans for this type of storage. Simply state: ‘This SOP covers all instances of the xxx application that contain validation/qualification data and live data. It does not cover instances that are only used informally. All data shall remain in the xxx system. No data shall be taken out of the system for long-term storage/archiving.’ Then, if you decide later that archiving is to be done, just change the SOP and follow the new procedure. Include in the SOP: r Under what circumstances shall data be selected and moved from the system to archive? r How shall the data be selected? For example: It could be based on products, projects, or time r How shall data be moved to the new media? r How can data be moved back to the system (retrieved) if needed? r How shall this retrieval be tested and documented? At the very least, this should be done every time there is a system upgrade r How often, under what circumstances, and how shall the data storage media be tested? 5.4.9

Qualification of Static Data in the System

Reference for more information: r Qualification of static data is described in Chapters 11–16 Static data needs to be qualified to make sure that it has been entered correctly and can be used as planned. It may be wise to include test plans for various types of work in the SOP. This means that the plans are approved and authorized with the SOP, and there is no need to approve or authorize each plan individually. Include in the SOP: r What data needs formal qualification? r How shall this data be qualified? 5.4.10

Static Data

Reference for more information: r Static data is described in Chapter 18. Even if your system isn’t a LIMS, you can get useful information from this chapter

P1: OTE c05

JWBK188-Segalstad

94

September 15, 2008

13:9



A example of an analysis table follows:

Analysis table – upper part

Explanation

Name Description Version Reported Name Common Name

Analysis Type

Alias Name Lab

The text for the final result used in reports, such as the CoA. The type of result produced.

The type of analysis method used to produce the result.

Entry See Naming Conventions for Analysis Name. See Naming Conventions for Analysis Name. Start with number 1. After this has been approved, give it the next available number. As used in the CoA. Use appropriate name on the list, or create a new name; see Common Name Table for naming conventions. Use appropriate name on the list, or create a new name; see Analysis Type Table for naming conventions. Leave empty. Leave empty.

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9


Procedures for Each System Inst Group

Instrument Groups is an entry in the List Table. It lists the types of instruments, but not the instrument itself; that is HPLC, pH meters. To create a new entry in the list, see Lists Table below.

Instrument

Must be identified in the Instruments Table. See the SOP for instruments if the instrument will have to be connected to a LIMS.

Test Location Expected Date

Group Name

Days: Hours: Minutes Time from logging the sample until it is expected to be done. From the List Table – Group Names List.

95

Select if only one type of instrument is used for obtaining results. When more than one instrument is used (i.e., balance and analytical instrument), no instrument group should be listed here. When using the analysis for samples: No entry in this field: All types of instruments can be assigned. Selected instrument group: Only instruments belonging to the instrument group can be assigned. Leave empty unless there is only one instrument of that type. When using the analysis for samples: Manual input of data: The analyst will answer which instrument he/she is using from the assigned instrument group or from a long list of different instruments. Connected instrument: The instrument will send the information to LIMS. Leave empty. Leave empty.

See LIMS-SOP Guidance to working with templates.

Systems that are configured with static data need a procedure to explain how this is to be done. Complex systems may need more than one procedure for entering static data. The SOP should include what to enter and where, but not how, as the users have been trained for this. It may be useful to add screen shots of the system, to make sure that the user can identify what the SOP is describing. Include in the SOP: r Which fields are mandatory? r Which fields are optional? r What rules exist to distinguish mandatory and optional fields? r Exactly which data should be entered in each field? This includes data formats, as the system doesn’t understand that, for example, ‘w/w %’ and ‘%w/w’ are the same r Refer to the SOP for qualification of the static data

P1: OTE c05

JWBK188-Segalstad

96

September 15, 2008

13:9



5.4.11

The System Description

Each system needs a system description. This can have references to the supplier-supplied description and to the configuration management logs, if these exist. There is no need to repeat the information in the SOP, but descriptions that are not located elsewhere must be included In the SOP. The system description is often a two- or three-page overview document, written such as it can be understood by nontechnical people. See also what is written about for the system description and log above, in the generic section of this chapter.

Include in the SOP: r Provide an overview of the process in which the computerized system is used, clearly describing the main functions of the computerized system r Describe the main data/electronic records managed by the computerized system r Provide a diagrammatic overview of the system, showing the main computerized system components (software, hardware, and IT infrastructure) r Provide an overview of the interfaces between the computerized system and other computerized systems, indicating the data that is transferred across the interfaces r Identify the location of the computerized system. Also, indicate the location of specific instances of the computerized system (e.g., installed versions of the application in different regions) r Describe the operation and maintenance strategy in place for the computerized system r Identify the responsibilities for system ownership, operation, administration, and maintenance. This should be done by named departments rather than by named individuals r How and when shall the description be updated?

5.4.12

Training

It may be stated that training shall be done according to the user’s role in the system. One example is that super-users will need training on the supplier’s four-day course, while ordinary users will be trained for two days by the super-users.

Include in the SOP: r How shall which people be notified about a new user’s training needs? r How much training do different users need when they have various roles in the system? For example: Key people will need more training than end-users, and there may be very different roles for end-users as well r How shall training be done? Class, interactive, or guided training? r Who is responsible for providing training? r How shall training be documented? r When the user is given a different role in the organization, a different kind of system access may be needed r How do we assess training needs for the various roles?

P1: OTE c05

JWBK188-Segalstad

September 15, 2008

13:9


References

5.5 5.5.1

97

Tasks SOP for an SOP

Create an SOP for an SOP using the guidelines described in this chapter. Include a flowchart for the SOP process. In a separate document, describe the roles that you use in the SOP. 5.5.2

Roles

Interview three people who work side-by-side in the organization to find out what they do, both every day and once in a while. They are likely to have some common tasks and some unique tasks. Make lists of key words from their answers, and create roles from that list. Assign the roles to each of the people. 5.5.3

An SOP for Roles and Responsibilities in the IT Organization

Create an SOP with key words for the roles, groups, and responsibilities that exist in the IT organization. This can be based on one of the following: r the text in the book/compendium r your own organization, where roles and responsibilities are different r how you would like to organize this in an organization 5.5.4

An SOP for Change Control

Look at the change control flowchart shown in Figure 5.1: r Can this be used for any changes in the company; for example, the manufacturing process, the QMS system, laboratory analyses, or IT systems? r Will you need to have additional or different change control procedures for any of these? r In that case: What makes it necessary to have specific change control for this/these? r Write the SOP based on this flowchart and your answers to the above questions

References 1. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. R R 4 Good Automated Manufacturing Practice (GAMP ) Guide for Validation of Au2. GAMP tomated Systems, 4th edn (2001), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-17-6, www.ispe.org. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based Ap3. GAMP proach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. R Good Practice Guide: Validation of Laboratory Computerized Systems, 1st edn (2005), 4. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-39-7, www.ispe.org.

P1: OTE c05

JWBK188-Segalstad

98

September 15, 2008

13:9



5. ISO 9001:2000 (2000) Quality Management Systems – Requirements, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 6. ICH (2006) Q9 Quality Risk Management, ICH, Geneva, Switzerland, www.ich.org. 7. US FDA (2005) 21 CFR Part 210 Current Good Manufacturing Practice in Manufacturing, Processing, Packing, or Holding of Drugs; general, US Food and Drug Administration, Rockville, MD, www.fda.gov. 8. US FDA (2005) 21 CFR Part 211 Current Good Manufacturing Practice for Finished Pharmaceuticals, US Food and Drug Administration, Rockville, MD, www.fda.gov. 9. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17


6 IT Integrated in the Supplier’s QMS


The supplier’s quality management system System development models Documents for software development The customer–supplier relationship

6.1

Introduction

Some suppliers are basically service providers and are used for outsourcing services. This is discussed in Chapter 2. This chapter covers how the suppliers of a computerized system shall include their part of the System Development Life Cycle (SDLC) in their quality system. It only covers parts of the QMS that are related to system development. In some standards suppliers are also called vendors, but most use the word ‘supplier.’ There are basically two types of suppliers to a system: the ones who program the system and the ones who implement or configure the system. The organization may be different: r The same organization programs and implements the system, using the same quality system r Different parts of the same organization program and implement the system, using different quality systems r Separate organizations program and implement the system, using different quality systems r The programming and/or implementation is done internally in the user organization International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c06

JWBK188-Segalstad

100

September 15, 2008

13:17


IT Integrated in the Supplier’s QMS

The software may be developed fully or in parts, especially for the user organization – this is called ‘customization.’ The software may also be a commercial off-the-shelf system that can be configured using the system’s basic functionality, or simply used as is, without any configuration. Configuration and implementation are often used as interchangeable expressions. Regardless of who the suppliers are, how they are organized, or whether the system is standard or customized, the same quality requirements apply. The supplier creates IT systems as well as using them. The use of these systems is described in Chapter 5.

6.2 6.2.1

Which Standards Should Be Used? GAMP

Suppliers to the pharmaceutical industry will often be asked whether they follow GAMP [1, 2] during their development and whether the system is 21 CFR Part 11 [3] compliant. GAMP has several appendices covering the development and testing of the system. Basically, the requirements set forth in these appendices are the same as described in this chapter. 6.2.2

21 CFR Part 11 Functionality Must be Built In

Part 11 has technical requirements that must be built into the system if it is to be used in the pharmaceutical industry. The rest of the requirements in Part 11 are procedures and validation requirements for the use of the system, over which the supplier has no control. A delivered system can be technically compliant but nothing more. Equivalently, the system can be delivered as validated or qualified, but as soon as it is in the users’ organization, it is no longer qualified. The installation has changed the system to a new platform, even if the latter is equivalent. The way in which the user organization uses the system is different, so at least IQ and PQ need to be done at the users’ site before the system again is in a validated state. 6.2.3

The IEEE, the ASTM, and the ISO

As discussed in the previous chapters, there are several standards available for the supplier. Which one (or ones) to use is a matter of preference, and is often colored by geographic location. In Europe, the ISO standards (www.iso.org) are preferred, while in the United States, the IEEE (www.ieee.org) and the ASTM (www.astm.org) are often preferred over the ISO. My suggestion is to use ISO 90003 [4] for the overall requirements, and to peruse the IEEE and ASTM standards when details are needed, as the IEEE has great standards for software testing [5–7]. This is the approach used in this book. 6.2.4

Good Engineering Practice

One expression not mentioned earlier is Good Engineering Practice (GEP). This isn’t one standard but, rather, a consensus for how engineering is to be undertaken and documented. The ISPE’s Baseline Guide for Commissioning and Qualification [8] explains GEP in more detail.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17


The Quality Management System

101

The definition of GEP is as follows: ‘Established engineering methods and standards that are applied throughout the product life cycle to deliver appropriate, cost-effective solutions.’ GEP is related to utilities, facilities, and equipment, and not specifically to IT systems. When these items are to be used in a GxP environment (usually the GMP), they include the following according to the Baseline Guide: r Design and installation that takes full account of current GMP, safety, health, environmental, ergonomic, operational, and maintenance requirements, recognized industry guidance, and statutory requirements r Professional and competent project management, engineering design, procurement, construction, installation, and commissioning r Appropriate documentation, including design concepts, drawings of design schematics, as-installed drawings, test records, maintenance and operation manuals, and statutory inspection certificates, to mention a few There are obviously differences between GMP and GEP. While GMP covers quality requirements and competence in the work done, GEP also includes cost-effective solutions, safety, health and the environment, and project management, to mention a few. In that respect, GEP is closer to ISO 9001 than to GMP, but the quality requirements in GMP need to be taken into account and followed. The GMP requirements are better defined and stricter than most other standards.

6.3

The Quality Management System

When creating a Quality Management System (QMS) in a supplier organization, the description in Chapter 4 should be read and followed. Further reading includes ISO 90003:2004 and the TickIT Guide [9], which is the guide to ISO 90003:2004 to be used for TickIT certification. This is explained in Chapter 2. Documents must be under control, and what this entails needs to be described in the QMS. The documents in question include not only those that are a part of the QMS, such as the Quality Manual and procedures, but also those that are generated for each particular product. The description must include requirements for: r approval prior to use r reviews and updates as necessary, and the reapproval of documents before use r version control and change control, to ensure that changes from last version, the version control, and the valid-from date can be seen in the document r distribution control for the documents r archiving for historic/replaced documents The process must be followed for documents in the quality system as well as for all documents called for in the quality system, such as change control, specifications, test documentation, reports, and so on – the latter are called ‘evidence of conformity to the requirements.’ The QMS needs to reflect the organization’s way of working – the processes. Processes must therefore be the backbone of the QMS, and the organization needs to understand and

P1: OTE c06

JWBK188-Segalstad

102

September 15, 2008

13:17



describe them correctly: r it must identify the processes, including those for software development r it must understand the interaction between processes r it must control the processes and monitor them In ISO, continual improvement is a goal in itself. There are several ways to do this, and the supplier needs to include as many ways as is feasible in the organization: r The quality system can always be improved, even when the processes are still the same r Processes can also be improved, and this must be reflected in the QMS r Corrective actions when something goes wrong must be followed by preventive action: How can we reduce the risk of this happening again? r The process planning and estimates can be followed by the reporting of the actual result. This can be an input for doing a better job next time r Customer satisfaction can be measured. When using information from customers, it may be possible to create metrics for the level of satisfaction, which can be followed over a period. Additionally, internal issues can be followed, such as the response time and resolution time for issues raised by customers r Metrics for the product include the number of errors, and necessary patches and releases, to mention a few. It is also possible to measure functionality, how well the system can be maintained, how efficient it is, and if it is usable and reliable The management has a responsibility to be actively involved in these quality processes. It isn’t possible to ‘leave the quality things to those who understand them’ and still be regarded as being involved in the processes. The most important of the management’s responsibilities is to follow up on all quality issues internally in the organization. That includes stressing the importance of meeting requirements set by customers, regulatory constraints, establishing and following up the quality system, conducting management reviews, and ensuring that resources are available. The management shall review audit results, customer feedback, process performance and product conformity, corrective actions and preventive actions, and other input that affects the quality. The outputs of these reviews are decisions for actions, this being changes to the QMS or resources needed for improvement – to mention a couple. It is also the management’s responsibility to make sure that internal audits are being performed. Findings must be acted upon to improve the quality system or the processes. Internal audits have the disadvantage of being too close to the operation, even when the independent QA personnel are used to do it. They carry the baggage of knowing how things are normally done, and they may not question the obvious. Supplier audits from customers are also good tools for improvement, as customers have a refreshing way of seeing the organization from outside, without the internal baggage. Competence is a necessity in any knowledge-based organization. Competence is normally acquired as a combination of formal education, formal training, and the informal training needed to do the job. This is often documented in two different documents – the Curriculum Vitae (CV) and the training records – but it is frequently not documented at all. The CV generally includes the formal education and where the person has been employed. This document isn’t edited very often, which is why training records are additionally being used. The training records include all training, whether it lasted a few hours or several

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17


System Development Models

103

days or months; and both formal and on-the-job training. On-the-job training is usually informal, but it should still be included in the training records. The training can be done by having the person learn while watching a mentor who knows how to do it, then do it under supervision until the mentor is satisfied that the person can go it alone. Finally, this must be documented in the training records. People need new knowledge and competence when technology develops or when they are given new responsibilities. The organization must assess both its needs and the employees’ wishes, and create a training plan for the next period, which usually means the following year. Both the plan and its fulfillment must be documented. The CV plus the training records will show the total competence of the employee. If the organization wants to sell its products to the regulated industries, it is highly advisable to know the regulations. In contact with the customers in the regulated industry, it is also quite smart to understand what they are talking about when they mention GALP [10], GAMP, Part 11, PI-011 [11], qualifications, or validation, to list a few of the expressions used in those industries. Both the US and the EU pharmaceutical regulations have their requirements for technical features built into the system, and Part 11 even has a requirement that suppliers must know what the regulations are about.

6.4


There are several models for system development and any of those, or your own model, can be used. Neither the ISO nor the pharmaceutical standards that mention models have any recommendations for which one to use; instead, they state quite clearly that it is your organization’s choice. What is important is that the model is described in the quality system and that the processes described follow the model. Below are brief descriptions of a few of the models in use, including their advantages and disadvantages. Before deciding which model to use, please consult more thorough literature on the issue. Any textbook on system development will include information on the author’s preferred model or models. The SDLC must be described in the QMS, regardless of which development model is used. Below is an overview of various requirements and documents that may be needed. Depending on the model chosen, there may be fewer or more, and each organization must decide what is appropriate. In a way, it is too bad that there is no standard answer on how things should be done. On the other hand, if you want to do things differently, you should also avoid constraints. There is only one rule: Say what you do and do what you say. Both of these aspects are a matter of documentation. Say what you do in your quality system. Then do as you say, and document it. A life-cycle model is a software process description, but the term ‘life-cycle model’ predates recent discussions of software processes. The process is a collection of activities, with well-defined inputs and outputs, for accomplishing some task. Regardless of the model chosen, the software must be developed in a structural manner: r r r r r

planned before being programmed programmed before being tested tested before being delivered divided into smaller, manageable units/phases where feasible described in the QMS

P1: OTE c06

JWBK188-Segalstad

104

September 15, 2008

13:17



Life-cycle models tend to focus on major life-cycle phases and their relationships to one another. To some extent, this division of the life cycle into phases is random, but the following phases have become conventional: r r r r r

requirements – determine customer needs and product constraints design – determine the structure and organization of the software system coding – write the software testing – exercise the system to find and remove defects maintenance – correct and enhance the product after deployment to customers

Organizations using other names for their phases can still use the various models, but they need to rename the boxes in the models accordingly. 6.4.1

Methods and Methodology

While a life-cycle model is a description of a high-level software process that typically focuses on product phases, a method is a detailed process for achieving some development goal. A methodology is the collection of ‘stuff’ used in a software project, which typically includes methods and a life-cycle model as well as tools, standards, and practices, to mention a few. Sometimes these terms are confused or used inconsistently. The main thing to remember is that a life cycle is usually about what happens to the product, while a process is a generic term for any organized activity. A method is something specific, usually with a name attached, while a methodology is more amorphous. Methods can be purchased in the marketplace or be created ‘at home.’ Most organizations either adopt standard methods or create their own by adapting the standard methods. Thus there is considerable consistency across the industry regarding methods used. For example, in the analysis and design arena, the common methods are as follows: r Some version of Structured Analysis/Structured Design (SA/SD). This approach has been dominant since the late 1970s, but is now fading fast r Some version of Object-Oriented Analysis and Design (OOA/OOD). This is the new, hot fad: It is rapidly replacing SA/SD throughout the industry Methodologies are also fairly standard across the industry – there are accepted ways of doing projects that govern choices of methods, techniques, and tools. Methodologies are usually tailored based on project characteristics such as size, reliability and safety requirements, team expertise, and budget. 6.4.2

The Trial-and-Error Model

The most primitive life-cycle model is trial and error, sometimes called build-and-fix or hack-and-foist. In this life-cycle model, the first version of the system is built without prior plans, documentation, or control. If the product is accepted, the developers face an interminable period of confusion, frustration, and drudgery as they fix an endless stream of problems.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17



105

V Model Requirements specification

Validation

Architectural Design

System Integration Test

Detailed SW Specification

SW Integration & Testing

Code/Unit Testing

Figure 6.1

The V Model.

Unfortunately, this life-cycle model, which hardly deserves such a dignified name, is all too common in practice; however, continued pressure from customers is forcing it to be abandoned. So forget about using this model.

6.4.3

The V Model

The V model, shown in Figure 6.1, is also known as the ISO V Model. The model gets its name from its V shape. Incidentally, it isn’t mentioned by name in ISO 90003, but it can be deduced from the text of the standard. Still, the standard only uses it as an example of the documents needed, while stressing that any model can be used. The V Model is probably one of the more well-known models. There are numerous variations where the principle is the same and the difference lies in the names in the boxes. Each development plan (on the left side) must have an accompanying test plan (on the right side). The test plan must be written in such a way that the each of the development requirements is tested. The principle is to start by creating the Requirements Specification. This is one document describing the functionality of the new system as seen from a user’s perspective. It does not include details of how to program, the tools used, or how to divide the system into modules. The plan for how to test this specification is written at the same time. The Requirements Specification is used to create one or several specifications covering architectural design. These include more details on how to achieve the requirements. Here, the modules are defined. Again, test plans must accompany the specifications. Each of the architectural design documents will have one or more detailed software specifications. This is generally where programming tools are determined. The bottom of the V is where the code and units are created and tested. This is where the actual programming is done.

P1: OTE c06

JWBK188-Segalstad

106

September 15, 2008

13:17



There is a one-to-many relationship from the top left to the bottom: Any of the specifications at the higher level can be a parent of one or several specifications at the lower level. Strengths: r Planning how to test this while specifying the system is actually two parts of the same issue. It is useful to work on these concurrently, to make sure that everything is covered in the test plans r Adding more detail at each successive lower level helps the specialists fulfill the requirements while keeping an eye on the functional requirements stated at the top r All plans are made early in the process, before the actual programming starts. Weaknesses: r Changes at one level have consequences for every level, and for both specifications and test plans. The result is frequent documentation changes on all levels and the risk of not bothering to keep them updated r The procedure depends on separating requirements from design, which is often difficult r It also emphasizes products rather than processes. One of the important shifts in perspective in achieving high levels of quality is to emphasize the process rather than the product developed by the process; the model focuses on the product, and on the intermediate work products generated in building a product, rather than on the development process itself 6.4.4

The Waterfall Model

The Waterfall Model is shown in Figure 6.2. The model gets its name from the cascading flow from the top to the bottom. The Waterfall Model has basically the same content as the V Model, but items are handled sequentially instead of concurrently. Although the Waterfall Model is now quite old – it was first suggested in the 1970s – it is still widely used. There are many versions of the Waterfall Model. For example, some models include a concept analysis phase before the requirements analysis phase. The major deliverables

Waterfall Model Phase Outputs

Phase Inputs Project Plan Requirements QA Plan

Software Requirements Specification (SRS) Design Document

Design

Software

Coding Test Plan

Testing

Test Report

Maintenance

Figure 6.2

The Waterfall Model.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17



107

from each phase are listed on the right. Each of these, along with additional documents listed on the left, is input to the next phases. Thus, for example, the project plan and the Quality Assurance plan are inputs to the requirements phase, which produces a Software Requirements Specification (SRS) as its major output. The project plan, the QA plan, and the SRS are then input to the design phase. Although the Waterfall Model stresses a linear sequence of phases, in fact there is in practice always an enormous amount of iteration back to earlier phases, a point made by the arrows leading back up the waterfall. Strengths: r Emphasizes the completion of one phase before moving on: This makes a project easier to manage and cuts down on costly iterations through phases r Emphasizes early planning, input, and design, which are often sorely lacking in other models. A life-cycle model emphasizing these things is helpful r Emphasizes testing as an integral part of the life cycle: Testing is often minimized in poorly managed projects, so building it into the life cycle helps to focus more attention on it r Provides quality checks at the end of each life-cycle phase, which helps to assure the product quality Weaknesses: r Depends on capturing and freezing requirements early in the life cycle. This is often difficult, as doing so may result in the delivery of a product that customers don’t want and won’t pay for r Depends on separating requirements from design, which is often difficult r Not politically feasible in some organizations. Some organizations are so short-sighted that a long-term project isn’t feasible; in such organizations, a model that does not require management commitment to a long process, as the Waterfall Model does, may be the only way to undertake large projects r Emphasizes products rather than processes, like the V Model 6.4.5

The Spiraling Model

The Spiraling Model is shown in Figure 6.3. The activity starts from the center of the spiral and continues outward. Each turn around the spiral comprises one complete phase with several activities: Objectives and constraints are determined, risks are identified and managed, and the functionality is implemented. Finally, the phase is reviewed and decisions are made as to whether the project should be abandoned or continued. If it is to be continued, a new loop is added and the same process is followed. Basically, the Spiraling Model is an evolutionary or incremental model, in which the Waterfall Model is used for every step. The developers define and implement the highestpriority features first. If the users or customers provide feedback, the model is called ‘evolutionary’ – if the customers are not involved, it is called ‘incremental.‘ Regardless, after testing, the developers continue with the next features in smaller, more manageable pieces. Risk management is incorporated, as risks are identified and analyzed before every major phase and managed so as to minimize them or avoid them altogether. Progress may be stopped at any given point if it isn’t adequate.

P1: OTE c06

JWBK188-Segalstad

108

September 15, 2008

13:17



Determine Objectives and Constraints

Implement & Test

Manage Risks

Design Requirements Concept

Plan Next Phase

Figure 6.3

Perform Phase

The Spiraling Model.

Strengths: r Emphasizes risks that are often ignored in other models r Emphasizes quality r Emphasizes risk reduction techniques, such as prototypes, simulations, buy versus build, and so on r Provides checkpoints for considering project cancellation Weaknesses: r Full-scale risk analysis requires training, skill, and considerable expense, so it may be appropriate only for large projects r The model is relatively untried

6.4.6

Prototyping

A prototype is a working model of a final system. Prototypes can be used in two ways, which are very different from each other: r in the requirements or design phases of a Waterfall Model, called ‘throwaway prototyping’ or ‘rapid prototyping’ r in a ‘prototype evolution model,’ also called ‘iterative enhancement,’ ‘incremental development,’ or ‘exploratory programming’ Prototyping is becoming more popular all the time and people often refer to prototypes in the literature. Unfortunately, a variety of terminology is used, so it is often difficult to tell what people really mean when they discuss prototyping. Care should be taken to learn the terms above, because they are most frequently used. Prototypes make it much easier to communicate with clients and to understand what they really need and want; they also make it possible to use ‘what if’ scenarios to explore requirements and design alternatives. Hence prototyping is a powerful tool for determining requirements quickly, completely, accurately, and cheaply.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17



109

The two major prototyping models, rapid prototyping and prototype evolution, are discussed below. Rapid Prototyping

So-called productivity tools have become so widespread and so easy to use that simple ‘mock-ups’ – that is, things that look like real programs but don’t do much – are very frequently put together. This largely removes the problem of investment in one of the several available rapid prototyping tools. Requirements and design prototypes, especially mock-ups, are usually completely unsuitable as finished products, a fact that many clients and managers don’t understand. There is always a danger that prototypes will be taken for real products, with disastrous consequences. Rapid prototyping strengths: r Requirements can be set earlier and with greater reliability r Requirements can be communicated more clearly and completely between developers and clients r Requirements and design options can be investigated quickly and cheaply r More requirements and design faults are caught at an early stage Rapid prototyping weaknesses: r Requires a rapid prototyping tool and expertise in using it – a cost for the development organization r The prototype may become the production system Prototyping Evolution

In a prototype evolution life cycle, an initial set of requirements is used to build a rough prototype that can then be evaluated by clients and developers alike. Feedback is then used to fix and extend the requirements, followed by revision of the original prototype. This cycle can continue for as long as necessary, ending only when a satisfactory product has been developed. Prototype evolution and rapid prototyping share the ability to generate excellent requirements quickly and cheaply; this is especially helpful when (as so often happens) no one really understands what the new system should do or how it should work. This approach also has the advantage that it quickly gets something into the clients’ hands, even if it isn’t complete. This can increase confidence and help meet user needs sooner. Prototypes are usually evolved top-down, which is a good approach for implementation and testing anyway. Developers enjoy having a working product at an early stage just as much as clients, so prototype evolution is often a morale booster for developers. Another benefit is to let the clients be part of the development process and to let them provide feedback, which increases the clients’ confidence and satisfaction. In effect, prototype evolution thrusts clients into the center of development, meaning that they are exposed to all the frustrations and problems that are otherwise hidden inside the development process. In particular, systems under evolution tend to be very unstable, with features that disappear or stop working, disastrous reactions to error, and frequent failures. This can alienate clients, which removes one of the main advantages of the approach.

P1: OTE c06

JWBK188-Segalstad

110

September 15, 2008

13:17



There is also a danger that the process will completely lose integrity and collapse into trial and error – this can occur if an orderly, well-documented procedure, with strict control of changes at every step, isn’t followed. Another problem is that the process is hard to manage because progress is difficult to track, and estimation of the completion time and of costs is almost impossible. Finally, the early system design will probably not easily encompass unforeseen later changes, so a lot of patching, forcing, and messy reworking is likely to be required. In the end, the system may be a mess that can’t possibly be maintained. Prototype evolution strengths: r Avoids building systems to bad requirements r Delivers a working system early and cheaply r Fits top-down implementation and testing strategies r Probably improves developer productivity Prototype evolution weaknesses: r Users may become frustrated due to constant system volatility and often unreliable systems r The process may collapse into trial and error r It is difficult to measure progress or estimate completion times r Systems tend to develop poor design structures, leading to maintenance problems 6.4.7

Reuse Base Model

The goal for this model is to leverage existing assets in creating new products. Assets include knowledge, documents, code, templates, and designs – to mention a few. This approach emphasizes a domain-centered view of software engineering that recognizes that most organizations build variants of systems within, at most, a few problem domains or problem areas. The life cycle is based on a process for building multiple related systems in a domain through systematic reuse of existing assets. The process of creating an infrastructure to support systematic reuse is called domain engineering. Domain engineering is like creating the assembly line in a manufacturing plant; running the assembly line is like producing software applications. Different application domains (product lines) require different tools (machines), models (molds), processes, and so forth. In this new paradigm, the software life cycle becomes a process of customizing the assembly line for a given set of requirements, and then running it to produce a software product. Strengths: r Potentially great productivity and quality gains r May improve business decisions r Encourages process maturity r Emphasizes cost-effective use of all assets Weaknesses: r Still an experimental approach r Limits products to a product line r Requires considerable infrastructure support

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17


Documents for Software Development

6.5

111


The product planning comprises both the software life cycle and Quality Planning. Both depend on the model used as well as the complexity of the software. The System Development Life Cycle depends on the model used.

6.5.1

The Quality Plan

Regardless of the model or complexity, a Quality Plan (QP) should be drawn up. In some cases, the quality system’s description is sufficient, but in most cases it isn’t. The quality system may be sufficient if the organization has one or very few different products, but it is generally not sufficient if there are more. The QP may be one document or a part of another document, or it could also be several documents. The QP will often tailor the requirements in the QMS for this specific product. It will include plans for creating several of the documents, but normally not the documents themselves, which will be created later. The various documents are discussed in the following pages. The development phases should be planned with input and what to do during the phase and output – if this isn’t already in other parts of the quality system.

6.5.2

Risks

Risk assessment and risk management should be addressed somewhere. It is irrelevant whether this is in a separate document, in the Quality Plan, or as a part of other documents, as long as risks are addressed. Risks are discussed in more detail in Chapter 12. There are a number of risks for the project: r r r r r r

criticality, safety, and security issues competence, or more likely the lack of competence resource estimates such as timing and available manpower project planning, including resources tools, such as new, fast, and untested or old, slow, and well known requirements, well specified or not

6.5.3

Tools

Several tools are used in the development process. Some of these are high-risk tools, with a high impact on product quality. These include tools for handling errors, managing the configuration, checking source code in and out during development, and so on. Other tools include purchased development tools and various libraries to be used during programming. The supplier needs to take responsibility for these tools and to integrate them into its own quality handling. All such tools must be under control and should be verified or validated. The suppliers also have their own suppliers, who provide the tools used in development in addition to the hardware. If these suppliers are used for subcontracted development

P1: OTE c06

JWBK188-Segalstad

112

September 15, 2008

13:17



and outsourced activities, they are called subcontractors. Supplier selection and contracts should also be included in the SOPs. Programming standards and naming conventions should be included in the SOPs.

6.5.4

The Requirements Specification

The Requirements Specification (RS) is also sometimes called the User Requirements Specification (URS). It is confusing that this term is used both for what the user desires when describing his or her needs for a new system, and for what the supplier decides to include in its off-the-shelf system. In order to distinguish them, ‘URS’ is used for the user’s requirements and ‘RS’ is used for the supplier’s requirements. The URS is described in Chapter 13. The RS has input from various sources: r r r r r

internal, when the software will be some kind of off-the-shelf system customer, if tailored specifically to one customer from one or more customers, if this is a request for an upgraded version prototyping a combination of several of these

Before adding the request or suggestion to the URS, the supplier must discuss the feasibility of the requests. Some of them may be turned down, as they are too complex, too expensive, not interesting to most of the customers, conflict with other functionality, or for various other reasons. Others may be found suitable for inclusion. The feasibility of the suggestions and requests, as well as the conclusion for their inclusion in or exclusion from the RS, must be documented. There may also be requirements that are not directly stated, but that will be needed in order to fulfill yet other requirements. An example is interfaces between modules, or with other systems. The RS must include the requirements that have been deemed feasible for inclusion. Each requirement should be expressed clearly in a way that will facilitate testing and validation. Furthermore, each requirement should be given an identification number/name. Changes to the RS must be controlled, either as amendments or as new versions of the document.

6.5.5

Detailed Specifications

The more detailed specifications needed in several of the models have different names in the various models and organizations. These specifications need to include information necessary at this level regarding the tools to be used for programming, the division of the whole software program into smaller pieces or modules, or other necessary information. The specifications also need to include how the different modules fit together, how they communicate, and so on. As with the RS, the changes in the requirements must be controlled.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17



6.5.6

113

The Traceability Matrix and Configuration Management

Once the RS has been determined, there is a need to start a traceability matrix; this will help in controlling the requirements and their status. Each requirement from the RS has an identification number/name. Often, this requirement will have more than one detailed requirement in the next set of specifications. These also need to have names and numbers. Test plans will often provide even more detail, again with a possible one-to-many relationship. The matrix should have columns in which each step is listed, and it must be kept updated. There is no difference between a matrix for a system developer and one for validation purposes – they both show relationships between requirements and testing on various levels. An example of a traceability matrix is shown in Figure 13.5. The configuration of the system is important, not only for the delivered system, but also for what is tested. It is useful to have tools for configuration management, as well as a type of document management system for checking programming files in and out when writing the software. During the development process, it is common to make a new build each time something is to be tested, to make sure that the newest version of each of the components is used. The configuration of each build must be traceable, so that it is possible to see exactly which configuration has been used at any given time.

6.5.7

Test Plans

Test planning should be done as early in the process as possible, and preferably at about the same time as the corresponding specifications are written. However, this depends on the model, so variations are permitted. Any test plan should clearly state what is to be tested, with details about how to test and inclusion of the expected results, which should be based on the specification for the function to be tested. A reference to the specification or an updated traceability matrix must show what is being tested. The test plan should have columns for identification of the test, what is to be tested, how to test, and the expected results, and it may also include a blank column that can be filled in with comments, results, or references to other documentation during testing. Testing encompasses both positive and negative testing. Positive testing checks that the system does what it is supposed to do according to the specification. Negative testing investigates what the system does when things are not as they are supposed to be. Here is an example: r The Requirements Specification says that you shall be able to enter numeric upper and lower limits for an input value, so that you can only enter values the fall within these limits: – positive testing will check that you can enter values inside the limits – negative testing will check that it isn’t possible to enter values outside of these limits – or that they can be entered, but they will be flagged up as being outside the limits r Testing must also include what happens right around the boundaries, taking into consideration various scenarios of being right on the limit as well as the rounding of values

P1: OTE c06

JWBK188-Segalstad

114

6.5.8

September 15, 2008

13:17



Test Documentation

The test documentation is the proof that the testing has been done. A copy of the test plan can be filled in during testing and used as documentation if there is space for comments and references. Errors must be indicated as such. Additional documentation should be prepared – when in doubt, document – the more the better. This could include screen shots, handwritten comments, or anything else that can help to document exactly what has been done. When done, the filled-in test plan with all additional documentation is now the test documentation, and is to be dated and signed by the tester.

6.5.9

Errors

Errors and failures must be clearly indicated and subsequently followed up by corrective actions – and also preventive actions when feasible. If the organization has a system for error handling, there must be a link between the error found and the error in the system. When errors are resolved, the functionality needs to be retested to prove that they have been resolved. Sometimes a complete test suite will need to be retested due to changes resulting from the resolution of errors.

6.5.10

The Test Report

The purpose of the test report is to report the conclusion from the testing. There is no need to repeat what can be seen in the test plans or in the test documentation, but all errors must be listed, even if they have been resolved. The status of each error may be included, but this is information that frequently changes, so it may be more useful to refer to an updated external error list. The conclusion should be stated as ‘Pass’ or ‘Fail.’

6.5.11

User Documentation, Manuals, and Help Functions

Systems are always supplied with documentation. This can take the form of paper manuals, online manuals embedded in the system, additional help functions in the system, and release notes, to mention a few. These documents need to be written, and they need to be up to date. If the documents are written at the same time as the system is being developed, it is vital to include them in the change control process, to make sure that they are in line with the current system. This documentation is also part of the controlled documents and is to be signed off before the system is ready for the customers. Help functions may also be created in such a way that users can update them according to their local needs. Care must be taken to ensure that these do not obscure the originals supplied with the system.

6.5.12

The Validation Report

The final report for the system is often called the Validation Report. In many models, this corresponds to the Requirements Specification. In other models, the report will simply be

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17


The Customer–Supplier Relationship

115

a conclusion of the activities that have led to the finished system. A sign-off on this report means that the system is ready for the customers.

6.6

The Customer–Supplier Relationship

The documentation for the project is the same regardless of whether the system is to be purchased off the shelf or specifically made for one customer. The main difference between these two is the customer’s involvement in the process. Customers are generally not involved in the process for off-the-shelf software; however, they sometimes help with the so-called ‘beta testing.’ This is done after the system has been fully tested at the supplier’s site, which is called ‘alpha testing.’ Customers may get the software early for testing in-house, often with their own data. As different organizations frequently use software very differently, there is a chance that new errors will be found. When software is specifically programmed for a customer, there is a closer relationship. The URS is made either by the customer or by the supplier in cooperation with the customer. Quite often, prototyping is used to help create the specification and/or the system. Both the URS and other documents should be reviewed by the customer. The customers need to be kept informed, and the supplier must have a system for doing so. The communication can include product information, contract handling, enquiries and a helpdesk, as well as customer feedback, including complaints. The contract must include a number of issues for software specifically designed for one customer: r Standards and design, procedures and/or development standards to use during development. These may belong to either of the organizations, and should be stated in the contract r Requirements for the platform hardware and software r Risk management r The project plan r Reviews r Progress reports r Disclosure of information r Confidentiality/nondisclosure agreements Contracts for customers buying the off-the-shelf system, as well as for those who contract software, must include other issues: r Maintenance and support. Maintenance agreements should be included in the contracts between the supplier and each customer. The scope must be defined: helpdesk (24 h a day, seven days a week, or less?), license agreements, including the number of users or concurrent users, implementation help, problem resolution times, and so on r Confidentiality r Security r Legal aspects such as intellectual property rights and license agreements, and copyrights r Warranty r Liability and penalties

P1: OTE c06

JWBK188-Segalstad

116

September 15, 2008

13:17



Replication is the act of creating copies of the final build of the software for delivery. This needs to be done in a structured way to make sure that it is correct each time. Delivery can be accomplished in various ways: The system can be delivered on media such as DVD, CD, or tape, or it can be delivered electronically from the supplier’s computer to the user’s computer via a network. There must be procedures to cover what a delivery will contain. In addition to the software, user manuals and release notes are usually included in delivery. Errors will be found after delivery, and the question is what to do about them. It is possible to create ‘patches’ that will correct the errors, and to distribute these to the customers. If the system is immature, unstable, or includes several errors, this will result in a long stream of patches that need to be installed at the customer’s site. Customers in the regulated industries do not find that particularly enjoyable, as their change control requires that each of those changes needs qualification/validation before being taken into use. Frequent patches mean continuous validation, and this is very costly – and annoying. It will be easier if the supplier collects all the patches and distributes them in a new release, perhaps also including more or better functionality for the main system. The next question is how often will a regulated user want to accept new releases when these mean so much validation work? Most will say not more than once a year – and preferably less often than that. The release notes must say exactly what the changes are. This will limit the validation work, as it won’t be necessary for the user to validate functionality that isn’t used. It must also be possible for the user to choose not to install the next version or the next patch. The supplier needs to decide, and communicate early on, for how long they will support older versions. Support not only means helpdesk support, but also that data from the old version can be used by the new version. It is a disaster for the user if, having decided not to upgrade a fully functional system, they find out that three versions later that they can’t include their data in the latest new version. The supplier and the customer need to agree on who is to install the system or the new versions. In any case, good installation instructions are needed. This requirement can be replaced with functionality that unpacks and installs the system by itself, which is what happens with most software for home computers. There might be some decisions to be made along the way – whether all modules are to be installed, where they are to be installed, and so on.

6.7 6.7.1

Tasks SDLC Models

Discuss the various models for the System Development Life Cycle. Which one would you prefer to use? Or would you like an entirely different model? Why? 6.7.2

The SDLC Model Flowchart

Create a flowchart for tasks to be included for your chosen model. This should include plans, reports, testing, and so on, set in a relative timeframe.

P1: OTE c06

JWBK188-Segalstad

September 15, 2008

13:17


References

117

Time axis Requirement input

Requirements spec.

Feasibility Study

Func.tional spec.

Project Plan

Design spec.

Test spec. and plan

Manuals

Code and test Milestones Bug fix/changes

QA Evaluation Prepare Install kits

Project Doc. update Install and Alpha test Prepare final install kits and manuals

Archive SW Ship

Figure 6.4

6.7.3

Post sales support

The System Development Model.

The Flowchart

Look at the flowchart in Figure 6.4. This was obtained from a supplier during an audit, to explain how work is carried out during system development. Discuss the content and suggest changes.

References R R 1. GAMP 4 Good Automated Manufacturing Practice (GAMP ) Guide for Validation of Automated Systems, 4th edn (2001), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-17-6, www.ispe.org. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based Ap2. GAMP proach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. 3. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 4. ISO 90003:2004 (2004) Software Engineering – Guidelines for the Application of ISO 9001:2000 to Computer Software (formerly ISO 9000-3), International Organization for Standardization, Geneva, Switzerland, www.iso.org.

P1: OTE c06

JWBK188-Segalstad

118

September 15, 2008

13:17



5. IEEE 1012-2004 (2004) IEEE Standard for Software Verification and Validation, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 6. IEEE 1016-1998 (1998) IEEE Recommended Practice for Software Design Descriptions, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 7. IEEE 1028-1997 (1997) IEEE Standard for Software Reviews, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 8. Pharmaceutical Engineering Guides for New and Renovated Facilities (2001), ISPE Baseline Guide, Commissioning and Qualification, Vol. 5, International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org. 9. TickIT (2001) The TickIT Guide Using ISO 9001:2000 for Software Quality Management System Construction, Certification and Continual Improvement, Issue 5.0, TickIT Office, 389 Chiswick High Road, London W4 4AL, UK, ISBN 0 580 36743 9, www.tickit.org. 10. US EPA (1995) 2195 Good Automated Laboratory Practice (GALP), US Environmental Protection Agency, Washington, DC, www.epa.gov. 11. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org.

P1: OTE c07

JWBK188-Segalstad

September 15, 2008

13:21


7 Organization for an IT System

This chapter discusses the following: r Which roles are needed around a live IT system? r Which groups are needed? r Which roles are needed around an implementation and validation project for an IT system?

7.1

Introduction

Basically, the roles and responsibilities are the same for a system validation project as for a live system. However, the people involved in the project may be different from those involved in the live phase of the same system. Some companies have dedicated people who work on systems validation during the project phase, while others use the same people in the project phase as in the live phase.

7.2

Roles and Responsibilities for a Live System

Different people in the organization have different roles of responsibility for the computer systems. These roles must be defined and documented, preferably in a generic SOP covering the whole company. There are often four or five roles involved for a large computer system, but there may be more or fewer. The roles may also be assigned to groups governing the system, instead of individuals. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c07

JWBK188-Segalstad

120

September 15, 2008

13:21


Organization for an IT System

This chapter describes the various roles and responsibilities that you may need. However, each company may decide to create more, fewer, or different roles from what is described here. The Information Systems/Information Technology (IS/IT) department will have the responsibility for keeping the infrastructure, the servers, the clients, and other hardware working. The department is also responsible for performing backups, maintaining hardware, installing new software, and maintaining the systems, as well as for operating systems, databases, e-mail, and other items outside of each single computer system. The department performs upgrades, but the owners of the system in question order the upgrades under change control. In some organizations, one or more people are assigned responsibilities for a single application, such as the laboratory information system or the manufacturing system. In many cases, the IS department is no longer an internal department. Instead, the work is outsourced to a company that specializes in maintaining systems for other companies; however, the roles and their responsibilities are still the same. The system owner or sponsor takes responsibility for the system from an organizational and financial point of view. The owner could be a single person or a group of people from various parts of the organization that use the system in question. This group is called a steering committee and is described below. The application manager/system manager is a person assigned to be responsible from the users’ perspective. Both expressions are used for the same role, and ‘application manager’ will be used here. The application manager must know what the system is being used for. Members of the organization will always discuss whether this manager should be an IT person or a ‘user person.’ Some organizations will want to have an application manager from the Information Systems (IS) department, whereas others may want to have one of the users in this role. I believe that a user will usually be the best person for this role, as a user will know the work that the system is supposed to aid with. Besides, most computer systems are so easy to handle that computer experts are not needed as application managers. The application manager is responsible for implementing the system and suggesting necessary changes. Changes must be made in order to ensure optimal use of the system and may be made in the system itself, in the way work is being done, or in the organization. The application manager is responsible for having SOPs written for the system, for keeping track of all documentation, for updating the user handbook, and for training, but may delegate the work and not have to actually perform it. Super-users should be appointed in some or each of the departments where the system is used. Super-users act as first-hand trouble-shooters for the users and relay problems to the application manager as necessary. In a smaller system, the application manager might have this role as well. Suggestions for system changes may come from the super-users, who may also implement the approved changes. The Quality Assurance (QA) department also has a role for the IT systems: QA authorizes the SOPs, the validation protocols and reports for the system, and performs internal and external audits. QA may also comment on security issues. The QA person assigned to IT systems should be trained in IT validation. The user has a role too: as a user of the system. In complex systems, there may be different types of users, depending on their job in the organization, which should also be reflected in the users’ access to the system, when possible. This differentiated access may cover data or functionality, or both.

P1: OTE c07

JWBK188-Segalstad

September 15, 2008

13:21


Roles and Responsibilities for an IT Validation Project

7.3

121

Groups in the IT System Organization

Larger systems with many users may have groups with responsibilities for the system, such as a steering committee and a work group. The steering committee, also called the sponsor, is the Parliament/Congress for a system. This group will make the political decisions on how to prioritize the different tasks to be completed with the system, and say ‘yes’ or ‘no’ to suggested changes. For a large system, with users in various parts of the organization, a steering committee is definitely needed. Members of the steering committee should be recruited from the upper parts of the organization where the system is used, and it consist of either people from top management or people assigned by the top management. The members of the steering committee do not have to understand the technical parts or the use of the system, but they must be willing to cooperate with people in the work group who do. An organization that has a computer system with a nonfunctioning steering committee will eventually run into problems, as there will be no one to make necessary decisions about the system. This will also result in a lot of frustration for the system’s key people. The work group is the government or executive branch for the system. The work group consists of key people – such as the application manager, the super-users, and the IS people – either all of them or some of them. These are the people who know the system well from an operational and technical point of view. They must be able to communicate with the steering committee, which has little comprehensive knowledge of the technical parts of the system. This means that they must be able to translate technical issues into everyday language. They may suggest changes to the steering committee, as well as performing the changes suggested or approved by the steering committee.

7.4

Roles and Responsibilities for an IT Validation Project

The validation teams perform the validation. They do it by assessing and documenting the integrity, security, and reliability of the system, and determining whether the system is suitable for the intended purpose and meets the requirements and specifications. In an IT validation project, the roles are basically the same as for the live system, though the system manager is called a validation manager or a project manager. Sometimes there are both a project manager and a validation manager. The project manager can be a professional who is moved from one project to another and manages the resources (people, time, and money). The validation manager and the validation team members must have appropriate training in computer validation principles and methodology, as well as in system training, according to the tasks that they are assigned in the validation work. The system must be validated before going live. This is true not only for a brand new system, but also for new versions of an old system. A validation team includes roles that are carefully put together to: r ensure the right competence for each task r avoid unfortunate mixing of tasks and responsibilities, thereby putting the integrity of the documented evidence at risk r avoid loading too much work on any team member, thereby putting the quality at risk

P1: OTE c07

JWBK188-Segalstad

122

September 15, 2008

13:21



More specifically, this means that tasks may be shifted between the roles as long as you never: r approve a document that you have written yourself r execute a test that you have written yourself r approve a test that you have executed yourself

7.5

Outsourcing

Outsourcing is done in many companies, and outsourcing of the IT department has been a trend for quite a while. The organization leaves the infrastructure and the running and maintaining of the servers, including backups, to other companies – sometimes even in other countries – while reducing the internal IT department. The motivation for outsourcing IT is normally that this will create values for the company; others can do a better and cheaper job than can be done internally. These values are generally thought of in monetary terms, as these are easiest to calculate. Lower capital investment makes it possible to obtain noncore services at a lower cost and at greater efficiency. IT is both different and similar in this aspect. You will not find IT services in the regulations, as you do laboratory analysis, production, or packaging. However, IT is used to support the product, and adulteration can be done through an IT system as well as it can be done through other means. Even if an outsourcing company were never to touch the product, it could be held liable. The FDA expects to see records during their inspections. They do not state exactly how quickly, but ‘promptly’ doesn’t mean hours or days. How will you handle this when the off-shore company is on another continent? It is never acceptable to say, ‘I don’t know; I pay them to do it.’ The result may be that you are indirectly inviting the FDA to visit your supplier. It is your product and the agency expects you to have the answers. Outsourcing IT has the advantage of close proximity regardless of geographic location. The world is only a millisecond big – that’s the time it takes to connect one side of the globe to the other. It is well known that labor is cheaper in many parts of the world outside the United States and Europe. Outsourcing to the cheaper countries is called ‘off-shoring.’ This can be beneficial from a financial point of view. Unfortunately, many countries are unstable. How will you address business continuity when the cause of the problem (e.g., civil war, unrest, or natural disaster) is on a different continent? One unforeseen challenge may be that the contract is made with one local company, which later subcontracts parts of the job to a country with cheaper labor. What happens to the agreements? Is the understanding you thought you had with the original partners transferred? Will the quality still be the same as you agreed upon? There are regulatory concerns regarding outsourcing: The same regulatory requirements apply to the supplier as they do to your own organization. Responsibilities can never be outsourced. The FDA was questioned about this [1] and answered that from an FDA perspective, outsourcing or off-shoring is no different than any other contracted-out activity.

7.6

The Service Level Agreement for Outsourcing

The outsourcing process must include a phase where quality requirements and workflows are mapped, compared, and adjusted until the service provider and the organization are

P1: OTE c07

JWBK188-Segalstad

September 15, 2008

13:21


The Service Level Agreement for Outsourcing

123

both convinced that they understand each other and can fulfill each other’s needs. This process includes a very thorough supplier audit, which is described in Chapter 10. The audit must be extensive, so that it finds all possible problems and discrepancies. The audit group must comprise all of the competent specialists needed for the work to be completed and the equipment to be used. The mapping includes the As-is and To-be scenarios for each of the items in question. These may include infrastructure, databases, servers, and so forth. The benefits and challenges for both the As-is and the To-be scenarios should be discussed and mapped. Figure 7.1 shows an example from Rasmus Hother le Fevre [2]. Only outsource things that work in the organization. Problems are not solved by outsourcing – they are simply shifted. Regardless of what is outsourced, you need to understand the risks, the impact, and the mitigation strategy. A Service Level Agreement (SLA) must be created. The SLA must cover details of what must be done, how things are to be done, response times, action times, and other relevant issues. Responsibilities are, of course, very important. If the SLA isn’t good enough, the work won’t be done well. A secure service provider is not necessarily GxP compliant. I audited one of the largest IT service providers for a pharmaceutical company. The service provider manages data for banks and other financial institutions, in addition to many other industries and organizations. As the service provider also runs several of the banks’ Internet banking facilities, security is vital. One would think that as they had adequate systems for these important issues, they would be perfect for the pharmaceutical industry; however, the audit showed that

Outsourcing of Servers Benefits TO-BE

AS-IS •Local support and knowledge •Independence of external vendors •100 % influence on server operations

•Access to large support organization •Major reduction in infrastructure servers •Access to all servers from one location •Surveillance of event logs and hardware including GxP Critical reports •The design will enable consolidation with other plans at a later stage

Challenges TO-BE

AS-IS •One isolated domain per factory causes very complex infrastructure •Limited 24 x 7 support •Time and cost consuming infrastructure because the plans are physically separated •Applications/servers are “duplicated” due to physically separated networks

• Collaboration between employees from both organization •Reduced internal IT domain knowledge

Figure 7.1 Outsourcing As-Is and To-Be. Reproduced, with permission, from Rasmus Hother le Fevre.

P1: OTE c07

JWBK188-Segalstad

124

September 15, 2008

13:21



they had inadequate change control and no control of the historic documentation. They changed versions of the software and tested that it worked. The testing had no formal test plans, and testing was done without creating any documentation or any reports; old versions of the software and the user documentation were thrown out as soon as the new versions replaced them. The pharmaceutical company explained to the service provider that this didn’t comply with GxP, and included requirements for handling changes, testing, and historic documentation in the SLA. This did add costs to the service, but the GxP requirements were fulfilled.

7.7

Consultants

Consultants are used more and more frequently to compensate not as much for missing knowledge inside the organization, but more for missing manpower. A consultant provides two extra hands and one extra brain that the organization does not have internally; however, it is important that the organization does not let the consultant do the job without any control or requirements. At the end of the day, it is the hiring company that has the total responsibility for the job the consultant did. Hiring consultants and keeping them ‘under control’ can be done in at least two different ways: Either work with the consultant, pick the consultant’s brains and learn along the way, and hence understand what is being done; or give the consultant a thorough Requirements Specification for what must be done and let him or her do it. Generally, the consultant will also need a great deal of information to merge his or her field of knowledge with the knowledge of how the specific company operates and is organized. It is my opinion that the only correct way is to work with the consultant, as the consultant alone never has sufficient internal knowledge to do a good job for the organization. Regardless of who has actually done the work, the organization using the system has total responsibility for the quality of its products and the way in which the information about its products was obtained. No matter which parts of the company are outsourced, it is a challenge for the quality of the drugs and documentation produced (GMP is also ‘known’ to mean Giant Mass of Paper). Even if both parties are using GMP/GLP/GCP requirements, the quality of the work may differ. The reason for this is that the standards are vague, and include elastic words such as ‘adequate’ and ‘sufficient.’ The standards leave it to companies to define what ‘adequate’ and ‘sufficient’ translate to in their particular organizations; SOPs in the two companies may even conflict. While pharmaceutical organizations are used here as an example, the same applies for other organizations. Consultants are normally used for one job at a time in the organization. The reasons for using consultants vary. In the 1980s, companies had all the necessary manpower internally. They had people with all of the appropriate skills, and if skills were lacking, existing people were trained or new people were hired. Consultants were used, but in secrecy. It was regarded as a failure not to have the skills internally, and one does not brag about failures. With the paradigm shift of the 1990s, companies were downsized and the number of internal personnel was drastically reduced. There was a shift from ‘we know it all’ to ‘we can buy the knowledge that we do not have.’ Knowledge was bought, or to put it in more politically correct terms, work was outsourced. The hiring of consultants gradually changed from being a secret, through acceptable, practice to something desirable that everybody talked about doing. It is simple to hire

P1: OTE c07

JWBK188-Segalstad

September 15, 2008

13:21


Consultants

125

consultants, and there are plenty of them on the market. Companies do not have any responsibilities for further employment once the consultant has completed the agreed-upon task. The result is that companies rely more and more on support from consultants, and there are several reasons for this: Some companies lack the technical expertise; however, this trend seems to be reversing. Many companies have the knowledge but don’t have the business experience to apply that technical knowledge. Others have the knowledge but not the available manpower for the job, and this group is growing with the added efficiency requirements that everyone has to adhere to. In other cases, companies lack confidence in their ability to evaluate options, or doubt their ability to implement the solution. In yet other cases, there are individuals who can’t convince their management that the solution is good, so they ask the management to use a consultant to make an independent verification. Seen again and again is the fact that the well-paid consultant’s words carry a lot more weight than those of the employees. It is frustrating when management has not listened to you for years, and then they will actually listen to a consultant who is saying the same thing as you did. Use the consultant to make your statement for you. You won’t get the credit, but maybe what counts is that things actually get done. The use of consultants has several advantages: The company doesn’t pay for training, as the consultant is, of course, expected to have the knowledge already; the company has no employer obligations, and is relieved of having to pay the consultant’s salary once the job has been completed. The disadvantages are that the hourly or daily rates are high, and that knowledge of what was done might be lost once the consultant leaves. The latter is serious, as the company is still left with the responsibility when the regulatory bodies, including the FDA, perform inspections. Knowledge transfer is rarely included in the task description for the consultant, but should be present in all parts of the communication between the company and the consultant. It is therefore extremely important to choose the right consultant for the job. The consultant must, of course, have knowledge in the field. As a student, you are sure to have had teachers who had knowledge but not the ability to transfer that knowledge to their students. Skills such as understanding people and human relations, as well as good communication skills, are therefore important. The consultant’s integrity and objectivity to view the problems in their right light, together with a problem-solving ability, are the basis for getting something done. Good technical skills are a must and need to be blended with a creative imagination, as no company and no problem is identical to the last one. Some people have technical skills rather than advisory skills. A purely technical person usually takes his or her skills to work every day, and then back home in the evening. Consultants should be advisors who counsel and give advice, who know their limits, and who do not go beyond those limits. The consultant has expert fields of knowledge, but rarely has knowledge of your organization, your ways of working, your computer system, and your quality system. Both parties must contribute with knowledge and training, which makes communication skills important. Interviewing the consultant will tell you if you are able to communicate with each other. Some people call it ‘chemistry,’ even if it has little to do with that science. Good communication will gain mutual trust, which is important in order to work together. And don’t forget that you have to live with the solution long after the consultant has left. Do your best to make the solution a good one. The consultant can be used for much more than the tangible tasks you included in the contract. First of all, this is a good opportunity to learn more by using the consultant as a sparring

P1: OTE c07

JWBK188-Segalstad

126

September 15, 2008

13:21



partner in discussions, or by picking the consultant’s brains for information/knowledge. A good discussion can contribute to a better solution. Even if the consultant is ‘the expert,’ you also have a lot of knowledge. Sometimes even your ignorance in the field is the best contribution, as you may ask the ‘stupid’ questions with the ‘obvious’ answers, which may not be so obvious after all when the consultant tries to explain them. The consultant’s knowledge will ‘rub off’ on you during the process, and most people enjoy learning something new. Your knowledge will also add to the consultant’s understanding and knowledge, so it will be a learning experience for both of you. A good consultant teaches while working with other people, and explains what is being done and why. Consultants have gained experience in many different companies, and may be able to make a number of suggestions based on how things are done in other companies – without, of course, revealing where those suggestions come from. While there are many ways to use a consultant to get things done, there are also many ways to misuse the consultant. Most of these include lack of communication and interest in what the consultant is doing, some consciously and others due to lack of time to get involved. Letting the consultant do the whole job without involving yourself isn’t fair to either of you. Not only are you misusing the consultant’s time, but also your company’s funds that pay for that time. With your involvement, things may be done more quickly and more correctly. You need to ask the consultant what information is needed, and to volunteer information that may be relevant to the task. So, even if you have agreed that the consultant is to carry out the task, you need to be involved. ‘You’re the expert, so let’s do what you say’ isn’t a good attitude. In fact, it isn’t even fun for the consultant to hear. The consultant may be the expert in the field, but you are the expert in what the company does and has. Question the consultant’s suggestions and decisions, and do not denigrate the consultant’s competence, but do understand what the consultant is doing, and contribute with your observations and your objections as to why this should be discussed once more. Remember that you have knowledge that the consultant does not have. Don’t do something just because the expert is saying that you should. Do it because it is the best thing to do, all relevant information taken into consideration. People who feel threatened by external expertise will often do their best to make the expert fail. If you are in this category, you should follow this approach: Don’t bother to inform the consultant about things that he or she might need to know. Likewise, keep your mouth shut whenever you have opinions that differ from those of the consultant. The fact that your opinions and knowledge are not taken into consideration just proves that the consultant is no good. Finally, of course, complain to everyone but the consultant about the stupid work that the consultant is doing, or – even better – wait until the work has been completed. Needless to say, this isn’t an acceptable approach.

References R 1. McClenney, N., SEC Associates, Inc. (2006) Presentation at GAMP Nordic Meeting, October 5, 2006. R Nordic Meeting, October 5, 2006. 2. Hother le Fevre, R. (2006) Proceedings of GAMP

P1: OTE c08

JWBK188-Segalstad

September 16, 2008

10:56


8 The Legal Implications of an IT System


Legal aspects of IT systems Financial systems Healthcare systems Systems for legal information

8.1

Introduction

IT systems may have various legal implications. It is well understood in the pharmaceutical industry that IT systems handling regulated data have to comply with the regulations for IT systems. In the regulated industries, the legal aspect is usually international rather than national. It is generally less understood that financial/economic systems also need to be under control, as these also handle legal data. One challenge is when the financial system or other non-GxP functions are integrated into the GxP system. This is common for several financial/manufacturing/warehouse systems. Whether these systems can be handled with differentiated validation levels depends on how well these parts are integrated. A thorough understanding of the system combined with risk assessment is needed to decide whether the various parts of the system can be handled differently. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c08

JWBK188-Segalstad

128

September 16, 2008

10:56


The Legal Implications of an IT System

As mentioned earlier, 21 CFR Part 11 [1] applies only to the FDA-regulated industries. But the document holds very valid requirements for electronic records and electronic signatures in any industry. Following the technical, procedural, and validation requirements here will ensure that the system is under control, which is also a must in most of the abovementioned types of computer systems.

8.2

Pharmaceutical Regulations

Regulatory systems include those controlling regulatory processes, those that collect, handle, and report regulatory data, and those that manipulate or calculate regulatory data. These systems need to comply with the regulations. Electronic signatures are usually optional, but if they are used, it is important that they are handled in a good and controlled manner, according to the regulations. The regulations are described in Chapters 1 and 2. If, for example, a pharmaceutical company uses data from the system for its products under GMP, GLP, or GCP, the system is a regulatory system and needs to be handled accordingly. This means validation based on risk assessment. If it isn’t based on risk assessment, complete validation is needed. Validation is described in Chapters 11–16.

8.3

Financial Systems

Most financial/economic IT systems must comply with national laws for accounting and taxation. The common consensus seems to be that as long as they give the right results, they are fine and can be used. Errors are fixed as quickly as possible, but it is hard to tell whether the rest of the system actually works correctly. The question is, of course, how can they know that when they haven’t validated the system? There’s no proof that it works. Financial authorities don’t want to see proof that systems do the right thing. They are only interested in the end result, which is correct book-keeping and thus the correct tax payment. This is generally cross-checked between the financial systems and the tax authorities’ systems, the input being the received output numbers from the business. There are a few other control points as well; in Norway at least, banks have to give the tax authorities all the banking information for all of their customers. It is relatively uncommon to validate these types of systems to the same degree as GxP systems. The reason is that they are expected to work correctly and that the users of financial systems are not trained in validation. It is also hard to persuade anybody to validate a system when there are no external requirements to do so. Change control, controlled documents, and other quality features that are normal in the regulated environment are relatively unknown, even for large service providers in the financial sector.

8.4

Patent Systems

Several systems may hold information that is used for patents. These include Electronic Lab Notebooks (ELN), Laboratory Information Management Systems (LIMS), and other systems that are relevant to storing data for current or future patents. It is crucial that these

P1: OTE c08

JWBK188-Segalstad

September 16, 2008

10:56


Systems for Legal Information

129

systems are under control so that it is possible to prove that the entries were made at a certain date and not changed subsequently. These systems should be technically compliant with 21 CFR Part 11 and should include a complete audit trail. It is quite common to relax on the quality standards when working in the exploratory area, and to be more stringent when the results of the work seem to get closer to being a project or product. From a patent point of view this is very unfortunate, as that may mean that others can prove that they worked on these things before you did, and you can lose a patent based on sloppy documentation. The conclusion is that even in an exploratory phase, the Quality Assurance of the data and of the computerized systems holding it must be adhered to. ELN is described in Chapter 17 and LIMS is described in Chapter 18.

8.5

Human Resources Systems

Human Resources (HR) systems that carry information about people also have legal implications in some countries. In Norway, for example, permission is needed from the authorities to have a computer system in which collected personal information is stored. That doesn’t include systems where the person is identified as a user by name and ID. But if the system includes more personal information, such as a person’s marital status, who their spouse is, details of their children, their home address, and their social security information, income, or tax information in any combination, then permission is needed. HR systems are also used for generating user IDs in the organization and will therefore also be regarded as GxP systems in the pharmaceutical industry.

8.6

Healthcare Systems

Healthcare systems are hold patient data, which is vital information for each patient. A mixup involving a patient’s name and their data can have devastating results; both for the one patient who doesn’t get the treatment needed, and for the other patient who gets treatment that isn’t needed and is potentially harmful. These systems may also communicate with other healthcare systems, and it is obvious that each system, as well as the communication between them, needs to be validated, to include the security mentioned in Part 11, and generally to be kept under complete control. Furthermore, these systems hold sensitive data, and access to it should be restricted to a need-to-know basis. The legal aspects of these systems include the danger of lawsuits, and the ability to prove that the system was working and not mixing things up. A complete audit trail will also show who accessed the system, what was done or looked at, and when this was done.

8.7


Police systems, customs systems, and immigration systems contain data that is used for legal purposes. The data held in these systems may have very considerable legal implications

P1: OTE c08

JWBK188-Segalstad

130

September 16, 2008

10:56



Table 8.1

Disputes about Legal Speed Measurement.

In Norway, the police are strongly enforcing vehicle speed limits. This is done in two different ways. Automatic Speed Measurements Automatic measurements are done from permanent installations along the roads. Here, the speed is measured, and the car is photographed if speeding. A fine notice is then mailed to the car owner, who has to identify the driver. If the fine is isn’t paid, the driver will be taken to court. Few have disputed the measurements and the fines are generally accepted. I know of one exception: A friend who works in a calibration laboratory was caught several years back. He neither admitted nor denied that he had been speeding, but he asked for the calibration procedures for the measurement devices, and proof that they had been followed. The police answered by sending him the notice again, and he repeatedly asked the question, saying that he wanted to contest the Quality Assurance of this in court. The police then told him to forget about the fine. The conclusion drawn by the calibration engineer was that not everything was as it should have been. He later told this to a friend who worked for the police, and this person said that ‘the only ones who don’t have to pay the fines are those, usually calibration people, who ask for proof of Quality Assurance.’ The question is: Where is the integrity of the system? How can they defend having a system that does not have adequate Quality Assurance and use this for fining people? Scary, if you ask me! Whether the procedures have been changed or not after this story from a few years back is unknown, but one can certainly hope so. Laser Measurements For some obscure reason, laser measurement instruments have a display only, and no way to print out the result with a date and a time. The police operating the device must be trained in using it, and must hold it very still during measurement. Wrong use has proved that bridges move, which in all likelihood they do not in an earthquake-free country. The display must be shown to the offender, who must sign to say that he saw it. The procedure also stipulates that the police must sign to the effect that the measured result has been controlled against the data for the measuring device. In a case that was taken all the way to the Supreme Court (Case HR-2007-00017-A), three questions were answered by the court to the advantage of the offender. The procedure for logging and control of the laser measurement devices was not followed: • The policeman did not sign to the effect that the measured result had been controlled against the data for the measuring device • The offender was not shown the display • There was no proof that the device was held still during measurement The Supreme Court judges emphasized that measurements must be carried out and handled in such a way that people can trust that they are good. Otherwise, people’s legal security and also trust is compromised. It is important that there is no doubt that the measured result is accurate and correct.

for the persons involved. The sentencing or acquittal of a person may be the result of the data stored, collected, and maintained in such systems. It is sometimes literally a matter of life and death that these systems work correctly, with full traceability (an audit trail) of who has done what in the system, when, and why. It must not be possible for anyone to tamper with the information without leaving an audit trail.

P1: OTE c08

JWBK188-Segalstad

September 16, 2008

10:56



131

Immigration systems help with access to a country and depend on the information in identification systems used by the immigration authorities. These may contain biometric information as well as passport information for millions of people. Identification of people based on fingerprints is used heavily by the police in EU for immigration and other legal purposes, and has resulted in better cooperation between the European countries. Fingerprint systems and retina scans are used together with machinereadable passport information by the US immigration authorities at all airports and at many other entry ports to the United States. Police systems such as the Automatic Fingerprint Identification System (AFIS) in the United States help the police work across state borders to find people who are also responsible for crimes in other states. The police also use automatic speed monitoring systems on the roads. These systems measure the speed of a vehicle and take a photograph if it is above the limit. The vehicle is identified from the photograph, and a fine is mailed to the owner. Needless to say, these speed measurements need to be calibrated. Laser measurements and radar measurements for the same purposes also need to be calibrated. This technology has been disputed, as described in Table 8.1 The police also use breath analyzers to check whether a driver has drunk too much. The older types show only if the reading is above or below the limit, and a blood sample is taken to determine the level of alcohol in the blood. The newest types, called ‘breathalyzers’ give the ‘final answer’ directly, and must be calibrated, as there is rarely a chance to get a second opinion by taking a blood sample. This technology has also been disputed, as described in Table 8.2 . All the laboratory systems handling samples for the police also need to be calibrated, maintained, and validated. Built-in security, such as the requirements stated in 21 CFR Part 11, is a must. Furthermore, it is vital to have complete traceability of the samples collected at a crime scene or by customs, through moving the samples to a laboratory, analyzing them, and reporting them. This is called a ‘chain of custody.’ If a link is missing, it is impossible to Table 8.2

Breathalyzers.

The project leader for the ‘breathalyzer’ development talked during the conference on Measurement Techniques in November 1999 about how this system was developed to make sure that alcohol content was measured correctly in the outgoing breath. Actually, it isn’t the ethanol that is measured, but one of the broken-down compounds. A large number of organic compounds were tested to see whether these would influence the measurement: A lot of method validation was done to prove that they did not. The instrument was a foolproof magic box: Breath input, and display output which showed the content of ethanol. A lot of programming was packed inside to give the output, and the operator could not in any way influence the result. I asked what they had done to validate this very sophisticated software. The answer was ‘Eeee, I am sure we did.’ – which made me sure they had not done anything, when he could not give any details at all. If I were to get caught by this instrument, I would contest the Quality Assurance of the output values. Unfortunately, there is no chance, as I never drink any alcohol when I know I will be driving. This was years ago, and they might have done something by now.

P1: OTE c08

JWBK188-Segalstad

132

September 16, 2008

10:56



Table 8.3

The Chain of Custody in a Narcotics Case.

My former colleague Magne Synnev˚ag used to be a QA. He has changed his career to become a lawyer. One of his clients was stopped by customs when driving off a ferry. They took him away from his car, looked around, and found five packages of something in the car’s gas tanks. They took him back and confronted him with their findings, which he denied having any knowledge of. The packages were sent to the police laboratory, where they found the content to be narcotics. However, several mistakes were made during this process, which lawyer Synnev˚ag decided to do something about: • The driver was not there when they searched the car. There was no proof that the packages were not planted by the customs (however, there is no reason to believe that they were) • Only two of the packages received an identification number, but none were logged as belonging to this case on site by customs • There was no chain of custody, and nobody knew who had handled them between their being found in the car and their arrival in the laboratory. This means that they could have been switched at any time with more potent material and no one would have known. Inside the laboratory, there was a chain of custody • Lawyer Synnev˚ag asked to inspect the customs procedures for handling findings, and the laboratory’s procedure for the chain of custody, the validation of analytical methods, and other Quality Assurance items that could affect the outcome of the court case. This request was denied by the prosecutor From a Quality Assurance aspect, where the lack of QA could cause an innocent man to spend several years in prison, this was an interesting case. However, that aspect never went to court, as the man decided to cooperate with the police to find the receivers of the goods and get them prosecuted.

prove that the samples collected are those that were analyzed and reported. The wrong person may accidentally or deliberately be linked to the wrong sample. Again, this technology has been disputed, as described in Table 8.3 .

Reference 1. US FDA (1997) 21 CFR Part 11 Electronic Records; electronic signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov.

P1: PIC c09

JWBK188-Segalstad

September 15, 2008

13:25


9 Advanced Quality Management Systems

This chapter discusses the following: r Which external and internal changes will affect the QMS r How to keep the QMS updated r Training and understanding quality

9.1

Introduction

The main objection against a Quality Management System (QMS) is that it leaves no flexibility as to how things are to be done. My view is that if this is true the QMS has not been made well. A good QMS will help the organization to carry out its tasks consistently and document them well. The work done will then be independent of the person doing it, as everyone will be working in the same way. The QMS is a great tool for the organization – not a straightjacket. I once wrote a QMS for an organization, and one of the staff was very hostile when approached for interview about his job. After a long time, the reason was found: He didn’t want an external consultant to tell him how to do his work. When he finally realized that it was actually the opposite that was about to happen, he was a lot happier. He explained how the work was done and how it was documented. The result was that he could finally let someone else take over his job when he wasn’t there, instead of having to do everything himself when he got back. The QMS was an advantage. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: PIC c09

JWBK188-Segalstad

September 15, 2008

13:25


134

Advanced Quality Management Systems

9.2

The Live QMS is a Good QMS

The world is changing. New regulations replace old ones, and old regulations are given new interpretations as well. The main change in the regulations during the past few years has been the risk-based approach, which is discussed in several of the other chapters of this book. The regulations are remarkably free of technology and solutions, which makes it possible to keep them unchanged for what seems like decades, as the GxPs have been until recently. Work processes change constantly and organizations are frequently reorganized. The QMS needs to be changed accordingly, as every change has a potential impact on the QMS. The main problem is often that ‘We’re so busy with this new stuff that we don’t have time to change our SOPs.’ The FDA’s answer to that is that ‘There is one thing worse than not having SOPs. That is to have SOPs and not follow them.’

9.3

Changes

Regulations change, though not very often. However, it is necessary to be alert and notice when new regulations are about to be changed. Guidance to regulations changes as well. One example is the various guidance documents for 21 CFR Part 11 [1] that came out as drafts from the FDA, some well founded and some not exactly well founded. They all caused discussions about the interpretation of Part 11. The FDA suddenly withdrew them all and issued a new guidance document [2]. Interpretations also change. This is especially true for new regulations, where there is little precedence for interpretation and where the regulations are unclear. Again, Part 11 can be used as an example. The question of which systems or applications were to be in compliance with Part 11 swung like a pendulum from one side to the other. If you did not want to validate Word, documents written in Word could only be used when printed out on paper. Some argued that you could not even store the documents electronically. You could, but you could only use them on paper, argued others. After 10 years, most people have a relatively good understanding of how Part 11 should be interpreted. It also helps to see the warning letters issued by the FDA, as these show how the agency interprets their rules. These are available from the FDA home page (www.fda.gov). Unfortunately, there is no equivalent web page for the EU. Responsibilities change in the organization. People move on to other responsibilities internally, or to other organizations. Work processes change as well, and the procedures describing these need to be changed accordingly. Procedures that use roles instead of names need not be changed if roles have not been changed. But people need to be assigned roles, usually in their job descriptions, so it is possible to find out who is actually responsible for doing a specific task. It is vital that people know which roles they have been assigned. The technology and tools used also change. New ‘gadgets,’ instruments, and IT systems are added or upgraded.

P1: PIC c09

JWBK188-Segalstad

September 15, 2008

13:25


Training and Understanding

135

Organizations change due to mergers or splits of companies, or due to internal reorganization. All these changes need to be reflected in the QMS.

9.4

How to Keep the QMS Updated

It is easiest to keep the QMS updated when everyone in the organization understands what a great tool the QMS is. When they all have the Quality Assurance understanding ‘under their skin,’ so that they are thinking in a quality way, they will all know when some parts of the QMS need to be changed. However, people are individuals with their own agendas, and the QMS isn’t foremost in everyone’s mind. There is also a good chance that whoever finds that an SOP needs to be changed will get the job if he or she passes that information on to others. Regular reviews of the QMS are therefore a necessity. Many organizations state that this shall be done every two years. The problem is that if it is done only every two years, the SOPs can be outdated for an unacceptably long time. It is important to have alert and quality-conscious personnel who remember that SOPs need to be changed when the workflows they describe change – and who make sure that they are changed accordingly, as soon as possible. People need to follow the SOP when they do their jobs. Whenever changes are needed, the SOP needs to be changed as well. These changes will be initiated by different people, depending on the reason for the change. The change in workflow description is normally initiated by the users when they change the workflow. Changes in standards and in other parts of the QMS may be initiated by QA or others in the organization. Understanding that these changes are needed is also a part of training. The quality management system needs to be dynamic in order to be good. It should follow the principle ‘Say what you do and do what you say.’ This principle can only be followed if the QMS is kept alive and maintained when needed, and not only every two years or whatever the system prescribes for the time between reviews.

9.5

Training and Understanding

An understanding of quality is what makes quality products. This is a long process that starts with the important step of training. People need to understand that the QMS must be kept up to date. Unfortunately, it takes more than a few days of training to really understand quality and start ‘thinking quality.’ It takes even longer to get the quality thoughts under your skin, and the only way to do this is to work with quality for some time. Training, whether this is based on GxP, on ISO, or on any other standard, is a good starting point. Most organizations with a quality system require their new employees to undergo a lot of internal training, where the QMS is one of the topics. The employees need to know what the QMS includes and how it works. Equally important is the fact that the QMS is a live system and that it is everybody’s responsibility to maintain it. Frequently, companies will give the responsibility for named SOPs to named persons, so that they can

P1: PIC c09

JWBK188-Segalstad

136

September 15, 2008

13:25



maintain them. That does not relieve the rest of the personnel from responsibilities for this SOP. They are required to suggest change when they see a need for change. After the initial induction, there are differing approaches to further training. Many organizations have a system for informing people of new SOPs and making sure that they are either taught formally or read by each person. To make sure that the employees have received the information, they require a receipt that the SOP has been read, and a note is made in the training log for each person. Some organizations also arrange tests to check that people really have understood the content of what they have been taught. It is a lot of work to create and correct these tests, but the organizations using this methods claim that it is worth the effort.

9.6

How to Use a QMS Effectively as a Tool in the Organization – Not as a Straightjacket

Chapter 4 explains how procedures need to be written so that they describe how things are to be done while at the same time flexibility can be maintained. All too often, the first attempt to write a QMS is too detailed, with little or no flexibility. The result is that the QMS is a straightjacket for the organization. Few people understand why they need such a system when they are used to working as they please, with a great deal of flexibility. The result is either that they give up on a QMS or that they make the next version too flexible, so that it barely describes what is to be done and how. The pendulum is now swinging in the opposite direction compared with the first attempt. The key is to take the middle road: Flexibility while accurate procedures are maintained. The procedures should be written so that they can easily be followed in order to do the job correctly, and at the same time allow room for flexibility in how things are done. It is important that the procedures also set out how the job is to be documented. How the job was actually done within the stated flexibility needs to be documented as well. An SOP for how to qualify the static data in a Laboratory Information Management System (LIMS) can be used as an example. This was written for a particular organization and has been used ever since. The SOP covers many types of qualifications for template (static) data. It first explains what each of the qualifications means, and then covers each of the static data types. The extract is about reports used by LIMS. Table 9.1 gives the text within the SOP, the explanation as to how the SOP can be tested, and test plans. Why was it written this way? r By having the test plan in the SOP, it will not be necessary to have QA approve each test plan r At the same time, it is obvious that the people doing the qualifications really need to know what they are doing. Otherwise, it isn’t possible to do a good job, as the descriptions are not good enough. In this case, the people qualifying the templates had a lot of education and hands-on experience of the system and how it worked, as well as knowledge of validation and qualification r It is up to each person to understand what they need to do to qualify each report, but the training and experience (as required in other SOPs) makes it possible to be flexible while maintaining the quality of the work done

P1: PIC c09

JWBK188-Segalstad

September 15, 2008

13:25


How to use a QMS Effectively as a Tool

137

r While the plans are rudimentary, the requirement for the documentation is not. The documentation will show what was done and can be audited to see if it was done well enough. As stated somewhere else in the SOP, QA needs to approve the work before it can be taken into live use

Table 9.1

The Text in a Standard Operating Procedure for Qualification of Static Data

Reports (text in SOP) The qualifications shall be done in the test instance. After approval the setup shall be moved to the production instance, following SOP xxx LIMS Instances and Export of LIMS Data. An IQ shall be done for the moved data in the production instance. IQ of the report is not done in the test instance. It should be tested that the report is installed correctly in the production instance, and that the correct group has access to it. However, a formal IQ is not needed. OQ: The OQ for the report may be done directly on the tables before the report is installed in LIMS, or from within LIMS after the installation. Alternative ways of retrieving information from the database may be used. The retrieved data shall be the same for the report and the LIMS/tables. Parameters in the report used for the selection criteria (e.g., the report ‘Sample results’ will have a parameter that asks the user which sample is to be reported) shall all be tested, preferably in various combinations. The qualification shall include that mandatory fields in a report are there, and that further requirements for layout and so on have been fulfilled. If the report is created based on a User Requirements Specification (URS), the qualification shall include all stated requirements. PQ: The PQ for the report checks that it can be run from inside LIMS. Guide to Reports OQ/PQ Method: The OQ for the report may be done directly on the tables before the report is installed in LIMS, or from within LIMS after the installation. Alternative ways of retrieving information from the database for comparison may be used, such as SQL statements, LIMS screens, and so on. The retrieved data shall be compared and be the same. Check points: – The report has been created according to the SOP xxx. The qualification shall include that mandatory fields in a report are there, and that further requirements for layout and so on have been fulfilled. – If the report is created based on a URS, the qualification shall include all stated requirements. The specification shall be enclosed. – Parameters in the report used for the selection criteria shall all be tested. If two or more parameters are used for selection criteria with AND or OR, various combinations shall be tested. For example: The trend report will have one parameter asking the user which sample type is to be reported and others asking for the time span or the number of batches to be reported. – PQ: The report installed in LIMS shall be possible to run from within LIMS. (Continued )

P1: PIC c09

JWBK188-Segalstad

138

September 15, 2008

13:25



Table 9.1

(Conti nued )

OQ/PQ LIMS Report name: Check item The report had been created according to SOP xxx OQ of the report was tested

Details of checking/Comments

Ref.

Outside of LIMS Inside LIMS

All parameters tested Combination of parameters tested (fill in details below): PQ of the report tested inside LIMS Other: Enclosed: URS for the report Numbered reference documentation (including comment sheets, reports, screen dumps, SQL queries, etc.) Testing

Tested data

Tested by (full name)

Signature

Approval for use

Approved date

Approval by (full name)

Signature

One way to improve the QMS is to actively make use of the errors found to see whether they can be eliminated. This is called Corrective Actions – Preventive Actions (CAPA) and is described in detail in Chapter 5. Corrective action is defined in ISO 8402 [3] as ‘Action taken to eliminate the causes of an existing nonconformity, defect or other undesirable situation in order to prevent recurrence.’ Preventive action is defined as ‘Action taken to eliminate the cause of a potential nonconformity, defect, or other undesirable situation in order to prevent occurrence.’ ISO 9001 [4] includes a requirement for continuous quality improvement. It may be difficult to measure quality and even more difficult to measure whether it has been improved. One way to do this is to create some kind of metrics for the work done. This can measure which problems are found and how these problems are solved. For a support organization, errors found and reported for the system can be measured, as can the time it takes to solve whatever problems the customers report. This makes for an active approach with regard to improvement. Regardless of the external standards used in the organization, it is important to have an active approach to quality and to have control over processes.

P1: PIC c09

JWBK188-Segalstad

September 15, 2008

13:25


References

9.7 9.7.1

139

Tasks Changing Times

In its view on how much to do, the FDA has moved from a do-it-all approach to a risk-based approach. It is now up to the organization to assess the risks and what to do about them. How would this impact the work to be done in the organization? 9.7.2

Training

Discuss the various approaches to training. What is good and what is bad for each of these approaches? How would you organize quality system training so that people would spend sufficient time to really learn it properly – and still keep a positive attitude? 9.7.3

Cooperation – The Quality Management System

EU GMP Annex 11 has the following text: ‘The software is a critical component of a computerized system. The user of such software should take all reasonable steps to ensure that it has been produced in accordance with a system of Quality Assurance.’ Discuss what ‘all reasonable steps’ would be. Does this depend on the system itself, the supplier of the system, the use of the system, the number of users, system criticality in the process, or other factors? 9.7.4

Create a CAPA SOP

The SOP should cover error handling, and should include CAPA. Remember to use headers and footers and all other elements of a formal SOP as described in Chapter 4, using either your own invention or your company’s standard. 9.7.5

A Change Control SOP

Create a change control SOP for IT system changes in the organization. Include a flowchart to make it easy to see what must be done. Include all the text needed in such an SOP. Remember to include headers and footers and all other elements of a formal SOP, using either your own invention or your company’s standard.

References 1. US FDA (1997) 21 CFR Part 11 Electronic Records; electronic signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 2. US FDA (2003) Guidance for Industry, Part 11, Electronic Records; Electronic Signatures – Scope and Application, US Food and Drug Administration, Rockville, MD, www.fda.gov. 3. ISO 8402-1989 (1989) Quality Terminology, International Organization for Standardization, Geneva, Switzerland (the standard has been withdrawn). 4. ISO 9001:2000 (2000) Quality Management Systems – Requirements, International Organization for Standardization, Geneva, Switzerland www.iso.org.

P1: PIC c09

JWBK188-Segalstad

September 15, 2008

13:25


P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


10 Audits


Different types of audits How to perform an audit What to look for Receiving an audit

10.1

Introduction

Pharmaceutical companies have been working with their GxP quality regulations for decades. They know that they have to control what they do internally and what their vendors/suppliers do. There is no difference between the use of the words ‘vendor’ and ‘supplier.’ As several standards prefer to use the word ‘supplier,’ it is used here. The suppliers may be supplying raw material, equipment, or services. The latter is often outsourcing of work or tasks that were previously done internally. Sometimes a computerized system has two different suppliers: one that has programmed the system, and one that helps implement the system. During the past decade, more industries and companies have decided to comply with quality standards such as the ISO 9000 series (see www.iso.org) and have made the decision to get a quality certification. A certified company will want to purchase goods from other ISO-certified companies to ensure the quality all the way through to their customers. Companies without a certification, or without a quality system, will probably lose contracts. The result is that they will want to get their own quality system, and may eventually want to get it certified. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c10

JWBK188-Segalstad

142

September 30, 2008

11:59


Audits

Checking a quality system and its use is done through an audit. There are three different types of audits: First-party: Second-party: Third-party:

Performed by Quality Assurance (QA) in house. Performed by the purchaser on his supplier’s quality system. Performed by an accredited audit team on behalf of a certification body with the scope of quality certification.

Each of these must be done by people who are independent of whatever is audited. A first-party audit is done by QA people who have not been involved in the work that is covered. A second-party or third-party audit must never be done by somebody who has been involved in, or has been employed by, the company during the past five years or so. The second-party supplier audit is covered below. In principle, a first-party audit is done in the same way even if the roles included are slightly different. Certification organizations, also called certification bodies, accreditation organizations, and regulatory agencies, each have their own way of carrying out a third-party audit.

10.2

The ISO 9000 Series

An ISO 9001 [1] or equivalent certification tells you that the company has an adequate quality system in use, but it does not say anything about the quality of the goods that the company sells. It has been said that according to ISO you will be in compliance if you sell concrete life vests, as long as that is documented. This isn’t true, though. ISO 8402 [2] defines quality as ‘The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.’ Concrete life vests can hardly fall into the characteristic of satisfying implied needs. When checking the supplier, ask to see their certificate and read the scope thoroughly. It is possible to have only parts of the company certified; for example, their customer service might be certified, but not their production. ISO 9001 covers design/development, production, installation, and servicing in general, and is more easily applicable for mechanical production than for software. ISO 90003 [3] was issued to help the software industry interpret ISO 9001.

10.3

TickIT

Companies that develop, supply, and maintain software may want to use the ISO 90003 guidelines for their quality systems if they want their system ISO 9001 certified. This can be done within the so-called TickIT Scheme [4], which uses ISO 90003 as the guideline to ISO 9001. The TickIT Guide [5] covers ISO 90003 and purchasers’, suppliers’, and auditors’ guides, in addition to other information. Anybody can purchase the TickIT Guide, which can provide valuable information on what to expect and how to perform the audit. TickIT originated in England and is still based there, but it is now widely spread internationally in Europe, Asia, and America. Few accredited certification bodies have TickIT auditors. In order to become an approved TickIT auditor who can certify under the TickIT scheme, it is necessary to have fulfilled a long list of criteria: a computer education,

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


Why Audit?

143

computer programming experience, Quality Assurance work experience, auditing experience, and a special examination. This gives a common baseline for the high level that is demanded of the company to be certified. Lead TickIT auditors run courses with final examinations for people who want to know more about Quality Assurance of computer systems, using ISO 90003 as a guideline for ISO 9001. The examinations are mandatory to become a TickIT auditor, but these courses are also extremely useful for QA/information technology people in general, regardless of the industry. A supplier with a TickIT certification thus has a quality system of a level uniform with other TickIT-certified suppliers. They have all been through third-party assessments (audits) by TickIT auditors, who use the same approach world-wide. However, the purchaser must be aware that every auditor performs sample audits, which don’t cover all items in a company. They may want to look into the development of one or a few of the company’s products; the product you want to purchase may not have been looked into at all. It is possible to question the supplier about the scope and extent of the audit. If it covers the system you are interested in, you are unlikely to gain much information by performing an additional audit yourself. The agrochemical, environmental, and pharmaceutical industries, and so on, which have to comply with their own requirements and regulations rather than the ISO 9000 series, will often purchase materials, equipment, and computerized systems from industries in which the ISO 9000 series should be familiar. Software houses with a TickIT certification will normally have the level of quality that is needed for ‘non-ISO’ industries.

10.4

Why Audit?

For any company working in any quality environment regulated by any standards, it is important to know the quality of the raw materials that they are using to manufacture their final product. It is equally important to know the quality of the tools that they are using, and computer programs are important tools in most cases. As users, we may handle the tools in a quality environment, but they are not regarded as being of good quality unless they have also been developed in a quality environment. The EU GMP [6] Annex 11 states ‘The user of such software should take all reasonable steps to ensure that it has been produced in accordance with a system of Quality Assurance.’ The OECD GLP [7] states ‘Computerized systems should be designed to satisfy GLP Principles and introduced in a preplanned manner. There should be adequate documentation to recognized quality and technical standards (i.e., ISO/9001.) For supplier-supplied systems it is likely that much of the documentation created during the development is retained at the supplier’s site. In this case, evidence of formal assessment and/or supplier audits should be available at the test facility.’ This can only be controlled by independent auditors who are not responsible for the development of the program. An audit is therefore a part of the quality requirements. The quality requirements are the same, regardless of whether the program is developed in house or by an external supplier. The audit should be performed regardless of the software’s origin. It is just as important to audit a supplier of a program that is sold off the shelf as it is to audit the supplier who creates the programs specifically for the purchaser.

P1: OTE c10

JWBK188-Segalstad

144

September 30, 2008

11:59


Audits

The shelf-ware supplier will be audited for how he or she handled the quality system during programming. The benefits for the purchasers may be to reduce their own costs and risks, and the audit may help them to make the right decisions in order to purchase the right tool. It may also help to improve the supplier’s quality performance for the new versions to come. Customers who audit a supplier who programs especially for them will have a stronger impact on the quality of the program that they are about to obtain. In any case, the benefit for the supplier organization may be to make them aware of discrepancies in their quality management, and this can help them to make improvements. It may seem expensive to go to a different country or continent to audit suppliers before purchasing a system. However, it should be argued that it is far more expensive to buy a system that turns out not to be in compliance with the quality requirements with which the company has to comply. The user may eventually find out that all data handled by the computer system will have to be recollected. The cost of that will certainly exceed the cost of an overseas audit. The user requirement specification for a new system should include a demand that the organization can audit the supplier both before and after the contractual agreements have been drawn up between the two parties. A supplier audit performed by a purchaser should preferably be done before a final decision is taken to buy or contract the system, and the result should be an important part of the decision. It may then allow time to insert corrective actions into the contract. An experienced auditor with knowledge of Quality Assurance of computer systems programming will be able to get a lot more information from the audit than an inexperienced one. The experienced auditors know the standards and have acquired a ‘feeling’ for quality, which makes them able to observe deficiencies and continue to research them in order to find objective evidence of noncompliance. Objective findings are defined as discrepancies that are proven and/or acknowledged by the auditee; for example, a plan is missing, the test documentation is missing, sign-offs are missing, and so on. Quite often, a user without auditing or QA experience will be sent to the supplier to take a look at the functionality of the off-the-shelf system. It is an advantage for the purchasing company to let the user bring a checklist of quality questions to be asked. The results from this checklist will provide a fairly clear indication of the supplier’s quality system, but this exercise doesn’t replace an audit. It may be wise to write a Standard Operating Procedure (SOP) for this purpose, which includes the checklists with the points raised here. The various documents and parts of the quality system mentioned below are discussed in more detail in Chapter 6. The auditors will quite likely find that work is organized in a different way from what they are used to in their own company. It is important to keep an open mind, comparing how things are done with the standard rather than with their own experience.

10.5

Audit in a Risk-Based Environment

Audits have typically been done for IT systems that have been deemed to be most important in the organization where they are used. The risk-based approach to validation, now accepted by the US [8, 9] and EU [10] authorities, allows leaving some of the validation to the supplier. That is, the user does

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


Audit Scope

145

not have to repeat what the supplier has already done. GAMP 5 [11] also advocates this approach and gives guidance in the process. This is allowed provided that the user has made a risk assessment the conclusion of which is that this is an acceptable risk. But what skills are needed to come to that conclusion? That will, of course, require knowledge of risk assessment. Most companies have QA people with a background in production or laboratory work, and with extra training in standards. The combination of this knowledge and understanding of Quality Assurance makes good auditors for performing audits within their field. While many internal auditors do have the knowledge to perform an audit, few companies have internal auditors who really know what to look for when auditing an IT supplier. The auditor must understand how software should be developed. It is not sufficient to see whether the audited company has a quality system and that they are following it. The auditor must also be able to understand what is not included in the quality system, or what is not described well enough in the quality system. Earlier, the FDA did not acknowledge anything but a do-it-yourself audit, which generally is a lot less well done than a TickIT audit/certification. The FDA and EU authorities now accept a risk-based approach where you (as a user) can leave a lot to the supplier. I have always said that I trust the development of the software if the supplier has a TickIT certification, as I know what that entails. Now it actually should add value, as it could reduce the number of customer audits. So in my opinion it would be wise to have certification, provided that we can make the pharmaceutical industry understand that this is a valuable part of the system development that they don’t need to repeat for themselves. Fewer audits are, of course, also a benefit for the supplier, who does not need to host as many audits. Only if the supplier has been audited by highly skilled auditors can any conclusion be made about the supplier’s performance in the quality arena. There will be a great need for skilled auditors who know what they are looking for. They must also know how to document exactly what they have seen and what was missing. Only then can any conclusions be drawn about the supplier’s performance. If, and only if, the thorough audit report shows that the supplier is up to the company’s expectations from a quality point of view, some of the testing can be omitted during the company’s own validation. I’m afraid that a risk-based approach with the conclusion that ‘we need to do less’ will be founded on lack of understanding and knowledge, because the auditors are not trained well enough for software audits. It may be wise to team up with external consultants who have this knowledge. However, don’t leave the work to the consultants. Join them during the audit. After all, your company is the one to be inspected by the authorities, and you need to be a part of the audit to see what has been done.

10.6

Audit Scope

The primary role of the auditor is to determine: r whether the quality system meets the purchaser’s requirements r if the audited organization follows its quality system r whether the quality system is effective and efficient

P1: OTE c10

JWBK188-Segalstad

146

September 30, 2008

11:59


Audits

In order to do so, the frameworks for approval and nonapproval must be defined. ISO 90003 is probably the best framework for the development, supply, and maintenance of software. However, the IEEE standards [12–14] are also very good, and can be used as well. If industry-specific standards have additional or other requirements, these should be included in the auditor’s requirements for approvals. Compliance with ISO 90003 will cover all explicit or implicit requirements stated in the GxPs for the development of computer systems. It is important to recognize that there are many ways of creating and operating quality systems, and that any one may be the correct and the optimal way for each specific company. The auditor should take great care to understand the way in which the audited company is operating and to compare this with the standard, rather than comparing it with the quality system that he or she knows and is used to. For example: Quality standards have requirements for filing documents, but there are no requirements for the kind of filing system to be used – electronic and paper-based systems are equally acceptable as long as the type is properly defined in the quality documents.

10.7

Supplier Audit Preparations

A supplier audit should be performed before acquiring a new computer system, and the result of the audit should be a major part of the decision to buy or contract the system from this supplier. All industries with quality requirements can use ISO 90003 as a guideline to how a computer system should be programmed, even if they have other industry-specific standards to comply with themselves. Additional requirements can be added to the list of things to check during the audit. Audit activities involve the supplier (the auditee) and the purchaser/customer (the auditor). Some of the activities belong to the one party, some to the other, and some to both parties on a cooperative basis. This is shown in Figure 10.1. Pre-audit activities must include an agreement of the date for the audit. Should the auditor arrive unannounced, the chances that anybody will have time to take care of him or her are rather minimal. Other preparations include determining the scope of the audit, selecting the audit team, and sending the schedule for the audit to the supplier. A checklist should be prepared before the audit. This is the auditor’s preparation for the audit, and it should not be communicated to the supplier. It is usual to start the audit day with a brief meeting to explain the scope of the audit and what the auditor will want to see. This is followed by the actual audit, and finally a ‘wash-up meeting’ or conclusion meeting, where the auditor will summarize his or her findings. The post-audit activities include a report with all objective findings. The auditee should preferably answer this with a statement of the time frame and suggestions for corrective actions for each finding. If needed, a follow-up audit can be performed to check improvements. The purchaser may wish to perform a new audit at a later stage, to see that changes and new versions are under control. The scope of the audit has to be determined. A supplier may have several IT systems on the market, but we might be interested in only one of them. The quality system should be included in the scope in any case.

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


Supplier Audit Preparations

147

Audit Activities Purchaser

Both

Supplier

Set date

Checklist

Yes

AUDIT

Deficiency

Reports

Corr. Actions

OK? No

Time

Buy

Don’t buy

Figure 10.1

Audit Activities.

During the audit itself, the auditors must be allowed to run the show. They are the ones who should determine the schedule for the audit; that is, when to start, how long the introductory meeting will be, who to meet, and when the audit will end. Ask the supplier if any of the people you would like to talk to will be busy and would prefer to meet you during a certain period. Try to accommodate that – a little flexibility will go a long way. When setting up the schedule for the audit, start with one hour in which the audited company can present its quality system and its ways of working. This will give you a good overview of how the company works, and at the same time it will prevent the audited company from spending the whole day giving presentations. Tell the company before you arrive that you are not interested in their sales pitch about their fabulous software. The audit scope will have to be determined during the planning phase. If you have previous experience with the supplier, there might be issues that you want to check. A good way for the auditors to prepare for the audit is to create a list of what they will want to see during the audit. This checklist can be based on GAMP, ISO 90003, the TickIT Guide, or any other standard, including your own internal requirements. Checklist suggestions can also be found in the ANSI/IEEE standards. Additional requirements can be added to the chosen basic standard. If the URS for the system did not include all the technical requirements for 21 CFR Part 11 [15], these requirements should also be included in the checklist. A short extract from the checklist is shown in Table 10.1. This has room for comments about references to documentation received during the audit or notes.

P1: OTE c10

JWBK188-Segalstad

148

September 30, 2008

11:59


Audits

Table 10.1 Part of the Audit Checklist Computer supplier audit checklist Customer name:

Page 1 of x System:

Date:

ISO 90003:2004

GAMP 4

Address: Supplier name: Address: Organization/Unit: Persons: Audited by: Siri H. Segalstad, Segalstad Consulting AS and

Supplier considerations Quality system General requirements

4

Process identification and interaction between them

4.1

Resource management, monitoring the processes

4.1

Continual improvement

4.1

B15

4.2

B3, I1

Q manual and SOPs. Life cycle model description

4.2.1

B3

Control of Q documents and Q records

4.2.3

B5

SW: Control of records, test documentation, change requests, audit and assessment reports, effective operation, minutes of meetings, release records

4.2.4

G4

B3

Documentation requirements Quality policy and objectives

Maintenance of Q system Management responsibility

B6 5

Management commitment Customers, overall responsibilities for the Q system.

5.1

B1, B2

Management reviews

5.1

B6

Customer focus To enhance customer satisfaction Quality policy

5.2

Comments

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


What to Look For

149

Table 10.1 (Continued) Supplier considerations

ISO 90003:2004

GAMP 4

Purpose, commitment to comply with regulations

5.3

B1

Improvement of effectiveness of Q system

5.3

Q-system understood in organization

5.3

Comments

Planning Measurable Q objectives

5.4.1

My own standard preference is the ISO 90003, the reason being that it is very well known in Europe, and quite well known in the United States. The standard is easy to get hold of and it has clear requirements that can be easily understood. I always let the supplier know which standards will be used for the audit, but they never receive the checklist before the audit, for several reasons: First, I don’t want them to see what I have on the list, and I sometimes diverge from the list to pursue interesting findings. Also, the fact is that I don’t use the list during the audit: I check back to it once or twice to see whether I have covered everything.

10.8

During the Audit

The audit starts with an opening meeting. The first item on the agenda is to present the people attending the meeting. The rest of the first hour is for the audited company to present itself, its quality system, and its ways of working. This will give the auditor a good overview of what the company does and how it thinks, which may be quite different from the auditors’ experience. That does not make it wrong, just different. The auditor’s job is to understand how the company works and compare that to the standard – not to his or her own way of working. The auditor should view the quality system and try to understand the way it is used in the supplier’s environment. Ask to see the quality documents, and proof that they have been used. The questions should be asked in the form ‘Show me . . .’ rather than ‘Do you have . . .?’

10.9

What to Look For

The supplier’s quality system will normally contain a Quality Policy, a Quality Manual, and procedures and/or work instructions, as described in Chapters 4–6. These are usually based on a standard, which may be external or developed in house. The scope of the audit is to assess whether this is in compliance with the standard that the purchaser has to follow. Local standards may include naming conventions, mandatory use of certain options, documentation requirements and layouts, formats and standards for software code, and so

P1: OTE c10

JWBK188-Segalstad

150

September 30, 2008

11:59


Audits

on. If the supplier is programming the system for the purchaser, contract-specific plans should also be included in the quality system. Product-specific plans should be included for shelf-ware. The supplier must be able to show adequate documentation that the quality system is being used. It should be possible to trace all paperwork to prove that all plans, checks, and controls have been performed, by whom and when. Finally, the auditors will assess whether the quality system is adequate for their company’s quality requirements. This is where knowledge and understanding of the quality requirements merge with the auditor’s experience, and it is also where differences between experienced and inexperienced auditors become evident. The EU GMP Annex 11 states that ‘Validation should be considered as part of the complete life cycle of a computer system. This cycle includes the stages of planning, specification, programming, testing, commissioning, documentation, operation, monitoring and changing.’ As previously mentioned, the OECD GLP suggests using, for example, ISO 9001 as a standard for development. ISO 90003 states: ‘A software development project should be organized according to a life-cycle model. Quality-related activities should be planned and implemented with respect to the nature of the life-cycle model used.’ It continues: ‘. . . irrespectively of the life-cycle model used.’ There are many different system development life-cycle models, each of which varies according to the complexity and size of the project, and also with the organization in which the system is being developed. Some of these are described in Chapter 6. An SDLC approach to programming a system is to divide the development into smaller phases. Each phase must be thoroughly planned in detail, and must include definitions of inputs and outputs for the phase. The plan must also specify Quality Control activities such as reviews and tests in order to be able to verify or validate the outputs, as well as first-party audits. The plans should be approved by QA before the actual programming starts. The verification and testing should be done and appropriately reported with deviations from plans (if any), documentation of what was done, who did it, and when it was done, results, and error reports. Some phases may be done in parallel; others have to be finished before a new one starts. When each phase is done, a report must be issued, reviewed, and approved before the next phase can begin. In this way, there will be a fully controlled development of each phase in the System Development Life Cycle. The checklist is a good tool to help the auditor remember the different things to be investigated, but care should be taken not to become a slave to the list. It may be more worthwhile to pursue investigation of one part than just to tick it off as ‘not in compliance,’ and continue with the next point. Noncompliance may be a good reason for deviating from the original checklist, with the result that it may not be possible to go through all of the points on the checklist within the allotted time. There might also be modules in the system that are interesting to focus on. There is also your preferred approach. In the top-to-bottom approach, you start with the whole system and drill down to a small part, which is usually decided while you are there. With the bottom-to-top approach, you start with one module to see how it fits into the whole system. Instead of asking for all the different documents at random, it may be easier to follow one part or module of the product through the whole life cycle. Start with the plans, and ask to see the documentation that all plans in the module were followed.

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


What to Look For

10.9.1

151

Organization

The full responsibility for, and commitment to, a Quality Policy belongs to the highest level of management. A management representative, often with a title such as ‘quality manager,’ will be responsible for all matters affecting the quality system. When conflicts arise between quality and business issues, quality isn’t going to win unless it’s anchored in top management. The implementation of the quality system involves all members of the organization. The supplier must have an organizational chart that clearly shows the quality organization and the staff responsible for quality. All roles and responsibilities must be defined and documented. The plans for each project must contain the responsibilities in that project, and may not be reflected in the organizational charts. A quality organization should have a separate QA unit or one or more QA people who are independent of the rest of the organization. QA people must not approve their own work; nor must they have any personal interest in whether or not the work they assess will be approved. According to most standards, staff must be adequately trained and capable of doing their jobs properly. A Curriculum Vitae (CV) and training records must be available to show that they are adequately educated and trained for their job. The training record will contain details of all classes, and should also contain details of on-the-job training, signed off by the trainer when he finds that the trainee’s knowledge or skill is adequate for performing the task. This is described in Chapter 5. Some auditors start the audit by asking for the training records of the staff involved in system development. It is rumored that the FDA view is that if the training records are missing, there is no competence and thus no acceptable system – and the audit can end there. The consequence may be that the relationship between the supplier and the customer may also end at this point. Change control must be applied throughout the life cycle. All changes must be evaluated for consequences before the change is implemented, and the evaluation must be documented as previously described in Chapter 5. Deviations from the original specifications for programming must also result in changes in the test plans. If not, the testing does not reflect the updated specification.

10.9.2

Plans

The development of an IT system in an SDLC must include several different plans for each of the different phases in the defined SDLC model. There shall be general requirements in the company’s quality system about which plans are to be made and tailored for each specific phase in the project. They may include, but may not be limited to, plans for development, quality, configuration management, testing, integration, and installation. Additionally, there may be contract-specific plans if appropriate. There may be several revisions of the plans during the development of the system, and they must be updated as a result of change control. Each phase needs to include plans for testing, test design, test cases, test procedures, test execution, and test reporting, all of which must be signed off and approved when done. Test plans can be written at the same time as the requirement specification for each phase

P1: OTE c10

JWBK188-Segalstad

152

September 30, 2008

11:59


Audits

or module. However, if the specifications are updated, the test plans must be updated as well, as a part of the change control. The auditor will normally expect to see all of the plans and reports that he or she asks for, and the sensible supplier will provide them. If not, the purchaser might suspect that the supplier is hiding something. The development plan is often called a project plan, and it includes a breakdown of the different tasks in the project, time/resources planning and allocation, responsibilities, and so on. Revisions may be needed to update actual progress versus planned progress. The development plan is often followed by a project report or reports. The Quality Plan is the application of the company’s quality system to the specific project. The general quality system will say that detailed Quality Plans are needed for each project, and that these must be available. However, there’s nothing wrong with recycling Quality Plans from one phase or project to the other, provided that they are fully applicable. The Quality Plan will indicate quality reviews, checks and inspections to be performed, and which documents or project outputs are involved, as well as procedures to be followed and authorization for sign-off. The configuration, including the versions of all hardware and software modules, must be updated continuously. The configuration management plan identifies the application of the configuration management to the specific project. The historic system configuration must be available in such a way that it is possible to query what the system looked like at any given date. Integration plans cover the integration of a single or several smaller modules into larger modules or the final product. Each of the modules must be completed, tested, and signed off before integration can start. The documentation shall prove that the plans were followed. The documentation includes records of what was actually done, reviews, reports, verifications, and sign-offs. When documentation is changed for any reason, this should be done according to a change control procedure.

10.10

Other Issues

Errors should be handled with identification of the error, corrective actions, and verification that actions have been performed properly. Which corrective action should be used depends on the nature of the error. Errors or faults in the quality system must result in updating of the quality system. Errors in plans must result in an update of the plan and its testing. Programming errors must result in corrections followed by new tests, until satisfactory results are obtained according to the plans. Security is normally a matter of concern. This may include physical access restrictions to the supplier’s premises, and access restrictions in the software for trained/untrained programmers. This may be especially important for the customer when the programming is done on contract for his company. Security also includes built-in functionality for security in the programs to be delivered, with differentiated access for different types of users, and audit trails for entries in the program during use. The contract between the supplier and the purchaser should include the purchaser’s specific requirements. The contract is very important for commissioned work, and generally

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


The Closing/Wash-up Meeting

153

more complex than for shelf-ware. The ISO standards don’t include requirements for delivery times, other than a reference to the contract. Delivery times should therefore be included in the contract. The contract may additionally have clauses on the test period, with acceptance testing at the customer’s site, support issues, and upgrades to come. If new functions are to be included in the next upgrades, this may also be stated in the contract. For GLP purposes, there is a requirement of access to the source code. Most suppliers will tell you that you may have access to the code at their site at any time. However, this isn’t worth much if the supplier goes out of business. This issue can only be handled properly through an escrow agreement, which is a deposit of the source code with a third party such as a lawyer or a bank.

10.11

Findings/Discrepancies

There is a difference between a major and a minor finding. A minor finding is, for example, that one signature is missing on a document, or any other one-time occurrence of little consequence. A major finding is a serious deviation from the standard and would be, for example, that signatures are missing from all the documents, parts of the QMS are missing, or any other item that has an impact on the quality. The findings or discrepancies from the standards are usually called ‘objective evidence.’ These fndings must be factual, and based on observations, measurements, or verified tests. They must be acknowledged by the auditee at the time they are found. The objective evidence may be reported in different ways. This may involve a report for each finding, completed during the audit, and/or a final report prepared after the audit. An ISO approach is to have a form that is completed for each finding. The form should include identification of the auditor, the audited company, the date, and which standard was used. Reference is usually made to the clause for the particular nonconformity. There is room for a brief factual statement of the findings, to be signed by the auditee. Details of agreed corrective actions must be completed by the auditee, and the form should also have room for review of the corrections by the auditor. The form is useful, but parts of it may be omitted in the case of a second-party audit.

10.12

The Closing/Wash-up Meeting

After the audit is completed, the auditors need to spend a little time alone to discuss and summarize their findings. Create an overview of the good things that have been seen during the audit, and continue with the findings. Make sure that everything is covered, as this is to be your complete collection of findings. When the overview has been written down, invite the supplier’s representatives to come back in for the closing meeting, which is also called the wash-up meeting. First, thank the company for letting you visit and for giving you some of their valuable time. Start with the positive things on your list, even if it’s only the lunch that they served, or their hospitality. Continue with your findings. You might have misunderstood something,

P1: OTE c10

JWBK188-Segalstad

154

September 30, 2008

11:59


Audits

so let them tell you if things are not described correctly. If possible, state whether the finding is major or minor. Bear in mind that your oral conclusion is what the audit report will cover. You should not add findings in the report that have not been mentioned in the closing meeting.

10.13

The Audit Report

Instead of the ‘ISO forms’ mentioned above, a draft audit report with all the findings can be sent to the supplier for review. If the auditor disagrees with the findings or finds errors in the report, he can say so in his review letter. The final report is then prepared and sent to the supplier. The customer may want to perform a new audit later to check improvements. In a quality-related environment, serious/major deviations from the standards or many smaller/minor deviations should result in a decision not to buy or contract a system from this supplier. The user has the full responsibility for the quality of the software that he is using. He can’t blame it on the supplier. Some companies don’t send the audit report to the supplier. This isn’t fair to the supplier, since the audit is costly, as several people are tied up with the task. The audit report is often regarded as a valuable tool for improvement of the quality system. I try to write an audit report that will be valuable for both parties. After the introduction with details of the companies, the people involved in the audit, the date, and other facts, I discuss what was seen during the audit. This includes a very thorough list of which documents have been seen, including version numbers and comments on each of these documents, the reason being that it must be possible to go back later and see, from the report, exactly what was investigated and checked. The report also discusses the findings, dividing them into major and minor discrepancies. Each finding is referenced to the clause on the standard used during the audit. The finding has one sentence about what is wrong or missing, plus a little explanation, with examples if appropriate. Finally, I like to include some notes about things that can be improved, these not being regarded as ‘findings.’ These notes are added as a service to the supplier.

10.14

Conducting an Audit from the Receiving Side of the Table

An audit done by regulatory officials such as representatives of the FDA is often called an inspection, but the meaning is the same. An audit looks quite different from the receiving side of the table than it does from the auditor’s side. The main differences are often more due to the styles of the auditors who conduct the audit. In both cases, the goal must be an open atmosphere with a good flow of information. The auditors must receive correct answers to their questions. They should be shown the documents that they have asked to see as quickly as it is possible to retrieve them. That is also all that they need to see – don’t volunteer information that wasn’t asked for. Many an auditor has started to dig into a pile of problems because some unfortunate person volunteered something that he hadn’t been asked about.

P1: OTE c10

JWBK188-Segalstad

September 30, 2008

11:59


References

155

Several pharmaceutical companies have created SOPs for what can and what can’t be shown during an audit. Regulatory agencies such as the FDA will have to know whether internal audits have been conducted, and the company will wants to be in compliance with that requirement. The SOP may say that the inspectors can see the list of internal audits performed, but not the audit reports, which will give away information that should remain internal. The inspectors will accept this approach provided that it is stated in the SOP. Many pharmaceutical companies also train their personnel in how to behave during an inspection. When an inspection is expected, the company makes thorough preparations. This includes checking all files to see that documents are where they should be, and preparing people so that everyone knows who is to answer questions about what. In this way, people will hopefully not reveal things they that shouldn’t reveal, or talk about things that they don’t know enough about.

10.15

Tasks

During the audit, you discover the following (experience from real audits): 1. The supplier doesn’t do any backing up. He explains that every time the 20 people in the company log into the server, all files are automatically backed up to the other PCs connected to the server. r Discuss whether this is acceptable r If not, explain how it can be made acceptable r Or maybe it can never be acceptable 2. The supplier has plans for how to upgrade his system to a new version to be released in one month. These plans are good. When you ask to see the reports from the last upgrade, you are told that the content of the documents was outdated and they no longer needed them, so they threw them out. r Discuss whether this may be acceptable, and state your reasons for the answer 3. The SOPs state that they shall be updated every year. Based on this requirement, all of the SOPs are outdated r Discuss whether this is acceptable. Suggest how the problem may be solved

References 1. ISO 9001:2000 (2000) Quality Management Systems – Requirements, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 2. ISO 8402-1989 (1989) Quality Terminology, International Organization for Standardization, Geneva, Switzerland (this standard has been withdrawn). 3. ISO 90003:2004 (2004) Software Engineering – Guidelines for the Application of ISO 9001:2000 to Computer Software (formerly ISO 9000-3), International Organization for Standardization, Geneva, Switzerland, www.iso.org. 4. TickIT Office, 389 Chiswick High Road, London W4 4AL, UK. 5. TickIT (2001) The TickIT Guide Using ISO 9001:2000 for Software Quality Management System Construction, Certification and Continual Improvement, Issue 5.0, TickIT Office, 389 Chiswick High Road, London W4 4AL, UK, ISBN 0 580 36743 9, www.tickit.org.

P1: OTE c10

JWBK188-Segalstad

156

September 30, 2008

11:59


Audits

6. European Union (1998) Volume 4 – Good Manufacturing Practices – Medicinal Products for Human and Veterinary Use, p. 153, incl. Annex 11 covering computerized systems. European Commission, Directorate General III – Industry, Pharmaceuticals and Cosmetics. 7. OECD (1995) OECD Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 10 GLP Consensus Document, The Application of Principles of GLP to Computerized Systems. Environmental Monograph No. 116, OECD, Paris, www.oecd.org. 8. US FDA (2005) 21 CFR Part 210 Current Good Manufacturing Practice in Manufacturing, Processing, Packing, or Holding of Drugs; General, US Food and Drug Administration, Rockville, MD, www.fda.gov. 9. US FDA (2005) 21 CFR Part 211 Current Good Manufacturing Practice for Finished Pharmaceuticals, US Food and Drug Administration, Rockville, MD, www.fda.gov. 10. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based 11. GAMP Approach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. 12. IEEE 1012-2004 (2004) IEEE Standard for Software Verification and Validation, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 13. IEEE 1016-1998 (1998) IEEE Recommended Practice for Software Design Descriptions, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 14. IEEE 1028-1997 (1997) IEEE Standard for Software Reviews, Institute of Electrical and Electronics Engineers, New York, www.ieee.org. 15. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov.

Acknowledgement Parts of text reproduced from ‘Development Qualification: Selecting the Right Vendor’, published in American Pharmaceutical Review, vol. 3, issue 4, Winter 2000, with permission from American Pharmaceutical Review.

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


11 Validation of IT Systems

This chapter discusses the following: r r r r r r

Requirements for validation Validation scope Running the validation project Hardware and software validation An overview of validation activities The Validation Master Plan and the Validation Plan

11.1

Introduction

When people are asked why they validate their processes and IT systems, most will answer that it is because they are forced to by their regulators. In my opinion, this isn’t the correct answer. The main reason for validation should be that we need to understand our processes, strengths, and weaknesses. Validation of these is a good way to get there. What we do see is that if organizations are not forced to validate, they will normally take the easy way out – that is, not do it. Many think that validation is costly. However, it may be a lot more expensive not to do it and find that the products or processes can’t be used.

11.2

External Requirements for Validation

The pharmaceutical regulations have requirements stating that the critical IT systems need to be validated. However, there are few specific explanations in these regulations as to how International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c11

JWBK188-Segalstad

158

September 15, 2008

13:33


Validation of IT Systems

this is to be done. Other quality standards may or may not include anything about validation of IT systems. Some regulations, standards, and guidelines hardly mention IT systems, but cover items such as ‘tools’ or ‘equipment.’ These definitely are to be interpreted as covering IT systems. As previously mentioned, GAMP [1] is about the only guideline that explains how to validate computerized systems. GAMP also has several additional Good Practice Guides for specific parts of the IT validation process: r r r r r r r r

the Part 11 risk-based approach to validation [2] the laboratory instruments guide [3] the testing of GxP critical systems [4] global information systems [5] calibration management [6] an infrastructure guide [7] process control systems [8] archiving of electronic data [9]

The validation of any specific system will differ even if the organization has a good description of how to do it in its quality system. The reason for this is that every system is different. What can be considered a sufficient amount of work for one system isn’t sufficient for the next, or is overkill for another one. There is always the question of how much validation is sufficient. Unfortunately, there’s no straight answer to that. It will never be perfect; after all, there is always a little more that can be done. The best thing to do is to check the FDA home page (www.fda.gov) and various publications that keep track of the FDA’s current views, to see whether there are any comments regarding this approach. Then use this knowledge to decide what you feel comfortable with. Can you defend this approach? Is it your gut feeling that this is good enough? With experience, a ‘gut feeling’ may be used to determine ‘good enough,’ but without experience it’s of little use. It is difficult to give a recipe or template for validation, as there is no such thing as ‘one size fits all.’ What does fit all is the necessity to assess each case to find out what is sufficient for the particular system. This and the following chapters will explain the assessments needed and the approach to validation. Examples are included to illustrate the assessments and the approaches, and hopefully you will be able to understand how to validate a system according to any standard, and regardless of size. The only way to really get validation ‘under your skin’ is to do it. No amount of classes or books can ever be sufficient – you have to rely on experience. The tasks will help you on your way.

11.3

Internal Requirements for Validation

This chapter will explain which documents are needed for validation. However, where each organization has the information varies considerably. There are no correct answers to what to document where and how, but there are some ways that are more functional than others. I will explain how I would prefer to do this, and why. However, other ways may be more

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


Internal Requirements for Validation

159

feasible in your organization. The quality management system is described in more detail in Chapter 4. There are two main rules: 1. Have the information and requirements as far up in the quality system hierarchy as possible. This means that it will be valid for the whole organization, or at least for a large part of it. 2. Don’t repeat the information in one part of the quality system somewhere else. Refer instead to the other part. Repeated information means that there’s a good chance that the various versions will be out of sync, or even contradict each other, after a couple of revisions. However, the lower levels of the hierarchy may include more detailed information than the higher levels. The quality policy doesn’t normally say much about validation of IT systems unless the organization has separate quality policies for products, processes, security, or IT systems. The quality manual, if it exists, should include overall, but probably not very detailed, requirements for what is needed for: r generic SOPs for IT systems r system-specific SOPs for IT systems r validation SOPs include details regarding IT systems: r generic SOPs for IT systems r system-specific SOPs SOPs should also cover validation issues: r r r r r r r r

risk management the Validation Master Plan the Validation Plan validation phases qualifications testing documentation and reports a dictionary and definitions of validation expressions

It is far better to have these requirements in SOPs than in system-specific validation documents. If these SOPs exist, the validation documentation for each system should not repeat the details that are covered elsewhere. Otherwise, each system validation will probably repeat, and may also contradict, what other validation teams have been writing in their system validation documentation. Let’s face it: This is unnecessarily duplicated work that can lead to problems. Validation documents must be created for each system or application, but even that may be repeated unnecessarily if it isn’t planned well. For example: Most of the clients and servers have several applications that use the same operating system, the same databases, and the same network. Create one set of validation documents for each of these, and refer

P1: OTE c11

JWBK188-Segalstad

160

September 15, 2008

13:33



to that when you validate your application. Refer also to other existing documents such as SOPs and the Quality Manual. There is no need to repeat the work. This chapter includes which information is needed somewhere. It is up to you to define where you want the information. It must exist, but there is no rule saying where. A well-planned approach can save the organization a lot of work. It isn’t cost-effective or useful to invent the wheel over and over again.

11.4

The Validation Cost

There are strict requirements for Quality Assurance, validation, and clinical testing programs before a new pharmaceutical product can be accepted for the market. This is a large cost, usually in the billion-dollar range. Of course we want to make sure that the product is safe and has no or few adverse effects. But if we can compromise and get the new product out a bit earlier with a little less testing and can help a thousand very ill persons, are they not entitled to that help, even if there may be five who get bad side effects? This is an ethical question that is hard to answer. Everyone remembers the thalidomide scandal, when many children were born without limbs because their mothers used the product, even though it should not have been used by pregnant women. Thalidomide reduced nausea, which is common for pregnant women, but it had not been tested on pregnant women. The fact is that the pharmaceutical industry is so scared of the very large lawsuits from everyone affected by adverse effects/death that they daren’t try to get a product onto the market without adequate testing, even if it could save a lot of people. Better safe than sorry, and money always speaks loudest. All kinds of validation require resources such as time, people, and money. One might discuss whether the economy in validation is an outgoing cost only. It is easier to assess the cost of validation than the cost of not validating processes, analytical methods, instruments, and IT systems. However, one oil company representative in Saudi Arabia told me that he did not even think about the cost of the planned LIMS system and the cost of its validation. That was minimal compared to one single failed production run in his plant. This is probably true for most other validations as well. While the validation cost is measurable, the cost of not validating and thus producing or delivering failed products will often be much higher. But this is hard to prove.

11.5

Inspectors

Inspectors, whether they are pharmaceutical or certification/accreditation inspectors, will handle IT systems differently. This depends on the inspector’s field of expertise. In some cases, the inspectorate’s unwritten policy is different from what the quality standard says. But in most instances it is the standard itself that is a problem. Elastic words such as ‘adequate’ and ‘sufficient’ are frequently used, and the interpretation of these words varies considerably. This also makes it possible for the inspectors to see something in one

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


The Validation Scope is Changing

161

organization that they think is a good way of working, and to apply it as a requirement for the next organization. Elastic words add to a spiral of ever-increasing requirements. The various accreditation and certification bodies handle IT systems differently during their audits. Some are just about as strict as the pharmaceutical bodies, while others don’t want to venture into that area. All inspectors have their specializations: Some specialize in production, or laboratory, or microbiology, and will not look at IT systems. At the most, the company may get a citation that the IT system has not been validated. Other inspectors have IT systems as their specialty, and will write two pages about what is missing for this particular IT system. It is also foolish for inspectors without thorough knowledge to get into a field where they are not experts. There are too many experts out there in the industry, and discussions might not be easy to handle. The fact that the FDA inspectors have paid three visits and haven’t checked IT validation doesn’t mean that the FDA isn’t interested in the topic. It only means that IT validation didn’t fall within the scope of these three inspections. But try to fight that internally as a QA person – I’ve tried, and it was a losing battle for a QA person with responsibilities for IT validation.

11.6

The Validation Scope is Changing

Up to 2007, it has been normal for users to test ‘everything’ themselves, regardless of what the suppliers have done during their system development; the reason being that you can really only be sure that things are done according to your needs if you do them yourself. This has resulted in a lot of duplicated work, especially when testing each single function, as this has frequently been done by suppliers before they have released the system. For software that has been bought as ready-to-use where no changes are needed (shelf-ware), OQ may be limited or nonexistent in the user organization. The risk-based approach that both the EU and the FDA regulators advocate [10–14] makes it possible to assess the risks of not doing everything yourself. GAMP 5 is seriously changing the validation scope compared to GAMP 4 [15], due to the new paradigm in risk-based approaches from the regulators. The focus has moved from validation and testing being the sole responsibility of the end-users to a focus on what the supplier has done, and on letting the end-user bridge the gap. This can only be done if the end-user is able to see where the gap is. In cases where the supplier is assumed to have performed adequate testing before releasing the software, this may be acceptable, but this assessment is based on risk. This assessment can only be made if you really know what the supplier has done during development. There is only one way to really know, and that is to make a very thorough supplier audit, in which the auditors understand what is needed during system development. Unfortunately, I believe that the average QA person performing a supplier audit for system development isn’t sufficiently competent to do this, though there are people who are. It takes more skill than just knowing quality systems and IT validation from the user’s perspective. The supplier audit is explained in Chapter 10. It is the company’s responsibility to gather enough information and documentation to ascertain that the supplier’s testing can be trusted. Reputation in the market, previous

P1: OTE c11

JWBK188-Segalstad

162

September 15, 2008

13:33



experiences, references from other customers, and the performing of an audit may provide helpful input. However, reputation and experience can’t replace actual knowledge. For an important system, a supplier audit may very well be the only solution. If you venture down the road of skipping some parts because the supplier has already done this testing, make sure that you really know what they have done and what they have not done. A thorough supplier audit done by competent persons is vital to understand what has been done and what is needed. The audit report must also be very detailed with regard to what the auditors looked at, what was good, and what was not good. Only then can you possibly document that parts can be skipped. In the chapters that follow, I have set out how I would like to see the validation done. As you now know, there are many ways to do it, and you need to be able to defend your decisions on inclusions and exclusions in the process, based on the following criteria: r the external regulations that you have to follow r the internal quality system that you have to follow r assessments of risks for the data and the processes that your system handles Even if your neighboring organization has decided that something shall be done in one way or the other, your decision in an almost equivalent situation will have to be made independently, and you may come to a different conclusion. As mentioned before, it all depends . . .

11.7

A Computer Validation Project

The company needs to have a policy for how to validate its computer systems. This must be described in the quality manual and/or in SOPs in order to create a uniform way of handling all the regulatory systems in the organization. Computer validation isn’t something to be done once and for all for an IT system. It is a life-cycle approach, which starts at the same time as one starts thinking about acquiring a new system. In fact, it should have been started by the supplier long before that, as most systems acquired have probably been developed at a supplier’s site for years. There are several roles in the validation project. These are described in Chapter 7. The validation project may be large, and take a long time for a complex system that is used in many places in the organization, or it may be small for a small system, without very many variables, that is used by few people in the organization. Create a project plan. Resource needs must be assessed for each validation project. The project plan should be kept updated by the project manager, who might be a different person from the validation leader/manager. Refer to the project plan from the other validation documents. The project plan is likely to change more often than the Validation Plan, so it is wise to keep them as separate documents. The project plan includes the names of all participants, and not just roles. The project plan should include resource planning (persons, monetary resources, and other resources as appropriate) and timelines for each validation activity.

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


The Network

11.8

163

Which Hardware and Software is To Be Validated?

The general answer to what should be included in validation is everything that affects the quality of the products, the regulatory requirements, or any other external framework that is to be applied. The hardware and the software are obviously within the scope. Computer systems should preferably be run using client–server architecture. In this way, most of the program and logic resides on the server and a minimum of logic resides on the workstation/PC. This is especially true when using so-called ‘thin clients,’ where the client is set up to act little more intelligently than a former terminal. Where a computer system resides fully on a PC, the PC itself must be under control. This requires one of the following solutions: r a dedicated PC, to maintain the validated status (a stand-alone system) r a dedicated PC connected to the corporate network and treated as a server – that is, with stringent control routines including change control and access control r a dedicated PC connected to a dedicated server and network A platform consists of a set of hardware and software components that are configured to work together. Instead of validating each component separately, the platform could be validated as a unit for its ability to perform as intended. The platform and application must be set up so that: r production systems are segregated from test and development systems, to ensure that the development and test operations don’t impact the operation of the live system r systems used for formal testing or development are segregated from systems used for, for example, informal testing or training Clients, servers, networks, and other hardware that affects the product quality needs to be validated/qualified. These items should be treated as separate entities, so that, for example, a server is qualified only once even if it is used for several systems or applications. The validation documentation for the applications using this hardware can refer to the qualification instead of repeating it.

11.9

The Network

The network supplier, whether this is an internal or and external (outsourced) supplier, usually controls all aspects of the Wide Area Network (WAN) between the routers. Changes to the WAN must be subject to procedures for change control and qualifications. Networks can’t be validated; they can only be qualified. The reason for this is that it isn’t possible to have complete control over all aspects of the network. Traffic comes in at any time and can’t really be controlled. The WAN rarely needs more than Installation Qualification and Operational Qualification. The Local Area Network (LAN) should be handled in the same way as the WAN. The specification, topology, and management of the LAN must ensure sufficient performance, availability, security, and robustness for all of the systems.

P1: OTE c11

JWBK188-Segalstad

164

11.10

September 15, 2008

13:33



Software

As the Operating System (OS) is used for most of the other applications, it should be qualified as a separate entity. The IT department, regardless of whether this is an internal or an external group, is normally responsible for the OS. The user communities rarely have any responsibility for an operating system. Operating systems rarely need more than an Installation Qualification and an Operational Qualification. Databases include large Oracle or SQL Server databases or smaller ones such as Access. The latter should ideally not be used for any regulatory systems, as it does not have the built-in security, audit trails, and access functionality needed. Many of the larger laboratory systems, production systems, and document management systems utilize Oracle or SQL server databases. Several of these systems may use the same database version. The user communities are rarely responsible for the database, as that is usually the responsibility of the IT department. The databases used for applications rarely need more than an installation qualification. The application or system using the hardware, operating system, and database needs to undergo complete validation.

11.11

Risks and System Categories

Regardless of the size and the importance of the computerized system in question, a few basic topics need to be addressed to find out what to do. First, you will need to find out how big a risk this system is in your organization, for your products or your services. What if the system fails to give the correct results? How to assess and manage risks is described in Chapter 12. High-risk systems need a lot more validation work than low-risk systems. Additionally, some parts of a system may carry higher risks than other parts, and may need more thorough testing than the other parts. You need to find out which category your system falls into according to whatever internal or external standard you are using. As described in Chapter 5, there are different ways to categorize systems. You may follow descriptions in GAMP, or your own organization can define its own categorization system. The validation activities depend on how your system is categorized.

11.12

Qualifications

The assessment of risk combined with the assessment of system category will form the basis for planning what to do with this specific computer system. Validation is generally a large topic, and it is useful to divide it into smaller tasks to be able to manage it. The manageable pieces can be defined however you like, as there are no requirements to do it one way or the other. While you are free to organize your pieces however you like, it is important that you document your definitions and stick to them.

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


Qualifications

165

I have chosen to use the four Qs in this book: 1. 2. 3. 4.

Development Qualification (DQ); Installation Qualification (IQ); Operational Qualification (OQ); Process/Performance Qualification (PQ).

These are well known within the pharmaceutical sector, but even here there are big differences between the various organizations in how each qualification is defined and who does what in the validation process. GAMP 4 omits the DQ, but includes it as a prerequisite and it is described, although the expression ‘DQ’ isn’t used. The DQ is usually not included in the FDA glossary definitions [16], where the validation starts with the installation. However, there are important things to be done before the installation starts, so I prefer to include the DQ in order to cover these items as well. There is no universally acknowledged definition of each of the phases. The FDA definitions don’t say anything about when or how a phase starts, and how to conclude a phase. Each company may define the content of the four qualifications as it pleases, as long as it is clear what each qualification comprises in their particular case. There are also no requirements stating that one needs to use phases. A completely different approach is equally good, as long as it is spelled out and used accordingly. The validation phases need to be defined somewhere. Whether this is somewhere in the quality system, in the validation master plan, or even in the Validation Plan for each system doesn’t really matter, but it is smarter to have it in the QMS, as this will be followed by all parts of the organization. What needs to be included is the definition of how a phase starts, what is to be done during the phase, and how the phase is defined as done. There is also a difference between the first validation of a system and revalidation due to changes such as upgrades. In the latter, there is a good chance that previously created documents can be reused or that they will just need minor editing. During IQ/OQ/PQ, the testing should preferably be done in a test environment. The ideal is to have identical instances (environments) for the test and live operations: the platform, system, set-up, configuration, support materials (manuals, procedures, etc.), and system training should be identical. These environments are described in Chapter 5. The testers should have the same training as the users are obliged to have. I like to use the validation model shown in Figure 11.1. This has the end-user’s activities for the system on the vertical arrows. The supplier’s activities are on the horizontal arrows in DQ, and the activities for the static data in the system are on the horizontal arrows in PQ. The validation model has one drawback: It doesn’t include time. It is normal to finish one ‘Q’ before the next one starts, but there are some activities in a later qualification that need to be in place in a previous one. For example, SOPs need to be in place before OQ can start, as they provide a framework for the testing. In many companies, PQ is defined to be done before the system goes live. I like to include the ongoing activities in the PQ phase to emphasize that the process isn’t done even if the system has been signed off as fit for use. In that case the PQ testing is necessary for the sign-off, while the other PQ activities are ongoing. You can choose your own definitions as long as you stick to them. Two or more qualifications may be done simultaneously, especially for the items in the OQ/PQ phase. This should be described in SOPs and/or in the system’s Validation Plan.

P1: OTE c11

JWBK188-Segalstad

166

September 15, 2008

13:33



Validation Supplier development

DQ

IQ

PQ

DQ

Company system Items

OQ

IQ OQ DQ

IQ

OQ

PQ

PQ Figure 11.1

11.13

The Validation Model.

Development Qualification

My definition of Development Qualification (DQ) is as follows: Establishing confidence that the IT system has been developed in a quality environment under good quality management.

The DQ comprises several different actors and activities: r The process of acquiring the system, including the User Requirements Specification, assessing the answers from the suppliers, and finding the best system r The development of the system that has been done by the supplier, and that will be checked during a supplier audit. The user organization’s DQ therefore also comprises the supplier’s DQ/IQ/OQ/PQ. Development also includes the potential customization of the system r The implementation of the system in the user organization; that is, filling the database with your own static data DQ is described in more detail in Chapter 13.

11.14

Installation Qualification

The FDA Glossary definition of Installation Qualification (IQ) is as follows: Installation Qualification (Platform Validation and SW installation). Establishing confidence that process equipment and ancillary systems are compliant with appropriate codes and approved design intentions, and that the manufacturer’s recommendations are suitably considered.

The IQ of the system includes installation of the system hardware and software on the user organization’s premises. IQ is described in more detail in Chapter 14.

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


The Validation Master Plan

11.15

167

Operational Qualification

The FDA Glossary definition of Operational Qualification (OQ) is as follows: Establishing confidence that process equipment and ancillary systems are capable of consistently operating within established limits and tolerances.

The OQ of the complete system involves testing all functions in use. These should be tested either separately as single functions, or as a part of the workflow (PQ) in which they will be used. OQ is described in more detail in Chapter 15.

11.16

Process/Performance Qualification

The FDA Glossary definition of Process/Performance Qualification (PQ) is as follows: Establishing confidence that the process is effective and reproducible.

The PQ includes all maintenance activities to ensure that the system will stay in a validated state during the live phase of the life cycle. This will be described in SOPs and documented when done. In this model, the PQ phase also includes DQ/IQ/OQ/PQ for each new item (customization, instrument connection, report, static data, etc.) added to the system before the item can be taken into live use. The number of SOPs needed for a system may vary, but for a complex system it is normally in the range of 15–25, depending on the company’s rules for the maximum number of pages in an SOP, as well as the variables in the system. Example, an explanation of how to build the static data or templates in the Laboratory Information Management System (LIMS) may be included in one very large SOP, or one for analytical methods, one for specifications, one for sample types, one for instruments to be connected, and so on. PQ is described in more detail in Chapter 16. The SOPs are described in Chapter 5.

11.17

The Validation Master Plan

The Validation Master Plan (VMP) is the company’s plan for handling validation. It usually covers several or all systems, and it may also cover topics other than the IT system; for example, process validation and analytical methods validation. There is a big choice of where to document what. A validation master plan for IT systems validation is necessary only if the QMS does not cover the topics listed below. If the QMS does cover these topics, a VMP can be a prioritized list of systems to validate with references to the QMS or it can be omitted altogether. If the plan has a limited time frame, it might state that over the next year these named systems must be validated. If it is a general validation master plan, it will only state how it should be used, while an external document will show which systems are planned for the next period. The description below covers VMPs for computerized systems only. The document formalities are included in Table 11.1 .

P1: OTE c11

JWBK188-Segalstad

168

September 15, 2008

13:33



Table 11.1 Document Formality Document formalities for each page of the document:

Document name; Document ID; Page x of y. Document formalities for the front page of the document:

r r r r r r r r

Document name Document ID Document version Document date Document valid from Who produced the document: author name, date, and signature Who approved the document: approver name, date, and signature Who authorized the document: authorizer name, date, and signature

An obvious reference is the internal QMS framework for validation. Furthermore, the VMP refers to the standards to be complied with, if this isn’t already stated in the QMS. In the pharmaceutical industry, these will normally be the GxPs with their inherent guidelines for IT validation, and specific guidelines for whatever products or testing the company is manufacturing or doing. Additionally, ISO (www.iso.org), IEEE (www.ieee.org), or other standards may be applicable, either because of certification/accreditation or because they simply make sense in the context. The standards say what needs to be done, but rarely how to do it. It is also appropriate to make a VMP for a nonpharmaceutical industry, as it gives an overview of what to do. It is a way to document the organization’s plans for validation. The tools used in the validation process very often cover GAMP and its guidelines. Several companies have stated that GAMP is an internal mandatory standard. The VMP must include how to assess risks if this has not already been described in other parts of the QMS. This assessment will make it possible to optimize the validation by focusing on the higher-risk areas and reducing efforts in the lower-risk areas. Without applying the risk-based approach, GxP systems should be defined as high-risk systems. Risks are described in Chapter 12. Software categories can be defined internally or externally, as described in Chapter 5. Requirements for validation documents for each system will be needed here, if they are not described in the QMS. Basically, these include the requirements for a Validation Plan (VP), with a corresponding Validation Report for each system. The VP is described later in this chapter. The phases in the validation – for example, DQ/IQ/OQ/PQ – may be defined here if they are not defined in other places in the quality system. In any case, requirements for system-specific plans and reports should be listed. For each phase, this includes demands for writing a plan, the testing to be done, the documentation to be created, and the report. The VMP also defines the input and output of each phase, as well as the prerequisites for the start of the phase. The expected output from a phase should be defined, and what

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


The Validation Plan

169

comprises the end of the phase. Something should also be said about the timing of activities relative to each other. The VMP should also cover high-level requirements on how to deal with external suppliers of hardware, software, and services as appropriate. As a VMP covers several different systems, it can be difficult to state the organization of each system validation. However, it can include requirements for roles involved in the validation of each system. It could also state that, for smaller systems, several roles can be held by the same person. However, it is good quality practice not to control or approve one’s own work, so independent roles need to exist for approval and authorizations. Strategies can differ between systems, and it should be possible to differentiate on the basis of risks, software categories, and technical issues. The document can include an overview of strategies, and whether or not automatic testing tools are allowed, preferred, or considered to be inadvisable. The VMP must refer to SOPs and other parts of the QMS in the organization. Repeating their content in the VMP should be avoided, as that can cause conflicts if the other documents are changed. A glossary should be as high up in the QMS hierarchy as possible. The glossary defines the expressions used in the organization, and will ensure that the same expressions are not defined differently in the Validation Plans for the various systems. If there is no central glossary, the definitions could be included in the VMP. The VMP should also include the requirements for a project plan for each validation project, if these have not been included in the QMS.

11.18

The Validation Plan

Is a Validation Plan VP needed? Without a shadow of doubt, the answer is ‘Yes!’ The Validation Plan covers one system. The VP defines how to validate that system and who is responsible for the tasks. The main purpose of a Validation Plan is to control and manage the various validation activities, such as DQ, IQ, OQ, PQ, training, SOP reviews, audits, and so on, and is connected to one specific validation project. The content of the Validation Plan depends on all the higher-level documents in the organization: The QMS – including the Quality Manual (QM) and the Standard Operating Procedures (SOPs) – and the VMP. It is therefore difficult to say that one thing should be included while another should not be – as before, it all depends . . . The general guidance is that if something has been described somewhere else, refer to that instead of repeating it in the current document. A few examples are as follows: r Risk assessment for this system has already been done according to SOP xxx. The risk assessment showed that the system is high-risk. Please see the details in risk report xxx r Change control will be done according to SOP xxx r The project plan will be drawn up according to the requirements in the VMP [document reference] or according to SOP xxx r Definition of phases in the validation are according to the quality manual/SOP xxx/VMP (as appropriate)

P1: OTE c11

JWBK188-Segalstad

170

September 15, 2008

13:33



On the other hand, if the higher-level documents don’t include enough detail, the details must be included in the VP. If, for example, the VMP doesn’t exist and the SOPs only state that ‘this must be planned/done,’ here is the place to do it: Include the content of the VMP listed above, in the VP, but fine-tune it to fit this particular system. Regardless of what the higher-level documents say, there is a need for a detailed VP with references to the other documents. The VP ties all of the requirements together for this specific system, even if it feels as though you are only making a ‘summary VP.’ Remember: The Validation Plan is the overall plan for how to validate this specific system. An accompanying report will be prepared later as an answer, and will serve as the documentation that the plan has been followed. The report is described below. The document formality is shown in Table 11.1. Which external and internal references form the framework for the validation? There might be additional SOPs to refer to; for example, system-specific SOPs. A risk assessment must be made for this system, based on internal requirements and/or the VMP. An assessment of software category or categories for this system should be made. This may actually involve more than one category if the system is an off-the-shelf system with additional customization. The VP should include information on the roles included in the validation process, but it shouldn’t include the names of the persons involved, with the exception of those writing, approving, and authorizing the document. Project members may change during the validation period, and if the names are included, this will require an update of the document. For the names of the persons involved, refer to the project plan. The project plan is rarely a controlled document from a validation point of view, and it will not normally need the same formal approvals and authorizations as the other validation documents. This means that it can more easily be kept updated. Based on the risks, software categories, and technical issues, the validation strategies should be determined in the VP. If no risk assessment has been made, there should be an overview of what is needed if the system or its parts are high risk or medium risk. If automatic testing tools are to be used, this can be included in the strategy chapter. If the QMS allows, it may be feasible to combine two or more phases in the same document. It is relatively common to combine the OQ/PQ plan and testing in one document series (plan–testing–report). For small systems or revalidation with few activities, a combined IQ/OQ/PQ can be acceptable. However, the VP must clearly specify that this will be done, and that all aspects of each phase are included in the combined documents. Systems that cover more than one site or part of the organization may need a different strategy from a one-site system. This should be covered in the VP as well. If it is the exact same system software, used the same way in two different settings, it may be possible to make a complete DQ/IQ/OQ/PQ in one place and roll that out to the others, using only an IQ to make sure that the installation is the same. If the users feel uncomfortable with this approach, reduced OQ/PQ testing, using the same test scripts and expected results as before, may prove that the system also works as intended. There will most likely be a need to create new SOPs and edit existing SOPs for the system and for the workflow that the system is a part of. An overview of these SOPs should be included in the VP.

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


The Validation Plan

171

If the system replaces another system or a manual system, there will also be a number of other SOPs describing the old way of working that need to be updated due to this new system. List all appropriate procedures and state that these need to be assessed for changes, how the assessment is to be documented for each SOP, and when the SOPs are to be updated. In some cases, it is just a matter of changing the name of the old system to the name of the new system; in other cases, the whole workflow changes, which means that the SOP has to be completely rewritten. A glossary should be included in the VP only if there is no other glossary in the QMS or VMP, or if the expressions used are not included in the other glossaries. Again: Don’t repeat this work if it already exists somewhere else. Errors are likely to be found during testing. These may be handled according to normal error-handling procedures in the organization, but sometimes these procedures are not optimal for the validation project. Explain how errors will be handled during the project. This is covered in more detail in Table 11.2. Table 11.3 is a form that can be used for error handling. The text and the form need to be in synchronization. Likewise, change control may need to be done differently during the project. For example, sometimes there are errors in the test scripts, and it must be possible to correct and change these scripts without involving a lot of other people. It should also be permissible to add new test scripts after the test protocol has been approved, but not to omit any that have been approved. Validation does create a Giant Mass of Paper (also nicknamed GMP). It might be wise to create an archiving system for all documents generated for this system. This is relevant if the organization uses paper archives. Some organizations have requirements for archiving one type of document in one place and another type of document somewhere else. In that case, you should discuss whether copies of all documents should be deposited in the ‘system archive.’ This isn’t an issue if documents are archived electronically in a Document Management System (DMS), where they can be tagged with the system name. However, that will require the DMS to be validated and under control, with documented access rights, an audit trail, and so on. Electronic storage of, for example, Word and Excel documents in a dedicated server directory isn’t considered as a document management system, because the security, audit trail, and access are insufficient. The testing should be done on the test instance of the system (the various instances are described in Chapter 5). Include text to make sure that all data from validation, qualification, and testing is backed up and archived. This is very important quality data, and without it you suddenly don’t have the raw data – and your validation effort is worthless. We do need a Validation Plan. We need a separate VP for revalidation only if the VP (or another QMS document) states that this is needed. Sometimes the revalidation consists of only one of the IQ, OQ, or PQ. The single qualification effort can then be controlled by the IQ, OQ, or PQ plan. This is described in more detail in the following chapters. The acceptance criteria should be stated in the VP. The acceptance criteria are that each of the qualifications has been done with acceptable test results, and that the plan has been followed and everything has been documented accordingly. The Validation Plan should also require that a Validation Report shall be written. The plan should include details of what the report is to contain.

P1: OTE c11

JWBK188-Segalstad

172

September 15, 2008

13:33



Table 11.2 Error Handling during Qualifications Error Handling It is important that those who validate the system know how to identify, categorize, and handle errors that occur during the validation, as well as during normal use later. All errors All errors shall be reported on the error form, evaluated by the system administrator, followed up with a plan within two weeks, and be subject to corrective actions depending of the type or error, and where it can be solved. The error forms with additional documentation shall be collected as a part of the validation documentation. The error form is included in this document. Errors that can be solved internally shall be corrected within two weeks as described below. Errors occurring in the software or the configuration of this software shall be handled according to the contract with the supplier. How to handle errors Description The error symptoms and how it occurred shall be described in as much detail as possible by the user discovering the error. Use the error form for this, and continue on a separate page if needed. Include possible screen dumps or reports of what was done. Reconstruction The user shall report the error immediately to the system administrator or other key persons and try to reconstruct it while documenting in detail what is done – while it is being done. Include possible screen dumps or reports of what was done. Diagnosis The user may suggest the diagnosis. The system administrator shall decide what the diagnosis is. If possible, the diagnosis shall include a description of the cause. Investigation The system administrator and/or the user shall investigate if it is possible to provoke the error by other means, such as other data, other commands, and so on. Seriousness The seriousness is assessed by the system administrator, using the score plan below. Assessment of seriousness The assessment of how serious the error is shall be done according to the score plan. The score plan contains guidelines to how to assess the seriousness. If the system administrator is unsure of what score to give, he/she shall discuss the matter with knowledgeable persons before the score is set. Score

Description and examples

0

Not a system error. Error form, corrective actions. Examples: User errors. Provoked unnatural errors. Minor error: Can be tolerated. Error form, corrective actions. Missing documentation directly dealing with the system as stated in the list of documents.

1

Handling

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


The Validation Plan

173

Table 11.2 (Continued) 5 10

Medium error: Can be tolerated. Examples: Information dialogue box is missing. Major error: Not tolerated. Examples: Result mix-up or data corruption. Reports contain major errors that update and corrupt the results; there may also be other corruption of data.

Error form, corrective actions. Error form, corrective actions. Stop the validation. Report immediately to LOQ and the vendor. QA shall evaluate if validation can continue before the corrective actions have been taken.

Corrective actions Internal matters Corrective actions for internal matters shall be done as described in the change control SOP and the qualification/validation SOP. The internal matters include all errors in the IQ/OQ/PQ related parts of the installation. Corrective actions shall be started within 10 working days of the discovery, and be finished as soon as possible. Documentation errors shall be corrected within 20 working days of discovery if possible. The actions for resolving the internal errors are:

r r r r r r

planning the correction if appropriate correcting the error documenting how the correction has been done revalidating/retesting when possible or if appropriate reporting the corrective action and the revalidation result approving and/or authorizing the corrective action

Application Corrective actions for errors in the delivered LIMS application shall include:

r Reporting the error to the supplier within two weeks. The error report shall be written for documentation purposes. Each phone call must be followed by a written statement, which shall be retained for documentation purposes. Letter/e-mail/fax are equally good reports r Acknowledgement from the supplier, with an estimate of what will be done to correct the error The error is regarded as solved when these actions have been taken. When a bug fix or upgrade of the system is received, this shall be subject to change control and revalidation as described in the SOPs. Errors that have been corrected before the Validation Report is written need not be included in the calculations of errors (see acceptance criteria), but shall be included in the error overview and discussions in the report. The reason for exclusion from the calculation is that they are no longer errors if they have been corrected. Examples of errors

r User-related errors or operating errors: The users will probably make errors during the validation. These may include giving the wrong command or forgetting to give a command, typographical errors, forgetting to do something, etc. The result of such an error may be that there is an extra version of a result, which will have to be explained, and therefore has to be reported. . .. These errors will have no consequence for the result of the validation. However, if the user error causes system errors, these shall be investigated and evaluated as such (Continued)

P1: OTE c11

JWBK188-Segalstad

174

September 15, 2008

13:33



Table 11.2 (Continued)

r Provoked errors: Errors that don’t occur in a normal operating environment, but are seen because of provocation during the validation. If a test has the expected result ‘Fail,’ the fail is the correct result, and not an error r Errors in the documentation availability: Errors in the documentation availability may include missing documents, incorrect versions of documents, unauthorized storage, unauthorized copies, and so on r Correctness of documentation: Errors in the descriptions of the systems, the SOPs or other documents may be found during the validation r Error messages from the system: Error messages from the system shall be reported immediately to the system administrator. The user and the application manager shall try to provoke the system to give the same message again, in order to reconstruct the whole situation. All steps shall be documented as described above. The error shall be investigated in order to find the possible reason for the message Errors in transfer of data: Errors in transfer of data shall be thoroughly described in order to document under which circumstances they occur.

r Problems with file integrity: It shall be documented which files can be edited and with which tools this can be done. SOP descriptions regarding file protection must make it illegal to tamper with the system, even if this is technically possible

11.19

The Validation Report

The Validation Report (VR) corresponds to the Validation Plan, and includes reference to the documents that were planned, as well as an overall conclusion of the validation. This report can usually be made by copying the VP, renaming it as the Validation Report, and then editing it as described here. Remember that this is the overall and high-level report, and it shouldn’t repeat the details of the underlying reports for the various qualifications. A conclusion must be added; for example, that all documents have been created as planned, and that testing shows that the system is fit for use. If this isn’t the correct statement, write that so-and-so was changed due to whatever, and that you found errors that were fixed, and errors that haven’t yet been corrected. Of course, the wording needs to be changed from ‘shall be created/done’ to ‘has been created/done.’ For each requirement for a document in the plan, include the reference to the created document, with the document name, version, and date. The output from the Validation Report is that the system is fit for daily use, or perhaps not fit for daily use, depending on the test results. The authorization of the report means that the system can be used or not used, according to the report’s conclusions.

11.20 11.20.1

Tasks Create the Table of Contents for the Validation Master Plan or Validation Plan

Choose a relevant system that you know, with relevant standards for where the system is to be used. If you created a risk assessment for a system, use it as a basis for this task.

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


Tasks

175

Table 11.3 An Error Form Used during Qualifications Error form Page 1 Part 1 to be filled in by person discovering the error:

User ID:

Date:

System module:

Error type:

User

Program

Other

Evaluation of error:

Emergency

Normal

Other, description:

Reference to validation part:

Error message:

Error description, diagnosis, and possible suggestions for solution/action:

Date:

Signature:

(Continued)

P1: OTE c11

JWBK188-Segalstad

176

September 15, 2008

13:33



Table 11.3 (Continued) Part 2 to be filled in by system administrator:

Error type:

Degree of seriousness:

Review of error:

For corrective actions, see next page.

Date:

Signature:

Error form Page 2 Part 3 to be filled in by person to initiate corrective actions:

Responsible person:

Date:

Signature:

Description of corrective actions (refer to other documents if applicable):

P1: OTE c11

JWBK188-Segalstad

September 15, 2008

13:33


Tasks Table 11.3 (Continued) Change in SOPs or other documentation needed No Yes, in document identification:

Part 4 To be filled in by person to approve the corrective actions:

Documentation for corrective actions accepted as sufficient

Revalidation/testing approved

Comments:

Date:

Signature:

177

P1: OTE c11

JWBK188-Segalstad

178

September 15, 2008

13:33



Draw up the table of contents for the Validation Plan based on the standards and your risk assessment. State any prerequisites you may have that will affect the table of contents.

References R R 1. GAMP 5 Good Automated Manufacturing Practice (GAMP ) Guide for A Risk-Based Approach to Compliant GxP Computerized Systems, 4th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. R Good Practice Guide: A Risk-Based Approach to Compliant Electronic Records and 2. GAMP Signatures, 1st edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. R Good Practice Guide: Validation of Laboratory Computerized Systems, 1st edn (2005), 3. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-39-7, www.ispe.org. R Good Practice Guide: Testing of GxP Systems, 1st edn (2005), International Society 4. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. R Good Practice Guide: Global Information Systems Control and Compliance, 1st 5. GAMP edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-43-5, www.ispe.org. R Good Practice Guide: Calibration Management, 1st edn (2001), International Society 6. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, US version ISBN 1-931879-25-7, German version ISBN 1-931879-26-5, www.ispe.org. R Good Practice Guide: IT Infrastructure Control and Compliance, 1st edn (2005), 7. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-42-7, www.ispe.org. R Good Practice Guide: Validation of Process Control Systems, 1st edn (2003), Interna8. GAMP tional Society for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org. R Good Practice Guide: Electronic Data Archiving, 1st edn (2007), International Society 9. GAMP for Pharmaceutical Engineering (ISPE), Tampa, FL, www.ispe.org. 10. US FDA (2005) 21 CFR Part 210 Current Good Manufacturing Practice in Manufacturing, Processing, Packing, or Holding of Drugs; General, US Food and Drug Administration, Rockville, MD, www.fda.gov. 11. US FDA (2005) 21 CFR Part 211 Current Good Manufacturing Practice for Finished Pharmaceuticals, US Food and Drug Administration, Rockville, MD, www.fda.gov. 12. PIC/S (2007) PI 011-03 Good Practices for Computerized Systems in Regulated ‘GxP’ Environments, PIC/S, Geneva, Switzerland, www.picsscheme.org. 13. ICH (2006) Q9 Quality Risk Management, ICH, Geneva, Switzerland, www.ich.org. 14. ISO 14971:2007 (2007) Medical Devices – Application of Risk Management to Medical Devices, International Organization for Standardization, Geneva, Switzerland, www.iso.org. R R 4 Good Automated Manufacturing Practice (GAMP ) Guide for Validation of Auto15. GAMP mated Systems, 4th edn (2001), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-17-6, www.ispe.org. 16. US FDA (2006) Glossary, US Food and Drug Administration, Rockville, MD, www.fda.gov.

P1: PIC c12

JWBK188-Segalstad

September 18, 2008

20:12


12 Risk Assessment and Risk Management


What risks are Risk tools How to assess risks How to manage risks

12.1

Introduction

We all use the word ‘risk’ every once in a while, with the meaning as defined in the Concise Oxford Dictionary: ‘Hazard, chance of bad consequences, loss and so on, exposure to mischance.’ This basically also covers the science of risk assessment and risk management, but this science has added several other words to the vocabulary to explain the details. This vocabulary is listed in Table 12.1, which shows that the words are defined slightly differently in a couple of standards/guidelines, but that the definitions are not contradictory. Even if we know the definition of the word ‘risk,’ most people don’t really understand it. Risk is negative. The equivalent word for the positive occurrence is ‘chance,’ but a lot of people use ‘risk’ for both the positive and negative possibilities. Table 12.2 gives a couple of examples of people’s perception of risk/chance. In order to understand and manage risks, one must understand the processes of which they are a part. Risks vary in different processes, and it isn’t possible to transfer the assessment of risk from one process to the other. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: PIC c12

JWBK188-Segalstad

180

September 18, 2008

20:12



Table 12.1 Risk Terminology Definitions Risk

Risk analysis Risk assessment

Risk control

Risk evaluation

Risk management

A measure of probability and severity of undesired effects. Combination of the probability of occurrence of harm and the severity of the harm. Hazard, chance of bad consequences, loss and so on, exposure to mischance. Systematic use of available information to identify hazards and to estimate the risk. A comprehensive evaluation of the risk and its associated impact. Overall process comprising a risk analysis and a risk evaluation. Process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels. Judgment, on the basis of risk analysis, of whether a risk which is acceptable has been achieved in a given context. Systematic application of management policies, procedures and practices to the task of analyzing, evaluating and controlling risk.

The FDA Glossary, with reference to the IEEE The GAMP risk guide

The Concise Oxford Dictionary, seventh edition The GAMP risk guide The FDA Glossary, with reference to the DOD The GAMP risk guide The GAMP risk guide

The GAMP risk guide

The GAMP risk guide

Table 12.2 Perceptions of Risk and Chance Most People Don’t Understand Risks – 1 According to Aftenposten, Norway, March 8, 2004, citing a master’s thesis by Kate Dockery, of the University of Florida, we are afraid of things that might happen, which most likely are not going to happen, but we are optimistic when it comes to situations that are likely to happen. One example that she uses is marriage. People get married, thinking that the 50% divorce rate is going to happen to others and not themselves. Most People Don’t Understand Risks – 2 In Norway, some 350 people a year die in traffic accidents, and about 350 people a year win one million kroner (approximately $200 000) in state lotteries. Everyone who spends money on the lotteries is sure that they will be one of the 350 lucky people who win, and no one ever thinks that they will be among those killed in traffic, even if the likelihood is the same. There is also a big discussion in Norway about how dangerous wolves are. Many people are scared of them, although there are fewer than 100 wolves scattered all over the country, and no one has been killed by wolves for the past 150 years. At the same time, everyone is in the traffic almost every day, where 350 people get killed and many thousands are wounded every year. If a wolf is seen in a neighborhood, people rush to drive their kids everywhere. Why are they scared of wolves and not of traffic? Kate Dockery might be right!

P1: PIC c12

JWBK188-Segalstad

September 18, 2008

20:12


Risk Assessment Tools

181

Risk assessment and risk management is a large topic, and can easily become the subject of a complete book or class by itself. This chapter will not go in depth on risk assessment and risk management. For those who want to know more, the following reading can be recommended: r r r r r r

ICH guideline Q9 on quality risk management [1] GAMP 5 [2] GAMP risk-based approach to compliant electronic records and signatures [3] ISO 14971 medical device standard [4] the book by Jones and Ashenden on risk management for computer security [5] the book by Kumamoto and Henley on probability risk assessment and management for engineers and scientists [6]

12.2

Addressing Risks

In order to manage risks, we first need to identify them. Risk management involves two main steps: r risk assessment, where risks are identified and defined r risk management, where decisions are made as to how to handle the risks Why should we worry about risk management for automated systems? According to Poul Skallerup [7], it is because safety-related functions in pharmaceutical production are implemented software, and critical functions in process control are implemented by software; for example, batch processing and calculations. Software in automated systems will always have systematic faults and never random faults.

12.3

Risk Assessment Tools

There are several tools available to assess risks. These take different approaches, and may yield very different results when the same item is being assessed. When selecting the tool to be used, it is imperative that you understand what you are trying to achieve. The two most common tools are HAZardous OPerations (HAZOP) and Failure Mode Effect and Criticality Analysis (FMECA). The principle of HAZOP is to determine in what way a user or the environment can influence a perfectly functioning device in a harmful way, and what the end result of that will be. In this method, a device may be anything that needs to be tested. It could be a medical device or a computerized system, or anything else. In HAZOP, one needs first to describe the device, its functions, and its intended use; for example, based on product specification, basic concepts, or similar products. The next step is to identify foreseeable misuse of the device. Tools in that process are a description of the intended use, the study of complaints, and hazard checklists; for example, those stated in ISO 14971. Creativity and brainstorming may also be great tools for this identification process. The output of the hazard analysis may be suggestions for design changes, specifications for testing, and changes to the user manual.

P1: PIC JWBK188-Segalstad

182

September 18, 2008

20:12



The method isn’t very suitable for detecting hazards due to component or assembly failure for a physical device. It doesn’t automatically evaluate combinations of disturbances. In FMECA, the interfaces of the device are described. This can be done by drawing up a table with the names of all items in both the row and column headings, and creating a list of all the interfaces between them in the middle. Even in a simple device, there are many interfaces. The output of an FMECA analysis is usually about the same as for HAZOP, though the two techniques do occasionally give very different results. The method isn’t suitable for determining individual component failures. It doesn’t automatically evaluate combinations of disturbances. A classic FMEA model for critical software is shown in Figure 12.1.

12.4

Risk Assessment

The principle of risk assessment is to see risk as a function of likelihood and impact. In order to do this, the risks must first be identified. The identification step is the determination of whether the system function or subfunction represents a risk when assessed against a series of criteria. The outcome of the discussions must be documented, even if the result is that this function doesn’t pose a risk. There is no fixed answer to the number of levels for impact, but it is most common to have three: direct (high) impact, indirect (low) impact, and no impact. According to

1

Medium

3

2

1

Low

3

3

2

High

High

1

Medium

Medium

2

Low

Low

High

Probability of Detection

Risk Classification

Risk Likelihood

Impact

c12

1

H

H

M

2

H

M

L

3

M

L

L

M

Reconsider Design Extra Procedures Enhanced Testing Extra procedures Enhanced testing

L

Limited testing

H

Figure 12.1 Risk Classification According to the FMECA Method. Reproduced by permission of Pharmadule.

P1: PIC c12

JWBK188-Segalstad

September 18, 2008

20:12


Risk Assessment

Technical Goal

Regulatory Requirements

Cost

Project Plan

4 Unacceptable

Not reached

Not reached

More than 50% over budget

Not reachable

3 Undecided

Very reduced

Serious discrepancies

Serious ~30% over budget

Serious delays >30%

2 Acceptable after discussion

Somewhat reduced

Some discrepancies

Some ~10% over budget

Delays ~10%

1 Acceptable without discussion

Minimally reduced

Parts of some requirements missing

Within budget

Within project plan

Figure 12.2

183

Four-Level Risk Assessment.

Magnus Jahnsson [8], the indirect impact level doesn’t add any value to the assessment, so the only two levels that are relevant are impact or no impact. There is always the question of how many levels of risks should be defined. In the examples below, three levels are used: high, medium, and low. It is possible to have more, but then the question of definitions is hard and will lead to long discussions. Only advanced risk assessors should use more than three. A four-level division will give too many options, and the final result won’t be very different from the three-level division. Figure 12.2 shows one company’s identification of risks and how it defines its four-level seriousness/impact scheme. The company has included four risk types (technical goals, regulatory requirements, cost, and project plan) in the assessment. Identify Product/Process Risks This step is the determination of whether the system function or subfunction represents a risk when assessed against a series of GxP criteria. Regardless of whether your organization is a production or laboratory facility, the same risks are still present, even if the focus may be more on results or customers than on patients. Unidentified risks in a forensic laboratory can have serious consequences: people who may end up in jail due to unidentified and/or unmitigated risks. Create your own list, to include your organization’s functions and potential risks. It is easy to see from the list below that computerized systems are involved in several of these processes. Examples of risks that may be identified include, but are not limited to, the following: r The pharmaceutical quality of the finished product (including clinical supplies): – incorrect composition – raw material errors

P1: PIC c12

JWBK188-Segalstad

184

September 18, 2008

20:12



– packaging material errors – integrity of QC laboratory results r The safety of patients and consumers: – adverse reactions – mix-ups involving samples r Incorrect data for the support of regulatory submissions: – the integrity of the regulatory records – statistical evaluations – calculations of results from test data A secondary element in the risk assessment process is to determine whether the system function or subfunction represents a risk to the business. Examples of risks that may be identified include, but are not limited to, the following: r Corporate reputation: – adverse publicity – impact on earnings – competitive advantage r Brand recognition: – loyalty (customers and supply chain) r Risk to manufacturing/process equipment: – equipment down-time – equipment damage – the cost of replacing equipment parts – the potential for injury (health and safety) r Risk to the operator Having determined that a particular function or subfunction may be a risk, the assessment should proceed to identify the various risk scenarios (i.e., the events that identify the risks associated with the use of the system). For each event, consider what the likely effect will be. Remember that there may be more than one in each case. This may be done by creating a table with the following columns: ‘Function,’ ‘SubFunction,’ ‘Risk scenarios,’ ‘Effects,’ ‘Likelihood.’ The next step is to determine the likelihood, also called the ‘frequency’ or ‘probability,’ of an adverse event occurring. The approach requires the team to consider the likelihood of the adverse event occurring within a given time period (day/month/year) or per quality of transactions, and to assign a value to that estimate. For example: Low: Medium: High:

The frequency of the event is perceived to be once per 10 000 transactions. The frequency of the event is perceived to be once per 1000 transactions. The frequency of the event is perceived to be once per 100 transactions.

It may be difficult to assess the likelihood of failed software. In that case, it may be wise to assign the value ‘high’ unless there are reasons for assigning lower values.

P1: PIC c12

JWBK188-Segalstad

September 18, 2008

20:12


Risk Management

185

Risk assessment also includes assessing how severe or serious the impact will be if the risk event actually happens. The effects may include impacts on: r regulatory compliance r financial issues r company reputation The impact of risks occurring may be described as follows: Low: Medium: High:

Expected to have minor negative impact. The damage would not be expected to have a long-term negative effect. Expected to have a moderate impact. The damage would be expected to have a short-to-medium term negative effect. Expected to have a high impact. The damage would be expected to have significant long-term effects and potentially catastrophic short-term effects.

Each threat found should be assessed for seriousness (impact) and likelihood (probability). Risk classification is shown in Figure 12.1, where the likelihood, impact, and probability of detection helps to determine whether the risk is high, medium or low. Please note that the above table is only a model and can therefore only give an indication of the degree of risk. For example: How should a risk with high impact and low probability be compared to a risk with low impact and high probability? Are they equivalent as to risk, or should one be given a higher risk classification than the other? This is a matter where you must use your own judgment to ensure the right level. Assess Probability of Detection The purpose at this stage is to identify whether the risk event can be recognized or detected by other means in the system. In that way, a high risk with a high probability of detection may not pose such a serious threat, because it can be recognized quickly and suitable corrective action can be taken. The probability of the risk being detected can be estimated as follows: Low: Medium: High:

12.5

Detection of the fault condition is perceived to be unlikely (e.g., in less than one event in every three transactions or operations). Detection of the fault condition is perceived to be reasonably likely (e.g., one event in every two transactions or operations). Detection of the fault condition is perceived to be highly likely (e.g., one event in every one transaction or operation).

Risk Management

The management of risk includes risk mitigation and determining the appropriate measures for mitigation. By combining the risk classification with the probability of detection, it is

P1: PIC c12

JWBK188-Segalstad

186

September 18, 2008

20:12



possible to prioritize the fault conditions associated with each adverse event based upon those areas of greatest vulnerability. Once these priorities have been determined, the team can proceed to define and document the appropriate measure(s) to mitigate the adverse events that pose the risks. You can create a 3 × 3 table like Figure 12.1 and decide whether the risks should be high, medium, or low for the various combinations. Those risks that end up with a high value are the most important ones to mitigate. Risks may be mitigated or avoided. The solution depends on whether you are a supplier or a user organization, and of course also on what the problem is. It is impossible to say here exactly what the solution should be for an unknown problem in an unknown system. Some suggestions that you may find useful are included. Hopefully they at least will make you start thinking in the right direction. Mitigation may include, but is not limited to, the following: r Modification of a process or system design. The supplier can change the programming and issue a new version or a patch. The user can change which part of the system is used for this particular process r Modification of the process design by additional data verification checks to reduce data entry errors by entering limits to the input values. The limits are described in Chapter 18 r The introduction of external procedures; for example, double-checking. This is common for clinical systems r Modification of the product design by including fault-tolerance in the automated system; for example, using replicate parts, system mirroring, and so on r Modification of project strategies r Reassessment of the project structure and of the key people for the roles in the project r Reconsideration of the amount of auditable built-in quality by adding or removing formal review points dependent on the identified risks r Modification of the validation approach r An increase in testing for high-risk areas r A decrease in testing for extremely low-risk areas r The elimination of risk r Avoidance, when the risks are so high that the new way of working should not be implemented Risks that have been managed may need a reassessment to find out which level they now belong to. While the managed risks ideally should be reduced from high to medium or low, or from medium to low, the changes may have an impact on other aspects. Sometimes this is because risks are easier to see and identify because we understand them better. Sometimes a function that was assessed as low risk because it wasn’t used very much will now have assumed a higher risk because it has taken over from the use of the original function. The conclusion is that, in any process or system, risks are not just to be assessed and managed once and for all. They need reassessment to obtain the current status.

P1: PIC c12

JWBK188-Segalstad

September 18, 2008

20:12


References

12.6 12.6.1

187

Tasks Risk Assessment

Choose a relevant system that you know, with relevant standards for where the system is to be used: r do a risk assessment r suggest how to manage the high-risk areas

References 1. ICH (2006) Q9 Quality Risk Management, ICH, Geneva, Switzerland, www.ich.org. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based Ap2. GAMP proach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. R Good Practice Guide: A Risk-Based Approach to Compliant Electronic Records and 3. GAMP Signatures, 1st edn (2005), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-38-9, www.ispe.org. 4. ISO 14971:2007 (2007) Medical Devices – Application of Risk Management to Medical Devices, International Organization for Standardization, Geneva, Switzerland, www.iso.org. 5. Jones, A. and Ashenden, D. (2005) Risk Management for Computer Security: Protecting Your Network & Information Assets, Elsevier, Amsterdam, ISBN 0-7506 7795 3. 6. Kumamoto, H. and Henley, E.J. (1996) Probabilistic Risk Assessment and Management for Engineers and Scientists, Institute of Electrical and Electronics Engineers, New York, ISBN 0-7803-6017-6. 7. Skallerup, P. (2003) Risk Management in Automated Systems, Proceedings of the ISPE Conference on Risk Management, Copenhagen, Denmark. R Nordic Conference, Stock8. Jahnsson, M. (2007) Risk Management, Proceedings of the GAMP holm, Sweden.

P1: PIC c12

JWBK188-Segalstad

September 18, 2008

20:12


P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40


13 Development Qualification

This chapter discusses the following: r Development qualification from the supplier’s and the user’s points of view r System selection r System implementation

13.1

Introduction

Development of the system is done in the DQ phase. This phase is defined in various ways in standards and guidelines, and some standards don’t even define DQ as a separate phase. GAMP [1], for example, talks about design, but not as a separate qualification phase. I prefer to include all stages of development in the Development Qualification (DQ) phase [2]. This ensures that DQ is done in a good way, regardless of who did what. Do you really need to go through all of the stages described below? It depends on what type of system you are planning. As a minimum, you will need to write a User Requirements Specification (URS) so that you know what you need, and so that later you can test that the system you purchased is according to your needs. A contract between the supplier and your organization is a must, at least from a business point of view. Whether you need to carry out the rest of the tasks described depends on factors such as: r the risks r the regulatory requirements for validation r the complexity of the system

International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c13

JWBK188-Segalstad

190

September 15, 2008

13:40



DQ-1

URS Ranking Audit

DQ-2 Contract

Implementation

DQ-3

Figure 13.1

Three-Part Development Qualification.

r whether the system is used by few or many people, in a small or large part of the organization – a large and complicated system with many variables will need more done to it than a small and simple system Regardless of what you decide to do, document your decision and the reasons behind that decision. The system should be selected based on four different assessments: r URS (objective assessment): That the user’s requirements are met r Built-in quality (quality assessment): That the requirements for the built-in quality are met r Functionality and ‘user-friendliness’ (subjective assessment): That the system is easy to use r Contract issues (purchasing/legal assessments): That the contract can be agreed on DQ has several subparts, as shown in the model for DQ in Figure 13.1: r r r r r

the URS; answers to the URS and ranking of the answers from the suppliers system development – possible audit selection of the system system implementation

13.2

The User’s Point of View

Few systems are created specifically for the user by the supplier; most commercial systems are sold off the shelf to other customers as well. This means that users don’t have any impact on the quality of the development that has been done over the previous years. However, users do need to check that the development has been undertaken in a quality fashion. If the development is to be done especially for the customer, the customer can state the requirement that the programming must comply with certain standards. If the customer buys a commercial system, he or she can only control the fact that it has been done. Additionally, there are the contractual issues that need to be resolved before the system is implemented and paid for. Contracts need to be agreed on, but in general this is a

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40


Project: A New System in the User Organization

191

business issue rather than a quality issue. Without a contract there is no new system. But if the supplier is to customize or configure the system, there is a need to include the quality requirements for the work to be done in the contract. Whether that is based on the supplier’s quality system, on the customer’s, or on a combination, will have to be agreed on.

13.3

The Supplier’s Point of View

Regardless of whether the system is created for a specific customer or is a commercial product, it needs to be developed in a quality way. In general, that means applying ISO 90003 [3] or an equivalent standard to the development process. Suppliers’ quality systems vary from the absence of a quality system, and no understanding of quality, to virtually perfect quality systems, and a very good understanding of quality. Suppliers should take note of ISO 90003 when designing their quality systems. By following the requirements in that standard, they can be reasonably sure that their quality systems will be accepted by the customers when they audit their suppliers. One issue that makes the supplier’s part of the system development different from that of the purchaser is that the supplier needs to have a described model for how to develop the system. The model may be any of the ‘normal’ ones described in the literature for system development, or a different, home-made model. Regardless of the model chosen, the supplier needs to create plans for how to do things in an orderly manner, carry out the tasks, and create reports after the work has been done. The only exception is during the early phases of the system development, if prototyping is used to try to find out what is really wanted; for example, what the screens should look like. Prototyping can of course be used as a tool, but it needs to be accompanied by proper plans once decisions have been made after using the tool. The quality system needs to include all of the elements that are expected in the pharmaceutical industry for production as well as for handling IT systems. These include complaints handling, support, error handling, change control, configuration management, and how to plan, program, test, and report the system development. This is explained more in Chapter 6.

13.4

Project: A New System in the User Organization

Your organization decides that a new system might be needed, and creates a project group for this purpose. The work ahead for the project group is the most important thing you will ever do for this system: The choice of the best new system for your organization. In the mid1990s it was said at the Laboratory Information Management System (LIMS) Conference that half of the LIMS projects failed. No explanation was given, but I’m convinced that there were two reasons: r The first was that requirements were not specified well enough in the URS. You can’t get the system you need unless you know what you want r The second was that the organization’s managers did not take their job seriously as owners of the system. They are responsible for making decisions and funding the system. The key people rarely have that authority

P1: OTE c13

JWBK188-Segalstad

192

September 15, 2008

13:40



I’m also convinced that this isn’t unique to LIMS projects; it happens in projects for all types of systems. The project group must be defined, together with the goals for the project and the people and roles involved. This is described in Chapter 7. In the case of a LIMS, the laboratory people are involved, while in the case of a Material Resource Planning (MRP) system, the production people are involved, to mention a couple of examples. Additionally, IT and Quality Assurance (QA) should be involved so as to be able to voice their opinions on the document.

13.5 13.5.1

The Four Assessments of System Selection Objective Assessment: The User Requirements Specification

The User Requirements Specification (URS) is your organization’s view of the functionality needed for the new system. You found out that you needed a new system, and it is now your job to describe as well as possible what this system will do for you. You can’t get the system you need unless you know what you want. The URS isn’t only necessary so that you can choose the best system, but also so that you can test that the system is in accordance with the requirements. The URS forms the ‘correct/expected answers’ to the validation testing. Without a URS you can’t validate the system, as there are no expected answers. How, then, can you know whether it works for you? The process of writing the URS in itself will also give you a much better understanding of the processes that you want the system to help you do. Now is the time to rethink how you work and imagine how you can improve your processes. Just having a new system doing exactly the same thing, in exactly the same way as you have always done it, doesn’t make your ways of working any more up to date. Writing the URS may seem tedious, but the process of writing and discussion is a good one. If you aren’t familiar with the system yourselves, it might be wise to get external help from a consultant who understands these types of system. This will add a lot to the process of understanding what your organization’s needs are, and how the system can improve the work processes and data security. Making sure that your organization understands its own needs will help you to select the best possible system on the market for the organization’s purposes. When writing a URS, it is important to describe your vision for the system in the organization, rather than stating that ‘The system should include the following information at the top left of the screen . . .’ Describe what your needs and visions are, and not what anybody else, including the supplier, thinks they should be. The URS should be written in detail, as it will form the basis for validation of the system, and it must therefore be possible to test against it. Statements should therefore be clear, concise, unambiguous, and testable. Don’t write all questions so that they need ‘yes’/‘no’ answers, even if these can be useful to a certain extent. Unfortunately, not all answers can be given as ‘yes’ or ‘no.’ Quite often, the answer is given as ‘It is possible to do this, but not the way it has been described in the URS. It may be done by . . .’ It is also likely that if you issue too clear statements on how rather that what, some of the answers will be ‘no,’ whereas the system may be able to solve the requirement in a different way that you hadn’t taken into consideration.

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40


The Four Assessments of System Selection

193

The more complicated issues need to be phrased so that the supplier must give an explanation. Present the supplier with a typical scenario, and ask how this might be addressed within their system. For example, ‘We need to divide samples and send them to different labs for testing, and then report them as one sample. How will you address this?’ The Content of the URS

The IT department may have their requirements as to which hardware, operating systems, and databases they want in the organization. The new system must, of course, also be able to run on the existing network. Normally these are clear requirements, although some may be options. A lot of systems are able to run on a variety of platforms, and it will be a matter of deciding which option you want in your organization. One way of writing the URS is to divide the URS into logical chapters, each starting with an explanation of the current workflow, and continuing with the visions that the company has about the new system in the organization. At the bottom of each chapter there is a table of requirements. Each requirement has an identification number. Some may be clearly stated requirements, while others are more like ‘Explain how your system can solve our vision.’ (Table 13.1) Table 13.2 shows the table of contents for a URS. As this isn’t for any particular type of system, you will need to fill in a lot more detail depending on the type of system you are about to acquire. An example of requirements from a URS is shown in Table 13.3. The URS should be sent out to a maximum of three or four suppliers. There are two main reasons for this: r You will have a problem with comparing answers from more than three or four suppliers. It will also become a big job r Suppliers spend a lot of time answering these large URS documents, and it is only fair to let them have at least a 25% chance of winning the order The next question is: Which of the many suppliers should you send your URS to? If there are, in fact, several suppliers of your new system, it is wise to check them out a little

Table 13.1 Different Approaches to the User Requirements Specification As a consultant, I’ve experienced many different approaches to User Requirements Specifications. Sometimes I’ve been asked to help validate an already chosen system and other times I’ve been involved in writing the URS. One company for contract production asked me to help validate their new LIMS system. I asked to see their URS, and was surprised to hear that they didn’t have one. I first asked why they wanted the system in the first place, and was told that their customers said that they had to have one. I then asked how they had chosen this particular system. They answered that the supplier had said that this (LIMS) system communicated well with the chromatography data system they already had. They had chosen a LIMS based on one single requirement! One company wanted a new system to take care of the reports that they created from their testing. They included all the current typewriter-written reports, and their URS only stated that the system needed to have these reports printed out exactly as the old ones had been.

P1: OTE c13

JWBK188-Segalstad

194

September 15, 2008

13:40



Table 13.2 A User Requirements Specification Table of Contents 1. System in company 1.1 Definitions 1.2 Purpose 1.3 Objectives of the system 1.4 Overall vision 2. URS explanation 2.1 Plans for handling the URS and answers 3. General requirements and questions 3.1 Information, helpdesk, online help, and so on 3.2 Your company’s procedures 3.3 Installation, implementation, and acceptance 3.4 System hardware and software 3.5 Software 3.6 The connection system – third-party software, remote data entry 3.7 Contingency 3.8 Performance and capacity requirements 4. System functionality 4.1 Workflows 4.2 Static data 4.3 Security issues 4.4 Instrument connection 4.5 Reports 4.6 Statistical and graphical data handling 4.7 Scheduling the work in the xxx 5. Daily use 5.1 Daily use of the system – goal 5.2 Workflow explanation 5.3 Control/approval

up front. You can, for example, create a very short URS (maximum one page) where you list the main functionality you need: r For a Laboratory Information Management System (LIMS), this could include questions such as whether the system has functionality for stability planning, pharmacokinetic testing, dissolution testing, patient/animal information, and other items that you need

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40



195

Table 13.3 Detail from a User Requirements Specification for a LIMS 4.2 Security issues LIMS must include certain features for securing the access to the system, the data, and the program files surrounding the system. Electronic signature: The Company plans to use electronic signatures. In order to use E-signatures, there are several security requirements for the rest of the system. The requirements are described in chapter 4.2.3 21 CFR Part 11 Compliance. 4.2.1 Vision

r Users shall have differentiated access to commands according to their needs and types of jobs or roles they have in the organization

r Users shall have differentiated access to which data they are allowed to see, use, change, and maintain

r Labs like, e.g. Microbiological Control Laboratory, which test on all types of samples shall r r r r r

have access to their samples for results entry, but not to other parts of the same samples, which ‘belong’ to other groups No one shall have access directly to the Oracle database uncontrolled by LIMS for viewing, updating, writing to, and deleting data Files where LIMS data or LIMS programs are stored shall have restricted access All changes in LIMS shall include an audit trail giving information on who made the change and when it was made and a mandatory reason to be given explaining why the change was made. The reason shall be chosen from a list Old versions of template parts and data shall not be deleted, but given a different status (‘old/replaced’) The LIMS security system is good enough for the 21 CFR Part 11 Electronic data and Electronic Signature

4.2.2 General Security Issues ID

General Security Requirement Text

4.2.2.A

Explain how access to functions and data is handled in the LIMS

4.2.2.B

Explain how access directly to the database can be limited

4.2.2.C

Which users must have direct access to the LIMS database (not through LIMS)

4.2.2.D

Explain how version control and audit trails are handled for the data in LIMS, both for the template part and for the part that covers the daily use.

4.2.2.E

Files needed by LIMS stored on the server. Explain who needs direct access to these, and how the access can be limited to a minimum of persons.

4.2.2.F

In which cases are old data automatically deleted by LIMS?

Answer

Reference

(Continued)

P1: OTE c13

JWBK188-Segalstad

196

September 15, 2008

13:40



Table 13.3 (Continued) Access levels: 4.2.2.G

Each user has his/her own access with combinations of commands and datagroups (see also 4.2.3.1 Electronic Records).

4.2.2.H

No user has access to commands/datagroups that are not defined for the user (see also 4.2.3.1 Electronic Records).

4.2.2.I

Access to commands shall not be preset in the system, but be configured to the laboratory’s needs.

4.2.2.J

Change in access shall be easy to make for users who can change other users access rights.

4.2.2.K

Only a system manager and a super-user shall have access to the entire LIMS (database, NLS files, etc.).

4.2.3 21 CFR Part 11 Compliance 4.2.3.1 Electronic Records ID

21 CFR Part 11 Requirement Text

Answer

Reference

Section 11.10 General requirements 4.2.3.1.A

LIMS can discern invalid records

4.2.3.1.B

LIMS can discern altered records

4.2.3.1.C

LIMS can generate accurate and complete copies of records in human readable (paper) form for inspection, review, and copying

4.2.3.1.D

LIMS can generate accurate and complete copies of records in electronic (floppy disk, CD, ASCII, .pdf) form for inspection, review, and copying

4.2.3.1.E

LIMS can protect records to enable their accurate and ready retrieval throughout the records retention period

4.2.3.1.F

Limitation of system access to authorized individuals, each with their own, individual account

4.2.3.1.G

Audit trail is automatic and computer generated (Continued)

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40


The Four Assessments of System Selection Table 13.3 (Continued) 4.2.3.1.H

Audit trail is date stamped day–month–year

4.2.3.1.I

Audit trail is time stamped hour–minute–second in locally defined time

4.2.3.1.J

Audit trail includes full name of the operator, or LIMS-defined operator ID

4.2.3.1.K

Audit trail records all system activity

4.2.3.1.L

Audit trail records all user logons and failed logons

4.2.3.1.M

Audit trail is generated during creation of data

4.2.3.1.N

Audit trail is generated during modification of all data

4.2.3.1.O

Audit trail is generated during ‘deletion’ or ‘deactivation’ of all data

4.2.3.1.P

If the record is changed the system retains/displays old/new value

4.2.3.1.Q

Changes to electronic records shall be made without obscuring previously recorded information (i.e., new versions are created instead of overwriting old versions)

4.2.3.1.R

Changes shall be accepted only when the user has stated a reason for the change

4.2.3.1.S

Reasons for changes shall be picked from a predefined list of valid reasons

4.2.3.1.T

Reasons may additionally be typed-in by the user if the list does not contain correct reasons

4.2.3.1.U

Audit trail associated with the record

4.2.3.1.V

Audit trails are available for review and copying by regulatory authority

4.2.3.1.W

Operational system checks enforce permitted sequencing as appropriate

4.2.3.1.X

Authority checks are designed to ensure that only authorized individuals can perform various tasks in the system.

4.2.3.1.Y

The system is able to discern the validity of the source of input

197

P1: OTE c13

JWBK188-Segalstad

198

September 15, 2008

13:40



r For a production system, this could include questions such as whether the system can store data for process testing done inline during production (Process Analytical Technology), and whether the production parameters for the production line can be set by the system, or entered into the system r For a document management system, this could include questions such as whether they can send documents out to predefined people for review, and keep track of who has reviewed the documents and who has not; if people can be defined as users on one level for some but not other types of documents; and so on The questions you ask will say a lot about your organization, so a signed secrecy agreement may be necessary. This should preferably be sent and returned before the suppliers receive the URS. Large organizations generally have a purchasing department that handles contracts. Contact this department to see if they have any input to the process. They might have a standard letter stating details of agreements, answering procedures, and other technical matters related to purchasing. If you need to do this yourself, include a covering letter with the URS, saying when you expect to receive the answers to the URS, and that those answers should also include the price. You should give suppliers two or three weeks to answer the URS. You should also include the name of a person who they may contact in writing if they have any questions. Make sure that these questions are answered promptly, and in all fairness circulate the answers to all of the suppliers, preferably without revealing who the other suppliers are. If the supplier asks for a few extra days to answer the URS, let them have that time. They may be experiencing a very busy period. But if they are interested in answering the URS and getting you as a customer, they shouldn’t need more than a few extra days. Now the challenge is to understand the answers given by the suppliers. This will be like comparing apples and pears to find out which is the best, and we all know that this is very difficult. So how can you compare the apples and pears? Here is where the ‘explain’ questions come in handy. These will tell you how the supplier intends to solve your challenges as set out in the URS. These answers will show you that they understand what you want to do, and that they have solutions. Some of these answers may be different from how you imagined the solution, but they may be just as good, worse, or even better than whatever you thought. If you have a problem understanding the answers, don’t hesitate to contact the supplier. But do this in writing and get the answer in writing, so that you can prove that the communication has taken place. Table 13.4 shows some experiences with URS and answers. When you have compared the answers, you can hopefully create a priority list of which supplier you think will have the best system for your organization. Before making the final decision and signing the contract, you will have to do a bit more work with the top two suppliers. 13.5.2

Quality Assessment: Supplier Audit

The quality requirements are equally important. When the system is to be used in the pharmaceutical industry, the quality requirements are mandatory, but even in other industries it isn’t a bad idea to include them. Regardless of whether the system is contracted or

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40



199

Table 13.4 Supplier Answers to the URS There is a big difference in how suppliers answer the same URS. Some will gladly say ‘yes’ to all of your yes/no questions regardless of whether or not this is correct, while others will be more truthful and say ‘yes’ to some questions and ‘no’ to others. Why this difference? Some suppliers have the same persons in the sales phase and the implementation phase. These suppliers are a bit more cautious about saying yes to everything, as they know that a lie here will eventually become their own problem. Others have different persons in the sales phase and in the implementation phase. A small lie isn’t going to be their personal problem. The conclusion is that you should not count the numbers of ‘yes’ and ‘no’ answers to find the best system for your organization. I have also experienced a case in which a supplier answered by saying that something could not be done in the system. I had years of hands-on experience as an application manager for that particular system and knew that it could be done. The suppliers, sales persons, and implementers alike know their system, but they don’t always have experience as users of that system.

purchased, the requirements for built-in quality are the same. The difference is that the user may have more control over what happens during development if the system is contracted, as the quality requirements can be stated up front. Suppliers catering to the pharmaceutical industry are very conscious of built-in quality, and they generally do this well. The EU GMP Annex 11 [4] states: ‘Validation should be considered as part of the complete life cycle of a computer system. This cycle includes the stages of planning, specification, programming, testing, commissioning, documentation, operation, monitoring and changing.’ And it continues with: ‘The software is a critical component of a computerized system. The user of such software should take all reasonable steps to ensure that it has been produced in accordance with a system of Quality Assurance.’ The interpretation of this used to mean a supplier audit. However, with a risk-based approach you may decide whether or not this is necessary. Supplier audits and the risk-based approach are described in Chapter 10. The purpose of the supplier audit is to see for yourself that the requirements for built-in quality have been met. For purchased systems, this should be done before the contract is signed. For contracted systems, this is a process that needs to be followed up during the system programming. In that case, it may be wise to perform more than one supplier audit – one before the contract is signed, to see if the supplier knows how to work in a quality environment, and another one after the programming is done, to check that they did a good job on this assignment. You start with the top supplier and audit that organization. If the audit result is good – fine. But if it isn’t, audit the next supplier on your priority list. You’ll then have to make a decision: Do you want the best system according to the URS answers with the worst built-in quality according to the audit, or the best quality with the worst system? Regardless of your choice, you will have to document internally why you made this decision. 13.5.3

Subjective Assessment: In-House Testing

There will often be more than one supplier that can fulfill the user requirements and the quality requirements. When asking any supplier if their system is ‘user-friendly,’ this will

P1: OTE c13

JWBK188-Segalstad

200

September 15, 2008

13:40



Table 13.5 Subjective Assessment is Really Subjective For a LIMS project, I asked the discussion list on the Internet for LIMS if anybody had comments on our list of potential suppliers. I got many answers, but it was far from easy to draw any conclusions. The same supplier’s one support center had comments ranging from ‘Perfect’ to ‘I will never work with them again if I can avoid that.’ A lot of this stems from what is usually called ‘chemistry,’ an expression that I really don’t like, as it has very little to do with that science.

always be answered with a ‘yes.’ An in-house test of the top two or three systems may show that one system is easier to use, more logical, or just ‘feels better.’ In my experience, most users will be happy with the chosen system simply because after they have used it for a while, it will have become the system that they know best. But how do you test user-friendliness? Systems seem to differentiate a bit more in how static data is entered and how easy it is. What you need to see during the in-house testing is both how to enter the static data and how to use the system on a daily basis. When you are inviting the two top suppliers to an in-house testing session, send them the exact same case and ask them to solve it in your presence. Their preparation is to familiarize themselves with your challenge, but they shouldn’t do any of the implementation of the static data before they arrive. One important aspect of the test is to see how this is implemented. You should also sit with them as they work, and ask them to teach you along the way. Also, try to do another case yourself. A user-friendly system should be intuitive and easy to learn. You can also ask the suppliers to submit a list of their most recent buyers. Contact these buyers and ask them about their experience with the system, its user-friendliness, and the supplier’s service, to get a more subjective feeling for the supplier. But remember that the supplier will only give references to their happy customers. You may need to do some research to find those who are not so happy. This can also be a factor in your subjective assessment. When asking around, make sure that you receive comments from customers who use the same support center as you will be using. Table 13.5 shows how this can be answered. Support is heavily dependent on people and their knowledge. Communication skills and getting along are important, as you will usually have to deal with the supplier’s people for a long time. If you can’t communicate well, you may have a problem.

13.5.4

Contract Assessment

The purchasing department should take care of the contract issues between the user organization and the supplier. If you as a user can stay away from that, stay away. The chances are that the people in this department are more skilled in negotiations than the users are. During negotiations the two organizations are on different sides of the table, but during implementation you are on the same side and will need to work together. Many people have a hard time adjusting from one role to the other. You can also negotiate with two suppliers at the same time, to end up with more favorable terms. The users should be instructed not to say anything to the suppliers about which one

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40


The Functional Specification and System Implementation

201

they prefer. That could make a mess of the negotiations. It is possible to be too tough as a negotiator. I experienced this once when the negotiations took a full month. The purchasing organization did get somewhat more favorable payment conditions, but since the project team sat idle during this long period of time, the net cost outweighed that by far. In general, contracts are not a quality/validation issue: Without a contract there is no new system. However, if the supplier is to customize or configure the system, you will need the contract to include quality requirements for this work. Whether that is based on the supplier’s quality system or the purchaser’s, or a combination, will have to be agreed upon. Congratulations: You now know which system you will have and which supplier you will deal with. Now the rest of the job starts.

13.6

The Functional Specification and System Implementation

The next task is system implementation. The amount of work done here varies tremendously from system to system. Some may be ready for operation as soon as they are unpacked and need little implementation. In other cases, months of work may lie ahead before the system can be taken into use. The implementation phase needs to be scaled accordingly. Before the implementation starts, the system needs to be installed. A formal Installation Qualification (IQ), which is explained in Chapter 14, isn’t needed if you start implementation in a ‘sandbox’ instance, which is just used for playing around. IQ needs to be done before you start the formal testing of the system. Instances are explained in Chapter 5. Your URS was most likely a mix between requirements with ‘yes’/‘no’ answers and questions that required more explanation. The supplier sent you their answers, in which they explained how their system could be used to solve your challenges. A complex system may also solve any given problem in a number of different ways, and you will now need to decide which is the best for your organization. This can best be done as a cooperative process between the supplier and the user organization. The supplier has the knowledge of the system, and the user organization of course has the best knowledge of what it does. Quite often, the URS is revised by the supplier and the user working together, to create a more solid URS, in which the requirements include some of the solutions for the chosen system. This is called a Functional Specification (FS) and it will explain in detail how the requirements can be met in the chosen system. The FS is written before the implementation of the system, and will be the answer to the ‘how’ questions in the URS. It is common to have the supplier drive this process, but it must be in very close cooperation with the user organization. As the process of writing the FS may be a long one, it is vital to keep the FS updated during the whole process. Each of the requirements in the URS needs to be addressed in the FS. Creating the FS may mean many meetings between the supplier’s implementing team and the specialists in the user organization. The FS forms the basis for the formal testing of the system; that is, OQ and PQ. Clear descriptions need to be set out for how each of the URS requirements will be met. The

P1: OTE c13

JWBK188-Segalstad

202

September 15, 2008

13:40



requirements in the FS are the ones that will be challenged during validation, and therefore statements must be clear, concise, unambiguous, and testable. Your URS has been made more detailed in the FS. Now you have two documents with requirements. You will need to keep track of the requirements between the URS and the FS. This may be done in the FS, but the tracking doesn’t stop with the specifications. The link should continue through to the IQ/OQ/PQ testing of the system, so that it is possible to see that each requirement has also been included in a test plan, and subsequently reported as ‘Pass’ or ‘Fail.’ One requirement in the URS may be broken down into several requirements in the FS. Each of these may be tested in one or more test plans in IQ/OQ/PQ. By creating a traceability matrix (also called a ‘trace matrix’) in tabular form, it is possible to sort the data according to each of the columns. The links can be kept in the traceability matrix: An example is shown in Table 13.6. Here, only one of the requirements in the URS is used. This has been broken into several requirements in the FS, and each of these has been tested in one or more test plans.

Table 13.6 A Traceability Matrix between URS, FS, and Testing URS ID URS text 4.1

FS ID

4.1.A The number of decimals to be entered/reported for any given component shall be configurable

4.1.B

4.1.C

FS text Number of decimals are entered when defining analytical methods

Number of decimals are entered when defining specifications for a product

Number of decimals are entered when defining calculations in analytical methods

4.1.D Number of decimals are entered when defining reports

IQ test plan

OQ/PQ test plan ID

N/A

1 Defining methods

N/A

2 Using the defined methods

N/A

3 Defining specifications

N/A

2 Using the specifications

N/A

1 Defining methods

N/A

2 Using the defined methods

N/A

4 Using the reports

P1: OTE c13

JWBK188-Segalstad

September 15, 2008

13:40


Tasks

13.7 13.7.1

203

Tasks Create a User Requirements Specification

Your company needs a new machine. You want this machine to do the following: r it can be programmed to have coffee ready for you in the morning when you arrive r it must turn itself off after working hours, or when the time is set manually r it must be able to bake fresh bread in amounts that you decide some days, this being planned for a period ahead r users need differentiated access, and you need to define which groups need to be able to do what Write a URS for this machine. You can make up your own definitions of ‘some,’ ‘period,’ ‘working hours,’ ‘morning,’ and so on, and you may also add other specifications, definitions, or requirements. Remember that the URS will be sent to suppliers, and that it must be phrased in such a way that you get answers to your requirements. Those answers should also be testable. 13.7.2

Create a Functional Specification

You have received answers to your URS from two suppliers for the new machine that you specified above. You have decided to buy from one of the suppliers, and you need to create a FS for the chosen machine. Define the functions that you need for each bullet point. Here are the answers: Supplier 1: r It can be programmed to have coffee ready for you in the morning when you arrive, but it will do this seven days a week, not only on workdays. The option is to start it manually when you need it r It turns itself off after work hours r It bakes fresh bread, but it can only bake loaves that are less than 500 g, not the size you wanted r User access can be defined as you want it. Supplier 2: r It can be programmed to have coffee ready for you in the morning when you arrive, and you can set days per week, or add exceptions as you please. This must be done for the next two months r It turns itself off after work hours r It is able to bake fresh bread in amounts that you determine r You can’t determine user access to the system

Acknowledgment This chapter is reproduced courtesy of Russell Publishing, LLC.

P1: OTE c13

JWBK188-Segalstad

204

September 15, 2008

13:40



References R R 1. GAMP 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based Approach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. 2. Segalstad, S.H. (2000–2001) Development qualification: selecting the right LIMS supplier. American Pharmaceutical Review, 3 (4), 84–87. Also published in European Pharmaceutical Review, 5 (4), 58–61. 3. ISO 90003-2004 (2004) Software Engineering – Guidelines for the Application of ISO 9001:2000 to Computer Software (formerly ISO 9000-3), International Organization for Standardization, Geneva, Switzerland, www.iso.org. 4. European Union (1998) Volume 4 – Good Manufacturing Practices – Medicinal Products for Human and Veterinary Use, pp. 153, incl. Annex 11 covering computerized systems. European Commission, Directorate General III – Industry, Pharmaceuticals and Cosmetics.

P1: OTE c14

JWBK188-Segalstad

September 15, 2008

13:41


14 Installation Qualification

This chapter discusses the following: r Installation qualification of hardware r Installation qualification of software r The IQ plan, testing, and the report

14.1

Introduction

The Installation Qualification (IQ) includes the installation of all hardware and software. In general, the IQ isn’t very labor-intensive. Basically, the hardware needs to be connected and the software needs to be installed. Both need to be checked to see that they work, but it isn’t the intention to check that they function correctly according to the URS. That is checked during OQ and PQ. All hardware and software must be installed according to the supplier’s prescriptions and/or the installation plan. The installation should then be tested by following the installation test plan. The installation and testing must be documented. A platform consists of a set of hardware and software components that are configured to work together. If a platform supports both regulatory systems and nonregulatory systems, the nonregulatory systems must be subject to the same controls as the regulatory systems. This must be taken into consideration when planning and performing IQ.


P1: OTE c14

JWBK188-Segalstad

206

14.2

September 15, 2008

13:41



IQ Organizational Issues

All requests for the installation and operation of new hardware and new applications must be documented in writing. The system owner must sign the request. Beyond this point, the hardware and software need to be under change control and procedures need to be followed. This includes, for example, change control, the system description, and the service level agreement if appropriate, to mention a few. The procedures and the system description are discussed in Chapter 5.

14.3

The IQ Plan

All hardware must be installed and tested according to an installation qualification plan. The validation plan for the system will say what must be included in IQ, and is described in Chapter 11. The IQ plan can be created as one plan covering the whole system, or as several independent IQ plans. It may be feasible to have smaller entities in a plan, rather than the whole system, because the same hardware, operating system, database, and network may be used for several applications. The document formalities are the same as described for the validation master plan in Chapter 11. The installation is usually described reasonably well by the supplier. Sometimes it is only a matter of connecting hardware or running a DVD to install software. There might be choices to be made during the installation. If possible, these choices should be planned ahead in the installation plan; but if this isn’t possible, the choices should at least be documented while they are being made during the installation. The IQ plan usually includes an overview of the items to be installed, and the documentation is generally done by making notes of version numbers and other necessary information that will form the basis for the system description. Mandatory topics are as follows: r The installation of hardware and software according to the supplier’s instructions, the validation plan, internal procedures, or a predefined combination of these r A detailed system description, including the name, manufacturer, version, patches, and other information that will uniquely identify the item. This can be omitted if appropriate logs are created and maintained. In that case, refer to these logs instead r Error handling for errors discovered during testing, provided that this isn’t covered in the Validation Plan. Usually, an error-handling SOP isn’t perfect for testing use r Test plans for the installation, including expected results: – Testing of the installed hardware and software. Test plans included in the installation specifications can be used, but make sure that these are complete and relevant for your needs – Testing the log-on to the application – Testing and restoration of the backup. This could include single files, complete data sets, and/or a database; a comparison of the backup and the original must be performed

P1: OTE c14

JWBK188-Segalstad

September 15, 2008

13:41


Tasks

207

– Testing of the security mechanisms – Relevant production application tests – Parallel testing of systems that share a common platform – Disaster/recovery. This may be tested when appropriate rather than at the time of IQ r Acceptance criteria Relevant topics are as follows: r Testing of the network; for example, stress tests, continuity, loop-delay tests (ping), and testing of the connection to other sites r Testing that peripherals such as printers, scanners, and so on work as intended r Testing of simple system administration tasks such as ‘create user’ and ‘delete user.’ For some systems, this may fit more naturally under OQ testing

14.4

IQ Testing

The testing must of course be done according to the IQ plan and be documented as well as possible using notes, screen dumps, and other appropriate means of documentation. The tester must, of course, sign and date the documents that are created – and these documents must be archived, as they comprise some of the raw data for IQ.

14.5

The IQ Report

The IQ report should be a follow-up to the IQ plan. It is usually a separate document in which the conclusions are listed. Don’t repeat what was planned, what was tested, and what the results were, as the plans and test documentation show these details. Instead, the report should refer to those documents. However, the report does need to state whether errors were found, whether they were resolved, and whether the acceptance criteria were met. Some companies have generic IQ plans where information is filled in, some of which have been drawn up specifically for the hardware/software under consideration. A dated and signed filled-in plan may then constitute the IQ report in some cases, provided, of course, that the company’s quality system allows this approach. A ‘Pass’/‘Fail’ conclusion according to the acceptance criteria set in the plan needs to be created. The IQ report must be signed off as ‘Pass’ and authorized before you can proceed to OQ.

14.6 14.6.1

Tasks Create an IQ Plan

Create an IQ plan for the hardware or software of your preference. Include: r a list of items that need to be documented

P1: OTE c14

JWBK188-Segalstad

208

September 15, 2008

13:41



r a test plan for what to test r acceptance criteria for the testing 14.6.2

Create a System Description

Use the same hardware or software as you did in the previous task. Create a system description for this setup.

P1: OTE c15

JWBK188-Segalstad

September 15, 2008

13:43


15 Operational Qualification

This chapter discusses the following: r r r r r

The principle of Operational Qualification (OQ) What needs to be included in OQ What happens if the supplier has done OQ The OQ plan and report OQ testing

15.1

Introduction

Technically, the purpose of OQ is to test that each function works correctly. The border between OQ and PQ is defined very differently from company to company, and that is perfectly sound. Some companies have different parts of the organization doing OQ and PQ testing; for example, the IT department is responsible for the IQ and OQ, while the end-users are responsible for the PQ. In those cases, it makes sense to divide the testing into distinct OQ testing and PQ testing, even if this results in some overlapping testing. Some organizations will let the end-users be responsible for both the OQ testing and the PQ testing. In those cases it might be possible to make a combined OQ/PQ. More detail on this can be found in Chapters 11 and 16.

15.2

The OQ Framework

The system’s validation plan is the most important part of the framework for OQ. This should be based on the organization’s QMS. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c15

JWBK188-Segalstad

210

September 15, 2008

13:43



An erroneous or inadequate IQ may render the complete OQ nonvalid. People responsible for OQ must therefore ensure for themselves that the IQ is approved and authorized prior to OQ testing. Essentially, the purpose of OQ is to test that the system’s functions work, as described in the User Requirements Specification (URS). The URS was created for selection of the system, and isn’t always easy to test against, as it contains several ‘How would you solve this problem’ questions. The Functional Specification (FS), with its links to the URS, is therefore a better specification to use for the ‘correct answer’ to the testing. OQ must be performed against an FS or similar formal specifications such as the URS. During OQ, all normal use of functions needs to be tested. OQ testing is meant to cover the system’s functionality and does not necessarily relate to the users’ workflow.

15.3

What if the Supplier has Done OQ?

For software that has been bought in ready-to-use form, where no changes are needed (shelf-ware), OQ may be limited or even skipped in the user organization. OQ testing must be performed on any development, customization, or code changes that are not covered by adequate testing and documentation from the supplier. For software that is developed or customized for the company’s specific use, an in-house OQ must be performed. Regardless of whether this is done internally or by the supplier, it is the user organization’s responsibility to make sure that it is done. Possible delegation of the work should be founded on risks and supported by audits, supervision, and formal agreements.

15.4

The OQ Plan

The same considerations are made for the OQ plan as for the IQ plan described in Chapter 14. The major difference between IQ and OQ is in the testing. OQ should test all functionality in use by the organization. Functionality that isn’t accessible to users needn’t be tested, but it does need to be tested if it’s to be made available to users at a later date. Mandatory topics are as follows: r Reference to the IQ report r Assumptions, exceptions, and limitations to OQ r Error handling for errors discovered during the testing, provided that this isn’t covered in the Validation Plan. Usually, an error-handling SOP isn’t perfect for testing use r Test plans for the operation, including expected results based on the URS and FS: – Test for pass (when things go right) – Test for fail (what happens when . . .) – Access to functions and to data – Testing of disaster/recovery if this wasn’t done during IQ – Backup and restoration of backup r Acceptance criteria

P1: OTE c15

JWBK188-Segalstad

September 15, 2008

13:43


The OQ Plan

15.4.1

211

Exclusions from Testing

Every item in the URS and FS needs to be included in OQ and/or PQ, but not everything needs to be tested. Some items can be exempted from testing, but that requires a reason. The excuses are called ‘assumptions,’ ‘exceptions,’ and ‘limitations,’ and are useful to limit the testing. Here are some examples used for an application, but you will have to make the assessment if this is feasible in your case. 15.4.2 15.4.2.1

Assumptions Industry Standards

There is a precedent for not having to validate ‘industry standards.’ It is assumed that the following are regarded as ‘industry standards’ and thus not in need of validation, and that the appropriate IQ/OQ/PQ testing has shown that they are in normal working order: r the operating systems for the server and clients r the network protocol It is further assumed that the appropriate IQ/OQ/PQ testing (refer to the documents) has shown that the following hardware is in normal working order: r the server r the printers r the PC clients r all other hardware, including the network 15.4.2.2

Communication and Equipment

It is assumed that possible errors in the following will be found during testing, and that there is therefore no need to have separate test plans for them: r the communication between the clients and the server r the communication between this system and printers r the network 15.4.2.3

Work Performance

It is further assumed that all work is performed according to the descriptions in the manuals, but limited to the functions, functionality, and equipment described in the procedures. There is no need to test other functions, functionality, or equipment. Those that are to be used later must be validated/qualified separately, as described in the SOP for change control. 15.4.2.4

Operating Environment

It is assumed that the operating environment is regarded as normal as far as temperature, light, pressure, and humidity are concerned. An extreme operating environment isn’t expected in real life, and won’t be forced during testing. Exceptions: r Verification of the source code itself will not be performed. A large number of man–labor years has been built into the system. This can’t easily be checked by a source code review

P1: OTE c15

JWBK188-Segalstad

212

September 15, 2008

13:43



r Testing of functions, functionality, or equipment not described in SOPs will not be done. These will have to be qualified or validated separately before use, according to the SOP for change control r Stress testing will not be performed. The system has low data intensity during data transfer, and the hardware and network used are well dimensioned. The server’s storage capacity is so large that what happens if the disk is filled won’t be tested. The license for the system is limited to a low number of concurrent users: It is unlikely that the system will have problems with handling all of them should they use the system at the same time. Possible slowness of communication between the clients and the server is more likely to be because of high-intensity use by other systems r A number of functions will not be tested during this stage, the reason being that these haven’t yet been implemented. According to the SOPs, they will have to be qualified/validated before they are taken into use Limitations: r The testing will be done as ‘black box testing,’ which means that input data will be entered, and the actual output data will be compared with the expected output data. How the data is treated between input and output is regarded as a black box r Not all function combinations are tested r Normal use of the system according to the procedures will be tested. Untested parts of the system will have to be tested later before taken into real use, according to the procedures r It may not be necessary to include the data entries for the static data. If they aren’t handled correctly by the system, this will show up when the dynamic data is tested. The organization can choose whether or not to test the static data; and if the decision is made not to test, this must be stated – with the reason – in the exception chapters in the Validation Plan or qualification plan. Besides, the static data needs to be qualified according to the SOP

15.5 15.5.1

OQ Testing Challenge the Functionality

Ensuring that things go right during normal use of the system is only one part of testing. The testing process should also challenge the functions and limits set in the system. Some examples are given below. Illegal data entry includes the entering of data outside of set limits in the system. For example: r The LIMS has defined that legal values of pH are between 0 and 14. Try to enter 14.1 or 74 (forget to enter the decimal point for pH = 7.4). Does the system accept this entry or not? If it is set up to accept it, does it flag up that the entry is illegal? Sometimes the users can set the rules, and those rules are not set correctly. But the important thing is that the system reports that the entry isn’t acceptable according to the rules. The LIMS also has a list of acceptable text values (e.g., colors). What happens when values not from the list are entered?

P1: OTE c15

JWBK188-Segalstad

September 15, 2008

13:43


OQ Testing

213

r The document management system has rules that say that the document needs to be approved by X before it is authorized by Y. Try to make Y authorize the document before X has done his job. Does the system accept the entry or does it flag it up as illegal? r The MRP recipe tells you to enter 5.0 kilos of compound Z. Try enter 5.5 kilos and see how the system reacts. Check the range of values that are acceptable for the system. Are 4.8 and 5.02 inside or outside of the acceptable range? When things don’t work as intended, challenge the system to give you the error messages. You will need to be a bit inventive in entering data to ensure that the system actually does what it is supposed to do, even if the entries are illegal or cause errors. 15.5.2

Security and User Access

All users must have their own defined accounts in the system, with their own user IDs. These accounts are usually defined with access to various functions and access to different data. Test a few users: r r r r

Does the user have access to the system using the correct ID and password? Does the user have access to the system using the correct ID and the wrong password? Does the user have access to the system using a wrong ID and an unknown password? When logged in, does the user have access to the allowed functions and not to disabled functions for that user? r When logged in, does the user have access to the right data and not to the disabled data for that user? Security also includes challenging the technical aspects of Part 11 (see Chapter 2). These requirements were, of course, included in the URS and FS for the system: r Is it possible to access the system or its data through the back door via directories, files, or databases? In that case: Can you view, enter data, change data, or delete data in this way? Does the system have a log telling you that this happened, including an audit trail? 15.5.3

System and Device Interfaces

Most systems are interfaced with other systems, instruments, or devices. Each of these parts needs to be validated, as does the interface between them. Whether this calls for separate validation/qualification plans or is included in this system’s documents depends on the nature of the system or device. 15.5.4

Reports

Most systems have some sort of reporting output. This can be a reporting tool, output to the screen, messages sent via e-mail or SMS, or other external output. Check that these work correctly. Reports usually need to be qualified separately to see that they report on what is needed, depending on the input to the report. For example: A report will create a batch record. It is normal for the report setup to ask which batch is to be reported, and then it will retrieve the

P1: OTE c15

JWBK188-Segalstad

214

September 15, 2008

13:43



data for this batch by querying the database. During the report qualification, the reported values are checked against the values in the database. Reports should be embedded in the system so that they can’t be manipulated before printout. If the report is exported to Word or Excel before it is printed, all data security that was included in the system itself is lost, as the report can be manipulated or edited before printing.

15.6

The Documentation of Testing

As with any testing, OQ must be well documented during the testing. Comments, printouts, reports, and database queries are some of various ways of doing this. If you can think of another way of documenting what you are doing, do it – the more, the better. Everything that you do will contribute to making it easier, at a later stage, to see what was done.

15.7

The OQ Report

The OQ report should be a follow-up to the OQ plan. This is a separate document in which the conclusions are listed. Don’t repeat what was planned, what was tested, and what the results were, as the plans and test documentation will show these details. Instead, the report should refer to these documents. The report, however, does need to state whether errors were found, whether they were resolved, and whether the acceptance criteria were met. A conclusion for ‘Pass’/‘Fail’ conclusion according to the acceptance criteria set out in the plan needs to be created. The OQ report must be signed off as ‘Pass’ and authorized before you can proceed to PQ.

15.8 15.8.1

Tasks Create a Test Plan for the Audit Trail of a System

The requirements for an audit trail are stated in 21 CFR Part 11 [1] Section 11.10 as follows: (e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

Create a test plan for how to test these requirements. Do you need to test this for all the parts of the system that have an audit trail?

Reference 1. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov.

P1: OTE c16

JWBK188-Segalstad

September 15, 2008

14:29


16 Process/Performance Qualification

This chapter discusses the following: r r r r r r

How definitions of the Process/Performance Qualification (PQ) phase vary The PQ plan and report How PQ testing is workflow testing Combined OQ/PQ testing Ongoing PQ SOPs

16.1

Introduction

The definition of PQ varies more than anything else between companies. Some define PQ as something to be done and signed off before the system is taken into use. The disadvantage of this approach is that the live system is ‘hanging out there’ without an anchor in validation terminology. Personally, I therefore prefer PQ to include systems testing and signing off before live use of the system, but also to include activities during the live phase as well. The important issue is to define internally what PQ comprises – and stick to that definition when doing the job. PQ testing must be performed against the URS and is meant to test the intended workflow. When a functional specification (described in Chapter 13), has been drawn up, this may be a better specification to test against, as it is a detailed version of the URS that addresses the chosen system in particular. International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c16

JWBK188-Segalstad

216

September 15, 2008

14:29



PQ is the users’ responsibility and must as a minimum be supervised by users. An erroneous or inadequate IQ or OQ may render the complete PQ nonvalid. People responsible for PQ must therefore ensure for themselves that the OQ is approved and authorized prior to PQ testing, provided that the OQ and PQ are not combined. As described in Chapter 11, it may be possible to have a combined OQ and PQ rather than keeping them separate.

16.2

The PQ Plan

The PQ tests the workflow through the system. In many cases, there may be more than one workflow through the system. This usually depends on which parts of the organization use it, which products/projects are going through the system, and other factors. It is important to test all these workflows in PQ. At the same time, it is certain that testing of the existing workflows will lead to a lot of unnecessary repetition of work, as many of them will be very much alike. I’ve found that it’s easier to create test data that resembles the real data, and make it as lean as possible in order not to do unnecessary work.

16.3

PQ Test Plans

There are basically two ways of creating a test plan for PQ. The first is to create it as a complete workflow, where data and expected results are stated for each entry. This is the most common approach. The main disadvantage is that there is a lot of editing when the next workflow, with a slightly different approach, is needed. My favorite, which I have used for 15 years, is ‘Lego block testing.’ I create a lot of small ‘Lego blocks’ that can be used and reused, and combined in several different ways just as the toy blocks can. The Lego testing involves several building blocks: r a small, separate test plan is created for each function – see the example shown in Table 16.1 r data sets are created for input separately – see the example shown in Table 16.2 r the test plans are combined with the data sets to create a workflow I will give an example for a LIMS system, but please note that this is not a complete list of what you need. You will need to create static data for your product ‘Validat,’ which will be used during testing. This has a minimum of analytical methods: r Two manual methods (one with text results, where the entry is selected from a list) and one with numeric results r The product also needs to have one or two instruments connected. Use a balance and a very simple other instrument, or preferably use a result file that the instrument already has and that it can resend to the LIMS. You are not going to spend time in the laboratory, and you are definitely not going to wrestle with instruments during the LIMS validation.

Numeric results

Text results

38

38

(Continued )

Appendix or error form

14:29

Press the ‘More’ button

Select the correct sample Enter the results according to the data sheet

The ‘Enter Sample Results’ screen opens The ‘Sample’ screen is shown Results which have specs, detection limits, or measure limits are flagged with IN or OUT (out is red); results without such limits and specs are marked with N/A Information about component, limits, status/condition, information, system IDs, and attributes is listed Can be selected from list of values or entered manually All samples/tests are available; numeric results can be entered; text results can be chosen from a list, or entered manually

Comments

Page

September 15, 2008

Results – by sample

Responsible

Ref. crosscheck list

Activity plan R1 Results – by sample (manual entry) The data sheet gives information No. on data to be entered Expected result

Test plan:

JWBK188-Segalstad

Test plan R1: results – by sample (manual entry)

c16

Table 16.1 An Example of a Test Plan

P1: OTE Printer: Yet to come

Testing performed date: Checked by date:

Calculated results

Signature: Signature:

Test plan:

Page

38, 58

38 38 1

38

Appendix or error form

14:29

Out of measure limit Out of detection limit Press ‘Commit,’ or the ‘Close’ button (system asks if you want to commit the results, answer ‘Yes’) Press OK and give the correct password

The out-of-spec-results are flagged with OUT in red letters Flagged OUT red letters Flagged OUT in red letters Enter authentication information; the screen shows with your username and an open field for the password The ‘Enter Sample Results’ screen is still shown plus the message: ‘Electronic Signature Event recorded for the user [your Full name], Date and time’ Calculated results (in black on the data sheet) are calculated by the LIMS; the results are the same on the data sheets and in LIMS

Comments

Page

September 15, 2008

Specification checking

Responsible

Ref. crosscheck list

Activity plan R1 Results – by sample (manual entry) The data sheet gives information No. on data to be entered Expected result

Test plan:

JWBK188-Segalstad

Test plan R1: results – by sample (manual entry)

c16

Table 16.1 (Continued )


Input value NE-PQ-2-2#1

PHARMA APIS1 Clinical cGMP IUPAC15 H2 O 18 AS1NE

Input value PQ2-Project 2-1 Neuland

(Continued )

14:29

Sample attribute name User sample ID

Dat./Vis.

Project Production/release See below; add as much methods from each type as used for the worklists AS1NE for log, entering results, approve tasks. QC1NE for CoA check and AS2NE for approve sample

Page

September 15, 2008

Submission attribute name Default value User submission ID Customer project description Customer datagroup Project chemist GMP status IUPAC name Formula Molecular weight Analyst Retain sample stor. time . . . 2

Study: Material/type: Methods: User:

Test plan

JWBK188-Segalstad

Data sheet 2 Note: Enter red values in LIMS only. Do not enter any black values

c16

Table 16.2 An Example of a Data Sheet


KARL FISCHER BLANK

Leave empty

C-PQ-4 Sample preparation Sample preparation

Interface Leave empty

Weight0

(Sample Integration Report)

KARL FISCHER OVEN CONTROL

Done – see attachment Interface

Sample preparation

GC PURITY S

Input value Checked

Component CoA check by AS/QC

See CDS report

IN

IN IN

IN

IN

Measure limit IN

N/A

N/A N/A

N/A

N/A

Detection limit N/A

N/A

IN N/A

N/A

N/A

Specification IN

14:29

Results by sample: COA CHECK

Receive the logged sample and the retain samples and assign the place

Sample receipt

September 15, 2008

System calculated value

Now SP-PQ-2Release

JWBK188-Segalstad

Date sampled Specification

c16

Table 16.2 (Continued )


Assay water Every report sends the path to the CDS Approve all sample tasks Approve Approve

Result entry from CDS:

Approve by task

Approve by sample

Approve by submission

Interface

No sample preparation Interface Interface

Test plan

See TiNetReport See TiNetReport

See TiNetReport

Page

IN

IN IN

IN

IN IN

IN IN

Dat./Vis.

N/A

N/A N/A

N/A

N/A N/A

N/A N/A

N/A

IN

N/A N/A

N/A

N/A N/A

N/A N/A

N/A

14:29

Weight0 Assay water

Sample preparation

Weight0 Assay water

Weight0 Sample preparation

IN

September 15, 2008

(Average value)

KARL FISCHER D

No sample preparation Interface No sample preparation Interface Interface

JWBK188-Segalstad

Sample preparation

c16

KARL FISCHER SST COUL


P1: OTE c16

JWBK188-Segalstad

222

September 15, 2008

14:29



Using existing result files will also ensure that you can precalculate the expected end result r ‘Validat’ also needs product specifications, and the methods and instruments need limits so that these can also be tested When deciding on methods to create, forget your knowledge of chemistry: For a LIMS, it doesn’t matter whether you enter three pH values and let the LIMS calculate the average, or you enter three peaks from an instrument and let the LIMS calculate the average. From a testing point of view, these are the same: Three results entered manually and/or electronically and calculated. 16.3.1

An Example of a ‘Lego’ Test Plan for a LIMS

New samples can be logged into the system in various ways: r r r r

Log 1 test plan: enter a single sample; that is, several methods for one sample Log 2 test plan: enter a group of samples; that is, several samples for one method Log 3 test plan: log the samples by analytical method Log 4 test plan: add a sample to an existing group of samples

Entering results can be done in various ways: r r r r

Results 1 test plan: enter the results manually by sample Results 2 test plan: enter the results manually by analytical method Results 3 test plan: enter the results electronically/automatically from an instrument Results 4 test plan: change a result

Approvals can be done in various ways: r Approve 1 test plan: automatic approval/rejection, depending on the results being inside or outside of specifications and limits r Approve 2 test plan: manual approval/rejection of an analytical result r Approve 3 test plan: manual approval/rejection of a sample r Approve 4 test plan: manual approval/rejection of a batch r Approve 5 test plan: change the approval to rejection and/or the opposite at each of the various levels; for example, result, sample, or batch Of course, there are many other functions that will need to be tested as well. For testing purposes, create an Excel file with data to be entered and expected results based on calculations of these data. Make sure that you include data that will be inside and outside of the various limits and specifications that you have set for ‘Validat’ and its analytical methods. Include information on whether the input data and calculated data are in/out of the spec/limits. Use a separate Excel page for each workflow. Yes, we know – Excel should not be used in the regulated industry, but Excel is a good tool for this purpose. Any discrepancies from the LIMS result will need to be sorted out later. When I used this approach for the first time, we found some discrepancies between Excel and our LIMS in the last digit of the calculated results. Thorough investigation found that the reason was that rounding of numbers was done differently in the two systems.

P1: OTE c16

JWBK188-Segalstad

September 15, 2008

14:29


Documentation during Testing

223

Now have your batch of the product ‘Validat’ go through the system in different workflows: r Workflow 1: combine Log 1, Results 2, and Approve 1. Use Excel data sheet no. 1 r Workflow 2: combine Log 2, Results 1 (for some analytical methods), and Results 3 (for an instrumental method). Then Approve 2 and 3. You find that you need to change a result, so use Result 4. This means that you also need to change an approval, so use Approve 5. Use Excel data sheet no. 2. This contains all the information for the original results and the changed result r Workflow 3 and upward: continue to create real-life workflows until all of the test plans have been used. Some of them will be used more than once PQ testing must cover the following: r Functionality as specified in the URS/FS. Some specific issues are as follows: – For systems with multi-user access, it must not be possible for two users to update the same data at the same time. When one user accesses data, the data should be protected by read-only for other users – If the system has automatic checks to enforce specific sequencing, those checks must be tested (also known as operational system checks) r Access control and security issues, if these haven’t been checked in IQ or OQ r System robustness (stress testing, limits and boundaries, parameters, global settings, etc.) r Interfaces to other systems. Based on the definition and description of the system’s interfaces (if any), the data input and output need to be tested r The audit trail r Record copying for inspection purposes r Electronic signatures if applicable, with additional requirements according to specific regulations If it is more practical or logical, some of the issues listed may be part of OQ rather than PQ.

16.4

Documentation during Testing

Each workflow is in its own binder, with information about who is to do which part of the testing. It is useful to get the testers to do their normal jobs during testing as well. This means that laboratory personnel enter results, and supervisors approve them. Each binder also has information about what to do if the results are not as expected, or when other errors are found. All documentation created during testing should be identified both on the test plan and in the document itself. Each tester should add comments, and should date and sign their work.

P1: OTE c16

JWBK188-Segalstad

224

16.5

September 15, 2008

14:29



The PQ Report

The PQ report should be a follow-up to the PQ plan. It is a separate document in which the conclusions are listed. Don’t repeat what was planned, what was tested, and what the results were, as the plans and test documentation will show these details. Instead, the report should refer to these documents. The report, however, needs to state whether errors were found, whether they were resolved, and whether the acceptance criteria were met. A ‘Pass’/‘Fail’ conclusion according to the acceptance criteria set out in the plan needs to be created. The PQ report must be signed off as ‘Pass’ and authorized before the system can go live. The validation report also needs to be written and authorized before the system goes live. Details of the validation report are given in Chapter 11.

16.6

Ongoing PQ

As mentioned before, my personal preference is to continue PQ from when the system is taken into use until it is retired. Whether or not your organization prefers to call this PQ, the processes are the same: The system must be under strict change control at any given time in order for it to be maintained in a validated state. If not, all your validation efforts are wasted. What is needed are the procedures explained in Chapter 5 and documentation to show that these have been followed. The documentation can take a variety of forms, including logs or reports, amongst others.

16.7 16.7.1

Tasks Create ‘Lego’ Test Plans for Your System

Use the system you are most familiar with and create the headings of the ‘Lego’ test plans for the main workflows through that system. 16.7.2

Combine the Test Plans to Create the Workflows

Make sure that all of the test plans are used one way or the other. 16.7.3

Relevant Input Data

Note which input data is relevant, not only for the case in which everything goes right, but also for those times when there might be some kind of difficulty.

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


17 Laboratory Instrument Systems

This chapter discusses the following: r Information on instruments used in the laboratory and the principles behind their use r How to qualify the instrument functionality r Considerations for validating instruments using computers. Laboratory instruments and laboratory computerized systems are used as examples, but the technical aspects are the same for production equipment

17.1

Introduction

Every laboratory today is filled with a variety of instruments that are used for analyzing the laboratory’s compounds. They vary a great deal in how they work, but their common factor is that they utilize a chemical or physical characteristic of the compound. A detector based on this characteristic will directly or indirectly show the amount or presence of the compound. Laboratories typically spend a lot of time finding good analytical methods to analyze their compounds. It is therefore important that both the instrument itself and the computer system attached or embedded in the instrument work correctly. This chapter is not about the techniques and understanding of how the instruments work. If you want to know more about those, please refer to textbooks on instrumental analysis.

17.2

Instruments

In the ‘old days,’ instruments were free-standing analytical devices with dials or knobs to adjust settings, and displays or needles on a graded background to show the obtained International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries Siri H. Segalstad C 2008 John Wiley & Sons, Ltd

P1: OTE c17

JWBK188-Segalstad

226

September 15, 2008

13:48


Laboratory Instrument Systems

measurement. Some instruments had a printout to show curves – for example, chromatograms or titration curves – or the actual measurement – for example, balances – but they could do hardly any result calculations. Printed chromatograms were cut out and weighed as a measurement of the integration area between the curve and the baseline, and standard curves were drawn up to find the content of the unknown sample. Newer instruments had some capabilities for entering standard data and calculating the unknown sample based on manual input data and measurements. Some of these had an RS232 port that could be used for a printer or for transmitting data to a computer. In our laboratory, we found that some of our balances had RS232 ports that were not connected to anything inside. It all looked impressive, but it wasn’t very useful. Today, there are still simple free-standing instruments in use. One example is balances. However, they can all be connected to a computer system if desired. More complex instruments have computers attached to them. These computers are loaded with software that generally can control the instrument as well as collecting the data, and can make calculations to determine the result for a run. These are called computerized systems. Some of the computerized systems are completely integrated with the instrument, so that is impossible to run the instrument without the computer. These need to be validated as one unit. Others can be separated and the instrument can be qualified separately from the validation of the computer system.

17.3

Analytical Instruments in the Laboratory

While this isn’t going to be a thorough overview of the various analytical instruments in the laboratory, there is a need to understand what at least some of these instruments do in order to understand how to validate the computerized systems attached to them. Instruments are used in the analytical laboratory to detect various compounds in a sample. In some cases, the instrument is used for a qualitative method and will show whether or not the compound is there. Typical examples are instruments that run a spectrum between a low and a high frequency. In most cases, the methods are quantitative and will show how much of the compound is present. This can be based on running a series of standards, which are samples with known amounts of the compound, and making a standard curve. The curve can then be used to calculate the amount of the unknown sample. Another way of determining an unknown quantity is to use internal standards, which are added to both the unknown samples and other standards. Some instruments will first separate the compounds in a mixture by using the compounds’ various characteristics, such as electronegativity, affinity with other compounds, and so on, and then detect each compound separately. A typical example of this is chromatographic methods. Some instruments will destroy the sample by vaporizing it or breaking down the molecules and detecting the remnants. Typical examples are mass spectrometers, Atomic Absorption (AA) instruments and Inductively Coupled Plasma (ICP) spectrographs. In all of these cases, some kind of detector is used to determine the chemical or physical characteristics of the compound. Below are some short explanations. Balances are well-known universal measuring devices. They differ only in the weight range and in accuracy. Typically, a laboratory balance will weigh a few grams with an

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


Analytical Instruments in the Laboratory

227

accuracy of five decimal places (=0.01 mg or 10 µg), while a production balance will measure hundreds of kilos with a 1 g accuracy. A lot of detectors in differing instruments are based on electromagnetic waves at various frequencies. The highest frequencies are the gamma rays, with roughly 1018 –1021 Hz; then X-rays, with 1015 –1019 Hz; Ultraviolet (UV), with 1014 –1016 Hz; Visible light, with 1014 –1015 Hz; Infrared (IR), with 1010 –1014 Hz; and Radio waves, with 104 –108 Hz. The frequencies and wavelengths for these are shown in Figure 17.1. Detectors for electrical characteristics often use electrodes that measure the difference between two solutions, where one is often part of the electrode. The measurements can be: r r r r

current – ampere (A) potential – volt (V) resistance – ohm () conductivity = 1/resistance – −1 = siemens

Figure 17.1

Wavelengths and Frequencies.

P1: OTE c17

JWBK188-Segalstad

228

September 15, 2008

13:48



A pH meter does not really measure acidity, but the potential between the electrode and the solution, from which the pH can be calculated. Its detector measures the concentration of hydrogen ions as a potential, and from this calculates the pH, which is defined as pH = −log [H+ ]. Titrations are volumetric analyses, where the amount/concentration is based on the following types of changes: r r r r

acid – base oxidation – reduction formation or dissolution of solid material color changes

Titration curves are typically S-shaped, the change of direction between up and down or left and right being the point of interest for the result. Titrations can also be based on color changes, where different colors start to appear as excessive amounts of different molecules build up. The eyes of the operator used to be the detector. Today, the instruments have their own detectors. The various components have different spectra in the UV–Visible and Infrared ranges. The IR is mainly used for qualitative analyses. The component is scanned within a frequency range by the IR, and the spectrum is compared to a standard of this component. The UV–Visible often covers both the UV part of the spectrum and the small visible part of the spectrum. It is more commonly used for quantitative methods, as only one frequency is measured. The principle of both Atomic Absorption (AA) and Inductively Coupled Plasma (ICP) spectrometry is to vaporize the sample and detect the element: AA vaporizes the sample in a flame, while ICP uses high-energy vaporization, also called a plasma. AA is generally better for the lighter elements, and the ICP is better for the heavier elements, but they do overlap. Chromatography has been used for a long time. The name is derived from the Latin chromos – meaning ‘color.’ The compounds in the sample would be separated, and the colors would reveal each compound: The results were originally detected by the operator’s eyes only. In principle, the components in the sample are separated by their differing affinities with a retainer called the stationary phase, when they are transported by a mobile phase. The detector is located at the end, and will detect when each component arrives. The oldest form is probably the paper chromatograph, where paper is used as the stationary phase. This is what you can see when wiping blueberry juice or ink with a wet towel: After a while, you get circles with different colors. The towel itself is the stationary phase, and the water that makes it wet is the mobile phase. The various components in the juice or ink will move with different speeds. Thin-layer chromatography uses a thin layer of silica or other porous material as a stationary phase, and is a variation of paper chromatography. A Gas Chromatograph (GC) uses gas as the mobile phase and a Liquid Chromatograph (LC or HPLC) uses liquids as mobile phases. These chromatographs use columns as stationary phases. They come with vast varieties of packing, designed to separate specific molecules traveling inside. Both instruments can use a variety of detectors, based on what

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


Raw Data and Meta Data

229

is most relevant for the components to be detected: r r r r r r r r

UV–Visible infrared refraction index fluorescence electrochemical characteristics conductivity radioactivity (α-, β-, or γ -rays) light-dispersion

The Mass Spectrometer (MS) will essentially break molecules down into smaller parts, which are detected by their mass. Nuclear Magnetic Resonance (NMR) is used in laboratories, and also in medical diagnostics, where it called Magnetic Resonance Imaging (MRI). The term ‘nuclear’ is probably too scary for people and is therefore politically incorrect. The principle has to do with the spin of a nucleus, typically a hydrogen nucleus, in a magnetic field. Hydrogen is in abundance in body fluids, so MRI will show water-filled areas in the body, which can be emphasized or masked using contrast agents. The X-ray spectrometer creates a pattern from one single crystal and is generally used for identifying minerals. X-ray diffraction is most common in the area of geochemistry and is used for quantification of elements. ‘Hyphen’ instruments are two or more types of instruments ‘hyphenated’ so that one separates the sample and feeds it into the next, where it is further separated and detected, or just detected. Some examples are as follows: r GC–MS: the Gas Chromatograph separates the components and feeds that part of the sample into the MS, where they are crunched into smaller pieces and finally detected by the MS r LC–MS: the Liquid Chromatograph feeds the sample into the MS r LC–MS–MS and GC–MS–MS use two mass spectrometers after the chromatography r LC–NMR and LC–NMR–MS techniques also exist

17.4

Raw Data and Meta Data

The raw data from an instrument is more than the measured data from the unknown sample. There is a whole range of data that is created during the analytical process. Each piece of data is vital to the end result, either directly or indirectly. Values for standards, blanks, and control samples are used to create standard curves. Without these, it may not be possible to recreate the result for the unknown sample. Meta data is data that can help prove that the job we did was done correctly. This includes identification and preparation of the standards, blanks, and control samples, to mention a few. Additionally, information on instrument calibration and maintenance, and on system suitability testing, are also meta data that should be recorded.

P1: OTE c17

JWBK188-Segalstad

230

17.5

September 15, 2008

13:48



Devices

Devices are defined broadly in the following context: They encompass anything that is used as a tool, in addition to the standard hardware. This includes, for example, bar-code readers, A/D converters for instruments, and hand-held or other external measuring devices, to mention a few. These devices need to be tested to see if they operate the way they should, and that they communicate with the other software as they are supposed to do. As the devices are very varied, it is difficult to say exactly what needs to be tested for each one. The URS for the device is the best source for creating the test plans needed. Bar-code readers are increasingly being used in laboratories and in production to help identify chemicals and instruments. First, the chemicals and reagents are identified in the IT system and given a bar-coded label. By running the reader over the label, the item is immediately identified by the system. Bar codes come in a number of types, based on different standards. When choosing a bar-code system, it is important to check that the IT system read this standard. A/D converters are used for converting analogue signals (A) into digital signals (D). They are typically used for chromatographs and other analogue instruments, in order to be able to transfer the signal to an IT system. The converters usually have a specification covering the signal-to-noise ratio and the signal range. If the network is unable to transfer the data after each run, some A/D converters can also collect data for several runs. Points to consider for validation are as follows: r checking that the converter’s specifications are correct r investigating what happens when the data is interrupted just as it is being transferred from the A/D converter r filling up the A/D converter with data and seeing whether this can still be downloaded to the IT system

17.6

Biometric Devices

Few companies use biometric devices to check people’s identity, but this practice will become increasingly commonplace. Scandinavian Airlines System (SAS) announced in October 2007 that people can ‘show their finger’ (=enter their fingerprint) when checking in luggage and then show it again when they board the plane. This will neither be saved nor used for identification. It will only be used to compare the two prints with each other, to make sure that the person checking in the luggage is the same as the person boarding the plane. There are basically two types of biometric device: one used to identify a person and another used to verify that identity. The identification process will usually query a database with a vast number of people, to check whether there is a fit with the new entry. Typically, the US Automatic Fingerprint Identification Systems (AFIS) operates in this way. The verification system will work more or less in the way that other systems do with passwords; it will compare the entered data with data already in the limited database, to

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


Validation of Computerized Instrument Systems

231

verify that this user has access to the system. Typically, you will log into the system by giving your user ID and then using the biometric to verify that you are who you claim to be. Biometric measurements include retina/iris scanning, fingerprints, hand measurements, face measurements, and other measurements that may be characteristic for the individual. Testing of retina/iris scanning could include: r Checking what happens to people with colds, allergies, hangover, or other ailments that may result in swollen or red eyes r It would also be interesting to test identical twins if possible Testing of fingerprints could include: r Testing what happens when a person has burnt his or her test finger, or has dirt or paint on the fingers r What happens if the test plate for the finger has not been cleaned properly, so that the previous person’s fingerprint is still there and the next user only pretends that he or she is pressing the finger hard? r It has also been reported that it is easy to create a rubber cast of a fingerprint and use this instead of the real finger. Depending on your risk assessment, this could be tested or not r Airlines have started to use fingerprint checking for access to the flight deck. As a terrorist would not blink at cutting a finger off a person, this device also needs to be able to check whether the finger is actually connected to a body; that is, whether it has a pulse Hand measurements will measure lengths and thicknesses of fingers and hands. What happens if a person is hot or cold, gains or loses weight, or gets arthritis or other ailments that affect these measurements? Facial measurements are subject to the same concerns as hand measurements. Testing of voice recognition could include: r What happens when a person has a cold?

17.7

Electronic Lab Notebooks

While the Electronic Lab Notebook (ELN) isn’t a laboratory instrument, it is increasingly being used in laboratories. In some cases, it will be used as an addition to LIMS. But ELNs are more frequently being used for early stages of the discovery of new molecules for possible pharmaceutical use. For this use, it is vital that the ELN has security built in so that it can be proved that the entry was made on a certain date and has not been changed since, the reason being that patents are at stake. The security will have to be according to 21 CFR Part 11 [1]. It is also very important that users know what to include in the ELN and how to use it. More information can be found at the web page for the ELN (www.censa.org).

17.8

Validation of Computerized Instrument Systems

The definitions of instrument, computerized system, and computer system are shown in Table 17.1.

P1: OTE c17

JWBK188-Segalstad

232

September 15, 2008

13:48



Table 17.1 Computerized Systems Terminology • Instrument = measuring device; • Computer system = data controlling and/or collecting device, usually capable of handling calculations; • Computerized system = integrated instrument and computer system.

Laboratory data systems can be divided into the following categories: r pure computer systems, such as Laboratory Information Management Systems (LIMS) and Manufacturing Systems (MES/MRP) r computerized systems, where an instrument or another technical item uses a computer to control, collect, manipulate, calculate, or store data from the instrument r instruments capable of transmitting data electronically to other computers The question about validation of computerized systems is whether they are separate entities or integrated with each other. If the instrument can be run ‘barefoot’ without a computer system, the instrument and the computer may be separate entities, even if the computer is used for collecting data. If the instrument can’t be run without the computer, they can be regarded as an integrated entity. The GAMP Good Practice Guide for Validation of Laboratory Computerized Systems [2] has an elaborate system for defining categories of computerized systems. While GAMP [3] defines four categories, the guide defines no fewer than seven categories, from A to G. Personally, I find it difficult to make computerized systems fit into these categories, and I would suggest using the normal GAMP approach instead. But the explanations of what to do should be read and followed, as there are many good suggestions for solutions in the guide. Validation of computerized systems follows the same principles as described for all other IT systems validation. It needs to be done according to risk management, as described in Chapter 12, and validated according to the discussions in Chapter 11.

17.9

Pure Computer Systems

The LIMS is thoroughly covered in Chapter 18. The connection between a LIMS and instruments needs to be validated. For instruments that have been connected before the LIMS has been validated, it is natural to include the connection validation as a part of the LIMS validation. Instruments connected later should follow SOPs. Manufacturing systems such as MES and MRP are covered by the exact same considerations as LIMS.

17.10

Computerized Instruments that Can Run ‘Barefoot’

An instrument that can be controlled without using a computer is a ‘barefoot’ instrument. This has validations/qualifications that can be done independently of each other: r the instrument itself r the analytical methods that use this instrument

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


Qualification of Laboratory Instruments

233

r the computerized system used for calculating results, if this exists r the electronic communication between the instrument and other computer systems The advantage is that the qualifications can be done independently and it is possible to concentrate on one qualification at the time. The instrument can be qualified before the computer system. Then we know that the instrument works as it should, and possible problems found during the computer validation can be located in the computer system.

17.11

Integrated Computerized Instruments

An instrument that can’t be run without a computer must be validated as one separate entity: r The instrument + computerized system needs to be validated as one unit r The analytical methods that use this instrument need their own validation r The electronic communication between the instrument and other computer systems needs to be qualified or validated. If, for example, a LIMS is sending information on samples, analytical method, and sequence to the instrument, this must be validated. If the instrument is sending results back to the LIMS, this needs to be validated too If an error is found during the validation of an integrated system, it may be more difficult to work out where the problem is, as we will need to look into both the instrument and the computer functions.

17.12

Qualification of Laboratory Instruments

Here, a HPLC is used as an example of what needs to be considered when qualifying an instrument. The HPLC comprises four different instrument pieces that can be removed and exchanged independently: the sample holder, the injector, the pump for the mobile phase, and the detector, in addition to the column. Each part of the instrument needs to be given some sort of identification. The first consideration is which part of this mix-andmatch instrument is defined as ‘this instrument,’ and which parts are just interchangeable components. The laboratory that I once worked for decided to use the pump as the defined instrument, as that was most likely not going to be changed in daily use. Below are some considerations for instrument qualification, but this description isn’t complete. Please refer to other literature [4, 5] for more information. For qualification and subsequent system suitability testing of chromatographic instruments, calculation of the resolution (R) is probably the most valuable single tool. It is simple to calculate it directly from the chromatogram for any two adjacent peaks: R = (2t)/(w2 + w1 ) = t/w2 . The real value √ of R as a validation tool is seen in the mathematical definition: R = 0.25 (α − 1) ( N) (k1 /[1 + k1 ]). Any change in separation (α), retention (k ), or peak width/efficiency (N) will show up as a change in R. Therefore, R is a ‘window’ into the performance of the pump, injector, column, and plumbing.

P1: OTE c17

JWBK188-Segalstad

234

September 15, 2008

13:48



17.12.1

The Sample Holder

The sample holder is usually rather more than just a storage location for the samples. Its construction varies: stationary or movable, circular or square, and sometimes it also includes a bar-code reader for sample identification. Points to consider for validation are as follows: r r r r

Is the right sample placed correctly for the injection needle? Does the carousel move one sample at a time? Does the carousel move according to a predefined sampling plan, if this can be planned? Does the bar-code reader work and is the correct bar code linked to the results?

17.12.2

The Injector

The injector is a small needle that collects the sample. In order to get correct results, it is vital that it collects the same and the correct volume each time. Points to consider for validation are as follows: r Does the injector collect the exact same amount each time? r Does it do that within the whole range of injection volumes that the laboratory uses? 17.12.3

The Pump

If there is just one mobile phase involved, the pump should give a consistent and correct volume per minute. However, there may be more than one mobile phase involved, each of which requires its own pump. When using more than one mobile phase, it is common to let one gradually replace the other. A typical example is x minutes with mobile phase A, then during the next y minutes mobile phase B takes over. The replacement is often linear, but may also be curved. If the linear replacement time is 10 min, A will be 90% and B will be 10% after one minute, 50% and 50% after 5 min, and so on. Points to consider for validation are as follows: r r r r r

Does the pump flow give the correct and accurate volume? Is the pressure correct? Does it perform in that way over the whole range of volumes used by the laboratory? Does the gradient work correctly? Is the pressure correct?

17.12.4

The Detector

As detectors vary considerably in technique, it will be necessary to understand how each of them works in order to draw up a good list of things to check. Points to consider for validation are as follows: r sensitivity r response r frequency accuracy, if appropriate

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


References

235

r other accuracy as appropriate r wavelength, if appropriate 17.12.5

The Column

Columns age and therefore need to be checked regularly. This is normally done by running a standard through the column. Points to consider for controlling the column are as follows: r Is the number of theoretical plates acceptable? r Is the retention time within the limits? r Is the peak separation good? 17.12.6

The Column Oven

The column is often kept in an oven, to maintain a standard temperature during the analyses. Points to consider for controlling the column are as follows: r thermostat accuracy r temperature range and accuracy

References 1. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, FDA, US Food and Drug Administration, Rockville, MD, www.fda.gov. R Good Practice Guide: Validation of Laboratory Computerized Systems, 1st edn (2005), 2. GAMP International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-39-7, www.ispe.org. R R 5 Good Automated Manufacturing Practice (GAMP ) Guide for a Risk-Based Ap3. GAMP proach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. 4. McDowall, R.D. (2005) Validation of Chromatography Data Systems, Royal Society of Chemistry, Cambridge, UK, ISBN 0-85404-969-X. 5. Huber, L. (1995) Validation of Computerized Analytical Systems, Interpharm Press, Buffalo Grove, Illinois, USA, ISBN 0-935184-75-9.

P1: OTE c17

JWBK188-Segalstad

September 15, 2008

13:48


P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


18 Laboratory Information Management Systems

This chapter discusses the following: r The decision to build or buy a new Laboratory Information Management System (LIMS) r Specifying and choosing a new LIMS r The cost of a LIMS r Differences between commercial systems r LIMS functionality r Static and dynamic data r Considerations for implementing static data in a LIMS r Whether to store dynamic data in a LIMS or in the instrument systems

18.1

Introduction

Basically, a Laboratory Information Management System holds information about samples in a laboratory, but which information is stored varies a lot between different user organizations. Some laboratories only store the end result of the analyses, which is usually manually entered into the system after the work and calculations have been done outside of the system. Others utilize the complete LIMS where all instruments are connected to the LIMS, all data is transferred electronically between the instruments and the LIMS, and the calculations are automatic. Few laboratories make the transition from a paper-based laboratory to a fully automated, electronic laboratory in one step.


P1: OTE c18

JWBK188-Segalstad

238

September 15, 2008

14:0


Laboratory Information Management Systems

Different industries have different needs for functionality. There are several LIMS suppliers on the market and the functionality in their systems varies a bit. Some suppliers have most of their customers in the pharmaceutical industry; others are more geared to contract laboratories, the nuclear industry, environmental laboratories, healthcare laboratories, and so on, and have their specific functionality built into their systems: r An environmental laboratory will need more information in the system on sample location and customers r A contract laboratory will need information on customers, prices for the analyses, and perhaps even differentiated prices based on the customer r A QC laboratory in a production plant will need to include specifications to make sure that sample results are within specifications r A pharmaceutical R&D laboratory may need to include stability testing and pharmacokinetic testing r A healthcare laboratory also needs to include patient data, and to make sure that this is available on a need-to-know basis only This is not a complete list. A LIMS is a database with additional programming to fulfill all these needs for a laboratory. The laboratory must understand its own needs in great detail in order to make a wise LIMS choice. There is a surprisingly wide range of LIMS suppliers on the market. Some have a global presence, while others are based in one country or a small region only. Most provide a flexible system, but some systems are more rigid. Some are specialized for animal testing, forensic or clinical testing with information on the patient. Others are specialized for batch production or continuous production, or perhaps both. Yet others are ideally suited for Research and Development(R&D) activities, which are traditionally hard to automate and manage. Today’s commercial systems are very flexible, and can usually be adapted to meet most of the needs of the laboratory. There are normally no limitations in selecting the preferred operating system, database, and hardware. A mid-1990s survey presented at a LIMS conference concluded that 50% of all LIMS implementation projects failed. No explanation was attempted, but the conclusion most people drew was that the LIMS systems were not good enough. My interpretation is that there were two reasons, both of which seemed to be common in the failed projects: r The first was that the LIMS did not meet expectations, simply because the expectations were never stated. They were just subjectively implied by the users, who thought that the LIMS could solve any problem that they had. There was also the issue of ‘scope creep,’ in which desires for added functionality result in project implementation delays r The second was that the organization was not set up to use this new system. Organization issues are discussed in Chapter 7

18.2

Should You Build or Buy a New LIMS?

The Internet discussion group on LIMS has two topics that frequently feature very heated discussions. One of these is the question of who is best suited to be the LIMS project

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Should You Build or Buy a New LIMS?

239

manager/system manager: an IT person or a laboratory person. The other concerns whether to build or buy a new LIMS. Advocates for building a new LIMS usually state that their laboratory is so unique that they can’t use a commercial LIMS. Very few laboratories are unique – it is their products that are unique. Laboratories generally work in the same way: Laboratories get a sample from somewhere. This may be external or internal; the latter including, for example, raw material, R&D, production, or study. This may be split into several samples to be analyzed. Analyses are done in various laboratories based on sites, laboratory type, and projects/products. The analytical methods may be manual or instrumental. The manual ones may include what the sample looks like or smells like. The instrumental ones may be virtually everything else that uses one or more instruments to obtain results. The results are often compared to specifications to see that the sample conforms. A manager approves or authorizes the results before they are reported, often on a Certificate of Analysis (CoA). A typical information flow through a LIMS is shown in Figure 18.1. The only thing that is unique in the laboratory is that each one has its own types of samples, and its own set of instruments, analytical methods, and specifications. Advocates also say that they can build a LIMS in a few months in an Oracle, Access, or SQL database. This will be completely tailored to their needs and it will be much cheaper than a commercial offering. Let us discuss these statements. It may be possible to build LIMS in a few months. To do so requires that there is a very, very good User Requirements Specification that covers everything that the laboratory ever does – and will do in the future. Few people are able to write such a specification, especially to include how they will work in the future. There is a very high risk that a home-made LIMS will not be flexible enough to allow for future changes. There is a greater chance that programming it will actually take a lot longer than a few months. By then, the users will have found many more things that should be included in the system, and these requirements will be added to the initial ones. We will then get what is generally called ‘scope creep.’ The result will invariably be that the project will take longer than anticipated. A commercial LIMS includes several decenniums or even centennials of manworking days in its planning, programming, and testing. If a programmer is used to prepare the LIMS, he will probably not know enough about laboratories to even ask the right questions when he is in doubt. If a laboratory person is used, he will probably not know enough about programming to do a good job. And unless either of these people is highly skilled in Quality Assurance, the chances are that they will program without producing enough documentation, such as a Requirements Specification, other specifications and plans, test plans, testing, reports, and so on. In any case, the laboratory will definitely have GAMP [1] Category 5 software, which will be frowned upon and scrutinized by the FDA and European authorities – and probably not pass the inspection. Back to square one. Another problem is that when there are one or two people programming a LIMS, the company is overly dependent on these people to make future changes and corrections. What happens when the key people leave the company? And, especially, what happens if they leave and haven’t documented everything thoroughly? It simply doesn’t make sense to create your own LIMS. Even if your IT people would love to create a LIMS for you, spending only a few months on the task, don’t believe them.

P1: OTE c18

JWBK188-Segalstad

240

September 15, 2008

14:0



Information flow in LIMS 1: Order/produce new item/batch

Status: Depends on order/ production

2: Arrival of item

3: Add batch #

6: Sampling

9: Deliver Sample to labs

5: Label printing

4: Batch status: Received

7: Batch status: To be analyzed

8: Result status: To be analyzed

20: Old result status: Replaced 19: Changed result 21: Batch status: To be analyzed

10: First result entry

11: Spec exists

No

Result status: Entered

No

Result status: Out of spec

Yes 12: Automatic Spec check

Yes Last result entry

15: Batch status: Unapproved

Result status: In spec

13: Batch status: Complete

14: Manual Batch approval

15: Batch status: Approved 19: Changing result after approval

17: Manual start of reports

CoA Other reports

Legend: System Manual input functionality

Figure 18.1

Information Flow in a LIMS.

16: CoA

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


The Real Cost of a LIMS

241

History has shown that regardless of the amount of time spent programming an in-house system, it is never as good and as flexible as buying a commercial LIMS. In addition, in-house projects are very likely to suffer delays, and will invariably be more expensive than expected. It is better to spend the money on a commercial system and get what you need, instead of spending money on a programmer from whom, if you are lucky, you will get some of the functionality you need, but not the flexibility, and at a much later date than expected. The chances are that when you finally get the system, your needs will have changed too, and the system will no longer be what you want. Very few companies build in-house systems these days, but some old systems, also called bespoke systems, are still being used. In the pharmaceutical industry, for example, regulators scrutinize these systems and find a great deal wrong with them. The question is whether the company is a pharmaceutical company or a software developer. Some of these companies have received severe warning letters from the FDA (www.fda.gov) as a result of their innovative programming and the lack of maintenance of their systems. Kill the build-it-yourself thought immediately. You are not going to get a 100% system even if you do build it yourself. You may just as well make do with a 90–95% system purchased from a commercial supplier.

18.3

The Real Cost of a LIMS

It is difficult to calculate whether a LIMS is cheaper than a paper-based laboratory. This is a cumbersome assessment, which needs to be done in each case if cost is the main consideration for implementing a LIMS. Day-to-day operation without a LIMS includes the amount of time spent on writing (and often also finding) the laboratory notebooks and logbooks, performing calculations, recording results in results documents, controlling results and other items, and transferring the data from one medium to the other, and finally to the Certificate of Analysis. Day-to-day operation with a LIMS will definitely reduce the labor time for these items. However, in order to get a workable LIMS system, a lot of time has to be spent implementing the static data, also called template data, into the LIMS. A LIMS is bought without any static data, and even the smallest unit of measure has to be entered. It is possible to calculate the time spent on implementation, and the chosen supplier can definitely help by using his experience. The implementation time depends on the number of instruments, products, laboratories, and so on that are to be implemented: Initial costs: C + I, where C, the cost of the purchase of the system, includes the supplier’s implementation time; and I is the internal training time, and the implementation and validation time cost for the system itself and for all items to be implemented in the LIMS. These are the implementation costs until the system is taken into use. Any changes after the implementation phase will be included in the maintenance of the system: Annual cost/benefit: M + L + Tn − To ,

P1: OTE c18

JWBK188-Segalstad

242

September 15, 2008

14:0



where M is the maintenance cost per year for changes, qualification/validation, error handling, backups, a helpdesk, and so on; and L is the license for the LIMS system. This is typically calculated as a percentage of the initial cost per year, and it depends on the number of concurrent users. Tn is the cost of the time spent using the new LIMS; and To is the cost of the time spent using the old (paper-based) system. Tn and To can be calculated from an average batch type (or per time if a continuous process is used; e.g., an oil refinery), and multiplied by the number of batches (or time units) per year. It would be simple if this was the whole story, but it isn’t. A LIMS will generally add quality to the products, by flagging problems, and forcing people to do things correctly, and in the correct sequence. It is possible to measure the cost of discarded products, recalled products, and so on – if the numbers exist. It is more difficult to assess the value of possible loss of reputation due to bad quality. The purchase price and the license are the only items with a real price tag, and that’s often what the boss wants to know. You usually pay for each hour the supplier sits in a meeting with you after the sales phase, but you may also have many of your own people in that meeting, usually at a much higher cost. Another problem is that implementation of a LIMS usually includes changes in work procedures, responsibilities, and a lot of other things. This may have an influence on both the old and the new ways of working, as well as the quality of the result. In heavily regulated industries such as the pharmaceutical industry, the quality is more important than the actual monetary Return on Investment (ROI). In securing funding for a LIMS, you can try a couple of tactics: r Can our company live without a LIMS? We certainly could not live without accounting software r Find a larger project (such as Enterprise Resource Planning – ERP or Material Requirements Planning – MRP) and get a LIMS attached to it. The LIMS budget will be tiny compared to the larger project. In other words, make the LIMS a part of a larger project. These systems communicate well, and the LIMS adds information that an EPR/MRP system is unable to handle in a satisfactory way

18.4

Differences between Commercial LIMS Systems

All LIMS systems can be configured to fit most of the laboratory’s needs. The configuration won’t be affected by upgrades, as it is usually kept with the rest of the data, inside the database. Some functionality may have to be customized through programming and this may affect the database structure or files. If an upgrade will cause a customized file to revert back to a standard file, or if a new table or a field within the table will be lost, this will be a major problem for the customization process. Good change control will be necessary. The following sections discuss some of the main differences between the LIMS systems currently on the market. Before choosing a system, it is vital that the users understand how it works, and that they get answers to some of the general questions listed below. There are no correct answers, as each organization must be aware of its own requirements and find what is useful for its purposes.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Differences between Commercial LIMS Systems

243

The general issues are as follows: r How does the system store configuration elements? In the database tables, or in separate files, which need to be assessed during upgrades? r How ‘IT-literate’ do the administrators and key users need to be? My personal opinion is that ideal administrator has a laboratory background and understands what the LIMS tool is being used for. This is more important than an in-depth understanding of the technology behind the database and the programs behind it. The IT person understands IT, but not necessarily the laboratory’s needs r What effect does configuration/customization have on support and upgrades? Can this easily be handled by the administrators, or are they dependent on support from the supplier? r How dependent are the end-users on the administrators for small changes to the system? It is useful to be independent and be able to handle configuration without help Calculations: r How are calculations set up in the system? Some have simple ways of doing this, while others require the use of their proprietary programming language in order to do it r How does the system handle calculations between samples/batches? In some systems this is easy to set up, in others more complicated. Some can’t do it at all, and values located somewhere else in the system must be entered manually each time r How are data from standards, molecular weights, and constants retrieved and included in the calculations? Some systems will let you select a reference to the table where the information is, while others will require you to enter the data for each calculation. Updating the latter naturally involves rather more work than updating one table Modules and functionality differ and companies have differing needs: r Functionality for planning stability testing is included in some systems but not in others r Batch trees can be easily created in some systems but not in others r In some – but not all – LIMS, patient data and/or contact data for suppliers and customers can be added r Dissolution testing is easy to set up in some systems, but difficult in others Reports are created differently in different systems. Some use a standard tool in a fourthgeneration language, where the user hardly needs to understand the database; others use proprietary reporting tools and/or tools where a thorough understanding of tables, fields, and relations in the database is necessary. A standard reporting tool is usually the best, and it may be possible to use it with any LIMS: r Can reports be started and printed out from within the LIMS after specifying what data is to be reported? This will secure the access to the data r Or will the data be imported into Word, Excel, or any other program where it can be manipulated, so that all your built-in security in the system will be compromised?

P1: OTE c18

JWBK188-Segalstad

244

18.5

September 15, 2008

14:0



Static and Dynamic Data

As no commercial LIMS can ever include all varieties of laboratories, the LIMS is sold as an empty database. The database tables are there, but they are not populated with any data – ˚ ˚ not even universal units of measure such as the tiny Angstr¨ om (Angstr¨ om is reputed to be −10 the world’s smallest Swede: 10 m). The strength of a commercial LIMS in the 21st century is that the systems have matured during their nearly 30 years of existence. They are now very flexible and can be configured to match virtually every need without changing the programming or the database. The system configuration makes it possible to tailor it to the laboratory where it is to be used. At the same time, it is easy to change the configuration when there are changes in the laboratory. LIMS basically has two types of data. The first is the static data, which is also called template data. The other is the dynamic data.

18.6

Static Data

The static data is where the laboratory tells the LIMS how the laboratory works. There will be static data for each analytical method, specification, instrument, sample type, and so on. Key people, usually together with the supplier, will configure or implement the static data in the LIMS before it is taken into use. Needless to say, the system must also be validated before it is used. The implementation time differs between the systems. Some will, for example, need a lot of work to connect instruments so that they can communicate with the LIMS, while others are closer to ‘plug-and-play.’ Some are more difficult when entering calculations that include several samples or batches and/or results from, for example, water analyses to adjust for the dry content of the sample. In some, there are tables where you can enter factors used in several calculations – for example, molecular or atomic weights – while in others these factors have to be entered in each calculation, which makes a lot more work when a factor needs to be updated in several places. Today, most LIMS systems use standard Windows or Web interfaces with which people are familiar. Apart from some functionality modules that may or may not be in a LIMS, there are few differences between the systems for the daily users of LIMS. A new user will have to learn how to use the system anyway. Most users are happy with their system, provided that it has been implemented in a good way. One is generally happy with what one knows.

18.7

Dynamic Data

If static data is where the laboratory tells the LIMS how the laboratory works, dynamic data is where the LIMS tells the laboratory what to do. The static data should be set up so that when a sample of a defined type arrives in the laboratory, the LIMS will know exactly what the staff expect to do with it. It will then copy the information to dynamic data and prepare the system so that information for this specific sample can be entered and stored in the database.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Types of Production

245

A new sample can be logged by telling the system that this sample is product A. The system will know exactly what data is expected for the product. It will create empty dynamic data for this specific batch, based on the sample type’s static data/templates. The system knows which analytical methods are used, what the specifications are for the product for several markets, which instruments are used, and how to collect data directly from the instrument. Other information – such as, for example, the batch number – will be prompted for and has to be provided. In addition to the specifications, the LIMS will check the entered results against a wide range of controls and warning limits. The system will know the status of the instruments, including the calibration and maintenance cycles, as well as the instrument limits, such as detection limits. The LIMS will also know how the reagents, standards, and control samples were prepared, and which of these were used for this specific sample. Finally, the end result can be calculated based on series of internal and external standards, calculation factors, and measured values. The result can be checked against the desired specifications. The LIMS also keep track of status changes from ‘planned’ and ‘logged,’ through ‘working on it’ and ‘finished,’ to ‘approved’ on different levels. The different data views are important features. These will show everything from a broad overview of information, which includes flagging up problems such as ‘out-of-spec’ results, uncalibrated instruments, and so on, to detailed information when drilling down to see finer detail.

18.8

LIMS Functionality

All LIMS systems have the same basic functionality, which makes it possible to enter static data and use this for logging a new sample, entering results manually or via instruments, comparing the results with specifications, approving the results, and reporting them in various ways. The main difference lies in the special functionality that is included, which you may or may not need. There are minor differences in how the data is entered, what data is available on the same screen, and so on.

18.9

Types of Production

Most industries manufacture their goods in batches. The batch is identified with a batch number, and the production parameters are easy to connect to the analytical data. There are also industries that manufacture goods in a continuous flow. Examples are oil refineries and distillers, where there is a continuous input flow of the raw material and a continuous output flow of the product or products. In most batch-related industry there is also some continuous production and/or time-point sampling. Distilled or treated water used in production is one such example. Cleaning-InPlace (CIP) samples, as well as microbiological production line testing, are time-point samples. The LIMS needs to be able to take care of all of these production types if the organization uses them. Not all LIMS systems are equally good in this respect. Terminology both in LIMS systems and in laboratories varies. In this chapter, a ‘sample’ is whatever is analyzed. Samples may be standards, blanks, or control samples. There may be several samples in a batch, each sent to different laboratories for testing. Additionally,

P1: OTE c18

JWBK188-Segalstad

246

September 15, 2008

14:0



there may be subdivisions of each sample. These are often called ‘parallels’ and/or ‘replicates.’ Some laboratories define these differently, and use both parallels (subsamples) and replicates (more than one test of the same sample or subsample). In general, they are all included one way or the other in calculating the final result. Continuous flow production is usually defined as a time point rather than as a defined batch. If the sample results in the laboratory at two time points are satisfactory, one can assume that the whole production run between these time points is satisfactory. If the last sample isn’t satisfactory, somewhere between the two time points things have gone wrong, and the production between these points may have to be checked and/or discarded. Not only does oil production have continuous flow production, but the samples are also defined differently: The product is ‘graded’ after production, when the company knows what it has produced. The reason for this is that the company’s products depend on the content of various hydrocarbons, which again depends on the distillation process. Genetics laboratories and screening laboratories for new drugs collect an enormous amount of data in a very short time. They need LIMS systems that can handle large amounts of data, and there are systems that are especially designed for high-throughput testing.

18.10

Analytical Methods

To a LIMS, there is no technical difference between analytical methods. They all include measured or observed data. Usually, some calculations are involved to obtain the final result based on the measurements. It makes little difference to the LIMS whether there are three weightings and the average of these is calculated, or whether there are three pH measurements and the average is calculated. There are still three results and a calculation. From a chemical point of view, there are of course differences between these methods. Analytical methods differ and may be handled very differently in a LIMS. Below are some examples to show what can, and perhaps even should, be included when implementing them in a LIMS. 18.10.1

Visual Inspection Methods

Several methods involve what is known as visual inspection. They are in abundance in the pharmacopoeias, but visual inspection is also used a lot in internal methods to get a first impression of the sample. If the product is supposed to be a yellow, fine-grained powder, a visual inspection will quickly show that white, course-grained crystals may not be exactly what we should have. These visual inspection methods may also include smell, even if that can hardly be called ‘visual’ inspection. Often, the specifications for a visual inspection method may be something like the following: ‘White to off-white, fine powder, maybe with some coarser grains, no distinct smell. The powder is easily soluble in water but not in ethanol.’ Let’s experiment with how to implement this in a LIMS: 1. Construct a pass/fail method, where the user must say whether a statement is correct. The answer for one batch is ‘Pass’ – there’s no problem with this answer. The answer for another batch is ‘Fail.’ This makes us wonder what failed: Was it the color, the grain type, the solution in water, the solution in ethanol, or the smell that was a problem? This

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Analytical Methods

247

doesn’t actually give us any useful information. When looking back over the history for these sample types, we can also see that a previous batch failed. But was that failure due to the same problem or to a totally different problem? 2. Construct a pass/fail method with a question for each of the statements. The answer for one batch is that all statements ‘Pass’ – still a good answer. The answer for another has ‘Fail’ on the color and the grains. This still doesn’t give us a very accurate answer as to what the sample really looked like. But we are able to see if the previous batch failed in the same parameters. 3. Construct a method where the answers are not given as ‘Pass’ or ‘Fail,’ but as lists of detailed answers to the questions. Make a list with the prompt ‘Color,’ which lists the correct values ‘White,’ ‘Off-white,’ ‘Light yellow,’ and other variations. To make sure that the question can be answered even if the color happens to be black, include ‘Other – see explanation’ in the list as well. Not only will the answers be standardized, but there will also be an opportunity to explain whatever is seen that isn’t on the list. The prompt ‘Grain‘ can have a list of ‘Fine powder,’ ‘Fine grain,’ ‘Fine grain with coarser crystals,’ ‘Coarse grain,’ ‘Large crystals,’ and so on. ‘Solution’ can have two or three items in the list of answers, such as ‘Soluble in water,’ ‘Partly soluble in water,’ and ‘Not soluble in water.’ By using methods 1 and 2, we can make an assessment of the results instead of observing the results. The assessment actually includes the specification. Our answer is therefore not the observation, but the spec-check of the result. A trend report of ‘Pass – Pass – Fail – Pass’ gives close to no information. By using method 3, we can report what we actually see. The results are detailed, and we can easily trend them to ‘Fine grain – Fine grain to powder – Powder – Fine grain with coarser crystals – Coarse grain,’ and then see the result of each production or batch. Some pharmacopoeia methods include making color solutions and comparing the sample with the color. In the EU Pharmacopoeia these solution series are called Y1 – Y2 – Y3 and so on for the yellow series, and the specification is ‘Not darker than solution Y2 and not lighter than solution Y4.’ Again, when implementing this in a LIMS, one should use implementation suggestion 3 above. Have the method prompt ‘Color solution’ and include a list of possible answers Y1, Y2, Y3, and so on, up to Y7. The specification (see below) should say that for this sample type, Y2 or Y3 or Y4 is within specification. In this way, the method can be used for yellow solution methods for other types of sample. The assessment is in the specifications and not in the method. To make it even more generic, one could include the R1, R2, R3 to R7 (reds) and B1, B2, B3 to B9 (browns) and so on to the list of colors and call the method ‘Color comparisons.’ However, the list here would be very long, so it might be easier to produce one method for each color. Another example with approximately the same type of analytical method (seen from the LIMS viewpoint) is the heavy metals, where one makes one standard solution, prepares the sample, and then compares them. Generally, the sample has a specification stating that it shall not be darker than the prepared standard solution. Instead of entering this in the LIMS as a pass/fail method, we should enter the actual observations as described above. This also includes the solution concentration and perhaps even its preparation, to make sure that we are documenting exactly what we have done. The sample result should be entered as one of a list of choices with the standard solutions that we usually prepare. That makes the method universal for all our heavy metals methods, while at the same time it

P1: OTE c18

JWBK188-Segalstad

248

September 15, 2008

14:0



gives an exact answer to what we have tested. The specifications are listed for each of the sample types that we are testing. 18.10.2

pH Methods

For a pH method in its simplest form, we calibrate the instrument with standard solutions in the laboratory and enter the measured result manually into the LIMS. This means, however, that we will still need to have additional information outside of the LIMS to be able to document how we reached the result. We need to have full traceability in everything we do, and the ideal place to store this is in the LIMS. Sure enough, it does add a lot of work to implement this in the LIMS, but we can get rid of paper records such as calibration logs, standards and reagents logs, and our paper laboratory notebook. The complete method is more than just the measurement of the unknown sample: r We use a pH meter. This should be identified with the instrument type (pH meter) and the instrument name (laboratory instrument # and/or instrument model) r The pH meter is normally located in laboratory yyy, but during use it had to be moved to laboratory zzz for some reason. Maybe the latter is important information in your organization, or maybe not r We use an electrode for our measurement. This should be identified with type and a name to know exactly which electrode we used. This was last maintained on date xxx r We use standard solutions to calibrate the instrument. The calibration records should be available so that we can show that the instrument was calibrated as it should be. We also need to know which standards we used – not only that it was pH 4 and pH 7, but also the identification (batch number or other). Often, standards are purchased as concentrates, with a manufacturer’s batch number. They are then diluted, and should be given a local identification or batch number after dilution. Information on how and when the dilution was done should be included in the LIMS r Finally, we measure our one sample and send the information electronically from the pH meter to the LIMS for direct storage All this information is necessary to show what we actually did. The instrument and electrode information, calibration, and maintenance are in the instrument part of the LIMS. Instrument connection is a separate part of the LIMS. The standard solution and standard preparation is in the reagent part of the LIMS. These are described in more detail in other chapters. 18.10.3

Weight

Weight measurement itself is usually not a complete analytical method, but it is used in almost every other analytical method in order to calculate concentrations or amounts. It should therefore be possible in the chosen LIMS to be able to use two or more different instruments for each analytical method. The balance is one of them, and whatever instrument is used for the analysis is the other. The accuracy of balances varies a lot between production balances and laboratory balances. Production balances typically weigh in kilos with 1 g accuracy, while in the laboratories four- or five-digit accuracy in grams is needed.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Calculations in Analytical Methods

249

Table 18.1 Number of Digits One example of an inflexible old LIMS from our own experience was that we had to define the number of digits globally for all numeric values in the system. We decided on five, as this was what analytical balances would give. We used the LIMS, among other things, for animal testing, where the method was the determination of toxicity. The unit of the result was ‘dead mice.’ It sure looked accurate with five digits, but it didn’t make sense. A mouse is either dead or not, and only integer numbers will do. (Though somebody argued that just maybe it could make sense to enter 1.5 if they found one dead and one half-dead mouse.)

The information needed in the LIMS for the balance and the weight measurements is the same as that listed for the pH meter: The name and perhaps the location of the instrument, and the calibration and maintenance data. 18.10.4

Text Results and Numeric Result

Some methods can have either a text result or a numeric result. The reason for this is explained under the analytical method limits, but we must also make sure that we can enter either of these options. The system must not require us to enter both the text values and the numeric values in order to accept the results as fully entered. Instruments have an output measurement with a certain number of digits. These are generally stated according to the accuracy of the measurement. When calculations are involved, the output may have a much higher number of digits. This number bears no resemblance to the accuracy of the result, only to the accuracy of the calculation. From a mathematical viewpoint, 0.5 is the same value as 0.50000. The difference is in the accuracy. A value of 0.5 is between 0.45 and 0.54, while the value of 0.50000 is between 0.49995 and 0.50004. When implementing this in a LIMS, we need to set the number of digits for each measurement and define the calculation according to the accuracy of the method. The number of digits must be scientifically sound and should be based on the method validation. But it is also important that all calculations use all digits, and that only the final result is rounded to the correct number of digits. If we round after each calculation step and use the rounded value in the next step, the final result is likely to be incorrect. Table 18.1 tells about digits.

18.11

Calculations in Analytical Methods

The end-result for analytical methods is often calculated from constants and measured or calculated values. Constants come from: r conversions from one unit to another – for example, grams to milligrams r the molecular or atomic weight for one or more molecules or atoms involved r other factors Measured and calculated values may come from different sources: r measurements in the current analytical method r measurements or final results from another method – for example, typically water content to determine the amount of dry sample

P1: OTE c18

JWBK188-Segalstad

250

September 15, 2008

14:0



r measurements from a different sample – for example, typically a concentration of a standard solution created earlier The LIMS must be able to include all these in calculations. By including constants, standards, and reagents preparations in the LIMS, calculations can be made automatically when these standards and reagents are identified. When setting up a method that uses, for example, standard solutions, reagents, standards, and so on, include a step where you have to identify the reagent’s batch number/ID. This can be done in an elegant and easy way if you utilize bar-coded labels that help identify the reagent. If information such as the concentration of this reagent is in the LIMS (see below), the LIMS can retrieve the correct values for calculation without any manual input.

18.12

Specifications and Limits

We normally think of specifications as something that our samples/batches need to comply with, but there are several types of specifications and limits. In many LIMS systems, limits can be set either in the form of ‘hard limits’ or ‘soft limits.’ Hard limits make it impossible to enter any value outside of the limit, while this is possible with soft limits, but the system will flag up that the values are outside of the limit. Each company implementing a LIMS must decide whether soft or hard limits should be set in each case, and where the limit is. There are no specific rules, so use your judgment, bearing in mind how your company works. Limits and specifications may be numeric, text, Boolean, and so on. They may be openended (either a low or a high limit), closed (both a low and a high limit), discrete (a list of acceptable color values Y1, Y2, and Y3), or a combination of more of these. The analytical method should include lists of acceptable values for input. If the users can enter discrete values freely, typographical errors and imagination will quite probably result in good input values being entered that don’t comply with the spec. 18.12.1

Unit Limits

All units must be written the in same way in order for it to be possible to compare them easily. The LIMS doesn’t understand that % w/w is the same as w/w% or any of a dozen varieties of writing this, even if we as people do understand that. Some units are used in limited value ranges. For example, it does not make sense to enter kilogram weights in milligram units, or the opposite. r pH is generally defined as having values between pH 1 and 14, but there also somewhat larger and smaller values should be possible to enter. The limits for the values should be set so that the LIMS flags up values that are outside of these limits. Typographical errors can easily be made, so that a pH of 7.5 is entered as 75. Such errors should be either forbidden by using hard limits or flagged up by using soft limits in the LIMS. A hard limit of 0–15 could be set, or a soft limit of 1–14 could be set r Milligrams may be entered as 1046 mg, but for practical purposes grams may be used instead. Soft limits could be set so that it is possible to enter milligrams that exceed one gram, but perhaps not 10 g and definitely not 1 kg. Equivalently, soft limits may be set on lower values, so that milligrams can be entered as 0.01 but not any lower

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Specifications and Limits

251

r % Concentration, whether this is measured in weight, volume, or other units, rarely exceeds 100%. Due to uncertainty in the analytical method, the value may be slightly higher. A hard limit of 100.00% could be a problem, so perhaps a soft limit of 100–105 might be better r Most other units have similar limitations

18.12.2

Analytical Method Limits

Most analytical methods that have undergone method validation will have set Limits Of Detection (LOD) and Limits Of Quantification (LOQ). Values below the LOD can’t be detected using this method. Values below the LOQ can be detected, but can’t be quantified using this method. When analyzing impurities, analytical results may be either the text value NMT LOD or NMT LOQ, or the actual value above LOQ. If the values come from an instrument, these may have been derived from mathematical standard curves and may be given an actual number for values between LOD and LOQ, while from an analytical point of view this value doesn’t exist as an accurate value. The LIMS must then be able to make an assessment of the received/calculated value. This should either be translated into the relevant LOD or LOQ, maybe including the values for those limits, or, if the value is above the LOQ, the actual numeric value can be used.

18.12.3

Instrument Limits

Instruments can also have the same limits as methods, but the limit may vary depending on what is analyzed by the instrument in question. Examples are Atomic Absorption (AA) and Inductively Coupled Plasma (ICP) instruments. Both analyze elements, but the sensitivity varies by several factors of 10 between the elements in the two instrument types. The ICP has better sensitivity for the heavier elements, and the AA has better sensitivity for the lighter elements. It should be possible in the LIMS to set limits for each instrument and component, so that unrealistic calculated values are not reported. Appropriate LOD and LOQ text values should be reported instead.

18.12.4

Sample Specifications

Sample specifications are set so that produced or purchased batches should be within these limits. How the limits are set varies a great deal, but reality is taken into consideration in the production process, the LOD and LOQ for the various compounds, the toxicity of potential impurities, and many other factors. These factors will not be discussed here. Instead, the focus will be on the specifications that have been set for the sample type and how to enter these in the LIMS.

18.12.5

Single Specifications

By single specifications, we mean the specification for each value that is to be spec-checked. Some of these may be the actual measurement, while others may be a calculated result for replicates, parallels, or the sample.

P1: OTE c18

JWBK188-Segalstad

252

September 15, 2008

14:0



Basically, single specifications are one of three types – open-ended, closed, or discrete: r an open-ended specification means that there is a high or a low limit, but not both r closed means that there are both high and low limits r discrete means that the there may be one or more results that are defined as the specification 18.12.5.1

Numeric Specifications

Numeric specifications are usually an open-ended or closed range of numbers, but they may be discrete. 18.12.5.2

Numeric Values in Ranges

A sample specification may require the content of the main component as NLT 95% w/w (weight/weight %), where NLT means ‘not less than.’ The LIMS does not normally understand this, so we need to enter a value; for example, >95 or ≥95. If the spec is >95, we can normally assume that 94.5 or higher is an acceptable value. Mathematically, 94.5 can be rounded to 95, provided that no decimal place is required. A value of 94.4 will be rounded down to 94. Arguably, there are several ways to round numbers, but the same discussion should be made regardless of how the organization decides that rounding should be done. The next question is how the LIMS handles the numeric specifications. Are these absolute, so that a value of 94.99 is outside spec, as the specified lowest value is 95? Or does the LIMS take into consideration that a value is rounded before it is spec-checked? Ideally the latter should be the case, and it should also be based on the number of digits you decide on for each single specification, in addition to being based on the accuracy of the method. Make sure that you understand how the LIMS handles these numeric specifications, and set them accordingly. If the LIMS does not round the values, the spec must use the absolute value of 94.5. There might be a problem in explaining why the limit in the LIMS is set differently than the limit on paper. The solution is to write this explanation in, for example, an SOP. Another solution is not to have double specification sets; that is, to create them in the LIMS only and produce the formal set of specifications as an approved printout from the LIMS. 18.12.5.3

Numeric Discrete Values

Discrete numeric specifications are not common, but they do exist. The specification must be a list of acceptable values, sometimes only one, which should be a subset of the list of acceptable input values in the analytical method. 18.12.5.4

Text Specifications

Text specifications are usually discrete, and the specification is handled just like the discrete numeric specifications above. An example is the specification for yellow colors Y1 to Y9, where the specification is a list of the values Y2, Y3, and Y4. Technically, it is possible to believe that there may also be a range of text specifications, such as letters higher than H in the alphabet, or letters lower than S. However, I can’t think

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Standards, Solutions, and Chemicals Used in the Laboratory

253

of any analytical method that would feature such an option, apart from counting the letters in an ‘alphabet soup.’ 18.12.5.5

Mixed Specifications

In the case of impurities, the specifications are often listed as NMT 0.5 mg/g of a certain component. This can easily be interpreted just like any open-ended numeric specification, but it really is not. We need to take into account that we might also get text results for the LOD and LOQ. Our specification must therefore include both the text LOD and LOQ, and the numeric values below the limit.

18.12.6

Specifications for a Sample Type

A set of specifications comprises the total requirements that need to be met for a given sample type. However, a sample type may have several sets of specifications, depending on the customers, the regulatory requirements, and the intended use. Many companies have internal specifications that comprise a combination of the most stringent values in their multiple customer/regulatory specifications. If the product passes all specs, it can be sold to anyone. If not, it may be worthwhile to check if it passes one customer’s specs, and sell it to that customer. Most LIMS systems handle multiple spec sets for a product, but some are more awkward to use than others. In some systems you have to predefine the default spec, and it isn’t easy to check the results against another spec. In some, you can more easily choose which spec you want to use for this batch, and retry with another set of specifications. A good reason for having this as an easy functionality is that if the batch does not fulfill the high-purity spec, you can check whether the batch complies with a lower-purity spec and sell the product as this purity instead. A company manufacturing a reagent may make several different grades of the same product and, accordingly, have several sets of specifications. The purity for a reagent to be used as a mobile phase for HPLC must be very high, so that the analyses don’t detect the impurities in the mobile phase instead of the impurities in the analyzed product. The same reagent sold as Technical Grade does not have to be equally pure. The US and EU pharmaceutical regulatory bodies use their local pharmacopoeias for reference. When selling to the US market, the product must be analyzed according to the USP, and compared with these specifications. The analyses and specifications in the EP must be adhered to for the European market.

18.13

Standards, Solutions, and Chemicals Used in the Laboratory

I mentioned earlier that it is useful to include all reagents, standards, and other chemicals in the LIMS. The reason for this is that all preparations, all concentrations, and all other information about the reagents will be in the same place as the rest of the laboratory information, namely in the LIMS. This means that the LIMS can use the information for calculations.

P1: OTE c18

JWBK188-Segalstad

254

September 15, 2008

14:0



18.13.1

Reagent Preparation and Use

From this point onward, reagents, standards, blanks, control samples, and so on are all called ‘reagents,’ regardless of their actual use. These reagents enter the laboratory either in ready-to-use form or as something that will be prepared as a solution or a dilution before use. Many of these will be included in the analytical methods calculations – which provides a good incentive to include their preparation and testing in the LIMS as well. Initial registration includes giving them some identification. This can be either the supplier-based batch number or an internal ID, or both. It depends on how reagents are normally treated in the laboratory. There should always be a link to the manufacturer’s batch number. In many cases, reagents are prepared before use. For liquids, this can be a dilution of the original, such as 1 : 10, 1 : 20, or whatever. The new solution must also be given an ID, with a link to the original. Information on the preparation itself should be entered in the LIMS. For dilutions, this may include the fact that we used 100 ml and diluted this to 1000 ml. It is too easy to accidentally write a 1 : 10 dilution as a 1 : 100. Instead, set the LIMS up so that it calculates the dilution from the measurements, and so that you have to tell the LIMS how many milliliters were poured into what size flask. It makes even more sense to let the LIMS calculate solution strengths made by weighing chemicals. Usually, descriptions of such solutions say something like ‘weigh accurately approximately 2 g.’ To a nonchemist this seems to be an oxymoron, but the meaning is that we need approximately 2 g, and this needs to be weighed accurately to four or five digits. Set this up in the LIMS so that the balance enters the weight into the LIMS automatically when you have finished adding the materials, and then you can enter the volume manually before the LIMS calculates the exact concentration. Let the LIMS print out labels, which include the ID, the name of the reagent, the concentration, when it was made, the expiration date, and any other information that you need. Bar-coded labels are useful, as these can be read electronically. When these reagents are later used in an analytical method, you can simply specify which ID this solution has, and the LIMS will be able to retrieve the concentration information. If bar codes are used, all you need to do is to run the bar-code reader over the label to identify what you have used. If expiration dates or retest dates are included, it is possible to enter limits of use so that an expired reagent can’t be used. Some reagents also need to be instilled, tested, or otherwise analyzed. These can be set up as analytical methods for this sample type, just as for any other sample type.

18.13.2

Reagent and Chemical Stock

It is possible to include the whole stock of chemicals in the LIMS, and withdraw what is used from the LIMS stock every time something is used. There are probably better systems for handling stock than a LIMS, though it can be used for this purpose. The system can be set up so that whenever a quantity is lower than a set limit, it can generate a report to be sent as an e-mail either to the person in charge or directly as an order to the supplier. Wherever this is handled, it is a lot of work remembering to reduce the storage by 5 g or 10 ml each time something is used. It may be possible to set this up automatically to

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Instrument Connections and Definitions

255

a certain extent, when you know that analytical method xxx uses a fixed amount of the reagent each time. But this doesn’t account for spills and other waste, which will have to be entered manually.

18.14

Instrument Connections and Definitions

The LIMS can do a lot of different things with instruments, depending on how it is set up. Instruments can be connected to the LIMS so that the instrument and the LIMS can communicate. The LIMS can also hold the information about maintenance and calibration schedules. It is then possible to see if the instrument was handled according to procedure when it was used for analytical work. Communication between the LIMS and the instrument can be either one-way or two-way. One-way communication is always from the instrument to the LIMS, never the opposite. Even the simplest instruments – for example, balances – may be capable of sending the measured value out to a port, where the LIMS can pick it up and enter it in the database. However, we need to help the LIMS identify which sample has been measured using which method. In two-way communication, the LIMS will tell the instrument what to expect, and will receive results from the instrument. What data is sent between the two systems depends on the capabilities of the instrument or its computer. Data can be sent from the LIMS to tell the instrument that the following sequence of samples, standards, and control samples will be run today, using method xxx. This may be all the information that the instrument needs to get the sequence started. But a lot of instruments are not quite smart enough, and will need to be started using their own computers. The information from the LIMS may then only be useful in identifying the sequence of samples and/or the method. Some manual work is still required in the laboratory, though, such as sample preparation and actually setting the samples in the instrument carousel in the right sequence. There are some systems where the instrument can read a bar-coded label and identify the sample. In that case, it might not be necessary to enter the samples in the correct sequence in the autosampler. Data can be sent from the instrument to the LIMS. If the instrument has received data such as a sample ID from the LIMS, the instrument will attach this information to the measured values or the calculated results, which it can send back to the LIMS.

18.14.1

Communication Formats

How this data is formatted varies a great deal. Work has been done internationally to create standards for this communication, but this doesn’t seem to have taken off. According to Rick Lysakowski [2], standard file formats are not easy to maintain, as the use of heterogeneous systems leads to difficulties with consistent and easy access to data. The output data might be different between instrument models and software versions, even for the same type of instrument from the same supplier. Details can’t be described universally. This depends totally on the LIMS and the instrument in question. Basically, what is done in order to move data from one entity to the other

P1: OTE c18

JWBK188-Segalstad

256

September 15, 2008

14:0



is to retrieve the data output from the transmitting system, and reformat it or parse it as needed, so that the receiving system is able to understand the format. The data is either sent to the receiver or left in a file that the receiver polls every so often, to see if there is new data available for the LIMS. LIMS systems vary a lot with regard to how easy it is to set external instruments up for communication with the LIMS. Some use an extra instrument server to do the job, while others use the LIMS directly. Some use the server for complex communications and the LIMS directly for, for example, balances and other simple instruments.

18.15

Instrument Information

Instrument information, such as the identification of instrument parts, and maintenance and calibration schedules, can be entered into the LIMS. Let’s say that an instrument needs maintenance every 12 months, and calibration every five days. By entering the schedule and when the work was done last time, the LIMS can calculate when it’s about time for the next service. The LIMS can also flag up that the instrument is right before due date, or even after due date. Provided that the procedures say that the instrument can’t be used after the maintenance date if the maintenance has not been done, hard limits can be set so that the user does not have access to this instrument in question from the LIMS until it has been recalibrated/maintained. If the procedures are not so strict, soft limits can be set instead, so that the instrument can be used, but it is flagged up that this was after the due date. Calibration runs, system suitability tests, and other instrument tests can be defined in the LIMS as analytical methods to be used for the particular instrument, or for this type of instrument. Results entered for the analytical method will show that the instrument was checked at a certain time and found to be in working order – or maybe not found to be in working order. If we include this information in the LIMS, instrument log books can be made obsolete. This is a sensible place to have the information, as it will be available for control at the same time as the sample. The controller has all the information a keystroke away, instead of in various logbooks located in different laboratories, or in different computer systems.

18.16

Do We Store the Data in the Instrument System or in the LIMS?

Where we want to store the data depends on the system in question. Some systems can’t store data permanently. Some systems can store data, but are not compliant with the regulatory requirements. Some systems can store the data in a compliant way. And the LIMS will have the end-result in any case. Here, it is assumed that the instruments are connected to the LIMS so that they can transmit their data to the LIMS. 18.16.1

Instruments and Systems That Do Not Have a Permanent Storage Facility

There are several instruments that can’t store data permanently, but that are able to transmit it to the LIMS. Some instruments can’t store data at all, and once the instrument is measuring the next sample, the data for the previous sample has disappeared and can’t be

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Do We Store the Data in the Instrument System or in the LIMS?

257

retrieved. Some instruments can store a limited amount of data; for example, the last 20 measurements. The twenty-first measurement will then replace the first one. For all practical purposes, we can say that these instruments don’t have a permanent storage facility. Data from such instruments must be transferred to the LIMS and stored there with a reference to which instrument obtained the data.

18.16.2

Instruments That Can Store Data

Instruments with a computer can usually store data internally. Whether this is feasible or not depends on the backup routines, among other things. If the computer isn’t connected to the network, data has to be backed up manually. This is dangerous. We tend to forget to do this, and we do it less frequently than we should. The backup media is often handled haphazardly: Diskettes, CDs, or tapes are frequently thrown into the nearest drawer, and without proper labeling. Backups should, of course, be stored in a different place from the originals. Without good backup, you are quickly out of compliance. Get the computer onto the network immediately! If the computer is on the network, data can automatically be stored on a server, where it can be backed up daily in the normal backup routine. So let’s return to the question of whether the data should be stored on the instrument server or in the LIMS. In many cases, it is a matter of doing both. To explain this, we need to look at how LIMS systems are created and how the instrument systems work. LIMS systems have a database in which data is stored. Some, but not all, also have a file database that can store image files, text files, and other files. An instrument with a computer system generally stores data in a format that is economical from a storage capacity point of view, as well as efficient for retrieval and use by the software.

18.16.3

LIMS Without a File Database

If we look at a Chromatography Data System (CDS), we can see that this typically collects data every second (HPLC), or some 10–20 times per second (GC). With runs of many minutes, we collect a large number of measurements from the detector. The system can calculate the concentration of our compounds from the peak generated in the chromatograph when using the information in the method and the sequence. If we have a LIMS without a capacity for storing files, each collected data item will occupy one entry in the database. This isn’t an efficient way of storing data. What’s worse is that the LIMS can’t interpret the data. The conclusion is to let the CDS store the raw data, and let it send the final results to the LIMS after data processing. These results can include information on integration areas for each peak, together with the name of the peak for each of the samples, standards, control samples, and so on.

18.16.4

LIMS with a File Database

If the LIMS can store the instrument files in a file database, it might be interesting to assess storing the data there instead of in the instrument system. This is useful only if the LIMS can utilize and interpret the files in some way. If not, leave them in the instrument system.

P1: OTE c18

JWBK188-Segalstad

258

September 15, 2008

14:0



The file database in the LIMS can be used for a number of other things, such as pictures, sound files, and text files; for example, procedures for how to handle the instrument or the written analytical method. The best advice is to talk to the LIMS supplier and ask for their opinion about where particular types of data should be stored.

18.17

Stability Studies and Stability Testing

Stability studies are created to see how products deteriorate over time. This information is used to find the best-before date or the expiry date. Stability studies are heavily used in the pharmaceutical industry and are also used in the food industry. A product will potentially deteriorate differently depending on the storage conditions. The product is therefore stored under variable conditions to test deterioration: r Light versus dark. Light might affect the product r Temperatures from below freezing to above freezing. Usually, high temperatures are worse than low temperatures r Freeze–thaw–freeze cycles. Mainly used for liquids r Humidity. Dry air can sometimes cause the product to evaporate. Humidity can affect the packaging r The position of the product – upright, on its side, or upside-down can make a difference for liquid products, but hardly for tablets r Sometimes other factors are also included A stability study will show which factors affect the product at what time. To test this, climate cabinets are used. Each one is set with values for the various parameters, so that there is a good coverage of the variables, and created so that it is possible to see which parameter is the problem. For example: If two cabinets have the same settings except for two parameters that differ, it isn’t possible to see which of these two differing variables is affecting the product, though multivariate data analysis can be used for this purpose. The study is therefore set up as a grid of the variable parameters. Samples are stored in each of the cabinets, and withdrawn for testing based on a schedule, typically two weeks, and then 1, 2, 4, 6, 9, 12, 18, 24, and 36 months after they entered storage. The batch or batches used for the testing must be analyzed at the starting point, or ‘zero time point.’ 18.17.1

Stability Study Functionality in a LIMS

Not all LIMS systems have functionality for planning a stability study. A good stability module will be able to set the grid, and, based on how many samples are withdrawn for each time point and each storage cabinet, it will also calculate the necessary number of samples for the study. It is useful to add some extra samples, as there might be leakage, breakage, and other spills. The samples all belong to the same study, but the system should also keep track of which samples come from the same cabinet and thus have the same storage conditions. This is important in order to see the trends for each set of storage conditions.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Dissolution Testing

259

These studies often have differing analytical schedules as well. Samples will undergo a full set of analyses at some of the time points, while reduced testing will be planned for others. 18.17.2

Analyzing the Samples after Withdrawal

When samples are due for analysis, they are taken out of the cabinet and into the laboratory. The LIMS will automatically log them as an active sample to be tested this week. The samples are handled just like any other sample in the laboratory. One word of caution, though: Make sure that the samples are checked against the same specification throughout the study, unless you specifically want to change the spec. Quite often, a new version of a spec-set will replace an old version, and this will affect studies that last for years.

18.18

Pharmacokinetic Studies and Testing

Pharmacokinetic studies are in principle set up in the same way as stability studies, but with one major difference: Stability studies have the goal of testing how stable the product is on the shelf, to determine the shelf-life. Pharmacokinetic studies are used to test how the body breaks the product down and disposes of it. Various body fluids are tested to find the product or its metabolites (breakdown products) over a shorter period of a few hours or a number of days. The fluids (blood, urine, feces, or others) are collected at certain time points and analyzed. 18.18.1

Pharmacokinetic Study Functionality in a LIMS

Some LIMS systems also have a separate module for pharmacokinetic studies; if not, it may be possible to tweak a stability study module so that it can be used. This isn’t ideal, but I’ve done it and it worked. The study is planned in the system, equivalently to the stability study. Samples belonging to the same animal or person are linked together in the system, and these are again linked together to belong to the whole study. Information on the animal and/or person must be included. Which information is needed is explained below. When the samples are ready for analysis, they will be just like any normal sample in the LIMS. A typical report from this testing would be a trend report showing the concentration of the products and its metabolites over time.

18.19

Dissolution Testing

Dissolution testing is done to check how tablets or other units dissolve. The procedure is rigidly described in the pharmacopoeias. If dissolution testing is something that your company does, you must make sure that the new LIMS is able to handle the special quirks of this method. You must check with the pharmacopoeia for how to do it with your products. Below is the requirement from the US Pharmacopoeia [3].

P1: OTE c18

JWBK188-Segalstad

260

September 15, 2008

14:0



The specification for the product dissolution is defined as ‘Q’: Stage S1: First six units are tested. Each of these is not less than Q + 5%. If this specification is not met, go to stage S2. Stage S2: Six additional units shall be tested. Average of the 12 units from S1 and S2 is equal to or greater than Q and no unit is less than Q − 15%. If specification is not met, go to stage S3. Stage S3: 12 additional units shall be tested. The average of the 24 units from S1 + S2 + S3 is equal to or greater than Q, not more than two units are less than Q − 15%, and no unit is less than Q − 25%. As we can see here, there is a variable number of samples to be tested and spec-checked. If a test from one stage is outside of specifications, additional samples must be tested, new calculations performed, and new specifications checked. Note that there are spec-checks on calculations, on single results, and on the number of single results. 18.19.1

Dissolution Functionality in a LIMS

Some LIMS systems may have functionality built into them for this purpose. But it is also possible to create the calculations and spec-checks in a LIMS using normal system functionality. I did this in an old LIMS, using a report automatically triggered by an out-of-spec result from Stage S1. This report would log new samples with a new Stage S2 method, which would make the correct calculations based on all results obtained from the current and previous stages, and would then compare that to the new Stage S2 specs. A different report would be triggered by out-of-spec results from Stage S2 and would create the additional samples for Stage S3, with their method, calculation, and specifications.

18.20

Information on Animals or Patients

Some laboratories need information that can be used to identify animals or patients. This is generally necessary for GLP and GCP purposes in the pharmaceutical industry, for pharmacokinetic studies, in healthcare systems, and in contract laboratories. Which fields are necessary will vary, but some of those needed for human patients are listed below: r r r r r r r r

name identification code, to make them anonymous male/female address (street, P.O. box, zip code, city, country) CRO center name (Clinical Research Center, doctor) CRO center address study information sample type (blood, urine, or other)

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Radio Frequency Identification

261

Some of the necessary fields for animals are as follows: r r r r r r

animal ID animal type male/female age study information sample/tissue type (heart, brain, liver, spleen, lung, etc.)

For either kind of study information, the sample type and the ID will be the link to the rest of the LIMS.

18.21

Customer Information

Contract laboratories will also need information on their customers. Some of the necessary fields are as follows: r r r r r r

customer name address phone number fax number e-mail address contract information – for example, reduced price for analysis

The customer may also need access to the LIMS to order an analysis, or to view the results and check the order status.

18.22

Bar-Coded Labels

The LIMS is able to create labels through the reporting system. The label can be configured to contain the information that the laboratory needs. The use of bar-coded labels can help secure data in the system by having electronic readings of the identification of, for example, reagents and standards. Then the LIMS knows exactly which reagent or standard and its concentration is being used. The LIMS can make use of this information during calculations, and there are no potential errors due to manual input. There are various types of bar codes that are used in different settings. Make sure that you specify which type of bar code you want to use with the LIMS and check that the LIMS can read it. The reporting system can generally create bar codes.

18.23

Radio Frequency Identification

One of the newer identification types is Radio Frequency IDentification (RFID). The technique is used in many different settings, including the security devices on goods in stores – you know, the ones that squeak if they’re not removed before you go through the

P1: OTE c18

JWBK188-Segalstad

262

September 15, 2008

14:0



security gate on your way out of the store. They are also used in Europe for identifying cars that have prepaid on toll roads. These devices are also implanted under the skin of dogs, for safe identification. When a dog is found, a scanner can detect the identification in the chip. The kennel clubs keep the overview and it is easy to find the owner. An RFID is also required when you want to bring a dog across a national border. In the manufacturing world, there can be one in each box of goods, making it possible to count the number of boxes on a pall electronically, rather than manually. RFIDs have also been used on bracelets for, for example, pharmacokinetic study patients, so that each patient can be identified correctly by reading the bracelet before blood sampling. An RFID can typically hold a lot more information than a bar-coded label. If you intend to use a RFID with a LIMS, make sure that the selected LIMS can read it.

18.24

The Chain of Custody

For forensic work, doping laboratories, police laboratories, and customs laboratories, secure data is vital, it will often be used for legal purposes. But it doesn’t help much to have secure data in the LIMS if it can’t be proved that the sample being analyzed is the exact same one that was collected. A chain of custody is important for this purpose. The chain is formed when one person acknowledges, in writing or through an IT system, that he has taken possession of the sample from the last person. When this is documented, it is possible to prove that the sample that was once collected is the very same one that is being analyzed. Most LIMS systems have functionality for a chain of custody, but if this is important the chain of custody must be set as mandatory. For most laboratories, a chain of custody isn’t important, and setting this functionality as mandatory will only result in irritation among the users.

18.25

Sample Scheduling and the Workload

Normally, production is planned well in advance. In Quality Control laboratories, it is therefore possible to plan the sample scheduling and workload. This may be useful to see how the week can be best organized, both for the staff and the laboratory resources. In other laboratories, it may not be quite so simple to plan the workload. Samples in an R&D laboratory or in a contract laboratory may have very short lead times, which is the time between knowing that there will be a sample coming in and the actual arrival of that sample. The LIMS can help in scheduling samples and workload, but this may become somewhat labor-intensive if it isn’t done properly. 18.25.1

Sample Planning

It is possible to log samples as soon as there is knowledge about new samples. Samples may come in from production or as raw materials/purchased goods. They can be given a status that informs us that they are planned to arrive in the future, usually with some indication of the expected date. Samples from, for example, stability withdrawals are also

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Status

263

known a long time before they are to be analyzed. These may also be logged and given a ‘planned’ status. Once the samples are in the arrivals area, they can be given a status that indicates that they are ready for sampling and analyses. It makes it easier to plan the work if samples are logged as soon as somebody knows that they will exist at some point in the future.

18.25.2

The Workload

With planned samples, it is possible to assess the future workload. A pool of people may be competent to do certain analyses. When the templates for the analyses are set up, these people can be entered as analysts. It should also be possible and easy to shift responsibility from one person to another due to heavy workloads, vacations, illness, or any other reason. The various LIMS systems differ to some extent in how workloads are handled, so if this is functionality that you will need, it’s best to check how it is handled in your system.

18.26

Status

All LIMS systems have status engines: r Some are automatic and change according to the work done in the system r Some are changed manually r Some can be preset to either manual or automatic. One example is approvals. The status may be automatically changed to ‘approved’ or ‘unapproved’ depending on the analytical results, or this may be forced so that it has to be assessed manually by authorized persons No data in the system is ever actually deleted from the system, though it may be given a status called ‘deleted.’ This status will usually make the item invisible during queries, but it still exists in the database and can be retrieved when needed. The names of the statuses may differ from system to system. The examples below are used to explain what the various statuses will do, and should not be interpreted as definitive names. What is important is that status is given as clear text, and not, for example, as ‘Status 1, 2, or 3,’ which needs to be interpreted.

18.26.1

Needed Status

The status for templates (static data) should include the equivalent of ‘new,’ ‘approved,’ and ‘old’/‘replaced.’ When a new template is being worked on, it should have the ‘new’ status, regardless of whether it is being created from scratch or whether an existing template is being copied and modified. When the template has been checked/tested or whatever, someone must approve it manually. The new status is then given as ‘approved.’ This template may later be replaced by a new one, and when the new one is approved, the old one will automatically be given the status ‘old’ or ‘replaced.’

P1: OTE c18

JWBK188-Segalstad

264

September 15, 2008

14:0



Status for results may include ‘empty’ (no result entered yet), ‘entered’ (result entered but not checked for specifications or other limits), or ‘in spec’ or ‘out of spec’ when checked. Status for samples may include ‘planned’ (when the sample has not yet been received), ‘received’ after reception (usually a manual change), ‘started’ when the first result has been entered, ‘complete’ when all results have been entered, ‘in spec’ when all results have been spec checked and are inside the spec, ‘out of spec’ when at least one result is out of spec, and ‘approved’ or ‘not approved,’ which may be done automatically based on the spec check, or manually. A sample may also be ‘discarded’ or ‘cancelled.’ Instruments and reagents may have a status indicating whether the item is ‘out of calibration,’ ‘out of maintenance,’ or ‘outdated’ – or whatever may make sense for the type of item. The status engine and status changes are useful for other purposes as well. It is possible to configure the LIMS to trigger things when a status changes. The list is endless, but some examples are as follows: r when a sample is logged, a work list is printed to a specific printer, or sent via e-mail to the laboratory manager r when a sample or series of samples are approved, the Certificate of Analysis is created as a .pdf file and sent to the contract laboratory customer r when an instrument is out of calibration, a message is sent to the person responsible for the instrument 18.26.2

Automatic Status Changes

The status engines are automatic. The LIMS checks all the time if conditions have changed so that a status needs to be changed. Typically, when results are entered, the status may change from ‘empty’ via ‘started’ to ‘complete’ and then to ‘approved.’ 18.26.3

Manual Status Changes

It should also be possible to make manual changes. This can involve various types of disposal, and approval/rejection of the sample. It should also be possible to overrule some of the automatic statuses given by the system. It may be necessary to approve or reject something manually that has already been automatically approved or rejected.

18.27

Security

Security is an important aspect of any computerized system. This includes both security for the data inside the system and secure access to the system. Chapter 2 on 21 CFR Part 11 [4] discusses the details of data security, so only an overview will be presented here. 18.27.1

User Access

The LIMS must include certain features for securing access to the system, the data, and the program files surrounding the system. Only defined users should have access to the

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Specifying and Choosing the New LIMS

265

LIMS, and it should be possible to tailor the access to functionality/commands and data for each user: r the user must log into the system in a secure way by using a user ID and a password, token, or biometric input that is unique to that user r users should have differentiated access to commands/functionality according to their needs and the types of jobs or roles that they have in the organization r users should have differentiated access to which data they are allowed to see, use, change, and maintain 18.27.2

Referential Integrity

The system should have referential integrity. This means that it should not be possible for anyone to have access to LIMS through the ‘back door’; that is, directly to the database tables or the system files so that they can write, delete, or modify data. Access to these tables or files may corrupt the whole database.

18.27.3

The Audit Trail

All new entries in the LIMS should include an audit trail, with information on who made it and when (date and time). All changes in the LIMS should include an audit trail giving information on who made the change and when it was made, and a mandatory reason to explain why the change was made. The reason should be chosen from a list.

18.27.4


The functionality for electronic signatures in a LIMS must assure that only the correct user signs in the LIMS, and not just someone who finds a computer with an open LIMS session. The LIMS must prompt for a password or biometric input before a signature is committed to the database. If the answer to the prompt fails (e.g., wrong password), the signature must not be committed.

18.28

Specifying and Choosing the New LIMS

The User Requirements Specification (URS) is discussed in detail in Chapter 13. It is useful to read through the whole of this LIMS chapter to see if there is functionality that you will need or will not need before writing your URS. 21 CFR Part 11 also has several requirements for technical solutions in a computerized system that need to be included in the LIMS URS. Writing the URS may seem tedious, but it does help the organization find out exactly what its needs are. The process of discussion and writing is a good one. If you are not familiar with LIMS yourselves, it might be useful to get external help from a consultant who understands LIMS and knows what a LIMS can do. This will add considerably to the process of understanding what the laboratory’s needs are, and how a LIMS can improve the

P1: OTE c18

JWBK188-Segalstad

266

September 15, 2008

14:0



work processes and data security. Making sure that the organization understands its needs will help it to select the best possible LIMS on the market for that organization [5, 6]. When writing a URS, it is important to describe your vision for the system in the laboratory, rather than stating that ‘The system shall include the following information at the top left of the screen . . .’ Describe what your needs and visions are, and not what anyone else, including the supplier, thinks they should be. Your vision might be, for example, that instruments should be connected to the system so that information xxx can be sent directly to the LIMS for further calculations – or that the instrument should perform all calculations on its own, and send the calculated result to the LIMS. Don’t write all questions so that they need ‘yes’/‘no’ answers. Some of them can be written this way, of course. But the more complicated issues need to be phrased so that the supplier must give an explanation. Present the supplier with a typical scenario, and ask them how this might be addressed within their system. For example: ‘We need to divide samples and send them to different laboratories for testing, and then report them as one sample. How would you address this?’ If you haven’t seen the system, ask the supplier to include some screen shots in an appendix. However, while this will show the layout of the screens, it may not say much about the functionality. Make sure that fancy layout doesn’t hide bad functionality. Table 18.2 includes extracts from part of a LIMS URS covering dissolution testing.

18.29

The Traceability Matrix

The traceability matrix, or trace matrix, is a document that shows the links between the various requirements and the testing, and is described in Chapter 13. Table 18.3 shows an example of a traceability matrix between the URS, the FS, and the OQ test plan. It is sorted by the URS statement, but it can easily be sorted by any other column.

18.30

A List of SOPs for a LIMS

Table 18.4 shows a list of items to be covered in SOPs for the LIMS systems. The content of these are described in the text above, as well as in Chapter 5.

18.31 18.31.1

Tasks Static and Dynamic Data

Explain the difference between static and dynamic data, and why we need to work thoroughly with the static data in order to get the necessary data for our samples 18.31.2

The Chain of Custody

A customs officer checking a car disembarking from a ferry finds a bag of powder in the gas tank and sends this off to the customs laboratory for analysis, where it is found to be heroin.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Tasks

267

Table 18.2 A URS for Dissolution Testing in a LIMS Dissolution testing is done according to principles outlined in the European and/or US Pharmacopoeias to see how tablets dissolve over time. The methods include stringent logic for retesting and calculations of retested results in case of initial failure. Dissolution testing is included in the URS because the recording of the results and in particular automatic verification up against specification limits implies special requirements. Example of testing Include the description stated above in the chapter on dissolution testing only if this is the way of doing this in your organization. Current way of working Assessment of results, with subsequent retesting is done manually, as are the result calculations. Vision with LIMS LIMS checks the results against the specifications, automatically adds new samples whenever needed for retesting, and calculates according to the rules.

ID

Dissolution testing requirement text

3.1

Can the logic for dissolution testing be built into the LIMS templates so that LIMS automatically adds the correct number of tablets for retesting, and makes the correct calculations? Can LIMS handle that the availability of some values is dependent of other values compliance with specification limits? Can LIMS handle that specification limits change depending of the number of individually tested samples? Can LIMS handle that there are two types of aggregation of the individual results to be verified up against different specification limits? If the above questions are negative, please describe an alternative way of covering our requirements.

3.2 3.3 3.4 3.5

Explain how the chain of custody must be in order to make the case ‘foolproof’ for the court. You may write this as a procedure or as a text. 18.31.3

The Chemical and Reagent Inventory

Discuss the advantages and disadvantages of having the inventory in a computer system such as a LIMS. 18.31.4

Basic Functions

Your laboratory is a contract laboratory doing environmental analysis for a number of customers. List which information your LIMS needs to include for: r demographic data r operational data r financial/billing data

P1: OTE c18

JWBK188-Segalstad

268

September 15, 2008

14:0



Table 18.3 A Traceability Matrix for Dissolution Testing in a LIMS Trace matrix between URS (sorted by the URS) AND Functional Specification (FS) AND LIMS OQ testing protocol (the ‘Test plan OQ’ column gives the name of the test plan where this is tested in a workflow) Statement

Ref. URS ID FS Test plan OQ Comments

Dissolution testing: LIMS adds the correct number of new tablets after the first failure LIMS adds the correct number of new tablets after the second failure LIMS calculated correctly after adding the first tablets Results entry: Numeric answers can be entered Text answers can be entered Numeric or text answers can be entered Calculated answers can be entered Results can be entered automatically from the instrument

18.31.5

3.1

24

U1

3.1

25

U1

3.1

26

U1

4.2

85

R2

4.2 4.2

86 87

R2 R3

4.2

88

R3

4.2

89

R1

Will be tested after the first instrument has been connected

Biometric Identification

Biometric identification will be used more and more to identify the person as the true and correct user. Today, the US immigration authorities scan thumbs and eyes to identify non-US citizens visiting the United States, and there are also some companies that require biometric identification for entrance to their premises and access to their computer systems. The aviation companies have discussed using fingerprint scanning for access to the flight deck, but they are also aware that a terrorist would be prepared to cut off a finger in order to gain access. Therefore, the scanning also needs to take into account that the finger is attached to a body; that is, by checking blood circulation. Discuss potential problems for each of the following types of biometric identification – that is, the things that can go wrong for a normal user in a normal company: r r r r

fingerprint scanning retina recognition voice recognition face recognition

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Tasks

269

Table 18.4 Standard Operating Procedures for a LIMS SOPs in the IT department SOPs in the IT department must be made, or changed, to include the LIMS when appropriate. An agreement for the maintenance and support of the LIMS must also be created: • Backup procedures. • Change control for items where IT is responsible (hardware, operating system, database management, network, installation of LIMS versions). • Configuration management outside of the LIMS (operating system, database, LIMS program files, network, hardware). • Security and user access outside of the LIMS. SOPs for LIMS key persons • Responsibilities for the LIMS (IT, LIMS system managers and key persons, LIMS steering committee, users, QA). • User training and user access inside the LIMS. • Security. • Building static data/templates in the LIMS, including nomenclature and so on. • Instrument connections to the LIMS. • Connections between the LIMS and other IT systems (MRP, DMS, CDS, other instrument systems). • Error handling. • Change control. • Validation/revalidation/qualification of the LIMS itself, connection to other systems and instruments, and static data. • Configuration management inside the LIMS (static data). • Disaster recovery. • Long-term storage of old data outside of the LIMS. • Retirement of the LIMS (yes, it is required!). SOPs for LIMS end-users • Daily use of the LIMS, with reference to other LIMS SOPs. Other SOPs • Each department where the LIMS will be taken into use will have to assess all existing SOPs to see if they need to be changed due to the implementation of the LIMS. Logs (documentation that SOPs have been followed) • Several SOPs will require documentation that they have been followed. In many cases this is a log, but it does not matter if it is electronic or a book, as long as there are procedures in place to make sure it works.

18.31.6

The Implementation of an Analytical Method

Below is a description of an analytical method from Arthur Vogel’s book on inorganic analysis [7]: Determination of sulphuric acid in concentrated acid Accurately weigh a small, glass-stoppered weighing bottle, and add from a clean dry 2 ml pipette or measuring cylinder 0.7–0.8 ml of the concentrated acid. Re-stopper the bottle immediately and re-weigh accurately. Place about 100 ml of water in a 250 ml volumetric flask and insert a short-necked funnel in the mouth of the flask. Pour the weighed acid into the funnel, and, without removing the weighing bottle, wash it thoroughly both inside and outside with a stream of water from the water bottle. Rinse the funnel thoroughly and remove it. Dilute nearly to the mark, and after 1–2 h, when the solution has acquired the laboratory

P1: OTE c18

JWBK188-Segalstad

270

September 15, 2008

14:0



temperature, make up exactly to the mark. Shake and mix thoroughly. Titrate 25 ml portions with standard 0.1 N sodium hydroxide, using methyl orange as indicator. From the results calculate the percentage by weight of H2 SO4 in the original concentrated acid.

2 NaOH + H2 SO4 → Na2 SO4 + 2H2 O For each ml 0.1 N NaOH there is 0.04904 g H2 SO4 .

Create an overview of how this should be implemented in a LIMS. 18.31.7

Requirements for an Audit Trail

The 21 CFR Part 11 requirement for an audit trail is stated as follows: 11.10 (e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

Create a detailed and testable specification to make sure that all aspects are covered in a new system.

References R

R

1. GAMP 5 Good Automated Manufacturing Practice (GAMP ) Guide for A Risk-Based Approach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL, ISBN 1-931879-61-3, www.ispe.org. 2. Lysakowski, R. (1995) Standards for exchanging analytical data, in Advanced LIMS Technology (ed. J.E.H. Stafford), Blackie Academic and Professional, an imprint of Chapman and Hall, Glasgow, UK, ISBN 0 7514 0189 7. 3. US Pharmacopeia (n.d.) USP 23 for 4a: Immediate-release dosage forms. US Pharmacopeia, Rockville, MD. 4. US FDA (1997) 21 CFR Part 11 Electronic Records; Electronic Signatures, US Food and Drug Administration, Rockville, MD, www.fda.gov. 5. Segalstad, S.H. (2000) The User Requirements Specification – the most important tool in the validation. Scientific Computing and Instrumentation, Fall, 24–25. 6. Segalstad, S.H. (2000) Development qualification: selecting the right LIMS supplier. European Pharmaceutical Review, 5 (4), 58–61. Also published in American Pharmaceutical Review, 3 (4), 84–87. 7. Vogel, A. (1969) A Textbook of Quantitative Inorganic Analysis, 3rd edn, Longman, London, ISBN 44247 8.

Further Reading The books that have been written on LIMS are relatively old, and parts of them may be outdated. However, they all contain a lot of useful information.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


Further Reading

271

McDowall, R.D. (1989) LIMS: Laboratory Information Management Systems: Concepts, Integration and Implementation, Royal Society of Chemistry, London. Mahaffey, R. (1989) LIMS, Applied Information Technology for the Laboratory, Van Nostrand Reinhold, New York. Nakagawa, A. (1994) LIMS Implementation and Management, Royal Society of Chemistry, Cambridge, UK, ISBN 8-85186-824-X. Stafford, J.E.D. (ed.) (1995) Advanced LIMS Technology, Blackie Academic and Professional, an imprint of Chapman and Hall, Glasgow, UK, ISBN 0 7514 0189 7. Paszko, C. and Turner, E. (2002) Laboratory Information Management Systems, 2nd edn, revised and expanded, e-book, Marcel Dekker, New York, ISBN 0-8247-0521-0521.

P1: OTE c18

JWBK188-Segalstad

September 15, 2008

14:0


P1: OTE c19

JWBK188-Segalstad

September 15, 2008

14:7


19 Building Management Systems and Heating, Ventilation, and Air Conditioning

This chapter discusses the following: r Building Management Systems (BMS) and Heating, Ventilation, and Air Conditioning (HVAC) r Hardware and software for BMS and HVAC r Regulations covering BMS and HVAC r Validation issues, including risk assessment for the whole systems and their component parts

19.1

Introduction

Building Management Systems and Heating, Ventilation, and Air Conditioning systems are used throughout most industries. The systems control temperature, humidity, ventilation rates, and air pressure. These systems are usually highly automated, with feedback from sensors to the control system to adjust for values outside of the set ranges. The systems will give an effective control of building-related processes and equipment. BMS is thus an effective solution for cost-conscious building management strategies. The input comes from sensors placed strategically in the areas to be controlled and monitored, and the output


P1: OTE c19

JWBK188-Segalstad

274

September 15, 2008

14:7


Building Management Systems and Heating, Ventilation, and Air Conditioning

will automatically adjust the mechanical devices, such as valve actuators, to restore the normal values. The systems are used to control, record, monitor, and alarm a large variety of processes, some of which are important to the products being made while others are not. Some of these systems will only control the environment in offices and other building areas. These are important for the people working in the buildings, but not important for the products themselves. Table 19.1 defines the terminology in the world of BMS. HVAC and BMS systems are used in several types of industries where the production environment is vital for the products. HVAC covers the mechanical parts of the system – including fans and ventilators, for example – while BMS covers the electronic parts of the system, where values are set, collected, and checked, and adjustment messages are sent to the actuators. The pharmaceutical industry may require sterile manufacturing, and the electronics and pharmaceutical industries may require cleanrooms that are virtually particle free. BMS systems will often cover both regulated and nonregulated facilities and processes simultaneously. These are complex systems, in which some parts have a direct impact on the processes and products, while other parts have little or no impact. Production air conditioning and chilled water may or may not have an impact, or may have an indirect impact. You need to assess your products and your production situation to determine the impact on the product quality from your BMS.

19.2

BMS Systems

A BMS is a computerized system that monitors, schedules, controls, optimizes, and manages building electrical and mechanical equipment operation to maintain occupant comfort and critical environments conditions within a facility. The data acquisition and control module of the BMS is comprised of the following components: the BMS server, BMS client workstations, BMS field panels with controllers, and network connections using a wide variety of protocols, as described in Table 19.1. The data acquisition and control module functions manage equipment control, environmental monitoring functions, alarm processing, and operator notification. The system manages the data collected by the data acquisition and control module, provides secure storage for those data records in electronic form, performs defined calculations on data records, and organizes and retrieves electronic data records as needed [1]. The BMS includes several of the components listed below. Some of these are sensors or measuring devices that need to be calibrated. Others are electronic field devices that can be used for setting values, ranges, and specifications. These devices can be either a computer hooked directly to the BMS or a portable hand-held terminal or PC that can be downloaded at any later point through a docking device. These are usually called Input/Output (I/O) devices. The sensors may be analogue or digital. The signal is sent to a programmable logical controller.

P1: OTE c19

JWBK188-Segalstad

September 15, 2008

14:7


BMS Systems

275

Table 19.1 BMS/HVAC Terminology Actuator BMS EMS Field device Field Panel FMS HMI

HVAC IMS I/O Network protocols used for BMS

Outstation

PLC

SCADA Sensor Substation Unterstation

A mechanical part such as a vent, a valve, and so on. Building Management System. A system that monitors, schedules, controls, optimizes, and manages building electrical and mechanical equipment operations. Environmental Monitoring System. See Sensor. A cabinet with one or more I/Os and PRSs. A brand of IMS and EMS. Human–Machine Interface. A panel used for communicating with the BMS. It may be located outside the field panel, or it may be portable. Note that portable HMIs usually don’t have an audit trail for changes, and should be used as view-only. Heating, Ventilation, and Air Conditioning. Used for the mechanical parts of the system only, with no sensors. Independent Monitoring System. Used to monitor environments controlled by a BMS. See Building Management System. Input/Output. Used for sensors, regardless of what the sensor measures. • TCI-IP • ModBus • EIBus (European InstaBus). A rigid protocol that needs approval before changes are made • BACNet (LON). An open protocol without any approval for changes, which makes it unpredictable • Profibus. An open protocol, frequently used in industry • Proprietary data buses work independently and alone on the network. Needs black box testing, as the content is not always known PLCs may be used to control a process ranging from a small number of Inputs/Output (I/O) devices to a large number of I/Os. The PLC may make autonomic decisions; for example, giving a message to an actuator to open a vent for hot air if the temperature is dropping. Called an ‘outstation’ in the United Kingdom, a ‘substation’ in the industry, and an ‘Unterstation’ in Germany. Programmable Logic Controllers are designed to control inputs/outputs. They may be used to control a process ranging from a small number of I/Os to several thousand I/Os. They may be general purpose or dedicated to certain functions. Supervisory Control And Data Acquisition system. Typically used for building management systems and production systems to control temperature, air pressure, humidity, and so on. Sensors measure pressure differences (P) between two places, temperature (T), Relative Humidity (RH), and other parameters. The output is a signal between 2 and 20 mA or 0 and 10 V. Industry expression. See Outstation. German expression. See Outstation.

P1: OTE c19

JWBK188-Segalstad

276

19.3

September 15, 2008

14:7



Programmable Logical Controllers

The hardware connected to any BMS system consists of a multitude of Programmable Logical Controllers (PLC), designed to control inputs/outputs. These PLCs are either general purpose or are tailor-made, with HVAC dedicated libraries. They are multi-function devices that use programmed instructions to store and manipulate data, and to monitor and/or control process devices. PLCs may be used to control processes ranging from a small to a large number of I/Os. The PLC may make autonomic decisions; for example, to send a message to an actuator to open a vent for hot air if the temperature is dropping. The PLC is called an ‘Unterstation’ in Germany, an ‘Outstation’ in the United Kingdom and the United States, and a ‘Substation’ by the BMS/HVAC industry. The PLC and several I/Os are located in a locked cabinet. The cabinet is called a field panel, and on the outside there is often a Human–Machine Interface (HMI) that can be used for communicating with the system. The PLCs use combinations of subordinate dedicated control systems and/or configurable systems to achieve a comprehensive control scheme on more complex processes than those previously described. All aspects of the system’s operation are defined and configured by the user.

19.4

SCADA

Supervisory Control And Data Acquisition (SCADA) systems are typically used for building management systems and production systems, to control, supervise, and report temperature, air pressure, humidity, and so on. SCADA systems, and a derivation hardware or software using a scientific programming language, such as FORTRAN, C, or Basic in a computer environment, are also included in this category of control systems. The SCADA solutions are open systems and are frequently preferred to proprietary and supplier-specific systems.

19.5

Control Parameters and Instrumentation

The control parameters in a BMS include temperature, air pressure, and humidity set points, acceptable ranges, time spans, and alarm limits, to mention a few. The parameters can be entered centrally in the BMS system or locally via Human–Machine Interfaces (HMIs), sometimes referred to as Man–Machine Interfaces (MMIs). The acronym HMI is a generic term for a field panel or other device that will let a person interact with a computer system. The BMS comprises a large number of instruments and devices that monitor and communicate measurements and status information. These are used for controlling the environment and adjusting parameters. The feedback from the measured values can adjust the parameters by creating actions using, for example, valves and other actuators to get the value back into the normal range. It is obvious that calibration of these instruments is critical to process control. A BMS system will also log the selected, measured data. Some of this data will often be part of the batch record for a production process, where the parameters are vital or even critical for the product. A typical example is sterile, aseptic, or cleanroom production, where air pressure readings can reveal potential contamination.

P1: OTE c19

JWBK188-Segalstad

September 15, 2008

14:7


Regulatory Requirements and Validation Enforcement

277

The system can be set up to give alarms when parameters are outside of their set limits, and may or may not have a feedback into automatic corrective actions. Regardless, these alarms can be reported and may be a part of the batch record.

19.6

Sterile Facilities

Sterile facilities are also called cleanrooms. They are needed in various types of production facility, ranging from sterile and aseptic pharmaceutical production facilities to electronics production units, where particles can be harmful. Bacteria are within the harmful range of sizes that can affect electronics, so even if the bacteria themselves don’t infect the electronics, they do affect them. Sterile facilities are categorized according to their particle amounts. Table 19.2 shows the definitions in the EU and the United States, based on the US Pharmacopoeia [2], the US GMP [3], and the EU GMP Annex 1 [4]. Please note that the volumes from which the particles are measured have different units in the two definitions; in the EU a cubic meter is used, while in the US 10 cubic feet is used. Sterile facilities need to be constructed in a scientific way to make it possible to keep them clean. For example: Surfaces need to be hard, so that particles aren’t created; and particle filters (HEPA filters) must be installed and maintained. The ISPE Baseline Guides [5–9]. have a lot more information on this. Sterile facilities also need to have barriers, such as airlocks with differing air pressures between the rooms, in order to make the air flow from the cleanest room to the less clean room. Otherwise, the particles will follow the airflow from an unclean room to a clean room – with disastrous results. The difference is often as low as 10 Pa, which is equivalent to the pressure of a $1 note lying on a table – hardly possible for a person to detect. The BMS system is vital for cleanrooms. The parameters must be set correctly, ranges for acceptable values must be set, and the alarms must work if measured values are outside of the acceptable ranges. Furthermore, there could be feedback from alarms to actions that result in adjustment of parameters, to get the values inside the acceptable ranges again.

19.7

Regulatory Requirements and Validation Enforcement

The regulatory background for validation is stated in various GMPs, which all have requirements for control of the environment. An extract is listed in Table 19.3. The type, size, and complexity of the BMS will determine how difficult it is to demonstrate that the BMS environment is under control. The FDA has issued a large number of warning letters regarding BMS systems. Extracts from some of these can be seen in Table 19.4. The key word here is ‘control’ over the environment. As mentioned in an earlier chapter, it is easier to see how the FDA handles deviations than how the EU does. The reason for this is the US Freedom of Information Act, which requires the US authorities to be open with the public. The FDA web page (www.fda.gov) lists all of the warning letters issued to pharmaceutical companies. The EU does not have the same openness, and it is rare to find information on inspections and findings.

P1: OTE c19

JWBK188-Segalstad

278

September 15, 2008

14:7



Table 19.2 Environmental Classification of Cleanrooms

Description Environmental classification Descriptive grade At rest

In operation

Max. no. of 0.5 µ particles permitted per m3 ≥ the stated size 5µ Max. no. of 0.5 µ particles permitted per m3 ≥ the stated size 5µ Maximum

International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries

International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries

Pharmaceutical Manufacturing Handbook: Regulations and Quality

Biocatalysis in the Pharmaceutical and Biotechnology Industries

Biocatalysis in the Pharmaceutical and Biotechnology Industries

International Accounting: Standards, Regulations, Financial Reporting ACT

Good Pharmaceutical Manufacturing Practice: Rationale and Compliance

Web Accessibility: Web Standards and Regulatory Compliance

Web Accessibility: Web Standards and Regulatory Compliance

Laboratory Auditing for Quality and Regulatory Compliance

Construction Quality and Quality Standards: The European perspective

The IT Regulatory and Standards Compliance Handbook:: How to Survive Information Systems Audit and Assessments

Cost-Contained Regulatory Compliance: For the Pharmaceutical, Biologics, and Medical Device Industries

Lecturer's Guide to Quality and Standards in Colleges and Universities

Quality (Pharmaceutical Engineering Series)

Data-Exchange Standards and International Organizations: Adoption and Diffusion (Advances in It Standards and Standardization Research Series (Aissr))

Quality Research in Literacy and Science Education: International Perspectives and Gold Standards

Validation Standard Operating Procedures: A Step by Step Guide for Achieving Compliance in the Pharmaceutical, Medical Device, and Biotech Industries,

Validation Standard Operating Procedures: A Step by Step Guide for Achieving Compliance in the Pharmaceutical, Medical Device and Biotech Industries

Containment in the Pharmaceutical Industry (Drugs and the Pharmaceutical Sciences)

Robotics and automation in the maritime industries

International Pharmaceutical Registration

Transport Processes in Pharmaceutical Systems (Drugs and the Pharmaceutical Sciences)

Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools

IT Compliance and Controls: Best Practices for Implementation

The Oil and Gas Industries

Resisting Protectionism: Global Industries and the Politics of International Trade

Wireless Quality of Service: Techniques, Standards, and Applications

Handbook of Regression and Modeling: Applications for the Clinical and Pharmaceutical Industries

Process Analytical Technology: Spectroscopic Tools and Implementation Strategies for the Chemical and Pharmaceutical Industries

International IT Regulations and Compliance: Quality Standards in the Pharmaceutical and Regulated Industries