ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)

ISPE-CCPIE CHINA CONFERENCE 2010

October 26-29 2010 Beijing

Validation of Legacy Systems

Case Study: ERP Legacy Systems Validation


David Stokes Global Head of Life Sciences, Business & Decision

• 25 years experience in computer system validation

and IT compliance

• Automated / Process Control Systems

• Corporate IT Systems

• IT Infrastructure

• Active member of GAMP® Forum

• Contributor to the GAMP® Guide and many

GAMP® Good Practice Guides

• Actively working on a number of computer system

validation projects executed in China


•2


Topics

• What is a Legacy System?

• Why Validate Legacy Systems?

• How to Validate Legacy Systems

• Case Studies • Retrospective Validation of Global ERP System for

multinational Medical Devices company

• Validation of Legacy ERP System for Chinese

Pharmaceutical company


•3


What is a Legacy System?

• “Any GxP relevant system that is in

place and in use, and which is not

deemed to satisfy current regulatory

expectations”


•4

“Legacy Systems” ISPE Pharmaceutical Engineering,

Nov/Dec 2003, Vol 23 No 6


What is a Legacy System?

• “…in place and in use…”

• Already in production use

• May have been in use for many years

• “…not deemed to satisfy current regulatory

expectations…”

• Infers not only regulations, but also regulatory

guidance and industry good practice

• Remember that regulatory expectations change

over time


•5


GAMP® “Legacy Systems” Article ISPE Pharmaceutical Engineering, Nov/Dec 2003, Vol 23 No 6

• Written in 2003 to principally address issues of

compliance with 21CFR Part 11 (Electronic

Records, Electronic Signatures)

• Note that the US FDA are now exercising

enforcement discretion with respect to

• 21CFR Part 11

• Systems in use prior to August 20, 1997

• Systems implemented after August 20,1997 have

no such enforcement discretion

• 21CFR Part 11 still applies in the USA

• There is no such discretion with respect to the

need to validate legacy systems Validation of Legacy Systems

•6


Why Validate Legacy Systems?

• Retrospective Validation

• Some systems have not been validated

that should have been validated

• This may have been because of

• Oversight or ignorance on the part of the

owner

• Deliberate decision to avoid the costs

assumed to be associated with validation


•7

Past



• Change in Use

• Some systems require validation for future use

because they are now being used for

• Different products

• Supply of product to different markets

• As a result of this different regulations may now

apply e.g.

• Bulk chemical manufacturer now manufacturing active

pharmaceutical ingredients

• Local company now starting to export product to the

US and/or Europe Validation of Legacy Systems

•8

Future



• Change in local regulations

• New expectations are beginning to emerge in

the Chinese market

• Chinese SFDA are already asking local

companies whether their systems are validated

• It is expected that regulations and/or guidelines will

follow

• World Health Organization (WHO) guidelines

already require the validation of GMP systems

in member countries


•9


Why Validate Legacy Systems

• Validation is no more that appropriately

documented good software engineering

practice

• Validated systems

• Are fit for purpose and better accepted by the

users

• Are more reliable, repeatable and robust

• Have a lower cost of ownership

• Mitigate risks to product quality, patient safety

and data integrity Validation of Legacy Systems

•10


Is Retrospective Validation of New Systems

Acceptable?

• No

• Systems should be validated at the time of original

implementation

• It is not acceptable to implement a new system and then

validate it as a ‘legacy system’

• PIC/S PI 011* states that legacy system validation “is not

equivalent to prospective validation and is not an option

for new systems”

*Pharmaceutical Inspection Cooperation Scheme Guidance

“Good Practices for Computerised Systems in

Regulated “GxP” Environments


•11


Topics









•12


How to Validate Legacy Systems

• Every system is different

• Function

• Size and Complexity

• History

• The validation of every legacy system is different

• It is not possible to provide a single set of activities

that will apply to every system

• A general process and key principles need to be

applied appropriately

• This requires planning by appropriately educated, trained

or experienced people Validation of Legacy Systems

•13


A General Process

• The “Legacy Systems”

guide provides a

general process that

can be followed

• This has been updated

in the following slides

to leverage GAMP® 5

and risk based

validation


•14


Scoping

• Review and revise the (site) Validation

Master Plan to include the system

• For some corporate systems, there may

be an independent Validation Master

Plan

• Update the inventory of systems to

include the system and its status


•15


Gap Analysis and Risk Assessment

• Conduct a High Level Risk Assessment

• See GAMP® 5 Appendix M3

• Review (or conduct) a supplier assessment

• May or may not require an audit

• Conduct a Gap Analysis

• What should be done

• What has been done


•16


What Should Be Done

• Understand the regulations and guidelines that

apply

• Depends on your products and markets

• Most regulatory authorities expect very similar

things in terms of validation

• There are some specific differences between

different regulatory agencies e.g.

• European regulators expect a ‘System Description’

• US regulators expect compliance with 21CFR Part 11

• You need to understand and plan for these

differences


•17


What Has Been Done?

• Confirm what validation was originally

done

• Review existing project documentation

• Review existing maintenance and

support documentation

• Interview project, maintenance and

support staff

• Interview system users


•18


Retire or Remediate?


•19

What Has Been Done

What Should Be Done

What Needs to be Done

Documentation, Interviews

Regulations, Guidance

System Risk Assessment

Cost Benefit Analysis

Retire and Replace

Remediate and Validate

Gap Analysis Assessment Decision

Supplier Assessment

Detailed Risk Assessment


Detailed Risk Assessment

• Assess the risks associated with the each of the

validation gaps

• Identify remediation actions and approximate cost

• Remediation actions and costs should be based on

reducing risk to an acceptable level, focusing on risks to

• Product quality

• Patient safety

• Data integrity

• Compare cost of remediation against the cost of

retirement and replacement

• Decide what to do Validation of Legacy Systems

•20


Planning

• Develop a risk-based Validation Plan

• Specific to the system

• Based around the assessed risks

• Leverage actual data about risk

• Real risk likelihood

• Real risk detectability

• Plan only those activities that

• Mitigate real risks

• Establish the necessary baseline for on-going

control in the Operational Phase


•21


Specification

• Review in detail any

• User Requirements

• Functional Specifications

• Design and Configuration Specifications

• Source Code

• Test documentation

• Compare against

• Current requirements

• Existing system

• Update as required


•22


Specification

• The “Legacy

Systems”

guide provides

a good

approach

• Focus on

• Understanding

the ‘as is’

• Confirming that

the ‘as is’ is fit

for current

purposes


•23


(Re) Development

• If the ‘as is’ is no longer fit for purpose

changes will need to be made

• To configurations

• To customizations

• This may specifically be the case if there is a

change in product or market requirements

• Documentation should be created or

updated to reflect this


•24


Testing

• Testing should be risk-based

• Not everything will need testing

• Other forms of verification can be acceptable

• Focus on

• Higher risk requirements

• What has changed

• What was known not to work

• Leverage existing Test Cases and Test Scripts

where they exist

• Updating as required


•25


Testing

• The Scope of testing may include

• Unit Testing and Integration Testing

• Where custom functions have been changed

• Where there are specific concerns or known issues

• Functional (User) Testing (OQ and PQ)

• To confirm fitness for current purpose

• IQ is often also required

• Retrospectively qualifying existing IT infrastructure


•26


Reporting

• Prepare the Validation Report

• Focus on demonstrating that

• Risks were effectively mitigated

• The system is demonstrably fit for purpose

• Focusing on key requirements

• A baseline for on-going operation, maintenance and

support has been established

• This may require developing additional operational

procedures (see GAMP Good Practice Guide)

• Update the system inventory to reflect the

current status Validation of Legacy Systems

•27


Topics









•28


Case Study #1

Retrospective Validation

• Global medical devices organization

• Two instances of large global Enterprise Resource

Planning (ERP) system

• Hosted and maintained in USA

• Supporting 20,000+ users and 30+ business units

• Had not been validated, despite multiple changes

of use for GMP purposes

• Required urgent validation following a series of US FDA

Inspections

• US FDA has closed down one manufacturing facility and

issued Warning Letters Validation of Legacy Systems

•29


Validation Planning

• Each system adopted a different approach

• One ERP instance was validated as part of a major

upgrade

• Effectively a re-implementation with prospective validation

• One ERP instance was not being upgraded

• A true retrospective validation

• A risk-based approach was used for both systems

• A new risk-management process and model had to be

developed

• Qualification of the IT Infrastructure was also

required Validation of Legacy Systems

•30


Retrospective Validation -

Specification and Testing

• Requirements and specifications

• Had not been well maintained

• Did not reflect the ‘as-is’ use of the system

• Did not take a risk-based approach

• Did not meet ‘current regulatory expectations’

• Test documentation

• Was largely up-to-date

• Used in a well defined and controlled software release

process

• Did not meet ‘current regulatory expectations’


•31


Retrospective Validation -

Remediation Activities

• Activities included

• Preparation of risk-based Validation Plan

• Updating of all Requirements and Specifications

• Focus on business oriented ‘Use Cases’

• Documentation and verification of all configuration settings

• Formal testing of all customizations

• Formal User Acceptance Testing of all business processes

• Focus on appropriate testing, not OQ and PQ

• Qualification of IT Infrastructure

• Validation Reporting

• 10 month exercise to bring system into an acceptable state of

compliance


•32


Case Study #2

Validation for Change in Use

• Large Chinese state owned pharmaceutical

organization

• Existing instance of ERP system

• Change in use / change in regulations

• Requirement to validate the system for sale of finished

pharmaceuticals to US and European market (GMP)

• US FDA Inspection pending

• SFDA required validation of the system for distribution of

Active Pharmaceutical Ingredients (APIs) and finished

pharmaceuticals for local Chinese market


•33


Validation for Change in Use –

Validation Planning

• No previous history or experience of computer

system validation

• System owner has an existing relationship with a

local System Integrator

• Well defined Software Development Life Cycle (SDLC)

• Effective working relationship

• Validation Planning

• Decided to combine initial validation activities with roll out

of new functionality to new sites

• Establish processes and templates that can be applied to

all sites Validation of Legacy Systems

•34



Validation Planning

• Needed to support the regulatory expectations and

inspection requirements of US FDA and SFDA

• Decided that key documents would be bilingual e.g.

• Validation Master Plan, Functional Specifications, Test Plan,

Validation Report etc

• Other documents would be written for the intended

audience (in Chinese) but would have bilingual headings,

to allow the structure to be understood e.g.

• Functional and Technical Design Specifications, Test Cases


•35



Requirements and Specifications • Written / updated

to leverage best

practice for ERP

systems

• Leverages the

software vendor

and system

integrators best

practices, with

necessary

content to support

validation e.g. • Key GMP

Requirements

• Risk Assessment


•36



Testing

• Test Cases were updated to reflect

• New / changed business processes and system

functionality

• Current regulatory expectations

• Based on GAMP® “Testing of GxP Systems” Good

Practice Guide”

• Risk-based testing, leveraging previous

experience with the legacy system i.e.

• Any known issues,

• Actual risk likelihood or risk detectability


•37



Remediation Activities

• Activities included

• Preparation of risk-based Validation Master Plan and site specific

Validation/Project Plan

• Documenting of all GxP Requirements and Specifications

• Documentation and verification of all configuration settings

• Data conversion of legacy data and risk-based data verification

• Formal testing of all customizations by System Integrator

• Formal User Acceptance Testing of all business processes

• Qualification of IT Infrastructure

• Development of maintenance and support procedures

• Leveraging GAMP® and ISO 20000 (ITIL)

• Validation Reporting

• This was a more planned activity, integrating regulatory expectations

into planned and budgeted activities


•38


Conclusions

• Many legacy systems still need to be validated to

meet current regulatory expectations

• Very often as a result in a change in use or to address

new markets

• Each system needs careful assessment and

planning

• The GAMP® Legacy Systems Guide can help

• Addressing legacy system validation as part of a

defined and budgeted process is more controllable

and cost effective than when addressed as a

matter of short term regulatory enforcement


•39

ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)

Documents

Transcript of ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)