Workshop

“Computerized System
Lifecycle CMF
Management” 03-04 November 2022
 HELLO!
I am Fajar Sidik
I am here as your partner during this workshop.
You can find me through fajar.sidik@cfi.co.id

2
 Please share your
expectation regarding
this workshop

3
PRE-TEST!
https://s.id/csvtest

4
Chapter 1
Introduction to Computerized System

5
What is a Computerized System ?

Hardware
Software Data Procedures
Firmware

Interfaces People Equipment

Computer System

Operating Environment

6
input output
The Regulation CDOB 2019

CPOB 2018 Aneks 7 Sebelum sistem komputerisasi

digunakan, harus diuji secara
Aplikasi hendaklah divalidasi; Infrastruktur IT menyeluruh dan dipastikan
hendaklah dikualifikasi. kemampuannya memberikan hasil
Penggantian operasi manual oleh sistem yang diinginkan
komputerisasi tidak boleh mengakibatkan
penurunan kualitas produk, kendali proses atau
Pemastian Mutu. Tidak boleh terjadi
peningkatan risiko menyeluruh terhadap proses EudraLex volume 4 annex 11

The application should be validated; IT

FDA 21 CFR part 11
deals with electronic records and signatures.
Part 11 mandates the requirements for
electronic records and signatures to be
accurate, reliable, readily retrievable, and
secure and to be able to replace paper records
and handwritten signatures legally
infrastructure should be qualified. Where a
computerised system replaces a manual
operation, there should be no resultant
decrease in product quality, process control or
quality assurance. There should be no increase
in the overall risk of the process
7
 What is included in Validation

Aplikasi
hendaklah
divalidasi;
Infrastruktur
IT hendaklah
dikualifikasi.

8
9
 What is included in Validation

Aplikasi
● Data Centre
hendaklah ● Server
divalidasi; ● Storage
● Wifi
Infrastruktur ● Switch Hub
IT hendaklah ● Router
● Firewall
dikualifikasi. ● Cloud
● Desktop Computer
● Network
● Mobile device
● Protocol

10
Guidance

11
 History of GAMP 5

Good practice guide

2001 2008 2022 2nd

1991 GAMP 1994 first 1996 1998
Released Released Edition
was product Released Released of GAMP 4 of GAMP 5
initiated released of GAMP 2 of GAMP 3
broaden applying
(Draft risk based
scope to
Supplier approach
all GxP
Guide)
system

Source :https://ispe.org/pharmaceutical-engineering/ispeak/gamp-25th-anniversary 12
Concept of CSA

13
What's New
• Appendix D8 – Agile
• Appendix D9 – Software tools
• Appendix D10 – Distributed Ledger System
(Blockchain)
• Appendix D11 – AI and ML
• Appendix M11 – IT Infrastructure
• Appendix M12 – Critical Thinking

What’s updated
• Appendix D1 – Specifying Requirements
• Appendix S2 – Electronic Production Records
• Appendix D2 – Functional Specification (removed)
combined with requirements
• Appendix O7 – Repair Activity (removed)
• Appendix S5 – Managing Quality withing outsourced
IS/IT Environment (Removed)

14
Same Concept of GAMP Market and
Develop Produce
distribute
Medicinal Medicinal
User product Product
Medicinal
Product

Product and Process Understanding

Lifecycle approach within QMS

Scaleable Life Cycle Activities
Science Based Quality Risk Management

Leverage Supplier
Involvement
Deliver Maintain and
Develop
products support
Supplier Product and
and product and
services
service services
15
Product and Process Understanding
Solid/ Liquid/ Injectable

OTC/ Prescription

Export / Local/ Toll

Critical Quality Attributes
Packaging design Critical Quality Parameters

Input Process Output

Tangible (RM,PM,
Sample)
Intangible
(Data, metadata)
16
17
 Scalable life cycle - Hardware categories
Category 1 – Standard
hardware component
The manufacturer model , version
number and,
where available, serial number, of
pre-assembled hardware should
be recorded.
Category 2 – Custom built
Hardware hardware component
categories
Should have a Design
Specification (DS), risk based
supplier audit and acceptance
testing including the
interconnection of component
18
 Scalable life cycle - Software categories

Category 1 – Infrastructure Category 3 – Non-Configured

Software/ Layered software Product
● OS ● Firmware based apps
Software
● Database Engine categories ● Instruments
● Programming Language
● Automation Tester
● Middleware

Category 5 – Custom
Category 4 – Configured
Application
Product ● Spreadsheet Macro
● ERP ● Custom Ladder logic
● LIMS ● Developed application
● SCADA
● MES
19
The Foundation

Patient Product
safety Quality

Intended Use

Data Integrity

20
Chapter 2
Perform Computerized System
Validation
21
 Deviation/
Incident Change Management
Functional Risk management Decommissioning
Assessment
Development Release Business Cont.
Review and
IQ/OQ/PQ summary Operational Plan
DevelopmentRelease
testing and Use Backup- Restore
Qualification Archive-Retrieve
Functional Supplier
Specification Selection Build Performance Periodic Review
Training SOP
monitoring
Security
Configuration Traceability
Administration
Design Software Matrix
Specification Design URS development

Validation Plan
Planning
Business Risk 22
Initial Risk
Assessment
Assessment
Detaill Regulasi CPOB 2018
CPOB 2018
1. Manajemen Risiko
2. Personnel
3. Pemasok dan Penyedia Jasa
Fase Proyek
4. Validasi
5. Data
6. Accuracy Check
7. Penyimpanan data
8. Cetakan atau prinout
9. Audit Trail
10. Manajemen perubahan dan konfigurasi
11. Evaluasi berkala
12. Keamanan
13. Manajemen insiden
14. Tanda tangan elektronik
15. Pelulusan bets
16. Keberlanjutan bisnis
17. Pengarsipan
23
 Planning – Business Risk Assessment

Financial Strategic Reputation

Risk Risk Risk

Business
Liability Security
Interruptio
Risk Risk
n Risk

24
 Planning – Validation Master Plan

4.Role &
1.Scope
Responsibility System
Inventory
Supported from List
5.Validation
2.Objective Master list of available
Life cycle
system in regulated site
with detail validation state
6.List and
3.Site
timeline of
overview
validation

25
 Planning - Role and Responsibility

QA System
owner
Computerized
System
Validation

SME

Process
owner
Supplier 26
 Planning – Validation Master Plan

Daftar seluruh sistem System

dan fungsi GxPnya Inventory
CPOB aneks 7 point
4.3 List

Master list of available

system in regulated site
with detail validation state
No System Software System Category Validat System Process ER-ES Remarks
Identificati Name ID ion status owner
on status
1 HPLC 1 Empowe XXAA 3 Valid Deploy QC N/A
r
2 EMS Lab XXLab SSAA 4 Not Deploy QC N/A DI RA
Valid available
No 27
 Planning – Validation Plan

In the approach of validation System Specific Validation

Plan
1. Scope & out of scope
2. Objective
3. System overview
4. Initial Risk Assessment
5. Validation Strategy
6. Documentation
7. Project Team
8. SOP list
9. Test Plan

28
 Planning – Validation Plan

1. Scope & out of scope

2. Objective Application
3. System overview
4. Initial Risk Assessment
Backup
Storage (NAS)

Network
1. Scope & out of scope
Validation is for the application server based and its related component, all the qualification of
network and infrastructure not relate are out of scope
2. Objective
Validation of server based application name __________
3. System overview
Architecture of the system and intended use of the system data
29
Planning – Validation Plan – System Overview

30
 Planning – Validation Plan – Initial Risk
Assessment

1. Scope & out of scope

2. Objective Set of question to determined GxP Summary &
3. System overview Impact and system complexity Recommendation
4. Initial Risk Assessment
GxP Impact
No Question Yes/No GAMP 5 Software Categories Complexity Implementation
1 Is the system / information used in manufacturing related process, No Question Yes/No
controlling or documenting quality of pharmaceutical related product 1 Is the system / information used in manufacturing commercially available?
Do the system / information used in manufacturing compromise wide variety of
2. Is the system/ information used in quality related decision? 2
software as infrastructure?
3. Is the system have automatic function for adjusting to occurring
3 Is the system / information use without configuration or configuration in scope of
anomaly/ validation check that relate to product quality and patient
printer availability, report header and/or within the scope of installed application
safety?
without use of other application?
4. Is the system have physical equipment that directly in contact with
4 Etc…
product?
5. Etc…. categories : 1/3/4/5

Criticality Impact: Direct/ Indirect/ None

31
 Planning - Initial Risk Assessment
CPOB aneks 7 point 4.4 Sistem kritis
● Pengaturan fisik dan logical
● Aliran data
● Interfaces dengan sistem ada proses
lain
Module ● Prasyarat perangkat keras & lunak
● Tindakan pengamanan
category

How often data should be backed up,

Critical
data how long retention period, security, ER assessment
point to note for accuracy check CFR part 11
(automated/ put procedural)
electronic/ paper records, data take on

Critical Should be added electronic

ES assessment
transact signature ? Who, When, How
CFR part 11
ion Any contingency plan should
be. 32
 Planning – Validation Plan

5. Validation Strategy → V Model, Supplier involvement, ERES compliance check

6. Documentation → Deliverable document

7. Project Team → Person will review, perform test, approve final report
8. SOP list → CSV, utilization, backup management, etc
9. Test Plan → Test protocol, pre-requisite, deviation handling, change during test,
33
test GdocP, test evidence
 Deviation/
Incident Change Management
Functional Risk management Decommissioning
Assessment
Development Release Business Cont.
Review and
IQ/OQ/PQ summary Operational Plan
DevelopmentRelease
testing and Use Backup- Restore
Qualification Archive-Retrieve
Functional Supplier
Specification Selection Build Performance Periodic Review
Training SOP
monitoring
Security
Design Traceability
Administration
Specification Software Matrix
Design URS development

Validation Plan
Planning
Business Risk 34
Initial Risk
Assessment
Assessment
Design
What does the system
• User Requirements
have to do ?

How will the system do

• Functional Specification
it ?

What will the system

• Design Specification
look like?

Who will built it for

• Supplier Selection
me?

Are they qualified to

• Supplier Audit
built it for me? 35
 Ice Breaking

❖ Draw straight line

❖ Draw a second straight line parallel to the

first line
❖ At the end of parallel lines, draw line
connecting the first and second line
❖ On the other end draw an inverted ‘V”

❖ On one side of the ‘V’ draw 2 parallel line

❖ At the last parallel line draw a horizontal line

connecting the end of the line

36
Writing User Requirement Specification (URS)

▰ Author & ▰ Requirements

Reviewer Page ▰ Req. identified number
▰ Document ▰ Glossary
number and
version
▰ Document
history
▰ Related SOP
for URS
template
37
What is inside your requirement ?

Records
and
Admin
User electroni
and
control c
security
signatur
Business
Data life e
Process
cycle
Function Operatin
g Audit
Interface
environ Trails
ment

38
User Requirement Specification

Production
Engineering
Department
as User

Documented
HSE Requireme
QA Formal
nt Profile
URS

IT
QC
R&D /
Technica
l 39
User Requirement Specification

Change may occur to the

document

Documented Given to Selected Quotation with

Formal Qualified Supplier Detailed technical
URS specification

40
Writing User Requirement Specification (URS)

▰ When Designing URS follow “SMART”

rules
S M A R T
P E C R I
E A H E M
C S I A E
I U V L B
F R E I O
I E A S U
C A B T N
B L I D
L E C
E 41
Specific

Your requirements should be

clear and specific. For
example, rather than drafting a
vague requirement such as
‘improve ad latency’, think
‘reduce ad latency by 50%’.

42
Measurable

Requirement must state something

that can be confirmed by
examination, test, or
demonstration. Avoid subjective
statements such as ‘easy’ or
‘faster’. If it can’t be measured,
there’s no way for both parties to
agree that the requirement has
been met.

43
Achievable

Your objective needs to

technically feasible. If you’re
not sure whether something is
technically possible, further
research is needed.

44
Realistic

Even if something is
technically achievable, it may
not be realistic due to budget
constraints, time restrictions,
regulatory requirements or
other limitations. It’s important
to be realistic when
determining your
requirements.

45
Time-bound

Requiring completion by a
specified deadline or within a
specified period of time.

46
Writing User Requirement Specification (URS)

▰ Avoid ▰ Avoid ▰ Prioritized

Ambiguity in uncommon requirement
wording terms/ jargon
▻ Essential
choice ▰ Use
▻ Optional/
▻ Easy identification
number Desired
▻ Fast

47
 Design - URS

The URS we know The User Stories

Focus on what system shall do and Focusing on user experience of user

capable of some feature performing task

Typical sentence: System shall able to ……... As a < type of user >, I want < some goal > so that
< some reason >.

Both are great combination of both maybe
help the supplier to know what user
actually want
User stories used for usually a business
flow requirement
User stories not likely used for security
feature or infrastructure
48
 Design – Supplier Selection

Regulated companies should assess

the quality and reliability of their
computerized system suppliers and
service providers
Supplier assessment
considering of system
novelty, complexity,
categorization and risk
Basic assessment:
• public domain information
• market reputation
• experience of prior performance
Explain
discussion with other companies
Desktop audit

On-site audit
49
 Design – Supplier Selection Best Practice
No Assessment Description

1 Supplier established QMS 1. Set of SOP, set of standard on SDLC (ISO 12207)
2. Training of staff
3. Compliance
2 Quality Planning Any qualification plan and report

3 Produce specification Complete set of specification with respective functional risk

4 Design Review Any design review perform and fully documented

5 Software Configuration Is it following the best practice of configuration and change

6 Commercial Released Does versioning apply, how it is apply

7 Provide user document and training Are training and documentation part of contract

8 System replacement retirement How it was managed and covered in contract

50
 Design – Supplier Selection

Service Level
Agreement

Supplier assessment Purpose Annual Maintenance

Contract

Responsibility of Supplier involvement in creation Confidence Level in

are : Leverage Supplier
document
•IT solution provider or vendor
•Inhouse developer or internal site team
51
 Design - FSDS

Functional Specification (FS) and Design Specification (DS) does not

contain any highly technical detail.

Rather, it describes how the proposed system will operate, how people
or data will interact with it and what to expect when different condition
occur.

A Functional Specification and Design Specification or FSDS maybe

combine or separately given depends on the complexity of the system
to become

52
Design - FSDS

Within the system development or any project FSDS will

help

– The Engineers know what UI and UX to design.

– The Programmers know what the code should do.

– The Validation Manager know what is at highest risk.

– The Specialist know the test case expected outcome.

– The Stakeholders know what will be delivered.

53
 Design – Functional Sepcification An FS defines what the system should
do, and what functions and facilities are
to be provided . It provides a list of
design objectives for the system. Formal
The FS defines a system to
testing will often be based on the FS
meet the user's needs as described
in a User Requirements Specification Overview
(URS)
Function
Both users and programmers Data
should understand the FS Explain Interfaces
Non – Functional Attributes
Environment
Glossary
54
 Design – Functional Specification (FS)
Overview Function Data
• Complete Architecture • Input/ output • Access speed
• GxP impact • Calculation • Update time
• Patient, Product, Data impact • Algorithm • Required filed
• Configuration tools/language/ • Performance • Validation check
standard program • Safety and security • Relationships
• Configurable function • Capacity and archiving
• Error condition • Integrity and security
• Migration
Interface Non function attribute Environment
• With user • Availability • Encryption
• With equipment • Maintainability • Physical
• With other system
• How data transmitted
• Transfer rate
• Data type, format, range, value meaning 55
 Design – Configuration / Design Specification (DS)

Produced by the supplier and reviewed

Based upon the type of system (e.g., and approved by regulated company
configurable or custom), Subject Matter Experts (SMEs)
configuration and Design
Specifications provide a Hardware design
detailed, technical expansion of the Software design
Functional Specification Configuration
Custom applications and Explain

part of supplier assessment

56
 Design – Configuration / Design Specification (DS)
Hardware design
• Main computer system
• Storage
• Peripherals
• Networks &
interconnection
• Embedded system (within
process equipment)
• Hardware operating
environment
• Database
• Interface
Software Design (custom
application)
• Database and collection files
• Records
• Data types & format
• Data precision and accuracy
• Algorithm
• Language & Version
• Reference standard
programming
• Input/ output
• Error handling
• Module operation
• Interface to other module
Configuration
• Setting and parameter
• Dependencies and impact to
other module
• OS and layered software
• Tools or method used to set
the option
*May incorporated this
information into FS for small
system
57
 Deviation/
Incident Change Management
Functional Risk management Decommissioning
Assessment
Development Release Business Cont.
Review and
IQ/OQ/PQ summary Operational Plan
DevelopmentRelease
testing and Use Backup- Restore
Qualification Archive-Retrieve
Functional Supplier
Specification Selection Build Performance Periodic Review
Training SOP
monitoring
Security
Design Traceability
Administration
Specification Software Matrix
Design URS development

Validation Plan
Planning
Business Risk 58
Initial Risk
Assessment
Assessment
How will the system • Software development (methodology, source code,
be built ? compiling – modules)

How will it be tested? • Development testing

How will you know it

is installed correctly • Installation Qualification
?
59
 Software should be
Build – Software Development subject to
Configuration
Management and
Define the program coding standards , documented version
directory structure standards , and file control.
naming conventions to be followed
Reviewed source code for custom
should be controlled accordance to
program to match the design
documented procedures Output
specification and following the
programming standard
Software development in GxP
environment for custom application
Commercial release
of the system to the
customer

More detailed see

• Appendix D4 GAMP 5 risk based approached to compliant GxP Computerized System pg. 187
• G.J. Myers: The Art of Software Testing
60
 Build – Commercial Release Commercial release
of the system to the
customer

System release to customers should be performed in accordance with a formal process that
describes criteria for
release, responsibilities, records to be retained, and items to be released, including software ,
hardware, and
documentation.
Release notes defining fixes , changes , and new features should accompany each release
including minor releases and patches.
Release to GxP
environment

More detailed see

• Appendix D4 GAMP 5 risk based approached to compliant GxP Computerized System pg. 187
• G.J. Myers: The Art of Software Testing
61
 Deviation/
Incident Change Management
Functional Risk management Decommissioning
Assessment
Development Release Business Cont.
Review and
IQ/OQ/PQ summary Operational Plan
DevelopmentRelease
testing and Use Backup- Restore
Qualification Archive-Retrieve
Functional Supplier
Specification Selection Build Performance Periodic Review
Training SOP
monitoring
Security
Design Traceability
Administration
Specification Software Matrix
Design URS development

Validation Plan
Planning
Business Risk 62
Initial Risk
Assessment
Assessment
 How much validation – • Risk Assessment and Critical Thinking
testing is required?

Are the processes required

to support it in place? • SOP’s, training, etc

Do basic functions work as

expected ? • Operational Qualification

Does the entire system • Performance Qualification – test cases

function as it’s required to? • Requirement/Specification/Test Matrix

How do we know everything

is addressed? • Summary report
63
Risk Based Approach if not using Critical Thinking

Using same robust

Supplier involvement and
approach to all risk The more the merrier
assessment not utilized
assessed

Hard to prioritize on
planning, remediation or Repeated test on system
test focus

64
What is Critical thinking ?

65
Simplified view of critical thinking

Which is spreadsheet
have more risk ?

< <
Monitoring For Stability Design Calculating Tablet
Department Monitoring Dissolution Result
Expense 66
 Identify Risk/
Requirement
Electronic record may
corrupt and loss during
process system operation
HPLC Calculation of average
and deviation standard may
use incorrect formula and give
incorrect result for product
release decision reference
Assess Risk Identify Control
The risk to product There is an automatic
quality and data periodic backup to a
integrity is introduced qualified
on this risk
The risk to patient The system was COTS no
safety, product quality method configuration
and data integrity is performed, final report and
introduced audit trail review by
manager
67
Function Prevention Detection

Management Control √

Data Lifecycle √ √

Training √

Incident reporting √ √

Data Review √

Audit Trail review √

Backup, Retore, Archive √

Retrieval

Audit and inspection √ √

Supplier Management √ √

Risk Management √ 68
Functional Risk Assessment - FRA

Critical impact System

: Complexity
Direct Cat.3
or Indirect Cat. 4
None Cat. 5

Complexity
Criticality Out of the box Configured Custom
Direct
Medium High Very High
Indirect
Medium Medium Medium
None
Very Low Low Low

69
 Deviation Handling and
Case Study CAPA Management
Start
Configurable
Direct impact
Batch
Revoke Justify
Containtment

Process Deviation Risk

Deviation occur Raised Assessment

Less than standard

yield Submit Investigation
CAPA log
Implementation and RCA

COTS
Yes No Not Direct
End VoE impact

Custom
Release Hold
Batch
Direct impact 70
Batch
URS ID Section Description Criticality

URS-BP-01 Business Process Flow Deviation Occur - Risk Assessment - Investigation - Implementation E
plan - CAPA Log

URS-BP-02 Business process flow Deviation Occur - Batch containtment on EBR - Justification by Risk - E
Revoke containment - Continue Batch

URS-F-01 Function Justification and Revoke on URS-BP-02 should only available by QA unit I

URS-F-02 Function Risk calculation based on Severity, Probability and Detectability which E
resulting in RPN S x P x D

URS-ES-01 Electronic Signature Submission of Implementation plan must have ES before it was D
recorded to CAPA log

URS-AL-01 Access Level Minimum of 5 access level can be managed in the system E

URS-IN-01 Interface CAPA system interface to ERP system (SAP type XX version XX) for I
batch product release and hold

URS-IF-01 Infrastructure QMS application should be able to operate on the Ubuntu version 20 on E
site premises 71
Functional Risk Assessment – FRA FMEA

72
 URS ID Failure Severity Occuranc Risk Class Detectabi Risk Mitigation
e lity Priority

URS- System moves incorrectly between Step Medium Medium 2 Medium Medium Configuration Test
BP-01

URS- Integration to batch record failure, system did High Medium 1 Low High Documented Test
BP-02 not contain the batch

F URS-F-
01
Batch continue without QA consent High Medium 1 Medium High Documented Test

M URS-F- Incorrect RPN calculation and formula Medium Medium 2 Medium Medium Configuration Test

E 02

URS- ES did not triggered when logging CAPA and Medium Medium 2 High Low Configuration Test
A ES-01 implementation

URS- Access level cannot be provided up to 5 levels Medium Low 3 Medium Medium Documented Test
AL-01

URS-IN- Interface problem, batch did not held before High Medium 1 Medium High Documented Test
01 CAPA fulfilment and batch maybe held forever
even if CAPA has been closed

URS-IF- System incompatible with Ubuntu 20 Medium Low 3 High Low Vendor Audit 73
01
Functional Risk Assessment – FRA Critical
Thinking

Critical impact System

: Complexity
Direct Cat.3
Indirect Cat. 4
None Cat. 5

Complexity
Criticality Out of the box Configured Custom
Direct
Medium High Very High
Indirect
Medium Medium Medium
None
Very Low Low Low

74
URS ID Section Criticality Impact Software Complexity Risk Mitigation/ Test Approach

URS-BP-01 Business Process Indirect Cat.3 Medium Unscripted Testing

Flow

URS-BP-02 Business process Direct Cat.4 High Scripted Testing

flow

URS-F-01 Function Direct Cat.4 High Scripted Testing

URS-F-02 Function Indirect Cat.4 Medium Unscripted Testing

URS-ES-01 Electronic Signature Indirect Cat.4 Medium Unscripted Testing

URS-AL-01 Access Level Indirect Cat.3 Medium Unscripted Testing

URS-IN-01 Interface Direct Cat.5 Very High Extensive Scripted Testing

URS-IF-01 Infrastructure None Cat.4 Very Low Design Review/ Vendor Audit

75
Functional Risk Assessment - FRA

Risk Test Assurance Level

Rating

Very Functionality verified or justified through

Low vendor audit or wide spread market use of
the software

Low Functionality validated through Unscripted

testing – ad hoc (vendor developer, during
FAT or development environment)

Medium Functionally validated through Unscripted

testing – exploratory/ error guessing

High Functionally validated through scripted

limited testing

Very Functionally validated through extensive

High scripted (positive and negative) testing

76
 What is Unscripted Testing ?

Unscripted Undocumented

Testing where tester’s actions are not

prescribed step by-step within
written instructions and are
experience based in nature, and may
include ad hoc, error guessing, and
exploratory testing
77
Qualification – IQ OQ PQ
Term Descrition GAMP 5

Design That the proposed design is Design review - Traceability

Qualification (DQ) suitable for intended purpose

Installation A System installed according Verification of software,

Qualification (IQ) written and pre-approved design hardware, other documentation
is correct

Operational A system operates according to Verification of the system

Qualification (OQ) specification and written against specification to
operation ranges demonstrate correct function

Performance System is capable performing Verification of the system

Qualification (PQ) within the scope of business fitness for intended use in
process in actual operating operating environment
environment 78
 Qualification – IQ OQ PQ

Installation Operational Performance

Qualification Qualification Qualification

Verification to Demonstrate

Installation/ Specification of Fitness for

configuration of functionality to intended use and
software and support business acceptance
hardware and process on against specific
document specified operating requirement
range
79
 URS ID Section Criticality Impact Software Complexity Risk Mitigation/ Test Approach

URS-F-01 Function Direct Cat.4 High Scripted Testing

URS-F-01 – Revoke Containment only available to QA unit

Test Plan To revoke batch containment by EBR automatic system Expected Outcome

Test Perform on dispensing – mixing process

Prerequisite Batch number ____
User from QA unit to revoke ______, User from production opr.
User Perform incorrect scan on material Vitamin D
Test Script 1. Login as Production Operator in PC production area (IP…) 1. Landing page of operator show
2. Open batch number _____ 2. Batch opened start from dispensing
3. Open material dispensing, start dispense it should appear to scan 3. Batch cannot be continued (freeze)
Taurine. Purposely scan vitamin D. 4. Message to input justification reason
4. Appeal to unfreeze the system typing reason, select shown
justification reason “error scan during dispense” 5. Landing page of QA dashboard show
5. Login on client PC in QA office (IP…….) 6. Task outstanding appear
6. Open task to related batch ____ to give revoke on the batch 7. Selection to revoke batch appear,
7. Revoke with comment and e-sign input
8. Refresh batch in production area 8. Batch production can be continued
9. Open audit trail and have symbol indicating
containment/deviation occur
9. Audit trail record the process of all
above
Review by 80
URS ID Section Criticality Impact Software Complexity Risk Mitigation/ Test Approach

URS-AL-01 Access Level Indirect Cat.3 Medium Unscripted Testing

URS-AL-01 – User Group by department and 3 role available

Test Plan Verification of user group according to department Expected outcome
Each group have 3 role (manager, supervisor,
staff/operator/analyst)
Test N/A
Prerequisite
Test Script 1. Verification of User group 1. User group according to
2. Verification of user role department in site
3. Perform checklist on user access 2. 3 role available
3. Access according to
manual book/ FS
Review by

81
 URS ID Section Criticality Impact Software Complexity Risk Mitigation/ Test Approach

URS-IF-01 Infrastructure None Cat.4 Low Design Review/ Vendor Audit

URS-IF-01 – System installed and compatible to server OS ubuntu 20

Vendor specification document the compatibility software

“Software compatible to Windows server and Ubuntu version 20 and up”

Installation qualification from vendor report during development on site premises server hostname, server IP)
Server OS 20

Sign Performer:
Sign Reviewer: Remark:

82
Qualification – Consideration of IQ

User and Logbook Embedded IT

technical system infrastructure
guides
SOP Hardware list Certification & Software list
calibration

Training result Instrument list Device list

and schedules

Service Level
Drawing List of critical
Agreements
spare parts
83
 Qualification – Consideration of OQ

Power failure Input validation Critical High volume load

transaction performance

System access & Electronic Data transfer

security feature signature feature within &
interface
Audit trail & Alarm and Backup &
critical action error message restore

Data entry Critical Data archiving

feature calculation & retrieving
84
Qualification – Consideration of PQ

Critical Data
Migration

Master Data
Verification PQ may not be
done for simple
system
End to End
business
process

85
 Objective of testing

Identify defects (bugs) so they can be removed or corrected before operational use

Preventing failures that might affect patient safety, product quality and data integrity

Providing documented evidence that system performed as intended

Demonstration system meet URS

Output of Test Test Test

testing protocol evidence Report

86
 Design Review Traceability Matrix

Requirem
ents
Requirement
Traceability
Matrix should
also provide
deliverable
result
Specificati
Testing
on

87
 Design Review Traceability Matrix

Functional/
Configuration/ Design Protocol documentation for
URS Document “001X.01”
Specification Document system “001X.01”
“XYZ01-V01”

FS - 001 - CS - 001 -
URS ID: OQ - 001 IQ - 001
Monthly Software &
DI001 - Data backup Automatic Software tools
Data Design for
automation to internal backup for backup
backup periodic
backup server IP. result and and network
periodic for backup &
192.168.1.1 restore structure
using “tools” parameter

88
 Qualification – Released Decision (Handover)
system handover from the
project team to the process
Project Operational owner, system owner, and
operational users is
Handover a pre-requisite for effectively
maintaining compliance of the
system during operation

• Dedicated report (may part of validation report)

• Confirmation of operational procedure
• Operational personnel readiness
• No critical risk left during project
Register in system
• Permission from validation environment to production
inventory
environment
• Rollback plan to previous version in case problem occur
Administrator
• Manage system validity (change management, deviation)
Responsibility
89
 Validation Summary Report

Activity Readiness Remarks

Validation

Validation Summary Report Is there approved validation

report in form of IQ, OQ and/or
rY
rN
Activity
SOP
Readiness Remarks

1. Scope & out of scope

PQ r N/A
Do controlled copy of SOP for rY
Data Migration operational already in place rN
Is data migration of GxP critical rY r N/A
2. Objective
and ready to use?
data have been confirmed to be rN
Do SOP for change rY
correct r N/A rN
management is available?
3. System overview Site user access
Does the procedure for
rY
Do SOP for incident
r N/A
rY

4. Supplier involvement
managing user access with management is available? rN
rN r N/A
reference from QA-G013 is
effective and in place for use? Do SOP for backup and restore rY

overview Do users access on the system

have been proven correctly by
rY
rN
management is available? rN
r N/A
Do SOP for record rY
5. 21 CFR ERES compliance their process owner?
Do external user access in case management, archived and
audit trail is available?
rN
r N/A
of multi-site system or rY
6. Validation Activity application of administrative
responsibilities have the correct
rN Do SOP for contingency plan is r Y
available? rN
r N/A
Overview access in the system ?
Do superuser access on the
rY
Do IT infrastructure SOP and
security have been established
rY
rN

7. Deviation List
system has been defined, and on SOP? r N/A
rN
the personnel is deemed r N/A Risk
qualified?
8. Recommendation
Do risk identified from GAP rY
Do system administrator has rY rN
during validation have been
been assigned? rN r N/A
mitigated or accepted?
9. Released Conclusion Training
Have the end user received rY
training for operating the rN
10. Checklist system?
Do you record the evidence of rY
training? rN 90
SOP & Training

▰ SOP for CSV

▰ SOP for utilization system
▰ SOP for backup and restore
▰ SOP data integrity
▰ SOP for user provision and access list
▰ SOP for audit trail review
▰ Training record and its correlation to user list
in the system 91
Establish
simple CSV
SOP to follow

Judul SOP: Validasi Sistem Terkomputerisasi versi 1

1. Tanggung Jawab Personil dan Fungsinya dalam Organisasi

2. Isi (berupa alur kerja)
● Konsep scalability V-model dari GAMP 5 dalam SOP
● Cara mendaftarkan sistem dalam inventaris sistem terkomputerisasi (+lampiran
contohnya)
● Cara membuat VMP/VP untuk sistem komputer (+lampiran contohnya)
● Cara membuat URS dan
● Cara melakukan kajian risiko fungsional dan kriterianya (+lampiran contohnya)
● Cara membuat protokol uji (IQ,OQ,PQ) dan relasinya dengan kualifikasi
(+lampiran contohnya)
● Cara membuat matriks ketertelusuran (+lampiran contohnya)
● Manajemen Perubahan & Penanganan Deviasi
Update SOP for
Establish simple
CSV life cycle
SOP to follow
approach

Judul SOP: Validasi Sistem Terkomputerisasi versi 2

1. Tanggung Jawab Personil dan Fungsinya dalam Organisasi tambahkan Vendor

(Internal team maupun external team) dan sistem administrator
2. Tambahkan Isi
● Initial risk assessment (Gxp Assessment, ERES assessment)
● Supplier audit/ assessment dan tingkat perjanjian kerjasama
● Pembuatan FS/DS
● Manajemen Perubahan & Penanganan Deviasi Selama Project
● Manajemen akses pada sistem
● Kewajiban melakukan backup-restore, archive-retrieve berdasarkan risiko pada
tiap sistem
● Manajemen audit trail
● Periodic Review/ performance monitoring
● Business Continuity plan
● Decommissioning sistem komputer
 Deviation/
Incident Change Management
Functional Risk management Decommissioning
Assessment
Development Release Business Cont.
Review and
IQ/OQ/PQ summary Operational Plan
DevelopmentRelease
testing and Use Backup- Restore
Qualification Archive-Retrieve
Functional Supplier
Specification Selection Build Performance Periodic Review
Training SOP
monitoring
Security
Design Traceability
Administration
Specification Software Matrix
Design URS development

Validation Plan
Planning
Business Risk 94
Initial Risk
Assessment
Assessment
 Operational and Use – Backup & Restore

Procedures should be established to cover routine back-up of

Responsibility of process
records, data, and software to a safe storage location ,adequately
owner and system owner
separated from the primary storage location, type and at a frequency
based on risk

Sustainable backup
Successful restore on Backup of software media
short notice include all software
component

Consider media ability to

Backup of data verify, refresh or rewrite
periodically based on risk

95
Operational and Use – Archive and Retrieve

Archiving is the
process of taking
records and data
off-line by
moving them to a
different location
or system , often
protecting them
against further
changes .

96
 Operational
Operational and Use – Change Management change control
(formal)

Fundamental to maintaining the compliant status of systems and

processes. All changes that are proposed during the operational phase of a
computerized system , whether related to software (including middleware),
After start formal testing, or
hardware, infrastructure, or use of the system, should be subject to a formal
else stated in validation plan
change control.
when
Ensure that proposed changes impact and risk are reviewed.
Ensure that changes are suitably evaluated, authorized, documented, tested,
approved and released before implementation and subsequently closed.

Formal control should not be

Change control for introduced too early during Project change
approved Document version development. This including
code change
control
document and history

97
 Operational and Use – Deviation and Incident
Management

Deviation should describe any activities and results that

did not conform to the expectations specified in the plan GMP related
and explain the impact including corrective actions

Incident Management is to ensure that any unplanned

issues that could impact patient May not
safety, product quality, and data integrity are addressed directly related
before any harm occurs to GxP

98
 Operational and Use – Periodic Review

Periodic reviews are used throughout the operational life of systems to verify that
they remain compliant with
regulatory requirements, fit for intended use, and meet company policies and
procedures

• Access change
• Action
• Backup and
restore necessary to
maintain
Component • GxP electronic
computer
archiving
system in
• Procedure
validated state
• Overall
performance

99
 Operational and Use – Performance Monitoring
preventive maintenance that
obtains performance data that
is useful in diagnosing system
problems
Periodic Review

Change Incident
management Management

Reviewed the need of

extend monitoring and
system state of
validation
User Experience

100
 Operational and Use – Business Continuity
Planning
Risk Assessment Determine hazard possibility and assess the severity such disaster event

Counteract with business strategy for recovery of the system or process

Defined strategy

Identifying process ownership, organizational resource and trigger

Develop strategy for initiation for short –term and long-term/ manual
Where manual processes
are invoked to allow the
Implement Formalized in procedure, note the key contact person business to continue to
operate , consider how
strategy any associated electronic
records or data will be
Rehearsed or tested in several ways, such as through synchronized once the
reviews , brainstorming, testing of sections of the plan, electronic systems have
Tested or re-installation of servers , switching to hot sites, and full been restored.
testing
rehearsed
If disaster recovery, RPO RTO should stated based on 101
risk
 Operational and Use – Security Administration

System administrator Intrusion detection Physical security

access user akses method

Anti-virus policies Connectivity to System access

external system security

Shared network Use of mobile Password

computing management

Third party access Internet access and Electronic messaging

use system

102
 Operational and Use – Decommissioning

Documented through Planned and reviewed

yang perlu diperhatikan adalah data-datanya

change management

E-Record retention, Data Migration and

Identification of verification
current SW, HW and
interface Responsibilities

Data Erasure Document related to

support system

Execution Reporting
103
POST-TEST!
https://s.id/csvtest

104
THANKS! https://s.id/absencfi

Any final questions?

105
Key Take Away

▰ CSV is Risk Based Approach from Planning,

Design, Build, Qualification and Operational
▰ Risk based critical thinking will minimize
validation effort
▰ CSV is the collaboration of many personnel
▰ Supplier selection is essential and internal IT
should be analogous
▰ Electronic Record is part of CSV which need to
be planned and tested
106
PT CSV Farma Indobuana
Jl. Bhineka Permai Blok T No. 4
RT. 009 RW. 012
Kel. Mekarsari, Kec. Cimanggis
Kota Depok, Jawa Barat 16452
Indonesia OUR OFFICE

T: +62 812 1045 2982 / +62 813 8258 9383

E : cs@cfi.co.id
W : cfi.co.id

107