Smartlogic

ולידציה – GAMP-Test Execution

GAMP- Good Automated Manufacturing Practice -Test Execution

After a test is written, reviewed, perhaps rewritten, and finally approved, it is then ready for execution.

Before commencing GAMP  tests using individual Test Cases or Test Scripts, pre-requisites for the test phase should first be verified and recorded. For example:

  • Test environment hardware (HW) (e.g., serial numbers and calibration certificates if required)
  • Test software (SW) (e.g., SW baselines)
  • Data sets
  • User accounts
  • Personnel involved (e.g., documentation of names, positions and sample signatures and initials)
  • Availability of baselined documentation (including, most critically, Test Documentation and Procedures)
  • Where applicable, calibration of critical instrument inputs

Manual Test Execution

Tests should be carried out as follows:

  • Any pre-requisites for the test should first be checked, as indicated above.
  • The test is then executed following the test instructions given within the Test Script.
  • Each test should be run and the test data collected as test results.
  • The tester decides whether the acceptance criteria have been met and records whether the test has passed or failed, and then signs and dates the test results. Sometimes, a third category 'refer for review', or 'conditional pass', or 'pass with observation' is used for cases where the tester feels that an independent opinion is required.
  • Supporting documentary evidence required by the Test Case or Test Script should be collated.
  • If an incident occurs, it should be recorded on a test incident sheet (or within the test incident system) and retained as part of the test record. The key to dealing with incidents during Test Script execution is to accurately record the incident and retain sufficient information to help with future problem solution.
  • It is helpful to maintain a test progress summary for recording overall test results and number of test runs. Depending on the company test policy, this summary may be regarded purely as a status and scheduling tool, or may form part of the post-execution review, and may be included in the Validation Report as a GxP document.
  • After completion of all tests or a group of tests (e.g., at the end of the day), there should be a review of the progress. A review group should assess all tests and incidents.

Possible actions for failed tests and incidents are:

  • Repeat the test.
  • Apply a change via change control and, if necessary, repeat the test.
  • Abandon one, several, or all tests.
  • Review the result, and upgrade it to a 'pass' status (with a record of the rationale for the change in status).

The review group should decide which course of action  to take and what retesting is required, and document the justification for the action(s). In my next post I will elaborate more on: Automated Test Execution (and Computerized Test Management Tools).

 

תיקי ולידציה – מושגים כלליים

ולידציה –  מושגים כללים ועקרונות הכנת תיקי ולידציה

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

ולידציה מקושרת בד"כ עם מתקן יצור של מוצר שאיכותו עשויה להשפיע על בריאות הציבור, ולכן היא מיועדת לצמצם למינימום את אפשרויות הסיכון הפוטנציאליות שעלולות להשפיע לרעה על איכות המוצר
תהליך הולידציה חייב לעמוד בתקנים של המנהל האמריקאי FDA. התקנים הרלוונטיים ביותר לתהליך הולידציה הם:
• Good Manufacturing Practice   –  GMP
• Current Good Manufacturing Practice –  cGMP
• Good Automated Manufacturing Practice  –  AMP.
במונח GxP משתמשים יותר בחופשיות בז'רגון הולידציה בהתייחסות לאוסף כללים מנחים.
cGMP הוא הדוגמה הנפוצה ביותר של GxP. עמידה בתקני cGMP מבטיחה אחידות, עוצמה, איכות וטוהר של מוצרים רפואיים ע"י דרישות מיצרני התרופות לבקרה הולמת על תהליכי היצור שלהם.
תקנים נוספים של ה- FDA הרלוונטיים לתהליך הולידציה הם:
• Good Laboratory Practice –  GLP.
• Good Clinical Practice –  GCP.
תהליך ולידציה כולל תכנון, התקנת והפעלת מערכת ניטור ובקרה במתקו יצור, וכמו כן, תכנון וביצוע תהליכי בדיקה כדי לוודא שמערכת הניטור והבקרה עומדת בסטנדרטים של ה- FDA.
תיעוד ולידציה הינו חלק של תהליך הולידציה שמכיל רישומים כתובים ו/או אלקטרוניים ביחס להתקנה והפעלת מערכת הניטור והבקרה, וביחס לבדיקות המתאימות של אותה מערכת.
הרישומים האלקטרוניים נדרשים בד"כ לעמוד בדרישות FDA שמתייחסות להיקף וישום של התקן
Part 11 of Title 21 of the Code of Federal Regulations; Electronic Records; Electronic Signatures – 21 CFR Part 11.
רישומים אלקטרוניים –  Electronic Records יכולים להכיל כל שילוב של מלל, גרפיקה, אודיו, צילומים, או כל מידע אחר המוצג באופן אלקטרוני, כאשר אלו מיוצרים, משתנים, מתוחזקים, מתויקים, מוחזרים ומופצים ע"י מערכת מחשבים.
חתימות אלקטרוניות – Electronic Signatures יכולות להכיל אוסף של כל סמל או סדרת סמלים מבוצעים, מאומצים או מאושרים ע"י גורם שמחויב חוקית באופן שווה ערך לחתימתו בכתב.
משתמשים ברישומים וחתימות אלקטרוניים בד"כ במערכות סגורות, בהן הגישה למערכת מבוקרת ע"י צוות אחראי על התכנים של הרישומים האלקטרוניים.

  תכולת תיקי ולידציה – ולידציה –  מושגים כללים

תיקי ולידציה מכילים באופן כללי שני סוגי מסמכים:
• מסמכים קשורים לתכנון, התקנת והפעלת מערכת הניטור והבקרה:
– ספציפיקציה נדרשת ע"י המשתמש  User Requirements Specification  – URS
– ספציפיקציה של דרישות פונקציונאליות  Functional Requirements Specification -FRS
– ספציפיקציה של תכנון פונקציונאלי  Functional Design Specification – FDS
– ספציפיקציה של תכנון חומרה  Hardware Design Specification – HDS
– ספציפיקציה של תכנון תוכנה  Software Design Specification – SDS
– שרטוט צנרת ומכשור  Piping and Instrument Drawing – P&ID
– רשימת כניסות/יציאות  Input/Output (I/O) List

• מסמכים שכוללים את תהליכי הבדיקות:
– פרוטוקול קווליפיקצית התקנה  Installation Qualification (IQ) Protocol
– פרוטוקול קווליפיקצית פעולה  Operation Qualification (OQ) Protocol
– פרוטוקול קווליפיקצית ביצוע  Performance Qualification (PQ) Protocol

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

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

הסבר כללי על השימוש ב 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% מהלקוחות מעדיפות לא להשתמש בחתימות דיגטליות.