Project Plan & Validation Plan dibuat pada saat awal proses validasi (setelah dokumen HLRA/ HLCD dan dapat dibuat bersamaan dengan URS & Supplier Assessment). Project Plan & Validation Plan menggambarkan strategi keseluruhan dari proses validasi yang akan dilakukan, dokumen validasi yang akan digunakan, kontrol terhadap proses validasi dan deskripsi tanggung jawab tim dan pihak-pihak yang akan terlibat dalam proses validasi. Project Plan dan Validation Plan dapat digabung untuk menghindari duplikasi, tapi biasanya untuk proyek skala besar Project Plan dan Validation Plan dibuat terpisah. Untuk instalasi aplikasi dekstop atau alat lab/ non lab, cukup gunakan Validation Plan sebagai acuan untuk menentukan tahapan apa saja yang perlu dilakukan dalam melakukan proses validasi. Validation Plan menjadi salah satu acuan kriteria apakah proses validasi yang dilakukan sudah sesuai dan sistem dapat digunakan.
User Requirements Specification (URS)
User Requirements Specification (URS) merupakan dokumen perencanaan yang menggambarkan kebutuhan bisnis terhadap sistem yang dibutuhkan oleh pengguna. URS dibuat pada awal proses validasi ketika bisnis atau pembelian sistem direncanakan. URS dibuat oleh pemilik sistem dan pengguna untuk menentukan kebutuhan spesifik dari sistemnya terhadap kebutuhan bisnisnya, dengan masukan dari pihak Quality Assurance. Persyaratan yang diuraikan dalam URS biasanya diuji pada Performance Qualification (PQ) atau User Acceptance Testing (UAT). Usahakan URS dapat dipahami oleh pembaca dengan tingkat kemampuan umum.
Quality Risk Assessment
Purpose of Risk Assessment
The purpose of the risk assessment process is to ensure that the validation (quality) effort is directed at the systems that have the potential to impact product quality, efficacy and data integrity (throughout this article referred to as Product Quality).
Initial Risk Assessments
In the ISPE Commissioning and Qualification Guide the approach to an initial impact assessment was first introduced. This was designed to ensure that only systems that have the potential to impact product quality require formal validation.
The impact assessment process had selections.
Direct Impact - A system that is expected to have a direct impact on product
quality.
Indirect Impact - A system that does not have a direct impact on product quality
but is linked to / supports a direct impact system.
No Impact – A system that does not have the potential to have an impact on
Product Quality and is not linked to or support a direct impact system.
Only systems that have a Direct Impact on Product Quality require full formal validation. Where systems are identified as Indirect Impact then the interfaces to the Direct Impact System should be considered. No Impact systems do not require formal verification and should be installed following Good Engineering Practices (GEP).
While this impact Assessment provides guidance as to what systems require validation it does not support the level of validation required. At the early stage of the process a Risk Assessment can support the approach and level of software validation required.
Computer System Risk Assessment
GAMP 5 supports the approach of performing an initial risk assessment to determine:
What are the risks to the business
System GxP Determination
What is the overall impact of the system
Determine if more risk assessment are required
This provides the impact assessment and some planning. However even at the early stage of the project a simple risk assessment can provide guidance to the Computer Systems Validation requirements, based on
Product Quality / GMP Impact
Complexity of the Process
Stability of the Software (GAMP Category)
From the combination of these items a number of recommendations can be made. This includes
Supplier Audit requirements
Software development controls (e.g. Source Code Review)
Design Documents (Functional Design Specification, User Manuals, etc)
Further risk assessment (Component Assessments, FMEA, etc)
Test Documentation
These recommendations as to the validation requirements can be automated in a spreadsheet, based of a combination of the Impact, Complexity and GAMP category.
In future posts I will provide examples of this Impact / Risk Assessment process for computerised systems. If there are any specific examples that you would find useful then please post them within the comments.
The purpose of the risk assessment process is to ensure that the validation (quality) effort is directed at the systems that have the potential to impact product quality, efficacy and data integrity (throughout this article referred to as Product Quality).
Initial Risk Assessments
In the ISPE Commissioning and Qualification Guide the approach to an initial impact assessment was first introduced. This was designed to ensure that only systems that have the potential to impact product quality require formal validation.
The impact assessment process had selections.
Direct Impact - A system that is expected to have a direct impact on product
quality.
Indirect Impact - A system that does not have a direct impact on product quality
but is linked to / supports a direct impact system.
No Impact – A system that does not have the potential to have an impact on
Product Quality and is not linked to or support a direct impact system.
Only systems that have a Direct Impact on Product Quality require full formal validation. Where systems are identified as Indirect Impact then the interfaces to the Direct Impact System should be considered. No Impact systems do not require formal verification and should be installed following Good Engineering Practices (GEP).
While this impact Assessment provides guidance as to what systems require validation it does not support the level of validation required. At the early stage of the process a Risk Assessment can support the approach and level of software validation required.
Computer System Risk Assessment
GAMP 5 supports the approach of performing an initial risk assessment to determine:
What are the risks to the business
System GxP Determination
What is the overall impact of the system
Determine if more risk assessment are required
This provides the impact assessment and some planning. However even at the early stage of the project a simple risk assessment can provide guidance to the Computer Systems Validation requirements, based on
Product Quality / GMP Impact
Complexity of the Process
Stability of the Software (GAMP Category)
From the combination of these items a number of recommendations can be made. This includes
Supplier Audit requirements
Software development controls (e.g. Source Code Review)
Design Documents (Functional Design Specification, User Manuals, etc)
Further risk assessment (Component Assessments, FMEA, etc)
Test Documentation
These recommendations as to the validation requirements can be automated in a spreadsheet, based of a combination of the Impact, Complexity and GAMP category.
In future posts I will provide examples of this Impact / Risk Assessment process for computerised systems. If there are any specific examples that you would find useful then please post them within the comments.
GAMP 5
GAMP® 5 provides pragmatic and practical industry guidance to achieve compliant computerized systems fit for intended use in an efficient and effective manner. This technical document describes a flexible risk-based approach to compliant GxP regulated computerized systems, based on scalable specification and verification. It points to the future of computer systems compliance by centering on principles behind major industry developments such as PQLI; ICH Q8, Q9, Q10; and ASTM E2500.
This revolutionary Guide addresses the entire lifecycle of an automated system and its applicability to a wide range of information systems, lab equipment, integrated manufacturing systems, and IT infrastructures. It contains new information on outsourcing, electronic batch recording, end user applications (such as spreadsheets and small database applications), and patch management.
Apa itu Validasi?
What is Validation?
Process validation is defined as:
Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specification and quality attributes [FDA Process Validation Guidelines, 1987].
This definition was modified by the PDA for a computerised system:
Establishing documented evidence which provides a high degree of assurance that a specific computer-related system will consistently produce a product meeting its predetermined specifications [PDA Technical Report 18, Validation of Computer-Related Systems, 1995].
The key concepts in the last definition above are:
Documented evidence;
High degree of assurance;
Predetermined specification
There are other regulatory or quality guidelines from the European Union and the Organisation for Economic Development. Each regulation may have slightly different requirements but all come down to the same series of requirements: in general, validation is concerned with generating the evidence to demonstrate that the system is fit for the purpose you use it for and continues to be so when it is operational and that there is sufficient evidence of management control. This usually means that an action must be documented. Another feature of validation is to produce an auditable system; having the appropriate documentation to aid any audit or inspection.
The problem is how to respond to the requirement for computer validation. Any response should be:
Scientifically sound
Structured
Provide adequate compliance
Reflect the way you use the application
This latter point is most important, there is no point validating a function of a system that is not used.
Equally important, is the fact that one organisation’s use of an application can be markedly different from another’s use of the same software.
Computer validation must provide confidence in the system first and foremost to management and the users, secondly to an internal quality audit and thirdly to an external inspector. Inspectors only audit an organisation on a periodic basis; all others work in the organisation and use its computerised systems daily. The users must have the confidence in a system above all others, otherwise your investment will be wasted.
Apa itu Validasi Sistem Komputer?
Validasi Sistem komputer (terkadang disebut Computer System Validation atau CSV) adalah proses pendokumentasian, bahwa perangkat sistem komputer telah memenuhi persyaratan berdasarkan kebutuhan yang telah ditentukan. Fungsi dari Validasi Sistem Komputer adalah untuk memastikan akurasi, kehandalan, konsisten dan kemampuan untuk membedakan catatan yang tidak valid atau dapat diubah adalah persyaratan yang penting dari compliance untuk catatan elektronik, seperti yang dijelaskan di FDA 21 CFR 11,10 (a) dan EMA Annex 11, Bagian 4 .