Smartlogic

Menu

תגית: FDA

ולידציה – 3 Validation case study – part

Posted on by אביב צברי

ולידציה – 3 Validation case study – part

 This article was written by Iian Shaya, validation,automation and control expert

אילן שעיה Ilan Shaya
Ilan Shaya CEO , control and automation specialist and designer

Documentation for IQ and OQ – to be checked at PDI/FAT

Welding reports

Surfaces finishing test reports

PDI and FAT results

As-built drawings, 3 sets in nominated project language, plus 1 set in English

As-installed versions of all documentation submitted for design review

Back-up software on diskette/CD-ROM, as appropriate, ready for re-installment

Machine configuration/start up, set-up and commissioning data, including tabulation of all change parts and identifications

Full machine parts list

Complete documentation (protocols and method statements) required for equipment DQ, calibration, IQ and OQ specified for manual and automatic operations

Calibration certificates for all required instruments to NIST

Specification for all parts manufactured by sub-contractors

Full identification of all parts according to the P&ID, including valves, regulators, instruments, pipes, media and flow direction arrows

Tags for electrical and pneumatic wiring

Documentation to ensure qualification in compliance with FDA and EMEA, as outlined above

DQ Protocols Including PC/PLC

Approval

Statement of purpose

System description

Traceability matrix

IQ Protocols Including PC/PLC

Approval

Statement of purpose

System description

Specifications

Materials in product contact

Engineering drawings

Subsystem inspection

Components

Piping

Valves

Instrumentation and calibrations

PC/PLC requirement definition

Software development documentation

Manual / technical literature

Test equipment data sheet

Component data sheets

Utility requirements

Exceptional conditions, if required

Summary

OQ Protocols Including PC/PLC

Statement of purpose

System description

Manual and automatic control over all modules through HMI

PC/PLC validation protocols

Step-by-step checking of schedule of system operation – SSO

Alarm and message reaction

HMI synoptic screen vs. P&ID

System operation tests

Operation tests for HMI to ensure compliance with 21 CFR part 11

Application software certification

HW documentation

SW code

SW components data sheets

HW components data sheets

PLC configuration

Graph printout

Synoptic screen list and printout

Operation screen list and printout

Parameters list screen

Messages and alarms list, and printout

HW inspections

SW inspections and application

Approved schematic description

Ladder diagram validation

PLC capabilities

PLC accuracy

SW development documentation

List of control devices

Exceptional conditions

Reports – verification of authorization inspection

PQ Protocols Including PC/PLC

Statement of purpose

Analysis procedures

Staff instruction

Plan for sampling

Criteria for acceptance

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – Validation case study – part 2

Posted on by אביב צברי

ולידציה – Validation case study – part 2

 This article was written by Iian Shaya, validation,automation and control expert

Validation Requirements

Documentation for Initial Tender

Project schedule and milestones design and construction detail

Project quality plan

Supplier’s local subsidiary/agent

Supplier’s documentation that the system / configurable software versions are released to the market and are FDA/EMEA compliant

Compliance to the 21 CFR Part 11 operational requirements – the contractor should ensure covering of all the requirements described below

Contractor to state the system/product status and implementation planned for each requirement – User's approval pre-delivery

Documentation for Design Review

PID for the system

Electrical and pneumatic schematics

:Installation data

General arrangement drawings

Floor loading

Utility requirements

Details of electronic records and approvals that may be subject to regulatory controls under CFR Title 21 part 11

Instrumentation documentation

:Main components specification

Equipment

Instrumentation

Valves

Piping

Control system

Pipe welding documentation

General installation book

Procedures

User guide

Security

Preventative maintenance + spare parts list

Operation procedure

Pressure test procedure

Leak test procedure

Passivation procedure

Calibration

:Functional Design Specifications for

Complete manufacturing system

Software – SW and hardware –HW

Functional Design Specifications

System Detail Design Specifications for HW and SW.

SW source code, with comments, for customized SW

SW complete version history

HMI alarm list, message list and graphical displays

I/O list

:List of materials

Product contact materials

Potential product contact lubricants

Welding procedures for product direct and indirect contact parts

Pre-delivery Inspection and Factory Acceptance Test (FAT) protocols

Steel certificates and gasket certificates

Documentation Prior to FAT or Pre-Delivery Inspection – PDI

:Progress visit report which will include

Mechanical and technical development

Automation and SW development

:Supplier’s factory test results for

Unit tests – The test protocols shall be traced to low level design document and will be approved by the user prior to execution. The approval of the report shall be performed by representatives of the user's validation team, IT QA.

Automation and SW development

:Integration Tests  – Simulation Testing

Approved PDI and FAT protocols

Commissioning

MCCR

Purpose

Scope

Responsibility

Execution instructions

System scope

System description

Drawing verification

Equipment verification

Valve verification

Instrument installation and calibration

Utility verification

Documentations verification

Piping Verification

Sample Point Verification

Safety, health and environment verification

Slopes verification (if relevant)

Electrical and communication activities

Pump installation verification, if relevant

Heat exchanger installation verification, if relevant

Air break verification, if relevant

Dead leg verification, if relevant

CE

Purpose

Scope

Responsibility

Execution instructions

System scope

System description

System startup

Equipment verification

Main equipment operation checks

System FDS (SSO) verification

System performance testing

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – FRS – Regulatory & HMI Requirements

Posted on by אביב צברי

ולידציה – FRS – Regulatory & HMI Requirements

 This article was written by Iian Shaya, validation,automation and control expert

Regulatory Requirements

These requirements cover all the FDA specifications regarding the system compliance with the 21 CFR Part 11 definitions, and also with usual validation documentation demands

Method to provide a computerized system that complies with 21 CFR Part 11 definitions, such as the system access control by the user's managing personnel, who shall be responsible for the content of the electronic records (ERs) contained in the system

Method to restrict logical access to the system according to specified authorization levels

Method to restrict logical access to the system only to specific user ID and password

Method to provide system capability to record the values, alarms, user changes and any other events, and provide readable forms and reports of ER data

Method to allow storage of historical events, current alarms and historical alarms data records on the computerized system database

Capability of data display to the user in "view only" mode, so the user cannot alter or delete data/records

Provision of user's capability to backup data daily, weekly and monthly, according to his procedures, to ensure protection of the records and to enable their accurate and ready retrieval throughout the records retention period

Provision by the supplier of a project plan and quality assurance (QA) processes during development and the testing stages as part of his QA systems

Provision by the supplier of the following documents

Functional Requirements Specification – FRS

Functional Design Specification- FDS

IO List

Schedule of System Operation – SSO

Installation Qualification (IQ) protocol

Operation Qualification (OQ) protocol

Performance Qualification (PQ) protocol

HMI Requirements

These requirements are intended to provide the URS demands from the HMI screens, regarding proper graphic design and functionality for controlling and monitoring the system, as specified in customer's contract with the supplier. The HMI screens provided usually are of the following types

Main Screen

Synoptic screens for displaying online values and status

Parameters screens for displaying temperature, humidity and pressure parameters values

Data logging and storage of historical trends, alarms and events

Tabular screens for displaying alarms

Graphical screens for displaying trends

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – URS – Regulatory & HMI Requirements

Posted on by אביב צברי

ולידציה – URS – Regulatory & HMI Requirements

 This article was written by Iian Shaya, validation,automation and control expert

Regulatory Requirements

These requirements cover all the FDA specifications regarding the system compliance with the 21 CFR Part 11 definitions, and also with usual validation documentation demands

Computerized system compliance with 21 CFR Part 11 definitions, such as the system access control by the user's managing personnel, who shall be responsible for the content of the electronic records (ERs) contained in the system

System capability of restricting logical access to the system according to specified authorization levels.

Access to the system allowed only by user ID and a specific password

System capability to record the values, alarms, user changes and any other events, and provide readable forms and reports of ER data

Storage of historical events, current alarms and historical alarms data records on the computerized system database

Data display to the user in "view only" mode, so the user cannot alter or delete data/records

Provision of user's capability to backup data daily, weekly and monthly, according to his procedures, to ensure protection of the records and to enable their accurate and ready retrieval throughout the records retention period.

Provision by the supplier of a project plan and quality assurance (QA) processes during development and the testing stages as part of his QA systems

Provision by the supplier of the following documents

Functional Requirements Specification –FRS.

Functional Design Specification – FDS

IO List

Schedule of System Operation – SSO

Installation Qualification (IQ) protocol.

Operation Qualification (OQ) protocol

Performance Qualification (PQ) protoco

HMI Requirements

These requirements cover the provisions demanded from the HMI screens, regarding proper graphic design and functionality for controlling and monitoring the system, as specified in customer's contract with the supplier

:Note

The final contents of the URS and FRS are tailored according to the type and size of the system under validation. Since the URS and FRS regarded herein are generic, they include requirements that may not be necessary in small or simple systems

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – URS and FRS Preparation Overview

Posted on by אביב צברי

ולידציה – URS and FRS Preparation Overview

 This article was written by Iian Shaya, validation,automation and control expert

User Requirements Specification (URS) and Functional Requirements Specification (FRS) are the first and starting points of a validation process and a validation documentation file

  – The validation process must comply with regulations issued by the United States Food and Drug Administration FDA

:The FDA regulations that are most relevant to the validation process are

Good Manufacturing Practice  – GMP.

Current Good Manufacturing Practice – cGMP

Good Automated Manufacturing Practice – GAMP

The validation process includes design, installation and operation of a monitoring and control system for a production facility, as well as planning and execution of test procedures, to verify that a monitoring and control system meets the FDA standards

Validation documentation is part of the validation process that includes written and/or electronic records regarding the installation and operation of the monitoring and control system, and the corresponding test procedures for this system

Electronic records are often required to fulfill regulations set by the FDA. These regulations regard the scope and application of Part 11 of Title 21 of the Code of Federal Regulations; Electronic Records; Electronic Signatures (21 CFR Part 11). Electronic Records may contain any combination of text, graphics, audio, pictures, or other information represented in electronic form, which are created, modified, maintained, archived, retrieved or distributed by a computer system

Electronic Signatures may contain computer data compilation of any symbol or series of symbols executed, adopted or authorized by an individual to be legally binding equivalent of the individual's handwritten signature

Electronic records and signatures are generally used in Closed Systems, in which the system access is controlled by personnel responsible for the contents of the system electronic records

The responsibility for writing and approving the URS and FRS is shared in practice by the user, who operates the production facility, and the supplier or vendor, who provides the monitoring and control system for ensuring the proper operation of the production facility. Usually, the URS is written by the user and the FRS by the supplier

:Note

The final contents of the URS and FRS are tailored according to the type and size of the system under validation. Since the URS and FRS regarded herein are generic, they include requirements that may not be necessary in small or simple systems

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – Installation Qualification (IQ) Protocol – 2

Posted on by אביב צברי

Installation Qualification (IQ) Protocol

Preparation Overview – part 2

 Installation Qualification (IQ) Protocol –  Test Procedures

This chapter contains all the test procedures or verifications required to verify the system under validation is properly installed and can be properly operated according to the supplier's requirements and user's specifications.

Each test procedure or verification must include the same contents:

Purpose or Objective

Procedure or Method

Acceptance Criteria

Test Results

The next sections provide overviews of the main test procedures and verifications, and their purposes. This IQ procedure is generic, and relevance of the test procedures and verifications provided below depends on the composition of the system under validation.

Note:

As mentioned in the previous chapter on IQ Protocol Contents, the final contents of the IQ protocol are tailored according to the type and size of the system under validation. Since this document is generic, it covers test procedures that may not be necessary in small or simple systems.

Drawings Verification

This procedure is intended to obtain signed, updated copy of the user's Piping and Instrumentation Drawing (P&ID), and verify that the drawing is accurate.

 Site Preparations

This procedure is intended to verify that the system under validation is installed and operated under environmental conditions, in particular temperature conditions, which comply with the manufacturer’s requirements.

                          Hardware Installation Test Procedures

  Voltage Supply

This procedure is intended to verify that the voltage supplied to the system components complies with the design requirements.

 IO List

This procedure is intended to verify that the system components are identified and installed in compliance with the IO List, the P&ID, and the system hardware requirements.

                        Software Installation Test Procedures

This section describes the test procedures for the installation of purchased software (SW) and application SW. These test procedures are relevant when the supplier installs these SW systems.

Supplier Installed Software

This procedure is intended to verify that purchased SW installed in the supervisory computer and control system (where relevant) by the supplier complies with the SW design requirements.

 Other Purchased Software

This procedure is intended to verify that other purchased SW, such as a version of Windows, is correctly installed on the system.

  Application Software

This procedure is intended to verify that the custom application SW is installed according to the design requirements.

 Closed System Verification (Where Relevant)

This procedure is intended to verify that the system is closed, i.e., it cannot communicate with Internet networks.

Glossary

CFR Code of Federal Regulations
FDA Food and Drug Administration
FRS Functional Requirements Specification
HW Hardware
IQ Installation Qualification
OQ Operational Qualification
QA Quality Assurance
SSO Schedule of System Operation
SW Software
URS User Requirements Specification

תקן 21CFRPart11 – הסבר כללי על קצה המזלג

Posted on by אביב צברי

הסבר כללי על השימוש ב 21CFRPart11

ראשית דבר נרצה לחשוף את הקוראים המבינים יותר והמבינים פחות למושג ה-CFR. מה זה בעצם CFR? תקן 21CFRPart11 הוא קיצור של Code of Federal Regulation, מכיל בתוכו את מערכת החוקים של מדינת ארה"ב ומחולק ל 50 כותרים ( Titles) כדוגמת:

Title 16: Commercial Practices, Title 17: Commodity and Securities Exchanges ,Title 18:   Conservation of Power and Water Resources etc…

בהקשר לעניינו CFR-21 הוא קובץ הנחיות המתייחס לרישומים האלקטרוניים והחתימה האלקטרונית במערכות אוטמציה ובקרה. תעשייני הפארמה מכירים את קובץ הנחיות זה טוב מאוד והוא משמש כמרכיב עיקרי במלאכת הולידציה של מערכות מפוקדות. קיימים מס' חברות בקרה בארץ אשר מספקות שירותי ולידציה אשר מתמחות בסעיף זה, אחת מהמובילות בתחום היא חברת סמארט לוג'יק.

כפי שנאמר קודם 21 CFR PART 11 מכיל חוקים למערכות ממוחשבות בכל הנוגע ל FDA. תפקידו העיקרי- להמנע בשימוש בנייר, על ידי הסתמכות על המערכת הממוחשבת.

למה אנחנו צריכים את זה?

בכדי להיות שחקן בזירת השוק המזון והתרופות האמריקאי אחת הדרישות ההכרחיות היא הוכחת קיום הדרישה על ידי מערכת הקרה הממוחשבת. בכדי להוכיח את קיום דרישות אלה המערכת לעבור סדרה של בדיקות איכות במסגרת תהליך "אימות"-ואלידציה. ניתן לראות באיור המצורף דוגמא סכמתית לתהליך הואלידציה.

חשוב להבין את מהות הואלידציה, המרת המערכת לתמיכה בסעיף 21 CFR 11 לכשעצמה אינה מספיקה. בכדי שהמערכת תהיה בעלת אישור ה-FDA יש לצרף למערכת את תיק הולידציה לאות הוכחה והכרה.

הדרישות הבסיסיות להכרה ב- CFR 11 היא בחירה במערכת ממשק משתמש תומכת, פיתוחה על ידי שימוש בכללים המופיעים בתקן וכאמור ביצוע ואלידציה וצירוף תיק הואלידציה עצמו.

 

כמו בצבא, ניתן לחלק את סדרת התקנות לשלושה חלקים:

Sub-Section a – הגדרות כלליות

החלק הראשון מתייחס להגדרות כלליות,  השני לרשומות אלקטרוניות והשלישי לחתימה אלקטרונית.

החלק הראשון מכיל תת סעיפים אשר מפרטים את היקף המסמך ( Scope 11.1) מה דרוש ליישום ( Implementation 11.2) והנחיות והגדרות לשימוש בו ( 11.3 Definitions).

בין הסעיפים העיקריים: מה נחשב לרשומה אלקטרונית ומה נחשב לביומטריה.

רשומה אלקטרונית ( Electronic Record): כל שימוש בטקסט, גרפיקה, נתונים, שמע, או כל ייצוג מידע אחר בצורה דיגיטאלית שנוצר על ידי מערכת מחשב.

חתימה אלקטרונית (Electronic Signature): סימן או רצף של סימנים אשר בעזרתם ניתן לקשור את החותם , ובעזרתה יכולה להחליף חתימה בכתב יד.

חתימה דיגיטלית (Digital Signature): חתימה אלקטרונית המבוססת על שיטת הצפנה ואשר מקיימת את סט החוקים שנקבעו על מנת שתהיה מאושרת בעזרתה ניתן לאמת את החותם ואת אמינות הנתונים.

שתיים מההגדרות הקריטיות המוזכרות בחלק זה אשר רלוונטיות לעמידה בתקן 21CFRPart11 הן הגדרות המערכת הסגורה והפתוחה.

מערכת סגורה: סביבה שבה הגישה אליה מבוקרת באמצעות אדם אשר אחראי לרשומות האלקטרוניות שנמצאים במערכת.

מערכת פתוחה: סביבה שבה הגישה אינה מבוקרת באמצעות אדם אשר אחראי לרשומות האלקטרוניות שנמצאים במערכת.

Sub-Section B – Electronic Records – רשומות אלקטרוניות

 החלק הטכני והאופרטיבי  – מה דרוש על מנת שהמערכת תהיה מאושרת. ההנחיה הראשונה מתייחסת להנחיה לביצוע, לאמור  סט של פעולות אשר יבטיחו את אמינות הנתונים ואמינות החותם על מנת שלא יוכל להתכחש לפעולותיו.

התת תקנה הראשונה  (a ) מתייחסת לאימות של המערכות עצמם, או יותר נכון על הצורך באימות. אין זה מספיק שהמערכת תענה על דרישות התקן עצמם אלא יש צורך בהבאת הוכחה דרך תיק ואלידציה אשר יכיל את נתוני עמידת המערכת בתנאים דרך סט של בחינת התקנה וביצועים איכותית.

תת תקנה (b ) מתייחסת לכך שהמערכת חייבת להיות בעלת יכולת ייצוא הרשומות בצורה קריאה דהיינו יכולת הדפסה, מערכת דוחות או גרפים אשר ביכולתם לייצא את הנתונים בצורה מדוייקת (שכפול אחד לאחד) לצורך בדיקה של הרשות.דרישה זו היא גם דוגמה טובה לכך שהתת תקנות אינם באות רק להקשות על בעל המפעל אשר פניו לאישור המערכת שלו אלא גם מבטיחות ייצור אחראי ומבוקר אשר ללא משאיר מקים לספקות בנוגע לביצועי אמת של המערכת והתהליך.

תת תקנה ( c ) מתייחסת לכך שעל המערכת קיימת הדרישה לא רק להציג את הרשומות אלא גם להוכיח שהרשומות מוגנות, קיימת אפשרות לאחזר הנתונים ושלא ניתן לגשת אל המידע משום מקום אחר. במילים אחרות להוכיח את שרידות הנתונים ולהראות שבכל שלב ניתן לאחזר את הנתונים.

תת תקנה ( d ) מתייחסת להגבלות המערכת על המשתמשים לפי רמות הרשאה. על מנת לוודא את אמיתות מסד הנתונים של המערכת, עליה להיות גם בעלת יכולת ניהול הרשאות מסודר ומתועד ושכל רמת הרשאה תהיה מוגבלת בביצוע מה שיושם לה. ניתן ליישם את דרישה בקלות לפי השימוש במושג 'טבלאת אמת' אשר תסכם את היררכיית חופש הפעולה של סוגי המשתמשים.

תת תקנה (e ) מתייחסת למושג מאוד מרכזי בעולם הואלידצה הלוא הוא ה- Audit-trail ,בפירוש חופשי וכללי של מושג זה ניתן להגדירו לפי הדרישה אשר אומרת כי כל רשומה אשר נעשתה במערכת חייבת להיות מעוגנת בתאריך אוטומטי. כל שינוי, עדכון, מחיקה של רשומה על ידי מפעיל חייבת להיות מתועדת. כמו כן יש לוודא ששינויים חדשים לא ימחקו את התיעוד של השינויים הקודמים. סעיף זה הוא קריטי ביותר לואלידציית המערכת במובן הזה שהוא לא משאיר כל מקום לאי ודאות, לכל שינוי ערך או הרמת התראה יש פירוט ואין החסרה של נתונים הן מהמפעילים והן מאיש הביקורת. רק בכדי להדגים את חשיבות התקנה, על מסד הנתונים לאפשר שחזור נתונים של עד 7 שנים אחורה.

מעבר לדרישת הגנת הרשומות, תת חלק 2 מתייחס גם לצורך שהמערכת תגיב אוטומטית על מנת לדאוג שהתפ"מ המורשה יעבוד כמתוכנן. תת תקנה (f) באה לאמר שמעבר לפעילות התקנית של מערכת הבקרה, עליה גם להיות בתאימות מלאה למסמכי התכנון המקדימים (FDS (. בדרך כלל, כאשר מדובר בתעשייה התהליכית תת תקנה (f) משחקת שחקן מרכזי בתיק הואלידציה ובתכנון הבקרה עצמה. מעבר לתאימות למסמכי התכנון, יישום תקנה זו בממשק המשתמש גם באה לידי ביטוי בכך שהמערכת תאכוף החלת סיסמאות לכל שינוי וקביעת גבולות נקודות עבודה ריאליות ביחס ל- FDS.

Sub-Section C – Electronic Signatures

תת חלק זה מתייחס לתקנות הנדרשות על מנת שהמערכת תהיה מאושרת לשימוש בחתימות דיגטליות. מאחר והדרישות לבדיקה ארוכות מאוד 99% מהלקוחות מעדיפות לא להשתמש בחתימות דיגטליות.