Why Validate?

NHS Symposium, 25th Sept 2013

John McNamee

Introductions

• RQA

• John McNamee

• Phil Harrison

2

RQA

• Was British Association of Research

Quality Assurance (BARQA)

• Research Quality Association (RQA)

• Started in early 80’s

• 600?? members

3

John McNamee

• Mechanical Engineer

• Computing since 1972

• Domestic Appliances, Aerospace,

Consultancy

• Safety testing (toxicology) in 1977

– Pre-clinical Safety testing

• Red Apple, FDA, OECD, BARQA

training courses4

Instem plc

• 3 companies (Instem, Fraser-Williams,

Apoloco) – 1969 – all GLP focused

• Amalgamated 1999

• Recent acquisitions – informatics and

Phase 1 Clinical (Logos – Alphadas – Early Phase EDC)

• Our space is Early Discovery

• 120 staff worldwide

5

6

Why Validate?Computerised System Validation

Objectives

• Understand the definition of ‘validation’ and why we

validate computerised systems

• Gain a high level understanding of what validation

involves

• Understand the potential repercussions if we don’t

validate

• Overview of typical inspection findings related to

computerised systems.

7

How it all started!

• In ~1976 scientists at IBT* were discovered

“doctoring” data in a host of animal studies

• FDA introduced the Good Laboratory

Practice (GLP) regulations– (Computers, as we know them, didn’t exist!)

• Then came QA, GMP, GCP, GxP, Red Apple,

GAMP, Part 11…….

• ……and Validation!

8*Industrial Bio-test Laboratories

History lesson! of Validation Regulations

• 1970s: Concept of “Validation” proposed

• In response to problems in the sterility of large volume parenteral market, two FDA officials were the first to propose “validation” as a way to improve the quality of pharmaceuticals

• Initially validation focused on the processes involved in making these products

• Led to associated processes including environmental control, media fill, equipment sanitisation etc

• 1983: FDA Published Bluebook

• Guide on the inspection of Computerised Systems in Pharmaceutical Processing

• 1987: FDA 21 CFR 58 Good Laboratory Practice Regulations

• 1987: Guideline published on Process Validation

• Validation expanded to include computer systems used in the development and production of pharmaceutical products and medical devices

• 1991: MHRA EU GMP regulations (Orange Guide)

• Annex 11 updated to include use of computer systems

• 1997: FDA publishes 21 CFR Part 11

• “rules on the use of electronic records, electronic signatures”

• OECD GLP 1997 & EU Directives

• 1999: GLP Regulation, Statutory Instrument No. 3106, effective 14 December

• 2004: GLP (Codification Amendments etc.) Regulation Statutory Instrument No. 994, effective 27 April

• 1997: ICH GCP Consolidated Guideline

• 2001: EU Clinical Trials Directive published in 2001 (2001/20/EC)

• Published by UK as Statutory Instrument 2004 No. 1031 for implementation from May 2004

• Applies to all bodies/institutions manufacturing, testing and analysing materials associated with clinical trials in humans.

• 2002: The General Principles of Software Validation published

10

Computerised System Validation

• The process of establishing documented evidence, that

provides a high degree of assurance, that a computer

system consistently performs according to predetermined

specifications and quality attributes [FDA]

• Validation - Confirmation by examination and through

provision of objective evidence that the requirements for a

specific intended use or application have been fulfilled.

[ISO 9000]

• Proving that the system is fit for purpose

Validation – why the need?

• 1987 Process Validation Guideline definition

“Establishing documented evidence that

provides a high degree of assurance that a

specific process will consistently produce a

product meeting its pre-determined

specifications and quality attributes.”

Validation later expanded to include computer

systems used in the development and

production of pharmaceutical products and

medical devices

11

Look at 3 documents

• Good Manufacturing Practice - GMP

• Good Laboratory Practice - GLP

• Good Clinical Practice - GCP

– Not in time order

– Different roots

– Same principles

12

http://ec.europa.eu/health/files/eudralex/vol-4/annex11_01-2011_en.pdf

13

14

EU GMP Annex 11 – ValidationPrinciple

• The application should be validated; IT infrastructure should

be qualified.

• Where a computerised system replaces a manual operation,

there should be no resultant decrease in product quality,

process control or quality assurance. There should be no

increase in the overall risk of the process.

Risk Management

• Risk management should be applied throughout the lifecycle

of the computerised system taking into account patient

safety, data integrity and product quality.

• Decisions on the extent of validation and data integrity

controls should be based on a justified and documented risk

assessment of the computerised system.

GMP Annex 11 – Personnel,

Suppliers & Service ProvidersPersonnel

• All personnel should have appropriate qualifications, level of access

and defined responsibilities to carry out their assigned duties.

Suppliers and Service Providers

• Where third parties are used ---- formal agreements must exist ---

these should include clear statements of the responsibilities of the

third party.

• The competence and reliability of a supplier are key factors when

selecting a product or service provider. The need for an audit should

be based on a risk assessment (vendor audit).

• Quality system and audit information relating to suppliers or

developers of software and implemented systems should be made

available to inspectors on request.

15

16

GMP Annex 11 – Project Phase, Validation

• The validation documentation and reports should cover the

relevant steps of the life cycle.

• Validation documentation should include change control

records and reports on any deviations observed during the

validation process.

• An up to date listing of all relevant systems and their GMP

functionality (inventory) should be available.

• User Requirements Specifications should describe the

required functions.

• User requirements should be traceable throughout the

lifecycle.

17

GMP Annex 11 – Project Phase, Validation

• The regulated users should take all reasonable steps to

ensure that the system has been developed in accordance

with an appropriate quality system.

• Evidence of appropriate test methods and test scenarios

should be demonstrated.

• If data are transferred to another data format or system,

validation should include checks that data are not altered in

value and/or meaning during this migration process.

18

GMP Annex 11 – Operational PhaseData entry

Accuracy Checks

Printouts (human readable form)

Data Storage

Audit Trails

Change and Configuration Management

Periodic Review

Incident Management

Security

Electronic Signatures

Business Continuity

Archiving

Operational detail: see “Maintaining the Validated

State”

Functional Requirements: see “Validating a New System”

The Application of The Principles of GLP

To Computerised Systems

• Broadly similar to Annex 11

• Requirements in addition to those in Annex 11:� More information about the responsibilities of specific roles with regard

to computerised systems

� Specifically requires that validation criteria are defined and testing

demonstrates that they are met.

� Requires that raw data are defined for each computerised system

� Requires that computerised systems are located in suitable facilities with

protected from extremes of temperature and humidity, etc, and have an

appropriate power supply.

� Data archived electronically is subject to the same requirements as any

other types of GLP data in terms of access control, indexing, and

expedient retrieval.

� Data can only be deleted if there is management approval and relevant

documentation produced.

19

ICH GCP 5.5.3 Electronic Systems

a) Ensure and document that the electronic data processing

system(s) conforms to the sponsor’s established

requirements for completeness, accuracy, reliability and

consistent intended performance (i.e. validation).

b) Maintain SOPs for using these systems.

a) Ensure that the system(s) are designed to permit data

changes in such a way that the data changes are

documented and that there is no deletion of entered

data) i.e. maintain an audit trail, data trail, edit trail).

20

ICH GCP 5.5.3 Electronic Systems

d) Maintain a security system that prevents unauthorised access to the data.

e) Maintain a list of individuals who are authorised to make data changes.

f) Maintain adequate backup of the data.

g) Safeguard the blinding (e.g. maintain the blinding during data entry and processing).

21

ICH GCP 5.5.4 & 5 Electronic Systems

• If data are transformed during processing, it should always be possible to compare the original data and observations with the processed data.

• The sponsor should use an unambiguous subject identification code (see 1.58) that allows identification of all the data reported for each subject.

22

23

The “V” or Validation Model -

the classic design for Computerised Systems

What Happens if You Don’t Validate?

• The system doesn’t work properly:

– Compromises patient safety

• Regulatory authority require you to:

– Perform remediation activities (agreed with them)

within an agreed (usually short) timeframe

– Stop using system until validated / can demonstrate

system is fit for purpose

– Assess whether any other systems you have are

similarly affected, and if so, perform remediation

activities.

• Potentially large costs and loss of reputation.

24

FDA Warning Letters - breakdown

1. Lack of Validation or Insufficient Validation (53%)

– Including inadequate validation, inadequate procedures,

insufficient testing, inadequate record-keeping and

documentation, and inadequate review.

2. Inadequate Record Protection (22%)

– Including failure to prevent data loss, failure to prevent

data alteration, and missing or incorrect data

25

FDA Warning Letters - breakdown

3. Inadequate System Access Controls (10%)

– Including inadequate or completely missing security

mechanisms and processes for authorizing, granting and

rescinding system access

4. Inability to Generate Readable Records (8%)

– Including failure to generate human readable records and

failure to generate accurate records

5. Inadequate Audit Trails (7%)

– Including missing audit trails and inaccurate date/time

stamps on audit trails

26

FDA Warning Letters

27

Summary

• Don’t do it unless you have to

• If you do it, document it properly

• Don’t go overboard

• Use Risk Analysis

28

29

QUESTIONS?