Computer System Validation LifeCycle Planning - CBI A_pres(3).pdf · Guide To Inspections of Computerized System In The Food Processing ... Electronic Data Archiving, ... GAMP® Good

Computer System ValidationLifeCycle Planning

Presented by

Sharon Strause, Senior Consultant

QACV Consulting, LLC

Computer and Software Validation

Hilton Philadelphia at Penn’s Landing

Philadelphia, PA

April 27 – 29, 2015

Sharon Strause

15 years with the

Pharmaceutical industry

Documentation

Computer System Validation

Quality Assurance in

information management.

11 years consulting

LifeScience Industries

Consumer Product Industries

Software Development Companies

Copyright QACV Consulting, LLC_2015

Where are you from?


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Key Issues

Additional Information


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Key Issues



Confidence building activity

Discover errors and ‘bugs’

Business benefit

Efficiency gains in current processes

New business process opportunities

DIRTFT (“Do It Right The First Time”)

Regulatory compliance

Why Validate


Pharmaceutical and Device Regulations US, Japan, EU, etc.

HIPAA

OSHA

EPA

DEA

DOD

Sarbanes-Oxley

ISO

Regulatory Compliance


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Key Issues



What to specifically validate Dictated by the predicate rules

FDA has also indicated other business critical processes Not called out in the predicate rules Should be evaluated to determine the need for

validation

Validation and the FDA


Hardware is considered to be equipment within the meaning of the CGMP regulations.

Software is regarded as records or standard operating procedures (instructions) within the meaning of the CGMP regulations.

Software maintenance is considered revision or change control.

FDA and CGxPs - Interpretation

(CPG 7132a.11)


FDA and CGxPs

Record controls require programs to ensure accuracy and security of computer inputs, outputs, and data.

Record access requirements - available for inspection and subject to reproduction.


The following slides are from two FDA presentations

“Current Status And Future Directions Of Part 11”,

September 21, 2004, Joseph C. Famulare, Director

“Update on Part 11 Regulation and Guidance”,

September 12, 2006, George R Smith Jr.,

Consumer Safety Officer

They show the significance of FDA interpretation

against the predicate rules.


211.68 – validation requirements of automated equipment

211.100 (a) - written procedures for production and process control

211.22 (a) – Quality control unit has the authority to approve and reject

211.67 ( c) – Records shall be kept of maintenance, cleaning, sanitizing, and inspection

GMP


211.103 - calculations of yield shall be performed by one person and independently verified by a second person

211.180 (a), (b), and ( c) – retention period for records

211.180 (d) – records retained can be original or true copies

211.194 (a) - Laboratory records shall include complete data derived from all tests necessary to assure compliance with established specifications and standards

GMP


50.20 – human cannot be involved in research without having a legally effective informed consent

56.108 (a) – IRBs must follow written procedures 56.115 (a) (5) – documentation of IRB activities 312.56 ( c) – sponsors shall review and evaluate

evidence related to safety and effectiveness 312.57 (a) – Records must be Accurate & Complete 11.10 (e) – Changes to e-recs must not obscure

previously recorded information

GCP


58.29 (b) – must maintain current summary of training for those engaged, or supervising the conduct of a non-clinical study

58.33 (b) – all experimental data… must be accurately recorded

58.35 (b) (4) – periodically submit a written status report noting problems and corrections

GLP


58.63 ( c) – records maintained of all inspections, maintenance records, testing, calibration and/or standardizing operations

58.107 (d) – receipt and distribution of each batch is documented

58.185 (b) – final report shall be signed and dated by the study director

GLP


21 CFR 812.145 (a) & (b) - Records must be Accurate & Complete

21 CFR 812.140 – must retain records required by 812

21 CFR 11.10 (e) – Changes to e-recs must not obscure previously recorded information

Devices


Validation Example – GMPs Key Words: ‘perform a function

satisfactorily…according to a written program’ 21 CFR 211.68 (a)

Validation Example – Medical Devices Key Words (not limited to): shall be validated, perform a

function satisfactorily 21 CFR 820.70(i)

Record Keeping Examples Key Words (not limited to): ‘must maintain’, ‘records

shall be kept’, ‘records shall include’ 21 CFR 58.29 (b), 21 CFR 211.67 (c)

FDA - Key Words


Audit Trail Examples Key Words (not limited to): ‘shall include complete…’,

‘must be complete’ 21 CFR 211-194 (a), 21 CFR 812.145 (a) & (b)

Retention Period Examples Key Words (not limited to): ‘retention period’

21 CFR 211.180 (b) & (c)

Electronic Signatures Key Words (not limited to): ‘shall be verified’, ‘shall

approve or reject’, ‘…shall be signed and dated’ 21 CFR 211.103, 21 CFR 211.22 (a), 21 CFR 312.56 (c), 21 CFR

58.185 (b)

FDA- Key Words


SOP Examples

Key Words (not limited to): ‘must follow written procedures’ 21 CFR 56.108 (a), 21 CFR 211.100 (a)

FDA – Key Words

End of FDA presentation slides


Sec. 820.198 (a) Complaint files. Each manufacturer shall maintain complaint files. Each manufacturer shall establish and maintain procedures for receiving, reviewing, and evaluating complaints by a formally designated unit. Such procedures shall ensure that: 1) All complaints are processed in a uniform and timely

manner; 2) Oral complaints are documented upon receipt; and 3) Complaints are evaluated to determine whether the

complaint represents an event which is required to be reported to FDA under part 803 or 804 of this chapter, Medical Device Reporting.

Automated Complaint Handling System -Example


Automated Complaint Handling System -Example

Sec. 820.198 (a) Complaint files. Each manufacturer shall maintain complaint files. Each manufacturer shall establish and maintain procedures for receiving, reviewing, and evaluatingcomplaints by a formally designated unit. Such procedures shall ensure that: 1) All complaints are processed in a uniform and timely

manner; 2) Oral complaints are documented upon receipt; and 3) Complaints are evaluated to determine whether the

complaint represents an event which is required to be reported to FDA under part 803 or 804 of this chapter, Medical Device Reporting.

Data Entry Queries

Time

stamps

Review

indicators,

Signatures

Std. Forms

Status indicators

and trackingCopyright QACV Consulting, LLC_2015

Use the regulations to get direction on what to validate

Use guidance documents and industry standards/practices to get direction on how to validate

Validation


General Principles of Software Validation; Final Guidance for Industry and FDA Staff: Jan 2002

Guide to Inspection of Computerized Systems in Drug Processing: Blue Book 1983

Guidance for Industry Computerized Systems Used in Clinical Investigations: May 2007

Guide To Inspections of Computerized System In The Food Processing Industry

Guidance for Industry Part 11, Electronic Records; Electronic Signatures —Scope and Application: Feb 2003

Pharmaceutical Inspection Convention (PIC) GMP Guideline PI 011-3 Good Practices for Computerized Systems in Regulated “GXP” Environments, Sep 2007.

GAMP5 A Risk-Based Approach to Compliant GxP Computerized Systems: Feb 2008

Guidance Documents(Partial List)


A Risk-Based Approach to Electronic Records and Signatures, Feb 2005

A Risk-Based Approach to GxP Compliant Laboratory Computerized Systems (Second Edition) Oct 2012

A Risk-Based Approach to GxP Process Control Systems (Second Edition) Feb 2011

A Risk-Based Approach to Operation of GxP Computerized Systems - A Companion Volume to GAMP 5, Jan 2010

GAMP® Good Practice Guides


A Risk-Based Approach to Regulated Mobile Applications, Oct 2014

A Risk-Based Approach to Testing of GxP Systems (Second Edition), Dec 2012

Electronic Data Archiving, Jul 2007

Global Information Systems Control and Compliance, Nov 2005

IT Infrastructure Control and Compliance, Sep 2005

Manufacturing Execution Systems – A Strategic and Program Management Approach, Feb 2010

GAMP® Good Practice Guides (Cont’d)


Overall validation model

Established procedures

Templates for key deliverables

Well defined maintenance phase

A Good Validation Program


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Key Issues



Continues to see significant problems with data

integrity (including outright fraud)

Does not trust what it’s seeing and what the

pharmaceutical industry is saying about its impact

Wants to return back to the original intent and

objectives

Why is Part 11 Back in the News?

FDA:


CDER announced this initiative in May 2010

To “evaluate the current pharmaceutical industry

understanding of, and compliance with, 21 CFR Part

11” and “where industry may not be complying

with, or understand, the enforcement approach as

stated in the guidance”

Part 11 “Tag-Along” Inspections


Some of the possible outcomes include –

Maintaining the “status quo, plus publishing

additional guidance”

“Amending the existing Part 11 regulation

and/or preamble”

CDER’s Public Statements


Some of the possible outcomes include –

“Proposing new wording / language to existing

CPGs and CPMGs that contain outdated

interpretations of Part 11 requirements”

“Revoking” or “amending” the current Scope and

Application guidance

CDER’s Public Statements


Applies to files/records required by predicate rule.

Applies to all GxP records saved on electronic media.

Applies to application software/associated documentation

Scope of Rule


Predicate Rules

GxP Regulations Good Laboratory

Practices (GLP)

Good Clinical Practices (GCP)

Good Manufacturing Practices (GMP)

Utilize to determine and apply the appropriate sections of any GxP regulation to computerized systems. Hardware = Equipment

Software = Records

Maintenance = Revision or Change Control GxMP Applicability to Hardware

and Software (CPG 7132a.11).


Part 11 requires the retention of electronic records in electronic form.

The predicate rule establishes the length of time that a record must be maintained.

Linkage between Part 11 & the Predicate Rules


Part 11 - Where does it apply?

Clinical

TrialsRegistration

Manufac-

turingDistribution

Research &

Development

Quality

Assurance

Electronic

Notebooks,

Reports,

Databases

Automated

Data

Collection

and

Reporting

CANDA’s

Updates,

Reviews

Electronic

Batch

Records,

Document

Management

Electronic

Notebooks,

Auditing,

Validation

Shipping

Documentation,

C’s of A


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Key Issues



Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV Planning

Project Methodology

Key Issues



“If you don’t know where you are going, you are likely to end up someplace else!”

Lewis Carroll

Planning


People vs. Technology

Project management is a job that deals mostly with people.

Technology is secondary.

James Lewis

Planning – Basic Elements


Problem Definition - Quote:

80% of projects that fail do so at the outset because they have not been defined properly……James Lewis

Helps define your solution/option suite

Assists project team with scope control.



Quote:

Those who fail to plan, plan to fail….FDA

Common Characteristic of unsuccessful projects

Conducted in secret

Project plans

Planned by the people who will use them to complete the project



In the beginning focus on what you need in the end…why are we implementing and

validating this system?

Define early what to validate and a risk based approach to how and why.

Planning


Project Methodology


Project management Key to SDLC

Stage Gates Concept

Early Planning – Project Initiation

Definition Requirements

Solution Analysis

Quality Review

Don’t Plan to Fail (1)


Stage Gates (Continued) Construction

Detailed Design Assemble/Test Quality Review

Implementation Preparation Warranty Quality Review

Benefit Quality Review

Sustain the Pipeline Quality Review

Don’t Plan to Fail (2)


A person or organization (e.g. customer, sponsor, performing organization, or the public) that is actively involved in the project, or whose interest may be positively or negatively affected by the execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables.

Identifying Stakeholders


Management

User Community

Project Team

Technical Team

Power Users

Support Team

Key Stakeholders


Total Computerized System

Controlling Computer System

Software

Hardware

Controlled Process

Equipment

Operating Procedures and Documentation

PeopleCopyright QACV Consulting, LLC_2015

Total System(Computerized System)

7

Controlling System(Computer System)

3

Controlled Process

6

Hardware

2

Software

1

Equipment

4

Operating

Procedures and

Documentation

5

Operational Environment8

... and

all the links

between the boxes

What needs to be validated?


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV Quality Process

SDLC

Key Issues



Quality Process in place includes….

SDLC Methodology

Project Planning

Vendor Management

Personnel Qualifications

Documentation Standards & Procedures

Methods for review & approval

Design Standards

Programming Standards

Configuration Management

Testing Standards & Procedures

Separation of Development, Test and Production Environments (if possible)


Quality Process in place includes….

Move to Production Process

Clearly defined responsibilities

Involvement of:

Customer/User

Quality Assurance professionals

Technology Professionals

Change Management

Training process

Process for continuous evaluation, incident monitoring, error correction

Processes and procedures for physical & logical security of system and data


Example - System Development Life Cycle


Example - System Development Life Cycle

Concept

Phase

Require-

ments

Phase

Design

Phase

Implemen-

tation

Phase

Integration

Phase

Installation

Phase

Maintenance

Phase

System Development Life Cycle

• Feasibility Study

Report

- Project Scope

- Risk/Safety

Analysis

- Process Desc.

and PIDs

- Technology

Assessment

- Regulatory

Assessment

• Training

Requirements

• Management

Approval

• Appropriation

Approval

• TPM Review

• Detail Project Plan

• Project Plan for

Remaining Phases

• Validation Plan

• Vendor Quality

Management Plan

• Vendor Qualification

Report

• Risk/Safety

Analysis

• Requirements

Specifications

• Functional

Specifications

• Training Plan

• User/Tech/Train

Manuals Plan

• Test Plan

• TPM Review

• Bus Tech Risk ID

• Project Plan

• Approvals NOTE:

- Documentation deliverables may be developed during

one phase of the life cycle and updated in one or more

subsequent phases.

• Risk/Safety

Analysis

• Requirements

Specification

• Functional

Specifications

• System Design

Specifications

• Traceability Matrix

• Test Plan

• Development Test

Plan

• Factory Acceptance

Test (FAT)

• IQ, OQ and PQ

• Training Plan

• User/Tech/Train

Manuals

• Conversion Plan

• TPM Review

• Approvals

• In-Process Audit

Report

• Requirements

Specifications

• Functional

Specifications

• System Design

Specifications


• Development Test

Plan

• IQ, OQ and PQ

• FAT Plan

• Source Code

• Executable Code

• Code Review

Documents

• Test Execution

Documents

• Training Plan/Materials

• User/Tech/Train

Manuals

• Acceptance/Implementation

Plan

• Approvals

• Requirements

Specifications

• Functional

Specifications

• System Design

Specifications


• Source Code

• Executable Code

• Training Materials

• User/Tech/Train

Manuals

• FAT Documents/

Reports

• IQ, OQ, PQ Protocols

• Integration Test

Documents

• Approvals

• IQ, OQ, PQ Reports


• User/Technical Manuals

• Training Materials

• Disaster Recovery

Plan

• Vendor Quality

Management Plan

• Validation Report

• Production Installation

Turnover Plan

• Post Implementation

Plan

• Approvals

• Periodic Review

Report

• Change Request/

Implementation Reports

• Document Supplements

• Maintain Training

• System Retirement

• Approvals


Network qualification Servers Lines, Routers, etc.

Data Migration Interfaces

Data Migration as well as ongoing use interfaces Schedules from other groups

Implementation i.e. Inventory completed

Marketing Launch schedule

Other support personnel Testing personnel Training personnel

Identifying Validation Dependencies


Data Migration

Migration Process Planned

Defined

Documented

Cleansing

Formatting

Conversion

Testing

Production Testing

Statistical Analysis


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Requirements

Key Issues



Requirements

Requirements are the foundation for your implementation and validation efforts.

Requirements are the most critical aspect of your implementation for they will

determine all aspects of the project from timeline to infrastructure to validation to

testing to maintenance!!Copyright QACV Consulting, LLC_2015

The cost to fix an error is generally 200 times more expensive in work or resources as compared to fixing it before implementation.

Requirement errors account for 40-60% of defects in software.

“Requirements engineering is where the informal meets the formal”

Requirements should be detailed enough so that designers know what to build and those developing the tests know what to test.

Requirements


One study revealed that for the successful projects, 28% of the project resources were spent on requirements. Furthermore 38% of the schedule went to requirements.

NASA projects that spent more than 10% of their total resources in the requirements phase, finished sooner and had lower costs compared to those that did not.

European study indicated that faster projects dedicated 14% of their efforts on requirements and 17% of the schedule, as compared to slower projects only committing 7% of their efforts and 9% of the schedule.

How Long Does It Take To Develop Requirements?

Results from summaries in Software Requirements by Karl Wiegers.


Basic Requirement Categories

Essential If these are not met then the system will not be

accepted. Core functionality, security, regulatory compliance, etc.

Desired (but not essential) Having these would be great and may even have a

large impact on the process being automated, but are not essential to the success of the project. Process improvements, personal preferences, etc.


Business process High level objectives for the business process being

automated User What the user will be able to do with the system

(typically focused on system/user interactions) Functional Specific behaviors the system must exhibit

Non-functional External interfaces, design constraints, quality

attributes, implementation constraints, etc.

Levels of Requirements


Characteristics of good requirements Complete

Consistent

Necessary

Accurate

Testable/Verifiable

Traceable

Unambiguous

Valid

Requirements


Group effort

All key stakeholders involved/represented

Diagram current and proposed process

Case studies

Workshops

Questionnaires

How to Gather Requirements


Develop a numbering scheme AT-1… AT-2…

AT-2.1… AT-2.2…

SEC-1…

Requirement development is a group effort with stakeholder involvement

Requirements should be approved and changes managed Change management process should be formal Changes are okay if they are controlled Change can affect scope, pending work, completed work,

timeline, cost, etc.

Managing Requirements


When are you “done”?

Can’t think of any more requirements within the scope of the project

New use cases are just another alternative to derive requirements that have already been captured.

Stakeholders start to repeat issues previously discussed

A gap analysis of the areas that needed to be addressed shows all concerns are documented.

Completing Requirements


Inspect the requirements for the attributes they are supposed to possess

Inspect the requirements for the attributes they are not supposed to possess such as design details, implementation details, project deadlines

Checklists are often helpful

Completing Requirements


“In the air, braking is not allowed, but a safe landing obviously requires brakes. To ensure that pilots did not inadvertently engage at A320 braking system, the software required that the wheels detect the full weight of the airplane. However, when a Lufthansa pilot attempted to land in Warsaw on a wet runway in high winds, the system did not detect the full weight of the plane on the wheels…the spoilers, brakes and reverse thrust were disabled for up to 9 seconds after landing in a storm on a waterlogged runway, and the airplane ran off the end of the runway …resulting in injuries and, loss of life.”

Complete Requirements?


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Risk

Key Issues



GAMP

Lifecycle approach

Phased to Project Management and Validation Process

FMEA

Quality Tools

Six Sigma

Tools for Evaluation


Do not document for documentation sake (i.e. to make the validation stack bigger and weigh more)

Improperly implemented documentation can add risk to your project Poor requirements Blanket procedures that apply to all situations without

regard to risk Lack of key documentation

Make your documentation meaningful and every word count

Can Documentation Add Risk?


Feasibility Stage

Is

Validation

Required

?

User

Requirements

Specification

Response to User

Requirements

Specification

Supplier

Assessment and

Purchase

Functional Spec

and Design

Test System

Validated System

Change Control

Determine Scope

of Validation

Document Justification

of Validation Approach

Update Validation

Plan

Develop Test

Plans

Decision

Documented

No

Yes

R

R

R

R

Validation ActivitiesProject Implementation Activities

Risk Assessment and

Validation Process, GAMP 4

R


Identify the system Identify hazards and

possible harms

Risk ManagementRisk Analysis

Risk Evaluation

Risk Mitigation/Control

On-going Evaluation

Estimate, justify and document risk level(probability/severity)

Estimate costs of mitigationvs. non-mitigation

Define and take actions for mitigation

Monitor for new harms Monitor risk levels Update plan and take

actions

Risk

assessm

ent

Key criteria: product quality (public health), business continuity

ISO 14971-1:1998


Start with a Process Flow Chart

Determine potential risks of the process relative to intended use

List critical control points for each identified hazard

List critical limits for each of the critical control points

List procedures used to monitor each of the critical control points

Risk Assessment


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Testing

Key Issues



Test scripts provide documented evidence that you have tested the system against your requirements.

The scripts may be called for to demonstrate your overall validation efforts or to demonstrate that a specific function is performing as anticipated.

How Your Test Scripts May Apply in an Audit


No - test scripts may be designed to fit the type of qualification testing but can contain similarities

They should be traceable

Vendor’s or developer’s specifications (equipment, environmental, etc.) (IQ)

Functional requirements (OQ)

Routine business process(es) (PQ)

Are All Test Scripts the Same?


Pass, fail, yes, no, as expected, true, and false are not and never will be objective evidence. They are conclusions and are conclusions made based on what one believes the objective evidence shows.

“Objective evidence is data that shows or proves that something exists or is true. Objective evidence can be collected by performing observations, measurements, tests, or by using any other suitable method.”

Objective EvidenceKey to Testing

ISO’s Plain English definitions


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV Maintenance

Change Control

Periodic Review

System Retirement

Key Issues



Validation is just one part of the system’s lifecycle. The maintenance phase ensures the system stays in a validated

state.

The Maintenance Phase


User/System log

Change control

Ongoing training needs to ensure continued compliance

Periodic review

The Maintenance Phase


System User Log - for documenting all uses of the system.

Error/Incident Log - All system errors/incidents are to be recorded on this log, whether software or hardware, and each problem should be reviewed and its impact and resolution assessed.

System Operation Log - is used to describe any system level activity such as backup, software installation, software change, etc.

Maintenance/Repair Log - is for noting any type of maintenance or repair performed on the system.

Use/Issues/Maintenance Log


Change Control

The only thing constant is change.

- Anonymous


Know Everything at Any Time

SV04

SV03

DH08

SV02

`

SV01

Bench 1 Bench 2

Review

Clients

Bench 3

DH09

DH08DH03

DH02

DH01

DH05

DH06

DH07DH04

N01N02N04N05N03

WANNetwork

05

CS01 CS02

SD FIBER

GB-Ethernet

100BaseT

`

CORE

ACCESS

DISTRIBUTION

• Equipment Hardware

• Computer hardware

• Network components

• Operating systems

• Application software

• Specifications

• Validation status

• Documentation

Slide – courtesy of L. Huber, www.labcompliance.com


Develop and implement SOP on change control

Describe who can initiate a request, evaluate and/or approve a request

Describe who can implement a change, what are the testing requirements, and what should be documented

Change Control ProcessPlanned Changes


Hardware defects

Software defects

Emergency situations

Timing critical for business continuity

Consider request and release approved by two senior network administrators

Full approval afterwards

Emergency situations only

BE SURE TO DEFINE

Change Control ProcessUnplanned Changes


Periodic Review

A critical part of your Quality Assurance Program and should be part of every IT

program.


An evaluation of the system to ensure its adequacy to perform its designated task(s),

compliance with current standards and industry trends,

and assurance the testing and associated documentation still supports the systems current use.

Frequency In conjunction with a major change to the system (event

driven)

At a predefined time period - recommended not more than every 36 months (time driven)

Periodic Review


Examines several key areas: Business Process Requirements Design Changes/change control Current system performance User load Procedures and standards System backups Testing (IQ, OQ, PQ) supporting the validated state Archival/availability of system related documentation

Periodic Review


System Retirement

System Retirement is another important element of the Maintenance Phase

Data is key here as it will drive what happens to the system in the retirement process.


The validation process encompasses the full lifetime of a system from installation to retirement.

Retirement formally closes the use of the system and ensures any records and data are available, as appropriate.

Two major steps to retirement Retirement Plan

Retirement Summary

System Retirement


Identifies the system (name and version) Identifies the hardware and software components to be

retired Outlines the method for deactivation, removal, or re-

assignment of the system Identifies all involved parties and others that should be

notified of the retirement Addresses the preservation of data, records, etc. Outlines system-specific procedures that should also be

retired The retirement plan should be a formal approved

document

Retirement Plan


Signals the completion and acceptance of the retirement activity

Summary of the outcome of deactivation and removal

Date the retirement was complete Be sure to include the “cleansing” of the server(s)

Actual disposition of the retired records

Any deviations from the Plan

Should also be an approved document

Retirement Summary


Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Training

Key Issues



System implementation and validation is a lot to handle. Do not assume everyone knows how to do it.

Before, during, and after the validation people need to be trained. But what are the basics of good training?

Training


Who Gets Trained

EVERYONE!!

Start with Management


Plan, Plan, Plan

Establish objectives

Design training

Prepare materials

Determine size, seating

Reserve the space

Notify participants

Elements of Training


Conducting Rehearse, Rehearse, Rehearse Room Setup Watch Time Train-the-Trainer

Adult learning principles Use humor Use brainstorming Use visuals Use vocal variety Use meaningful gestures Do’s & Don’ts Handling a class

Elements of Training (2)


Documenting

Name of course

Date & Time of course

Length of course

Description of course

Name & Signature of Trainer

Names & Signatures of Attendees



Follow-up strategy Feedback Reference Materials Newsletters Table Toppers Department/Safety Meetings Measure & Monitor Performance Peer Audits Current Events/Bulletin Boards Contests



Agenda

Why CSV

FDA & CSV

Part 11

Elements of CSV

Key Issues Compliance

Validation



Audit trails

Record linking

Training

Procedures

Data migration

Archiving

Documentation

Record retention

Key Compliance Issues


Audit trails

Record linking

Training

Procedures

Data migration

Archiving

Documentation

Record retention

Key Compliance Issues


Audit Trails

Identified to Predicate Rules

Confirmed during testing

Reportable

Permanently linked to record –confirmed during testing.


Audit trails

Record linking

Copies of records

Inadequate Procedures

Data migration

Archiving

Record retention

Computer System Validation –Key Compliance Issues


Record Linking

Unbreakable links for predicate rule requirements

Reportable through the linkage

Electronic signature component to actual record (encrypted)


Audit trails

Record linking

Copies of records


Data migration

Archiving

Record retention



Copies of Records

Required by predicate rule

Must include all links and signature components

Ideal

Exportable to Industry Standard Format (PDF)


Audit trails

Record linking

Copies of records


Data migration

Archiving

Record retention




Include as part of UAT/PQ

Trained

Documented

Competence

Usability

Complete


Audit trails

Record linking

Copies of records


Data migration

Archiving

Record retention



Data Migration

Migration Process Planned

Defined

Documented

Cleansing

Formatting

Conversion

Testing

Production Testing

Statistical Analysis


Audit trails

Record linking

Copies of records


Data migration

Archiving

Record retention



Archiving

Planned as part of implementation

Record Linking

Signatures

Data

Record Recovery

All pieces visible


Audit trails

Record linking

Copies of records


Data migration

Archiving

Record retention



Record Retention

Requirements

Regulatory

Legal

Corporate

How

Electronic Media

Paper

?????


Requirements

Design Control

Testing

Change Control

Traceability

Monitoring

Key Validation Issues


ApproachWhere do you begin?


IFYOUW

OULDJUS

TTELLMEW

HATTODOTH

ENIWOULDNOTH

AVE TOTHINKATALL


Understanding the principles Knowing the requirements Knowing the governing regulations Establishing the risk

Detailed application Becomes a matter of rational trial and error Document, Document, Document Don’t take shortcuts Do “Lessons Learned”

Evaluate, Evaluate, Evaluate

Right Things in Focus


Questions


Thank You

[email protected]
