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

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?

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
4

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 Supplier
responsibilities

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

6

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

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

8

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

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 endusers perspective it describes what is
required.
The URS should also consider nonfunctional requirements, e.g. how many
users the system should support,
availability, performance, etc.

User
Requirements
Specification

The URS should ideally support purchasing

decisions.
12

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

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

Validation
Plan

14

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

An Example V Model Validation Approach

16

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.

Supplier
Audit
Report

18

(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
19

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

20

Some Definitions
IQ. Generate documented evidence that the system was
installed according to approved System Design Specifications
and 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

21

User Acceptance Testing

Test against user requirements
Formal (documented) testing
Fully traceable
Test against expected outcomes
Validation / Pre-production
environment
End-user site

Test
Plan

Can equate to OQ and PQ

Requires risk assessment for scope
Requires formal functional testing
by developer
22

Completing Test Scripts

Step

Test Procedure

Expected
Result

Actual
Result

Pass/Fail
(Issue)

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
23

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

24

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

25

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

QUESTIONS?

27

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