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
•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
•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
•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
• Case Studies
•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
•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 AnalysisAssessment 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
•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
•27

Topics
• Case Studies
•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
•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
•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
•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)

More Related Content

What's hot

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

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