ISPE GAMP Good Practice Guide: Electronic Records and · PDF fileispe/gamp: good practice...

ISPE/GAMP: GOOD PRACTICE GUIDE INDUSTRY REVIEW

ELECTRONIC RECORDS AND DATA INTEGRITY JUNE 2016

of 198

1

2

3

4

5

6

ISPE/GAMP GOOD PRACTICE GUIDE: 7

ELECTRONIC RECORDS AND DATA INTEGRITY 8

9

10

DRAFT FOR INDUSTRY REVIEW 11

12

JUNE 2016 13

14

15

16

PLEASE NOTE: CROSS REFERENCES WILL BE UPDATED DURING THE FINAL PRODUCTION OF 17

THIS ISPE GUIDANCE DOCUMENT. 18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40 41

42

©ISPE 2016. All rights reserved. 43

44

45

Do not distribute this document or post on any Web site, blog site or page, or any other internet site.(Copyright © 2016 International Society for Pharmaceutical Engineering (ISPE). All rights reserved.)



of 198

PREFACE 46

TBA 47

48

49

50



of 198

ACKNOWLEDGEMENTS 51

TBA 52



of 198

TABLE OF CONTENTS 53

1 INTRODUCTION ............................................................... 7 54

1.1 OVERVIEW ............................................................... 7 55

1.2 PURPOSE ................................................................ 7 56

1.3 SCOPE .................................................................. 8 57

1.4 HOW TO USE THIS GUIDE .................................................. 9 58

2 GUIDING PRINCIPLES AND KEY CONCEPTS ....................................... 10 59

2.1 GUIDING PRINCIPLES .................................................... 10 60

2.2 KEY CONCEPTS .......................................................... 10 61

3 RISKS AND ACTIONS FOR ELECTRONIC RECORDS AND DATA INTEGRITY ............... 13 62

3.1 INTRODUCTION .......................................................... 13 63

3.2 IMMEDIATE ACTIONS ..................................................... 14 64

3.3 STRATEGIC ACTIONS ..................................................... 22 65

3.4 SYSTEM LIFE CYCLE ACTIONS ............................................. 23 66

3.5 KEY DATA LIFE CYCLE ACTIONS ........................................... 26 67

4 QUALITY RISK MANAGEMENT ................................................... 30 68

4.1 INTRODUCTION .......................................................... 30 69

4.2 STEP 1: IDENTIFY REGULATED DATA, RECORDS, AND SIGNATURES .............. 31 70

4.3 STEP 2: ASSESS IMPACT OF DATA AND RECORDS ............................. 32 71

4.4 STEP 3: ASSESS RISKS TO ELECTRONIC RECORDS BASED ON IMPACT ............ 36 72

4.5 STEP 4: IMPLEMENT CONTROLS TO MANAGE IDENTIFIED RISKS ................. 38 73

4.6 STEP 5: MONITOR EFFECTIVENESS OF CONTROLS ............................. 38 74

5 DATA LIFE CYCLE ........................................................... 40 75

5.1 INTRODUCTION .......................................................... 40 76

5.2 DATA CREATION AND CAPTURE ............................................. 40 77

5.3 DATA CALCULATION/PROCESSING ........................................... 41 78

5.4 RECORD REVIEW ......................................................... 42 79

5.5 RECORD ANALYSIS & REPORTING ........................................... 44 80

5.6 RECORD RETENTION AND ARCHIVAL ......................................... 46 81

5.7 MIGRATION ............................................................. 49 82

5.8 DESTRUCTION ........................................................... 52 83

6 DATA GOVERNANCE FRAMEWORK ................................................. 53 84

6.1 INTRODUCTION .......................................................... 53 85

6.2 OVERVIEW .............................................................. 53 86

6.3 ELEMENTS OF THE DATA INTEGRITY FRAMEWORK .............................. 54 87

6.4 HUMAN FACTORS IN DATA INTEGRITY ....................................... 60 88

6.5 DATA INTEGRITY MATURITY MODEL ......................................... 60 89

7 AUDIT TRAIL AND AUDIT TRAIL REVIEW ........................................ 66 90

7.1 INTRODUCTION .......................................................... 66 91

7.2 REGULATORY BACKGROUND ................................................. 66 92

7.3 APPLICATION AND USE OF AUDIT TRAILS ................................... 68 93

7.4 AUDIT TRAIL REVIEW .................................................... 69 94

8 GAMP 5 QUALITY RISK MANAGEMENT ............................................ 72 95

8.1 INTRODUCTION .......................................................... 72 96

8.2 OVERVIEW OF QUALITY RISK MANAGEMENT ................................... 72 97

8.3 QUALITY RISK MANAGEMENT PROCESS ....................................... 72 98

8.4 EXAMPLE FUNCTIONAL RISK ASSESSMENT APPROACH ........................... 74 99

8.5 RISK MANAGEMENT THROUGHOUT THE SYSTEM LIFE CYCLE ...................... 75 100

9 RISK CONTROL MEASURES FOR RECORD, DATA, AND SIGNATURE INTEGRITY ........... 77 101

9.1 INTRODUCTION .......................................................... 77 102

9.2 RECORD AND DATA CONTROLS .............................................. 77 103

9.3 IMPLEMENTATION OF CONTROLS ............................................ 78 104

9.4 RIGOR OF CONTROLS ..................................................... 86 105

9.5 SIGNATURE CONTROLS .................................................... 86 106

9.6 REGULATED COMPANY AND SUPPLIER RESPONSIBILITIES ....................... 87 107

9.7 PROCEDURAL REQUIREMENTS (RESPONSIBILITY OF REGULATED COMPANY) ......... 87 108

9.8 TECHNICAL REQUIREMENTS (LARGELY MET THROUGH SUPPLIER ACTIVITIES) ...... 89 109



of 198

10 RISKS RELATED TO RECORD RETENTION, ARCHIVING, AND MIGRATION ............. 90 110

10.1 INTRODUCTION .......................................................... 90 111

10.2 MANAGEMENT OF ELECTRONIC RECORDS ...................................... 90 112

10.3 HYBRID RECORDS AND ARCHIVES ........................................... 92 113

10.4 AUDIT TRAIL CONSIDERATIONS ............................................ 93 114

10.5 ALTERNATIVE SYSTEMS ................................................... 94 115

10.6 CONVERTING ELECTRONIC TO ALTERNATIVE FORMAT/MEDIA HYBRIDS ............. 94 116

10.7 EXAMPLES OF APPLICATION OF GAMP® 5 RISK ASSESSMENT TO RECORDS MANAGEMENT117

101 118

11 DATA INTEGRITY FOR END-USER APPLICATIONS ............................... 109 119

11.1 INTRODUCTION ......................................................... 109 120

11.2 DATA INTEGRITY FOR SPREADSHEETS ...................................... 109 121

11.3 DATA INTEGRITY FOR PC DATABASES ...................................... 110 122

11.4 DATA INTEGRITY FOR STATISTICAL TOOLS ................................. 111 123

12 EXAMPLES OF RECORDS AND SIGNATURES REQUIRED BY GXP REGULATIONS ......... 112 124

12.1 KEY DEFINITIONS ...................................................... 112 125

12.2 EXAMPLES FROM US REGULATIONS ......................................... 112 126

12.3 EXAMPLES FROM EU REGULATIONS ......................................... 123 127

12.4 EXAMPLES FROM ICH Q7 ................................................. 125 128

13 CASE STUDIES ........................................................... 126 129

13.1 SPREADSHEET FOR BATCH RELEASE CALCULATIONS BASED ON MANUAL INPUT OF LAB 130

DATA TO A TEMPLATE ......................................................... 126 131

13.2 AUTOMATED FORMULATION PRODUCTION & PACKING EQUIPMENT ................. 128 132

13.3 BUILDING MANAGEMENT SYSTEM (BMS) ..................................... 133 133

13.4 INTERACTIVE RESPONSE TECHNOLOGIES (IRT) .............................. 136 134

13.5 ENTERPRISE RECOURSE PLANNING (ERP) SYSTEM ............................ 139 135

13.6 DRUG SAFETY SYSTEM ................................................... 144 136

14 DATA INTEGRITY MATURITY LEVEL CHARACTERIZATION ......................... 146 137

14.1 INTRODUCTION ......................................................... 146 138

15 USER REQUIREMENTS ...................................................... 159 139

15.1 INTRODUCTION ......................................................... 159 140

15.2 TECHNICAL CONTROLS ................................................... 160 141

15.3 PROCEDURAL CONTROLS .................................................. 163 142

16 DATA INTEGRITY CONCERNS RELATED TO SYSTEM ARCHITECTURE ................. 165 143

16.1 DATA RESIDES ON A LOCAL HARD DISK .................................... 165 144

16.2 INTERNALLY MANAGED CENTRAL DATABASE .................................. 165 145

16.3 INTERNALLY MANAGED DISTRIBUTED DATA .................................. 166 146

16.4 CLOUD-BASED SOLUTIONS ................................................ 167 147

17 COMPUTERIZED SYSTEM LIFE CYCLE ......................................... 170 148

17.1 INTRODUCTION ......................................................... 170 149

17.2 COMPUTERIZED SYSTEM LIFE CYCLE ....................................... 170 150

17.3 SPECIFICATION AND VERIFICATION ....................................... 171 151

17.4 LIFE CYCLE PHASES .................................................... 172 152

18 CORPORATE DATA INTEGRITY PROGRAM ....................................... 178 153

18.1 INTRODUCTION ......................................................... 178 154

18.2 IS A DATA INTEGRITY PROGRAM REQUIRED? ................................ 178 155

18.3 INDICATORS OF PROGRAM SCOPE AND EFFORT ............................... 179 156

18.4 IMPLEMENTATION CONSIDERATIONS ........................................ 181 157

18.5 KEYS TO SUCCESS ...................................................... 182 158

18.6 SUMMARY .............................................................. 184 159

19 PAPER & HYBRID RECORDS ................................................. 185 160

19.1 CONTROLS ............................................................. 185 161

19.2 MANAGING RECORDS & SIGNATURES IN HYBRID SYSTEMS ...................... 185 162

19.3 RISK ASSESSMENT ...................................................... 185 163

19.4 CONTROLS FOR MANAGING RECORDS & SIGNATURES IN HYBRID SYSTEMS ......... 186 164

19.5 USE OF FORMS TO ENFORCE PROCEDURES ................................... 187 165

19.6 ISSUES WITH HYBRID RECORDS IN PRODUCTION AND LABORATORY .............. 188 166

20 PROCESS MAPPING/INTERFACES ............................................. 190 167



of 198

20.1 INTRODUCTION ......................................................... 190 168

20.2 PROCESS (BUSINESS) FLOWCHARTS ........................................ 190 169

20.3 DATA FLOWCHARTS ...................................................... 192 170

20.4 HOW MUCH IS NEEDED? .................................................. 193 171

20.5 CONCLUSION ........................................................... 193 172

21 INSPECTION READINESS ................................................... 194 173

21.1 INTRODUCTION & GENERAL PROCEDURES .................................... 194 174

21.2 KEY INFORMATION THAT NEEDS TO BE MAINTAINED FOR REGULATORY INSPECTIONS – 175

RIGHT PEOPLE AND RIGHT INFORMATION ......................................... 195 176

22 GLOSSARY ............................................................... 198 177

23 REFERENCES ............................................................. 198 178

179



of 198

1 INTRODUCTION 180

181

1.1 OVERVIEW 182

This GAMP Good Practice Guide: Electronic Records and Data Integrity provides 183

practical guidance on meeting current regulatory expectations for the management 184

of electronic records and the data underlying them, which includes the need for 185

integrity, security, and availability throughout the required retention period. 186

It describes how a risk management approach may be used to ensure the compliance 187

of regulated electronic records and signatures, including managing risks to 188

integrity of underlying data, through the application of appropriate controls 189

commensurate with the identified risks. 190

191

This Guide has been developed by the GAMP Community of Practice (CoP) of ISPE, 192

and is intended to complement GAMP 5 - A Risk-Based Approach to Compliant GxP 193

Computerized Systems. It has been designed so that it may be used in conjunction 194

with guidance provided in GAMP 5 and other GAMP Good Practice Guides. 195

196

Collaborating with regulators and industry experts, GAMP promotes the innovative 197

use of automation and computer technology in a risk-based approach that safeguards 198

patient safety, product quality, and data integrity. 199

200

1.2 PURPOSE 201

Since the publication of the GAMP Good Practice Guide, A Risk-Based Approach to 202

Compliant Electronic Records and Signatures in 2005, the social, technical, and 203

regulatory landscape has changed: 204

205

Increased regulatory focus on the wider aspects of data integrity, including 206

publication of specific regulatory guidance on the topic and increased 207

number of citations in the area. 208

209

The increased public and regulatory acceptance and understanding of 210

electronic signatures as being the legally binding equivalent of traditional 211

handwritten signatures, and increased use of electronic transactions in 212

daily life. 213

214

Technical developments such as the increased adoption of cloud computing 215

models. 216

217

The enhanced Quality Risk Management and Specification and Verification 218

approach as defined in GAMP 5. 219

220

The revision of EU GMP Annex 11 and EU GMP Chapter 4 (both adopted for wider 221

use by PIC/S). 222

223

This Guide provides comprehensive and up-to-date guidance to meet these changes. 224

Electronic record and data integrity is achieved by well-documented, validated 225

systems, and the application of appropriate controls through both the system and 226

data life cycles. 227

228

The approach allows measures aimed at a high degree of integrity, availability, 229

and confidentiality (where required) to be established for records that have a 230

high potential impact on product quality or patient safety, while permitting a 231

less rigorous approach for records of lower impact, or those with lower levels of 232

associated risk. 233

234

This overall philosophy is intended to encourage innovation and technological 235



of 198

advance while avoiding unacceptable risk to product quality, patient safety, and 236

public health. 237

238

The guidance is intended for regulated companies and suppliers of any systems, 239

products, or services in this area, as well as a useful reference for regulators. 240

241

Some familiarity with current international regulations is assumed. 242

243

1.3 SCOPE 244

This Guide addresses the integrity of all regulated data, records, and signatures 245

managed by computerized systems used within the regulated life science industries 246

including pharmaceutical, biological, and medical devices. This Guide may also be 247

useful in other regulated areas such as cosmetics and food. 248

Current international GxP life science requirements related to electronic records 249

and data integrity have been taken into account, and the following publications 250

have been specifically considered: 251

252

US Codes of Federal Regulations (CFRs) covering GCP, GLP, GMP, and medical 253

devices 254

255

US CFR regulation 21 CFR Part 11, and associated guidance 256

257

Relevant sections of EU and PIC/S regulations, including Chapter 4 and Annex 258

11 259

260

MHRA GMP Data Integrity Definitions and Guidance for Industry 261

262

FDA - Data Integrity and Compliance With CGMP - Draft Guidance for Industry 263

264

ICH Q9 Quality Risk Management 265

266

ICH Q10 Pharmaceutical Quality System 267

268

Draft WHO Guidance on Good Data and Record Management Practices 269

270

This Guide covers regulated electronic records, electronic signatures, handwritten 271

signatures captured electronically, and handwritten signatures applied to 272

electronic records. This Guide also addresses the need for integrity of the 273

underlying data. 274

275

While paper, electronic and hybrid situations are considered, the focus is on 276

electronic aspects, and the Guide encourages a move away from hybrid solutions 277

wherever practical. 278

279

This Guide provides a method for managing risk to electronic data, records 280

and signatures. Organizations may already have established risk management 281

activities and tools, and this Guide does not intend or imply that these 282

existing methods should be discarded, rather that they continue to be used 283

as appropriate within the context of the overall risk management process 284

described. 285

286

Note that this Guide provides a pragmatic approach to managing risk. Other methods 287

or techniques giving documented evidence of adequate control, and ensuring 288

appropriate security and integrity, may also be acceptable. 289

290

The Guide is equally relevant to both new and existing computerized systems. While 291



of 198

not within the scope of this Guide, it is recognized that aspects such as business 292

criticality, health and safety, and environmental requirements may require 293

specific assessment and control. Legal admissibility of information stored 294

electronically should also be considered. 295

296

1.4 HOW TO USE THIS GUIDE 297

The Guide contains this Introduction, a Main Body, and a set of appendices. It 298

has been structured to meet the needs of various readers, and contains, in 299

increasing level of detail: 300

301

1. Critical areas of regulatory focus and concern 302

2. An overview of risks to record and data integrity, and a high level overview 303

of how to address them 304

3. Further information on how to apply the GAMP® 5 life cycle and Quality Risk 305

Management (QRM) approach to electronic record and data integrity 306

4. More detailed “how to” guidance for specific topics 307

5. Example case studies 308

Readers requiring an overview of the topic should read this Introduction, plus 309

Section 2, Guiding Principles and Key Concepts, and Section 3, Risks and Actions 310

for Electronic Records and Data Integrity. 311

312

Readers seeking further information on the overall approach to ensuring electronic 313

record and data integrity should also read the remaining sections of the main 314

body. 315

316

Readers requiring detailed information on particular topics should also consider 317

the applicable appendices, based on their areas of interest and responsibility. 318

All readers may find the example case studies in Appendix x useful when applying 319

the guidance provided to specific situations. The case studies reflect a wide 320

variety of typical regulated systems. 321

322

Appendix X proves references and Appendix y contains a Glossary. 323

324



of 198

325

2 GUIDING PRINCIPLES AND KEY CONCEPTS 326

327

2.1 GUIDING PRINCIPLES 328

Risk management practices for electronic record and data integrity controls must 329

protect public health. In order to be effective, however, risk management 330

practices must also be practical and efficient. To this end the following guiding 331

principles have been adopted for this Guide: 332

Provide a consistent and sufficiently flexible risk management approach to 333

address all relevant international regulatory expectations 334

Leverage and support other wider industry activity in field of data 335

integrity 336

Adopt the philosophy of managing risk by generally accepted good practice 337

to address electronic records and data integrity 338

Ensure the risk management approach to electronic records and data integrity 339

is simple and effective. The effort required to assess and manage risk must 340

be proportionate to the level of risk 341

Provide interpretation of key international regulations and guidance on this 342

topic 343

Focus on records and data with significant potential impact on product 344

quality and/or patient safety. 345

Emphasize the benefits, and encourage the use of technology, rather than 346

introduce unnecessary barriers to technological advance. 347

348

2.2 KEY CONCEPTS 349

(1) Definitions and Scope 350

The term GxP regulation refers to the underlying international life science 351

requirements such as those set forth in the US FD&C Act, US PHS Act, FDA 352

regulations, EU Directives, Japanese MHLW regulations, adopted PIC/S GMP Guides, 353

or other applicable national legislation or regulations under which a regulated 354

company operates. 355

A regulated record is a record required to be maintained or submitted by GxP 356

regulations. A regulated record may be held in different formats, for example, 357

electronic, paper, or both. 358

A regulated electronic record is a regulated record maintained in electronic 359

format. A regulated electronic record is a collection of regulated data (and 360

metadata necessary to provide meaning and context) with specific GxP purpose, 361

content, and meaning. 362

Regulated electronic records include, but are not limited to Part 11 records as 363

defined by US FDA (Appendix X of this Guide provides examples of records required 364

by GxP regulations). 365

366

Note that that there may be records required to support regulated activities, 367

despite them not being explicitly identified in the regulations. 368

A regulated signature is a signature required by a GxP regulation. Regulated 369

signatures include signatures that document the fact that certain events actions 370

occurred in accordance with the GxP regulation rule (e.g. approval, review or 371

verification of a regulated record). 372

A regulated electronic signature is a signature applied electronically to a 373

regulated electronic record, and intended to be the equivalent of a handwritten 374

signature required by a GxP regulation. 375

By the application of a signature, the status of a record is changed. Signatures 376



of 198

should be clearly distinguished from identification events (that may also be 377

required by regulations) where the requirement is only for the identification of 378

an individual performing a particular activity. This may, for instance, be 379

achieved by logging of an event in an audit trail by a validated computerized 380

system. 381

Signatures are often implemented by a unique user-id and password combination. 382

Other uses of user-ids and password, such as logging on to a system, should be 383

clearly distinguished from signature events. 384

Signatures not required by predicate rules, and other superficially similar cases 385

such as identification of individuals, acknowledgement of steps or actions, or 386

logging-on to a system, are not regulated signatures. 387

388

389

390

391

392 Figure 1-1. Narrow Scope and the need for underlying data integrity. 393

394

As shown in Figure 1-1, GxP data is a subset of all data maintained by a regulated 395

company. Data integrity requirements apply to all regulated (GxP) data. Regulated 396

electronic records are collections of regulated data and metadata with a specific 397

GxP purpose, content, and meaning. Electronic signatures may be applied to some 398

regulated electronic records, and paper signatures may be applied to others (a 399

hybrid situation). 400

Some regulations (e.g. 21 CFR Part 11) apply specifically to regulated electronic 401

records and regulated signatures. Wider data integrity controls must be in place 402

to ensure the accuracy and reliability of such record content. 403

404

(2) Data Governance 405

Data governance ensures formal management of records and data throughout the 406

regulated company. Data governance encompasses the people, processes, and 407

technology required to achieve consistent, accurate and effective data handling. 408

It provides the structure within which appropriate decisions regarding data-409

related matters may be made according to agreed models, principles, processes, 410

and defined authority. Data governance may also be considered as a quality 411

assurance and control approach for applying rigor and discipline to the process 412



of 198

of managing, using, protecting, and improving organizational information. 413

414

(3) Quality Risk Management 415

The Quality Risk Management (QRM) approach defined in GAMP 5, following ICH Q9, 416

will be applied to identifying, assessing, and managing risks to data and record 417

integrity. Section 4 provides details of the approach, including some definitions 418

specific to QRM. 419

420

(4) System Life Cycle 421

A system life cycle approach, as described in GAMP 5 is applied. Data and record 422

integrity must be built in and maintained throughout the system life cycle phases 423

from concept through project and operations to retirement. 424

The system life cycle activities should be scaled based on the complexity and 425

novelty, of the system, and potential impact on product quality, patient safety 426

and data integrity. 427

428

(5) Data Life Cycle Approach 429

As well as the system life cycle, the data life cycle is also considered. All 430

phases in data life cycle from initial data creation and capture recording through 431

processing (including transformation or migration), review, reporting, retention, 432

retrieval and destruction must be controlled and managed in order to ensure 433

accurate, reliable, and compliant electronic records and data. 434

435

(6) Process Understanding 436

A full understanding of the business process(es) to be supported, including the 437

intended user-base and intended use of data and records within the process, is 438

fundamental to accurately determining electronic record and data integrity 439

requirements. As described in GAMP 5, thorough process understanding is also the 440

basis for quality risk management. 441

442

As noted in the GAMP Good Practice Guide: A Risk-Based Approach to GxP Compliant 443

Laboratory Computerized System, [ref] data integrity cannot be achieved without 444

a complete understanding of the information flow. 445

446

(7) Leveraging Supplier Involvement 447

As described in GAMP 5, regulated companies should seek to leverage supplier 448

knowledge, experience, and documentation throughout the system life cycle, subject 449

to satisfactory supplier assessment. For example, suppliers may assist with 450

clarifying technology limitations, gathering requirements, defining and assessing 451

risks, identifying appropriate technical or procedural controls, developing 452

technical controls, verifying controls, and monitoring the effectiveness of 453

controls. The supplier may also an impact on the way the data is managed through 454

the entire data life cycle. 455

456

Planning should determine how best to use supplier documentation and expertise, 457

including existing test documentation, to avoid wasted effort and duplication. 458

Justification for the use of supplier documentation should be provided by the 459

satisfactory outcome of supplier assessments, which may include supplier audits. 460

461



of 198

3 RISKS AND ACTIONS FOR ELECTRONIC RECORDS AND DATA 462

INTEGRITY 463

464

3.1 INTRODUCTION 465

During recent regulatory inspections, the following have emerged as specific areas 466

of regulatory focus and concern: 467

468

Lack of basic access control and security measures allowing unauthorized 469

changes 470

Shared user logins 471

Lack of contemporaneous recording of activities 472

Failure to investigate data discrepancies 473

Testing into compliance 474

Incomplete collection, retention, and review of data for quality decisions 475

Overwriting or deletion of raw data 476

Missing or disabled audit trails 477

478

These regulatory focus areas are reflected and discussed in this section, where 479

key aspects and risks related to records and data integrity are covered in more 480

detail. 481

482

It is recognised that introducing comprehensive electronic record and data 483

integrity controls across an organization may involve cultural and behavioural 484

shifts, requiring a focused corporate data integrity programme over a period of 485

time, such that appropriate controls are built in to a data governance framework, 486

embedded in the wider Quality Management System. 487

488

This section identifies the most important aspects that all regulated 489

organizations should consider, and highlights areas that should be investigated 490

and actioned immediately, as a series of tables: 491

492

Immediate Actions 493

Strategic Actions 494

System Life Cycle Actions 495

Data Life Cycle Actions 496



of 198

497 Figure 3.1: Action Tables 498

499

The section also describes an initial management activity to assess the current 500

situation and identify primary gaps, before embarking on a strategic program, or 501

the application of specific controls. This is achieved through use of a Critical 502

Issues Executive Dashboard, providing a visual representation that provides 503

executives with a quick and easy way to view performance against requirements. 504

505

506

3.2 IMMEDIATE ACTIONS 507

Immediate analysis and action in the following critical areas will give 508

organizations the opportunity to quickly address and significantly improve 509

electronic record and data integrity (“quick wins”). Taking early action should 510

provide an immediate improvement to the compliance status of computerised systems 511

and associated processes. Longer term data integrity programmes to ensure full 512

compliance will still be needed. 513

514

Topic Immediate Actions For More

Information

Access

Control Ensure user access management process is

established and in operation.

Ensure basic access controls are established

(e.g. unique usernames and private password).

Ensure appropriate segregation of duties, i.e.

ensuring that users with elevated privileges do

not have vested interest in data (i.e. are

independent of the business process).

Limit use of administrator accounts to those

required to perform their duties.

Avoid shared logins and generic accounts.

Section

3.2.1

Appendix Y



of 198

Topic Immediate Actions For More

Information

Data

Security Ensure GxP data and records (including hybrid

records) are not held in unsecured areas.

Establish controls to prevent the unauthorized

deletion or modification of regulated data and

records inside or outside the software

application (e.g. limiting user rights).

Section

3.2.1

Appendix Y

Audit Trail Ensure appropriate audit trail functionality is

available, enabled, and verified, based on risk.

Section

3.2.1

Appendix Y

515



of 198

3.2.1 Critical Issues Executive Dashboard 516

For critical areas of regulatory focus and concern management should assess the current situation and identify 517

primary gaps. The following dashboard allows an initial baseline to be established, as a key input to subsequent 518

strategic programmes, and to highlight where specific controls are required. Efforts to address any gaps identified 519

should be prioritised based on the criticality of GxP functionality impacted and the medical benefit of the 520

associated pharmaceutical products being supported. 521

522

523

Critical

Issue Sample Regulatory Requirement Red Amber Green

1. Lack of basic

access control

and security

measures

allowing

unauthorized

changes

21 CFR 11.10 (d) Limiting system

access to authorized individuals.

Annex 11 12.1 Physical and/or

logical controls should be in place

to restrict access to computerised

systems to authorised persons.

21 CFR 211.68 (b) Appropriate

controls shall be exercised over

computer or related systems to

assure those changes in master

production and control records or

other records are instituted only

by authorized personnel.

Basic access

control missing in

many cases.

Lack of

appropriate

controls to assure

that changes in

regulated records

and data are made

only by authorized

personnel.

Established

standards and

procedures for

security and

access control,

but not

consistently

applied, and not

regularly

reviewed.

Established

systems for

consistent access

control and

security

management,

including regular

review of access

rights, security

breaches and

incidents

2. Shared user

logins

MHRA Data Integrity Definitions and

Guidance: Shared logins or generic

user access should not be used.

Where the computerised system

design supports individual user

access, this function must be used.

FDA Data Integrity and Compliance

With CGMP Draft Guidance for

Industry: When login credentials

are shared, a unique individual

cannot be identified through the

login and the system would thus not

conform to the CGMP requirements in

parts 211 and 212.

Widespread use of

shared user

logins. Lack of

understanding of

potential risk and

issues

Policies in place

forbidding shared

user logins, but

not consistently

applied, and not

regularly

reviewed

Shared user logins

forbidden, and not

used except in

rare, documented,

and justified

cases. Periodic

reviews verify

adherence to

policy.



of 198

Critical


3. Lack of

contemporaneous

recording of

activities

EU / PIC/S GMP 4.8 Records should

be made or completed at the time

each action is taken and in such a

way that all significant activities

concerning the manufacture of

medicinal products are traceable.

21 CFR 211.100 (b) Written

production and process control

procedures shall be followed in the

execution of the various production

and process control functions and

shall be documented at the time of

performance.

21 CFR 211.160 (a) …The requirements

in this subpart shall be followed

and shall be documented at the time

of performance.

Widespread

examples of

activities not

recorded at the

time of

performance, or

pre-dating or

backdating of

records. Low

awareness of

requirement for

contemporaneous

recording.

Policies in place

regarding

contemporaneous

recording, for

both paper and

electronic

records, but not

consistently

applied, and not

consistently

checked or

assessed during

normal record

review by the

operational unit

Good awareness and

adherence to

policies regarding

contemporaneous

recording, for

both paper and

electronic

records, supported

by validated

technical system

controls and

appropriate

procedural

controls.

Consistently

checked during

normal operational

record review.

4. Failure to

investigate data

discrepancies

21 CFR 211.192 Production record

review … Any unexplained

discrepancy … or the failure of a

batch or any of its components to

meet any of its specifications shall

be thoroughly investigated…

EU / PIC/S GMP , Chapter 1.9 (vi)

Records are made of the results of

inspection and that testing of

materials,

Intermediate, bulk, and finished

products is formally assessed

against specification. Product

assessment includes a review and

evaluation of relevant

production documentation and an

assessment of deviations from

specified procedures;

Widespread

examples of

discrepancies not

being

investigated. Low

awareness of

requirement to

investigate data

discrepancies

Policies in place

regarding

investigating

data

discrepancies but

not consistently

performed, and

some cases where

relevant

production and

laboratory data

excluded from

investigations

Investigation of

data discrepancies

routinely and

thoroughly

performed and

fully documented,

with due

consideration of

all relevant data.



of 198

Critical


5. Testing into

compliance



Industry: FDA prohibits sampling

and testing with the goal of

achieving a specific result or to

overcome an unacceptable result

(e.g., testing different samples

until the desired passing result is

obtained). This practice, also

referred to as testing into

compliance, is not consistent with

CGMP… We would consider it a

violative practice to use an actual

sample in test, prep, or

equilibration runs as a means of

disguising testing into compliance.

Widespread

examples of

testing into

compliance. Low

awareness of

unacceptability of

such practices.

Policies in place

regarding testing

into compliance,

but with some

examples of bad

practice.

Good awareness and

adherence to

policies

prohibiting

testing into

compliance,

supported by

management

behaviour,

validated

technical system

controls and

appropriate

procedural

controls.



of 198

Critical


6. Incomplete

collection,

retention, and

review of data

for quality

decisions

21 CFR 211.194 Laboratory records.

(a) Laboratory records shall

include complete data derived from

all tests necessary to assure

compliance with established

specifications and standards,

including examinations and assays…



Industry: Any data created as part

of a CGMP record must be evaluated

by the quality unit as part of

release criteria…To exclude data

from the release criteria decision-

making process, there must be a

valid, documented, scientific

justification for its exclusion.

EU / PIC/S GMP, Chapter 1.8 (viii)

Records of manufacture including

distribution which enable the

complete history of a batch to be

traced are retained in a

comprehensible and accessible form

Quality decisions

often taken on

incomplete data,

or incomplete

review of that

data. Lack of

appropriate

policies and

procedures on this

topic

Policies in place

regarding

investigating

data collection,

retention, and

review, but not

consistently

applied. Some

cases of missing

data.

Quality decisions

based on complete

and accurate data,

consistently

ensuring

compliance with

established

specifications and

standards.



of 198

Critical


7. Overwriting or

deletion of raw

data

21 CFR 211.194 Laboratory records.

(a) Laboratory records shall

include complete data derived from

all tests necessary to assure

compliance with established

specifications and standards,

including examinations and assays…

EU / PIC/S GMP Chapter 4 … Records

include the raw data which is used

to generate other records. For

electronic records regulated users

should define which data are to be

used as raw data. At least, all data

on which quality decisions are based

should be defined as raw data

Widespread

examples of

overwriting or

deletion of raw

data. Low

awareness of

unacceptability of

such practices.

Policies in place

regarding the

retention and

protection of raw

data, but not

consistently

applied. Some

cases of missing

data.

Quality decisions

based on complete

and accurate data,

consistently

ensuring

compliance with

established

specifications and

standards.



of 198

Critical


8. Missing or

disabled audit

trails

21 CFR 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…

EU / PIC/S Annex 11 (9)

Consideration should be given,

based on a risk assessment, to

building into the system the

creation of a record of all GMP-

relevant changes and deletions (a

system generated "audit trail").

For change or deletion of GMP-

relevant data the reason should be

documented. Audit trails need to be

available and convertible to a

generally intelligible form and

regularly reviewed.

Widespread

examples of

missing or

disabled audit

trail. Low

awareness of

unacceptability of

such practices.

Audit trail in

place for most

regulated

systems, but with

undefined and

inconsistent use

within business

processes.

Sometimes

incomplete or not

fit for purpose

(e.g. in content

and

reviewability).

Effective audit

trail in place for

all regulated

systems, and use

and review of audit

trail included in

established

business

processes.

524



of 198

3.3 STRATEGIC ACTIONS 525

Electronic record and data integrity will only be successfully established if 526

certain key strategic considerations are addressed by the organization. Table 527

x.x below highlights these topics, which are pre-requisites to the success of 528

longer term Data Governance. Some companies may want to initiate a Data 529

Integrity Programme to provide overall coordination of activities being 530

undertaken by the organisation. 531

532

533

Topic Strategic Actions For More

Information

Data

Governance Establish a Data Governance framework as an

integral part of the Quality Management System

Establish Data Integrity policy

Ensure senior management understanding and

commitment

Ensure good awareness within the organization

Establish need for data ownership and define

roles and responsibilities

Measure effectiveness

Section 6

Appendix Y

Regulatory

Compliance

Understand the regulatory requirements that apply.

Companies that operate across multiple

jurisdictions need to consider potential conflicts

between local laws and regulations and understand

the aggregate requirements to be applied.

Section 6.2

Appendix Y

System Life

Cycle

Establish a system life cycle that is scalable

according to:

system impact on patient safety, product

quality and data integrity

system complexity and novelty

outcome of supplier assessments

Ensure System Life Cycle addresses electronic

record and data integrity requirements at the

appropriate time, so that effective technical,

procedural and behavioral controls are

established. For example:

identification and understanding of business

process

electronic records and electronic signatures

are identified

raw data to be retained is identified

assessment, management and leverage of

supplier and service suppliers

Section 3.4

Data Life

Cycle

Establish Data Life Cycle covering creation and

capture, processing, reporting, retention and

retrieval, and destruction. Ensure the data is

attributable, legible, contemporaneously

recorded, original and accurate (ALCOA), complete,

consistent, enduring, and available (ALCOA+).

Section 3.5,

5

Appendix Y

ISPE DRAFT © 2016



of 198

Topic Strategic Actions For More

Information

Ensure that:

production and process control functions are

recorded at time of performance

complete data is captured, retained and

available for inspection

all relevant data is considered when taking

release decisions

data discrepancies and failures within the

business process are investigated

procedural controls are established for manual

operations on electronic records (e.g. SOP on

manual integration in chromatography)

Quality

Risk

Management

Ensure Quality Risk Management is applied to the

management of electronic record and data

integrity, for example:

when determining the need for, extent of, and

use of, audit trail functionality

when planning the verification and testing of

procedural and technical controls

when establishing operational processes, such

as backup and restore, archiving, disaster

recovery

Section 4

Appendix Y

534

3.4 SYSTEM LIFE CYCLE ACTIONS 535

The following tables provide a list of key actions related to management of 536

electronic records and data integrity throughout the system life cycle. This 537

table also refers to other sections and appendices within the Guide that provide 538

further guidance on these topics. 539

540

3.4.1 Concept Phase 541

Topic Concept Phase Actions For More

Information

Goals and

objectives

Establish clear data integrity goals and objectives

– begin with the end in mind.

Section X

Appendix Y

Process

understandi

ng

An understanding of the business process is

required, including data flow and (critical)

records.

Section X

Appendix Y

Initial risk

assessment

An initial (process risk) assessment should be

conducted to identify process level data integrity

risks.

Section X

Appendix Y

542

3.4.2 Project Phase 543

Topic Project Phase Actions For More

Information

Project

steering

committee

A project steering committee is needed that

understands the business process, regulatory

requirements and expectations and has authority

to make decisions and to drive them to completion.

Section X

Appendix Y



of 198


Information

Project team Product and process understanding is critical to

the success of the project. Effort should be made

to ensure a cross-functional team is created with

appropriate knowledge of the business process and

regulatory requirements and expectations,

including process SMEs, quality and regulatory

SMEs, and technical SMEs.

Team member training should include electronic

records, electronic signatures and data integrity

requirements, as appropriate to the system.

Section X

Appendix Y

Project

change

management

Changes made during the project phase need to be

reviewed for their impact on the business process

and/or data integrity. Approval for change should

be sought from the process owner and/or data

owner, as appropriate.

Section X

Appendix Y

User

Requirements

Requirements for electronic records, electronic

signatures and data integrity should be

established and be based on a documented risk

assessment and include GxP impact.

Appropriate controls should be identified

(technical and/or procedural).

Record and data integrity requirements should be

defined and documented (e.g. in a URS).

Requirements should include all relevant process

(predicate) requirements, and any specific

regulatory requirements relevant to data and

record integrity.

Section X

Appendix Y

System

Architecture

The choice of system architecture can affect data

integrity and the implications should be assessed.

Architecture can also have an effect on

operational needs such as backup and recovery,

business continuity, downtime for service or

upgrade, etc.

SaaS or PaaS approaches delegate varying degrees

of responsibility to suppliers, but also limit the

degree of control that a user company has relating

to control of data and changes.

Section X

Appendix Y

Supplier

Assessment &

Management

The need to assess suppliers should be based on a

documented risk assessment.

Supplier should be assessed for their

understanding of regulatory requirements and

expectations for electronic records and data

integrity.

Section X

Appendix Y

Validation Systems should be validated for intended use and

to assure data integrity.

Extent of validation for intended use and data

integrity controls should be based on a documented

and justified risk assessment. Risk assessments

should be conducted at appropriate points such as

business process, user requirements, and system

Section X

Appendix Y ISPE D

RAFT © 20

16



of 198


Information

levels.

The business workflow, including data flow and

(critical) records should be defined. The risk

points and mitigation controls (both technical and

procedural) should be identified and validated.

Appropriate test methods and test scenarios should

also challenge user access accounts/segregation

of duties, error handling, parameter and data

limits.

Regulatory A thorough understanding of applicable laws and

regulations is necessary for delivering a

compliant solution. While conflicts between GxP

regulations are unlikely, conflict between GxP

requirements and other national laws are possible.

For example, a privacy law requiring deletion of

all personal data when an employee leaves a firm

may conflict with a GxP expectation to retain a

training record. Such conflicts need to be

resolved by Legal and QA authorities and the

decision documented.

Section X

Appendix Y

Data

Management

planning

Data retention requirements should be

established. Where computerized systems span

counties/regions, different retention periods may

apply. The legal department, and if it is a GxP

record, QA should be involved in discussion of

such issues.

Such conflicts need to be recognized during

requirements gathering so that business rules for

managing the data can be designed.

Section X

Appendix Y

544

3.4.3 Operations Phase 545

Topic Operations Phase Actions For More

Information

Support A support model should be established, including

training on the requirements for electronic

records and data integrity.

Section X

Appendix Y

Change and

configuration

management

Changes to the computerized system should be

executed in a controlled manner in accordance

with a documented procedure. Any changes to the

business processes or data requirements should

be approved by the process owner and data owner

respectively.

Section X

Appendix Y

Incident

management

All incidents should be reported and assessed,

including system failures and data errors. The

root cause of critical incidents should be

identified with appropriate corrective and

preventive actions.

Section X

Appendix Y

Security

Management

Access to the computerized system and data

storage areas should be restricted to authorized

persons. Physical and/or logical controls should

be established, with the extent of security based

Section X

Appendix Y

ISPE D

RAFT © 20

16



of 198

Topic Operations Phase Actions For More

Information

on the criticality of the computerized system.

Prevention of unauthorized entry may include, but

not limited to, the use of keys, pass cards,

personal codes with passwords, biometrics.

Backup &

Recovery

Regular backup of data should be executed, with

the frequency based on criticality of data.

Integrity and accuracy of backup data and the

ability to restore should be monitored

periodically.

Section X

Appendix Y

Business

continuity

In the event of a breakdown, provision should be

made to ensure the continuity of support for

those computerized systems supporting critical

processes (manual or alternative system).

The time required to bring the alternative

arrangements into use should be based on risk and

appropriate for a particular system and the

business process it supports. These arrangements

should be adequately documented and tested.

Section X

Appendix Y

546

3.4.4 Retirement Phase 547

Topic Retirement Phase Actions For More

Information

Planning Retirement planning needs to consider the

requirement for data migration and/or data

archiving. Verification of migration and/or

archiving should include checks that data are not

altered in value and/or meaning, and that the data

can still be retrieved in the required manner.

Section X

Appendix Y

548

3.5 KEY DATA LIFE CYCLE ACTIONS 549

Data life cycle phases may vary based on individual company implementation, but 550

should cover: 551

552

• Creation and Capture 553

• Processing 554

• Review and Reporting 555

• Retention and Retrieval 556

• Destruction 557

558

The following tables list the actions related to these phases. The tables also 559

refer to other sections and appendices within the Guide that provide further 560

guidance on these topics. 561

562

3.5.1 Data Creation and Capture 563

Topic Data Creation and Capture Phase Actions For More

Information

General Data should be created, modified or deleted so

that it is uniquely identified with the individual

who performed the action.

Section 5.2

Appendix Y



of 198

Topic Data Creation and Capture Phase Actions For More

Information

Data

verification

Identify the need for a second person to verify

data entry.

Section 5.2

Appendix Y

Data capture Ensure that data is captured and saved at the time

of the activity and prior to proceeding to the

next activity in the process.

Section 5.2

Appendix Y

Audit trail The use of secure, time-stamped audit trails that

independently record operator actions based on the

need to comply with predicate rule requirements,

a justified and documented risk assessment, and a

determination of the potential effect on product

quality and data integrity.

Section 5.2

Appendix Y

Time stamp Ensure that time and date stamps used are

unambiguous within the context of their use and

cannot be changed by system users.

Section 5.2

Appendix Y

564

3.5.2 Data Processing 565

Topic Data Processing Phase Actions For More

Information

Access

control

Ensure adequate access control procedures are

established to prevent unauthorized access to and

processing of data:

• limit access to system administrators

privileges only to persons independent of

those responsible for the content of the

electronic records

Ensure adequate controls to prevent the

overwriting of data

Section 5.3

Appendix Y

Displays

and

printouts

Ensure that regulated data in displays and paper

printouts is not obscured, for example by the

inappropriate use of annotation tools.

Section 5.3

Appendix Y

566

3.5.3 Data Review and Reporting 567

Topic Data Review and Reporting Phase Actions For More

Information

Original

records

The original records requiring review should be

defined.

Section 5.4,

5.5

Appendix Y

Review

process

The review process should be documented. Section 5.4,

5.5

Appendix Y

Review

approval

The method of indicating the review and approval

of electronic records should be defined, for

example by use of an electronic signature.

Procedures for data review should clarify the

meaning of the review and approval signatures to

ensure persons understand their responsibility as

reviewers and approvers.

Section 5.4,

5.5

Appendix Y

Errors and

omissions

The procedure for handling errors or omissions

identified during data review should be defined.

Section 5.4,

5.5

ISPE D

RAFT © 20

16



of 198

Topic Data Review and Reporting Phase Actions For More

Information

This procedure should enable data corrections or

clarifications to be made in a GxP compliant

manner.

Appendix Y

568

3.5.4 Data Retention and Retrieval 569

Topic Data Retention and Retrieval Phase Actions For More

Information

Retention

periods

Minimum retention periods for data should be

defined.

Section 5.6

Appendix Y

Location Data should be stored in geographical locations

that have adequate protections for personal

data or intellectual property.

Section 5.6

Appendix Y

Metadata Data and associated metadata such as audit

trails to be retained should be defined.

Section 5.6

Appendix Y

Copies Copies of records (including those made for

archival purposes) should preserve the content

and meaning of the record, and continue meet

relevant GxP regulatory requirements

(predicate requirements).

Section 5.6

Appendix Y

Backup and

restore

Ensuring adequate backup of data to allow

retrieval and recovery.

Section 5.6

Appendix Y

Data encryption Use of encryption to secure data. Section 5.6

Appendix Y

Synchronization There may be synchronization issues where the

system architecture involves storing data on

multiple servers (e.g. to distribute processing

load and or to facilitate business continuity).

Clear business processes should be established

when synchronization is not performed in real-

time.

Section 5.6

Appendix Y

Archival Archiving of data should be planned such that

required associated metadata is either archived

with, or is traceable to, the data set.

Section 5.6

Appendix Y

Retrieval The ability to retrieve archived data and

associated relevant metadata throughout the

required retention period should be verified.

Section 5.6

Appendix Y

570

3.5.5 Data Destruction 571

Topic Destruction Phase Actions For More

Information

Legal Data destruction needs to account for all local

laws, for all locations that reference the data.

It may be the case that retention requirements

differ by jurisdiction, or that there is a

litigation hold on some data in some countries.

On rare occasions there may be conflict between

applicable laws.

Section 5.8

Appendix Y

Verification Destruction should not occur without verification Section 5.8

ISPE D

RAFT © 20

16



of 198

Topic Destruction Phase Actions For More

Information

that the record is not in a hold status to support

litigation. When a record is destroyed,

distributed copies should also be destroyed.

Appendix Y

572

573



of 198

4 QUALITY RISK MANAGEMENT 574

575


Risks to data and record integrity should be identified and managed along with 577

other quality and safety risks by adopting a risk management approach based on 578

an understanding of the process. 579

580

GAMP 5 describes a five step approach for Quality Risk Management, based on ICH 581

Q9 [ref]. This approach can be applied to data and record integrity risks, as 582

shown in Figure 2-1. 583

584

Figure 2-1: Managing Risks to Electronic Records 585

586 Managing risks to electronic data, records, and signatures involves the 587

following activities: 588

589

Identifying which regulated data and records are maintained in the system 590

and where signatures are applied to those records, based on an analysis 591

of the processes, and the applicable regulations. 592

Assessing the impact of the data and records on product quality or patient 593

safety. 594

Assessing the risks to the data and records (i.e. identifying the 595

vulnerabilities) using a scaleable approach based on the impact of the 596

data and records. 597

Implementing controls to manage the identified risks, and verifying that 598

the controls have been successfully implemented. 599

Monitoring the effectiveness of controls during operation. 600

The objective of these activities is to reduce risks to product quality or 601

patient safety to an acceptable level and to comply fully with GxP regulations. 602

603

Where appropriate, during development of User Requirements and then Functional 604



of 198

Specifications (or equivalent), business processes should be defined and the 605

associated data, records, and signatures identified. The impact of the data and 606

records can then be established, risks assessed, and controls identified. More 607

detailed assessments may be performed as the system life cycle progresses and 608

more information becomes available. 609

610

Similar records (e.g., calibration-related records) may be grouped by type, so 611

that a consistent risk management approach can be applied to all records of 612

that type either within individual projects or across the organization. 613

614

Controls may be behavioural, technical, or procedural in nature. Technical 615

controls should be included in the relevant specification and identified 616

procedures should be developed for the system. Behavioural controls are general, 617

i.e. not specific to a single system. These are described in Section 6, Data 618

Governance Framework. 619

620

Verification of the installation and correct operation of controls occurs during 621

testing. 622

623

It is recommended that the activities to manage specific risks associated with 624

regulated data, records, and signatures should form part of the normal 625

validation planning strategy. 626

627

The emphasis should be to encourage innovation and technological advances, 628

without leading to over-engineered solutions that adversely impact the 629

productivity of the process and without providing added benefit to patient 630

health. 631

632

4.1.1 Risk Management Based on the Impact of Records 633

This Guide describes a five step risk management approach based on the impact 634

of the record, or type of data or record, on product quality or patient safety. 635

636

Step 1: Identify regulated data, records, and signatures 637

638

Step 2: Assess impact of data and records 639

640

Step 3: Assess risks to data and records (vulnerabilities) 641

642

Step 4: Implement controls to manage identified risks 643

644

Step 5: Monitor effectiveness of controls during operation 645

646

A suitable cross-functional team, made up of individuals representing QA, 647

process owner, system owner and users, IT, and engineering, as appropriate, 648

should perform these activities. The team should include the electronic record 649

or data owners. 650

651

4.2 STEP 1: IDENTIFY REGULATED DATA, RECORDS, AND SIGNATURES 652

Regulated data and records should be identified and documented. This should be 653

completed as early as possible during system specification, based on defined 654

business processes. A data flow analysis is useful in supporting this activity 655

and in determining the role of each item in regulated processes. 656

657

The emphasis should be on identifying records required by regulations such as 658

clinical study reports, training records, or batch records, rather than physical 659

database records, or table fields. Some records may be created and maintained 660

on one system and copies transferred and used by other systems. 661



of 198

662

Each signature or signature type (e.g., preclinical study approval, batch 663

release approval) should also be identified. Whether or not the signed record 664

is used for regulatory purposes should be decided and the conclusion documented. 665

666

Appendix x gives examples of records and signatures required by GxP regulations. 667

668

Software code, internal system configurations, and technical parameters are not 669

regulated data or records as described in this Guide. These are controlled by 670

normal validation, change management, and configuration management processes. 671

672

4.3 STEP 2: ASSESS IMPACT OF DATA AND RECORDS 673

Impact assessment allows the selection of the appropriate approach to risk 674

management for an identified item or item type. The conclusions of the impact 675

assessment should be documented. 676

677

Impact should not be determined solely by the requirement for a record in a GxP 678

regulation, but by an assessment of the potential impact of the record on 679

patient safety or product quality. Regulated electronic records may be 680

classified based on risk. 681

682

While in reality there is a continuous scale of impact, classification may be 683

based on High, Medium, or Low, or other scales, e.g. 684

685

High impact records typically have an immediate and obvious impact on 686

product quality or patient safety. Examples include batch release or 687

adverse event records. 688

Medium impact records typically have a significant but lower impact on 689

product quality or patient safety. These records are often used as 690

supporting evidence of compliance, such as validation documentation or 691

training records. 692

Low impact records typically have limited impact on product quality or 693

patient safety. Such records may be used to support regulated activities, 694

but are not key evidence of compliance. For example, calibration 695

scheduling records are typically low impact; the key records being the 696

standards defining the required frequency and the records showing 697

calibration has been performed in accordance with those standards. 698

699

Examples of record types specifically identified in GxP regulations with an 700

indication of their typical impact are given in Table 2.1. It is important to 701

note that this list of records is for guidance only. It is not intended to be 702

definite or an all-inclusive list of possible record types. Companies should 703

make a documented judgment of the impact of records or types of records based 704

on their own processes and circumstances. 705

706

This judgment should be driven by an overall risk assessment of the business or 707

facility aimed at identifying the overall undesirable outcomes that may occur 708

independently of whether electronic records are involved. These can then be 709

assessed against the primary, and related, risks to product quality or public 710

safety. Different facilities and products will have very different profiles in 711

this respect. 712

713

For example, a medical device company making tongue depressors is likely to 714

focus on issues associated with direct contamination and failures of sterility, 715

while an oncology drug manufacturer would typically focus on potency, stability, 716

composition, and lab assay.717



of 198

Table 2.1: Typical Impact of Records by Type 718

719

H: High Impact 720

M: Medium Impact 721

L: Low Impact 722

723

Type of record Typical

Impact

Considerations

Training/personnel

record, job

descriptions, incl.

roles and

responsibilities.

L-M While required by some GxP regulations these records do not have

an immediate impact on product quality or patient safety.

Effective training may be in place even if not supported by

records.

QA Audits and

Investigations

(including Deviations)

H QA investigations are often used for internal control, but if the record

is used in a study report or for a product release decision then the

impact is higher.

Equipment cleaning

records

H Cleaning records may impact product quality or patient safety (for

example risk of cross-contamination). The impact will depend upon

materials & products concerned and detectability.

Calibration records H Calibration records may impact product quality or patient safety (for

example risk of incorrectly processed products). The impact will depend

upon materials & products concerned and detectability.

Planning documents L Documents such as cleaning, calibration, or maintenance schedules may

be requested by inspectors as a sign of compliance with GxP requirements,

when considered as part of a quality system. While the absence of such

plans may increase the risk of companies not having the required results

available for inspection the key records are the results of executing

such plans.

Management information, such as project plans would have low impact.

Validation

documentation

L-M E.g., Validation Plan, Specifications, Traceability Matrix, Test

Protocols and Results, Validation Reports.

Financial Disclosure by

Clinical Investigators

L Required by GxP regulations.

Inspection Records M Records of inspections of laboratories or facilities.



of 198


Impact

Considerations

Environmental

Monitoring records

M-H Impact will vary depending on the criticality of parameters being

monitored. For example, microbiological and environmental performance

of a sterile area may be high impact. Another example may be monitoring

records from clinical trials studies. Secondary packaging and

warehousing areas may be medium impact depending on the product, while

building management records of office environments would not be regarded

as having GxP impact.

SOPs L-H SOPs used in electronic form constitute electronic records. The impact

of SOPs will depend on the nature of the SOP or set of SOPs concerned.

For example, a set of SOPs that are used to govern the validation of

automated systems should not be considered as critical as SOPs that are

used to govern QC operations including final batch release.

Material and finished

product specifications

H These are the specifications used to release product. Material can range

from finished product to shipping boxes.

Distribution records H These affect product recall and product return.

Clinical and Non-

clinical studies and

reports

H Indicate the methods and content of the study to be carried out and

include:

non-clinical study protocols, clinical study protocols, Institutional

Review Board (IRB) documentation.

Contains patient safety data.

Informed consent

documentation

M Required for clinical trials.

Investigational New

Drug applications

(INDs)

H An IND is a compilation of documentation. These records contain patient

safety data and information about process and product specifications.

Disposition of

investigational drug

H Affects the ability to recall investigational product.

New Drug Applications

(NDAs)

H An NDA is a compilation of documentation. These records contain patient

safety data and information about process and product specifications.

Adverse Events (AEs)

and Adverse Drug

H Contains patient safety data.



of 198


Impact

Considerations

Reactions (ADRs)

Bioequivalency Study

Reports

H Contains patient safety data.

QC Analysis results H High if used for final product release decisions, or intermediate

products.

Batch records H These records document production and product quality.

Component, drug product

container, closure, and

labeling records

H These records enable component traceability and batch recall.

Sample management

records

L Required for compliance with US PDMA (or other similar national

regulations) for drug samples requested by physicians

Patient information

leaflets

H Contains information such as usage instructions and contraindications

Master production and

control records

H Contain specifications on which release decisions are based.

Complaint files H These are an important measure of product quality.

724



of 198

Not all records are specifically identified in GxP regulations. Some are 725

maintained in order to provide evidence of GxP compliance or GxP decision 726

making. A standard approach should be adopted to determine the impact of 727

records, using a checklist of questions, such as the following: 728

729

Can corruption or loss of the record lead to misinterpretation of 730

product quality, safety, or efficacy? 731

Can corruption or loss of the record cause the product to be adulterated 732

or result in the release of adulterated or quarantined product? 733

Can corruption or loss of the record cause the product to be misbranded? 734

Can corruption or loss of the record affect the ability to recall 735

product? 736

Can corruption or loss of the record affect product quality or patient 737

safety decisions? 738

Does the record have an impact on patient safety decisions? (E.g., 739

impact on pre-clinical or clinical safety results, impact on Adverse 740

Drug Reactions (ADR) and Adverse Events (AE)). 741

Is the record required by, or submitted to, a regulatory agency and 742

could it relate to decisions on product quality or patient safety? 743

744

Impact classification will vary from case to case depending on factors such 745

as the nature of the product, and company procedures and processes. The 746

initial tendency of organizations may be to define the majority of records 747

in the high impact group rather than in the low to middle groups. However, 748

with improved understanding over time the interpretation of degrees of risk 749

associated with records may start to decrease. 750

751

Typically, most regulated electronic records across an organization will be 752

used within an overall management process with independent safeguards against 753

failure (e.g., final QC testing and QA release of product). Therefore, while 754

electronic records such as QA release decisions will be high impact, the 755

majority of electronic records across the organization should have medium 756

impact on product quality or patient safety. Classifying records as high 757

when they are more realistically medium may lead to unnecessary work and 758

controls which are not justified by the risks to product quality or patient 759

safety. 760

761

It may also be appropriate to consider records associated with rules or 762

regulations other than GxP regulations when identifying record types. These 763

may include records relating to the handling of controlled substances or 764

occupational health and safety. Issues of legal admissibility should also be 765

considered. 766

767

4.4 STEP 3: ASSESS RISKS TO ELECTRONIC RECORDS BASED ON IMPACT 768

Following the identification of electronic records and their impact, the 769

next step is to select the appropriate risk management approach. 770

Potential hazards and vulnerabilities should be identified and the associated 771

risks assessed. The following aspects should be considered during the 772

assessment: 773

774

Severity of the consequence 775

Probability of occurrence 776

Likelihood of detection prior to harm occurring 777

778

The extent and formality should depend on impact, becoming increasingly more 779

rigorous with greater impact. 780

781

Hazards and vulnerabilities should be formally identified and analyzed by a 782

cross-functional team, including process SMEs, technical SMEs and QA. 783



of 198

784

[REFER TO QRM APPENDIX HERE] 785

786

4.4.1 Hazards and Vulnerabilities 787

Potential hazards and vulnerabilities may be classified as human-related, 788

computer-related, or physical/environmental. 789

790

Table 2.2 provides some examples of potential hazards. Note that the focus 791

here is on hazards to data and records rather than to the system. These 792

examples are not intended to be definitive or all-inclusive. 793

794

Table 2.2: Examples of Hazards and Vulnerabilities 795

796

797

Hazard / Vulnerability Consequence

Human-related (accidental or

deliberate)

Human error (includes errors

of judgment and errors in

carrying out required actions)

Wrong record/signature displayed

Accidental corrupted

record/signature

Invalid contents of

record/signature

Incorrect copy of record

Change error Invalid contents of record

Unauthorized change Invalid contents of

record/signature

Undetectable change Invalid contents of

record/signature

Wrong access rights Wrong record/signature displayed

Invalid contents of

record/signature

Computer-related

Hardware undersized Loss or corruption of record(s) or

signature(s)

Hardware loss (e.g. disk

crash)

Loss or corruption of record(s) or

signature(s)

Data loss (e.g. backup

failure)

Loss or corruption of record(s) or

signature(s)

Software terminates Loss or corruption of record(s) or

signature(s)

Wrong version of software Loss or corruption of record(s) or

signature(s)

Multiple versions of software Loss or corruption of record(s) or

signature(s)

Software lost or deleted Loss or corruption of record(s) or

signature(s)

Software failure** Invalid contents of

record/signature

Wrong record/signature displayed

Accidental corrupted

record/signature



of 198

Hazard / Vulnerability Consequence

Printer error or failure Incorrect copy of record/signature

Physical/Environmental

Power surge Loss or corruption of record(s) or

signature(s)

Power failure Loss or corruption of record(s) or

signature(s)

Fire and/or smoke Loss or corruption of record(s) or

signature(s)

Environment problem Loss or corruption of record(s) or

signature(s)

Theft of hardware/software Loss of record(s) or signature(s)

** Includes incorrect manifestation and incorrect link to the

appropriate record

798

799

4.5 STEP 4: IMPLEMENT CONTROLS TO MANAGE IDENTIFIED RISKS 800

The company should identify risk control measures that are appropriate for 801

reducing risks to an acceptable level. Risk control involves eliminating or 802

managing the hazard and may be achieved by one or more of the following: 803

804

Modifying the process 805

Modifying the system design 806

Applying behavioural controls 807

Applying procedural controls 808

Applying technical controls 809

810

The control measures should be aimed at eliminating or reducing the 811

probability of occurrence of the harm, reducing the severity of harm, or 812

increasing the probability of detection. The selected control measures should 813

be documented and justified with reference to the identified risks, and 814

implemented and verified. The rigor and extent of controls will depend upon 815

the impact and identified risks. 816

817

The company should consider any residual risks to records that remain after 818

the risk control measures are applied. If these risks are not acceptable, 819

further risk control measures should be considered and applied. The risk 820

control measures may also introduce new hazards. If so, risks associated 821

with these new hazards should be assessed. 822

823

Finally, the company should satisfy themselves that risks from all identified 824

hazards have been evaluated. This judgment should be documented. 825

826

There should be traceability between the identified hazards and the 827

implemented and verified control measures. 828

829

A range of controls that may be applied is discussed in detail in Appendix 830

X. 831

832

4.6 STEP 5: MONITOR EFFECTIVENESS OF CONTROLS 833

During periodic review of systems, or at other defined points, the company 834

should review the risks to records. It should be verified that controls 835

established during system development and validation are still effective, 836

and corrective action taken if deficiencies are found. The company should 837



of 198

also consider: 838

839

If previously unrecognized hazards are present 840

If the estimated risk associated with a hazard is no longer acceptable 841

If the original assessment is otherwise invalidated (e.g., following 842

changes to applicable regulations or change of system use) 843

844

Where necessary, the results of the evaluation should be fed back into the 845

risk management process, and a review of the appropriate steps for the 846

affected records should be considered. If there is a potential that the 847

residual risk or its acceptability has changed, the impact on previously 848

implemented risk control measures should be considered, and results of the 849

evaluation documented. It should be noted that some changes may justify 850

relaxation of existing controls. 851

852



of 198

5 DATA LIFE CYCLE 853

854


The data life cycle is comprised of two components – the business process 856

and the data flow. The MHRA emphasized this when they stated in their March 857

2015 guidance that “consideration should be given to the organizational (e.g. 858

procedures) and technical (e.g. computer system access) controls applied to 859

different areas of the quality system” and “The degree of effort and resources 860

applied to the organizational and technical control of data life cycle 861

elements should be commensurate with its criticality in terms of impact to 862

product quality attributes.” The elements of the data life cycle are defined 863

in Figure ###, below: 864

865 Figure ###: Data Life cycle. 866

Each of the life cycle elements can have an impact on ensuring data integrity. 867

Therefore, the importance of defining and implementing robust risk-based 868

processes is essential to identifying, assessing, mitigating, and 869

communicating potential data integrity issues throughout the data life cycle. 870

871

5.2 DATA CREATION AND CAPTURE 872

Data integrity is a critical consideration for data creation and capture—if 873

the original data lacks integrity, it is difficult to repair gaps and ensure 874

integrity after data collection has occurred. In practice, data integrity is 875

most often compromised at the point of creation/collection. Ensuring data 876

integrity at the moment of data creation/collection involves both behaviours 877

and technology, human and technical controls. These controls start before 878

data is collected: they begin when a system is purchased. 879

Data creation/collection depends on control of the following factors: 880

system clock—providing the timestamp for all activities 881

configuration options that control the system—these include system 882

options and work flows 883

system administrators who often have control over the environment and 884

data files created during data creation/collection 885

users and the actions they are permitted to perform. 886

ISPE D

RAFT © 20

16



of 198

Note that there may also be a data migration step from retention and archive 887

of data in an existing system to creation in a new system. 888

5.2.1 System Purchase or Development 889

Regulators expect new systems to be compliant with regulations (MHRA, 2015 890

[Ref]); however, non-compliant systems are available for purchase and 891

acquired as viable options by an organization for a number of reasons, 892

including lower cost, better interface, specialized features, or vendor 893

relationship. The same considerations apply to upgrades to currently 894

implemented systems. Before making any purchase decision, the data flow and 895

user requirements need to be evaluated. This evaluation should focus on 896

looking for unmet requirements and design elements which make it possible to 897

undermine data integrity, e.g. for users to delete, move, or rename data 898

files using either the application (“front door”) or the operating system 899

(“back door”). Gaps should be documented and evaluated. Potential 900

mitigations should be developed for gaps and included in the document, along 901

with cost estimates for these actions. These mitigations might add 902

significant cost to installing a system that is fit for purpose. 903

904

5.2.2 Fit for Purpose 905

The system must be designed and implemented for its intended use. This 906

includes: (1) proper installation; (2) complete set of user/functional 907

requirements; (3) process data flow map—data needed for intended use; (4) 908

configuration of system to meet requirements; (5) testing critical functions 909

for evidence of performance; (6) human and technical controls to address 910

missing requirements or gaps in system design. For many systems, 911

configuration control—including the system clock--is essential to ensure that 912

original and complete data is accurately collected. Once the system is 913

defined, configured and tested, residual risks should be evaluated and 914

documented as proof that design and controls are adequate and effective, and 915

the system is fit for business purposes. 916

917

5.2.3 Access Controls 918

The security principle of least access—the fewest people with the least 919

possible access to perform their assigned duties-- minimizes data integrity 920

risks by minimizing the exposure of the data. 921

In addition, personnel with enhanced access rights and capabilities to 922

modify/delete any of the above critical factors should be in positions where 923

they are not given incentive to modify/delete data in improper ways for 924

personal benefit. 925

926

5.2.4 Monitoring Data Creation/Collection 927

Once systems are verified to be fit for purpose, with appropriate access 928

controls in place, data creation/collection may begin. During routine 929

operation, users should be monitoring the system for expected performance. 930

Original data must be secured as rapidly as possible, to prevent adulteration 931

and to provide a trusted value for subsequent processes and reports. If 932

original data can be altered, an audit trail must be enabled to record the 933

event. Periodic review of access rights and system performance will assure 934

that controls still function as designed, so created/collected data is 935

trustworthy. 936

937

5.3 DATA CALCULATION/PROCESSING 938

After original data has been collected and written to a medium, it is 939

typically used to compute other data that will determine if the process is 940

in control, responding properly, is a representative sample of the material 941

in question, and many associated other factors. These computations are 942

important, as they assist users in determining the acceptability of the data 943

to characterize the product under examination. 944

945

5.3.1 Calculations as Validity Checks 946

Calculations can be used to determine the validity of the data as it is 947



of 198

entered. These validity checks can use formulas or other defined limits to 948

alert the user that a value exceeds a specification, or it is statistically 949

different from many other values. This same approach can be employed to 950

test the results of calculations. These validity checks can alert users to 951

verify the original data once more, to assure its accuracy. However, there 952

is a risk these alerts can prompt users to falsify their entries to obtain 953

a value that falls within specification, regardless of the observed value. 954

If the system does not record every data entry in an audit trail, original 955

values can be repeatedly modified to obtain an acceptable calculated value 956

that falls within specification, with no historical record of improper 957

activity. 958

959

5.3.2 Calculations as Transformations of Data 960

Data integrity requires control over the calculation set (i.e. method or 961

workflow) performed on original data. A linkage between original data and 962

calculations is necessary to verify the accuracy of the calculated data, and 963

to reproduce the result value, should it become necessary. This linkage 964

between original data and calculations is necessary to verify the accuracy 965

of the calculated data. Calculation sets should have limited access, as 966

changes have potential impact on the calculated data value. 967

968

5.3.3 Control of Calculations 969

Good system designs preserve the original data values which are inputs to 970

the calculation set and permits a user to reproduce a calculation anytime 971

during the data life cycle. In addition, audit trail should be enabled to 972

record all reprocessing of the calculations. 973

974

Calculations should start with data that has been recorded in an enduring 975

medium. Systems that temporarily store data in a buffer and permit 976

calculations to be performed before storage are not optimal. This scenario 977

provides an opportunity for the user to remove the data without a permanent 978

record by aborting the process or powering down the system. To avoid this 979

scenario, all calculated values should be securely stored before they are 980

presented to the user. This ensures that any subsequent action can be 981

recorded in a history file. This creates a complete record of any result 982

reprocessing, so the scientific merit of all actions may be evaluated by the 983

data reviewer. It reduces the temptation for someone to recalculate a set of 984

values to meet a specification, which may be called “testing into 985

compliance”. 986

987

5.4 RECORD REVIEW 988

5.4.1 Introduction 989

Defining and implementing robust risk-based review processes is essential to 990

assessing, mitigating, and communicating potential data integrity issues 991

throughout the data life cycle. Result review is defined, per existing 992

regulations, as the review of individual results or sets of results (i.e. 993

records) prior to making a decision (accept/reject) about product or data 994

quality. Result review should include the comparison of results against 995

specification/ limits/ acceptance criteria. It also includes the evaluation 996

of completeness and correctness of metadata. 997

998

The review process allows an individual to make a judgment about potential 999

validity any manually entered values, and any information associated with 1000

decisions or actions taken. The reviewer should assess and understand the 1001

impact that any manual adjustments or alterations of the data might have on 1002

the results, the metadata, or the product decision(s), as well as changes to 1003

the method versions used in creation of the result. The review should also 1004

include an assessment of the conformity to sound scientific practice and 1005

documented procedures. Increased rigor should be applied to manual 1006

adjustments, overrides, and/ or results that barely meet the specifications. 1007

1008



of 198

5.4.2 Controls and Considerations for Record Review 1009

The World Health Organization (WHO) has identified [Ref] [DRAFT Guidance on 1010

Good Data and Record Management Practices (September 2015)] a number of 1011

controls for the review of records. Written procedures and training should 1012

be in place to ensure appropriate review and approval of critical records, 1013

including both paper and electronic. The record review procedures should 1014

clearly describe the review of the data and relevant metadata, including 1015

changes to the original data and information in the audit trails to ensure 1016

these changes are complete, scientifically appropriate, and adequately 1017

justified and investigated when required. 1018

The record review procedures should also define the frequency, roles and 1019

responsibilities, and approach to review the primary record(s), and the 1020

appropriate metadata associated with that record, such as audit trails. 1021

(Note: Audit trail review considerations will be addressed in more detail in 1022

the next section.) This procedure should also define the process for dealing 1023

with any aberrant data identified during the review process. Trending of 1024

data is discussed later in the reporting section (See 5.5.3). 1025

Any departures from the expected outcomes should be thoroughly investigated 1026

and documented. Specific review procedures for different types of records, 1027

such as chromatography data, LIMS records, or batch records, might be 1028

required to provide the appropriate level of detail, and individuals 1029

performing these reviews should be appropriately trained on the review 1030

process and the system generating the record(s) subject to review. Data 1031

reviews, as predicate rule records, should be documented. 1032

This review is typically captured via signing off on the review and approval 1033

process, either as an electronic signature in a computer system, or as a 1034

physical signature on a paper or hybrid record. The data review procedure 1035

should clearly define the meaning of this signature so those executing the 1036

review understand their responsibilities relative to the scope, accuracy, 1037

consistency and completeness of the record and its conformance with 1038

applicable standards and specifications. Controls should also be in place 1039

to enable the reviews to identify non-conformance to procedural requirements. 1040

Quality Assurance, as part of these controls, should review a sampling of 1041

relevant records, raw data, and metadata as part of the self-inspection 1042

process to ensure ongoing compliance with applicable policies and procedures, 1043

continuing effectiveness, and compliance of the data integrity program. 1044

1045

5.4.3 Audit Trail Review 1046

Audit trail review provides a means to detect data integrity issues, and 1047

also functions as a deterrent for unauthorized or improper data manipulation. 1048

The MHRA Data Integrity Definitions and Guidance (MHRA, March 2015) defines 1049

an audit trail as “metadata that are a record of GxP critical information 1050

(for example the change or deletion of GxP relevant data), which permit the 1051

reconstruction of GxP activities.” It is a record of who did what, when, 1052

and why. Therefore audit trails are critical for verifying that changes made 1053

by authorized users were appropriate. The audit trail provides the most 1054

effective means of assessing data integrity in the hands of someone who 1055

understands the business process and the impact of the actions recorded 1056

within the data audit trail. Per the MHRA Data Integrity Definitions and 1057

Guidance (March 2015): 1058

1059

"Audit trail review should be part of the routine data review/ approval 1060

process, usually performed by the operational area which has generated 1061

the data (e.g. laboratory)." 1062

1063

It is important to note that all audit trails are not created equal and are 1064

not always called audit trails. Systems typically include many metadata 1065

fields and audit trails. Software developers/ system suppliers may use the 1066

term “audit trail” to track other computer system and file maintenance 1067

activities. The audit trail review does not need to include every system 1068

activity. The risk-based review of electronic data and metadata, such as 1069



of 198

audit trails, requires an understanding of the system and the scientific 1070

process governing the data life cycle so that only meaningful metadata is 1071

subject to review, regardless of naming conventions used by the software 1072

developer/ system supplier. Meaningful metadata are those items with direct 1073

GxP relevance, including those items that relate to data creation, 1074

processing, modification, and deletion. Unfortunately, in some cases, the 1075

audit trail is not easily accessible and/ or permanently associated with the 1076

result, making both review and data integrity assessment very difficult. It 1077

is therefore important prior to implementing the system to ensure the correct 1078

metadata is readily available and maintained securely by the system. The 1079

appropriate audit trail data may best be reviewed by running various database 1080

queries or by the review of designed and validated system reports. Increased 1081

result review rigor should be applied to manual adjustments, and sample 1082

selection for a statistical review should emphasize borderline results. 1083

Written procedures on data review should define the frequency, roles and 1084

responsibilities, and approach to review of meaningful metadata, including 1085

critical audit trials. 1086

In an environment where hundreds to thousands of results are generated, 1087

review of the audit trail and metadata associated with this volume of results 1088

presents some logical and resource challenges. For just one hundred sample 1089

results, even spending as little as two minutes per result can mean more 1090

than three hours review time daily from each reviewer on samples and more 1091

than one level of review may be required. It is probably not possible to 1092

effectively review each result and its history in two minutes. Where the 1093

process or application permits, technology controls implemented within many 1094

systems offer the ability to provide an efficient additional level of 1095

assurance and may permit a “review by exception” approach. This approach 1096

applies a risk-based approach to data review based on alerts to highlight a 1097

subset of results requiring additional scrutiny, such as results/ data that 1098

are within but close to the specification limit, have been manually 1099

manipulated (i.e. integration), or have been reprocessed. They can also 1100

highlight situations where critical data has been manually entered or 1101

changed. A detailed review is then performed on a subset of the results/ 1102

data based on “flagging” items that meet the configured review criteria. 1103

Keep in mind that it is required to determine and document what the adequate 1104

level of result review is and to be able to provide a documented rationale 1105

for doing so during an audit or regulatory inspection. These types of systems 1106

also require validation to verify and document the alert functionality. 1107

1108

5.5 RECORD ANALYSIS & REPORTING 1109

5.5.1 Introduction 1110

Managing data across the entire data life cycle is critical to ensuring the 1111

integrity of the information. Just like the other steps associated with the 1112

data life cycle, data processes associated with the reporting of records 1113

should be also designed to adequately control data integrity risks. Good 1114

data management process design, based on the application of sound scientific 1115

practices and technology and effective data integrity control strategies, 1116

should result in increased assurance of data integrity and effective and 1117

efficient business processes. Increased data integrity risks result when 1118

data processes or specific process steps are inconsistent, subjective, open 1119

to bias, unsecured, or unnecessarily complex or redundant. Data integrity 1120

risks are reduced when processes are well understood, well defined, based on 1121

appropriate and validated assumptions, and adhere to good documentation 1122

practices. Manual and paper-based processes can also contribute to lower 1123

confidence in data integrity due to risks related to the potential for non-1124

contemporaneous actions, loss of data, and/or lack of attributability. The 1125

core of data governance is creating a framework within a QMS to ensure that 1126

data generated is recorded, processed, reported, retained, and used 1127

consistently and appropriately throughout the life cycle. Having well 1128

defined processes, based on sound scientific practices and available 1129

technology, is critical to ensuring the information is complete, consistent, 1130



of 198

and accurate. This is especially true for record reporting. 1131

1132

5.5.2 Data Reporting Procedures 1133

Poorly designed products, processes and test methods create opportunities 1134

for erroneous decisions. Critical reports associated with operational data 1135

need to be well defined to avoid inconsistencies and the opportunity for 1136

data reporting errors, whether inadvertent or intentional. To obtain 1137

complete and accurate data it is necessary to establish policies, systems, 1138

procedures and controls to ensure reliability and integrity of data. For 1139

example, regulatory authorities continue to discover issues with the 1140

operation and control of laboratory equipment like chromatography 1141

instruments. In many cases, chromatographic test methods and laboratory 1142

procedures do not define integration parameters, or conditions under which 1143

manual integration of chromatograms is allowed. They fail to address 1144

handling atypical chromatographic results or investigating those results. 1145

Similar issues exist for other laboratory analysis techniques, and other key 1146

business processes associate with the pharmaceutical product life cycle. It 1147

is therefore critical to have a data integrity control strategy integrated 1148

into policies, systems, and procedures to ensure that the required data 1149

checks and reporting processes are carried out properly and to provide 1150

evidence to demonstrate that a given procedure and / or process is in a state 1151

of control. 1152

1153

Data reporting procedures are critical to ensuring the consistency and 1154

integrity of results. These procedures, if not already well defined as part 1155

of the testing methods and procedures, should address a number of key 1156

elements. First, it must be very clear about what data is to be included in 1157

the data set used for reporting the results. The US FDA regulation 21 CFR 1158

211.194(a) states that “Laboratory records shall include complete data 1159

derived from all tests necessary to assure compliance with established 1160

specifications and standards.” The practice of performing initial “trial” 1161

sample analyses prior to acquiring the “official” analyses is not acceptable, 1162

especially when these “trial” sample results are subsequently discarded. All 1163

data should be included in the dataset unless there is a documented scientific 1164

rationale for excluding it. Second, the practice of reprocessing data 1165

through minor adjustments to the analysis parameters until a passing result 1166

is obtained and reported is also inappropriate and would be considered 1167

“testing into compliance.” The data reporting procedure should also address 1168

situations where manually entered information might be acceptable in lieu of 1169

auto-population. In this case, the ability to flag these situations is very 1170

beneficial to aid in the data review process and establish controls to prevent 1171

and detect data manipulation. It is also common to include the information 1172

associated with the record review process requirements, including audit 1173

trails reviews, results at or near specification limits, etc. 1174

1175

5.5.3 Trending and Atypical Results Reporting 1176

As mentioned earlier, the record reporting life cycle process should address 1177

handling of atypical results and the process for investigating those results. 1178

This process should include investigating and determining corrective and 1179

preventative actions for invalid runs, failures, repeats and other atypical 1180

data. EU GMP Chapter 6.9 states “Some kinds of data (e.g. tests results, 1181

yields, environmental controls) should be recorded in a manner permitting 1182

trend evaluation. Any out of trend or out of specification data should 1183

therefore be addressed and subject to investigation.” Unfortunately, out-1184

of-spec investigations cost time and money, and the financial impact of 1185

losing a batch can be enormous, so there is a temptation to simply reanalyze 1186

or reintegrate until a satisfactory lab result is achieved. An inability to 1187

find the root cause may result in reoccurring problems and workarounds which 1188

only contribute to additional data integrity issues. 1189

1190

Therefore, paying close attention to trends and metrics is a key indicator 1191



of 198

of potential issues. Trending and report generation to look at anomalies in 1192

the data and reports is also a great forensic tool for identifying and 1193

investigating potential data integrity issues within your systems and 1194

organization, especially if good and usable audit trails do not exist. The 1195

key is to encourage problem identification and solving. It must be easy and 1196

safe for operators, analysts, supervisors, and management to report actual 1197

and potential problems, or improvements will not occur. Trending and 1198

atypical result review and reports are a great means of identifying issues 1199

and implementing solutions to ensure continuous improvement. 1200

1201

5.6 RECORD RETENTION AND ARCHIVAL 1202

This section describes how to manage electronic records in order to comply 1203

with GxP regulations for record retention and archival. Only with a document 1204

or record management program addressing control of regulated records 1205

throughout the entire data life cycle can a company demonstrate their 1206

commitment to data integrity. The primary focus is on compliance issues 1207

related to the logical and physical choices firms make regarding the 1208

retention process. According to the MHRA GMP Data Integrity Definitions and 1209

Guidance for Industry (March 2015) the data life cycle is defined as ‘All 1210

phases in the life of the data (including raw data) from initial generation 1211

and recording through processing (including transformation or migration), 1212

use, data retention, archive / retrieval and destruction.’ While this 1213

includes consideration of issues related to migrating records to non-1214

processable formats, it is also not intended to be a complete guide to GxP-1215

compliant data migration or archiving practices. 1216

1217

See GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems 1218

(Appendix D7) and GAMP Good Practice Guide: Electronic Data Archiving 1219

(Appendix G3) for further details. 1220

1221

This section specifically does not discuss defining the retention period for 1222

various types of records, which is based on the relevant GxP regulations and 1223

may differ based on jurisdiction, company policies and legal obligations, 1224

and is outside the scope of this Guide. 1225

1226

5.6.1 Regulatory Expectations 1227

According to EU GMP Guide Annex 11: Computerized Systems, Revision 2011, 1228

1229

‘Data should be secured by both physical and electronic means against 1230

damage. Stored data should be checked for accessibility, readability and 1231

accuracy. Access to data should be ensured throughout the retention 1232

period.’ 1233

Within FDA Guidance for Industry Part 11, Electronic Records; Electronic 1234

Signatures – Scope and Application, the phrase repeated multiple times is 1235

that any records or copies of records must ‘preserve their content and 1236

meaning.’ 1237

1238

The retention and accessibility of all data necessary to reconstruct studies 1239

and to support regulated decisions has always been a regulatory expectation. 1240

Data retention requires that the data retained maintain its integrity i.e. 1241

have all of the required elements of ALCOA+: 1242

1243

Attributable - data must be linked to the individual who created the data. 1244

Legible - data is clear, concise, and readable. Changes to legible data 1245

must not hide or obscure the original record. 1246

Contemporaneous - data must be captured at the time of the action and 1247

include the date and time of its measurement or action. All electronic 1248

data, contemporaneous data must include metadata related to the action or 1249

event. 1250

Original - data must be the original record or a certified copy. 1251



of 198

Accurate - data is correct through the system’s life cycle and indicates 1252

the same value and its correct meaning. 1253

Complete - data includes all data from actions taken to obtain the final 1254

result. Complete data includes all metadata generated for each action 1255

taken, including audit trails. 1256

Consistent - data shall be created in a manner that can be repeated, 1257

following a logical sequence based on the method or procedure. 1258

Consistency can be defined throughout the life cycle of your data. 1259

Enduring - data must be protected from loss, damage and/or alteration and 1260

must be available throughout the defined retention period. 1261

Available - data is retrieved throughout the retention period. Data must 1262

be available in human readable form. 1263

It is important to understand the difference between backup and restore and 1264

record archiving and retrieval. Backup and restore are the routine processes 1265

of copying live records and software to alternate media to protect against 1266

loss of data or software availability and the subsequent ability to restore. 1267

Archival of a record is the process for long-term storage of data ensuring 1268

access to the record throughout the required retention period while 1269

preventing access or damage to the record. The archival process should 1270

provide assurance that the integrity of the record is maintained and 1271

periodically confirmed. To reconstruct studies or decisions, the complete 1272

data must be retained along with the metadata necessary to preserve the 1273

content and meaning of the data. It should be noted that some companies 1274

utilize and retain backups throughout the retention period to address the 1275

need for archival. While this might technically comply, it is horribly 1276

inefficient and results in the potential storage of multiple copies of the 1277

data, as well as other files that are required to restore the application. 1278

It can also make the retrieval of the specific data you want less timely and 1279

more difficult. 1280

1281

Record retention is maintaining records in a secure, accessible, and reliable 1282

form for a period of time, as set in regulations or other mandate. According 1283

to EU GMP Guide Annex 11: Computerized Systems, Revision 2011, ‘Data and 1284

document retention arrangements should ensure the protection of records from 1285

deliberate or inadvertent alteration or loss. Secure controls must be in 1286

place to ensure the data integrity of the record throughout the retention 1287

period, and validated where appropriate.’ 1288

Regulatory authorities define the requirements for data retention and the 1289

associated retention period (the length of time specified for data to be 1290

preserved) and the retention period can vary from a few years to decades 1291

depending on the type of record. Each company must define their record 1292

retention schedule based upon the regulatory expectations. 1293

1294

According to GAMP® 5, ‘Archiving is the process of taking records and data 1295

off-line by moving them to a different location or system, often protecting 1296

them against further changes. Archived records should be readily retrievable 1297

for business or regulatory purposes.’ While an archive is often the best 1298

approach to meeting record retention requirements, it has additional meaning 1299

in that the archive process must ensure that the record cannot be modified 1300

or deleted. Archival generally involves moving the record from the system 1301

that produced it to an alternate location. This move may be to a totally 1302

separate system and/ or database or simply a move from the main database to 1303

an internal archive database. The key reason for an archive is that the 1304

complete records are maintained (enduring) throughout the appropriate record 1305

retention schedule for the purpose of being able to reconstruct the activity 1306

and defend any conclusions or decisions. 1307

1308

For further information on Archiving and Retrieval, see GAMP® 5 Appendix O13, 1309

and GAMP Good Practice Guide: Electronic Data Archiving for further details. 1310



of 198

In some systems, the data and the associated metadata may not be available 1311

as a single record, but may be found in separate folders or logs. Therefore, 1312

when this data is archived, arrangements must be made to ensure that the 1313

data and necessary metadata are archived so as to ensure this association is 1314

maintained. 1315

To address the on-going availability of the data, it is necessary to consider 1316

the availability of the software and devices needed to access the records. 1317

For any data, the approach to data retention should be based upon an 1318

assessment of the risk associated with the data format, physical media, and 1319

future expected use of the data. A documented risk assessment should be done 1320

to analyze what metadata and what audit trails are necessary to document 1321

record control. Data management activities (including security, disaster 1322

recovery, etc.) must also be considered. The risk assessment may need to be 1323

re-visited, to address changes in technology throughout the data life cycle. 1324

1325

5.6.2 Risk 1326

Regulated companies should address the record retention requirements for a 1327

specific system based upon a documented risk assessment. It should evaluate 1328

the risks associated with the record, the requirements of the data format 1329

and the technological issues associated with record retention. This risk 1330

assessment should be repeated periodically throughout the retention period 1331

to ensure that the archiving approach is still the correct solution to ensure 1332

the data are complete, consistent, accurate and enduring. 1333

Companies may choose to retain records in formats other than the original 1334

electronic record format if content and meaning are preserved, the static or 1335

dynamic nature of the data is not lost, and GxP regulations are met. The 1336

ability to retain records in a format that ensures the dynamic nature of the 1337

data throughout the retention period is not always possible or feasible or 1338

cost effective due to the difficulty of migrating the data over time. 1339

1340

The need for and risks associated with retaining data in a dynamic format 1341

typically decreases with age of the data. One alternative to consider is to 1342

develop rendering software solutions to view records should the originating 1343

system become obsolete. Rendering software will typically not feature 1344

significant abilities to process the data, but may provide a means to ensure 1345

the retrieval of the data in a usable format throughout its retention period. 1346

A justified and well documented risk assessment is essential when making any 1347

decision regarding an alternate format for the retention of the data. A 1348

risk assessment tool provides objective criteria to support such decisions, 1349

but in specific cases there may be over-riding considerations unique to the 1350

circumstances. During a risk assessment, one individual factor may be so 1351

important, that despite a favorable risk assessment it may be decided not to 1352

migrate data. If a particular e-records management decision seems 1353

fundamentally unwise, it probably is. 1354

1355

If the regulatory expectations are met and it is highly unlikely that data 1356

will have to be processed by the business, then paper or other static 1357

electronic options may be an adequate solution as long as it is a complete 1358

and accurate record. 1359

1360

Another risk that cannot be overlooked is the practice of storing multiple 1361

copies of a record. A paper printout or static record may satisfy the 1362

retention requirements if it is a complete copy of the original record. The 1363

issue occurs when this practice creates a risk of multiple inconsistent 1364

copies, especially if decisions based on old data. It’s also creates a 1365

problem when it is time to destroy records. Good record retention practices 1366

must therefore be in place to discourage and eliminate this practice and 1367

clearly define what record constitutes the official record. 1368

1369

5.6.3 On-line or Near-line 1370

One approach to archiving records is to archive them on-line. This may seem 1371



of 198

to be contradictory to many of the definitions of archiving in that many 1372

definitions indicate that records are removed from the production system. 1373

Additionally, FDA CFR 21 Part 58 Good Laboratory Practice for Nonclinical 1374

Laboratory Studies, requires that ‘All raw data …generated as a result of a 1375

nonclinical laboratory study shall be retained. There shall be archives for 1376

orderly storage and expedient retrieval of all raw data… An individual shall 1377

be identified as responsible for the archive.’ Meeting this requirement 1378

becomes problematic if the records are maintained on the live system. A big 1379

advantage of this approach is there is no need to migrate the data. If the 1380

records are to be retained on-line in a production database, measures need 1381

to be taken to protect them from alteration in order to comply with this 1382

predicate rule. Also, it is essential to have a sound disaster recovery 1383

process in place to ensure the data is not at risk of loss due to a system 1384

disaster. Because of the increasing volume of data, there may be performance 1385

issues associated with this solution. 1386

1387

Similar to the on-line approach, a ‘near-line’ solution can be implemented 1388

where records to be archived are moved to an alternate database that can 1389

still be accessed through the system and therefore transparent to the users. 1390

An advantage of this approach is that the records can be under the control 1391

of the archivist. As this ‘near-line’ solution involves the creation of an 1392

archive copy, the electronic record should be removed from the original 1393

system. The process of moving the records to an alternate database requires 1394

the development of a process to perform this migration. 1395

Both of these approaches: 1396

1397

Have the advantage of rapid access. 1398

Require procedures addressing logical and physical security, and back-up. 1399

Require that controls be established to ensure that final/approved records 1400

are secure from modification or deletion. 1401

Provide access to the records in a way that is invisible to the users as 1402

the records would still be accessible through the main application. 1403

Require that the storage capacity of the system be monitored to ensure 1404

sufficient capacity. 1405

Throughout the record retention period, there is a regulatory expectation 1406

that the records remain available. 1407

1408

Changes or upgrades to the application need to be assessed for the effect on 1409

the ability to restore archived records, whether stored near-line or off-1410

line. This will be applicable when system upgrades are performed or when 1411

there are changes in hardware, software, file format or analysis algorithms. 1412

The archived records may need to be migrated to the new database structure 1413

to enable the records to be legible and complete in the future. Data migration 1414

plans, tests and reports should be developed to ensure the integrity of the 1415

archived records. Both on-line and near-line approaches will need to be 1416

Either retaining records in the production database, or using a near-line 1417

archival approach are acceptable as long as the records are retained in 1418

accordance with relevant GxP regulations and in accordance with company 1419

policies. Even if the on-line or near-line approach is taken at the time of 1420

record archiving, it will be necessary to re-address archival if the 1421

originating system is decommissioned. If a risk assessment determines that 1422

the records need to remain processible it may be necessary to migrate 1423

electronic records to a different electronic form to preserve that ability. 1424

1425

5.7 MIGRATION 1426

Another approach to archiving records is migration of the records to an 1427

alternate media. Given the length of time records need to be retained, it 1428

may be necessary to migrate electronic records to a different electronic 1429

form, while if necessary preserving the ability to reprocess them. The 1430



of 198

primary driver for any decision to migrate records to other formats should 1431

be business need or record loss. Any record migration should be done based 1432

upon a documented risk assessment and must be done following a validated 1433

process or through appropriate verification so as to preserve the integrity 1434

of the records. 1435

As with any archive solution, the process must ensure the records remain 1436

legible and retrievable throughout the record retention period. Any process 1437

used for the archival of records needs to be tested to ensure that the records 1438

archived are complete and that they can be readily retrieved. It is also 1439

essential that the retrieval of the archived data be periodically tested to 1440

ensure it remains accessible throughout the required retention period. 1441

1442

The migration solution will need to be reviewed at various times during the 1443

record life cycle when system changes could result in the inability to 1444

retrieve the complete records. Depending upon the media used for the migrated 1445

records, additional considerations and processes need to be established to 1446

assure the long-term accessibility of the data. Do the media need to be 1447

refreshed and/or do the media require any special storage conditions? Another 1448

consideration must be given to how the records can be retrieved from the 1449

media. If the migrated records are viewed by restoring them into the 1450

originating system, the import process will need to be reviewed every time 1451

there are changes to the originating system. It may occasionally be 1452

necessary to “technically refresh” archived data, converting it to a new 1453

format that is compatible with an upgraded production system to preserve the 1454

ability to reprocess the records. Technically refreshing the records can 1455

also be a complex problem and validation activities may therefore be 1456

important. 1457

1458

Electronic data migration procedures and considerations are discussed in GAMP 1459

Good Practice Guide: A Risk-Based Approach to Operation of GxP Computerized 1460

Systems, and GAMP Good Practice Guide: Electronic Data Archiving for further 1461

details. The same principles followed for migration from one system to an 1462

alternate system may need to be followed when moving between system versions 1463

if the vendor has not provided an appropriate process. Any migration 1464

activities should be performed so as to ensure that the migrated data is 1465

still complete, accurate, and available. When migrating records, companies 1466

should make an informed risk based decision regarding the migration of 1467

metadata along with the data. This decision should be based upon business 1468

requirements and regulatory expectations. If the audit trail is integral to 1469

understanding the record, it should be maintained as part of the migrated 1470

record. A decision not to migrate an audit trail should be justified based 1471

on risk, and documented. 1472

Whenever migrating records from a computer system to another system, measures 1473

should be undertaken to ensure that the content and meaning are preserved. 1474

This generally entails either validating the conversion or verifying the 1475

accuracy of the new version. A statistical method for verification of 1476

accuracy like AQL [add to glossary] can be useful if the number of records 1477

is large. 1478

1479

If GxP regulations are fully satisfied and the content and meaning of the 1480

records are preserved and archived, then the original records may be deleted. 1481

Retaining the original record in an accessible format opens the possibility 1482

that the original record may be improperly used as a basis for further 1483

regulated activity. Firms need to be aware that regulators will base their 1484

assessment on the records that are actually used in their business processes. 1485

If a firm has signed paper copies in a locked file cabinet and the staff 1486

uses an electronic database, regulators are going to expect to see controls 1487

on the database and not the file cabinet. 1488

1489

5.7.1 Hybrid Records 1490

Under certain circumstances it may be acceptable to archive records in a 1491



of 198

format other than electronic e.g. paper or in a standard electronic format 1492

such as PDF, depending on the manner the record will be used. Some of the 1493

issues to consider include: 1494

1495

Data integrity of the records – complete record 1496

Future use of the record, including needs to sort or trend data 1497

The risk assumed with moving the records to a non-processible format 1498

or media 1499

Availability of the records to regulators. 1500

While PDF is an electronic format, and does offer some possibility to manage 1501

records using audit trails and digital signature, conversion to PDF generally 1502

sacrifices the ability to process the data. PDF does provide the ability to 1503

execute some limited searches within records. PDF documents are editable 1504

with certain software by normal means, so controls should be in place to 1505

ensure any final, approved records cannot be modified or deleted and retain 1506

their original content. This should be considered when selecting to what 1507

format to convert records. 1508

1509

The use of non-electronic or standard electronic format like PDF may be an 1510

acceptable archive process as long as all GxP regulations are satisfied, the 1511

records must be complete, preserve their content and meaning, and maintain 1512

record integrity throughout the retention period. Paper and electronic record 1513

and signature components can co-exist (i.e., a hybrid situation) provided 1514

the GxP regulations are met. A justified and well documented risk assessment 1515

is essential when making any decision regarding an alternate format for the 1516

retention of the data. 1517

1518

5.7.2 Information Management Systems 1519

It may make sense to leverage superior data management capabilities (e.g., 1520

audit trailing, consolidated back-up, etc.) in a higher-level system as 1521

opposed to trying to build the same capabilities into several stand-alone 1522

systems. Assuming that the content and meaning of the record is fully 1523

preserved, and all future uses and manipulations of the data are intended to 1524

be in the higher system, this approach should generally preclude any future 1525

manipulation of the original “raw” data file. This can be enforced by removal 1526

of the record as advocated above. Firms need to understand the risks as 1527

well as benefits of such a solution. For example EU Volume 4 in 6.9 states 1528

‘for some kinds of data [e.g. analytical test results, yields, environmental 1529

controls]… it is recommended that records be kept in a manner permitting 1530

trend evaluation.’ If a firm interprets this as requiring the ability to 1531

reprocess the data, transferring it to a LIMS may not be the right choice 1532

unless the LIMS can actually be used to manage raw data files that could be 1533

exported back to the original software. However, it may not even be necessary 1534

to be able to reprocess data to do trend analysis. All foreseeable scenarios 1535

for manipulating the data need to be considered in evaluating the risk of 1536

this solution. The risks and costs associated with validating or verifying 1537

the data migration also must be considered. 1538

Stand-alone system records being managed in this manner would be handled 1539

more consistently, as all data would be managed via the same procedures. The 1540

ability to search is likely to be improved, as all records would be accessible 1541

through one database, with more sophisticated data management tools. 1542

1543

Firms need to consider that many stand-alone systems use proprietary data 1544

formats that will not convert cleanly while preserving content and meaning 1545

of the record. It may be possible to manage data files through the higher-1546

level system, but the records may not be viewable without the use of the 1547

originating system. In such cases a decision must be made whether the ability 1548

to re-process the data is critical; the need for this may decrease as the 1549

record ages. 1550

1551



of 198

5.8 DESTRUCTION 1552

The record retention policy should contain information about how long the 1553

records need to be retained to meet regulatory expectations but also 1554

information about records disposal or destruction. Maintaining records for 1555

longer than the retention is not good records management. Records need to 1556

be periodically reviewed to ensure that the appropriate retention schedule 1557

is applied to records. The procedure should contain information as to how 1558

to dispose of records and what authorization is required. It is essential 1559

that the destruction process ensure that all copies of the records be 1560

destroyed. Record destruction procedures must adequately address privacy 1561

and litigation issues. There must be a documented process for the destruction 1562

of records when they have reached the end of their retention schedule. As 1563

with most processes, it is important that this process be assessed for 1564

effectiveness. 1565

1566

References (MR) [Gail - please move to References] 1567

1. The World Health Organization (WHO) DRAFT Guidance on Good Data and 1568

Record Management Practices (September 2015) 1569

2. The MHRA GMP Data Integrity Definition and Guidance for Industry (March 1570

2015) 1571

3. “Considerations for a Corporate Data Integrity Program” – An ISPE GAMP 1572

Community of Practice Concept Paper 1573

4. “Implementing a Corporate Data Integrity Program”, Michael Rutherford, 1574

PE Data Integrity Special Report, March/ April 2016 1575

5. “The Human Impact on Data Integrity”, a four part series of articles 1576

in the PE Data Integrity Special Report, March/ April 2016 1577

6. FDA - Data Integrity and Compliance With CGMP - Draft Guidance for 1578

Industry [may be final by actual publication] 1579

1580

1581



of 198

6 DATA GOVERNANCE FRAMEWORK 1582

1583


This section describes a framework for data governance, covering: 1585

1586

Definition and overview of data governance 1587

Elements of data governance 1588

Importance of human factors in data integrity 1589

Maturity levels for data governance 1590

1591

6.2 OVERVIEW 1592

Data governance may be defined as: 1593

1594

The sum total of arrangements to ensure that data, irrespective of the 1595

format in which it is generated, is recorded, processed, retained and 1596

used to ensure a complete, consistent and accurate record throughout 1597

the data life cycle. 1598

MHRA [Ref Appendix x, x] 1599

1600

Data governance ensures formal management of records and data throughout the 1601

regulated company. Data governance encompasses the people, processes, and 1602

technology required to achieve consistent, accurate and effective data 1603

handling (See Figure X.1). Data governance provides the structure within 1604

which appropriate decisions regarding data-related matters may be made 1605

according to agreed models, principles, processes, and defined authority. It 1606

may also be considered as a quality assurance and control approach for 1607

applying rigor and discipline to the process of managing, using, protecting, 1608

and improving organizational information. 1609

1610

Organizations have increasingly recognized the need to manage data as an 1611

important corporate asset, and an executive level role, such as a Chief Data 1612

Officer (CDO) or Chief Data Governance Officer or Director for Data 1613

Governance may be appointed to oversee the area. 1614

1615 Figure X.1 People, Processes, and Technology – elements of data governance 1616

1617

For regulated company many elements of a Data Governance are closely related 1618



of 198

to regulatory requirements and may be covered by existing aspects of the 1619

life sciences quality management system. 1620

1621

The specification, design, validation and operation of processes and systems 1622

should meet the defined requirements for regulated data integrity. This 1623

should include ensuring appropriate control over intentional, unintentional, 1624

authorized and unauthorized changes to regulated data. 1625

1626

Training on the importance of data integrity principles and policies is 1627

required. Senior management should create a working environment that 1628

encourages a culture of willing and open reporting of errors, omissions and 1629

abnormal results. Data governance should also address data ownership 1630

throughout the data life cycle. 1631

1632

The risk to data integrity, especially as it may be related to risk to product 1633

quality and product safety should be managed by an established Quality Risk 1634

Management process, defined as part of the Quality Management System. Risk 1635

to data integrity associated with any outsourcing of activities, or use of 1636

service providers should be assessed and managed though appropriate formal 1637

agreements. 1638

1639

The data governance approach should be holistic, proportionate, and 1640

integrated: 1641

1642

The data governance system should be integral to the pharmaceutical 1643

quality system described in EU GMP chapter 1. The effort and resource 1644

assigned to data governance should be commensurate with the risk to 1645

product quality, and should also be balanced with other quality 1646

assurance resource demands. As such, manufacturers and analytical 1647

laboratories are not expected to implement a forensic approach to data 1648

checking on a routine basis, but instead design and operate a system 1649

which provides an acceptable state of control based on the data 1650

integrity risk, and which is fully documented with supporting 1651

rationale. 1652

MHRA [Ref Appendix x, x] 1653

1654

While this Guide is primarily focused on electronic record and data 1655

integrity, it should be noted that manual systems and paper based records 1656

may also be a key area of data integrity failure. Risks associated with 1657

manual systems, including risks at the interface between manual and 1658

computerised systems should also be considered. Computerised systems related 1659

activities are only one part of the broader governance framework, and 1660

equivalent considerations are required for paper-based systems and processes. 1661

1662

Human factors are a critical aspect of an affective Data Governance 1663

Framework, and the topics of cultural differences, human error, understanding 1664

and awareness, and motivation and behaviour are covered in detail in Appendix 1665

X Human Factors. 1666

1667

6.3 ELEMENTS OF THE DATA INTEGRITY FRAMEWORK 1668

1669

The overall data integrity framework consists of the following elements: 1670

1671

Goals and Objectives 1672

Organization and Data Ownership 1673

o Leadership and Management Responsibility 1674

o Roles and Responsibilities 1675

o Policies and Standards 1676

o Awareness and Training 1677

Strategic Planning and Data Integrity Program 1678



of 198

Data Life cycle 1679

o Data Management 1680

o Incident and Problem Management 1681

o Access and Security management 1682

o Quality Risk Management 1683

Supporting Processes 1684

o Auditing 1685

o Metrics 1686

o Classification 1687

o Validation 1688

IT Architecture and Infrastructure 1689

Maturity level model 1690

1691

(See Figure x.2 Data Governance Framework.) 1692

1693

Some data governance elements are covered in the relevant sub-sections below, 1694

and some of the elements above are covered in detail in other sections of 1695

this Guide. 1696

1697

Element Reference to further information

1. Awareness and Training Appendix x (Human Factors)

2. Auditing, metrics, and

classification

Appendix y

3. IT Architecture and

Infrastructure

Appendix z

4. Quality Risk Management Section 4

5. Validation Section 3.4.2

1698

1699 1700

Figure X.2 Data Governance Framework 1701

1702 ISPE D

RAFT © 20

16



of 198

6.3.1 Scope and Objectives 1703

Effective data governance requires the organization to be clear on the scope 1704

and objectives. General goals and objectives for data governance in any 1705

organization may include: 1706

1707

Increasing consistency and confidence in decision making 1708

Decreasing compliance risk 1709

Improving data security and privacy 1710

Maximizing the potential business value of data 1711

Clarifying accountability for data quality 1712

Minimizing or eliminating re-work 1713

Optimizing process effectiveness 1714

1715

For a specific company, data governance activities may have different scope 1716

and objectives depending on the nature, situation, and the business context 1717

of the organization. Examples may include: 1718

1719

Policy, Standards, and Strategy, e.g. where a company may be currently 1720

fragmented or organized in siloes, but moving towards enterprise 1721

solutions or centralized processes 1722

Data Quality, e.g., where problems in this area may be caused by mergers 1723

or acquisitions, or a change in business scope 1724

Privacy and Security , e.g., due to concerns about compliance with 1725

national or regional Data Privacy regulations 1726

Architecture / Integration, e.g. due to major computerized system 1727

acquisition or update 1728

Data Warehouses and BI, e.g. related to the proposed adoption of a 1729

specific business tool 1730

Management Support, e.g., to resolve conflict or tension between 1731

operational and compliances objectives 1732

1733

For most organizations it is likely that some focus and prioritization will 1734

be required. Although the overall structures and concepts in this Guide would 1735

be appropriate for many companies in many sectors, the discussion will 1736

concentrate on current focus areas for a regulated life science organization, 1737

specifically around compliance, regulated data quality, and managing risks 1738

to data integrity, and therefore ultimately product quality and patient 1739

safety. 1740

Specific data governance goals and objectives for a regulated organization 1741

are likely to include: 1742

1743

Effective compliance with GxP regulations 1744

Minimizing inspection risk 1745

Compliance with various data privacy laws and regulations 1746

Ensuring adequate data security and access control 1747

Assessing and controlling regulated data integrity risk 1748

Demonstrating fitness for intended use through computerized system 1749

validation 1750

Achieving these objectives effectively throughout a wide range of 1751

sites encompassing many local cultures and circumstances 1752

1753

For a regulated organization, the key overarching objectives should be 1754

product quality and patient safety, for which appropriate data governance 1755

delivering acceptable data integrity is a pre-requisite. 1756

1757

Data Governance goals, objectives, and scope should be defined and 1758

communicated by senior management based on significant input from Business 1759

Process Owners, Quality Assurance, and Information Technology functions. 1760



of 198

1761

6.3.2 Organization and Data Ownership 1762

Data Governance should not be regarded as primarily an IT issue. Effective 1763

data governance in regulated life science organizations requires 1764

communication and co-operation between business process owners, Quality 1765

Assurance, and the IT department, with sufficient support and leadership by 1766

senior management. 1767

1768

6.3.2.1 Leadership and Management Responsibility 1769

Senior management with executive authority have a responsibility to promote 1770

the requirements for data integrity through the organization, to provide 1771

appropriate resources, to resolve issues, define priorities, and ensure that 1772

data integrity expectations are achieved across all levels of the 1773

organization. Senior management should lead by example, and reinforce the 1774

messages by positive action, rewarding appropriate behaviour, and taking the 1775

necessary management action when data integrity expectations and polices are 1776

not met. 1777

It may be helpful to create a Data Governance Council, or equivalent, ensuring 1778

adequate input from business process owners, Quality Assurance, and IT. Such 1779

a body would play a key role in defining policies, dealing with serious data 1780

related problems or incidents, taking decisions on roles and 1781

accountabilities, and leading initiatives aimed at raising awareness. Such 1782

a body would typically be led by a member of executive management. 1783

1784

For further information on Management Responsibility see Appendix x (Human 1785

Factors) Section y. 1786

1787

6.3.2.2 Roles and Responsibilities 1788

Two key roles associated with regulated Computerized Systems are defined in 1789

EU Annex 11 [ref] and GAMP 5 [ref]: 1790

1791

Process Owner 1792

System Owner 1793

1794

The terms and definitions used in specific organizations and the boundaries 1795

between such roles may vary. The use of the terms in this guide and the role 1796

descriptions below are aligned with the definitions in GAMP 5 and Annex 11. 1797

1798

Process Owner 1799

This is the owner of the business process or processes being managed. The 1800

process owner is ultimately responsible for ensuring that the computerized 1801

system and its operation is in compliance and fit for intended use in 1802

accordance with applicable SOPs. The process owner also may be the system 1803

owner. In many cases the Process Owner will be the de-facto owner of the 1804

data residing on the system. 1805

Specific activities may include: 1806

1807

approval of key documentation as defined by plans and SOPs 1808

providing adequate resources (personnel including SMEs, and financial 1809

resources) to support development and operation of the system 1810

ensuring adequate training for end users 1811

ensuring that SOPs required for operation of the system exist, are 1812

followed, and are reviewed periodically 1813

ensuring changes are approved and managed 1814

reviewing assessment/audit reports, responding to findings, and taking 1815

appropriate actions to ensure GxP compliance 1816

1817

System Owner 1818

The System Owner is responsible for the availability, and support and 1819



of 198

maintenance, of a system and for the security of the data residing on that 1820

system. The system owner is responsible for ensuring that the computerized 1821

system is supported and maintained in accordance with applicable SOPs. The 1822

system owner also may be the process owner. 1823

1824

The System Owner acts on behalf of the users. Global IT systems may have a 1825

global system owner and local system owners to manage local implementation. 1826

Specific activities may include: 1827

1828

approval of key documentation as defined by plans and SOPs 1829

ensuring that SOPs required for maintenance of the system exist and 1830

are followed 1831

ensuring adequate training for maintenance and support staff 1832

ensuring changes are managed 1833

ensuring the availability of information for the system inventory 1834

and configuration management 1835

providing adequate resources (personnel including SMEs, and 1836

financial resources) to support the system 1837

reviewing audit reports, responding to findings, and taking 1838

appropriate actions to ensure GxP compliance 1839

1840

The term Data Steward is often used in the context of data governance. The 1841

term, however, is not yet standardized, and does not have a simple one-to-1842

one relationship with Process Owner, System Owner, or other similar role 1843

names used in GxP regulations and guidance. It may be a functional role, or 1844

included as part of a wider job description. 1845

1846

The term may be used differently and may play different roles in the data 1847

governance framework in specific organization. A Data Steward may, for 1848

instance be a senior decision maker who serves on the data governance council 1849

or similar and contributes to policies. Such individuals may also be referred 1850

to as Data Governors or Data Champions or data Governance Authorities. 1851

1852

In this Guide, however, we propose that a Data Steward is defined as a person 1853

with specific tactical coordination and implementation responsibilities for 1854

data integrity. A Data Steward is responsible for carrying out data usage, 1855

management and security policies as determined by wider data governance 1856

initiatives, such as acting as a liaison between the IT department and the 1857

business. They are typically personnel on the shop floor or in the 1858

laboratories who actually generate, manage, and handle the data. 1859

1860

6.3.3 Policies and Standards 1861

Data governance policies and standards should be established, and 1862

communicated to all relevant staff. 1863

1864

Data policies define the expectations and rules covering the integrity, 1865

security, quality, and use of data during its life cycle. Data standards 1866

provide details on how to achieve the defined polices. They may include 1867

naming standards, data modelling standards, and data architecture standards. 1868

1869

It should be clear who has responsibility for defining, reviewing, approving 1870

and monitoring compliance with, policies and standards. Such policies and 1871

standards may be developed by a Data Governance Council, or similar. 1872

1873

Based on the policies and standards, practical procedures, typically in the 1874

form of Standard Operating Procedures (SOPs) should be established, defining 1875

key activities and processes related to Data Integrity. Examples include 1876

procedures for handling adverse event and complaint data and evidence, manual 1877

chromatography integration practices, and batch record assembly and review. 1878

1879



of 198

These policies, standards, and procedures as described above should be 1880

incorporated as an integral part of the overall Quality Management System, 1881

and unnecessary duplication should be avoided. 1882

1883

6.3.4 Awareness and Training 1884

Regulated companies should ensure sufficient training in the importance of 1885

data integrity principles, and awareness and training on detailed regulatory 1886

requirements and organizational polices and standards. 1887

1888

The aim is to achieve a state where all staff routinely follow accepted data 1889

integrity principles and practices, from a position of awareness and 1890

understanding, rather than depending on policing and technical controls to 1891

prevent users from doing the wrong thing. 1892

1893

For further information on training see Appendix x (Human Factors) Section 1894

Y. 1895

1896

6.3.5 Technology and Tools 1897

Data governance technology, including, related to, or developed from data 1898

quality management or business process management tools, may be used to 1899

automate the definition, management, and enforcement of business rules at 1900

the data level. 1901

1902

Technology may assist in improving data quality and the data’s fitness for 1903

intended use by providing tools for data parsing and standardization, data 1904

cleansing against data quality standards, integrity and consistency rules, 1905

matching and linking between datasets, identification of data quality 1906

problems, and generally ensuring conformance to the defined policies and 1907

standards of the organization. 1908

Technology Issues are discussed further in Appendix X. 1909

1910

6.3.6 Strategic Planning and Data Integrity Program 1911

Data Governance initiatives and programs must be sufficiently strategic and 1912

high level to provide a clear vision and direction to the organization as a 1913

whole, while also ensuring that critical immediate actions are prioritized, 1914

facilitated, and delivered. Effective data integrity initiatives and programs 1915

require senior management sponsorship at an appropriate. 1916

1917

Short term needs must be addressed (especially critical compliance 1918

requirements) while the wider aspects of Data Governance in the organization 1919

are being developed and overall maturity level increases. See Section 3.2, 1920

Immediate Actions, for examples of critical immediate actions. 1921

1922

Data Governance programs should be scaled based on the size and complexity 1923

of the business unit, level of compliance risk, and potential impact on 1924

product quality and patient safety. 1925

1926

As noted in MHRA Guidance [Ref.] the effort and resource assigned to data 1927

governance should be commensurate with the risk to product quality, and 1928

should also be balanced with other quality assurance resource demands. 1929

1930

Communication should clearly link the Data Integrity program with immediate 1931

business objectives or regulatory compliance challenges and requirements, so 1932

that the value of the program is obvious to all stakeholders. A communication 1933

plan, and if necessary a change management plan, should be established to 1934

ensure ongoing stakeholder engagement and understanding, and a smooth 1935

transition to new ways of working. 1936

1937

A process should be established for systematically incorporating learning 1938

points, and building them into the program and sharing with stakeholders. A 1939

repository of items such as templates, checklists, example citations, and 1940



of 198

FAQs on an internal information sharing and collaboration site or similar 1941

should be considered. 1942

For further discussion of corporate Data Integrity Programs, Appendix xx. 1943

For further information on knowledge and information sharing see Appendix x 1944

(Human Factors) Section Y. 1945

1946

6.3.7 Data Life Cycle and Data Management 1947

The data life cycle, should be defined in Standards and procedures. The data 1948

life cycle is described in detail in Section 5. 1949

Appropriate data management functions should be established to implement the 1950

policies and standards established by the Data Governance framework, 1951

including: 1952

1953

Data architecture management 1954

Data quality management 1955

Master and reference data management 1956

1957

Data architecture models (which may be conceptual, logical or physical) may 1958

be defined in the form of data flow diagrams, entity-relationship diagrams, 1959

or system architecture diagrams. These together with data standards and 1960

procedures define how the data life cycle is implemented within the 1961

organization. 1962

1963

Data quality relates to the data’s fitness to serve its intended purpose in 1964

a given context within a specified business or regulatory process. Data 1965

quality management activities address aspects including accuracy, 1966

completeness, relevance, consistency, reliability, and accessibility (for 1967

further details see Section 5 where ALCOA and ALCOA+ is discussed). 1968

1969

Data quality management enforces the established standards to ensure that 1970

data meets the relevant business definitions and rules of the Data Governance 1971

framework. 1972

1973

6.4 HUMAN FACTORS IN DATA INTEGRITY 1974

Consideration of various Human Factors is critical for effective data 1975

integrity. Success requires the consideration of: 1976

1977

Understanding and mitigating the impact of corporate and local 1978

cultures. 1979

Implementing mechanisms to minimize human error rates 1980

Reducing motivation, pressures, and opportunities for data 1981

falsification and fraud 1982

Promoting impartiality in quality related decision making 1983

Applying effective behavioural controls – influencing behaviours and 1984

attitudes 1985

Data auditing and periodic review 1986

1987

These topics and other related aspects are discussed in detail in Appendix 1988

X Human Factors. 1989

1990

6.5 DATA INTEGRITY MATURITY MODEL 1991

This section describes an approach to assessing the maturity level of an 1992

organization in relation to data integrity. 1993

1994

Less mature organizations put their effort on managing the current as-is 1995

situation, often defining controls based on procedures that are typically 1996

aimed at detecting failure, and may achieve varying degrees of success in 1997

doing this. More mature organizations focus on modifying their processes and 1998

systems to use appropriate technical controls if they are available, and 1999



of 198

evaluate systems for gaps prior to use. The most mature organizations design 2000

integrity into their processes before systems and technology are purchased, 2001

and do not purchase systems that cannot be configured to provide adequate 2002

data integrity. 2003

2004

The Data Integrity Maturity Model described is a simple representation of 2005

the regulated company, based on the status of the essential elements of 2006

effective processes for data integrity. 2007

2008

In this section maturity areas are identified and maturity factors are 2009

described for key aspects related to Data Integrity. 2010

2011

Based on this model companies can assess their current state of maturity, 2012

and understand what actions and improvements are required to reach the next 2013

maturity level. 2014

2015



of 198

2016 Level 1 Level 2 Level 3 Level 4 Level 5

Undefined

Uncontrolled

Not monitored

No Evidence

Partially

defined

Not formally

controlled

Not formally

monitored

Person

dependent

Defined

policy and

processes

Inconsistent

application

Inconsistent

monitoring

Defined

policy and

processes

Routine

application

Routine

monitoring

Proactive

Continuous

improvement

2017

2018

2019

Figure x.3 Data Integrity Maturity Model 2020

2021

Note that Maturity level is in reality a continuum rather than discrete level 2022

or steps, so an organization may span more than one level for some areas, 2023

and organizations or parts of organizations may display attributes of more 2024

than one level. 2025

Different sites, business areas, or departments within an organization may 2026

well differ in data integrity maturity. For any specific assessment, it is 2027

recommended that the scope is well defined, to avoid confusion and 2028

inconsistent results. 2029

2030

Table X.1 Maturity Factors defines the areas to be assessed for maturity, 2031

and for each area defines the maturity factor to be assessed against. 2032

2033

Appendix X, Data Integrity Maturity Level Characterization gives more 2034

detailed examples of possible or typical states related to the levels. These 2035

examples are intended to be indicative only, and should be considered and 2036

interpreted within the specific context of individual organizations. 2037

2038

Red Amber Green ISPE D

RAFT © 20

16



of 198

The maturity model may also be used as a rapid and efficient, but relatively 2039

detailed management indicator, enabling organizations to effectively focus 2040

resource and effort. This general approach is very flexible and may be 2041

structured in multiple ways, e.g. by geographical area, site, or department. 2042

As can be seen from Figure x.3 the Maturity Model supports a “red”, “amber” 2043

“green” dashboard approach. (See also the Executive Risk Dashboard, Section 2044

3.2.1, which is at a higher level and more focused on key compliance risks). 2045

2046

Table X.1 Maturity Factors 2047

2048

Maturity Area Maturity Factors

Culture

DI Understanding

and awareness

Awareness of the importance of data integrity, and

understanding of data integrity principles

Corporate culture

and working

environment

A culture of willing and open reporting for errors,

omissions and abnormal results, and willing

collaboration to achieve data integrity objectives

Quality Culture An environment in which employees habitually follow

quality standards, take taking quality-focused

actions, and consistently see others doing so.

Governance and

Organization

Leadership Objectives defined and communicated by executive

management.

Sponsorship Executive management providing appropriate resources

and support.

Structure Appropriate roles and reporting structures.

Stakeholder

Engagement

Engagement of business Process Owners, Quality

Assurance, and key supporting technical groups (e.g.

IT)

Data Ownership Clear ownership of data and data-related

responsibilities

Policies and

Standards

Defined polices and standards on data integrity

Procedures Established procedures defining key activities and

processes

Awareness and

Training

Awareness and training on regulatory requirements

and organizational polices and standards.

Quality Management

System

Established and effective Quality Management System,

focused on patient safety, product quality and data

integrity.

Business process

definition

Clear and accurate definitions of regulated business

processes, covering all key GxP areas

Supplier and service

provider management

Assessment of suppliers and service providers

against agreed standards, and setting up and

monitoring of contracts and agreements to deliver

those standards.

Strategic Planning and

Data Integrity Program

Planning Executive level strategic planning and programs for

improving and/ or maintaining data governance and

data integrity.

Communication Communication and change management processes,

supported by a suitable repository of information

and resources.

Regulatory

Awareness Awareness of applicable regulatory requirements



of 198

Maturity Area Maturity Factors

Traceability Traceability to applicable regulatory requirements

from, e.g., Quality Manual, polices or procedures

Inspection

readiness

Preparation for inspection, including

responsibilities, and inspection readiness

documentation.

Regulatory

Relationship and

communications

Effectiveness of communication with regulatory

authorities, and effectiveness of dealing with

concerns and citations.

Data Life Cycle

Data life cycle

definition

Data life cycle(s) defined in standards and/or

procedures

Quality Risk

Management

Application of risk management (including justified

and documented risk assessments) through the data

life cycle.

Data Management

processes and tools

Established data management processes, supported by

appropriate tools.

Master and

reference data

management

Established processes to ensure the accuracy,

consistency, and control of master and reference

data.

Data Incident and

Problem Management

Established processes to deal with data incidents

and problems, linked with change management and

deviation management as appropriate.

Access and Security

management

Establishing technical and procedural controls for

access management and to ensure the security of

regulated data and records.

Archival and

retention

Establishing processes for ensuring accessibility,

readability and integrity of regulated data in

compliance with regulatory requirements including

retention periods.

Electronic

Signatures

Effective application of electronic signatures to

electronic records, where approval, verification, or

other signing is required by applicable regulations.

Audit trails Usable and secure audit trails recording the

creation, modification, or deletion of GxP data and

records, allowing effective review either as part of

normal business process or during investigations.

Data Life Cycle

Supporting Processes

Auditing Auditing against defined data quality standards,

including appropriate techniques to identify data

integrity failures

Metrics Measuring the effectiveness of data governance and

data integrity activities

Classification and

assessment

Data and system classification and compliance

assessment activities

CS Validation and

compliance

Established framework for achieving and maintaining

validated and compliant computerized systems

Control Strategy Proactive design and selection of controls aimed at

avoiding failures and incidents, rather than

depending on procedural controls aimed at detecting

failure

IT Architecture Appropriate IT architecture to support regulated

business processes and data integrity

IT Infrastructure Qualified and controlled IT infrastructure to

support regulated computerized systems

2049

2050



of 198

2051

APPENDICES 2052



of 198

2053

7 AUDIT TRAIL AND AUDIT TRAIL REVIEW 2054

2055


This appendix describes a risk-based approach to audit trails and audit trail 2057

review for GxP regulated systems. It places audit trails in the wider context 2058

of information security, and suggests a practical role for audit trails and 2059

audit trail review within that wider framework. 2060

It outlines the current regulatory requirements for audit trail, as defined 2061

in EU Annex 11 and US FDA 21 CFR Part 11 and associated guidance, and then 2062

describes an overall risk-based strategy for meeting these requirements. It 2063

specifically addresses the topic of audit trail review, exploring and 2064

suggesting flexible and pragmatic approaches to meeting requirements, while 2065

also balancing effort with benefit in terms of safeguarding patient safety, 2066

product quality, and regulated data integrity. 2067

Audit trails, if they are properly specified, implemented, and controlled, 2068

can be very useful in supporting in-process reviews of critical electronic 2069

records and as investigative tools, and this is how they should be regarded. 2070

Indiscriminate review of all audit trail information is an expensive activity 2071

with very low probability of benefit. On the other hand, examining audit 2072

trails for a specific set of records as part of an in-process review or 2073

investigation where data integrity has been determined to be uncertain can 2074

be a powerful tool to help determine the trustworthiness of the records in 2075

question. 2076

Decisions on audit trails and the review of audit trails should be based 2077

upon: 2078

a thorough understanding of the business process supported by the 2079

computerized system 2080

the risk to patient safety, product quality and GxP record and data 2081

integrity 2082

Audit trail review should be part of the routine data review / approval 2083

process, usually performed by the operational area which has generated the 2084

data (e.g. laboratory). 2085

7.2 REGULATORY BACKGROUND 2086

The MHRA Data Integrity Definitions and Guidance (Ref), states that: 2087

Where computerised systems are used to capture, process, report or 2088

store raw data electronically, system design should always provide for 2089

the retention of full audit trails to show all changes to the data 2090

while retaining previous and original data. 2091

It should be possible to associate all changes to data with the persons 2092

making those changes, and changes should be time stamped and a reason 2093

given. 2094

Users should not have the ability to amend or switch off the audit 2095

trail. 2096

The relevance of data retained in audit trails should be considered by 2097

the company to permit robust data review / verification. 2098

The items included in audit trail should be those of relevance to 2099

permit reconstruction of the process or activity. 2100

It is not necessary for audit trail review to include every system 2101

activity (e.g. user log on/off, keystrokes etc.), and may be achieved 2102

by review of designed and validated system reports. 2103

Audit trail review should be part of the routine data review / approval 2104

process, usually performed by the operational area which has generated 2105

the data (e.g. laboratory). 2106



of 198

There should be evidence available to confirm that review of the 2107

relevant audit trails have taken place. 2108

When designing a system for review of audit trails, this may be limited 2109

to those with GMP relevance (e.g. relating to data creation, 2110

processing, modification and deletion etc.). 2111

Audit trails may be reviewed as a list of relevant data, or by a 2112

validated ‘exception reporting’ process. 2113

QA should also review a sample of relevant audit trails, raw data and 2114

metadata as part of self- inspection to ensure on-going compliance 2115

with the data governance policy / procedures. 2116

US FDA regulation 21 CFR Part 11 [ref], in Section 11.10 (e), requires: 2117

Use of secure, computer-generated, time-stamped audit trails to 2118

independently record the date and time of operator entries and actions 2119

that create, modify, or delete electronic records. Record changes shall 2120

not obscure previously recorded information. Such audit trail 2121

documentation shall be retained for a period at least as long as that 2122

required for the subject electronic records and shall be available for 2123

agency review and copying. 2124

2125

Note that this requirement specifically covers operator entries and actions 2126

that create, modify, or delete regulated electronic records, but not all 2127

activities performed by users, and not all system actions. 2128

2129

In the Part 11 Scope and Application Guidance [ref], FDA clarifies their 2130

expectations and interpretation: 2131

2132

We recommend that you base your decision on whether to apply audit trails, 2133

or other appropriate measures, on the need to comply with predicate rule 2134

requirements, a justified and documented risk assessment, and a 2135

determination of the potential effect on product quality and safety and 2136

record integrity. We suggest that you apply appropriate controls based 2137

on such an assessment. Audit trails can be particularly appropriate when 2138

users are expected to create, modify, or delete regulated records during 2139

normal operation. 2140

2141

The guidance clarifies that when applying time stamps (such as in audit 2142

trails), they should be implemented with a clear understanding of the time 2143

zone reference used. In such instances, system documentation should explain 2144

time zone references as well as zone acronyms or other naming conventions. 2145

The guidance also notes that audit trails may be just one among various 2146

physical, logical, or procedural security measures in place to ensure the 2147

trustworthiness and reliability of the records, within the context of a wider 2148

information security management framework. 2149

2150

EU GAMP Annex 11, as revised in 2011, [ref] includes the following clause: 2151

9. Audit Trails 2152

2153

Consideration should be given, based on a risk assessment, to building 2154

into the system the creation of a record of all GMP-relevant changes and 2155

deletions (a system generated "audit trail"). For change or deletion of 2156

GMP-relevant data the reason should be documented. Audit trails need to 2157

be available and convertible to a generally intelligible form and 2158

regularly reviewed. 2159

Again, the focus is clearly on GMP relevant data changes or deletions. The 2160

phrase “regularly reviewed” has caused much discussion, and this appendix 2161

proposes a practical and pragmatic approach to meeting this requirement. 2162

Various other technical and system logs may be used in support of compliance 2163

and investigations, especially in the absence of true audit trails. These, 2164



of 198

however, are not intended to be audit trails in the sense that Part 11 and 2165

Annex 11 require, and that declaring them as such may incur regulatory risk 2166

and potentially a burdensome review processes. 2167

7.3 APPLICATION AND USE OF AUDIT TRAILS 2168

An audit trail is typically used to provide two functions: 2169

Attribution of data related action or change 2170

Traceability of changes 2171

In a wider context, audit trails may also be used as one of the safeguards 2172

to deter, prevent, and detect unauthorized record creation, modification, or 2173

deletion. 2174

Audit trails themselves should be secure from change. For enhanced usability, 2175

if they are available, facilities should be configured to allow the search, 2176

sorting and filtering audit trail data. It must be recognized, however, 2177

that not all applications support this. 2178

Requirements for identifying who performed an action, and when, are 2179

traditionally met in paper-based systems by initialling (or signing) and 2180

dating the relevant record, even though there may be no associated GxP 2181

requirement for a signature. In this case the signature is intended to 2182

identify the person performing the action rather than as an authorisation or 2183

approval. 2184

In an electronic system, an audit trail is one suitable way of meeting such 2185

requirements for identification where there is no need for a regulated 2186

signature. The accuracy and reliability of the audit trail should be verified 2187

during validation. 2188

Some GxP regulations require traceability of creation, modification, or 2189

deletion of regulated records. 2190

In a traditional paper-based system, such a requirement would typically be 2191

implemented as follows: if a user recognizes that a certain data entry is 2192

wrong they strike out the wrong data in a way that it is still readable and 2193

put the correct value next to it with their initials, the date, and in some 2194

cases the reason. 2195

In an electronic system, an audit trail is designed to provide this 2196

traceability. Again, the accuracy and reliability of the audit trail should 2197

be verified during validation. 2198

An audit trail should be applied when users create, modify, or delete GxP 2199

regulated records during normal operation. The audit trail should record the 2200

value of GxP relevant initial records at creation, as well as modifications 2201

and deletions, and the reason for such modification or deletion. 2202

With the exception of entering a reason for a change, audit trails should be 2203

automated, i.e. all audit trail functions should be executed without user 2204

intervention, and secure. The audit trail information should never be 2205

modifiable by the system user. 2206

An electronic audit trail is particularly useful and relevant for high impact 2207

GxP records. Other forms of audit trail, e.g. change control records, may 2208

be an appropriate audit trail method for lower impact records. 2209

Audi trail information should include the following: 2210

The identity of the person performing the action 2211

In the case of a change or deletion, the detail of the change or 2212

deletion, and a record of the original entry 2213

The reason for any change or deletion 2214

The time and date when the action was performed 2215

The need for, and the type and extent of, audit trails should be based on a 2216

documented and justified risk assessment. Specific GxP (predicate) 2217

requirements requiring audit trails may also apply. Alternative approaches 2218



of 198

may be used for low risk records. 2219

Logical and possibly procedural controls should be established for the 2220

management of audit trails, including limitations to the ability to 2221

deactivate, change, or modify the function or the audit trails themselves. 2222

Such procedures should cover the following: 2223

Initial verification of audit trail functionality, and subsequent 2224

verification during change management 2225

Management, monitoring, and periodic formal verification of audit trail 2226

configuration according to an established procedure 2227

Not allowing audit trails be configurable by persons with normal user 2228

privileges 2229

Not allowing audit trails to be turned off (except for well-documented 2230

purposes related to maintaining or upgrading the system, during which 2231

time normal user access must be prevented). 2232

If an audit trail is deemed necessary but the system is incapable of 2233

audit trailing, then other measures, e.g. a logbook, should be 2234

implemented. 2235

Effective segregation of duties and related role-based security, e.g. 2236

system administrator privileges should be restricted to individuals 2237

without a conflict of interest regarding the data 2238

Ensuring that any change to audit trail configuration or settings is 2239

documented and justified 2240

Established and effective procedures for system use, administration, 2241

and change management 2242

The approach to audit trail review should also be based on a documented and 2243

justified risk assessment. Audit trail review should focus on checking that 2244

audit trails are enabled and effective. 2245

To support audit trail objectives, suitable records security controls should 2246

be in place for high risk records, and appropriate segregation of duties 2247

enforced (e.g. such that nobody with a conflict of interest has privileges 2248

that would allow alteration of data or audit trail configuration). 2249

Audit trails should be regarded as only one element in a wider framework of 2250

controls, processes, and procedures aimed at an acceptable level of record 2251

and data integrity. Audit trails should be regarded primarily as a tool to 2252

be used for investigation, as and when required, and as a tool to assist 2253

data integrity review as part of an established business process, rather 2254

than for continuous routine review. 2255

7.4 AUDIT TRAIL REVIEW 2256

As noted previously audit trail review should be part of the routine data 2257

review / approval process, usually performed by the operational area which 2258

has generated the data (e.g. laboratory) in the context of the business 2259

process. 2260

The objective of reviewing audit trails is to identify potential issues that 2261

may result in loss of data integrity. Such issues may include erroneous 2262

data entry, operations conducted by unauthorized persons, data not entered 2263

contemporaneously or falsification of data. It is unlikely that review of 2264

audit trail records outside the context of the business process and process 2265

understanding would be effective in identifying such problems. 2266

Also validated controls minimize the risk of such problems. For example, 2267

segregation of duties and role based security are validated and periodically 2268



of 198

reviewed to ensure that only authorized persons can enter and transact data. 2269

Further, validated data entry verification ensures that results can only be 2270

entered within permitted data ranges and alerts are automatically generated 2271

when data is outside defined quality limits. 2272

If we draw parallels with the management of paper records there are a number 2273

of different forms of audit trail. 2274

1) Audit trail of process operations 2275

2) Document histories 2276

3) Hand amended data on written records, typically to address a mistake 2277

in recording of original results 2278

In the case of (1), audit trail of process operations are also typically 2279

embedded within the electronic record and as such, this form of audit trail 2280

is reviewed during the approval process of the electronic record. 2281

For (2), document histories provide an opportunity for reviewers to determine 2282

the specific changes made to a document during the review and approval cycle. 2283

Electronic audit trails may provide similar opportunity for reviewers and 2284

approvers of electronic documents. In fact, it is likely that such documents 2285

contain a history embedded in the document itself as with the paper 2286

counterpart. An audit trail is typically not intended to be the equivalent 2287

of a document change history log. 2288

Electronic audit trails as defined by current global regulations are largely 2289

biased towards (3). The primary objective of the review of hand amended 2290

records is to ensure that the amendment is legible, traceable and that the 2291

revised data is within permitted range. As discussed earlier, in the 2292

electronic world other controls such as data range verification and role 2293

based security provide a proactive means to minimize the risk of data 2294

integrity issues. In such cases, validation and security management 2295

processes are far more effective than reviewing the audit trail. 2296

It may be argued that internal audit should address the management of 2297

electronic records in the same way that it would paper records. However, 2298

internal audit would not require all records to reviewed, or even a 2299

statistical sample. 2300

The true value of electronic audit trails is in the support of specific 2301

investigation, where a potential problem or fraudulent act has been 2302

highlighted, and the audit trail is used to confirm or otherwise the existence 2303

of the problem. Even in this scenario, the audit trail would be only one 2304

element of the investigation. Periodic review of audit trails has limited 2305

scope for identifying such issues. For example audit trails will not detect 2306

that an analyst entered “2” when the value was really “5”. Much more in-2307

depth analysis is required to determine that the result from an instrument, 2308

for instance, does not match the entered data in the Laboratory Information 2309

Management System. 2310

Current electronic audit trail solutions vary in degree of effort required 2311

to access and interpret them. Some common challenges with audit trail 2312

solutions include: 2313

Audit trails may require specialist tools to access them and are not 2314

readily available to system users 2315

System logs may need to be translated from technical data to business 2316

information 2317

Audit trails may be very extensive and identifying specific required 2318

information is difficult 2319

Audit trails may contain much information that is irrelevant from the 2320

perspective of the main objective of seeking to ensure data integrity 2321

As many systems are purchased products, not all specific details of the 2322

available audit trail are always under the control of regulated company 2323

implementing and using the systems. 2324

Many solutions may be technically “compliant” in terms of the information 2325



of 198

that is recorded, but limited thought may have been given to the actual 2326

business use of the audit trail information, and as such it would be a 2327

difficult and costly exercise to support in-process or periodic review of 2328

audit trail information, especially compared to the likely value of such 2329

reviews. 2330

2331



of 198

2332

8 GAMP 5 QUALITY RISK MANAGEMENT 2333

2334


This appendix summarizes the key aspects of Quality Risk Management as 2336

described in GAMP 5 [Ref]. 2337

Quality Risk Management is a systematic process for the assessment, control, 2338

communication, and review of risks. 2339

Application of Quality Risk Management enables effort to be focused on 2340

critical aspects of a computerized system in a controlled and justified 2341

manner. 2342

Quality Risk Management should be based on clear process understanding and 2343

potential impact on patient safety, product quality, and data integrity. 2344

8.2 OVERVIEW OF QUALITY RISK MANAGEMENT 2345

Qualitative or quantitative techniques may be used to identify and manage 2346

risks. Controls are developed to reduce risks to an acceptable level. 2347

Implemented controls are monitored during operation to ensure ongoing 2348

effectiveness. 2349

Managing the risks may be achieved by: 2350

o elimination by design 2351

o reduction to an acceptable level 2352

o verification to demonstrate that risks are managed to an acceptable 2353

level 2354

It is desirable to eliminate risk, if possible, by modifying processes or 2355

system design. Design reviews can play a key role in eliminating risk by 2356

design. Risks that cannot be eliminated by design should be reduced to an 2357

acceptable level by controls or manual procedures. Risk reduction includes 2358

applying controls to lower the severity, decrease probability, or increase 2359

detectability. 2360

A systematic approach should be defined to verify that the risk associated 2361

with a system has been managed to an acceptable level. The overall extent of 2362

verification and the level of detail of documentation should be based on the 2363

risk to patient safety, product quality, and data integrity, and take into 2364

account the complexity and novelty of the system. 2365

The information needed to perform risk assessments may become available, and 2366

should be considered, at different stages in the life cycle. For example, 2367

the high-level risks associated with a business process need to be understood 2368

before the risks associated with specific functions of computerized systems 2369

can be assessed. 2370

The ICH Q9 Guideline [ref] (since adopted as EU GMP Annex 20) describes a 2371

systematic approach to quality risk management intended for general 2372

application within the pharmaceutical industry. It defines the following two 2373

primary principles of quality risk management: 2374

The evaluation of the risk to quality should be based on scientific 2375

knowledge and ultimately link to the protection of the patient. 2376

The level of effort, formality, and documentation of the quality risk 2377

management process should be commensurate with the level of risk. 2378

In the context of computerized systems, scientific knowledge is based upon 2379

the system specifications and the business process being supported. 2380

8.3 QUALITY RISK MANAGEMENT PROCESS 2381

The following five-step Quality Risk Management Process is based on the 2382

approach defined in ICH Q9. 2383

2384

Figure x – Quality Risk Management Approach 2385



of 198

2386 2387

Step 1 – Perform Initial Risk Assessment and Determine System Impact 2388

An initial risk assessment should be performed based on an understanding of 2389

business processes and business risk assessments, user requirements, 2390

regulatory requirements, and known functional areas. Any relevant previous 2391

assessments may provide useful input, and these should not be repeated 2392

unnecessarily. 2393

The results of this initial risk assessment should include a decision on 2394

whether the system is GxP regulated (i.e. GxP assessment). It also should 2395

include an overall assessment of system impact. 2396

Step 2 – Identify Functions with Impact on Patient Safety, Product Quality, 2397

and Data Integrity 2398

Functions which have an impact on patient safety, product quality, and data 2399

integrity should be identified by building on information gathered during 2400

Step 1, referring to relevant specifications, and taking into account project 2401

approach, system architecture, and categorization of system components. 2402

Step 3 – Perform Functional Risk Assessments and Identify Controls 2403

Functions identified during Step 2 should be assessed by considering possible 2404

hazards, and how the potential harm arising from these hazards may be 2405

controlled. 2406

It may be necessary to perform a more detailed assessment that analyzes 2407

further the severity of harm, likelihood of occurrence, and probability of 2408

detection. Section x describes an example detailed assessment process. 2409

The judgment as to whether to perform detailed assessment for specific 2410

functions should be dealt with on a case-by-case basis and the criteria can 2411

vary widely. 2412

Appropriate controls should be identified based on the assessment. A range 2413

of options is available to provide the required control depending on the 2414

identified risk. These include, but are not limited to: 2415

o modification of process design 2416

o modification of system design 2417

o application of external procedures 2418

o increasing the detail or formality of specifications 2419

o increasing the number and level of detail of design reviews 2420

o increasing the extent or rigor of verification activities 2421



of 198

Where possible, elimination of risk by design is the preferred approach. 2422

Step 4 – Implement and Verify Appropriate Controls 2423

The control measures identified in Step 3 should be implemented and verified 2424

to ensure that they have been successfully implemented. Controls should be 2425

traceable to the relevant identified risks. 2426

The verification activity should demonstrate that the controls are effective 2427

in performing the required risk reduction. 2428

Step 5 – Review Risks and Monitor Controls 2429

During periodic review of systems, or at other defined points, an 2430

organization should review the risks. The review should verify that controls 2431

are still effective, and corrective action should be taken under change 2432

management if deficiencies are found. The organization also should consider 2433

whether: 2434

o previously unrecognized hazards are present 2435

o previously identified hazards are no longer applicable 2436

o the estimated risk associated with a hazard is no longer acceptable 2437

o the original assessment is otherwise invalidated (e.g., following 2438

changes to applicable regulations or change of system use) 2439

8.4 EXAMPLE FUNCTIONAL RISK ASSESSMENT APPROACH 2440

Where these are required, functional risk assessments should be used to 2441

identify and manage risks to patient safety, product quality, and data 2442

integrity that arise from failure of the function under consideration. This 2443

is covered by steps 2 and 3 of the process. 2444

Functions with impact on patient safety, product quality, and data integrity 2445

are identified by referring to the user requirements specification (URS), 2446

functional specification (FS), and the output of the initial risk assessment. 2447

Risk management aims to establish controls such that the combination of 2448

severity, probability of occurrence, and detectability of failures is reduced 2449

to an acceptable level. Severity refers to the possible consequence of a 2450

hazard. 2451

The method presented in this section provides a simplified functional risk 2452

assessment tool. It is not mandatory: other detailed risk assessment methods 2453

may be used. It may be used, if necessary and appropriate, to support step 2454

3 of the 5 step process. 2455

Each of the hazards identified for a function is assessed in two stages, as 2456

shown in Figure X: 2457

Severity of impact on patient safety, product quality and data integrity is 2458

plotted against the likelihood (Probability) that a fault will occur, giving 2459

a Risk Class. 2460

Risk Class is then plotted against the likelihood that the fault will be 2461

detected (Detectability) before harm occurs giving a Risk Priority. 2462

2463

Figure x.x : Risk Assessment Method2464



of 198

2465 The Risk Priority obtained helps to focus attention on areas where the 2466

regulated company is most exposed to hazards. Note that the identification 2467

of controls to manage risk to an acceptable level is the main objective. 2468

8.5 RISK MANAGEMENT THROUGHOUT THE SYSTEM LIFE CYCLE 2469

Appropriate risk management processes should be followed throughout the life 2470

cycle in order to manage identified risks and to determine the rigor and 2471

extent of the activities required at each phase of the life cycle. 2472

While risk-based decision making should be used throughout the life cycle, 2473

different approaches may be appropriate to different situations, ranging from 2474

formal risk assessments to decisions taking into account pertinent risk 2475

factors. 2476

For example, formal risk assessments are usually performed at several stages 2477

when developing new software. A formal risk assessment would normally not be 2478

required, however, when determining the need for a formal supplier audit. 2479

This risk-based decision, typically, is made and documented by the project 2480

team also taking into account novelty and complexity, the categorization of 2481

components, and any intention to leverage supplier documentation. 2482

Figure x shows the typical use of risk-based decision making throughout the 2483

life cycle. 2484

2485

Figure x Typical Use of Risk-Based Decision Making2486



of 198

2487 2488



of 198

2489

9 RISK CONTROL MEASURES FOR RECORD, DATA, AND SIGNATURE INTEGRITY 2490

2491


This Appendix discusses various risk control measures that can be used to 2493

manage risks, as identified by the process described in Section X of this 2494

Guide. The control measures should be aimed at eliminating or reducing the 2495

probability of occurrence of the harm, reducing the severity of harm, or 2496

increasing the probability of detection. The rigor and extent of controls 2497

will depend upon the impact of the electronic record and identified risks to 2498

those data and records. 2499

This appendix also discusses principles and controls for the application of 2500

electronic signatures. 2501

Controls for hybrid and paper records are discussed in Appendix x. 2502

9.2 RECORD AND DATA CONTROLS 2503

Controls may be applied at different levels, including for example: 2504

Organizational 2505

Infrastructure 2506

System 2507

Database 2508

Record 2509

Field 2510

Controls may be behavioural, procedural, or technical in nature. 2511

The underlying behavioural controls are described in Section x Governance 2512

and Section Y on Human Factors. 2513

Procedural and technical controls available to reduce risks to an acceptable 2514

level include: 2515

Security and user management 2516

Backup and restore 2517

Disaster recovery and business continuity 2518

Change Management 2519

Validation 2520

Audit trail 2521

Copying controls 2522

Retention controls 2523

Software controls 2524

Hardware controls 2525

Policies and procedures 2526

Training and experience 2527

2528

A combination of these controls may be necessary to adequately manage the 2529

risk. The selected controls should be implemented, verified, and documented. 2530



of 198

Many of these controls will be implemented at the system level (e.g., audit 2531

trail). The implementation of procedural controls should be considered at a 2532

corporate, site, or department level as appropriate, to minimize unnecessary 2533

duplication of procedures. 2534

9.3 IMPLEMENTATION OF CONTROLS 2535

2536

Controls may be implemented in different ways and with differing degrees of 2537

rigor. Table 4.1 shows how various types of controls may be implemented. 2538

Table x.1: Possible Implementation of Controls 2539

2540

Control Possible Implementation and Scalability Options

Security and

User Management Physical access security

Formal access authorization

Confirming identity of new user before granting access

Unique user identification

Different user-id/password combinations for logon and

signatures

Providing defined profiles for individual users or

groups

Clear separation of server administration, application

administration and user roles and responsibilities

Limiting write, update, or delete access (e.g., to key

users)

Enforced password changing

Enforced minimum password length and format

Idle time logout

Management of lost or compromised passwords

Group access (sharing of access accounts)

Proactive monitoring for attempted breaches

Automated measures on attempted unauthorized access

(e.g., lock account, notify management)

Limiting and controlling use of super-user accounts

Testing and renewal of identity devices or tokens



of 198


Backup and

Restore Formality of process

Documented testing of process

Frequency

Redundancy (e.g., number of tapes in cycle)

Auto or manual processes

Backup verification

Backup media

Storage conditions

Storage location(s) including remote storage locations

Media refresh

High availability system architecture

Periodic testing throughout retention time

Amount of documentation retained

Disaster

Recovery and

Business

Continuity

Service level agreements

Formal contracts for restoration of service

Defined allowable time of outage

Recovery mechanisms (e.g., hot standby, procedural)

Documented testing of the plan

Definition of defined recovery point

Documented procedures for business continuity and

number of personnel trained in these procedures



of 198


Change

Management Extent of QA involvement (e.g., Procedural

authorization vs. individual approval vs. audit

verification)

Defined roles and responsibilities for change

assessment, authorization, review and approval

Formality and roles involved in authorization

Formality and roles involved in different types of

review (which can include design review /risk

assessment)

Formality and roles involved in approval

Amount of testing carried out

Formality of go live process after upgrade

Amount of documentary evidence retained

Validation Extent of QA involvement

Formality of process with defined roles and

responsibilities

Degree of specification

Degree of review

Nature, scope & degree of testing, including controls

implemented in support of electronic records and

signatures

Roles involved in review

Roles involved in approval

Amount of documentary evidence retained



of 198


Audit Trail Type (automatic, manual, combination)

Date and time stamped

Identification of time zone

Amount of information retained (who/what/when)

Access control and security of the audit trail

Ability to change the audit trail

Retention of the audit trail

Backup and restore of the audit trail

Procedures for managing the audit trail

Retention of previous versions of data

Purpose: e.g. as a part of normal business data

verification, for auditing of planned authorized

changes to data, or for detecting unauthorized changes

Copying

Controls (see

also retention

below)

Format of copy (common portable electronic, paper)

Reference to original on copy

Relationship with original (e.g., exact copy, summary)

Preservation of meaning and content

Search, sort, and trend capabilities

Process for producing copies (time required, access

levels)

The method for controlling the exact copy, e.g. use of

cyclic redundancy check (CRC-32) or message digest

(MD5)



of 198


Retention

Controls Retention periods

Definition of what is being retained

Retention of associated data (e.g., audit trails,

configuration information)

Capacity limits

Automatic or requiring human intervention

Ability to reprocess data

Involvement of QA

Formal disposal procedure

Periodically test ability to retrieve records

throughout retention period

Media maintenance procedures throughout retention

period

Ability to read physical media

Dependence on original version of software

application

Dependence on original version of operating system

Dependence on original configuration of hardware

Software

Controls User identity checks

Checksums and other verification of data transfer

Standard network protocols for data transfer

Automatic functionality to reduce human error, e.g.

use of barcodes

sequence enforcement

Measurement redundancy in critical applications

Data entry checking

Error handling

Alarms

Notification of software failure

Audit trail (treated separately, see above)

Prompting for confirmation of action

Monitoring tools (e.g., event logs)



of 198


Hardware

Controls Mirrored or RAID drives

UPS

Contingency in sizing of hardware

Network monitoring (could be also software control)



of 198


Policies and

Procedures Formality of policies and procedures

Extent of QA involvement

Formality and roles involved in authorization

Formality and roles involved in review

Formality and roles involved in approval

Internal audit processes to confirm adherence to

procedures

Policies & Procedures to cover topics such as the

following where appropriate:

Validation

Quality Risk Management

System documentation management

Change management

Taking copies of electronic records

Backup and restore

Access management

Audit trail management and review

Signature management

Usage of electronic signature

Operation of automated software controls

Record retention periods

Significance of electronic signatures in terms of

individual responsibility

Consequence of falsification

Data archiving and deletion

Application archiving



of 198


Training and

Experience Training and experience of users of systems containing

electronic records

Training and experience of developers of systems (both

regulated companies and suppliers)

Amount of documentation retained

Significance of electronic signatures in terms of

individual responsibility

Consequence of falsification

Usage of electronic signature

2541



of 198

9.4 RIGOR OF CONTROLS 2542

The rigor with which the controls are applied should take into account both 2543

the impact of the record and the risks identified. As the impact and risk 2544

increase then more rigorous control is required, as shown in Figure 4.1. 2545

2546

Figure x.1: Relationship between Impact, Risk, and Rigor of Controls 2547

2548

2549 2550

Companies should take into account the need for authenticity, integrity, 2551

accuracy, reliability, and where appropriate the confidentiality of the 2552

electronic records. 2553

A combination of many technical and procedural controls may be required to 2554

achieve an adequate level of protection. 2555

For systems containing multiple types of records, two approaches are 2556

possible: 2557

2558

1. Apply controls to all records appropriate to the highest identified 2559

risk 2560

2561

2. Apply controls to individual record types appropriate to the 2562

identified risk for each type 2563

9.5 SIGNATURE CONTROLS 2564

Companies should define when regulated signatures are required in light of 2565

their own processes and circumstances. These may be applied electronically, 2566

and if so, appropriate electronic signature controls should be applied. 2567

Examples of GxP regulations requiring signatures are provided in Appendix x 2568

of this Guide. 2569

It is important to distinguish between signature and identification events. 2570

Increasing Risk

Increasing

ImpactIncreased Rigor

of Control required

Increased effect on:

•Patient safety•Product safety•GxP compliance

Increased Potential for:

•Loss of record•Corruption of record•Wrong record•Lack of detection

Consider:

•More controls•More frequent controls•Automatic controls•Increased internal audits

Increasing Risk

Increasing

ImpactIncreased Rigor

of Control required

Increased effect on:

•Patient safety•Product safety•GxP compliance

Increased Potential for:

•Loss of record•Corruption of record•Wrong record•Lack of detection

Consider:

•More controls•More frequent controls•Automatic controls•Increased internal audits



of 198

A signature can be regarded as a key event in the life cycle of a record. By 2571

the application of a signature, a record is, e.g. verified, reviewed, or 2572

approved, and the status of the record is changed. 2573

Note also that a signature should be distinguished from identification (that 2574

may also be required by regulations) where the requirements is only for the 2575

identification of an individual performing a particular activity. This may, 2576

for instance, be achieved by logging of an event by a validated computerized 2577

system. 2578

The following should be clear for each regulated electronic signature: 2579

• The identity of the signer 2580

• The date and time when the signature was executed 2581

• The meaning of the signature (such as verification, review, or 2582

approval) 2583

This information should be clear to any reader or user of the record, e.g. 2584

included as part of a human readable form of the signed record, and should 2585

be permanently linked to the record, such that it cannot be removed, altered, 2586

or copied by ordinary means. 2587

Regulated electronic signatures should have the same impact as hand-written 2588

signatures within the boundaries of the company. 2589

The following implementation options may be considered when deciding upon a 2590

suitable approach to ensuring compliant signatures. The appropriate level of 2591

control will depend upon the impact of, and risks to, the signed electronic 2592

record in question. 2593

2594

Method for ensuring uniqueness of signature components, including 2595

prohibition of reallocation of user-ids 2596

2597

Prevention of deletion of signature related information after the 2598

signature is applied 2599

2600

Biometric methods or Digital Signatures (for very high risk cases) 2601

2602

2603

Technical or procedural approaches to ensure integrity of link 2604

between signature and record 2605

2606

Method of display or print of signed records 2607

2608

Procedure for delegation of signature responsibilities (e.g. covering 2609

holidays or periods of absence) 2610

2611

Options for entry of all or some components of multiple component 2612

signatures 2613

2614

9.6 REGULATED COMPANY AND SUPPLIER RESPONSIBILITIES 2615

Typically the regulated company will be responsible for procedural controls, 2616

while many of the required technical controls are typically provided by a 2617

supplier, either as part of a product or through a configuration or design 2618

process. 2619

The final responsibility for compliance with regulatory requirements rests 2620

with the regulated company 2621

9.7 PROCEDURAL REQUIREMENTS (RESPONSIBILITY OF REGULATED COMPANY) 2622

The following list defines procedural requirements to support the use of 2623

compliant electronic record and signature systems. The procedures implemented 2624

should be commensurate with the identified risk: 2625

Systems should be validated according to defined procedures. 2626



of 198

2627

Systems, records, and documentation should be developed according to 2628

defined procedures and should be managed under change control 2629

procedures. 2630

2631

Provision of data to external parties should be formally managed. 2632

2633

When copies of records with any associated audit trails and 2634

signatures are created for regulatory inspection, there should be 2635

controls to ensure legal compliance and that confidentiality is 2636

maintained. 2637

2638

Retention periods, and responsibilities for complying with these 2639

periods, should be documented. Document management procedures should 2640

ensure that handwritten signatures linked to electronic records are 2641

maintained for the same retention period. 2642

2643

Backup and recovery, and archive and retrieval of data should be 2644

formally documented. 2645

2646

Procedures should define how access to systems is limited to 2647

authorized individuals. 2648

2649

Evidence should be available to demonstrate that persons who develop, 2650

maintain, or use electronic record and signature systems have the 2651

education, training, and experience to perform their assigned tasks. 2652

There should be training records and a procedure that addresses this 2653

requirement. Refer to local SOPs for Staff and Training Records. 2654

2655

Unsuccessful attempts to access the system should be monitored - this 2656

is a system control and may not be possible on some systems. 2657

2658

There should be a system of self-inspection to demonstrate compliance 2659

with the procedures and controls. 2660

2661

The following procedural requirements relate to systems that utilize 2662

electronic signatures: 2663

The significance of electronic signatures, in terms of individual 2664

responsibility, and the consequences of misuse or falsification 2665

should be documented. Procedures should be established to ensure 2666

individuals understand they are accountable and responsible for 2667

actions initiated under their electronic signatures, and that 2668

electronic signatures must not be made known to others. Particular 2669

attention is needed when electronic signature components are used on 2670

multiple systems, or for other activities such as logging into a 2671

system, to ensure that the integrity of the signature components is 2672

not compromised. 2673

2674

Security procedures should be established that ensure electronic 2675

signatures are unique to an individual. The user id should never be 2676

reassigned to another individual. 2677

2678

Procedures should be established to verify the identity of an 2679

individual before the assignment of their electronic signature, or 2680

any component of an electronic signature (such as the user ID). 2681

2682

Security procedures should ensure that the ability to apply 2683

electronic signatures is withdrawn for individuals whose 2684

responsibilities change and make the original assignment no longer 2685



of 198

applicable, without the loss of information relating to signatures 2686

already executed. 2687

2688

There should be initial and, where applicable, periodic testing of 2689

devices that bear or generate the confidential component of an 2690

electronic signature to ensure that they function properly and have 2691

not been altered in an unauthorized manner. 2692

2693

Procedures should be established to manage signature loss (e.g., 2694

token, password), and periodic changing where applicable (e.g., 2695

passwords). 2696

2697

Procedures should cover the delegation of signature responsibilities 2698

(e.g., holidays, periods of absence). 2699

2700

9.8 TECHNICAL REQUIREMENTS (LARGELY MET THROUGH SUPPLIER ACTIVITIES) 2701

Many of the controls identified in Table x.1, and signature controls 2702

identified in Section y, are technical in nature and will form part of the 2703

functionality of the supplied system. Suppliers of such systems should be 2704

aware that these controls will likely be standard requirements for systems 2705

supplied to the regulated life science industries, consistent with their 2706

applicability as shown in Table x.1. Suppliers are liable to assessment, 2707

including audit, to ascertain that technical controls have been implemented 2708

appropriately, since user companies have ultimate responsibility for the 2709

system in use. 2710

Suppliers should provide documentation that defines which electronic records 2711

and signatures a system is capable of maintaining. The controls available to 2712

help manage these records and any associated signatures should also be 2713

described. The user can then use this information during the risk management 2714

process. 2715

It may not be possible to implement certain technical controls due to the 2716

required functionality not being currently available in the automated system. 2717

If it is determined that including the required technical control would not 2718

be practical, then the use of alternative technical controls, or failing 2719

that procedural controls, should be considered for acceptability by the user. 2720

The use of multiple procedural controls may together produce sufficient 2721

collaborative information to support the evidence of record control. 2722

Suppliers may also provide administrative features and utilities in their 2723

applications and systems to make the user implementation of procedural 2724

controls more efficient, consistent, and secure. An example of this would be 2725

the inclusion of a system workflow to route lists of authorized users to the 2726

System Owners on a periodic basis for review. 2727

2728

2729



of 198

2730

10 RISKS RELATED TO RECORD RETENTION, ARCHIVING, AND MIGRATION 2731

2732


This Appendix describes how to manage electronic records in order to comply 2734

with GxP regulations for record retention. It specifically does not discuss 2735

defining the retention period for various types of records, which is based 2736

on the relevant GxP regulations and company policy, and is outside the scope 2737

of this Guide. The primary focus will be on issues relating to choices a 2738

firm may wish to make regarding the logical or physical nature of the 2739

retention process concerning electronic records compliance. While this 2740

includes consideration of issues related to migrating records to non-2741

processible formats, it is also not intended to be a complete guide to GxP-2742

compliant data migration or archiving practices. GAMP guidance on these 2743

topics is available in separate guides1. 2744

The terms “record retention” and “archiving” describe separate issues. While 2745

an archive is often the best approach to meeting record retention 2746

requirements, it has additional meaning in that the archive process generally 2747

involves removing the record from the system that produced it, e.g., a 2748

production data base. There are “near-line” solutions that do this invisibly 2749

to the users where, for example, older records may be moved to another 2750

database that is also accessible through the main application. There are 2751

also “off-line” solutions that involve storage to different media (most 2752

commonly magnetic tape), which typically will require more effort to retrieve 2753

archived records. Near-line solutions have the advantage of rapid access; 2754

off-line solutions trade rapid access for less costly storage solutions. Any 2755

of these options, or retaining records in the production database, is 2756

acceptable as long as the records are retained in accordance with relevant 2757

GxP regulations2. 2758

Use of non-electronic media such as microfilm, microfiche, and paper, or a 2759

standard electronic file format, such as PDF, SGML, or XML is also acceptable 2760

as long as all GxP regulations are satisfied, and copies of records preserve 2761

their content and meaning. While far from ideal, paper and electronic record 2762

and signature components can co-exist (i.e., a hybrid situation) provided 2763

the same GxP regulations are met. PDF format can support electronic 2764

signatures, such as through PKI, but the question as to whether a full 2765

electronic signature can be converted from an application to a PDF is 2766

dependent on architecture and is beyond the scope of this guide. 2767

For any data, the approach to data retention should be based upon an 2768

assessment of the risk associated with the data format, physical media, and 2769

future expected use of the data. Data management activities (including 2770

security, disaster recovery, etc.) must also be considered. 2771

10.2 MANAGEMENT OF ELECTRONIC RECORDS 2772

Measures required to support electronic records, whether on-line or archived, 2773

are discussed in GAMP® 5 (Appendix xx). For on-line records, such measures 2774

include logical and physical security, and back-up. When system upgrades are 2775

performed, data migration plans must ensure the integrity of the records 2776

already in the database. For archived electronic records, additional 2777

considerations include exercise of the media3, refresh of the media4, and 2778

1 Insert EDA GPG reference 2 21 CFR 58.190 requires that the results of pre-clinical studies be archived (and under the control of an archivist) at the completion of the study. In such cases, if the records are to be retained on-line in a production database, measures need to be taken to protect them from alteration in order to comply with this predicate rule. 3 For example, magnetic tape may delaminate if it is not periodically wound/rewound 4 The lifetime of magnetic media varies, but in all cases is prone to degradation over time. CDs probably have a longer, although still finite, useful lifetime. The typical solution is to copy the data to new media



of 198

storage conditions. For older records, it may occasionally be necessary to 2779

“technically refresh” archived data, converting it to a new format that is 2780

compatible with an upgraded production system5. It may also be necessary to 2781

develop new rendering software solutions to view records from obsolete 2782

systems after those systems are retired. Typically, rendering software will 2783

not feature significant abilities to manipulate data, so if there is a clear 2784

need to be able to process the data the “technical refresh” approach would 2785

be preferable. 2786

Record managers follow most of the same principles outlined above for data 2787

management, but they tend to think in different terms based on a record 2788

lifecycle that readily translates to paper as well. Figure A2.1 shows what 2789

most records management professionals consider to be a record lifecycle. 2790

Figure A2.1: Record lifecycle 2791

2792 10.2.1 Record Creation 2793

From a record management standpoint this generally includes a combination of 2794

the WHO’s Creation and Processing steps, and possible even Analysis and 2795

Reporting. Records need to be classified (e.g. as GxP, data privacy 2796

sensitivity, etc.) in order to understand what laws and regulations apply to 2797

their management. As such the global concerns are the same as those discussed 2798

in the data lifecycle.Active Records 2799

Active records may still be in the Analysis and Reporting stage of the data 2800

lifecycle, or may be purely in the storage and retrieval phase. Active 2801

records are routinely subject to retrieval for business purposes. 2802

Electronically, they will reside in the active database. Paper records will 2803

be readily retrievable in a short time. For global systems, this might 2804

involve replication to local sources in distributed systems. 2805

10.2.2 Semi-active Records 2806

These records are still references for business purposes, although rarely. 2807

For example, they may be needed to support a regulatory inspection. 2808

Electronically, they may reside in a near-line archive with limited access. 2809

Expectations for the retrieval of semi-active records needs to be clearly 2810

defined. For global system near-line archives can be local, although it is 2811

of the same type.

5 For example to support new version of layered software, e.g. a database engine upgrade. Technically refreshing the records can also be a complex problem. For example, there may be floating point issues, rounding versus truncating, etc. Validation activities may therefore be important.



of 198

probably better to do this globally in order to minimize the number of copies 2812

of the record being managed. 2813

Not all companies use a semi-active stage in their lifecycle; they prefer to 2814

limit themselves to active and inactive. 2815

10.2.3 Inactive Records 2816

Most archived records fall into this category. These records are very 2817

unlikely to be retrieved, but are being held to conform to retention policy. 2818

For global systems it is highly advisable to manage one archive globally, 2819

which will make the eventual destruction of the record much simpler. 2820

10.2.4 Destruction 2821

This stage if the record lifecycle is effectively the same as for the data 2822

lifecycle. 2823

10.2.5 Record Aging and Risk 2824

For some records the risk associated with them is not constant throughout 2825

the record lifecycle. This can impact the measures and controls required to 2826

safely, effectively, and economically manage the records. One important 2827

time at which the risk related to a set of records should be evaluated is 2828

when a data migration is contemplated. Data migration is difficult and 2829

expensive, and for records with a long retention period it may be required 2830

multiple times. If the risk related to the records is low, it might be 2831

reasonable to migrate the records to a medium with a longer lifespan, e.g. 2832

paper, PDF, flat file, etc. 2833

For global systems this risk assessment is trickier, as it must consider the 2834

risks related to all sites and jurisdictions with an interest in the data. 2835

Whenever a decision is made to convert records to a less processible format 2836

a well-documented risk assessment should be done that looks at all applicable 2837

risks for all jurisdictions and for perspective uses of the information. For 2838

example, clinical data relating to a mature product that is being phased out 2839

of production might be a candidate for conversion to another format. However, 2840

if the product is planned for introduction to a new country or is being 2841

considered for a new therapeutic indication it would probably be wiser to 2842

migrate the records and keep them processible. 2843

10.3 HYBRID RECORDS AND ARCHIVES 2844

The ability to retain records in processible form throughout the retention 2845

period is not always required. This is often based or recognition that the 2846

likelihood that a record will need to be reprocessed becomes so low as a 2847

record ages that the ROI of keeping the record processible approaches zero. 2848

In some cases a decision point may be reached with a variety of options, 2849

which have widely varying cost and long term viability. Error! Reference 2850

source not found. shows several options and their varying impact on cost, 2851

processibility of the records, and long-term viability of the solution. 2852

2853

Figure 1 — Risk/benefit considerations for data conversion.

Migration of the records to a new format

Retention of records in the old format with some form of viewer allowing limited manipulation, e.g. sorting or trending

Retention of records in the old format with a viewer with not additional functionality

Conversion of records to a standard electronic format with long term viability (e.g. PDF)

Printing of records to paper.

Hig

her c

ost

Bet

ter l

ong-

term

via

bilit

y

Bet

ter p

roce

ssib

ility



of 198

Companies may choose to retain records in formats other than the original 2854

electronic record if content and meaning are preserved, and GxP regulations 2855

are met. Firms have to evaluate whether retaining records in a processible 2856

form is worth the expense of doing so. If the result of the evaluation is 2857

a decision to compromise or remove the ability to reprocess, there should be 2858

a documented risk assessment supporting the decision, including the reasoning 2859

behind the choice of which metadata needs to be migrated to the new format. 2860

The primary consideration must be the effect of a change in data format on 2861

risk to patient safety, but other factors could include 2862

The ability to demonstrate data integrity in the new format 2863

The likelihood that changes to the data would be necessary after 2864

conversion 2865

Future use of the record, including prospective needs to sort, trend, 2866

or otherwise manipulate the data 2867

The difficulty and expense to do the any of the above data 2868

manipulations, if necessary 2869

Availability of the record to regulators 2870

Company risk tolerance related to a potential regulatory request. 2871

If it is highly unlikely that data will have to be processed, then PDF or 2872

other options, possibly even paper, may be an adequate solution. If there 2873

is any metadata that is still necessary to support data integrity, provisions 2874

should be made to ensure that such metadata remains part of the record. 2875

Date of record edit, identity of the editor, and previous values, would be 2876

examples of this if the assessment concluded that the audit trail needed to 2877

be retained. 2878

If GxP regulations are fully satisfied and the content and meaning of the 2879

records are preserved and archived, then the original (no longer processible) 2880

version of the records may be deleted. It is never advisable to delete 2881

processible records before their retention period is over. If no migration 2882

or transformation is required to keep it in a processible format, archival 2883

in its current format should be considered based on the risks associated 2884

with this approach. 2885

Retaining the original record (or a copy) in an accessible format after 2886

archiving opens the possibility that such records may improperly become the 2887

basis for further regulated activity. Firms need to be aware that regulators 2888

will base their assessment on the records that are actually used in their 2889

business processes. If a firm has signed paper copies in offsite storage and 2890

the staff uses an electronic database, regulators are going to assign greater 2891

importance to controls on the database than the offsite storage location. 2892

It is important to note that the archival process involves the removal of 2893

the data from the production environment once the actual archival is complete 2894

and the appropriate verification process has been completed. Ergo the 2895

original electronic record should be eliminated. Note also that if a 2896

company’s procedures require keeping the original data, it is likely that 2897

conversion to an alternative format would not be considered acceptable by 2898

regulators6. 2899

10.4 AUDIT TRAIL CONSIDERATIONS 2900

In general, an audit trail should be considered part of the record and 2901

migration activities should retain the information. Even if the conversion 2902

is to PDF or paper, a record of the changes prior to transformation should 2903

be preserved if possible. A decision not to migrate an audit trail should 2904

be justified, based on risk, and documented. 2905

6 If a firm feels the need to retain the original electronic record it will appear as though they either have lower confidence in the alternative format or that they anticipate needing the original. Neither is likely to inspire regulatory confidence.



of 198

However, there may be occasions when retaining audit trail information is 2906

problematic. In such cases when converting records to an alternative format, 2907

companies should make an informed decision regarding whether it is acceptable 2908

not to migrate audit trail information with the data. If the audit trail is 2909

integral to understanding or ensuring the integrity of the record, for 2910

example, changing a GLP or GMP lab test result based on re-integration of a 2911

chromatogram, it should be part of the migrated record as well. It may not, 2912

however, be necessary if the audit trail is not required by GxP regulation 2913

and the data was used only for purposes like statistical process optimization 2914

within validated parameters, or for workflow tracking, and thus has low GxP 2915

impact. 2916

10.5 ALTERNATIVE SYSTEMS 2917

Occasionally, it may be advantageous or necessary to convert electronic 2918

records to a different electronic form, while preserving the ability to 2919

reprocess them. Records may be collected and managed on different systems. 2920

For example, it may make sense to leverage superior data management 2921

capabilities (e.g., audit trailing, consolidated back-up, etc.) in a higher 2922

level system as opposed to trying to build the same capabilities into several 2923

lab instruments. Assuming that the content and meaning of the record is fully 2924

preserved, and all future uses and manipulations of the data are intended to 2925

be in the higher system, this approach should generally preclude any future 2926

manipulation of the original “raw” data file through the instrument. Raw 2927

data could still be retained in an archive inaccessible to lab analysts, but 2928

no further manipulation that would supersede the converted records that have 2929

been designated as the “official records” should be possible. This can be 2930

enforced by removal of the record from the instrument as advocated above.7 2931

Instrument records being managed in this manner would be handled more 2932

consistently, as all data would be managed via the same procedures. Search 2933

capability is likely to be improved, as all lab records would be accessible 2934

through one database, with more sophisticated data management tools. 2935

Firms need to consider that many instruments or other systems use proprietary 2936

data formats that will not always convert cleanly to new formats while 2937

preserving content and meaning of the record. It may be possible to manage 2938

data files through the higher level system, but the records may not be 2939

viewable without the use of the originating system. In such cases a decision 2940

must be made whether processibility is critical; the need for this may 2941

decrease as the record ages. 2942

Finally, whenever migrating records, measures should be undertaken to ensure 2943

that the content and meaning are preserved. This generally entails either 2944

validating the conversion or verifying the accuracy of the new version.8 2945

2946

10.6 CONVERTING ELECTRONIC TO ALTERNATIVE FORMAT/MEDIA HYBRIDS 2947

Under certain circumstances it may be acceptable to retain records in a 2948

format other than electronic (paper, microfilm/microfiche, etc.), or in an 2949

alternative “standard” electronic format like PDF9, depending on the manner 2950

7 Firms need to understand the risks as well as benefits of such a solution. For example EU Guidelines for Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use Volume 4 (2014) in Section 6.9 states ‘for some kinds of data [e.g. analytical test results, yields, environmental controls] should be recorded in a manner permitting trend evaluation.’ If a firm interprets this as requiring the ability to reprocess the data, transferral to a LIMS may not be the right choice unless the LIMS can actually be used to manage raw data files that could be exported back to the original software. However, it may not even be necessary to be able to reprocess data to do trend analysis. All foreseeable scenarios for manipulating the data need to be considered in evaluating the risk of this solution. The risks and costs associated with validating or verifying the data migration also must be considered.

8 A statistical method for verification of accuracy like AQL can be useful if the number of records is large. 9 While PDF is an electronic format, and does offer some possibility to manage records using audit trails



of 198

the record will be used. If a company uses a record in electronic format to 2951

support regulated activities or decisions, it cannot arbitrarily designate 2952

a printed copy as the official record. However, if the employees actually 2953

reference only the paper copy, it may be acceptable to retain the record on 2954

paper, and in this case, the electronic record should be deleted. 2955

All possible scenarios should be considered. For drug product distribution 2956

records, for example, the speed of response is critical for dealing with 2957

recall situations. The ability to search and access distribution records 2958

quickly is best suited to a computerized system, so it may be decided that 2959

distribution records are not well suited for immediate conversion to a non-2960

processible format. The risk would be substantially lower, however, after 2961

the expiration of a lot of drug product, so conversion to paper at that point 2962

might be justified. 2963

10.6.1 When Conversion Might Be Considered 2964

The primary driver for any decision to convert records to other formats 2965

should be business need. Some of the logical points for considering such a 2966

move include: 2967

• Creation of the record 2968

• The point at which a record is to be archived 2969

• At system upgrade, especially if data conversion is otherwise 2970

necessary 2971

• At system replacement when contemplating a data migration to the 2972

new system 2973

• At system retirement, especially if data conversion or 2974

development of rendering software is otherwise necessary 2975

• The point at which a media refresh is necessary 2976

10.6.2 Changing Repositories without Altering Format 2977

Although the risks are lower, there are some risks associated with moving 2978

records from one repository to another, as is usually the case for simple 2979

archiving. Such risks might include media degradation, accidental loss, 2980

failure to retain software capable of viewing the records, etc. There are 2981

methods such as checksum verification to ensure that migration is complete. 2982

10.6.3 Risk Assessment for Conversion 2983

Decisions to convert records to an alternative media, format, or repository 2984

should be justified with a risk assessment showing no unacceptable risk to 2985

data integrity, product quality, and patient safety. However, the risk 2986

assessment process should be made as facile as possible by doing the 2987

assessment on groups of related records. For a small to moderate sized system, 2988

it is even conceivable that all of the records produced by a system could be 2989

assessed as a single group (e.g., a chromatography data system). However, 2990

large complex systems like ERP will clearly have several such groups of 2991

records that should be evaluated independently. 2992

The approach to this risk assessment should be multi-tiered. First, it must 2993

be determined what the overall impact of the record is according to the 2994

scheme discussed in Section 2.1.3 of this Guide. For low and medium impact 2995

records the approach to archiving (i.e., transferring records to different 2996

media while retaining the original architecture of the record) should simply 2997

follow good IT practices. For archiving of high-impact records, risks such 2998

as those in Table 2 should be evaluated. 2999

When considering conversion of regulated records to another format, risks 3000

and digital signature, it is considered an alternative format because conversion to PDF generally sacrifices the ability to process the data. However, PDF carries the advantage of being able to execute some limited searches within documents, and depending on how the files are stored, also may offer searchability on the documents themselves. This should be considered when selecting to what format to convert records.



of 198

such as those presented in Table 1 should be considered for high impact 3001

records. Companies should determine the degree to which this approach should 3002

be applied to medium impact records. 3003

These assessments should consider the manner in which the data is accessed 3004

and used. Whilst the “potential effects” noted in Table 1 and Table 2 are 3005

generic, firms would have to consider them in the context of each unique set 3006

of records. For example, if accuracy and completeness of records in a drug 3007

safety database could be compromised by conversion, and the converted record 3008

could then be interpreted incorrectly, there could be significant risk to 3009

patient safety based on erroneous medical conclusions. The same occurrence 3010

to records in a training database would clearly have a much less immediate 3011

and severe impact. 3012

3013

3014



of 198

Table 1: Risk Factors for Conversion of Electronic Records to an Alternative Format

Risk Factor Considerations Potential Effects

Conversion may change the

accuracy and completeness of

the record in a manner that

would affect the

interpretation of the data

If the converted record is

considered the “raw” data, the

possibility of changing the

interpretation of the data would

be unacceptable.

Interpretation of the converted record

leads to a different conclusion than

before conversion

Users may have to execute a

rapid search of the data

across records

If rapid retrieval is

necessary, .e.g., to support a

product recall, conversion may

be ill-advised since cross-

record searching is far easier

using database technology.

Unable to rapidly search

Inadequate/incomplete searches

Users may have to execute

large or frequent searches on

the records

Frequent or large searches

introduce increased probability

that the searches will be

incomplete.

Spend inordinate resources on searches


Unable to execute effective search

Users may have to search the

records based on a wide range

of keys

Most filing systems for non-

electronic records have limited

searchable keys.



Unable to execute effective search

Retention of original record

after conversion to an

alternative format

Why retain the original? How

will it be kept consistent with

the master copy?

Inconsistency of records

“Master copy” confusion/inaccuracy

•

Record may have to be modified

after it is committed to

alternative format

Changes may be harder to execute

and to track in the alternative

format.

Audit trail inadequate

External audit trail may be required

(possible regulatory exposure)



of 198


Employees who need it do not

have ready access to the

record in the new format in

order to carry out their job

responsibilities

If they are expected to use the

alternative format record, it

needs to be accessible. This can

be problematic due to geographic

or technical factors (e.g. no

access to a required reader).

Inefficiency

Actions taken based on insufficient data

An audit trail needs to be

retained as part of the record

in the alternative format

Is the record history retained

in the audit trail critical to

the value of the record? Audit trail inadequately shows subsequent

changes, with the result that data

integrity may be considered compromised

by regulators

Size of archive may become unwieldy if

audit trail retention is handled

ineffectively

Large database size may lead to

performance problems

Is the audit trail integral to

data integrity?

Is an audit trail required by

a GxP predicate rule?

An audit trail in an

alternative format may double

(or worse) the size of each

record. (This may in fact be

a driver for moving records

from the database to archive.)

A signature is associated with

the record

Is evidence of the approval

extant in the new version?

Is the alternative format

adequate evidence of

authenticity?

Is the link between signature

and record preserved?

Evidence of timely approval is

compromised or lost

Hybrid manifestation of e-sig loses legal

meaning/weight

Linkage of record with signature is broken



of 198

Table 2: Risk Factors for Transfer of Electronic Records to Alternative Media (Archiving)


Users may have to execute a

rapid search of the data

across records

If rapid retrieval is

necessary, .e.g., to support a

product recall, search

capabilities on the new media

may be limited and restoration

of the records to a searchable

platform may cause delay

Unable to rapidly search. This may be

partially mitigated by development of

emergency procedures to eliminate delays that

are purely administrative in nature.

Users may have to execute

large, complex, or frequent

searches

Search capabilities on the new

media may be limited.

Frequent restoration of

archived data would be

resource-intensive and

expensive.


Retention of original record

after conversion to an

alternative media

Why retain the original?

How will it be kept

consistent with the master

copy?

Inconsistency of records

Record may have to be modified

after it is committed to

alternative media

Changes may be harder to

execute and to track on the

new media.

Required changes not executed or not

executed in a timely fashion

Audit trail inadequate

An audit trail needs to be

retained as part of the record Is the record history

retained in the audit trail

critical to the value of the

record?

Size of archive may become unwieldy if audit

trail retention is handled ineffectively

Is the audit trail integral

to data integrity?

Is an audit trail required

by GxP regulation?

Depending on architecture of

the audit trail, changes

after commitment to



of 198


different media may multiply

record size several-fold.



of 198

Based on the identification of risk factors such as those in Table 1 and Table

2, the GAMP® 5 risk assessment methodology can be applied. The first step is to

identify potential effects for the risk factors, such as those shown in the two

right-hand columns of these tables. For each possible effect the GAMP® 5

methodology relates likelihood of occurrence to the severity of harm then takes

that result and relates it to the probability of detection of a fault.

The traditional application of the GAMP® 5 model to risk assessment is for the

purpose of validation planning, and is geared toward system failure. Using the

model to assess risk to record integrity, probability of detection is a little

more complex. This is because of the additional mode of ‘loss of record

integrity’ which involves alteration or deletion of the record through

knowledgeable human actions or record manipulations within the system that do

not track metadata relevant to tracking change. Human actions will inevitably

be harder to detect through electronic means; indeed, this is a major principle

by which the need for an audit trail should be judged. Hence, in many cases one

of the identified hazards related to a record should be change undetectable by

normal means. Clearly, if a system has an audit trail or checksum verification

built in, detectability will be high; if detectability is dependent upon human

observation, it will be low. See Appendix XX for a detailed discussion of the

GAMP® 5 risk assessment methodology.

10.7 EXAMPLES OF APPLICATION OF GAMP® 5 RISK ASSESSMENT TO RECORDS MANAGEMENT The following examples describe a variety of risk management scenarios related

to record retention, covering such issues as:

Risk related to deciding what data should actually be retained as records

Risk related converting records from processible to non-processible

format

Age-dependent risk

Example 1: Raw data from a GLP environmental monitor to be retained only as

processed hourly average and alarm records

This case presupposes a system collecting temperature and humidity data with a

high frequency (e.g. a data point every 5 seconds). The system has a validated

alarm function for reporting excursions. Only the system can write to the data

files, which are accumulated in a logically protected directory.

The GLP regulations only offer an expectation that monitoring be in place. The

practice before installing the new system was to report hourly averages based

on a continuous analog chart recorder, with the charts retained as evidence of

control. However, in the new system there is no compelling driver for retaining

anything beyond the hourly averages and the excursion alarm history, since these

give an adequate description of the environmental conditions and the controls

on them. Because the data is secure and there are validated safeguards ensuring

that excursions are recorded and acknowledged, there are reasonable controls in

place to warrant a strategy of discarding the detailed raw data and retaining

only the processed hourly averages and the alarm history as the GLP record.

(See Table 3 for details of the risk assessment.)

Example 2: A database containing the results of a recently completed clinical

study is proposed for conversion to PDF

Each of the effects is assessed using the grids in Appendix XX in reference to

the proposed new format. One of the possible risks is undetectable change, as

the proposed new record format is not supported by an audit trail. In this case

there is a reasonable probability that some of the data may need to be altered,

and it is possible that further manipulation of the data may be required prior

to significant decisions which have regulatory impact. Without the audit trail



of 198

functionality, detectability will be an issue, and when the GAMP® 5 risk

assessment methodology is applied most of the risk priorities turn out medium

to high, which indicates this database is not a good candidate for conversion.

(See Table 4 for details of the risk assessment.)

Example 3: The same clinical study database system is proposed for conversion

to PDF ten years later

In this case a software upgrade forces us to consider whether we wish to spend

substantial resources to migrate this data to the new, fully functional clinical

data management system. While the data is still useful, and may in fact have

been used to support a recent application for a new therapeutic indication, the

data has essentially been static for a considerable period.

There is no foreseeable need to search or manipulate the data through its native

application, although it still retains business value; the statistical analysis

data sets would be used to answer any additional regulatory queries that might

arise from the recent application. Applying the same risk assessment shows that

the risk level for conversion to a non processible format has dropped

substantially, with all risk priority values coming out low-medium, making the

case that conversion to paper or PDF from the clinical database at this point

is reasonable (see Table 5 for details of the risk assessment.)

Example 4: Distribution records considered for conversion to “official” paper,

deleting original e-record

The key risk factors associated with retaining distribution records only on

paper is the searchability factor. In case of product recall, speed may be

essential to protecting public health; a dangerous product must be removed from

the market quickly, and the danger with converting such records to paper

involves inefficiency of the search process. It is possible that the search

might yield incomplete results, or that obtaining complete and reliable results

would take too long. Ergo data conversion to paper followed by deletion is not

advisable. (See Table 6 for details of the risk assessment.)

Example 5: Distribution records considered for conversion to “official” paper,

maintaining original e-record

Inconsistency would be a problem inherent in this approach. Every change to a

record would have to be made in two places, a process bound to fail at some

point. The proposition that the paper copy is official would be difficult to

argue with a regulator as well, since the electronic record would be maintained

to meet an important GMP requirement. (See Table 7 for details of the risk

assessment.) Neither of the previous two approaches for managing distribution

records can be supported based on these risk analyses.

Examples 2 and 3 show how judgments and factors affecting a decision to convert

regulated records to a different format can change as the record advances

through its life cycle. No specific defined value or cut-off point for a go/no

go decision can be predefined in the context of this risk assessment process

because many other variables, especially the nature of the product and risk to

patient safety, and a company’s risk tolerance, must be considered.

Example 1, on the other hand, shows a case where conversion is very safe from

the start, while 4 and 5 demonstrate a type of record where conversion appears

to be a poor idea laced with high assumed risks. Firms will have to decide for

themselves exactly how much medium to high risks they can tolerate. Such

decisions must account for a number of factors including regulatory compliance,

cost, staffing, etc. The overriding consideration, of course, must always be

patient safety.



of 198

Note also that even in the context of a decision whether to convert records

based on a risk assessment, one individual factor may be so important, that

despite a favorable risk assessment it may be decided not to convert the data.

A risk assessment tool provides objective criteria to support such decisions,

but in specific cases there may be over-riding considerations unique to the

circumstances. If a particular e-records management decision seems

fundamentally unwise, it probably is.

Example 6: Chromatography Data System migration/ retention to an alternate

format which may not allow for reprocessing the data early in the data lifecycle.

In this scenario, the fundamental risk and issues associated with chromatography

data system is the dynamic nature of records and the expectation of retaining

the ability to process the data throughout it data lifecycle. Per current

regulatory guidance and expectations, printouts or a static record does not

preserve the dynamic format which is part of the complete original record.

Electronic copies can be used as true copies of paper or electronic records,

provided the copies preserve the content and meaning of the original data, which

includes the associated metadata and the dynamic nature of the original records.

In this scenario where the data is early in its lifecycle, the risks associated

with migrating or retaining the data in an alternate format that does not

maintain the dynamic nature of the data significantly increases and would

discourage this approach, especially if the records will be used to support the

regulated activities in the future. This risk should be fully evaluated,

justified, and documented as part of the migration strategy to support the

criticality of the dynamic nature of the records and ensure the data migration

does not create data integrity issues.

Example 7: Chromatography Data System migration/ retention to an alternate

format which may not allow for reprocessing the data late in its data lifecycle.

Just like the scenario above, the fundamental risk and issues associated with

chromatography data system is the dynamic nature of records and the expectation

of retaining the ability to process the data throughout it data lifecycle. The

fundamental difference in this example is the late data lifecycle implication

of the data. Over the lifecycle of the record, the need for the dynamic nature

of the records and the need to process records will typically decrease, thereby

lowering the risk of maintaining the data in its original format and increase

the potential for migration and/ or retention of the records in alternate

formats. But this risk must be fully evaluated, justified, and documented to

ensure the dynamic nature of the records is truly no longer needed and this

does not create data integrity issues. True copies of dynamic electronic

records may be made and maintained in a compatible or alternate format, provided

that the content and meaning of the original records are preserved and that a

suitable reader and copying equipment are readily available to support the

alternate format during the later stages of the data lifecycle.

Reading these tables: These tables summarize application of the GAMP® 5 risk

assessment methodology to issues related to record retention, archiving, and

conversion. For each risk factor there is one likelihood of occurrence. Two

possible effects are evaluated for each risk factor. This is not to imply that

there will always be exactly two possible effects. For each effect there is a

severity of impact, and from these two values is derived the risk level. Risk

level then is plotted against the probability of detection to give the final

risk priority values. Not all risk factors from Table 1 and Table 2 appear in

these examples, and others could apply. These must be derived based on effect

on patients, business practice and regulatory requirements.



of 198

Table 3: Raw Data from a GLP Environmental Monitoring Device

Hazard Likeli-

hood Risk 1

Im-

pact Det.

Risk 1

Priority Risk 2

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the raw data L

Unable to perform rapid search L H L

Need to execute large or frequent searches of raw data L

Unable to perform large searches L H L

Need to search your records based on a wide range of keys? L

Unable to execute sophisticated searches L H L

Need to reprocess raw data L Unable to reprocess data M H LInadequate data for GLP decision M H L

Raw Data from Environmental Monitor Retained only as Processed Hourly Average and Alarm RecordsRisk 2 AssessmentRisk 1 Assessment

Table 4: Risk Assessment for a Recently Populated Clinical Database

Hazard

Likeli-

hood Risk 1

Im-

pact Det.

Risk 1

Priority Risk 2

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the data H

Unable to perform rapid search M H M

Weak response to clinical emergency H H M

Need to execute large or frequent searches on your records H

Unable to perform large searches H H M

Search may not find all records H L H

Need to search your records based on a wide range of keys H

Unable to execute sophisticated searches H H M Manual intervention L H L

Managing change: Record will have to be modified after it is converted L

Audit trail for changes after conversion lost M L M

Compliance compromised M L M

Risk 2 Assessment

Clinical Study Database for a New Drug Entity Proposed for Conversion to PDFRisk 1 Assessment



of 198

Table 5: Risk Assessment for an Old Clinical Database

Risk Factor Likeli-

hood Effect

Im-

pact Det.

Risk 1

Priority Effect

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the data? L

Unable to perform rapid search L H L

Weak response to GxP emergency L H L

Need to execute large or frequent searches on your records? L

Unable to perform large searches M H L

Search doesn't find all records L L M

Need to search your records based on a wide range of keys? M

Unable to execute sophisticated searches M H L Manual intervention L H L


Audit trail for changes after conversion lost M L M

Compliance compromised L M L

Effect 2 Assessment

10-Year-Old Clinical Study Database for a Drug Entity Proposed for Conversion to PDFEffect 1 Assessment

Table 6: Distribution Records, Deleting Original

Hazard

Likeli-

hood Risk 1

Im-

pact Det.

Risk 1

Priority Risk 2

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the data? M

Unable to perform rapid search H M H

Weak response to recall H M H

Need to execute large or frequent searches on your records? H

Unable to perform large searches H H M

Search doesn't find all records H L H

Need to search your records based on a wide range of keys? H

Unable to execute sophisticated searches H M H Manual intervention M H M

Managing change: If the audit trail is part of the paper record L

Review of audit trails is very difficult H H L

Post conversion changes untracked H L H

Managing change: If the audit trail is not part of the paper record H

Review of audit trails is impossible H H M



Audit trail for changes is piecemeal H M M


Distribution Records Considered for Conversion to "Official" Paper, Deleting Original e-RecordRisk 2 AssessmentRisk 1 Assessment



of 198

Table 7: Distribution Records, Retaining Original

Hazard

Likeli-

hood Risk 1

Im-

pact Det.

Risk 1

Priority Risk 2

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the data HSearch must be done on "unoffical" record M H M

Questionable response to recall M H M

Need to execute large or frequent searches on your records H

Search must be done on "unoffical" record M H M


Need to search your records based on a wide range of keys H

Search must be done on "unoffical" record M H M


Managing change: only e -rec changed after alternative declared “master”

M Inconsistency of records H L HInadequate data for GMP decision H L H

Managing change: Record will have to be modified after it is converted M

Audit trail for changes after conversion lost L L M

Compliance compromised M L H

Employees don't have convenient access to alternative format records M Inefficiency M M M

Actions based on insufficient data M M M

Employees have access to record in its original electronic form M E-record used as master M L H

Compliance compromised M L H

Distribution Records Considered for Conversion to "Official" Paper, Retaining Original e-RecordEffect 2 AssessmentEffect 1 Assessment



of 198

Table 8: Chromatography Data System migration/ retention early in the data lifecycle.

Hazard Likeli-

hood Risk 1

Im-

pact Det.

Risk 1

Priority Risk 2

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the raw data H

Depending on format, potential inability to perform rapid search

H H H

Questionable response to product issue and/ or inspectional request

H H H

Need to execute large or frequent searches of raw data H


H H H


H H H

Need to search your records based on a wide range of keys? M

Depending on format, potential inability to execute sophisticated searches

H H H


M H H

Need to reprocess raw data H

Depending on format, potential inability to reprocess data

H H H

Inadequate data for product issue and/ or inspectional request

H H H

Chromatography Data System migration/ retention to an alternate format which may not allow for reprocessing

the data early in the data lifecycle.Risk 2 AssessmentRisk 1 Assessment



of 198

Table 9: Chromatography Data System migration/ retention late in the data lifecycle.

Hazard Likeli-

hood Risk 1

Im-

pact Det.

Risk 1

Priority Risk 2

Im-

pact Det.

Risk 2

Priority

Need to execute a rapid search of the raw data L


H H L


H H L

Need to execute large or frequent searches of raw data L


H H L


H H L

Need to search your records based on a wide range of keys? L

Depending on format, potential inability to execute sophisticated searches

H H L


H H L

Need to reprocess raw data L

Depending on format, potential inability to reprocess data

H H L

Inadequate data for product issue and/ or inspectional request

H H L

Chromatography Data System migration/ retention to an alternate format which may not allow for reprocessing

the data late in the data lifecycle.Risk 2 AssessmentRisk 1 Assessment



of 198

11 DATA INTEGRITY FOR END-USER APPLICATIONS

11.1 INTRODUCTION End-user applications are small applications that hare typically created outside

of traditional software development environments. They are often developed by

the people who will use them, although in some cases they may be repeatedly created

off templates. The most common types are spreadsheets, although they can also be

small databases (often PC-based), statistical programs (e.g. developed on a SAS®

platform), or computer programs (e.g. developed in a language like BASIC).

The decision to use such applications for GxP processes should be risk-based. In

some cases the ease of developing and using such applications simply cannot

counterbalance the higher data integrity risks that accompany their use. There

have been enough warning letters for using spreadsheets to manage GxP records to

demonstrate the opinion of the US FDA on this topic10. However, it can be possible

to enact appropriate controls to mitigate the risks and bring them down to an

acceptable level.

11.2 DATA INTEGRITY FOR SPREADSHEETS Spreadsheets are extremely useful tools that are attractive for a variety of uses

related to regulated activities. Part of the attraction derives from the ease of

use and the power of the tool. However, this very flexibility makes spreadsheets

a high risk form of electronic records from a data integrity standpoint if they

are not extremely carefully controlled.

These risks do not mean that they are unusable, but limits have to be set related

to the manner in which spreadsheets are used and managed. GAMP® 5 provides a

discussion if the various types of uses of spreadsheets and validation

implications, and this will be the basis for the following discussion.

One of the biggest challenges related to managing spreadsheets is that they do no

support audit trails. There may be add-on tools available to do so, but they are

not commonly used. If a company elects to depend on such a tool a thorough

analysis should be done of the capabilities and limitations of the add-on; chances

are many of the controls described below will still be in order.

11.2.1 Spreadsheet That Are Simple Documents

The easiest class of spreadsheet to manage is those that are just static tables.

Control of such electronic documents should be managed in the same way as word

processing documents. The most effective manner of control would be to manage

the document within and EDMS (Electronic Document Management System).

In the absence of an EDMS one of the primary challenges is control of the storage

of the documents, with control issues that are basically the same as for any other

electronic file. Saving the final version as a PDF can be a helpful means of

ensuring a document is immutable. Digital signature tools can be used as

necessary.

11.2.2 Spreadsheets That Are Templates

A very common use for spreadsheets is for repetitive usage of calculation

algorithms. These have an enormous potential impact, since any integrity issues

related to the template obviously propagate to every record that is generated

based upon that template.

While it is not necessary to verify that a spreadsheet does arithmetic properly,

it is critical to ensure that algorithms in such a template are the correct ones.

Prior to providing the template for use, this should be independently verified

and approved. Template should be stored in a manner restricting the ability to

alter them to a very small number of people. Typically this will be a combination

of measures such as:

Storage of the template in a directory that severely restricts write, edit,

10 http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/2014/ucm406826.htm and http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/2013/ucm369409.htm are two examples.



of 198

and delete access

Users should only be able to copy the template to a separate, also protected,

directory with limited access

Password protection of all cells in the template except for those where

data is entered so that the algorithms cannot be edited by during use

Restriction of the ability to edit documents created using the template

Traceability to the creator/editor of records created based on a template

If feasible, once records created from a template are finalized they should

be stored in an immutable format such as PDF

11.2.3 Single Use Spreadsheets

Another common use of spreadsheets is to analyze a unique problem, such as

investigating an out of specification result or evaluating a manufacturing trend.

In many ways managing such spreadsheets is similar to managing the spreadsheets

that are simple documents. The primary difference is the integrity of the

calculations. Similarly to the template the calculations should be verified to

be the proper ones, but checking arithmetic is unnecessary. One way of providing

a lasting record that the calculations are the correct ones is to capture a view

of the calculations11.

If a spreadsheet of this type must be left open for further data entry it is

advisable to set it up so that revision of the spreadsheet will require versioning.

One mechanism would be to disallow saving over the existing version.

Administrative procedures defining protections are recommended.

11.2.4 Spreadsheets as Databases

Because they are common and possess the ability to do rudimentary search and sort

on a large table of data, it is tempting to use spreadsheets as databases.

Unfortunately standard spreadsheet databases are completely unsuitable from a data

integrity viewpoint. The primary reason for this is that every time data is added

to the database, a completely new version of the database is effectively created.

In addition, audit trails for the individual cell contents are not available, so

that it is not possible to recreate changes without examining every single version.

If a desktop database is required it would easier to control data integrity using

a real database engine, although data integrity is far easier to control on

platforms other than a desktop device.

11.3 DATA INTEGRITY FOR PC DATABASES 11.3.1 User-Developed and Managed Tools

The aspects of a purely local database that need protection are no different from

those required for a server-based database. They can, however, be trickier to

administer. For example, segregation of duties is not possible if the user of

the database is also the developer and owner. For this reason the routine use of

such tools for GxP processes is not advisable.

This does not mean that a tool developed in this fashion can never be used. When

a tool is developed for a specific problem, e.g. supporting an investigation,

single use applications are not only acceptable but expected. This does not mean

data integrity concerns are ignored; just that regulators are not going to expect

to see 6-month IT projects executed under a formal SDLC with built-in data

integrity protections. However, once the investigation is completed, the database

should be locked and securely stored.

11.3.2 Centrally Managed PC Databases

It may be that a regulated company decides to use a PC database because its

simplicity is well suited to the user community and the task at hand. In such

cases the tool should be managed by at IT group in the same fashion as a server

11 In Microsoft Excel® this is done by the keystroke combination of <CTRL><~>. This displays all of the cell content as calculations and can be printed to paper or PDF. Other spreadsheet tools should have similar capability.



of 198

based database. This in effect makes the tool a server based database that simply

happens to be built on a different database engine and operating system.

Segregation of duties, access controls, backup, and archiving can all be managed

properly in this fashion. The one caveat is that some PC-based database engines

may not have the ability to manage issues like audit trails and role based security

in a way that would be expected by regulators. All such issues should be

considered before electing to use such a tool.

11.4 DATA INTEGRITY FOR STATISTICAL TOOLS User-developed statistical tools are often used in the same manner as the databases

discussed above, and have the same data integrity concerns. Single use tools

supporting investigations should be locked and controlled following completion of

the investigation.

Sometimes such a tool will be used repetitively, for example to analyze tablet

weight distribution for a batch of finished product. Template controls should be

similar to those discussed above related to spreadsheet templates:

The template should be stored in a controlled location, with limited

access.

Authorized users should only be able to copy the template to a different

directory where it can be used, and even in this location the code should

be inaccessible to the users; they should only be able to add and process

data.

Once the result has been obtained it should be protected against

unauthorized change.

The result of the analysis should be traceable to the user who generated

it.



of 198

12 EXAMPLES OF RECORDS AND SIGNATURES REQUIRED BY GXP REGULATIONS

This Appendix contains indicative examples of records and signatures required by

various US and EU regulations, and by ICH Q7. It is not intended to provide

examples of all GxP regulations. While every effort has been made to ensure

accuracy at time of publication, neither ISPE nor the GAMP Forum can be held

responsible for any errors or omissions in the text. In no event shall ISPE or

any of its affiliates (including the GAMP Forum), or the officers, directors,

employees, members, or agents of each of them, be liable for any damages of any

kind, including without limitation any special, incidental, indirect, or

consequential damages, whether or not advised of the possibility of such damages,

and on any theory of liability whatsoever, arising out of or in connection with

the use of this information. Readers are strongly recommended to refer to current

regulations when reviewing and deciding on policies, procedures and processes.

12.1 KEY DEFINITIONS Some key definitions from the Main Body are included here for convenience and

completeness.

A regulated record is a record required to be maintained or submitted by GxP

regulations. A regulated record may be held in different formats, for example,

electronic, paper, or both.

A regulated electronic record is a regulated record maintained in electronic

format. A regulated electronic record is a collection of regulated data (and

metadata if necessary to provide meaning and context) with specific GxP purpose,

content, and meaning.

Regulated electronic records include, but are not limited to Part 11 records as

defined by US FDA.

Note that that there may be records required to support regulated activities,

despite them not being explicitly identified in the regulations.

A regulated signature is a signature required by a GxP regulation. Regulated

signatures include signatures that document the fact that certain events actions

occurred in accordance with the GxP regulation rule (e.g. approval, review or

verification of a regulated record).

A regulated electronic signature is a signature applied electronically to a

regulated electronic record, and intended to be the equivalent of a handwritten

signature required by a GxP regulation.

Signatures not required by predicate rules, and other superficially similar cases

such as identification of individuals, acknowledgement of steps or actions, or

logging-on to a system are not regulated signatures.

By the application of a signature, the status of a record is changed. Signatures

should be clearly distinguished from identification events (that may also be

required by regulations) where the requirement is only for the identification of

an individual performing a particular activity. This may, for instance, be

achieved by logging of an event in an audit trail by a validated computerized

system.

Signatures are often implemented by a unique user-id and password combination.

Other uses of user-ids and password, such as logging on to a system, should be

clearly distinguished from signature events.

12.2 EXAMPLES FROM US REGULATIONS 12.2.1 Introduction

This section provides examples of records and signatures from US Regulations

covering GLP, GCP and GMP.

The preamble to 21 CFR Part 11 refers to electronic signatures that meet the

requirements as being considered equivalent to full handwritten signatures,



of 198

initials, and other “general signings” required by agency regulations.

Comment 28 of the preamble states: “The agency advises that current regulations

that require records to be signed express those requirements in different ways

depending upon the agency’s intent and expectations. Some regulations expressly

state that records must be signed using “full handwritten” signatures, whereas

other regulations state that records must be “signed or initialed;” still other

regulations implicitly call for some kind of signing by virtue of requiring record

approvals or endorsements. This last broad category is addressed by the term

“general signings” in Section 11.1(c).”

General signings implies that the use of the words “initials”, or “approved”, or

“rejected”, or “authorized” within FDA regulations equates to a regulated

signature requirement.

For the purpose of this guidance, the following terms have been defined in

accordance with 21 CFR Part 11 (for “signature") or established custom (for other

terms).

Term Definition

General

Signing:

An implied signature indicated by use of the words

“initials”, or “approved”, or “rejected”, or “authorized”

within FDA regulations.

Signature: The legal mark of an individual, executed by them, with

the present intention of authenticating a written

statement permanently.

Identification: An attribute linked to a record that uniquely identifies

the person originating or modifying that record. When

used in the context of a computer system that needs to

comply with 21 CFR Part 11, identification is not intended

to meet the requirements for electronic signatures

defined in 21 CFR Part 11.

Initials: The abbreviated signature of an individual, and

considered equivalent to a signature, if intended to meet

FDA regulation for signature. Not an acceptable

alternative if the regulation calls for full handwritten

signature. Interpreted as a general signing.

Written: Documented permanently and non-verbally. Can be applied

to procedures, records, interpretations, authorizations,

approvals, or rejections.

Approved: Indication that a person has accepted a procedure,

statement, item of data or conclusion as satisfactory.

Interpreted as a general signing.

Rejected: Indication that a person has rejected a procedure,

statement, item of data or conclusion as not satisfactory.

Interpreted as a general signing.

Authorized: Indication that a person in authority has agreed an action

or granted privileges. Interpreted as a general signing.

Authenticated: Indication that information is genuine.

12.2.2 GOOD LABORATORY PRACTICE (GLP)

Code of Federal Regulations, Part 58



of 198

58.120 Protocol.

58.120(a) Each study shall have an approved written protocol that clearly

indicates the objectives and all methods for the conduct of the

study. The protocol shall contain, as applicable, the following

information: ….

(10) The records to be maintained.

(11) The date of approval of the protocol by the sponsor and the dated

signature of the study director.

58.120(b) All changes in or revisions of an approved protocol and the reasons

therefore shall be documented, signed by the study director, dated,

and maintained with the protocol.

58.130 Conduct of a nonclinical laboratory study.

58.130(e) All data generated during the conduct of a nonclinical laboratory

study, except those that are generated by automated data collection

systems, shall be recorded directly, promptly, and legibly in ink.

All data entries shall be dated on the date of entry and signed or

initialed by the person entering the data. Any change in entries

shall be made so as not to obscure the original entry, shall indicate

the reason for such change, and shall be dated and signed or

identified at the time of the change. In automated data collection

systems, the individual responsible for direct data input shall be

identified at the time of data input. Any change in automated data

entries shall be made so as not to obscure the original entry, shall

indicate the reason for change, shall be dated, and the responsible

individual shall be identified.

58.185 Reporting of nonclinical laboratory study results.

58.185(a) A final report shall be prepared for each nonclinical laboratory

study and shall include, but not necessarily be limited to, the

following: ….

(12) The signed and dated reports of each of the individual scientists or

other professionals involved in the study.

(13) The locations where all specimens, raw data, and the final report

are to be stored.

(14) The statement prepared and signed by the quality assurance unit as

described in 58.35(b)(7).

58.185(b) The final report shall be signed and dated by the study director.

58.185(c) Corrections or additions to a final report shall be in the form of

an amendment by the study director. The amendment shall clearly

identify that part of the final report that is being added to or

corrected and the reasons for the correction or addition, and shall

be signed and dated by the person responsible.

58.190 Storage and retrieval of records and data.

58.190(a) All raw data, documentation, protocols, final reports, and specimens

(except those specimens obtained from mutagenicity tests and wet

specimens of blood, urine, feces, and biological fluids) generated

as a result of a nonclinical study shall be retained.

58.190(b) There shall be archives for orderly storage and expedient retrieval

of all raw data, documentation, protocols, specimens, and interim

and final reports. Conditions of storage shall minimize

deterioration of the documents or specimens in accordance with the

requirements for the time period of their retention and the nature

of the documents or specimens. A testing facility may contract with

commercial archives to provide a repository for all material to be



of 198

retained. Raw data and specimens may be retained elsewhere provided

that the archives have specific reference to those other locations.

58.190(e) Material retained or referred to in the archives shall be indexed to

permit expedient retrieval.

58.195 Retention of records.

58.195(b) Except as provided in paragraph (c) of this section, documentation

records, raw data and specimens pertaining to a nonclinical

laboratory study and required to be made by this part shall be

retained in the archive(s) for whichever of the following periods is

shortest:

(1) A period of at least 2 years following the date on which an

application for a research or marketing permit, in support of which

the results of the nonclinical laboratory study were submitted, is

approved by the Food and Drug Administration. This requirement does

not apply to studies supporting investigational new drug applications

(IND’s) or applications for investigational device exemptions

(IDE’s), records of which shall be governed by the provisions of

paragraph (b)(2) of this section.

(2) A period of at least 5 years following the date on which the results

of the nonclinical laboratory study are submitted to the Food and

Drug Administration in support of an application for a research or

marketing permit.

(3) In other situations (e.g., where the nonclinical laboratory study

does not result in the submission of the study in support of an

application for a research or marketing permit), a period of at least

2 years following the date on which the study is completed,

terminated, or discontinued.

58.195(d) The master schedule sheet, copies of protocols, and records of

quality assurance inspections, as required by 58.35(c) shall be

maintained by the quality assurance unit as an easily accessible

system of records for the period of time specified in paragraphs (a)

and (b) of this section.

58.195(e) Summaries of training and experience and job descriptions required

to be maintained by 58.29(b) may be retained along with all other

testing facility employment records for the length of time specified

in paragraphs (a) and (b) of this section.

58.195(f) Records and reports of the maintenance and calibration and inspection

of equipment, as required by 58.63(b) and (c), shall be retained for

the length of time specified in paragraph (b) of this section.

58.195(g) Records required by this part may be retained either as original

records or as true copies such as photocopies, microfilm, microfiche,

or other accurate reproductions of the original records.

58.195(h) If a facility conducting nonclinical testing goes out of business,

all raw data, documentation, and other material specified in this

section shall be transferred to the archives of the sponsor of the

study. The Food and Drug Administration shall be notified in writing

of such a transfer.

12.2.3 GOOD CLINICAL PRACTICE (GCP)

Code of Federal Regulations, Parts 50, 56, 312

PART 50 CONSENT

50.27 Documentation of informed consent.

50.27(a) Except as provided in 56.109(c), informed consent shall be documented



of 198

by the use of a written consent form approved by the IRB and signed

and dated by the subject or the subject’s legally authorized

representative at the time of consent. A copy shall be given to the

person signing the form.

50.27(b) Except as provided in 56.109(c), the consent form may be either of

the following:

(b)(1) A written consent document that embodies the elements of informed

consent required by 50.25. This form may be read to the subject or

the subject’s legally authorized representative, but, in any event,

the investigator shall give either the subject or the representative

adequate opportunity to read it before it is signed.

(b)(2) A short form written consent document stating that the elements of

informed consent required by 50.25 have been presented orally to the

subject or the subject’s legally authorized representative. When this

method is used, there shall be a witness to the oral presentation.

Also, the IRB shall approve a written summary of what is to be said

to the subject or the representative. Only the short form itself is

to be signed by the subject or the representative. However, the

witness shall sign both the short form and a copy of the summary,

and the person actually obtaining the consent shall sign a copy of

the summary. A copy of the summary shall be given to the subject or

the representative in addition to a copy of the short form.

PART 56 INSTITUTIONAL REVIEW BOARDS

56.115 IRB records.

56.115(a) An institution, or where appropriate an IRB, shall prepare and

maintain adequate documentation of IRB activities, including the

following:

(1) Copies of all research proposals reviewed, scientific evaluations,

if any, that accompany the proposals, approved sample consent

documents, progress reports submitted by investigators, and reports

of injuries to subjects.

(2) Minutes of IRB meetings which shall be in sufficient detail to show

attendance at meetings; actions taken by the IRB; the vote on these

actions including the number of members voting for, against, and

abstaining; the basis for requiring changes in or disapproving

research; and a written summary of the discussion of controverted

issues and their resolution.

(3) Records of continuing review activities.

(4) Copies of all correspondence between the IRB and the investigators.

(5) A list of IRB members identified by name; earned degrees;

representative capacity; indications of experience such as board

certifications, licenses, etc., sufficient to describe each member’s

chief anticipated contributions to IRB deliberations; and any

employment or other relationship between each member and the

institution; for example: full-time employee, part-time employee, a

member of governing panel or board, stockholder, paid or unpaid

consultant.

(6) Written procedures for the IRB as required by 56.108 (a) and (b).

(7) Statements of significant new findings provided to subjects, as

required by 50.25.

56.115(b) The records required by this regulation shall be retained for at

least 3 years after completion of the research, and the records shall

be accessible for inspection and copying by authorized



of 198

representatives of the Food and Drug Administration at reasonable

times and in a reasonable manner.

PART 312 INVESTIGATIONAL NEW DRUG APPLICATION

312.57 Recordkeeping and record retention.

312.57(a) A sponsor shall maintain adequate records showing the receipt,

shipment, or other disposition of the investigational drug. These

records are required to include, as appropriate, the name of the

investigator to whom the drug is shipped, and the date, quantity,

and batch or code mark of each such shipment.

312.57(c) A sponsor shall retain the records and reports required by this part

for 2 years after a marketing application is approved for the drug;

or, if an application is not approved for the drug, until 2 years

after shipment and delivery of the drug for investigational use is

discontinued and FDA has been so notified.

312.58 Inspection of sponsor’s records and reports.

312.58(a) FDA inspection. A sponsor shall upon request...permit such officer

or employee to have access to and copy and verify any records and

reports relating to a clinical investigation conducted under this

part. Upon written request by FDA, the sponsor shall submit the

records or reports (or copies of them) to FDA. The sponsor shall

discontinue shipments of the drug to any investigator who has failed

to maintain or make available records or reports of the investigation

as required by this part.

312.58(b) Controlled substances. If an investigational new drug is a substance

listed in any schedule of the Controlled Substances Act (21 U.S.C.

801; 21 CFR part 1308), records concerning shipment, delivery,

receipt, and disposition of the drug, which are required to be kept

under this part or other applicable parts of this chapter shall, upon

the request of a properly authorized employee of the Drug Enforcement

Administration of the U.S. Department of Justice, be made available

by the investigator or sponsor to whom the request is made, for

inspection and copying. …

312.62 Investigator recordkeeping and record retention.

312.62(a) Disposition of drug. An investigator is required to maintain

adequate records of the disposition of the drug, including dates,

quantity, and use by subjects....

312.62(b) Case histories. An investigator is required to prepare and maintain

adequate and accurate case histories that record all observations

and other data pertinent to the investigation on each individual

administered the investigational drug or employed as a control in

the investigation. Case histories include the case report forms and

supporting data including, for example, signed and dated consent

forms and medical records including, for example, progress notes of

the physician, the individual’s hospital chart(s), and the nurses`

notes. The case history for each individual shall document that

informed consent was obtained prior to participation in the study.

312.62(c) Record retention. An investigator shall retain records required to

be maintained under this part for a period of 2 years following the

date a marketing application is approved for the drug for the

indication for which it is being investigated; or, if no application

is to be filed or if the application is not approved for such

indication, until 2 years after the investigation is discontinued

and FDA is notified.

312.68 Inspection of investigator’s records and reports.



of 198

An investigator shall upon request from any properly authorized

officer or employee of FDA, at reasonable times, permit such officer

or employee to have access to, and copy and verify any records or

reports made by the investigator pursuant to 312.62. The investigator

is not required to divulge subject names unless the records of

particular individuals require a more detailed study of the cases,

or unless there is reason to believe that the records do not represent

actual case studies, or do not represent actual results obtained.

12.2.4 GOOD MANUFACTURING PRACTICE (GMP)

Code of Federal Regulations, Part 211

211.68 Automatic, mechanical, and electronic equipment.

211.68(a) Automatic, mechanical, or electronic equipment or other types of

equipment, including computers, or related systems that will perform

a function satisfactorily, may be used in the manufacture,

processing, packing, and holding of a drug product. If such equipment

is so used, it shall be routinely calibrated, inspected, or checked

according to a written program designed to assure proper performance.

Written records of those calibration checks and inspections shall be

maintained.

211.68(b) Appropriate controls shall be exercised over computer or related

systems to assure that changes in master production and control

records or other records are instituted only by authorized personnel.

Input to and output from the computer or related system of formulas

or other records or data shall be checked for accuracy. The degree

and frequency of input/output verification shall be based on the

complexity and reliability of the computer or related system. A

backup file of data entered into the computer or related system shall

be maintained except where certain data, such as calculations

performed in connection with laboratory analysis, are eliminated by

computerization or other automated processes. In such instances a

written record of the program shall be maintained along with

appropriate validation data. Hard copy or alternative systems, such

as duplicates, tapes, or microfilm, designed to assure that backup

data are exact and complete and that it is secure from alteration,

inadvertent erasures, or loss shall be maintained.

211.180 General requirements.

211.180(a) Any production, control, or distribution record that is required to

be maintained in compliance with this part and is specifically

associated with a batch of a drug product shall be retained for at

least 1 year after the expiration date of the batch or, in the case

of certain OTC drug products lacking expiration dating because they

meet the criteria for exemption under 211.137, 3 years after

distribution of the batch.

(b) Records shall be maintained for all components, drug product

containers, closures, and labeling for at least 1 year after the

expiration date or, in the case of certain OTC drug products lacking

expiration dating because they meet the criteria for exemption under

211.137, 3 years after distribution of the last lot of drug product

incorporating the component or using the container, closure, or

labeling.

(c) All records required under this part, or copies of such records,

shall be readily available for authorized inspection during the

retention period at the establishment where the activities described

in such records occurred. These records or copies thereof shall be

subject to photocopying or other means of reproduction as part of



of 198

such inspection. Records that can be immediately retrieved from

another location by computer or other electronic means shall be

considered as meeting the requirements of this paragraph.

(d) Records required under this part may be retained either as original

records or as true copies such as photocopies, microfilm, microfiche,

or other accurate reproductions of the original records. Where

reduction techniques, such as microfilming, are used, suitable reader

and photocopying equipment shall be readily available.

(e) Written records required by this part shall be maintained so that

data therein can be used for evaluating, at least annually, the

quality standards of each drug product to determine the need for

changes in drug product specifications or manufacturing or control

procedures….

211.182 Equipment cleaning and use log.

A written record of major equipment cleaning, maintenance (except

routine maintenance such as lubrication and adjustments), and use

shall be included in individual equipment logs that show the date,

time, product, and lot number of each batch processed. If equipment

is dedicated to manufacture of one product, then individual equipment

logs are not required, provided that lots or batches of such product

follow in numerical order and are manufactured in numerical sequence.

In cases where dedicated equipment is employed, the records of

cleaning, maintenance, and use shall be part of the batch record.

The persons performing and double-checking the cleaning and

maintenance (or, if the cleaning and maintenance is performed using

automated equipment under 211.68, just the person verifying the

cleaning and maintenance done by the automated equipment) shall date

and sign or initial the log indicating that the work was performed.

Entries in the log shall be in chronological order.

211.186 Master production and control records.

211.186(a) To assure uniformity from batch to batch, master production and

control records for each drug product, including each batch size

thereof, shall be prepared, dated, and signed (full signature,

handwritten) by one person and independently checked, dated, and

signed by a second person. The preparation of master production and

control records shall be described in a written procedure and such

written procedure shall be followed.

211.188 Batch production and control records.

211.188 Batch production and control records shall be prepared for each batch

of drug product produced and shall include complete information

relating to the production and control of each batch. These records

shall include:

211.188 (a) An accurate reproduction of the appropriate master production or

control record, checked for accuracy, dated, and signed;

211.188 (b) Documentation that each significant step in the manufacture,

processing, packing, or holding of the batch was accomplished,

including: ….

211.192 Production record review.

All drug product production and control records, including those for

packaging and labeling, shall be reviewed and approved by the quality

control unit to determine compliance with all established, approved

written procedures before a batch is released or distributed. ….

211.194 Laboratory records.

211.194(a) Laboratory records shall include complete data derived from all tests



of 198

necessary to assure compliance with established specifications and

standards, including examinations and assays, as follows:

(1) A description of the sample received for testing with identification

of source (that is, location from where sample was obtained),

quantity, lot number or other distinctive code, date sample was

taken, and date sample was received for testing. ….

(4) A complete record of all data secured in the course of each test,

including all graphs, charts, and spectra from laboratory

instrumentation, properly identified to show the specific component,

drug product container, closure, in-process material, or drug

product, and lot tested.

(5) A record of all calculations performed in connection with the test,

including units of measure, conversion factors, and equivalency

factors. ….

(7) The initials or signature of the person who performs each test and

the date(s) the tests were performed.

(8) The initials or signature of a second person showing that the original

records have been reviewed for accuracy, completeness, and compliance

with established standards.

211.194(b) Complete records shall be maintained of any modification of an

established method employed in testing. Such records shall include

the reason for the modification and data to verify that the

modification produced results that are at least as accurate and

reliable for the material being tested as the established method.

(c) Complete records shall be maintained of any testing and

standardization of laboratory reference standards, reagents, and

standard solutions.

(d) Complete records shall be maintained of the periodic calibration of

laboratory instruments, apparatus, gauges, and recording devices

required by 211.160(b)(4).

(e) Complete records shall be maintained of all stability testing

performed in accordance with 211.166.

211.196 Distribution records.

Distribution records shall contain the name and strength of the

product and description of the dosage form, name and address of the

consignee, date and quantity shipped, and lot or control number of

the drug product. For compressed medical gas products, distribution

records are not required to contain lot or control numbers.

211.198 Complaint files.

211.198(a) Written procedures describing the handling of all written and oral

complaints regarding a drug product shall be established and

followed. Such procedures shall include provisions for review by the

quality control unit, of any complaint involving the possible failure

of a drug product to meet any of its specifications and, for such

drug products, a determination as to the need for an investigation

in accordance with 211.192. Such procedures shall include provisions

for review to determine whether the complaint represents a serious

and unexpected adverse drug experience which is required to be

reported to the Food and Drug Administration in accordance with

310.305 and 514.80 of this chapter.

211.198(b) A written record of each complaint shall be maintained in a file

designated for drug product complaints. The file regarding such drug

product complaints shall be maintained at the establishment where

the drug product involved was manufactured, processed, or packed, or



of 198

such file may be maintained at another facility if the written records

in such files are readily available for inspection at that other

facility. Written records involving a drug product shall be

maintained until at least 1 year after the expiration date of the

drug product, or 1 year after the date that the complaint was

received, whichever is longer. In the case of certain OTC drug

products lacking expiration dating because they meet the criteria

for exemption under 211.137, such written records shall be maintained

for 3 years after distribution of the drug product. ….

12.2.5 Examples From US Regulation CFR Part 820

This sub-section contains examples of records and signatures required by 21 CFR

820 (Medical Device Quality System Regulation).

820.3(e) Design history file (DHF) means a compilation of records which

describes the design history of a finished device.

820.3(i) Device history record (DHR) means a compilation of records

containing the production history of a finished device.

820.3(j) Device master record (DMR) means a compilation of records containing

the procedures and specifications for a finished device.

820.30(j) Design history file. Each manufacturer shall establish and maintain

a DHF for each type of device. The DHF shall contain or reference

the records necessary to demonstrate that the design was developed

in accordance with the approved design plan and the requirements of

this part.

820.40(a) Document approval and distribution. Each manufacturer shall

designate an individual(s) to review for adequacy and approve prior

to issuance all documents established to meet the requirements of

this part. The approval, including the date and signature of the

individual(s) approving the document, shall be documented.

Documents established to meet the requirements of this part shall

be available at all locations for which they are designated, used,

or otherwise necessary, and all obsolete documents shall be promptly

removed from all points of use or otherwise prevented from

unintended use.

820.40(b) Document changes. Changes to documents shall be reviewed and

approved by an individual(s) in the same function or organization

that performed the original review and approval, unless specifically

designated otherwise. Approved changes shall be communicated to

the appropriate personnel in a timely manner. Each manufacturer

shall maintain records of changes to documents. Change records shall

include a description of the change, identification of the affected

documents, the signature of the approving individual(s), the

approval date, and when the change becomes effective.

820.72(b)(2) Calibration records. The equipment identification, calibration

dates, the individual performing each calibration, and the next

calibration date shall be documented. These records shall be

displayed on or near each piece of equipment or shall be readily

available to the personnel using such equipment and to the

individuals responsible for calibrating the equipment.

820.80(e) Acceptance records. Each manufacturer shall document acceptance

activities required by this part. These records shall include:

(1) The acceptance activities performed;

(2) the dates acceptance activities are performed;

(3) the results;

(4) the signature of the individual(s) conducting the acceptance

activities; and



of 198

(5) where appropriate the equipment used. These records shall be

part of the DHR.

820.180 All records required by this part shall be maintained at the

manufacturing establishment or other location that is reasonably

accessible to responsible officials of the manufacturer and to

employees of FDA designated to perform inspections. Such records,

including those not stored at the inspected establishment, shall be

made readily available for review and copying by FDA employee(s).

Such records shall be legible and shall be stored to minimize

deterioration and to prevent loss. Those records stored in automated

data processing systems shall be backed up.

820.180(a) Confidentiality. Records deemed confidential by the manufacturer

may be marked to aid FDA in determining whether information may be

disclosed under the public information regulation in part 20 of

this chapter.

820.180(b) Record retention period. All records required by this part shall be

retained for a period of time equivalent to the design and expected

life of the device, but in no case less than 2 years from the date

of release for commercial distribution by the manufacturer.



of 198

12.3 EXAMPLES FROM EU REGULATIONS This sub-section contains indicative examples of records, signatures and

identifications required by EU Good Manufacturing Practice.

CHAPTER 4: DOCUMENTATION

Generation and Control of Documentation

4.1 All types of document should be defined and adhered to. … Many documents

(instructions and/or records) may exist in hybrid forms, i.e. some elements

as electronic and others as paper based. Relationships and control measures

for master documents, official copies, data handling and records need to be

stated for both hybrid and homogenous systems. Appropriate controls for

electronic documents such as templates, forms, and master documents should

be implemented. Appropriate controls should be in place to ensure the

integrity of the record throughout the retention period.

4.2 …. The reproduction of working documents from master documents should not

allow any error to be introduced through the reproduction process.

4.3 Documents containing instructions should be approved, signed and dated by

appropriate and authorised persons. Documents should have unambiguous

contents and be uniquely identifiable. The effective date should be defined.

Good Documentation Practices

4.8 Records should be made or completed at the time each action is taken and in

such a way that all significant activities concerning the manufacture of

medicinal products are traceable.

4.9 Any alteration made to the entry on a document should be signed and dated;

the alteration should permit the reading of the original information. Where

appropriate, the reason for the alteration should be recorded

Retention of Documents

4.10 It should be clearly defined which record is related to each manufacturing

activity and where this record is located. Secure controls must be in place

to ensure the integrity of the record throughout the retention period and

validated where appropriate.

4.11 Specific requirements apply to batch documentation which must be kept for

one year after expiry of the batch to which it relates or at least five years

after certification of the batch by the Qualified Person, whichever is the

longer. For investigational medicinal products, the batch documentation must

be kept for at least five years after the completion or formal discontinuation

of the last clinical trial in which the batch was used. Other requirements

for retention of documentation may be described in legislation in relation

to specific types of product (e.g. Advanced Therapy Medicinal Products) and

specify that longer retention periods be applied to certain documents.

4.12 For other types of documentation, the retention period will depend on the

business activity which the documentation supports. Critical documentation,

including raw data (for example relating to validation or stability), which

supports information in the Marketing Authorisation should be retained whilst

the authorization remains in force. It may be considered acceptable to retire

certain documentation (e.g. raw data supporting validation reports or

stability reports) where the data has been superseded by a full set of new

data. Justification for this should be documented and should take into account

the requirements for retention of batch documentation; for example, in the

case of process validation data, the accompanying raw data should be retained

for a period at least as long as the records for all batches whose release

has been supported on the basis of that validation exercise.

Specifications



of 198

4.13 There should be appropriately authorised and dated specifications for

starting and packaging materials, and finished products.

Manufacturing Formula and Processing Instructions

Approved, written Manufacturing Formula and Processing Instructions should

exist for each product and batch size to be manufactured.

Packaging Instructions

4.19 Approved Packaging Instructions for each product, pack size and type should

exist.

Batch Processing Record

4.20 A Batch Processing Record should be kept for each batch processed. It should

be based on the relevant parts of the currently approved Manufacturing Formula

and Processing Instructions, and should contain the following information:

….

c) Identification (initials) of the operator(s) who performed each significant

step of the process and, where appropriate, the name of any person who checked

these operations;

f) A record of the in-process controls and the initials of the person(s) carrying

them out, and the results obtained;

i) Approval by the person responsible for the processing operations.

Batch Packaging Record

4.21 A Batch Packaging Record should be kept for each batch or part batch

processed. It should be based on the relevant parts of the Packaging

Instructions.

The batch packaging record should contain the following information: ….

c) Identification (initials) of the operator(s) who performed each significant

step of the process and, where appropriate, the name of any person who checked

these operations;

d) Records of checks for identity and conformity with the packaging instructions,

including the results of in-process controls;

g) Notes on any special problems or unusual events including details, with

signed authorisation for any deviation from the Packaging Instructions;

i) Approval by the person responsible for the packaging operations



of 198

12.4 EXAMPLES FROM ICH Q7 This sub-section contains indicative examples of records, signatures and approvals

required by ICH Q7 (see Appendix xx, reference xx).

ICH Q7 § 2.4 Internal Audits (Self Inspection)

2.40 In order to verify compliance with the principles of GMP for APIs, regular

internal audits should be performed in accordance with an approved schedule.

ICH Q7 § 6.1 Documentation System and Specifications

6.10 All documents related to the manufacture of intermediates or APIs should be

prepared, reviewed, approved, and distributed according to written

procedures. Such documents can be in paper or electronic form.

6.14 When entries are made in records, these should be made indelibly in spaces

provided for such entries, directly after performing the activities, and

should identify the person making the entry. Corrections to entries should

be dated and signed and leave the original entry still readable.

6.18 If electronic signatures are used on documents, they should be authenticated

and secure.

ICH Q7 § 6.4 Master Production Instructions (Master Production and Control

Records)

6.40 To ensure uniformity from batch to batch, master production instructions

for each intermediate and API should be prepared, dated, and signed by one

person and independently checked, dated, and signed by a person in the

quality unit(s).

ICH Q7 § 6.5 Batch Production Records (Batch Production and Control Records)

6.51 These records should be numbered with a unique batch or identification

number, dated and signed when issued….

6.52 Documentation of completion of each significant step in the batch production

records (batch production and control records) should include: …

- Signatures of the persons performing and directly supervising or checking

each critical step in the operation.

ICH Q7 § 6.6 Laboratory Control Records

6.60 Laboratory control records should include complete data derived from all

tests conducted to ensure compliance with established specifications and

standards, including examinations and assays, as follows:...

- The signature of the person who performed each test and the date(s) the

tests were performed; and

- The date and signature of a second person showing that the original

records have been reviewed for accuracy, completeness, and compliance

with established standards.

ICH Q7 § 6.7 Batch Production Record Review

6.70 Written procedures should be established and followed for the review and

approval of batch production and laboratory control records, including

packaging and labelling, to determine compliance of the intermediate or API

with established specifications before a batch is released or distributed.

6.71 Batch production and laboratory control records of critical process steps

should be reviewed and approved by the quality unit(s) before an API batch

is released or distributed. Production and laboratory control records of

non-critical process steps can be reviewed by qualified production personnel

or other units 6.71 Batch production and laboratory control records of

critical process steps should be reviewed and approved by the quality unit(s)

before an API batch is released or distributed. Production and laboratory



of 198

control records of non-critical process steps can be reviewed by qualified

production personnel or other units following procedures approved by the

quality unit(s).

13 CASE STUDIES

13.1 SPREADSHEET FOR BATCH RELEASE CALCULATIONS BASED ON MANUAL INPUT OF LAB DATA TO A TEMPLATE

Table Heading 1 Table Heading 2

System: Spreadsheet supporting a QC calculation

System Description and

Primary Business

Purpose:

Template for a calculation required for batch release

based on multiple product parameters

Potential Users: QC, Quality Assurance

User Interface: PC

Potential System

Interface(s)

LIMS, instruments, or manual input

Electronic Data: Operator identity

Date and time

Material identity

Assay

Uniformity

Impurity limits

quantification

calculation of based on input data

Electronic Records (GxP

Impact): QC testing of finished pharmaceuticals products,

APIs, in-process samples and raw materials

Stability testing

Batch release records

Electronic Signatures: Possibilities various applications of PKI either

through the spreadsheet tool or by applying the

signature to a PDF.

Typical Hybrid

situations for records

and signatures:

Paper copies should include both a printout of the

results of the calculations and a printout showing the

calculations12

Typical Access Controls: The template should have cells locked and password

protected except for those required for data entry.

The template should be stored in a secure directory.

Users should only be able to copy the template to

another directory for editing. Once the data entry is

12 The spreadsheet tool should have the capability to display cell functions. For example, in Microsoft Excel® this is done by the keystroke sequence <CTRL><~>



of 198


completed the file should be stored in a secure

location, protected from further editing.

Consideration should be given to conversion to a more

immutable format such as PDF.

Audit trail: Audit trails are not innately available for

spreadsheets, although there are commercially

available add-ins that purport to have that capability.

Managing the files in an EDMS is a good solution.

Data typically subject

to formal change control

The template and the completed calculations should be

subject to formal change control

Procedures typically

required:

System use, change control, user access control,

management of completed spreadsheets

Special issues that may

need to be considered:

None

Validation Required: Calculations should be formally verified as being the

correct calculations. There is no need to validate

standard spreadsheet functions. If the spreadsheet

includes macros, these are effectively small computer

programs and should be validated. See GAMP® 5 Appendix

XX for further guidance.

Validation Responsible: QC / QA

Project Phase

Considerations:

Not applicable

Operation Phase

Consideration:

Change control

Backup of GxP data and records

Retirement

Considerations:

Data retention, archiving of data and validation

documentation

13.1.1 Records Risk Assessment and Controls Considerations

Type of Data Risks Controls Comments

Calculations Unauthorized access

to methods

Locked cells

Storage in a secure

location

Electronic

Saved Data Unauthorized access

to calculated data

Storage in a secure

location

Conversion to PDF

Preserve electronic

copies in an EDMS

Printed

Paper

Records

Completeness,

accuracy of data

contained in printed

records

Include printout of

calculations as

part of the report

All records Not retained in a

retrievable manner

for the duration of

the records retention

Records / Data

retention policies

in place

Backup and Archive



of 198


period processes in place

and tested

Use of an EDMS

13.2 AUTOMATED FORMULATION PRODUCTION & PACKING EQUIPMENT


System: Formulation Production & Packing Equipment


Primary Business

Purpose:

Management and control of formulation production

machines & packing lines. Control systems linked to

machine sensors control the machine according to fixed

data and recipe instructions and according to input

from HMI panel. The control system sets and monitors

critical parameters and the machine has alarms to warn

if approaching or outside limits.

Potential Users: Pharma Production Departments, Operators,

Supervisors, Managers and Maintenance Staff

User Interface: HMI terminal interface to a PLC, may be linked to a

SCADA in sophisticated applications.

Potential System

Interface(s)

May be linked to SCADA or MES via a local area network

for downloading settings for managing recipe or

uploading data to create a batch record for later

review as part of batch release. However, stand-alone

devices are common.

Electronic Data: Machine data can be categorized as:

Master Data: Machine settings, product settings,

recipe instructions

Recorded Data including alarms covering :-

o Date and time

o Operator data - operator identity

o Process data : quantities, weight, volume

o Operating parameters

o Processing times

o Environmental conditions, RH, delta P, room

temp


Impact):

Unlikely to retain electronic records. These systems

are not suitable for long term storage of regulated

electronic records. Electronic records should be

transferred to a separate batch record system for long

term storage as soon as possible.

Records may be transferred to :-

o a SCADA or MES system via a network

o recorded on a separate electronic system not

connected to the equipment

o recorded on a paper system

May have data about changes to critical parameters in

an audit trail

Electronic Signatures: Operator signatures for changing master data or for



of 198


confirmation of key recipe steps or acknowledging

alarms should be transferred to the batch record and

transferred to anther system as soon as possible.

Typical Hybrid


and signatures:

Records may be generated by the system and then printed

out for subsequent review and approval as part of a

paper batch record. It may not be possible to record

confirmation of key recipe steps or managing alarms

and this may have to be on the batch record system

which is a separate system on paper or on a separate

electronic system not connected to the equipment.

Typical Access Controls: Access control is always required but older machines

may only have physical control.

Logical access control may be standalone user-id and

password or may have group password.

Equipment SCADA or MES network may have network access

controls.

Audit trail: Electronic audit trails are provide by newer systems,

old equipment may not have these.

If available audit trail should be used to track

changes to fixed data , and can be used for

investigation or internal audit. Changes to critical

parameters should be formally managed by change control

procedures.

Data or operating

parameters typically

subject to formal change

control

Changes to master data or fixed data associated with

critical process parameters (CPPs and alarm settings)

should be managed with change control and access

control.

Especially important are any changes to warning and

action alarms which production have to operate within.

These are related to proven acceptable ranges (PAR)

with limits tested during validation.

For equipment it is often difficult to access and

change process raw data. Summary batch data should be

transferred to a separate batch record system with its

own controls as soon as possible.

Hardware, software, documentation and configuration

should be under change control.


required:

SOPs are required for :-

o managing access controls

o machine set up

o machine operation including allowable

changes

o managing alarms

o managing changes to critical parameters

o managing the audit trail

o backup of fixed data

o backup of operating software



These systems are not suitable for long term storage

of regulated electronic records. Electronic records

should be transferred to a separate batch record system

for long term storage as soon as possible

Records may be transferred to :-

o a SCADA or MES system via a network

o recorded on a separate electronic system not



of 198


connected to the equipment

o recorded on a paper system

If there is a critical alarm then these must be

investigated by appropriate procedure (CAPA) and close

out by QA. The batch should not be accepted or released

until deviations are investigated and assessed. Once

the batch is finished and accepted the summary data

may be transferred. The raw data may not be required

further unless for engineering purposes.

Validation Required: Equipment qualification includes the validation of the

process control system (should be an integrated

approach with the equipment). This has to be completed

before process validation. See below for important

testing requirements.

Process validation includes confirmation of CPPs and

the high and low values which production have to

operate within based on proven acceptable ranges.

Validation Responsible: Pharmaceutical Company is responsible but often

delegated to Project Contractor or to Supplier. VMP/

VPs and SME’s and key validation documents should be

reviewed and approved by the Pharma Company to ensure

that the documents meet requirements including the

points in this guidance.

Project Phase

Considerations:

FAT and/ or SAT should include testing of data transfer

to other systems

And testing of key controls eg.

o access controls

o machine set up and operation of the HMI

o machine operation including allowable

changes

o alarms

o managing changes to critical parameters

o managing the audit trail

o backup and restore of fixed data and

operating software

Operation Phase

Consideration:

Backup the fixed data & operating software every month

and store in a safe place eg the warehouse.

Only retain operating data in the machine until batch

is released. If have alarms then retain the event log

for investigation, internal audit or for maintenance.

Retirement

Considerations:

Normally not an issue as long term data is not

retained.



of 198


Type of

Data

Risks Controls Comments

Master Data Unauthorized

access to master

data

Access control with

unique User Accounts if

possible

Group based user

accounts with SOP

control of groups

Change control procedure

Audit trail master data

if possible

Internal audits

Include in

validation testing

Data

Transfer

via

Interface

Incorrect data

mapping

Failure of data

transfer

Recovery of data

following

interface

failure

Validation of interface

Warnings of interface

failure

Automatic recovery if

possible

Data transport files

protected from

unauthorized user access

Include in

validation testing

Electronic

Saved Data Unauthorized

access of

electronic files

in batch record

system (outside

of equipment

sytem)

Saved records in a

secure format e.g. PDF

Records stored in a

secure location (and

backed up)

Only accessible by

authorized users

Routine backup and

restore

Internal audit

SOPs should define use

and management of such

records

Saved records validated

for completeness and

accuracy

Include in

validation testing

Printed

Paper

Records

Completeness,

accuracy of data

contained in

printed records

Linkage to

between

electronic and

paper records

Completeness of

paper records vs

electronic

records

Printed paper records

should be linked to

electronic counterpart

Printed records should

be validated for

completeness and

accuracy including

associated meta data

contained in the

electronic record.

Include in

validation testing

Data

retention

All records

Not retained in a

retrievable

manner for the

duration of the

Records / Data retention

policies in place

Backup and restore

processes in place and

Include in

validation testing



of 198

Type of

Data

Risks Controls Comments

records

retention period

tested

Training on SOPs

Internal audits



of 198

13.3 BUILDING MANAGEMENT SYSTEM (BMS)


System: Building Management System


Primary Business

Purpose:

Controls and monitors production and non-production

environments, utilizes and services. Other areas of

use include:

Energy management

Lighting control

Security

Access control

Fire alarm system

Lifts, elevators

Potential Users: Engineering, Production, Quality Assurance

User Interface: Graphical user interface, pc, tablet, dedicated

controller

Potential System

Interface(s)

Data Historian

Electronic Data: Process Parameters, Process Measurements


Impact):

Sequence Logic, Recipes, Process Parameters, Process

Measurements, Alarm logs, Alarm Limits, Process Trends

Electronic Signatures: Modern technologies may include electronic signatures

for batch

Typical Hybrid


and signatures:

Alarm logs and process data trends may be printed and

signed as part of batch records

Typical Access Controls: Logical user access security, network security

Different access levels, usually configurable by role

Audit trail: Modern systems include audit trail capability for

managing changes to configuration and process

parameters, alarm limits, recipes

Data or operating



control

Process setpoints, alarm limits, instrumentation

configuration, data trending setup


required:

System use, change control, user access control



BMS is often segregated from Environmental Monitoring

System (EMS). The EMS monitors GxP process

measurements, reports GxP alarms and trends GxP

measurements

If there is no reliance on the BMS for monitoring,

recording and reporting GxP activities then validation

is focussed on EMS.

Validation Required: Where controlling and monitoring GxP processes. Where

EMS is implemented for GxP process monitoring and data

recording / reporting the EMS is the focus of

https://en.wikipedia.org/wiki/Access_control

https://en.wikipedia.org/wiki/Fire_alarm_system

https://en.wikipedia.org/wiki/Elevator

https://en.wikipedia.org/wiki/Elevator



of 198


validation.

Validation Responsible: Engineering / QA

Project Phase

Considerations:

Factory acceptance and commissioning can be leveraged

in support of validation if conducted in a controlled

manner and in accordance with Good Documentation

Practice.

Operation Phase

Consideration:

Change control

Configuration management

Instrument calibration

Engineering Maintenance

Service Level management

Backup of GxP data and records

Disaster Recovery

Retirement

Considerations:

Retention of process data e.g. trended GxP data, GxP

alarm logs

Archive of validation documentation



Recipes Unauthorized access

to recipes data

Unique User

Accounts

Role Based Security

at data element

level

Audit trail recipe

changes

Process

Parameters,

Alarm Limits,

Trend

configuration

Unauthorized access

to recipes data

Unique User

Accounts

Role Based Security

at data element

level

Audit trail recipe

changes

Interfaced

Data Process data sent to

data historian

Interface failure

Interface outage and

back log of data

Validation of

interface

failures, data

mapping, interface

triggers

Reconciliation of

data between

interfaced systems

Inflight data

protected from

unauthorized user

access

Electronic


to recipes,

configuration,

Unique User

Accounts

Role Based Security



of 198


process parameters,

alarm data

at data element

level

Audit trail changes

Printed Paper

Records E.g. alarm logs,

trends

Completeness,

accuracy of data


records

Printed records

should be validated

for completeness

and accuracy


retrievable manner

for the duration of


period

Records / Data

retention policies

in place

Backup and Archive

processes in place

and tested



of 198

13.4 INTERACTIVE RESPONSE TECHNOLOGIES (IRT)


System: Interactive Response Technologies (IRT)


Primary Business

Purpose:

Data management system.

A system designed to enable the provision of critical

data to a centrally located database via the use of

interactive response technology (IRT), encompassing

both interactive voice response systems (IVRS)

utilizing the telephone or tone diallers and

interactive web response systems (IWRS) utilizing the

internet. Such systems are increasingly used by the

pharmaceutical industry for Clinical Trials.

An IRT consists of hardware and software configured

and coded to allow a high degree of customization for

specific sponsor requirements with respect to clinical

study protocol design. The system optimizes drug

availability at sites and collects information from

callers (medical professionals and / or patients), who

respond to pre-configured prompts via the telephone

keypad or computer web-browser.

User Interface: Typically a telephone receiver and keypad, or PC based

web-browser

Potential System

Interface(s)

Such systems are typically networked on a LAN with

external connections via the WAN or public telephone

system.

Electronic Data: Information such as patient details, subject consent,

dispensed packs, patient diary records.

Recruitment information, patient diary records, drug

inventory details, product recalls, expiry dating,

monitoring reports.

Linkage to other systems is dependent upon organization

and study design. Some companies may be able to

integrate their own Clinical Trials Management systems

(CTMS) with the real-time information contained within

the IRT database via remote connection. A similar

scenario may exist for Clinical Trials Supplies systems

and IRT. In other cases this data transfer could be

paper-based.


Impact):

This system will hold patient data information and

other personally identifiable information (PII) in

addition to information supporting management of the

Clinical Trail e.g. randomization data and expiry dates

for the investigational medicinal product (IMP).

Such data can be regarded as high impact.

Electronic Signatures: No e-signatures are typically applied to records within



of 198


IRT, although printed-paper records may be signed by

hand.

Typical Hybrid


and signatures:

Print out data for transfer into regulatory

submissions.

Typical Access Controls: Access permissions should be based upon the delegated

activities of different roles. This will necessitate

the implementation of domain and network access

controls, network user-id and password, application

user-id and password. The system will also require both

physical and procedural controls to restrict access to

servers/computer room.

Audit trail: Yes, a readily accessible audit trail is required.

Audit trails should be available for all data related

to the project/study protocol including any

alterations to critical parameters either as a result

of interacting with the system or manual interventions

(e.g. amendments to data if response was incorrect).

Data or operating



control

Changes to critical parameters relating to each

project/study protocol, and amendments to response

data should be controlled by audit trail and standard

operating procedures.


required:

Specific procedures required for system access

controls, module configuration, data entry, change

control and disaster recovery.



This critical high impact system should have a verified

‘hot’ backup and restore process, design to maintain

24 hours a day global availability and emergency

unblinding (if applicable), and a Business Continuity

Plan.

Retirement

Considerations:

Definition of mechanisms for system closure via either

an automated process or one that is manually initiated

by the sponsor, such that the IRT is shut off at the

end of the clinical study



of 198



System

configuration Incorrect set up

Loss of system

availability

Loss of integrity

Formalized system

development life

cycle approach

Risk based

qualification and

validation



of 198

13.5 ENTERPRISE RECOURSE PLANNING (ERP) SYSTEM


System: Enterprise Resource Planning System


Primary Business

Purpose:

Management of enterprise resource planning data. Key

foundation in integrated enterprise wide business

planning, finance, manufacturing and quality

management. Involved with entire supply chain process

of a company.

Typically, the modules and business process encompass:

Order to Cash (Order Entry; Pick/Pack/Ship; Accounts

Receivable)

Procure to Pay (Purchasing; Receiving; Accounts

Payable)

Manufacturing and Inventory Control (Forecasting;

Planning; Work Order Management; Warehouse

Management; Quality Management; Plant Maintenance;

Cost Accounting)

Human Resources Information System (Payroll; Time

Management)

Potential Users: Planning, Production, Packaging, Warehouse, Quality

Control, Quality Assurance, Procurement, Customer

Services, Finance, Human Resources, Engineering, IT

User Interface: The system can be client server based.

The system could be connected to a midrange computer

such as an AS/400. The user interface could be PC based

with Graphical User Interface (GUI) client software or

terminal emulation, or terminals could be used.

Potential System

Interface(s)

The ERP system could be linked to a wide variety of

systems including:

Dispensing

Warehouse Management System (WMS)

Transportation

Customer Relationship Management

Laboratory Information System (LIMS)

Quality Systems

Manufacturing Execution System (MES) in real time

EDI

Forecasting

Logistics

Could be on a global network and the system could

control multiple sites.

Electronic Data: Some aspects of the system maintain and manage

regulated GxP data and some are non GxP (finance

records).

Although there is a significant volume of data, the

data is largely maintained in a central database, with

the different “records” such as material receipts,

batch records, QC inspection records essentially being

different views of the database created through



of 198


predetermined and validated queries and reports.

ERP data can be categorized as:

Master Data (Product; Materials; Customers;

Suppliers; Recipe; Maintenance; Sales)

Transactional Data Purchase Orders; Process Orders;

Batch; Inventory Records; QC Inspection Records)

Transmitted Data (Interfaces transmitted sub

contract manufacturing; Inventory and distribution

records to 3rd party logistics companies)


Impact): Lot Master (H): Status. Lot numbers, expiry date,

potency, lot reconciliation

Lot Tracing/Recall Data (H)

Approved Vendors (M)

Certificate of Analysis (H)

Bill of Materials (H)

Work Order Information

Manufacturing Instructions

Material/Finished Product Specifications (M-H)

Distribution Records (H)

Batch Records (H)

Training Records (M)

Maintenance Records (H)

Material Test Data ( )

Electronic Signatures: Certificate of Analysis

Electronic Change Management

Electronic Batch Records

Quality signatures for material usage/release/hold

Typical Hybrid


and signatures:

Items approved online so they can be used to

manufacture product or to ship to customers but where

there is no electronic signature facility available.

Typical Access Controls: The systems typically have elaborate security control

that provide users with secure access by user-ID and

password that range from transaction level to field

level depending on the system and criticality of the

business processes.

Audit trail: Typically audit trails are provide by modern systems.

Audit trail may be configured for a specific

transaction or a table (by activating table logging).

This would allow for a risk-based approach for the data

that would require an audit trail (critical GxP data

versus non-GxP data that may not require the same rigor

of control).

There are further Engineering Change Control systems

that can be applied for master file versioning.

Data or operating



control

Hardware, software, documentation and configuration

are under change control.

Changes to master files and system transactions are

typically controlled through (electronic) change



of 198


control procedures and system security.


required:

Information Technology procedures for managing the

system, such as Security Management; Change Control;

Backup and Recovery; Disaster Recovery; Incident

Management; Performance Monitoring.

Business procedures for the business processes and

system operations that include how to perform system

transactions.


need to be considered: Size and scale of the system so risk based approach

to validation is recommended

Consistent application of validation approach (may

be implemented across sites, by different groups)

Potential global nature of system

Management of the solution template across multiple

organisations and locations

Control of a system which may have GxP and non GxP

elements

Data Conversion during project implementation.

Control and compliance of supporting infrastructure

Configuration management

Data archiving and long term storage

Use of quality reports from the system

Validation Required: GxP processes and functionality typically determined

by process and functional risk assessment. Electronic

records risk assessment identifies GxP records.

Project should be structured to ensure clarity of user

requirements and business process definition before

implementation and validation.

Validation activities usually integrated with system

integrator methodology, usually an iterative approach

to system configuration.

Supplier assessment should ensure that system

integrator understands regulatory requirements and

good documentation practices.

Validation Responsible: User organization would lead validation in association

with QA. May need QA representation across functions.

Often need validation and QA responsibilities at core

system and site level to address global and local

aspects.

Project Phase

Considerations:

Configurable aspects are often iterative and therefore

design and configuration are developed in situ. Must

ensure traceability between processes, requirements,

design and configuration before testing.

May be able to leverage conference room pilot testing

in support of validation if conducted to Good

Documentation Practices.

Business Processes and Risk Assessment

User Requirements (organized by module or business

process)



of 198


Configuration

Design verification for configured and custom

elements. Functional risk assessment for custom

elements and extensive business process configuration

Build (for custom elements)

Different environments for build, validation / test

and production

Installation / Operational / Performance verification

Operation Phase

Consideration:

Master data management is complex due to different

business functions involved (e.g. production, QA,

customer services, finance, etc)

Change control (consider a Change Review Board with

cross functional representation)

Configuration management for changes to out of the box

configuration

Retirement

Considerations:

Data migration is a major undertaken that requires

careful and early planning and management

ERP are based on centralized database of which circa

25% is GxP. Archiving GxP records in a retrievable

form is challenging

Validation documentation should be archived



Master Data Unauthorized access

to master data

Ownership of data

across multiple

locations

Ownership or data

elements within

master data records

e.g. item data has

data elements owned

by production,

quality, finance, etc

Unique User

Accounts

Role Based Security

at data element

level

Data Maintenance

process

Data Ownership

model supported by

change control

process that

engages data owners

Audit trail GxP

significant master

data elements

Understanding of

data ownership

with supporting

data management

processes is

essential

Transactional

Data Unauthorized

transaction

processing

Unique User

Accounts

Role Based Security

at transaction

level

Transaction logs

Business process

procedures

Training

Beware that audit

trails of

transactional

data impacts

system

performance and

data storage



of 198


Interfaced

Data Incorrect data

mapping

Failure of data

transfer triggers

Recovery of data

following interface

failure

Validation of

interface

failures, data

mapping, interface

triggers

Reconciliation of

data between

interfaced systems

Data transport

files protected

from unauthorized

user access

Electronic


of electronic files

in stored location

(outside of ERP)

Saved records e.g.

PDF records should

only be stored in

secure locations

that are only

accessible by

authorized users

SOPs should define

use and management

of such records

Saved records

validated for

completeness and

accuracy

Printed Paper

Records Completeness,

accuracy of data


records

Linkage to between

electronic and paper

records

Completeness of paper

records vs electronic

records

Printed paper

records should be

linked to

electronic

counterpart

Printed records

should be validated

for completeness

and accuracy


retrievable manner

for the duration of


period

Records / Data

retention policies

in place

Backup and Archive

processes in place

and tested



of 198

13.7 DRUG SAFETY SYSTEM


System: Drug Safety System


Primary Business

Purpose:

Collects processes and analyses Adverse Events /

Adverse Drug Reactions and supports the reporting to

regulatory agencies and other parties.

Potential Users: Drug Safety Department, Pharmacovigilance

User Interface: Graphical user interface, pc, tablet,

Potential System

Interface(s)

EDC systems, Call Centers and other computerized input

channels

Document Management Systems

Electronic Reporting to Regulatory systems

Electronic Data: Reporter Data

o Type: Health Care Professional,

Customer/Patient

o Contact data

o Date of Report

o Origin of Report

Patient Data

o Contact data

o Medical History

o Gender / Age etc.

o Lab Data

Drug/Device/Vaccine Data

o Manufacturer

o Dosage

o Treatment dates

o Concomitant medication

Event Data

o Verbatim and Coded Term

o Event Onset and duration

o Seriousness and severity

o Event outcome

Regulatory Report Data

o Regulatory Report forms

o Periodic Reports

o Submission data

Pharmacovigilance Data

o Signal Detection Data

Meta Data

o Case processor / Medical Assessor

o Follow-up tracking

o Source documentation


Impact): Safety Data of finished pharmaceuticals products or

investigational medical products

Individual and aggregated safety Reports including

submission tracking



of 198


Risk – Benefit Analysis / Safety Signals

To support this Safety System, create/collect the

following records:

Individual Case Safety Reports

· Aggregated / Periodic Safety Reports

· Safety Signals

· Tracking Reports

Electronic Signatures: Modern technologies include electronic signatures for

medical assessment approval and / or approvals for

submission

Typical Hybrid


and signatures:

The original record for Safety information can be

electronic or paper-based. Electronic records should

be maintained in electronic format while paper

documents should be scanned and then archived

appropriately.

Typical Access Controls: Logical user access security, network security

Different access levels, usually configurable by role

Audit trail: Modern systems include audit trail capability for

managing changes to data

Data typically subject

to formal change control

Users and User Groups, Workflows, reports, system

upgrades, Dictionaries


required:

System use, Data Entry Guideline, change control, user

access control



Long term data storage for data which has to be stored

for the life of the product and beyond.

Availability and Business continuity aspects due to

the time critical nature of the process.

Privacy and confidentiality aspects due to the

sensitive nature of the data.



of 198

14 DATA INTEGRITY MATURITY LEVEL CHARACTERIZATION

14.1 INTRODUCTION This Appendix supports the approach to assessing the maturity level of an organization in relation to data

integrity described in Section 6.5. The Data Integrity Maturity Model is a simple representation of the regulated

company, based on the status of the essential elements of effective processes for data integrity. In Section 6.5

maturity areas are identified and maturity factors are described for key aspects related to Data Integrity. Based

on this model companies can assess their current state of maturity, and understand what actions and improvements

are required to reach the next maturity level.

This appendix gives more detailed examples of possible or typical states related to the Maturity Levels, as

described in Section 6. These examples are intended to be indicative only, and should be considered and interpreted

within the specific context of individual organizations.

Table X.1 Data Integrity Maturity Level Characterization

Maturity Area Maturity Factors Maturity Level Characterization

Level 1 Level 2 Level 3 Level 4 Level 5

Culture

DI

Understandi

ng and

awareness

Awareness of the

importance of data

integrity, and

understanding of data

integrity principles

Low

awareness,

limited to

SMEs and

specialists

General

awareness of

the topic,

but not

fully

reflected in

working

practices

Principles

reflected in

working

practices, but

not consistently

applied

Data

integrity

principles

fully

incorporated

and applied

in

established

processes and

practices

Formal

ongoing

awareness

programme,

proactively

keeping

abreast of

industry

developments

Corporate

culture and

working

environment

A culture of willing and

open reporting for

errors, omissions and

abnormal results, and

willing collaboration

to achieve data

integrity objectives

Unwillingness

or no

motivation to

report errors

and abnormal

results.

DI problems

may be

reported but

mitigation

is either

inadequate

or ignored

Policies and

procedures

encourage

openness, but

not implemented

in all cases.

Mitigation

generally

limited to the

specific

instance

Full openness

and

collaboration

achieved

through such

behaviour

being

motivated by

management

behaviour.

Mitigation

considers

wider

implication

Anticipating

potential

future DI

weaknesses

and applying

appropriate

controls



of 198



Quality

Culture

An environment in which

employees habitually

follow quality

standards, take taking

quality-focused

actions, and

consistently see others

doing so.

Low awareness

and

application

of quality

principles

and

standards. A

culture of not

reporting

what

management

would rather

not hear

Ad-hoc

quality.

Activities

performed,

but relying

on

individual

efforts

General

application of

some quality

principles, but

not fully

ingrained or

consistent.

Quality

consideration

s

incorporated

in normal

working

practice

Quality and

continuous

improvement

incorporated

in normal

working

practice

Governance and

Organization

Leadership Objectives defined and

communicated by

executive management.

Leadership

silent or

inconsistent

on the need

for data

integrity.

Other

business

priorities

typically

override.

Leadership

state need

for DI, but

do not lead

by example.

Objectives

defined in

policies and

high level

statements, but

not always fully

reflected in

management

priorities.

Management

actions and

priorities

fully reflect

stated

objectives

DI aspects

routinely

addressed

and improved

as part of

management

review

Sponsorship Executive management

providing appropriate

resources and support.

Appropriate

resources

only made

available in

emergencies

(e.g.

critical

citation).

Appropriate

resources

available in

principle,

but often

not be

available in

practice due

to other

pressures.

Appropriate

resources

available, but

may be diverted

or diluted due

to other

pressures.

Required and

planned

resources are

available and

safeguarded

due to ongoing

commitment to

data

integrity

Management

looking

ahead to

identify

future

resource

needs, based

on

experience



of 198



Structure Appropriate roles and

reporting structures.

No

consideration

of specific

data

governance in

roles and

responsibilit

ies.

Data

governance

roles only

recently

established,

or in flux.

Data governance

roles

established, but

not always

effective.

Data

Governance

roles are well

integrated

into the

management

structures

and systems

Management

reviewing

and adapting

organization

al

structures

based on

experience

Stakeholder

Engagement

Engagement of business

Process Owners, Quality

Assurance, and key

supporting technical

groups (e.g. IT)

Data

integrity and

governance

seen as either

an IT issue or

a Quality

Issue. No real

Process Owner

involvement

Ad-hoc

involvement

of Process

Owners, and

Quality

Assurance.

High person

dependence.

Process Owners,

and Quality

Assurance

typically

involved, but

not consistently

Process

Owners,

Quality

Assurance,

and IT work

together

through the

data and

system life

cycles

All

stakeholders

consistently

work

together to

identify

further co-

operation

opportunitie

s, based on

experience.

Data

Ownership

Clear ownership of data

and data-related

responsibilities

Process,

system, and

data owners

not defined

Process,

system, and

data owners

identified

in few

areas.

Process, system,

and data owners

typically

defined in many,

but not all

cases, and

responsibilitie

s not always

clear

Process,

system, and

data owners

are well

defined and

documented.

Process,

system, and

data owner

responsibili

ties

considered

and

clarified

during

management

review.

Policies

and

Standards

Defined polices and

standards on data

integrity

No

established

policies and

standards for

data

integrity

Ad-hoc

policies and

standards

for data

integrity in

some cases

Polices and

standards exist,

but not fully

integrated into

the QMS and

business

process.

Policies and

standards

fully

integrated

into the QMS

and fully

reflected in

business

processes and

practices

Policies and

standards

regularly

reviewed and

improved

based on

experience



of 198



Procedures Established procedures

defining key activities

and processes

No

established

procedures

for key data

integrity

related

activities

Ad-hoc

procedures

for data

integrity in

some cases

Some procedures

and standards

exist, but not

covering all

data integrity

related

activities.

Procedures

for all key

areas fully

integrated

into the QMS

and

reflecting

established

policies and

standards.

Procedures

regularly

reviewed and

improved

based on

experience

Awareness

and

Training

Awareness and training

on regulatory

requirements and

organizational polices

and standards.

No real

awareness of

regulatory

requirements

and company

policy in this

area

Some

awareness of

regulatory

requirements

and company

policy, in

pockets.

General

awareness of

well-known

regulations, and

the existence of

company policies

Comprehensive

training

program

ensures an

appropriate

level of

knowledge of

specific

regulatory

and company

requirements

Formal

training

needs

analysis,

taking into

account

regulatory

developments

. Training

effectivenes

s assessment

for ongoing

improvement

Quality

Management

System

Established and

effective Quality

Management System,

focused on patient

safety, product quality

and data integrity.

Few

procedures in

place focused

on patient

safety,

product

quality and

data

integrity.

Some

procedures

and quality

control

processes,

but not

consistently

achieving

quality

goals.

Established

Quality

Management

System, but

compliance and

data integrity

activities are

not fully

effective

Established

and effective

Quality

Management

System,

consistently

achieving

data

integrity

goals in

support of

patient

safety and

product

quality

QMS subject

to regular

management

review and

continuous

improvement



of 198



Business

process

definition

Clear and accurate

definitions of

regulated business

processes, covering all

key GxP areas

Few business

processes

formally

defined and

documented

Some

business

processes

formally

defined and

documented

on an ad-hoc

basis,

either by

project or

operational

groups

Most business

processes

defined, but not

consistently

following

conventions or

standards, and

not always

complete and

up-to-date.

Business

processes

defined

following

established

conventions

and

standards.

Business

processes

defined and

supported by

appropriate

tools, and

consistently

maintained.

Supplier and

service

provider

management

Assessment of suppliers

and service providers

against agreed

standards, and setting

up and monitoring of

contracts and

agreements to deliver

those standards.

Many

suppliers and

providers

with a

potential

impact on data

integrity not

assessed or

managed

Some

suppliers

and

providers

with a

potential

impact on

data

integrity

informally

assessed

Established

process for

supplier

management, but

not applied

consistently.

Data integrity

implications not

always fully

covered by

assessments or

agreements

Established

process for

supplier

management,

consistently

applied, and

including a

data

integrity

risk review.

Effectivenes

s of supplier

management

subject to

regular

management

review based

on metrics.

Strategic

Planning and

Data Integrity

Program

Planning Executive level

strategic planning and

programs for improving

and/ or maintaining

data governance and

data integrity.

No planning

for data

integrity or

data

governance at

executive

level

Limited

planning for

data

integrity or

data

governance,

typically

driven by

emergencies

Specific Data

Integrity

program or

equivalent

underway.

Successful

Data

Integrity

programs

achieving

stated

objectives

Data

integrity

integral to

ongoing

organization

al strategic

planning



of 198



Communicati

on

Communication and

change management

processes, supported by

a suitable repository

of information and

resources.

No

communication

and change

management

process for DI

Some

informal and

person

dependent

communicatio

n and change

management.

Formal

communication

and change

management for

DI in place, but

on a per-project

or per-site

basis, with ad

hoc

repositories.

Communication

and change

management

for DI

integral to

QMS,

supported by

tools and

central

repository.

Communicatio

n and change

management

for DI

subject to

review and

improvement,

supported by

defined

metrics.

Regulatory

Awareness Awareness of applicable

regulatory requirements

No awareness

of key

regulatory

requirements.

Some

awareness of

detailed

regulatory

requirements

, based on

individual

experience

and effort.

Formal

regulatory

awareness-

raising

underway,

including

training on

regulations and

guidance.

All staff

aware of

regulatory

requirements

affecting

their work.

Formal

training

needs

analysis and

action,

taking into

account

regulatory

and industry

developments

.

Traceabilit

y

Traceability to

applicable regulatory

requirements from,

e.g., Quality Manual,

polices or procedures

No

traceability

to

regulations

Little

traceability

of policies

and

procedures

to specific

regulations.

Traceability in

place, but

limited to key

regulatory

requirements.

Full

traceability,

e.g. from

Quality

Manual or

policies, to

specific

regulatory

requirements.

Traceability

effectively

maintained

and updated

taking into

account

regulatory

developments



of 198



Inspection

readiness

Preparation for

inspection, including

responsibilities, and

inspection readiness

documentation.

No inspection

readiness

preparation

Limited

inspection

readiness

preparation

- ad-hoc and

dependent on

individual

Process and

System

Owners

Inspection

readiness

activities in

place, but

inconsistent in

level, content,

and approach

Established

process for

inspection

readiness

covering all

systems

maintaining

regulated

data and

records.

Inspection

readiness

processes

regularly

reviewed and

refined

based on

regulatory

and industry

developments

.

Regulatory

Relationshi

p and

communicati

ons

Effectiveness of

communication with

regulatory authorities,

and effectiveness of

dealing with concerns

and citations.

No

communication

except during

inspections,

when specific

citations are

addressed.

Ad-hoc ,

informal

communicatio

n as-and-

when

required,

not

following a

defined

procedure.

Communication

as-and-when

required,

following a

defined

procedure.

Effective,

consistent,

communication

with

regulatory

bodies

following a

defined

procedure.

Clear

communicatio

n lines to

key

regulatory

bodies, with

internal

specialists

following an

established

process.

Concerns and

citations

are

proactively

managed.

Data Life

Cycle

Data life

cycle

definition

Data life cycle(s)

defined in standards

and/or procedures

Data life

cycles not

defined.

Some data

life cycles

defined on

an ad-hoc

basis.

Data life cycles

generally

defined

following

procedures. Not

consistently

applied.

Data life

cycle defined

in

procedures,

and applied

consistently

to all key

regulated

data and

records.

Data life

cycles

defined f and

maintained,

supported by

effective

automated

tools



of 198



Quality

Risk

Management

Application of risk

management (including

justified and

documented risk

assessments) through

the data life cycle.

No documented

and justified

assessment of

risks to data

integrity

Limited data

integrity

risk

assessments

performed on

an ad-hoc

basis.

Data integrity

considered in

risk assessment

procedures, but

not performed to

a consistent

level.

Data

integrity

risk

management

established

as an integral

part of the

data life

cycle and

system life

cycle.

Quality Risk

Management

activities

subject to

continuous

improvement

Data

Management

processes

and tools

Established data

management processes,

supported by

appropriate tools.

No data

management

processes

Some data

management

processes

defined by

individual

Process

Owners

Data management

procedures

defined, but not

always

effectively

implemented

Well

established

and effective

data

management

processes.

Well

established

common data

management

processes,

maintained,

updated,

supported by

appropriate

automated

tools

Master and

reference

data

management

Established processes

to ensure the accuracy,

consistency, and

control of master and

reference data.

No

master/refere

nce data

management

processes

Some

master/refer

ence data

management

processes

defined by

individual

Process

Owners

Master/referenc

e Data

management

procedures

defined, but not

always

effectively

implemented

Well

established

and effective

master/refere

nce data

management

processes.

Well

established

common

master/refer

ence data

management

processes,

maintained,

updated,

supported by

appropriate

automated

tools



of 198



Data

Incident

and Problem

Management

Established processes

to deal with data

incidents and problems,

linked with change

management and

deviation management as

appropriate.

No formal data

incident and

data problem

management

process.

Some data

incident and

data problem

management

processes

defined by

individual

Process/Syst

em Owners

Data incidents

and problems

typically

effectively

dealt with as a

part of normal

system or

operational

incident

management, but

with limited

consideration of

wider DI

implications.

Established

data incident

and problem

management

process

linked to CAPA

and deviation

management

where

necessary.

Established

data

incident and

problem

management

process,

supported by

tools and

appropriate

metrics,

leading to

process

improvement.

Access and

Security

management

Establishing technical

and procedural controls

for access management

and to ensure the

security of regulated

data and records.

Lack of basic

access

control and

security

measures

allowing

unauthorized

changes

Some

controls,

but group

logins and

shared

accounts

widespread.

Password

polices weak

or not

enforced

Established

standards and

procedures for

security and

access control,

but not

consistently

applied

Established

system for

consistent

access

control and

security

management,

including

regular

review of

security

breaches and

incidents

Established

integrated

system for

consistent

access

control and

security

management,

supported by

appropriate

tools and

metrics for

continuous

improvement.

Archival

and

retention

Establishing processes

for ensuring

accessibility,

readability and

integrity of regulated

data in compliance with

regulatory requirements

including retention

periods.

No

consideration

of long term

archival and

retention

periods

No effective

process for

identifying

and meeting

regulatory

retention

requirements

. Few

archival

arrangements

in place.

Retention policy

and schedule

defined covering

some, but not

all regulated

records. Some

systems with no

formal archival

process.

Retention

Schedule

includes all

regulated

records, and

those

policies

supported by

appropriate

archival

processes and

tools.

Archival and

data

retention

policies and

processes

regularly

reviewed

against

regulatory

and

technical

developments



of 198



Electronic

Signatures

Effective application

of electronic

signatures to

electronic records,

where approval,

verification, or other

signing is required by

applicable regulations.

No control of

electronic

signatures.

Lack of

clear policy

on signature

application,

and lack of

consistent

technical

support for

e-

signatures.

Policies in

place. Compliant

e-signatures in

place for some,

but not all

relevant

systems.

Compliant e-

signatures in

place for all

relevant

systems,

supported by

consistent

technology

where

possible

Electronic

signature

policies and

processes

regularly

reviewed

against

current best

practice and

technical

developments

Audit

trails

Usable and secure audit

trails recording the

creation, modification,

or deletion of GxP data

and records, allowing

effective review either

as part of normal

business process or

during investigations.

Lack of

effective and

compliant

audit trails

Some limited

use of audit

trails.

Often

incomplete

or not fit

for purpose

(e.g. in

content and

reviewabilit

y). Not

typically

reviewed as

part of

normal

business

process.

Audit trail in

place for most

regulated

systems, but

with undefined

and inconsistent

use within

business

processes in

some cases.

Effective

audit trail in

place for all

regulated

systems, and

use and review

of audit trail

included in

established

business

processes.

Audit trail

policies and

use

regularly

reviewed

against

regulatory

and

technical

developments

Data Life

Cycle

Supporting

Processes



of 198



Auditing Auditing against

defined data quality

standards, including

appropriate techniques

to identify data

integrity failures

No data

quality or

integrity

audits

performed

Some audits

performed on

an ad-hoc

and reactive

basis, but

no

established

process for

data quality

and

integrity

auditing.

Data quality and

integrity

process defined,

but audits not

always effective

and the level of

follow-up

inconsistent.

Effective

data auditing

fully

integrated

into wider

audit process

and schedule.

Auditing

process and

schedule for

subject to

review and

improvement,

based on

audit

results and

trends.

Metrics Measuring the

effectiveness of data

governance and data

integrity activities

No data

related

metrics

captured.

Limited

metrics

captured, on

an ad-hoc

basis

Metrics captured

for most key

systems and

datasets. Level,

purpose, and use

inconsistent.

Metrics

captured

consistently,

according to

an

established

process.

Metrics

captured

consistently

, and fed

into a

continuous

improvement

process for

data

governance

and

integrity

Classificat

ion and

assessment

Data and system

classification and

compliance assessment

activities

No data

classificatio

n.

Limited data

classificati

on, on an ad-

hoc basis.

No formal

process

Data

classification

performed (e.g.

as a part of

system

compliance

assessment), but

limited in

detail and

scope.

Established

process for

data

classificatio

n, based on

business

process

definitions

and

regulatory

requirements.

Classificati

on process

subject to

review and

improvement,

based

outcomes and

trends.



of 198



CS

Validation

and

compliance

Established framework

for achieving and

maintaining validated

and compliant

computerized systems

Systems

supporting or

maintaining

regulated

records and

data are not

validated

No formal

process for

CS

validation,

The extent

of

validation

and evidence

dependent on

local

individuals.

Most systems

supporting or

maintaining

regulated

records and data

are validated

according to a

defined process,

but approach is

not always

consistent

between systems

and does not

fully cover data

integrity risks

Established

process in

place for

ensuring that

all systems

supporting

and

maintaining

regulated

records and

data are

validated

according to

industry good

practice, and

fully

compliant

with

regulations,

including

effective and

documented

management of

data

integrity

risks.

CS

Validation

policies and

processes

regularly

reviewed

against

regulatory

and industry

developments

Control

strategy

Proactive design and

selection of controls

aimed at avoiding

failures and incidents,

rather than depending

on procedural controls

aimed at detecting

failure

No

consideration

of potential

causes of data

integrity

failures and

relevant

controls

Some

application

of controls,

typically

procedural

approaches

aimed at

detecting

failures

Technical and

procedural

controls

applied, but

dependent on

individual

project or

system

Technical and

procedural

controls are

applied in

most cases,

based on an

established

risk-based

decision

process

Integrity

fully

designed

into

processes

before

purchase of

systems and

technology,

including

appropriate

controls



of 198



IT

Architecture

Appropriate IT

architecture to support

regulated business

processes and data

integrity

No

consideration

of IT

architecture

strategy

IT

architecture

strategy and

decisions

not

documented,

and

dependent on

local SMEs.

IT architecture

considered, and

generally

supports data

integrity and

compliance, but

is typically

defined on a

system by system

basis.

Established

IT

architecture

policy and

strategy,

with full

consideration

on how this

supports data

integrity.

IT

architecture

strategy

regularly

reviewed

against

industry and

technical

developments

.

IT

Infrastructure

Qualified and

controlled IT

infrastructure to

support regulated

computerized systems

No

infrastructur

e

qualification

performed

No

established

process for

infrastructu

re

qualificatio

n. Some

performed,

dependent on

local SMEs.

Infrastructure

generally

qualified,

according to an

established

process, but is

often a document

driven approach,

sometimes

applied

inconsistently

Established

risk-based

infrastructur

e

qualification

process,

ensuring that

current good

it practice is

applied,

supported by

tools and

technology

Infrastructu

re approach

regularly

reviewed

against

industry and

technical

developments

.



of 198

15 USER REQUIREMENTS 1

2

15.1 INTRODUCTION 3

In order to establish a computerized system to meet its intended use, the 4

system must align its user requirements to actual business process and/or 5

data workflows. The business process knowledge and regulatory assessment 6

should drive every aspect of the system validation from the initial user 7

requirements to its functional and design requirements through qualification, 8

procedural controls, system release and continued use. The basis of all 9

system validations is the development of a user requirements specification. 10

Therefore, to ensure that a system adequately addresses all of the data 11

integrity concerns necessary to meet the regulatory requirements and 12

expectations, it is important to thoroughly understand the business process 13

and its data. 14

15

One excellent way to gain the necessary understanding of a system is to 16

create business process and/or data workflows (Appendix X provides 17

methodologies for creating these workflows). Below is an example of a Change 18

Management Enterprise System business process workflow, reference Figure 1. 19

20 Figure 1: Potential User Requirements Derived from Business Process Workflow 21

22

By laying out the business process workflow, the roles, records, signature 23

requirements, system functionality, etc. necessary to support the system for 24

its intended use can be more clearly identified and agreed upon by project 25

partners. Potential failures can also be assessed and remediated prior to 26

selecting, designing or establishing the system thus saving the business 27

precious resources, time and money. 28

29

In this example the business process workflow is broken into user 30

requirements that further clarify how the system will be used. It is important 31

to consider the regulations and business rules governing the business process 32



of 198

and those requirements that should be added in to ensure compliance and 33

inspection readiness--reference Table 1 for examples that may be applicable. 34

35

Note: The following requirements are based upon a review of currently 36

available regulatory requirements and expectations for electronic records or 37

signatures and data integrity including: 38

39

Title 21 – FDA Code of Federal Regulations Part 11 Electronic Records; 40

Electronic Signatures 41

FDA Guidance for Industry Part 11, Electronic Records; Electronic 42

Signatures – Scope and Application 43

EudraLex Volume 4 Good Manufacturing Practice Medicinal Products for 44

Human and Veterinary Use, Annex 11: Computerized Systems 45

Guidance on Good Data and Record Management Practices – World Health 46

Organization Draft 47

MHRA GMP Data Integrity Definitions and Guidance to Industry 48

Data Integrity and Compliance with cGMP Guidance for Industry – FDA 49

Draft 50

OECD Principles of Good Laboratory Practice and Compliance Monitoring 51

Number 17 Advisory Document of the Working Group on GLP Application of 52

GLP Principles to Computerized Systems. 53

54

User Requirements Specifications should describe the required functions of 55

the computerized system and be based on documented risk assessment. 56

Requirements must be unambiguous and testable. Critical data, and critical 57

requirements, should be identified and documented during validation, to 58

assure that appropriate risk management is employed throughout the system’s 59

life. 60

61

15.2 TECHNICAL CONTROLS 62

Technical Controls

1 The system should employ logical controls to restrict access to

authorized persons. The extent of security controls depends on the

criticality of the computerized system.

The system must use 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.

The system must have access controls to ensure that people have

access only to functionality that is appropriate for their job role,

and that actions are attributable to a specific individual.

2 Suitable control methods for preventing unauthorized physical access

to the system should be employed e.g. computer hardware,

communications equipment, peripheral components and electronic

storage media. Controls may include the use of keys, pass cards,

personal codes with passwords, biometrics, or restricted access to

specific computer equipment (e.g. data storage areas, interfaces,

computers, server rooms, etc.). Creation, change, and cancellation

of access authorizations should be recorded.

3 The system must ensure that the accuracy, completeness, content and

meaning of data is retained throughout the data lifecycle.

Original records and true copies must preserve the integrity

(accuracy, completeness, content and meaning) of the record.

4 The system must be able to generate accurate and complete copies of

GxP electronic records in both human readable and electronic form

suitable for inspection, review, and copying by the agency.



of 198

Technical Controls

5 Access to the system must be via individual login credentials made

up of a unique combination of user-id and Password. Pass-through

technologies such as Single sign-on that leverage earlier user

authentication are acceptable.

6 The system must provide a mechanism to archive complete and accurate

records from the system and to protect them from deliberate or

inadvertent loss, damage and/or alteration for the retention period.

Security controls must be in place to ensure the data Integrity of

the record throughout the retention period, and validated where

appropriate.

7 The computer system must provide a process for regular back-ups of

all data including metadata.

Note: The URS should include details as to the frequency of back-

up, the nature of the back (full/incremental) and the length of time

the backups are retained.

Integrity and accuracy of back-up data and the ability to restore

the data should be checked during validation and monitored

periodically.

8 The system must provide a mechanism to enforce data retention

requirements, including data ownership, data holds (regulatory holds)

and destruction of data.

Stored data should be verified for restorability, accessibility,

readability and accuracy throughout the retention period.

9 Where appropriate, system operational system checks must enforce

permitted sequencing of GxP steps and events, and must disallow non-

permitted sequencing of GxP steps and events.

10 Computerized systems exchanging data electronically with other

systems should include appropriate built-in checks for the correct

and secure entry and processing of data, in order to minimize the

risks.

11 The system should perform an accuracy check on manually entered data.

12 The system must provide a secure, computer-generated, time-stamped

audit trail to independently record the date and time of entries and

actions that create, modify, or delete electronic records. Record

changes shall not obscure previously recorded information. The system

should record the identity of operators entering or confirming

critical data. Any modification to an entry of critical data should

be recorded with the reason for the change.

13 The system must provide audit trails that are available and

convertible to a human readable form.

14 The system should enable review of audit trails that capture changes

to critical data.

15 The computer system must ensure that electronic signatures, including

the human-readable display or format, captured by the system include:

(1) Printed name of the signer,

(2) Date and time when signature executed,

(3) Meaning associated with the signature.

16 The computer system must ensure that electronic signatures and

handwritten signatures executed to electronic records are 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.

17 The computer system must ensure that electronic signatures include

the time and date that they were applied and are permanently linked

to their respective record.



of 198

Technical Controls

18 The system must use at least two distinct identification components

such as an identification code and password to ensure that electronic

signatures can only be used by their genuine owners;

The system must support that the human readable form of an electronic

signature for display or print out must be unique to an individual.

19 The computer system must ensure that 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 components that is

only executable by, and designed to be used only by, the individual.

20 The computer system must ensure that when an individual executes one

or more signings not performed during a single, continuous period of

controlled access, each signing shall be executed using all of the

electronic signature components.

63

64



of 198

15.3 PROCEDURAL CONTROLS 65

Within the regulations are many procedural controls that should be 66

established for systems. 67

68

# Procedural Controls

1 All personnel should have appropriate qualifications, level of

access and defined responsibilities to carry out their assigned

duties.

2 GxP electronic records created, processed, stored or reported must

be identified. The system must be able to generate accurate and

complete copies of GxP electronic records in both human readable

and electronic form suitable for inspection, review, and copying by

the agency.

3 Procedures should be established to check stored data for

accessibility, durability and accuracy.

4 Validation documentation and reports should cover the relevant

steps of the life cycle and should include operational change

control records (if applicable) and reports on any deviations

observed during the validation process.

Manufacturers should be able to justify their standards, protocols,

acceptance criteria, procedures and records based on their risk

assessment.

5 Evidence must be available to demonstrate that persons who develop,

maintain, or use electronic record/electronic signature systems

have the education, training, and experience to perform their

assigned tasks.

6 Authorization records should be periodically reviewed based upon

the criticality of the process supported by the computerised system

and in case of relevant organizational changes in the test facility.

7 Computerized system configuration settings should be defined,

tested, and protected from unauthorized access as part of computer

system validation. They should be managed under change control.

Variable settings which relate to an analytical run would be

considered as electronic raw data.

8 System administrator access should be restricted to the minimum

number of people possible taking account of the size and nature of

the organisation. The generic system administrator account should

not be available for use. Personnel with system administrator access

should log in under unique log-ins that allow actions in the audit

trail(s) to be attributed to a specific individual.

9 Critical changes with data integrity implications (e.g. system

access changes, configuration changes, data movement, data deletion

etc.) performed under system administrator access must be visible

to, and approved within, the quality system.

10 Business areas must ensure individuals understand they are

accountable and responsible for actions initiated under their

electronic signatures.

11 The business or system management must establish loss management

procedures to electronically reauthorize 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.

12 Procedures should be established for an additional check on the

accuracy of the record when critical data are being entered

manually.

13 Procedures should be established to ensure that only authorized

people can amend entered data.



of 198

# Procedural Controls

14 Audit trail information must be retained for a period at least as

long as that required for the subject electronic records and must

be available for regulatory review and copying.

15 Based upon risk, procedures should be established to review audit

trails with each critical record and before final approval of the

record.

16 Procedures should be established to ensure that electronic

signatures have the same impact as hand-written signatures,


signatures not based upon biometrics must be administered and

executed to ensure that attempted use of an individual’s electronic

signature by anyone other than its genuine owner requires

collaboration of two or more individuals.

18 A System Access Plan should be established to ensure that the

identity of the individual is verified prior to the assignment of

their Electronic Signature, or any element of an Electronic

Signature (such as the user ID).

19 A procedure should be in place to ensure that the linkage of hand-

written signatures to electronic records is maintained throughout

the retention period.

20 Processes must be established to ensure that attempted use of an

individual's electronic signature by anyone other than its genuine

owner requires collaboration of two or more individuals.

21 Procedures should be established to perform periodic testing of

devices that bear or generate the confidential component of an

electronic signature to ensure that they function properly and have

not been altered.

22 Password aging procedures should ensure that identification code

and password issuances are periodically checked, recalled, or

revised.


signatures are unique to one individual and not reused, or

reassigned.

24 Maintaining the uniqueness of each combined identification code and

password, such that no two individuals have the same combination of

identification code and password.

25 Password expiry procedures should be established.

69

70

71

In summary, User Requirements Specifications should be directly tied to the 72

defined and agreed upon business process workflows and regulatory 73

requirements governing the data and records of the system. 74

75



of 198

76

16 DATA INTEGRITY CONCERNS RELATED TO SYSTEM ARCHITECTURE 77

78

The architecture of applications will impact the controls that are 79

appropriate to ensure data integrity. Architectures that must be considered 80

range from the C:\ drive on a PC that collects or processes GxP data to SaaS 81

applications for which the data owner may not even know where a particular 82

record resides. Some architecture choices will have direct and obvious data 83

integrity impact, others will have more subtle and indirect impact. This 84

appendix addresses different architectures and approaches to managing data 85

integrity issues that relate to each. 86

16.1 DATA RESIDES ON A LOCAL HARD DISK 87

In some ways this is the simplest architecture, yet these systems often have 88

the greatest vulnerability because of the lack of built-in controls. This 89

can be especially problematic for lab instrument control systems if they 90

have not been designed with data integrity controls in mind, and such is 91

often the case with older instruments. Where applications do not provide 92

adequate protection, operating system level controls should be implemented 93

where possible. In cases where an application does have sufficient 94

protection, there still need to be OS level controls in place to ensure that 95

the application level controls cannot be circumvented simply by accessing 96

the data directly through the OS. The following should be considered: 97

Attributability: Login should be required in order to ensure that 98

records created on the systems are attributable to the person who 99

created it. If this is not possible, a logbook may be kept, but since 100

this is often ineffective consideration should be given to upgrading 101

or replacing the system. 102

Audit trails: Elements that may make audit trails less trustworthy 103

include improper control of the system clock, uncontrolled data access 104

at the operating system level, lack of attributability, etc. 105

Segregation of duties: OS level access to the data should be limited 106

to IT. This means that lab analysts should never have administrator 107

rights on instrument controllers or data systems. 108

Back-up: It is critical to ensure that locally stored records are 109

protected. The best approach is to accumulate data to a managed network 110

drive instead of the local hard disk; second best is an automated back-111

up process where local files are automatically copied periodically to 112

a managed network drive; third best is a faithfully executed manual 113

back-up. Note that in this last approach back-up media should be 114

suitably protected and ideally should be stored in a remote location. 115

Archive: Archive may be a fairly simple process if the PC application 116

includes an archive function. However, if it does not it may be 117

difficult to manually move all of the data and associated metadata to 118

archive media. Archive media should have a level of protection similar 119

to back-up media. 120

Disaster recovery: There should be specific plans to deal with system 121

loss. It generally isn’t acceptable to simply say a new PC will be 122

obtained, as getting one with the correct configuration may not be as 123

simple as it seems. 124

16.2 INTERNALLY MANAGED CENTRAL DATABASE 125

These systems are either server-based applications or PC-based applications 126

where all data management occurs outside the PC. The key to this is that 127

such architecture should be among the easiest to properly manage to ensure 128

integrity of the data. Data integrity protections should include: 129



of 198

Attributability, based on login as above. In this architecture, 130

however, it is harder to justify a paper-based control such as a 131

logbook. 132

Segregation of duties: Administrative rights should be limited to IT 133

professionals. Certain limited administrative functions such as 134

approval of user rights may make more sense to assign to the 135

business, but in such cases there needs to be no potential conflict of 136

interest. 137

Back-up: In general this will be handled through enterprise processes 138

owned by IT. There will be a standard periodicity to take incremental 139

and full back-ups, and back-up media will be stored securely (usually 140

offsite). Media may be recycled according to a standard practice, 141

e.g. only the four most recent copies are retained, with the fifth 142

iteration being over-written onto the media used for the first. 143

However, the business process owner must make sure that such an 144

enterprise process is compatible with the actual business process. For 145

example, if an application is only used in January to compile annual 146

summaries, the process above would not work. If the data became 147

corrupted between February and August, the next time the database is 148

opened in January the corruption would be found, but the corruption 149

would have been propagated to all existing back-up copies. 150

Archive: Archives should be managed in alignment with the data 151

lifecycle. This includes the destruction of all archive copies, 152

including back-ups, when the records reach the end of their retention 153

period. 154

Note that retention of back-ups in lieu of a true archive is a very 155

poor solution. It makes record destruction problematic as it is very 156

difficult to selectively remove expired records, and restoring a back-157

up simply to access an archived records could have significant business 158

impact. 159

Disaster recovery: Like back-up, there are probably enterprise 160

processes for managing disaster recovery processes. This should 161

include testing, since there are likely to be dependencies on other 162

enterprise-owned assets. Disaster recovery planning should follow a 163

well-defined risk based process, so that systems with major patient 164

safety or business impact are appropriately scheduled in case of a 165

wide-ranging disaster. 166

16.3 INTERNALLY MANAGED DISTRIBUTED DATA 167

Distributed systems require all of the same protections as centralized 168

systems as noted above. Added complications could occur based on two 169

architecture subtypes. 170

16.3.1 Locally unique data accessible globally 171

In some cases local databases are used to achieve desired performance of the 172

system at multiple sites. This generally does not entail managing local 173

record copies at sites other than the one at which the records were generated, 174

although a small subset might have local copies that were saved in accordance 175

with local business practice. For example, manufacturing records for 176

products made offshore might be copied locally to support a regulatory 177

compliance expectation. 178

The local databases should be managed similarly to the centralized system 179

described above. The complication that arises is treatment of the data that 180

is required to be retained in other jurisdictions. This means that for 181

global systems company processes must include an accounting for the use of 182

information at other sites when making decisions related to archive 183

management and data destruction. 184



of 198

16.3.2 Data replicated globally 185

Again, the same issues described for centralized systems exist and need to 186

be appropriately addressed. In some senses the unique problem faced in this 187

scenario is the converse of the problem with local data used globally. For 188

replicated data when records are scheduled for destruction, the challenge is 189

to ensure that all copies of the record are destroyed. This needs to account 190

for all locally archived copies in addition to copies in the active database. 191

Failure to do so could expose the company to legal discovery liabilities. 192

The second complication with centrally stored records is that retention 193

policies need to recognize the potentially differing requirements based on 194

the applicable jurisdictions. For example, some blood product records must 195

be retained for ten years in the United States, whereas the same records 196

must be retained for thirty years in Europe and Japan. Therefore knowledge 197

of where the product has been distributed is key in determining the timing 198

of the steps in the data lifecycle. 199

The same considerations described above apply to any centrally managed 200

archive. 201

16.4 CLOUD-BASED SOLUTIONS 202

In general the evaluation process, the controls, and the complexity of 203

contractual and service level agreements should increase in line with the 204

amount of control the regulated company is transferring to the cloud 205

provider. From lowest to highest this is IaaS PaaS SaaS. Each of the 206

types of solution should have the controls discussed for the lower level 207

solutions in addition to those discussed at that level. 208

Many regulated companies will find themselves looking to cloud solutions for 209

GxP processes that have not been specifically developed for the GxP world. 210

This is not necessarily a bad thing. However, when evaluating such a supplier 211

the regulated company must expect not to see the same processes that would 212

be found in a supplier whose primary customer is the pharmaceutical industry. 213

Documentation may be less formal, management approval may not be required in 214

as many places, etc. The emphasis should be on evaluating the state of 215

control over the high risk processes. Rather than looking for “GxP-compliant 216

processes” they should look for “GxP-compatible processes.” The key question 217

is whether there are reasonable and appropriate controls that ensure data 218

integrity, not whether the controls look exactly like those of the regulated 219

client. 220

16.4.1 Internally managed with cloud storage (Infrastructure as a 221

Service, IaaS) 222

The requirements for these systems are again the same as for internally 223

managed centralized systems, with the difference that some of the tasks of 224

managing the data will fall to external personnel. The following should be 225

accounted for in assessing the risks related to this architecture: 226

Data management processes at the cloud provider need to be assessed to 227

make sure that the regulated company is satisfied that the provider’s 228

controls are adequate. If there are some countries where the regulated 229

company does not want data stored, this needs to be contractually 230

agreed. 231

Depending on the level of access and the type and format of the 232

information being processed or stored in the cloud the regulated 233

company may decide that the data should be encrypted. 234

Some cloud providers may have internal policies that give 235

administrative rights to dozens or even hundreds of staff, believing 236

that they need to have the internal flexibility to assign any employee 237

to work on any contract. While this is probably not necessary, a 238

regulated company is unlikely to be able to convince a cloud supplier 239

to change that model. They need to assess whether this can be 240

acceptable, possibly with additional compensating controls. If not, 241

look elsewhere for a solution. 242



of 198

Supplier change control processes need to be evaluated to ensure that 243

proper and timely notification is given for changes that might have 244

some impact on data integrity. 245

Disaster recovery processes need to be assessed to make sure that they 246

will restore data access in a time frame acceptable to the regulated 247

company. This needs to include a mutually agreeable Recovery Time 248

Objective (RTO, or how quickly service is restored), and this should 249

be included in the SLA. Recovery Point Objective (RPO, or how much 250

data can be lost since the last back-up) is probably the responsibility 251

of the customer, since they are managing the database on the supplier 252

equipment. However, if data back-up is contracted to the supplier, 253

this will affect the ability to meet the RPO. 254

Before entering into an arrangement with any cloud service there needs 255

to be an agreed and well-defined process for disengagement. This needs 256

to address timing, including both advanced notice of intent to sever 257

the relationship and the time allowed to do it; supplier and regulated 258

company responsibilities; and cost. 259

16.4.2 Internally managed application with cloud-based platform 260

Solutions involved a Platforms as a Service, (PaaS) supplier should include 261

consideration of all of the above plus: 262

Change control will have wider impact, as it will extend beyond 263

hardware and operating systems and into layered software. When 264

entering into an agreement with a PaaS supplier, it should be clarified 265

what the supplier’s policy is related to support of older software 266

versions. For example, if the provider’s policy is to support only 267

the current and one older version of a database it may drive more 268

upgrades than the regulated company desires, and such upgrades may 269

require data migrations with all the concomitant data integrity risks. 270

Disaster recovery responsibilities will move more toward the supplier. 271

In addition to RTO, the supplier will probably be charged with meeting 272

the RPO requirements as well. Hence RPO should be covered in the SLA. 273

In addition, staff at the provider may now be directly managing data, 274

e.g. as a database administrator (DBA). It should be well understood 275

and documented what the DBA can do. For example, is the DBA allowed 276

to make direct data changes, and if so what controls are in place for 277

that? DBA access to confidential data may also make encryption 278

advisable. The impact of a supplier policy of wide granting of 279

administrative rights has greater potential data integrity impact if 280

it applies to DBA access as well as to hardware support. 281

Some suppliers have multiple data centers and will distribute load in 282

order to balance the demand. This could entail placing data in one 283

country and manipulating the platform from another. If either of these 284

are unacceptable to the regulated company restrictions need to be 285

contractually negotiated. 286

16.4.3 Software as a Service (SaaS) 287

Every issue noted above applies to SaaS systems, but aside from decisions 288

related to record retention virtually all of the data management activities 289

are carried out by the supplier. This means that the contract and SLA should 290

be written to ensure mutually agreeable controls are in place. Some of these 291

controls will have direct data integrity impact, and others indirect. 292

Specific points that should be addressed include: 293

Some SaaS providers execute non-optional changes periodically. For 294



of 198

the most part, this is not likely to have a negative impact, but for 295

GxP applications there needs to be sufficient prior notification to 296

allow testing, and defined processes at the regulated company for 297

dealing with the impact of both successful and unsuccessful testing. 298

It may be that the supplier wants to use customer data to test software 299

changes. Such testing should only be allowed with the express 300

permission of the regulated company. Some precautions like de-301

identification or masking of confidential data may be advisable. 302

A provider may have internal processes for incident management that 303

delay reporting of serious issues to customers pending preliminary 304

investigation. Depending on the application, this might be 305

unacceptable to the regulated company. This needs to be outlined in 306

the SLA. 307

Similarly, a SaaS provider may be reluctant to activate disaster 308

recovery processes because of the marketing fallout of a declared 309

disaster. As a result they may allow themselves a few hours to 310

troubleshoot before declaring a disaster, and this may impact data 311

collection and processing during this early stage of a disaster. It 312

is incumbent upon the customer to examine and understand the provider’s 313

disaster recovery procedures. 314

As with PaaS, the SaaS supplier may want to move or archive data at 315

other locations, and they may not even know where at the time of 316

engagement. The SLA should address whether this can be allowed, or at 317

least timely notification of such actions. 318

When evaluating a SaaS supplier regulated company auditors are unlikely to 319

find software development practices that are aligned with traditional GxP 320

expectations. For example, many SaaS suppliers use some form of Agile 321

development process. Since Agile eschews documentation in favor of rapid 322

results, evaluation should concentrate on the state of control of the 323

software development process, focusing on compensating controls and any 324

documentation that is eventually produced. Companies would not employ Agile 325

methodologies if they could not produce reliable software when used properly. 326

As noted above, “GxP-compatible” processes should be the goal. 327

Some of the above concerns may require a degree of compromise on the part of 328

a SaaS supplier. Undoubtedly this will entail resistance from the supplier. 329

However, two factors should be clear: 330

The life sciences industry is among the most heavily regulated. Any 331

technology company desiring to enter this arena needs to be aware of 332

this. There may need to be some investment in documentation and process 333

changes, but it is a lucrative source of revenue and will pay back 334

handsomely. The customer should be happy to help the supplier develop 335

acceptable processes. While pointing this out to suppliers doesn’t 336

always work, it can help soften resistance to change. 337

A prospective customer needs to weigh the risks of engaging a SaaS supplier 338

with no experience with regulated clients. While flexibility in the form of 339

accepting “GxP-compatible” processes is important, the willingness to walk 340

away if the circumstances are not right should always remain on the table. 341

A risk management approach should always be applied to the selection process. 342

Some processes that are perfectly acceptable for the management of sales 343

force sample management might not be acceptable for the management of drug 344

safety data. 345

346



of 198

347

17 COMPUTERIZED SYSTEM LIFE CYCLE 348

349


This Appendix describes the activities required for a controlled life cycle 351

for computerized system maintaining regulated data and records. This Appendix 352

reflects the computerized system life cycle defined and described in GAMP 5 353

[Ref.] 354

Compliance with regulatory requirements and fitness for intended use may be 355

achieved by adopting a life cycle approach following good practice as defined 356

in GAMP 5. A life cycle approach entails defining and performing activities 357

in a systematic way from conception, understanding the requirements, through 358

development, release, and operational use, to system retirement. 359

17.2 COMPUTERIZED SYSTEM LIFE CYCLE 360

The life cycle for any system consists of four phases: 361

• concept 362

• project 363

• operation 364

• retirement 365

Table x Overview of Phases 366

Phase Description

Concept The regulated company considers opportunities to

automate one or more business processes based upon

business need and benefits.

Typically, initial requirements will be developed and

potential solutions considered.

From an initial understanding of scope, costs, and

benefits, a decision is made on whether to proceed to

the project phase

Project Involves planning, supplier assessment and selection,

various levels of specification, configuration (or

coding for custom applications), and verification

leading to acceptance and release for operation.

Risk Management is applied to identify risks and to

remove or reduce them to an acceptable level.

Operation Typically the longest phase and is managed by the use

of defined, up to date, operational procedures

applied by personnel who have appropriate training,

education, and experience.

Maintaining control (including security), fitness for

intended use, and compliance are key aspects.

The management of changes of different impact, scope,

and complexity is an important activity during this

phase.

Retirement The final phase involves decisions about data

retention, migration, or destruction, and the

management of these processes.

367



of 198

These life cycle phases are shown in Figure x. 368

369 A GxP assessment should be performed at the beginning of the project stage 370

to determine whether a system is GxP regulated, and if so, which specific 371

regulations apply, and to which parts of the system they are applicable. 372

This should be performed as part of the initial system risk assessment. 373

17.3 SPECIFICATION AND VERIFICATION 374

Figure x shows a general approach for achieving computerized system 375

compliance and fitness for intended use within the system life cycle. This 376

general specification, design, and verification process is aligned with ASTM 377

E2500 [Ref xx]. 378

As shown, the specification activities have equivalent verification steps to 379

determine whether the specification has been met. Several levels of 380

specifications may be required for larger systems, while specifications may 381

be combined for smaller, simpler, systems. Specifications should be addressed 382

by appropriate verification steps. 383

Figure x: A General Approach for Achieving Compliance and Fitness for 384



of 198

Intended Use 385

386 The application of this general approach will vary widely depending on the 387

risk, complexity, and novelty of the system. 388

17.4 LIFE CYCLE PHASES 389

17.4.1 Concept Phase 390

Activities in the Concept phase will depend on company approaches to 391

initiating and justifying project commencement. Gaining management 392

commitment to provide appropriate resources to achieve compliance and fitness 393

for intended use is an important pre-project activity. 394

During the Concept phase, the regulated company considers opportunities to 395

automate one or more business processes based upon business need and 396

benefits. Typically, at this phase, initial requirements will be developed 397

and potential solutions considered. From an initial understanding of scope, 398

costs, and benefits, a decision is made on whether to proceed to the project 399

phase. 400

17.4.2 Project Phase 401

The Project phase involves planning, supplier assessment and selection, 402

various levels of specification, configuration (or coding for custom 403

applications), and verification leading to acceptance and release for 404

operation. Risk Management is applied to identify risks (including risks to 405

data integrity) and to remove or reduce them to an acceptable level. 406

The Project phase consists of the following stages: 407

planning 408

specification, configuration, and coding 409

verification 410

reporting and release 411

A validation plan, or equivalent, should describe the life cycle and 412

validation approach. Activities should be scaled according to: 413

system impact on patient safety, product quality, and data integrity 414

(risk assessment) 415

system complexity and novelty (architecture and categorization of 416

system components) 417

outcome of supplier assessment (supplier capability) 418



of 198

The role of specification documents is to enable systems to be developed, 419

verified, and maintained. The number and level of detail of the 420

specifications will vary depending upon the type of system and its intended 421

use. For example, software design specifications are not expected from the 422

regulated company for non-configured products. 423

Specifications may be available from the supplier. Before use, the regulated 424

company should ensure that they are complete, accurate, and adequate to 425

support subsequent life cycle activities 426

Any required configuration should be performed in accordance with a 427

controlled and repeatable process, and a defined specification. Any required 428

software coding should be performed in accordance with defined standards. 429

The need for code reviews should be addressed as part of risk management. 430

Software should be subject to Configuration Management and documented version 431

control. Any software development tools used should be assessed for 432

suitability and fitness for purpose. 433

Verification confirms that specifications have been met. This may involve 434

multiple stages of reviews and testing depending on the type of system, the 435

development method applied, and its use. 436

Testing computerized systems is a fundamental verification activity. Testing 437

is concerned with identifying defects so that they can be corrected, as well 438

as demonstrating that the system meets requirements. 439

Testing often is performed at several levels depending on the risk, 440

complexity, and novelty. One level of testing may be appropriate for simple 441

and low risk systems. 442

An appropriate test strategy should be defined, reviewed, and approved by 443

appropriate Subject Matter Experts (SMEs). 444

During reporting and release the system should be accepted for use in the 445

operating environment and released into that environment in accordance with 446

a controlled and documented process. Acceptance and release of the system 447

for use in GxP regulated activities should require the approval of the process 448

owner, system owner, and quality unit representatives. A computerized system 449

validation report should be produced summarizing the activities performed, 450

any deviations from the plan, any outstanding and corrective actions, and 451

providing a statement of fitness for intended use of the system. 452

17.4.3 Supporting Processes 453

An appropriate Quality Risk Management process should be established. 454

Appropriate configuration management processes should be established such 455

that a computerized system and all its constituent components can be 456

identified and defined at any point. 457

Change management procedures also should be established for both project and 458

operational phases. The point at which operational (GxP) change management 459

commences should be clearly defined. 460

At suitable stages during the life cycle, planned and systematic design 461

reviews of specifications, design, and development should be performed. This 462

design review process should evaluate deliverables to ensure that they 463

satisfy the specified requirements. Corrective actions should be defined and 464

progressed. 465

The rigor of the design review process and the extent of documentation should 466

be based on risk, complexity, and novelty. 467

Traceability is a process for ensuring that: 468

requirements are addressed and traceable to the appropriate functional 469

and design elements in the specifications 470

requirements can be traced to the appropriate verification 471

As well as demonstrating coverage of design and verification, traceability 472

can greatly assist the assessment and management of change. Traceability 473

should be focused on aspects critical to patient safety, product quality, 474

and data integrity. 475

Normal GxP document management practices should be applied, including 476

activities of preparation, review, approval, issue, change, withdrawal, and 477



of 198

storage. 478

17.4.4 Operation Phase 479

Once the system has been accepted and released for use, there is a need to 480

maintain compliance and fitness for intended use throughout its operational 481

life. This is achieved by documented procedures and training that cover use, 482

maintenance, and management of the system. 483

The operational phase of a system may last many years, and may include changes 484

to software, hardware, the business process, and regulatory requirements. 485

The integrity of the system and its data should be maintained at all times 486

and verified as part of periodic review. 487

As experience is gained during operation, opportunities for process and 488

system improvements should be sought based on periodic review and evaluation, 489

operational and performance data, and root-cause analysis of failures. 490

Information from the Incident Management and CAPA (corrective and preventive 491

action) processes can provide significant input. 492

Table x gives an overview of Operational processes. 493

Operational Process Description

1. Handover Handover is the process for transfer of

responsibility of a computerized system from

a project team or a service group to a new

service group.

2. Establishing and

Managing Support

Services

The support required for each system, and

how it will be provided, should be

established. Support may be provided by

external or internal resources. This process

should ensure that support agreements

Service Level Agreements (SLAs), maintenance

plans, training, and SOPs are established.

3. Performance Monitoring

Where appropriate, performance of the system

should be monitored to capture problems in a

timely manner. It also may be possible to

anticipate failure through the use of

monitoring tools and techniques.

4. Incident and Problem

Management

Incidents, such as system failures and data

errors, should be reported and assessed. The

primary objective of Incident Management is

to ensure that any unplanned issues that

could impact patient safety, product

quality, and data integrity are addressed

before any harm occurs.

The root cause of critical incidents should

be identified and should form the basis of

corrective and preventive actions.

5. Change Management,

Configuration

Management, and Repair

Any changes to a computerized system,

including configuration of the system,

should only be made in a controlled manner

in accordance with a defined procedure.

Change and configuration management

processes should be applied to the full

system scope including hardware and software

components and to associated documentation.

All changes that are proposed during the

operational phase of a computerized system,

whether related to software (including

middleware), hardware, infrastructure, or

use of the system, should be subject to a

formal change control process.



of 198


The process should ensure that proposed

changes are appropriately reviewed to assess

impact and risk of implementing the change.

The process should ensure that changes are

suitably evaluated, impact and risk

assessed, authorized, documented, tested,

and approved before implementation, and

subsequently closed. These activities should

be documented. Relevant documentation should

be updated as part of a change.

The repair or replacement of defective

computerized system components, typically

hardware or infrastructure related, should

be managed in accordance with a defined

process.

6. Periodic Review Computerized systems should be periodically

evaluated to confirm that they remain in a

valid state and are compliant with GMP. Such

evaluations should include, where

appropriate, the current range of

functionality, deviation records, incidents,

problems, upgrade history, performance,

reliability, security and validation status

reports.

Periodic reviews are used throughout the

operational life of systems to verify that

they remain compliant with regulatory

requirements, fit for intended use, and meet

company policies and procedures. The reviews

should confirm that, for components of a

system, the required support and maintenance

processes and expected regulatory controls

(plans, procedures, and records) are

established.

A process for timing and scheduling of

reviews should be defined. The review

periods for specific systems should be based

on system impact, complexity, and novelty.

These decisions should be documented.

Problems found during the review should be

documented, along with recommended

corrective actions. Consideration should

also be given to possible wider

implications. Agreed corrective actions

should be resolved and approved.

7. Backup and Restore Data should be secured by both physical and

electronic means against damage. Stored data

should be checked for accessibility,

readability and accuracy. Access to data

should be ensured throughout the retention

period.

Regular backups of all relevant data should

be performed. Integrity and accuracy of

backup data and the ability to restore the

data should be checked during validation and

monitored periodically.

Procedures should be established to cover



of 198


routine backup of records, data, and

software to a safe storage location,

adequately separated from the primary

storage location, and at a frequency based

on risk. There should be written procedures

for recovery following a breakdown.

Backup processes should be verified when

they are established. There should be

procedures and plans for regular testing of

backup and restore capability. Such

activities and subsequent action taken

should be documented.

8. Business Continuity

Management

For the availability of computerized systems

supporting critical processes, provisions

should be made to ensure continuity of

support for those processes in the event of

a system breakdown (e.g. a manual or

alternative system). The time required to

bring the alternative arrangements into use

should be based on risk and appropriate for

a particular system and the business process

it supports. These arrangements should be

adequately documented and tested.

The regulated company should perform

business continuity planning to actively

protect its ability to continue to supply

the public, and to comply with the regulatory

requirements.

The time required to bring the alternative

arrangements into use should be based on risk

and appropriate for a particular system and

the business process it supports. Critical

business processes and systems supporting

these processes should be identified and the

risks to each assessed.

9. Disaster Recovery As a subset of business continuity planning,

plans should be specified, approved, and

rehearsed for the recovery of specific

systems in the event of a disaster.

These plans should detail the precautions

taken to minimize the effects of a disaster,

allowing the organization to either maintain

or quickly resume critical functions. There

should be a focus on disaster prevention,

e.g., the provision of redundancy for

critical systems.

A Disaster Recovery Plan should be in place

for each critical system, and should

encompass not only a process for restoring

the system, but also any infrastructure

required for the system to operate.

10. Security and User

Management

Physical and/or logical controls should be

in place to restrict access to computerized

system to authorised persons. Suitable

methods of preventing unauthorised entry to

the system may include the use of keys, pass



of 198


cards, personal codes with passwords,

biometrics, restricted access to computer

equipment and data storage areas. The extent

of security controls depends on the

criticality of the computerized system.

Creation, change, and cancellation of access

authorisations should be recorded.

Measures should be implemented to ensure

that GxP regulated computerized systems and

data are adequately and securely protected

against wilful or accidental loss, damage,

or unauthorized change.

Such measures should include:

Establishing and maintaining security

roles and responsibilities, policies,

standards, and procedures

Performing security monitoring and

periodic testing, e.g., manual check of

system access log, automated notification

of lockouts, testing of tokens

Implementing corrective actions for

identified security weaknesses or

incidents.

Ensuring a list of those authorized to

access the system is established and

maintained.

11. System Administration System Administration processes provides

administrative support for systems,

including performance of standard

administration tasks. The extent of this

process varies greatly depending on the

nature of the system. System administration

processes should be established and

appropriate resource made available before a

computerized system becomes operational.

System administration tasks should be

identified, documented and be supported by

controlling procedures. System

Administrators should be trained to perform

these tasks and evidence of their competency

retained. System administration duties

should be segregated from operational

processing duties.

12. Archive, Retention,

and Retrieval

Archived data should be checked for

accessibility, readability and integrity. If

relevant changes are to be made to the system

(e.g. computer equipment or programs), then

the ability to retrieve the data should be

ensured and tested.

Procedures for archiving and retrieval of

records should be established based on a

clear understanding of regulatory

requirements. Roles, responsibilities and

procedures for archiving and retrieval



of 198


should be defined.

GxP records and data should be secured by

physical or electronic means against wilful

or accidental damage, throughout the

required retention period. Archiving

processes should ensure that record content

and meaning are preserved. Stored records

and data should be initially and then

periodically checked for accessibility,

durability, accuracy and completeness.

Procedures should address media selection,

exercise, and/or refresh requirements.

494

17.4.5 Retirement Phase 495

A process must be established for controlled and documented retirement of 496

systems. 497

The retirement of a system should be achieved either by following a System 498

Retirement procedure or by developing a retirement plan specific to the 499

system. 500

The retirement plan or procedure should describe how any data maintained by 501

the system will be dealt with in a manner that meets regulatory and business 502

requirements, and how integrity of GxP records and data is preserved. 503

504

18 CORPORATE DATA INTEGRITY PROGRAM 505

506


Data integrity is a global regulatory and compliance expectation, as seen by 508

the increased data integrity rigor by the global regulatory agencies and 509

guidance by the MHRA, the WHO, and the FDA. And global regulatory agencies 510

are becoming more aligned around these expectations. What can data integrity 511

problems mean for your firm? It can mean recalls of products, warning or 512

untitled letters, import alerts, injunctions, seizures, Application 513

Integrity Policy Invocations/ legal action, and most concerning, patient 514

harm. It is as much a compliance issue as it is a financial issue, as seen 515

by the impact of these regulatory actions on companies bottom lines. For 516

these reasons, pharmaceutical companies are being driven to implement 517

corporate data integrity programs. 518

The basis for this appendix is a compilation of materials, discussions, and 519

presentations by the ISPE GAMP Data Integrity Special Interest Group (SIG), 520

and heavily leverages an ISPE GAMP Community of Practice Concept Paper 521

created by one of the SIG sub teams and authored by John Avellanet (Cerulean 522

Associates LLC) and Eve Hitchings (Eli Lilly and Company) entitled 523

“Considerations for a Corporate Data Integrity Program”, March 2016. The 524

intent of this concept paper is to share implementation considerations based 525

on the experiences of several companies, including successes and challenges. 526

Although the specifics of each individual company’s data integrity program 527

will be different, the considerations described should give companies a 528

direction for creating a successful corporate data integrity program. 529

18.2 IS A DATA INTEGRITY PROGRAM REQUIRED? 530

This question is one that is asked often as companies determine how to address 531

data integrity within their organizations. The MHRA GMP Data Integrity 532

Definition and Guidance for Industry (March 2015) provides some interesting 533

perspectives related to this question. It states that “Data Integrity is 534

fundamental in a pharmaceutical quality system which ensures that medicines 535

are of the required quality.” It goes on to say that “The data governance 536

system should be integral to the pharmaceutical quality system …..” So there 537

is clearly an expectation that companies address data integrity and data 538



of 198

governance in their pharma quality system because it is fundamental to 539

ensuring product quality. So does this mean that companies must implement 540

elaborate and highly resourced programs to address data integrity? The MHRA 541

guidance further states that “The effort and resources assigned to data 542

governance should be commensurate with the risk to product quality and should 543

be balanced with other quality assurance resource demands.” So the effort 544

and resources should be aligned with the risk and with other quality demands. 545

It also states that “As such, manufacturers and analytical laboratories are 546

not expected to implement a forensic approach to data checking on a routine 547

basis, but instead design and operate a system which provides an acceptable 548

state of control based on data integrity risk, and which is fully documented 549

with supporting rationale.” The emphasis is on designing and implementing 550

a system to provide an acceptable state of control based on data integrity 551

risk. The MHRA guidance also says that “consideration should be given to 552

the organizational (e.g. procedures) and technical (e.g. computer system 553

access) controls applied to different areas of the quality system” and the 554

“effort and resources…. be commensurate with its criticality in terms of 555

impact to product quality attributes.” 556

18.3 INDICATORS OF PROGRAM SCOPE AND EFFORT 557

In order to design and implement an appropriate corporate data integrity 558

program, you must first understand your current state and acceptability of 559

control based on data integrity risk. Since data integrity and data 560

governance should be an integral part of your quality system, focusing on 561

the organizational/ procedural controls is an appropriate place to start. 562

It is critical to know if the data integrity requirements are adequately 563

addressed within your Quality Management System (QMS). Performing a review 564

of your QMS vs. data integrity requirements will identify any data integrity 565

procedural controls that might be lacking. Do adequate processes exist 566

within the QMS to prevent, detect, report, and address data integrity 567

failures? Are the ALCOA + requirements clearly addressed within the QMS? 568

Are there adequately defined processes for properly generating and reviewing 569

data? And are there proper controls for the entire lifecycle of data? If 570

you have a good and well-defined corporate QMS aligned with current GxP’s, 571

the majority of these items should be addressed and traceable to the 572

appropriate regulation applicable to your business processes. However, 573

organizational related gaps are more likely to be identified as sites and 574

local business areas define and execute their local procedures, so more 575

detailed gap assessment may be required to truly understand the state of 576

data integrity controls in place at this local level. This leads quickly 577

to the another control you need to assess and understand – Is there an 578

appropriate Corporate and Quality Culture. Is there appropriate knowledge 579

and accountability of data integrity requirements and expectations at the 580

shop floor level since these are the people who typically generate and manage 581

the data used to support product quality? Management accountability, at all 582

levels of the corporation from the CEO to the operations floor supervision, 583

plays a very key role in ensuring data integrity. It is critical that they 584

“walk the talk” and foster an environment that promotes and ensures good 585

data integrity practices. The importance of management accountability will 586

be discussed in more detail later in this article. 587

Just like the organizational controls, you must also assess the technical 588

controls, which include your equipment and computer systems. Are these 589

systems properly qualified and/ or validated to ensure data integrity? All 590

too often, systems are not capable of, designed to, or configured to ensure 591

data integrity. System access and security must be properly defined and 592

audit trails must be properly utilized to review, detect, report, and address 593

data integrity issues. And appropriate data lifecycle management processes 594

must be in in place to ensure the integrity of the data throughout its 595

required retention period. The technical controls do not stop there. It is 596

just as important to ensure proper segregation of duties to eliminate role 597

conflicts that can raise concerns about data integrity. These include proper 598

administrator access, control and/ or elimination of shared accounts, and 599



of 198

properly defined user roles with privileges assigned based on the user’s 600

roles and responsibilities. 601

Organizational and technical controls are only as good as they are 602

implemented. Therefore understanding how these data integrity and QMS 603

procedures and controls are executed and applied in your business processes 604

it is another key indicator of your acceptable state of control based on 605

data integrity risk. A key requirement of your QMS is to have an auditing 606

or self-assessment process to monitor your adherence and compliance with 607

your QMS and the regulatory requirements of your business. A quick measure 608

of your data integrity compliance is a review of the self-assessment, 609

internal audits, and third party audits reports and observations associated 610

with these activities. What types of data integrity issues exist? Are there 611

repeat findings related to data integrity issues? Are there systemic issues 612

and is it a corporate or quality culture issue? Of course it is only possible 613

to review this data if these self-assessment and audit processes are designed 614

and capable of identifying data integrity risks and gaps. If these processes 615

do not utilize forensic audit techniques and emphasize identification of 616

data integrity compliance gaps that in itself is a concern. Having good 617

self-assessment and audit processes which include an emphasis on data 618

integrity will be critical to the long term monitoring and overall success 619

and effectiveness of your program and ensure you are identifying and 620

addressing data integrity issues before regulatory inspections identify them. 621

If you have been fortunate enough to be inspected by a regulatory agency who 622

has implemented forensic data integrity inspection techniques, this is 623

another measurement of your acceptable state of control of data integrity 624

risks. (If not, a review of regulatory observations from other companies 625

can provide insights into current trends and concerns.) Data integrity 626

related observations issued for a given site are potential indicators of 627

systemic issues that might exist at other sites within your company. It is 628

essential that you determine if similar issues exist at other sites within 629

your company and develop action plans to close those gaps globally. There 630

is no faster way to lose the trust of a regulatory agency than to have the 631

same issues identified at multiple sites within your company. This clearly 632

demonstrates a systemic issue and a potential corporate and quality culture 633

issue. 634

A very common question that is usually asked is how much effort is required 635

for implementing a Corporate Data Integrity Program? Keep in mind that the 636

MHRA GMP Data Integrity Definition and Guidance for Industry (March 2015) 637

states that “The degree of effort and resources applied to the organizational 638

and technical control of data lifecycle elements should be commensurate with 639

its criticality in terms of impact to product quality attributes.” So it 640

really depends on several factors. The first factor is what were the outcomes 641

of your gap assessments and audits of your organizational controls (i.e. 642

your QMS and procedures)? If there are significant gaps that exist, then a 643

greater effort will be required to update the QMS with the appropriate 644

controls to address those integrity risks. These updates will also likely 645

result in the creation of site and/ or local procedures to functionally 646

implement these controls and processes. The second factor is what were the 647

outcomes of your gap assessment and audits of your technical controls 648

associated with your equipment and computer systems? It could result in 649

updates, reconfiguration, or even replacement of a number of systems, all of 650

which must be qualified and/ or validated. Depending on the extent of the 651

changes to these systems, the amount of effort and resources will vary by 652

projects and/ or system. The third factor that must be considered is the 653

gaps associated with business processes and execution of those processes. 654

These are typically found by executing a detailed business process review 655

and gap assessment with those people responsible for executing those 656

processes. Business process changes are not always easy, especially when 657

processes and approaches have been in place for a significant period of time. 658

These types of changes not only require procedural changes, but also quality 659

and business culture changes to implement them. Training will need to be 660



of 198

developed and implemented to support changes to these processes. Management 661

accountability and support is extremely critical and will have a direct 662

impact on the success of making these changes, especially when it spans 663

multiple organizations and potentially sites. The outcomes of these 664

activities will serve as the basis for developing your initial data integrity 665

strategy and defining your corporate program. 666

18.4 IMPLEMENTATION CONSIDERATIONS 667

The key to success of any data integrity program is having a well-defined 668

strategy. The assessment activities outlined above will serve as a good 669

basis for defining and establishing your strategy. This high level plan 670

will define the approach, timeline, resource requirements, and rationale for 671

executing your data integrity program. This strategy can serve as a mechanism 672

to track progress for senior management and provide a documented rational 673

and plan to outline your program and actions during audits and inspections. 674

At a minimum, it shows your commitment to identifying and addressing data 675

integrity issue within your company and establishes a corporate governance 676

process for overseeing these activities. It also provides a mechanism to 677

ensure multi-site alignment of activities and a holistic approach to 678

compliance with data integrity compliance. 679

Corporate governance is another critical success factor. First, identifying 680

and establishing executive sponsorship is crucial to getting the support for 681

your data integrity program. The sponsor, who is critical to the overall 682

success, will be required to set the direction, define the priorities, 683

provide the resources, and break down organizational barriers. They will 684

also help executives within a company be aware of the four key benefits that 685

a data integrity program can deliver including the financial benefits, risk 686

reduction, the regulatory benefits, and the legal product liability impact. 687

Second, management accountability is an absolute must to a successful 688

corporate data integrity program. Management at all levels of the company 689

must “walk the talk”. By doing so, they demonstrate the core values of 690

integrity in response to a failure. They do not incentivize data 691

falsification and discourage the “wanting to please management” mentality 692

that can lead to many data integrity issues. And of most importance, they 693

eliminate the fear of management retribution and foster an environment where 694

employees are encouraged to identify and report data integrity issues on the 695

shop floor. Management is also accountable for providing the appropriate 696

resources to ensure data integrity, including people, capable instruments 697

and systems, and sound and understandable business processes. It is also 698

imperative that they accept the fact that some level of data integrity issues 699

always have and will occur. It is human nature to make mistakes – we are 700

not perfect. This concept is not easy to accept, but is reality. Human 701

factors contribute greatly to data integrity issues, whether intentional or 702

inadvertent. Management is also accountable to drive a strategy that focuses 703

on prevention, detection, and response. Data integrity must be owned by the 704

business. It does require cross-functional oversight and participation, 705

including IT, Quality, records management, etc. But to be truly successful, 706

it requires business process knowledge and ensuring those processes support 707

data integrity requirements. 708

The remaining corporate governance implementation considerations are 709

knowledge sharing and training, which are closely related. As you roll out 710

your data integrity program, there are a number of common questions and 711

topics that you will want to address and share to help build a good data 712

integrity foundation across your organization. These questions include, but 713

are not limited to: 714

What does data integrity mean and how does it apply to my day-to-day 715

business activities? 716

What role does equipment qualification and computerized system 717

validation play in data integrity? 718

How does data integrity relate to 21 CFR Part 11 and EU GMP Annex 11? 719



of 198

What are our roles and responsibilities vs. those of the regulatory 720

agencies? 721

When does data integrity start and when does it end? 722

Making information readily available to all levels of the organization is 723

beneficial. Establishing a data integrity knowledge repository or 724

knowledgebase is a great way to provide historical and current information. 725

Leveraging Subject Matter Experts (SME’s) and outside experts early in the 726

process is crucial, especially early in the process to establish an 727

appropriate foundation of knowledge of data integrity. Data integrity needs 728

to be inherent within our processes. Having that basic understanding will 729

provide a good basis for implementing more focused training. Data handlers 730

should be formally trained to understand their role in maintaining data 731

integrity. They are accountable for understanding their business processes 732

and the information and the data they generate. They are the data integrity 733

stewards. They are also responsible for identifying and escalating concerns 734

regardless of the impact on delivery, quotas, or timelines. Quality and 735

compliance roles should have advanced training and an understanding of data 736

integrity requirements to ensure requirements are implemented within systems 737

and processes, as well as support the business processes and business owners. 738

Behavioral factors are another area of consideration when implementing a 739

corporate data integrity program. Behaviors can promote and encourage the 740

proper actions, or damage and discourage data integrity within a company. 741

One example is the damaging behavior of cost saving measures, which may 742

encourage the sharing of passwords due to limited user license purchases. 743

Another is poorly conducted investigations that often blame human error or 744

end in no assignable cause. A change to a Standard Operating Procedure (SOP) 745

may also be proposed as a preventative action, but all too often they can be 746

ignored and not truly address the real issue. Poorly chosen metrics can 747

also undermine data integrity. Three factors that support fraudulent 748

practice are pressure, opportunity, and rationalization. Metrics that 749

encourage any one of these factors can encourage data integrity issues. For 750

example, emphasis on speed vs. accuracy and quality can force employees to 751

cut corners and focus on the wrong things. Other behavioral factors include 752

improvisation, impartiality, and falsification for profit. Chapter 5: 753

Governance and Human Factors - provides more details on this topic. All of 754

these factors must be considered when implementing your data integrity 755

program. 756

18.5 KEYS TO SUCCESS 757

There is no “one size fits all” approach when it comes to implementing a 758

corporate data integrity program. But there are some elements that can 759

increase the likelihood to be successful. Business processes, systems, 760

equipment, personnel, etc. will continue to evolve and change, so you need 761

to plan for continuous improvement. Defining and establishing appropriate 762

data integrity program metrics is necessary for two reasons. First, it 763

ensures a positive return on investment. Whenever senior management invests 764

time, money, and resources into a program, they expect there to be a return 765

on that investment, otherwise why invest in the first place. Metrics also 766

measure the success of the program and demonstrate progress against the 767

goals. At early stages of the program, reporting of DI issues will increase 768

with increased awareness and improved detection, which may skew the metrics. 769

It is important to manage this “bad news” and continue to foster an 770

environment of open reporting. A program reporting process will also bolster 771

success. Your plan and/ or strategy should define the reporting expectations 772

to senior management, area business leadership, the program team, as well as 773

to those on the shop floor. It is an opportunity to share metrics and 774

progress to date, as well show progress against the plan. It also identifies 775

and communicates issues and provides a mechanism to agree on next steps. 776

Audit processes also are critical to the success of the program. Multiple 777

types of audits will need to occur including, but not limited to: 778



of 198

Initial gap assessment or audit of non-conformance 779

Periodic audit of long-term data archives 780

Supplier qualification audits 781

Closeout gap assessment or full audit following program completion 782

Ongoing internal quality audits of established data integrity controls 783

to ensure continuing effectiveness and compliance 784

These audits will provide critical information to set a baseline and measure 785

the success of your implementation, as well as highlight possible gaps and 786

possible correction and additions to your project scope. For the initial 787

and closeout assessments, consider using an independent auditor. (This does 788

not necessarily mean an outside expert, but rather use someone independent 789

of the internal core team.) 790

A final key to success of implementing a data integrity program is to define 791

and implement robust review processes, including result review and periodic 792

review processes. This topic was discussed in detail in Section 4.3: Data 793

Review and Appendix A.1: Audit Trail and Audit Trail Review. As stated 794

before, result review of individual results or sets of results prior to 795

release should include the comparison of results against specification/ 796

limits/ acceptance criteria. It also includes the evaluation of completeness 797

and correctness of metadata. The review provides a means to make a judgment 798

about the accuracy and integrity of any manually entered values, as well as 799

review any information associated with any decisions or actions taken. 800

Reviewers must assess and understand the impact that any manual adjustments 801

or alterations of the data or metadata might have on the results or product 802

decision, as well as be aware of any changes to method versions used in 803

creation of the result. The reviewer must also make an assessment of the 804

conformity to sound scientific practice and documented procedures. Increased 805

result review rigor should be applied for manual adjustments and/ or results 806

that barely meet the specifications. An additional element of result review 807

that must not be overlooked is audit trail review. The MHRA Data Integrity 808

Definitions and Guidance (March 2015) states that “Audit trail review should 809

be part of the routine data review/ approval process, usually performed by 810

the operational area which has generated the data (e.g. laboratory).” The 811

audit trail provides the most effective means of assessing data integrity. 812

Unfortunately in some cases, the audit trail is not easily accessible and/ 813

or permanently associated with the result, making this review difficult to 814

complete and detection of data integrity issues very difficult. So 815

appropriate and accessible audit trails are a technical means of preventing 816

and detecting data integrity issues. Review of the audit trail and metadata 817

associated with the volume of results generated in today’s business processes 818

presents some logical and resource challenges. Technology controls 819

implemented within many systems have provided a means to review by exception. 820

This approach applies a risk-based approach to data review based on alerts 821

to highlight a subset of results requiring additional review, such as 822

results/ data that are within but close to the specification limit, have 823

been manually manipulated (i.e. integration), or have been reprocessed. They 824

highlight situations where critical data has been manually entered or 825

changed. A detailed review is then performed on a subset of the results/ 826

data. Keep in mind that it is your responsibility to determine and document 827

what the minimal level of result review is and be able to provide a documented 828

rational for doing so during an audit or regulatory inspection. These types 829

of systems also require validation to verify and document the alert 830

functionality. 831

Computer systems require periodic reviews to ensure they continue to operate 832

in a matter consistent with their intended use and remain in a validated 833

state consistent with that use. GAMP® 5 is a great resource to better 834

understand the concepts of periodic review. From a data integrity 835

perspective, system periodic review should include the evaluation of any 836

changes to system configuration that could impact data integrity. It should 837



of 198

also focus on any deletions of data, including what was deleted, why, and by 838

whom. It should also focus on system administration activities and user 839

accounts, especially account disabling due to unsuccessful login attempt. 840

Other periodic review activities that should be addressed include review of 841

SOP’s to ensure appropriate data integrity controls are addressed, system 842

validation records are current and reflect the intended use of the system, 843

required SOP records are maintained, change control process is functioning 844

properly, and system performance does not negatively impact the intended use 845

of the system. For more detailed information, refer to Part 3 of the “Human 846

Impact on Data Integrity” article series. 847

18.6 SUMMARY 848

Data integrity is fundamental element of a pharmaceutical quality system and 849

has a direct impact on product quality. Increased focus on data integrity 850

by regulatory agencies around the world continues to increase and raise 851

awareness of the need to address this critical compliance requirement. 852

Companies must ensure they are appropriately addressing data integrity and 853

data governance. Organizational/ procedural and technical controls must also 854

be considered as part of an overarching data governance system and the effort 855

and resources should be commensurate with its criticality in terms of impact 856

to product quality attributes. Key implementation considerations for a 857

corporate data integrity program include development of a high level strategy 858

which includes a documented rational, identifying and gaining executive 859

sponsorship, focusing on management accountability, implementing tools for 860

knowledge sharing, and developing and providing the appropriate levels of 861

training. It is imperative that your data integrity program addresses 862

behavioral factors and drives a strategy that focuses on prevention, 863

detection, and response. As the program progresses, business processes, 864

systems, etc. will continue to evolve. So the program must include a plan 865

for continuous improvement, which includes appropriate metrics to measure 866

performance, program reporting to communicate progress, and appropriate audit 867

and assessment processes to identify issues and measure progress and on-868

going compliance. 869

870

References 871

7. The MHRA GMP Data Integrity Definition and Guidance for Industry (March 872

2015) 873

8. John Avellanet (Cerulean Associates LLC) and Eve Hitchings (Eli Lilly 874

and Company), “Considerations for a Corporate Data Integrity Program” 875

– An ISPE GAMP Community of Practice Concept Paper, March 2016 876

877



of 198

878

19 PAPER & HYBRID RECORDS 879

880

Paper and electronic record and signature components can co-exist (i.e., a 881

hybrid situation) and are allowed provided they are complete and accurate. 882

The data retention process requires a risk assessment to ensure that suitable 883

controls are in place and that all required data is retained. 884

Hybrid records are common in older systems, as older technology may not allow 885

the use of electronic signatures with electronic records, or important 886

metadata such as user identity or date/time is not collected by the software. 887

Examples are :- 888

The release of a manufacturing batch that has been compiled using 889

electronically created records with no facility for electronic 890

signature. 891

Records that are generated electronically, printed out and a 892

handwritten signature applied 893

A signed paper record scanned into an electronic system and stored as 894

*.PDF format 895

19.1 CONTROLS 896

Suitable controls should be established and verified. These may include 897

standard operating procedures that define the process of controlling the 898

signed paper record, and for making modifications to the paper and electronic 899

records if required. The procedure should provide a process that prevents 900

incorrect or out of date versions of records from being used. 901

19.2 MANAGING RECORDS & SIGNATURES IN HYBRID SYSTEMS 902

Older production and laboratory systems which do not have adequate controls 903

require hybrid record management using a combination of electronic records 904

and paper records. Examples of hybrid records and signatures are as follows :- 905

Records: The machine (for example a formulation production machine or 906

lab equipment) collects data as part of the operation of its computer 907

control system. The collected data is printed out and the printed 908

output is attached to the paper batch record. 909

Signatures: a signature is used to review, verify, approve, reject, 910

authorize, confirm, check. For processing operations an operator may 911

check and confirm an action, a supervisor may verify an action and for 912

critical steps this may be a second person verification. QA may approve 913

the batch after reviewing the batch record. These signatures may be 914

applied to the paper batch record which includes printouts of data 915

collected electronically. 916

Record retention : paper records & signature may be :- 917

o retained on a paper system 918

o retained by scan or transferred into a separate electronic 919

system for long term storage 920

19.3 RISK ASSESSMENT 921

Regulated companies should use risk assessment to decide the approach to 922

data retention and data format for the required period. Companies may retain 923

records in formats other than the original electronic record if content and 924

meaning are preserved, and regulatory requirements are met. For batch records 925

the ability to retain records in process-able form throughout the retention 926

period is not normally required. For lab records there is a requirement to 927

retain the record in a process-able form (note this is a reference to the 928

MHRA guide) for part or all of the retention period depending on the record 929

and based on risk. 930



of 198

Factors to consider in the risk assessment include: 931

Definition of the data to record and retain based on regulations and 932

company policies 933

Data integrity requirements including retention time, legibility, time 934

and date stamps, user ID, associated meta data (particularly important 935

for lab data), change control and audit trail. 936

The need to keep meta-data associated with the data post conversion 937

The risk assumed with moving the records to a non-process-able format 938

or media 939

Future use of the record 940

Time of retention versus likely demand for reprocessing. 941

Availability of the record for inspection by regulators 942

Current regulatory requirements 943

NOTE: According to the MHRA guide data may be static (e.g. a ‘fixed’ record 944

such as paper or pdf) or dynamic (e.g. an electronic record which the user 945

/ reviewer can interact with). If the data is dydnamic it maybe important to 946

retain in their dynamic (electronic) format, to enable interaction with the 947

data. Data must be retained in a dynamic form where this is critical to its 948

integrity or later verification. The risk assessment should consider these 949

requirements. 950

19.4 CONTROLS FOR MANAGING RECORDS & SIGNATURES IN HYBRID SYSTEMS 951

Hybrid records require controls similar to those for electronic systems. 952

These controls should be described in SOPs, typical controls are :- 953

Procedure for signing paper printouts : A procedure is required to 954

define the creation, review and approval of the paper record including 955

attached electronic printouts. The procedure should describe the link 956

between the electronic and signed paper and define the signed paper 957

copy is the master. 958

Procedure for data retention /data integrity describing how data is 959

managed and retained including the following important points :- 960

o Retention time 961

o The record is legible for the required period 962

o The record retains date and time stamps 963

o The record retains data about the user who created the record 964

(user ID) 965

o The record retains any associated meta data 966

o The record contains any changes recorded using change control 967

and audit trail 968

Access control is always required and may be physical access control 969

to the document control centre for paper records. 970

Change control - changes managed on paper with change SOP 971

Audit trail – no electronic audit trail is available so may have paper 972

audit trail in the record, the audit train should be linked to the 973

change control. Use the risk assessment to see if the audit trail meets 974

requirements. 975

Transfer of data from old systems. Old systems may have retained data 976

overwritten every time the system is used or after a period of time. 977

It is important to transfer the data for long term storage of the 978

record by printing out and signing. Use the risk assessment as 979



of 198

described above to decide the complete record for transfer which may 980

include meta-data . 981

982

Paper records which include attached electronic data may be retained as paper 983

or by scan or transfer into a separate electronic system for long term 984

storage. These records require the same controls as above and additional 985

controls for the electronic storage system 986

19.5 USE OF FORMS TO ENFORCE PROCEDURES 987

When using paper based systems or hybrid systems it is good practice to use 988

a form to capture the data. The form ensures that all the required data for 989

each step of the process is recorded. The use of the form should be described 990

in the data retention SOP. Forms need to include references to the data, 991

standards, or SOPs they support to enable linkage to associated electronic 992

records, and to assist with archiving. 993

Forms can be retained on paper or scanned into an electronic system for long 994

term storage. Any change of format & media should be subject to risk 995

assessment as described above. 996

Example of part of lab data entry form. 997

Data Entry Form

Process Step SOP Analyst Second person

verification

check

or

result

Signature Date &

time

Signature Date &

time

1 samples arrive in lab

2 received and logged

3 Issue data entry form

and sample labels

4 segregated by item

code

5 document equipment

information

6 document reagent

information

7 record sample weight

8 print balance report

Audit trail of changes : Any changes have to retain the old data & show the 998

new data with reason for change, signature , time and date. Link to change 999

control if appropriate 1000

Example of part of production data entry form 1001

Data Entry Form

Process Step SOP Operator Second person

verification

check

or

result

Signature Date &

time

Signature Date &

time

5 Raw materials

dispensed in weighing

bay & labels printed

and fixed to bags

6 weights and labels

checked by supervisor

7 transfer to mixing

room

8 check labels against

batch record



of 198

9 Select correct recipe

on mixing station HMI

10 Correct recipe and

critical parameters

checked by supervisor

11 start recipe and

follow instructions

on HMI

12 confirm correct

materials added

13 confirm mixing time

1002

Audit trail of changes : Any changes have to retain the old data & show the 1003

new data with reason for change, signature , time and date. Link to change 1004

control if appropriate 1005

19.6 ISSUES WITH HYBRID RECORDS IN PRODUCTION AND LABORATORY 1006

Master Record - Companies should decide and document which is the regulated 1007

record (may be both). Suitable controls should be established and verified. 1008

These may include standard operating procedures that define the process of 1009

controlling the signed paper record, and for making modifications to the 1010

paper and electronic records if required. The procedure should provide a 1011

process that prevents incorrect or out of date versions of records from being 1012

used. 1013

Spreadsheets : It is very common to record production and laboratory data 1014

and calculate results with a spread-sheet. The spread-sheet records the data 1015

and then manipulates the data. The results are printed out, reviewed and 1016

signed & dated. The printout is retained in the batch record or lab record, 1017

the paper printout is the master record. For this use of a spreadsheet, the 1018

sheet should NOT be the first place the data value is entered—raw data—1019

because there is no audit trail provision if the value is changed in the 1020

spreadsheet. In this case, the raw data should be recorded in an official 1021

lab data document, then transferred to the spreadsheet. This permits the 1022

raw data to be preserved, so potential spreadsheet formula errors can be re-1023

verified. 1024

Spreadsheet records and calculations using templates have to be validated 1025

and controlled as described in GAMP5 appendix S3. 1026

The use of spreadsheets should be described in the data retention SOP and 1027

the risk assessment should look at the risks to managing and retaining these 1028

records. 1029

Chromatography Analysis 1030

It used to be common practice to print out the chromatogram and approval it 1031

by signatures on the paper record and attach the printout to the batch record. 1032

Regulators have recognized that this does not capture all the required raw 1033

data to enable the sample to be re-run. It is normal to re-run samples in 1034

the lab and it is important to record all the setup and base line information 1035

for review to be sure the sample meets the specifications. All this data has 1036

to be retained. 1037

http://www.fda.gov/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/1038

ucm124787.htm#3 1039

The quantity and complexity of the raw data is such that it cannot be 1040

abstracted to be managed on paper and must be retained in the original 1041

computer system to ensure that samples can be re-processed and compared. 1042

The management of chromatography data should be described in the data 1043

retention SOP including being able to re-process samples and compare all raw 1044

data. Re-process includes re-integration of chromatograms, resetting 1045

parameters describing changes are part of normal operation and have to be 1046

recorded and controlled by change control and audit trail (manual 1047

intervention/integration) describing the retention of all raw data 1048

The risk assessment should look at the risks around re-processing samples 1049

and comparing the raw data. The data may be transferred to another system 1050



of 198

for long term storage, any change of format & media being subject to risk 1051

assessment as described above. 1052

Production Machine 1053

Production equipment may collect electronic data which is printed out for 1054

subsequent review and approval as part of a paper batch record. 1055

It may not be possible to record confirmation of key recipe steps or record 1056

the management of master data or fixed data. Especially important are any 1057

changes to master data such as machine settings, product settings, recipe 1058

instructions and warning and action alarms. These may have to be recorded 1059

separately on the batch record system. The risk assessment should look at 1060

the risks around managing the retained data including any changes to master 1061

data. 1062

The data may be transferred to another system for long term storage. Any 1063

change of format & media should be subject to risk assessment as described 1064

above. 1065

Access Control 1066

A problem with older equipment /systems is that the access control may be 1067

physical control or limited logical access —for example, only one ID and 1068

password for all users. The risk assessment should look at the risks around 1069

unauthorized access / changes and additional physical controls, procedures 1070

and training may be required. 1071

1072

* Use of PDF 1073

PDF is an electronic format which allows searching and is suitable for long 1074

term storage. It does offer some possibility to manage records using audit 1075

trails and digital signature. However conversion to PDF sacrifices the 1076

ability to process the data. PDF is editable with certain software, so 1077

controls should be in place to manage this risk. 1078

1079



of 198

1080

20 PROCESS MAPPING/INTERFACES 1081

1082


Business process workflow and data flow diagrams are visual tools to show 1084

relationships of a business activity, including the creation and/or movement 1085

of data across a business activity and/or relationships between entities 1086

(interfaces). Visual tools permit people to analyze whole systems/processes 1087

in ways that would otherwise be difficult to achieve with text alone. It is 1088

often difficult to adequately understand a process without an understanding 1089

of the system’s intended use without process workflows and relationship 1090

diagrams including data flows diagrams across its infrastructure, especially 1091

when enterprise-level systems are involved. 1092

There are two distinct yet common methods to document and use these tools in 1093

defining the business process flowchart and the data flow diagram. The 1094

business process flowcharts identify business activities and decision points… 1095

whereas in contrast the data flow diagrams identify the creation, movement, 1096

use and archiving of data elements throughout a process.… 1097

20.2 PROCESS (BUSINESS) FLOWCHARTS 1098

Business Process Flowcharts show activities that collectively define a 1099

business process. They provide the “process” view of activities. This 1100

includes actions, decision points and sub-processes, reference Figure 1 1101

example. 1102

Access Change is Needed

CompleteAccess Request

FormObtain Approval Submit Access

Action Completed in System

Submitted for Review

NotificationsSent to Person, System Owner

Action Complete and

Correct?End Access Change

No

Yes

1103 1104

Figure 1: Access Management Business Process Flowchart Example 1105

This map can be extended by using lanes (also called swim-lanes) that add an 1106

additional dimension to the map, such as the role performing the action, or 1107

the location. Another approach is to create a table that provides details 1108

to understand each step of the map: for example, each action is numbered, 1109

and corresponding numbers in a table provide the location, responsible person 1110

(role), time to perform the action, and its output(s). Such a map/table 1111

combination gives a powerful understanding of a process, permitting users to 1112

identify critical points of the process. These critical points can then 1113

have risk management applied to them, forming the basis of a risk-based 1114

control strategy. 1115



of 198



FormObtain Approval Submit Access


Submitted for Review

NotificationsSent to Person, System Owner

Action Complete and

Correct?End Access Change

No

Yes

2

6

3 4

5

1

WhoLine

SupervisorSystem OwnerTraining Leader

Access Website

SystemAdministrator

System Owner or SME

WhereAccess

WebsiteAccess

Website(Email

message)Requested

SystemRequested

System

AccessWebsite

(Email message)

11 22 33 44 55 66

1116 1117

Figure 2: Access Management Process Flowchart Example including User and 1118

System Interfaces 1119

For large and/or complex systems, it is often more efficient to map the 1120

process in multiple layers. For example, a Layer 1 Map will diagram the 1121

entire system as a single box, showing its interfaces to other large systems. 1122

Layer 2 could show the interfaces between the system and one/several systems, 1123

in greater detail: for example, the interface with the financial system and 1124

its associated product library with standard costs. 1125

Process maps detailed in this manner provide understanding at the level 1126

needed by the audience: Layer 1 might be sufficient for senior executives, 1127

where Layer 2 will be useful for system support personnel. As mentioned 1128

earlier, if Layer 2 does not have sufficient detail for system understanding, 1129

another layer of depth might be necessary (e.g. Layer 3). The goal is to 1130

create the minimum number of process flowchart layers needed to define 1131

requirements, identify critical decision points and risks, and support the 1132

system. 1133



of 198



Form

Submit AccessTo System

Administrator

Action Complete and

Correct?

End Access Change

New User?

Create TrainingPlan

New Training Needed?

Add CourseTo Training Plan

Training Complete?

Training Approval

System Owner Approval

Obtain Approval

YES

NO NO

Get Template for System

Revoke Previous Role

Enter Requested User and Role

Screen Capture Image to Access

Library


Review Screen Capture

Compare System to

Approval Form

Review Access Audit Trail

ExecutionApproval Submitted for Review

Approved Form Archived

Lookup People to Notify

Send Notification

Message

Notifications to Person, System Owner

YES

NO

NO

YES YES

1134 1135

Figure 3: Layer 2 Access Management Process Flowchart 1136

20.3 DATA FLOWCHARTS 1137

Data flowcharts graphically illustrate the creation, use, and movement of 1138

data elements throughout the business process. It provides the “data” view 1139

of activities. They use similar images as the process flowcharts to 1140

illustrate actions and decisions, but list data elements (fields, table, or 1141

databases) that are impacted at each step. 1142

For simple systems it is possible to create a “hybrid” that combines both 1143

process and data into a single flowchart. For systems of moderate complexity, 1144

it is also possible to create a business process flowchart, and create the 1145

identical flowchart relabeled with data elements rather than process 1146

activities. This approach permits support personnel to see both process and 1147

data views in parallel. 1148

Data flow diagrams are useful for identifying data that is impacted by 1149

activities, for identifying data elements required by regulations, for ways 1150

that data can be re-processed or modified (therefore requiring an audit 1151

trail), and data that is critical for correct decisions. 1152


ApprovalE-Signature

Request Complete and

Correct?

End Access Change

SystemUsername

Requested RoleSystem Owner

Date Requested

AccessRequests

System AdminUsername

Requested RoleDate Needed

Access Request

AccessRequests

Review

User Mail NodeSystem Owner Mail Node

Role(Text Message)

E-mail Notification

System AdminRequestor

Admin NameDate/TimeUsernameNew Role

1153 1154

Figure 4: High Level Data Flow Diagram 1155



of 198

Advantages of Flowcharts (versus Text Statements) 1156

Superior to text for understanding relationships between steps (data 1157

process etc.) 1158

Show decision points (aids users in identifying critical steps) 1159

Illustrate inputs and outputs for each step 1160

Illustrate links between different processes or systems 1161

20.4 HOW MUCH IS NEEDED? 1162

Flowchart mapping processes and data flow diagrams are similar to software 1163

documentation: as the system size, complexity, and support level increase, 1164

the need to document in greater depth increases. In practice, personnel 1165

performing a routine process daily/weekly are able to identify data integrity 1166

risks and critical decision points when given a business process flowchart; 1167

consequently, a process flowchart is sufficient. In contrast, an electronic 1168

batch system with connections to inventory, planning, financials, control, 1169

and historian systems will require several process flowchart maps—perhaps 1170

one for each listed connection, and at least two levels of flowchart data 1171

maps for each process map—perhaps even more layers of data mapping in some 1172

areas. 1173

Because flowchart maps assist with process definition and understanding, 1174

identifying data integrity risks and critical decision points, and risk 1175

identification, once sufficient mapping is done to assist personnel in 1176

accomplishing these objectives, then enough flowchart mapping has been done. 1177

Beyond this, additional layers of data mapping add little value. 1178

20.5 CONCLUSION 1179

Process and data flow diagram maps provide a visual tool to understand 1180

business activities. Both provide information to personnel who perform risk 1181

identification (discovery) and URS activities. 1182

1183



of 198

1184

21 INSPECTION READINESS 1185

1186

21.1 INTRODUCTION & GENERAL PROCEDURES 1187

21.1.1 What is inspection readiness? 1188

It is anticipated that as regulators are performing more focused data 1189

integrity inspections there may be a decrease in the notice given by 1190

the regulators for inspections so that they see things as they are 1191

without firms preparing for an inspection. Firms need to have 1192

established policies and procedures to ensure that they are in a 1193

constant state of inspection readiness. Inspections may have a 1194

specific focus on the management of data integrity to verify the 1195

adequacy of controls. Alternatively, inspectors may adopt a forensic 1196

type approach to challenge the data integrity of certain records. 1197

This Appendix provides guidance on inspection readiness for data 1198

integrity rather than providing general guidance on inspection 1199

readiness. Firms are encouraged to consider data integrity within the 1200

context of broader inspection readiness programmes at their facilities. 1201

1202

21.1.2 Handling special requests during inspections 1203

It is increasingly common for inspectors to request copies of 1204

electronic records. This is analogous with taking copies of paper 1205

records and should be facilitated. Copies of electronic records can 1206

be provided as paper records, suitable marked and signed as authorized 1207

copies of the electronic master record. If paper copies of electronic 1208

records are provided during an inspection, there will need to be a 1209

discussion with the inspector(s) it the paper records do not represent 1210

complete copies of the electronic records. Alternatively, the 1211

regulatory authority may request electronic copies, in which case the 1212

media on which it will be stored needs to be agreed and labeled/signed 1213

as an authorized copy. It can prove to be quiet challenging if a USB 1214

stick is requested! Media should be scanned to ensure there are no 1215

viruses and that it is a complete copy of the requested record. 1216

Consideration should be given to whether it needs to be password 1217

controlled so that it remains secure. Consideration should also be 1218

given to agreeing that the information is treated as confidential 1219

business information and not used for any purpose outside the 1220

jurisdiction of the regulatory authority without prior written consent 1221

of the firm being inspected. As with any information provided during 1222

an inspection, it is recommended that a second copy of whatever is 1223

provided to the regulatory authority be created for the firm to retain 1224

so that they know exactly what has been handed over in the inspection 1225

if they ever need to refer back to it in the future. 1226

1227

Regulatory authorities have the same rights to access historical 1228

electronic records as they do for paper records. For this reason, 1229

electronic records should be maintained in a readable format for the 1230

same duration as equivalent paper records with supporting metadata 1231

where necessary. It is not necessary to keep the superseded legacy 1232

computerized systems as long as the storage media with the retained 1233

records can be read and understood. Stored electronic records should, 1234

if technologically possible, be the complete and accurate record. 1235

1236

Inspectors may also want to take photographs of equipment and 1237

facilities. This a simple task when using modern mobile (cell) 1238

telephones with built in cameras. Firms should have a policy on the 1239

taking of pictures, which should be shared at the beginning of the 1240

inspection so that there are no surprises to either party. If there 1241

are restrictions on taking photographs, such as safety issues in areas 1242

with potentially explosive processes, then this must be carefully 1243



of 198

explained at the beginning of the inspection. Most Inspectors will be 1244

happy to email copies of the photos they take back to the firm. 1245

However, where this is not the case it is recommended that the firm 1246

take it own comparable photos of the scenes to retain, again in case 1247

they ever want to refer back to what was photographed in the future. 1248

1249

Inspectors may also request direct access to computer systems to view 1250

records or workflows. Personal access should not be granted for 1251

inspectors that allows them manipulate data, apply electronic 1252

authorizations or approvals, or otherwise administer workflows. Only 1253

suitably trainer personnel must be able to do these activities. 1254

However, it might be possible to give read-only access to inspectors. 1255

Unless they are familiar with the system it is typically much more 1256

efficient to provide a trained operator to access the computerized 1257

system for the inspector to watch. Firms should keep copies of database 1258

queries and routines used to collect records for inspection. 1259

1260

21.2 KEY INFORMATION THAT NEEDS TO BE MAINTAINED FOR REGULATORY INSPECTIONS 1261

– RIGHT PEOPLE AND RIGHT INFORMATION 1262

One of the first computer system documents requested by a regulator is 1263

the Computer System Inventory. Therefore, there should be processes 1264

in place to ensure that the inventory is maintained current and 1265

accurate. 1266

Should an inspector(s) take a focused look at a computer system, it is 1267

important for the facility be able to readily identify the people 1268

responsible for that system i.e. the Process Owner and System Owner. 1269

In global companies, many systems are not locally managed systems, but 1270

represent systems that are used across the entire organization. With 1271

global systems, each site must know whom to contact for system 1272

information. They must also have documented evidence that the system 1273

meets their requirements and is fit for purpose. 1274

The Process Owner and System Owner will be accountable for responding 1275

to any system specific questions posed by the inspector(s). These 1276

people need to be very knowledgeable about the documentation supporting 1277

the implementation, control, maintenance, use and history of the 1278

system. There must be robust procedures to ensure that when anyone 1279

new assumes one of these roles there must be a robust process for the 1280

transfer of the system history and knowledge to the new person to 1281

remain in a state of inspection readiness. 1282

With the increased focus on data integrity, the Process Owner and the 1283

System Owner should be able to speak to any technical and procedural 1284

controls implemented to support the integrity of the creation, 1285

processing and reporting of the data. To ensure the constant state of 1286

inspection readiness, it is important that organizations have robust 1287

established procedures for all aspects of the system lifecycle. The 1288

Process Owner must be prepared to explain to the inspector(s) the 1289

business process supported by the system, the data flows, any business 1290

SOPs supporting the process as well as any security controls. With 1291

global systems and many interconnected systems, it is important to be 1292

able to demonstrate control of the data and records and consider any 1293

system interfaces 1294

The Process Owner must be prepared to speak to the record integrity 1295

including that: 1296

o Use SOP governs the timely recording of data 1297

o Audit trail is enabled and operating 1298

o Data / records can only be changed by authorized users 1299

o Data / records are restricted from change at required points 1300

in the lifecycle 1301

o Records are only approved / signed by authorized users 1302

o Approvals are enforced at the required points in the 1303

business process 1304



of 198

o Audit trail review (in accordance with risk) is integrated 1305

into the business process 1306

1307

The System Owner must be able to explain to the inspector(s) the IT 1308

procedures used to support the system. They should be able to explain 1309

the change control process, documentation and all change controls. 1310

Such a discussion requires the Process Owner to be very knowledgeable 1311

about not only the business process for the use of the system but also 1312

the validation documentation supporting the validation and use of the 1313

system. Together they need to be able to easily share the information 1314

about the requirements and testing of the data integrity related 1315

technical and procedural controls. To assist these individuals it is 1316

helpful to create a documented version history of the system. 1317

Together, the Process Owner and Service Owner should be able to discuss 1318

some of the key computer system documents including: 1319

o Validation Plan 1320

o Requirements 1321

Data integrity controls 1322

System security controls 1323

o Validation Report 1324

o Change control records 1325

1326

To ensure computer system inspection readiness, there must be robust 1327

monitoring of the system, business, and IT support procedures to ensure 1328

that the processes are adequate and are being followed. Below are 1329

some of the routine key areas that should be reviewed as part of 1330

monitoring to ensure readiness: 1331

Access control 1332

o User Access SOPs are in place and being followed 1333

o Available user roles are documented and managed by change 1334

control 1335

o Documentation supporting that only authorized and trained 1336

people have system access 1337

o Evidence that access is periodically reviewed (by automated 1338

checks where available) 1339

o Segregation of duties enforced 1340

o Generic accounts are not used for data modification 1341

o Back door changes requiring IT tools and skills are 1342

authorized, verified and documented 1343

o Historic access records 1344

Backup and Disaster Recovery 1345

o Documented and verified procedures for backup, restore, 1346

disaster recovery and record retention 1347

o Documented evidence that records and data are periodically 1348

backed up 1349

o Records retention policies are clearly defined and followed 1350

o Records and data can only be accessed by authorised users 1351

(network and system) 1352

o Archived records are secure and accessible for the retention 1353

periodically 1354

Data / Record Maintenance 1355

21.2.1 People preparedness, training records and procedures 1356

In addition to the Process Owner and System Owner, all individuals 1357

using or supporting the system must be ready for an inspection. There 1358

need to be robust systems to ensure that all individuals have current 1359

CVs, job descriptions and training records. If there are procedures 1360

for management review of training records, it is important to ensure 1361

there is documented evidence supporting this review. Training should 1362

ensure that individuals using or supporting computer systems understand 1363

what SOPs govern their roles. They should also be able to clearly 1364



of 198

articulate their roles and responsibility with respect to the system. 1365

21.2.2 Internal Data Integrity Investigations 1366

From time to time it will be necessary for the firm’s Quality Unit to 1367

conduct data integrity investigations. The basic approach to such 1368

investigations is no different to other investigations and they should 1369

be documented in the same manner with incident summaries, root cause 1370

analysis, and CAPAs. Consideration should be given to moving 1371

individuals to non-GxP activities under investigation for data 1372

integrity breaches until the investigation is completed. Trends 1373

across multiple data integrity incidents should be analyzed and any 1374

global CAPAs followed through where there are wider organizational 1375

implications. 1376

1377

Data integrity is not just about technical and procedural controls. A 1378

risk assessment should form part of this assessment considering not 1379

just the compliance risk to data but also the consequences to safety, 1380

efficacy and quality of medicinal products. Regulatory inspectors 1381

may be interested to understand not only the human factors associated 1382

with such incidents but also any contributory supervision and 1383

leadership factors. Workflows, equipment, and facilitates must all 1384

be suitable along with the provision of appropriate training and 1385

supportive oversight to assure data integrity. Process and data flows 1386

can be used in risk assessments to identify where additional controls 1387

might be warranted. 1388

1389

When preparing for inspections it is important to remember that 1390

regulators are increasingly sharing information and may be aware of 1391

data integrity issues before they formally inspect systems. 1392

Regulatory inspections may also ask for details of what has been 1393

reported to other regulatory authorities. Legal should be engaged to 1394

confirm what information could be shared within any restrictions 1395

imposed by the other regulatory authorities. 1396

1397

1398



of 198

1399

22 GLOSSARY 1400

TBA 1401

1402

1403

23 REFERENCES 1404

TBA 1405

1406

1407

1408

1409

1410

1411

1412

ISPE GAMP Good Practice Guide: Electronic Records and · PDF fileispe/gamp: good practice...

Documents

Transcript of ISPE GAMP Good Practice Guide: Electronic Records and · PDF fileispe/gamp: good practice...