This document outlines the importance of IT validation in ensuring that software and systems meet specified requirements and regulatory standards, particularly those set by the FDA. It details the validation process, key practices, documentation requirements, and the implications of validation on patient safety and product quality. The document also emphasizes the need for ongoing procedural controls, change management, and regular evaluations to maintain system compliance and effectiveness.

1. IT Validation
Who cares?
Why is it so important?
Bob Sturm
Director, IT Validation

2. IT Validation - Agenda
• What is validation?
• Why validate software?
• What does our company want?
• What is the GAMP 5/Validation Life Cycle?
• What does the FDA want?
• What are good documentation practices?
• What is our document naming convention?
• What about Change Control for GxP systems?
• Any Questions?
• Check the IT Validation site on SharePoint for the latest
validation templates as well as training, reference and
administrative documentation for validation

3. Questions For You
• How many here use validated computer systems?
• How many here have been actively involved in a
computer system validation (CSV) project?
• How many here have used software, at work or at
home, that doesn’t quite do what it’s supposed to?

4. What is validation?
• FDA definition
Establishing documented evidence that provides a
high degree of assurance that a specific process will
consistently produce a product meeting its
predetermined specifications (requirements) and quality
attributes

5. What Does That Mean?
• If it’s a critical GMP, GLP, or GCP process:
• You have to know what it’s supposed to do
• It has to work when it’s rolled out
• It has to work over its expected lifetime
• You have to be able to PROVE IT!

6. So What Is Computer Validation?
• FDA definition:
“Confirmation by examination and provision of
objective evidence that software specifications
conform to user needs and intended uses, and that
the particular requirements implemented through
software can be consistently fulfilled."

7. Okay… What Does That Mean?
• We document what the user needs and what the system
must do
• This establishes intended use and predetermined specifications
• We document testing of the system’s function and
performance
• This establishes that the system fulfills the requirements
• We document proper engineering and quality assurance
practices in the design, build, and installation of
computer hardware and software
• This establishes that the system should consistently work right
• FIT FOR IT’S INTENDED USE!  Key

8. Why validate software?

9. How Do We Decide Whether To Validate?
• If the system automates a process or manages
records regulated by the GMPs, GCPs, or GLPs, we
validate
• Validation isn’t a fixed concept…
• The amount of work, documentation, and $$
involved depends on:
• The level of risk assigned to the system
• The complexity of the system
• Whether we write the software ourselves, or purchase it and
install it ourselves, or use a system that’s hosted by a partner
• Contact me or QA Systems

10. WAN Infrastructure
(Qualified)
• Validation layer
CSCR GxP software applications Oracle (GxP)
• Qualification layers: GLOBAL | LOCAL
GMGT008 General IT Services
Core IT Infrastructure Software and Network LAN
Operating Systems
Hardware Desktop
Computers
Data Centers
ITMS processes – ISO certifications

11. The Difference between Validation and Qualification

12. Computer Validation Process
• SOP for Validation of GxP Computer Systems
• QA Systems does a GxP Risk Assessment
• Complete a CSCR
• Form a validation team
• System owner
• QA Systems
• IT: Applications, Infrastructure, Validation
• Decide what activities and deliverables are appropriate
• Start the system implementation
• Do formal validation testing and documentation
• Use and maintain the system under procedural controls

13. Potential Validation Documents
(GAMP 5)
Validation Plan Validation Summary
Data Migration (DM)
User Risk Analysis
Requirements PQ Protocol/ Scripts
Functional Specs OQ Protocol/ Scripts
Design specs IQ Protocol/ Scripts
Trace Matrix

14. Even More Possible CSV Deliverables
• Migration Qualification: assure that data from the
old system makes it to the new system okay
• Configuration Baseline Document
• Training materials
• SOPs/ WIs for system use, security, administration,
etc.
• All of these CSV documents have two purposes:
• Prove to ourselves that it works and we did the validation right
• Prove the same thing to an inspector, maybe years later,
maybe when everyone who was involved is gone
• One size does not fit all validations!

15. Policies vs. SOPs vs. Work Instructions
• “Policies generally set the overall tone and are high-
level requirements for the organization.
• SOPs then add the "how to implement" back-bone to
your policies.
• Some companies then use Work Instructions as step-
by-step procedures for doing a particular operation.
• From an auditing perspective, whatever a person needs
to do his or her job is a procedure.
• The FDA considers policies, SOPs, procedures,
work instructions, and your other internal guidance
ALL as "procedures" under its regulations.”
- Janis Olson, 22 years as an FDA field investigator and
regional manager; May 2011

16. What does the FDA want?
• www.fda.gov
• Four key things: Validation Project Plan,
Requirements, Test documents and a Validation
Summary Report
• Focus: Patient safety, Product quality and Data
integrity
• Complete, accurate, reliable and consistent
• Audit trial, system security, access controls and data
backup
• “IF IT ISN’T DOCUMENTED, IT DIDN’T HAPPEN”
(FDA and IT Industry Mantra)

17. What about 21 CFR Part 11?
• As we started using computers more, inspectors found
it hard to audit records required by the regulations
• We also started using electronic signatures
• 21 CFR Part 11 is intended to assure two things:
• Electronic records required by regulations are as trustworthy and
inspectable as paper records
• Electronic signatures required by regulations are as valid and
legally binding as wet ink signatures
• If Part 11 applies to the records in your system, the
required Part 11 controls simply become part of your
validation requirements

18. Industry Mistakes and Misconceptions
- From FDA field investigators
• Focusing on a software package rather than the
system as a whole
• Failure to plan for and address configuration
• Treating Part 11 as a quality issue
• Part 11 is focused on electronic signatures
• Audit trials can be manual
• If I print and sign, I can delete the electronic record
• Vendor certification is all that is needed for COTS
software

19. FDA Warning Letters - 483
• Purpose
• First warning of an issue from the FDA
• Gets the attention of senior company management
• Initiation of administrative enforcement
• Impact
• Corrective actions
• Company’s reputation with the FDA

20. FDA 483 Warning Letters
• FDA concludes that the…systems lack
adequate validation and therefore are
unacceptable for use in the production of
drug products
Trends
• As many as half of all inspections are now
focusing on some aspect of computerized
system quality and compliance

21. SOP for Good Documentation Practices
- Use MS Word’s Spell & Grammar Checker
Initial & date
cross outs.
Only one line.
Always use Validation Templates:
a Blue or Black Always use the
ballpoint pen latest version
from SharePoint.
Documentation
Good Practices
Complete all fields in
forms, don’t leave any Use the correct date
fields blank and write format:
legibly 03-Nov-10
03Nov10
Keep it current. Store and retain it properly.

22. Neatness Counts!

23. Once Our System Is Validated
• Validation shows that our system works… on the day
that validation is complete
• During the (hopefully) years the system is in operation,
we need ongoing procedural controls, especially:
• System use
• Change control
• Problem management
• Periodic evaluation
• Training for new users
• Ongoing system administration and security administration

24. Change Control - CSCR
• Uncontrolled changes to a validated system will make
people question whether it’s really still validated
• SOP for Computerized System Change Control
• All changes to a validated system must be documented, justified,
tested, and approved
• Changes might be as simple as a software patch from the vendor,
or as complex as installing a new version of the application
• Each change includes a mini validation effort… or maybe not so
mini, to assure and document that the system still works right

25. Problem Management - CSPR
• When things aren’t working right, people may question
whether the system is really still validated
SOP for Computerized System Problem Reporting
• Problems using or administering a validated GxP computer
system must be reported, tracked, resolved, and approved
• System users should report each issue to IT and the system
owner
• IT and system owners should consult with QA Systems to
determine whether the issue rises to the level of a “formal
problem” per the SOP
• The fix for a problem may be quick, or it may turn into a change
control

26. Periodic Evaluation
• Every once in a while, we need to step back and
take a look at our validated computer systems
• SOP for Validation of GxP Computer Systems
• Requires a periodic evaluation at least every three years (and an
annual security check)
• Evaluation includes original validation work, all change controls,
all problem reports, discussions with system owner/users
• Does the original validation work meet current standards?
• Have planned or unplanned system changes caused issues?
• Have changes outside the system caused issues?
• End result: either we declare the system to still be validated, or
we decide we need to perform some remedial activities

27. 9 Most Common Validation Errors
Validation Documents
• Missing Information – All
• Inconsistency – All
• Lack of Needed Detail – URS and FS
• Traceability – TM
• Vague Wording – All
• Unverifiable Test Results – Test scripts
• GDP – Test scripts
• Incomplete Testing – Test scripts
• Ambiguity – URS and FS

28. Questions??
• The only dumb question is the one you don’t ask.
* * * Complete your training record!

29. BONUS SECTION
• Additional information

30. FDA 483 Inspectional Observations
• “Validation…is inadequate in that there is no
documentation of: validation plan, test plan,
training plan or validation report
• “Original specifications are not complete
• “Validation…is inadequate in that there was no clear
correlation and comparison between expected and actual
test results
• “Documentation of the validation…is inadequate in that
observed test results are recorded only as a check mark.
Actual observed results are not recorded.
• “All functions of the software were not tested
• “Testing was performed before test plans were approved

31. FDA Warning Letters – Computer
Systems
• Computer software
• Lacks security to prevent unauthorized access
• Has no audit trial capability
• Lacks data security
• Lacks documentation of changes
• No documented software training
• Changes obscure original data
• Changes not restricted to authorized persons
• Original records can be deleted from the
computerized system without documentation
• Inadequate system validation

32. Possible Computer Validation Deliverables
• Validation Plan: what we want to accomplish
• User Requirements: intended use and security
• Functional Specification: what the system must do
• Design Specification: how the system will do it
• Installation Qualification: tests to show we put it together right
• Operational Qualification: tests to show it functions correctly
• Performance Qualification: tests to show it meets users’ needs
• Trace Matrix: shows that all requirements were tested
• Validation Report: summarizes what we did and how it went

33. 21 CFR Part 11
• What is a Part 11 record?
• Data is submitted to FDA in electronic format
• Electronic signatures intended to be the equivalent of a
handwritten signature
• Things to consider: from the 21 CFR Part 11 document
• Validation of systems
• Audit trails – secure, computer-generated and time stamped
• Ensure that only authorized individuals can access system
• Persons associated with system have training, education and
experience to perform their tasks
• Written policies: SOPs and Work Instructions

34. 21 CFR Part 11 – More items
• More things: from the 21CFRPart11 document
• Use of device checks to determine, as appropriate, the
validity of the source data input
• Use of operational system checks to enforce appropriate
permitted sequencing of steps and events
• Appropriate controls over system documentation
• Electronic Signature (e-sig)
• An e-sig is unique to one person, shall not be reused nor
reassigned to anyone else
• Person using an e-sig must certify to the FDA that their e-sig
is equivalent to their handwritten signature
• An e-sig is either biometric based or it consists of an
identification code and a password

35. GAMP 5: IT Computer System Validation and Document Flow: Key Validation Documents
** EVALUATE ** ** PLAN **
- Major release
A B K Validation/
- Added functionality Qualification Project Supplier Audit
Plan
** REQUIREMENT ANALYSIS ** ** BUILD / TESTING ** ** BUILD / TESTING **
** DEPLOYMENT **
IDENTIFY REQUIREMENTS WRITE PROTOCOL & EXECUTE TESTS SUMMARIZE TEST RESULTS
TEST SCRIPTS WRITE FINAL REPORTS
Installation Qualification Installation
IQ Installation Qualification Validation/
User Protocol & Test Scripts Qualification Test Qualification
D (Val Env) Summary Report
Requirement Execution (Val Env.) Summary Report
C
Specifications (Val Env.)
Functional F
E F G G
Specifications
Design Operational
Specifications Qualification Training Records
Summary Report
Operational Operational
Qualification Protocol Qualification Test
& Test Scripts Execution
Performance
Qualification Support Model
Performance Summary Report
Requirements Trace H I
Matrix Qualification Test
Execution
Performance
Qualification Protocol J
& Test Scripts ** MAINTENANCE **
J Pre
Post Implementation
IQ IQ Summary
Report Final WIs/ SOPs
IQ Protocol & IQ Execution
Test Scripts (Prod. Env.) (Prod Env.)
Optional: C-Risk Analysis, D-Training Plan,
D-Training Plan, (Production Env.)
E-Detailed Design Specs., F-Configuration Spec.,
F-Configuration Spec.,
F J Post J CHANGE
F
G-Training & Manuals, H-Migration Qualification Protocol,
G-Training & Manuals, H-Migration Qualification Protocol, CONTROL
I-Draft WIs/ SOPs, J-Migration Qualification Report
J-Migration Qualification Report Regression Test
Protocol Regression Test Regression Test
Administrative: A-GxP Assessment, B-IT Project Charter & CSCR, & Test Scripts Execution Summary Report
K-MS Project Plan ** RETIREMENT **