Validating a New

Computerised System

NHS Symposium, 25th Sept 2013

Phil Harrison

Introduction – Phil Harrison

• Chemistry background

• Quality Systems Manager in Active Ingredients

Manufacture

• Quality Assurance roles within Information Systems in

Pharmaceutical Research & Development

• Quality Manager, GXPi, Software Company serving Life

Science customers

• Consultant supporting clients with Good Manufacturing

Practice, Auditing, Computer System Validation

2

Validating a New Computerised System

• Context: Purchasing and installing a new

computerised system that will be used in a

healthcare process, and hence needs to be validated

• Where do we start?

• What activities do we need to carry out?

• What documents do we need to produce?

• How can suppliers help?

3

4

Computerised Systems?

• Information Systems, e.g.

Patient Records

• Laboratory Information

Management (e.g. LIMS)

• Label Generation

• Dosage Calculation

• Computer Controlled Lab

equipment (e.g. HPLC)

The approach is broadly the same

for all; responsibilities and

detailed activities may vary

Computer System Validation – GAMP 5

• Good Automated Manufacturing Practice

• A widely used and referenced guideline

• Applicable across all GXP areas, not just GMP

• Split into Regulated Company and Supplierresponsibilities

6

Regulated Company Responsibilities

• Governance for Achieving Compliance, inc:

• Policies & Procedures

• Roles & Responsibilities

• System Inventory

• Validate each system during implementation, inc:

• Validation Planning

• User Requirements

• Supplier Assessment

• Testing and Reporting

• Maintain System Compliance during Operation

7

Supplier Responsibilities

Use Good Practices for development and support, inc:

• Establish Quality Management System

• Technical Design and Build

• Technical Testing

• Commercial Release of the System

• Provide User Documentation and Training

• Support and Maintain the System in Operation

8

System Life Cycle Principles

� Concept / Project / Operation / Retirement

� Build or Buy?

� Projects and Development Lifecycles can include:� Planning

� Specification, configuration, coding, installation

� Verification or Testing

� Reporting & Release

� Review and approval at each stage

9

Risk Assessment

• Does the system need to be validated at all? Could it affect

patient safety if something went wrong?

• Means of reducing levels of validation dependant upon risk

• Use a functional risk assessment to decide how much

testing is needed

• Establish controls in response to your risks

• Document your risk-based decisions e.g. “we will not be

testing function x because…” or “we will not be validating

system y because…”.

• Should not be used as an excuse to do nothing!

GAMP Categories

• Used to identify how the SDLC should be used for

a particular project.

1.Infrastructure Software

2.(Was previously “firmware” – no longer used)

3.Non-configured, off-the-shelf products

4.Configured Products

5.Custom /bespoke Applications

10

11

12

User Requirements

• User requirements should be gathered, documented and uniquely numbered in a User Requirements Specification (URS)

• The URS details the required and desired functions and features from the end-users’ perspective – it describes what is required.

• The URS should also consider non-functional requirements, e.g. how many users the system should support, availability, performance, etc.

• The URS should ideally support purchasing decisions.

UserRequirementsSpecification

SMART Requirements• Requirements should be ‘SMART’:

– Specific. Each requirement must be focused on a clear objective or broken down further.

– Measurable. The achievement of the requirement must measurable by an objective test

– Achievable. Requirements must be non-contradictory and be realistic in terms of the available functionality.

– Relevant. The requirements must be clearly related to a specific, agreed business need.

– Time-limited. It must be possible to meet all listed requirements within the time-frame of the current implementation.

• “The system must be easy to use” is not SMART and not easy to test!

13

14

Validation Plan

• A document describing the

overall strategy and responsible

parties for validating a

computerized system within its

operating environment

• This plan includes measures and

responsibilities, agreed

assumptions about limitations on

the scope of the validation

exercise, and justification for any

exclusions

ValidationPlan

Validation Plan Contents (example)

• Purpose

• Scope

• Definitions

• Roles & Responsibilities

• System Risk Assessment

• Validation Approach / Methodology

• List of deliverables (documents) to be produced

• Operation and Maintenance

• Version History

• Approvals & Authorisation

15

16

An Example “V” Model Validation Approach

Supplier Assessment

• The supplier should be assessed, before any contract is

signed, to gain confidence that:

– They have competent staff who are trained and

experienced to perform their roles

– They have developed the software in a controlled

manner against an approved QMS

– There is appropriate documentation to describe the

software

– They have performed appropriate testing to

demonstrate the software works as intended

– The supplier has a mature process for providing

customer support

17

Supplier Assessment

• For suppliers whose product

is very well established and

widely used, confirming this

fact might be sufficient (e.g.

Microsoft?)

• Remote Assessment?

• On-site audit of the supplier?

• It may be possible to

reference or use details from

suppliers’ existing

documentation.

18

SupplierAudit

Report

19

(Supplier) Technical aspects

• Functional Requirements Specification

• System Design Documentation

• Coding and Code Reviews

• Unit / Integration / System Testing

• Provision of Test Scripts or advice for IQ/OQ/PQ or

User Acceptance Testing

20

IQ / OQ / PQ

• Care needed – these terms are not used consistently

across all GXP areas!

• IQ - Installation Qualification

• OQ - Operational Qualification

• PQ - Performance Qualification

• Can involve Plans, Specifications, Protocols (Test

Scripts) and Reports, depending on complexity

21

Some Definitions

• IQ. Generate documented evidence that the “system” was installed according to approved System Design Specificationsand manufacturer instructions and in accordance with the Validation Plan

• OQ. Generate documented evidence that the system will operate according to approved Functional Requirements and manufacturer instructions throughout its anticipated operating range, and in accordance with the Validation Plan

• PQ. Generate documented evidence that the system will operate according to critical user requirements, procedures and processes in the end-user environment and in accordance with the Validation Plan

22

User Acceptance Testing

• Test against user requirements

– Formal (documented) testing

– Fully traceable

• Test against expected outcomes

– Validation / Pre-production environment

– End-user site

• Can equate to OQ and PQ

– Requires risk assessment for scope

– Requires formal functional testing by developer

TestPlan

23

Step Test Procedure Expected Result

Actual Result

Pass/Fail(Issue)

1

2

3

Completing Test Scripts

• As expected’ only usually acceptable if accompanied by

documented evidence (e.g. a screenshot, report, etc).

• Any issues (failures) should result in an issue report, in

order to get he problem fixed

24

Set up Operational Arrangements

• Training for users and support staff

• Operational use process / procedure

• Support Contract / SLA for future incidents, problems, changes

• Backups & Disaster Recovery

25

Validation Report and “Go-Live”

• Validation Summary Report

– This document is the final

report issued at the end of

the validation activities

– It is a document that

describes the outcome of the

executed validation plan, and

records the validation status

of a computer system

• Approval / Release of the

System for Live use

Validation(Summary)

Report

Summary

• Write a Validation Plan

• Define a User Requirements Specification

• Assess Suppliers, and use them to support

technical validation efforts

• Carry out User Acceptance Testing

• Installation, Operational, Performance Qualification

• Write a Validation Report

• Ensure operational arrangements are in place

26

27

QUESTIONS?

Useful Links

• RQA Courses & Seminars http://www.therqa.com/learning/professional-development-courses-and-seminars/

• RQA Publications re Computer System Validation http://www.therqa.com/publications/booklets/computerised-system-validation/

• GAMP 5 Guide – Risk Based Approach to Compliant

GXP Computerised Systems http://www2.ispe.org/eseries/scriptcontent/orders/ProductDetail_PRISM.cfm?pc=5BOUN

DDLUS

• FDA Guidance re Mobile Medical Applications http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/ConnectedHealth/M

obileMedicalApplications/default.htm

28