gxpi presentation - validating an edms - the lean and simply

Validating an EDMS – the lean and simply compliant way

March 2012

© GxPi 2012 2

Agenda

Mark Stevens, Operations Director and Phil Harrison, Computer Systems Compliance Consultant at GxPi, will discuss:

Basic approach to validating an EDMS

Focussing validation effort to areas of greatest risk in both implementation and use

Introducing GxPi’s view of Lean Compliance

Working smart – application of Lean Compliance to EDMS validation

© GxPi 2012 3

Introductions

Mark Stevens – Mark graduated as a chemical engineer and entered the pharmaceutical and biopharmaceutical industries in 1994, since then he has been involved with engineering design, project management, systems implementation, compliance, strategic planning, business process improvement and delivering performance improvements to organisations and quality systems.

Phil Harrison – Phil graduated as a chemist, originally working within the fine chemicals industry before moving to the pharmaceutical industry in 1991. Since then, he has worked within Information Systems, Quality and Compliance roles within global pharmaceutical organisations. He has been involved with the implementation and use of EDMS with GMP and R&D environments.

© GxPi 2012 4

GxPi Overview

“We simplify complex process and technology environments to deliver our customers’

compliance and quality goals in their regulatory framework.

We achieve this through a combination of Services and Products that transfer our expertise

to our customers”.


Basic Approach to

Validating an EDMS

March 2012

© GxPi 2012 6

Basic Approach to Validating an EDMS

What does validation mean?

Computer System Validation can be defined as “Establishing documented evidence which provides a high degree of assurance that a Computerised System will consistently and reliably meet its pre-determined user requirements”. (FDA and other similar definitions)

Why do we need to validate an EDMS?

Because it will help to ensure that the system does what we want it to do!

Because we have to! - Validation is a regulatory requirement, if we are using the EDMS to support Good Practice (GxP) processes in the Life Sciences industry, e.g.

21 CFR Part 11 – Electronic Records and Signatures

Annex 11 of the European GMP Guide

How do we validate an EDMS?

Use defined processes within your organisation.

Use published guidance, e.g. GAMP 5 (Good Automated Manufacturing Practice)

Refine or tailor the approach to suit your specific use of an EDMS.

© GxPi 2012 7

Computerised Systems in Context (from PICS Good Practices Guide)

Operating Environment (other systems, people, equipment and procedures)

Computerised System

Controlled Function or Process

Computer System

Software

Hardware

SOPs

Equipment

People

© GxPi 2012 8

Computerised Systems in Context : the People – Process – Technology triangle

© GxPi 2012 9

Components of an EDMS - terminology

Infrastructure Sometimes used to refer just to hardware, networks and servers Often includes the software needed to manage networks and

servers such as Operating Systems Infrastructure needs to be “qualified, as distinct from “validated” Infrastructure control varies widely across different organisations

It can take a lot of effort to put this in place first time around

Base Software or Middleware Software that is needed for the application to work, but does not

need to be fully validated every time E.g. SharePoint, Oracle, Documentum

EDMS Application Software

The software you will use to manage your documents, that gives functionality for reviewing, reading, signing etc. Can be configured to meet specific requirements May be installed on server(s) and/or on individual client PCS

© GxPi 2012 10

Infrastructure Qualification - example

Qualification means :

Product tested against known ‘standard’ components OS versions Browser versions MOSS & SQL versions

All to specific service pack level

Infrastructure change control following qualification including: Service Pack patching Desktop control

Qualification enables x-docs™ to be ‘certified’ for use in a specific environment

© GxPi 2012 11

Categorisation of Software - GAMP Categories

Category 1 – Infrastructure Software

(Category 2 – no longer used in GAMP 5 - was previously “Firmware” in GAMP version 4).

Category 3 – Non-configured Products

Category 4 – Configured Products

Category 5 – Custom Applications

(GAMP 5 – A Risk-Based Approach to Compliant GxP Computerised Systems)

So where does an EDMS fit into these categories?

Typically, EDMS application software will now be category 4, but supported by

software in categories 1 and 3.

© GxPi 2012 12

Example “V-Model for” for Software Validation

Unit Specification

Design Specification

Functional Requirements

User Requirements

User Acceptance

Testing

System Testing

Unit Testing

Integration Testing

Coding

© GxPi 2012 13

Key Deliverables needed for Validation of an EDMS

User Requirements Specification Functional Specification Design Specifications Code Reviews Test Plans, Scripts and Reports – probably

at more than one level of testing e.g. Unit, Integration, System and User Acceptance

Traceability Matrix Qualification of Infrastructure Qualification of Test and Live

environments Procedure for operational use of the

system Procedures for Support and Maintenance

of the system, including Change Control, Incident and Problem Management (CAPA)

User training records Eventual decommissioning plans

Validation Plan

Validation Report

Operational Procedures


Focussing Validation Effort on

areas of Greatest Risk

March 2012

© GxPi 2012 15

Validation Approach for an EDMS – User Requirements

As for validation of any information system, the starting point must be to understand and define the user requirements

Be aware of how documents are actually used within the organisation e.g. will paper or electronic copies be used in practice, or both?

Which aspects of document management are most important to your organisation? Is it just version control, or more?

What is the nature of the actual documents you want to manage in this way – may not all be straightforward MS Word .doc files

Be aware of the value of Electronic Signatures for distributed organisations, once all have confidence that it works. Remember training and guidance will be needed first!

Ensure that the new system reflects the actual business processes

Where are your documents stored now? Will migration or uploading of documents into the new system be part of the your EDMS project, and how will you want to verify or test this?

© GxPi 2012 16

Important messages!

• Define your key User Requirements and hence your User Acceptance Testing as early as possible!

• Make the appropriate resource commitment for project management and system ownership in order to be successful, irrespective of size of organisation.

© GxPi 2012 17

Risk Based Approach - Examples

Which of your requirements are associated with the greatest level of risk when you use the EDMS?

Focus your testing on the functionality associated with high-risk requirements

For example, if this is the first application using Electronic Records and Signatures to be introduced in an organisation, then ER/ES functionality may be an area to focus on.

Is infrastructure is already qualified and subject to rigorous change control?

How good is the existing Quality Management System and the procedures for computer system validation? The risk may be higher of this is the first system to undergo formal validation.

You can reduce the risk by buying Commercial Off The Shelf software (COTS) – relying on the experience of your vendors

© GxPi 2012 18

Risk Based Approach - Examples

Basic document management functionality such as version control, may already have been thoroughly tested by the vendor. But, how important is version control to your Business?

Focus on any configuration, or coding, that is unique to your organisation, in preference to details that are already widely used elsewhere.

You may not need too much attention on middleware, other than confirming correct installation and versions.

Use past experience e.g. if previous projects have seen variations between Test and Live environments, make sure that your EDMS Test Environment is equivalent to the Live environment, via careful installation qualification.

GAMP guidance makes a clear distinction between responsibilities of the “Regulated Company” and the “Supplier”. If the supplier is trusted, and has been audited, it should be acceptable to rely on more of their testing and documentation.


Introducing GxPi’s view of

Lean Compliance

March 2012

© GxPi 2012 21


Lean Compliance - the process of enhancement and measuring performance of the key quality, compliance and validation attributes whilst identifying and eliminating non-essential elements from the activities of your business

Biggest benefits will tend to be through the elimination of waste – this is where the focus should be

Value-adding Activity that transforms or adds value to the

quality / compliance operation

Make as effective as

possible

Business Value Activity that does not add value but is

necessary to the business

Reduce and Minimise

Waste Activity that uses resources but creates no

value

Eliminate and Prevent

Summary of function value categorisation

© GxPi 2012 22


EDMS Lean Compliance – some practical ideas Risk Assessment – carry out this exercise properly! Just because something was important

and tested in a historical instance, does it actually need to be done this time?

Avoiding duplication of effort through risk assessment (GAMP5) model – select an appropriate supplier, complete due diligence and clearly specify your requirements of them

Identifying what components of the EDMS are essential to be bespoke and which can adopt standard functionality offered by the customer (non-value adding)

Validation test plan – structure validation testing to use SOPs as principal source of instruction rather than labour-intensive preparation of test scripts. Manage the overall project and deliverables to suit this

Trace Matrix – spending the time to set up the index from user requirements at the start of the project and maintaining this will save considerable time and effort later on in the process

User testing should be focussed around the validation of processes and operation of the system. Let supplier do the functional system testing – and provide evidence that this has taken place

© GxPi 2012 23

Example “V-Model for” for Software Validation

Unit Specification

Design Specification

Functional Requirements

User Requirements

User Acceptance

Testing

System Testing

Unit Testing

Integration Testing

Coding

Use standardised functionality and minimise bespoke design

Use vendor testing package

Focus on processes and operations

© GxPi 2012 24


EDMS Lean Compliance – some further thoughts

Is a key project within any business

Focus on key areas of risk, such as software provider testing, requirements

specification and how the application transfers between different infrastructures

Identify all areas of project that need to be controlled / validated, such as data migration etc.

Project plan for the retirement and decommissioning of any legacy systems

Plan the project, migration and switch-over to avoid the need to maintain duplicate systems

If the EDMS does not offer the ‘basic’ compliance / functionality you would expect, is it a solution that should be considered?


Conclusions

March 2012

© GxPi 2012 26

Conclusions

Changing type of EDMS application software means a reduced level of validation is required by the end user IF project implemented correctly

Correct use of risk-based approach will reduce validation burden

Need to have a suitable QMS in place in order to validate an EDMS

Lean compliance – look to use standard functionality where possible. Use supplier testing as part of validation and avoidance of duplicated or non value-adding effort

Hosting, such as x-docs™ Server, further reduces validation effort and cost of implementation

GxPi has a wealth of experience and resource available across the full range of CSV applications

gxpi presentation - validating an edms - the lean and simply

Documents