Smartlogic

ולידציה לנוהל 126 של משרד הבריאות

חברת Smart Logic מומחית בולידציה לנוהל 126 של משרד הבריאות

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

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

תנאי אחסון כלומר תנאי טמפרטורה –

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

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

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

מקרר פרמצבטי לאחסון תרופות Pharmaceutical refrigerator – כנ"ל

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

על פי נוהל 126 למשרד הבריאות על כל מקרר לעמוד בדרישות כדלהלן :

חדרי קירור : מערכת בקרת טמפרטורה שתווסת את פעילות מערכות הקירור בטווח של 20-80 בכל חלל חדרי הקירור.

מערכת ניטור טמפרטורה שתופעל על ידי רגשים עצמאיים ומכוילים שמפעילה מערכת התרעה כאשר ישנן חריגות בטמפרטורת החדר (מתחת ל- 2.50, מעל 70 והתרעה מידית לאנשי מפתח כאשר הטמפרטורה מעל 80).

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

ולידציה אחת ל – 5 שנים

כיול שנתי לרגשי טמפרטורה של מערכת הניטור.

מקרר פרמצבטי לאחסון תרופות Pharmaceutical refrigerator על פי נוהל 126 למשרד הבריאות הקריטריונים הם אותם קריטריונים אבל נוסף קריטריון אחד והוא: חיסונים יאוחסנו באריזות אטומות לאור ודלת החזית של המקררים המיועדים לאחסון  חיסונים חייבת להיות אטומה לאור.

מקרר לאחסון תרופות על פי נוהל 126 למשרד הבריאות יש להתקין במקרר בקר דיגיטלי המאפשר שליטה על הטמפרטורה בין 20-80 . הבקר יכוון לטמפרטורת האמצע או לפי הוראות יצרן.

מערכת לניטור טמפרטורה המחוברת לרגש טמפרטורה עצמאי ומכוייל (הרגש יהיה בעל צג חיווי חיצוני) ובעל רמת דיוק של C0.50±, על פי נוהל 126 למשרד הבריאות, תדירות דיגום אחת ל -15 דקות. שמירת נתוני הטמפרטורה תעשה באמצעות מערכת אחסון פנימית או התקן נייד מסוג data logger.

בעת חריגה בטמפרטורה תהיינה התרעות קוליות או ויזואליות, כמו כן מומלץ על התרעה באמצעות מערכת מסירת הודעות (מתחת ל- 2.50, מעל 70 והתרעה מיידית לאנשי מפתח כאשר הטמפרטורה מעל 80).

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

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

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

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

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

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

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

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

שמירת המסמכים תיעוד נתוני הטמפרטורה ישמר כ-hard copy  או כקובץ מגובה למשך 5 שנים מתאריך הבדיקה כמו כן גם מסמכים הכיול והולידציה. סיכומי חריגת טמפרטורה ישמרו אצל הרוקח האחראי למשך 5 שנים.

 

 

 

לפגישת ייעוץ, אנא התקשרו 08-9102070

 

 

 

ולידציה לנוהל 126 של משרד הבריאות

חברת סמארט לוג'יק מומחית בולידציה לנוהל 126 של משרד הבריאות

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

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

ובקצרה ולרענון הזיכרון מהי ולידציה : ולידציה היא הוכחה מתועדת כי תהליך / ציוד / מערכת / תהליך עומדים בקריטריוני הקבלה והדרישות אשר הוגדרו מראש ותועדו בנוהל מאושר בכל הנוגע ל:

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

 הולידציה נדרשת למגוון תחומים והיא כוללת תעשיות שונות כגון :

כימיה

קוסמטיקה

מזון ותוספי תזונה

מכשור רפואי

תוכנה ומערכות מחשוב

מדעי המחשב

כימיה ואנליטיקה

הנדסה

 

תהליך הולידציה לרוב יכלול את השלבים הבאים:

VP – Validation Plan – תכנית הולידציה

Impact/criticality and risk assessments –  הערכת קריטיות, השפעה וסיכונים

DQ – Design Qualification –  ולידציה תכנון המערכת

IQ – Installation Qualification –  ולידציה להתקנה

OQ – Operational Qualification – ולידציה לפעילות

PQ – Performance Qualification –  ולידציה לביצועי המערכת

PPQ – Process Performance Qualification –  ולידציה לתהליך הייצור

Re-Validation –  ולידציה חוזרת / תקופתית

 

ולהלן פירוט מרכיבי הולידציה (בהתאם לנוהל משרד הבריאות תנאי אחסון והובלה של תכשירים נוהל מספר 126)

 

הסמכת התקנה IQ Installation Qualification

הסמכת התקנה I.Q Installation Qualification באה לאמת את ההתקנה והתצורה של המערכת. ההסמכה יכולה להבטיח כי הקבצים הדרושים הוטענו, הציוד הותקן, ההליכים הדרושים אושרו, והצוות המתאים הוכשר. הדרישות להתקנה נכונה של המערכת הוגדרו במפרט העיצוב. הסמכת התקנה I.Q Installation Qualification חייבת להתבצע לפני השלמת הסמכת פעולה O.Q Operation Qualification. או הסמכת ביצועים P.Q Performance Qualification

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

 

הסמכת פעולה OQ Operation Qualification

השלב הבא הוא הסמכת פעולה Operation Qualification O.Q. בשלב זה, במידה וציינתם כי הציוד מיועד לזמן ריצה בטווח של 50-150 סל'ד ותמשוך כמות מסוימת של כוח, תרצו לוודא כי הציוד עומד בדרישות. אז, בדקו את הפרמטרים האלה ואתגרו אותם. ושוב, וודאו כי הציוד בפועל, פועל בזמן הריצה שהוא אמור להיות.

 

הסמכת ביצועים PQ Performance Qualification

בשלב הסמכת ביצועים  PQ Performance Qualification  אנחנו אוהבים לאתגר את הציוד, כמו בשלב של ה -OQ, אבל בשלב הזה תחת עומס. אמנם זה טוב כי טווח הפעולה הוא בזמן ריצה של ב 50 סל'ד או 150 סל'ד כאשר קו הייצור ריק, אבל עולה השאלה הבאה : מה קורה כאשר יש 300 קילוגרמים של חומר? האם עדיין ניתן להשיג את טווחי המהירות האלו? זו המהות והמיקוד של שלב PQ. לאחר שתשלימו את שלושת השלבים האלה, הציוד זמין לשימוש בכל תהליך שהתכוונת לכך.

פירוט מרכיבי הולידציה

הסמכת התקנה Installation Quafilication, כוללת את הבדיקות הבאות:

  • בדיקת התאמת מרכיבי המערכת לתכנון והתקנתם בהתאם לתכנון ו/או הוראות יצרן.
  • בדיקה לגבי כל המרכיבים אם הם מסומנים ומזוהים כנדרש וכל הרגשים מכוילים

הסמכת פעולה Operation Qualification  כוללת את הבדיקות הבאות:

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

 הסמכת ביצועים  Performance Qualification   כוללת את הבדיקות הבאות:

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

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

 

במהלך תהליך הולידציה נדרשות בדיקות מסוימות והן:

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

דו"ח ולידציה

כמו שהזכרנו לעיל, את תוצאות הולידציה יש לסכם בדו"ח כתוב הכולל את המרכיבים הבאים:

  • היקף ולידציה מנומקת (IQ, OQ, PQ).
  • אישור פרוטוקול.
  • פירוט ציוד נבדק
  • פירוט פרמטרים נבדקים
  • פירוט ציוד הבדיקה ואישור כיולים.
  • אישור הסמכת בודקים
  • תוצאות בדיקות ומדידות שבוצעו

 

הדו"ח יכלול תוצאות מפורטות, ניתוח תוצאות ומסקנות.

 

לפגישת ייעוץ , אנא התקשר אלינו 08-9102070

 

 

 

 

 

 

 

 

Test Incidents – Analysis, Logging & Classification

                   GAMP – Test Incidents – Analysis, Logging & Classification

Incident Analysis and Logging

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

This article was written by Ilan Shaya a world specialist in validation, automation & control

When a test incident occurs during a particular step, the overall test should not be continued if the failure produces an output tat that prevents entry into a subsequent step. When a test continues after following a failure, the failed step should be clearly identified on the test results sheet

It is important to fully record the details of all new test incidents and maintain an index of these incidents

Test incidents may be fed either into an existing change control system or into a separate process for resolving test incidents. An example of an incident report (summarizing details of the incident, proposed solution and retest requirements, review, implementation and closure) is given in GAMP 4, Appendix D6

                    Test Incident Classification

In addition to correcting an identified fault, it is important to evaluate test incidents in order to determine their most likely cause. An important part of any Corrective & Preventive Action (CAPA) process is intended to address this issue. Metrics on the causes of avoidable test incidents provide a useful indicator of areas within the overall SW development life cycle that may benefit from improvement activities, to reduce the likelihood of recurrence.

Typical test incident types that occur in SW testing include, but are not limited, to those described below

              Incorrect SW Installation

Errors such as program dumps, abnormal terminations, or inability to access applications, result often from a failure in the installation or configuration process, or the installation of a wrong SW version

When any of these errors is determined to be the cause of the incident, it is usually necessary to postpone any further testing until the test environment is correctly set up

              Incorrect Programming/Coding

Incidents may result in actual system outputs failing to agree with required system outputs. These incidents should be noted, and, unless the defects are considered sufficiently important to invalidate the rest of the test steps, the execution of the test case can continue

Once the cause of a defect is identified, the defect should be corrected and the corrected SW included in a subsequent SW build for retesting

               Incorrect Test Data

Testing failures may occur as a result of failure to create correct data in the test database, in advance of the test case being run

               Inadequate Specification- Incorrect Understanding of Program Functionality

Testing failures may occur as a direct result of the fact that the controlling Design Specification does not state clearly enough what is required from a particular piece of functionality. This may be particularly evident when a custom system is developed to satisfy a new business process that may not be fully established yet

               Poorly Specified Test Case/Script

Tests can fail if the Test Case or Test Script (or other relevant document) produced is incorrect and indicates an outcome different than documented in the corresponding requirements

When a Test Case or Test Script has been modified during execution, a test incident should be raised to manage changes to the Test Case or Test Script, and to confirm the pass/fail status of the test

Incidence of this type of error should be minimized by ensuring independent review of the test case before approval, including a cross check of the expected output as specified in the controlling requirement.

                Incorrect Design Solution

Test errors can arise where the SW may work correctly against design, but the design implemented does not satisfy the original stated requirements, or fail to reflect any subsequently agreed change requests

               Inconsistent Controlling Design Specification

Test incidents can occur where the content of the relevant controlling Design Specification contains inconsistencies. It is, therefore essential that this specification is corrected to prevent further confusion

This incident type should not be confused with Incorrect Programming/Coding, where the SW coded does not match a particular requirement of the controlling Design Specification, and the code needs to be corrected

The controlling Design Specification inconsistencies should be logged in the incident management system so the specification can be corrected following the appropriate document management system

           Unexpected Test Events

During execution of a Test Case or Test Script, the tester may notice an anomaly in the SW that, although not affecting the success of the overall test objective, nevertheless requires further investigation. This event should be recorded in the incident management system in order that the controlling Design Specification, and the corresponding Test Case or Test Script can be updated to reflect the presence of the anomaly

             Test Execution Errors

Test can be classified as failures if the tester fails to follow the steps outlined in the Test Script, or the overall Test Protocol or Test Specification governing that activity

Missing signatures and timestamps for dates, and other important cross reference information is another area that could cause a test to be considered a failure

               Force Majeure

Test incidents of this nature reflect an unexpected event over which the test or project team have no control, and which brings testing to a premature halt. These events can be raised as issues by the project team, but are generally resolved outside of the project

ולידציה – SSO for Turbine Air Inlet Cooling

   Schedule of System Operation – SSO

Turbine Air Inlet Cooling

This article is an elaborated example of a schedule of system operaton – sso we did for one of our clients. Of course the actual documents contain all the operational and alarm parameters  

                Scope

This Schedule of System Operation (SSO) covers the required technical data and operation logic regarding the components of Turbine Air Inlet Cooling system, according to the Smartlogic's requirements and the client specifications

              System General Description

 :Turbine Air Inlet Cooling system contains two cold liquid circuits

Primary – 4 chillers and their respective primary pumps

Secondary – 2 pumps for each turbine inlet air cooling coil, 2 pumps for Cogen1, 2 pumps for Cogen2, and 2 pumps for the electric generator cooling (one operating and the other in standby

                Applicable Documents

User Requirements Specification (URS) for Monitoring and Alarm System

Parameters List

            Operational Parameters List

                          Alarm Parameters List

                              Operation Logic

            :Start Conditions of Chiller

COND_SYS_RDY Signal is on
Relevant pumps are waiting for our commands, including their corresponding valves

OIL_PUMP_OK Signal is on

READY Signal from MCC (C-025/RD) is on

READY Signal from Chiller (JM-025/RD) is on

ZS (Freeze protector) Signal is off, not indicating alarm

           : Running Logic for Chiller

Start corresponding Reg_valve (condenser regulate valve) on 100% and wait until valve feedback indicating >= 95%

Delay REG_VALVE_DLY_SP – 10 second

:If number of operating chillers <= 2

Send signal to  Start_cond_pump_1 – Start one Condense Pump

:If number of operating chillers > 2

Send signal to  Start_cond_pump2 – Start Two Condense Pumps

Verify from via communication that relevant cond_pump has

Delay 20 seconds

Perform PID on PDIT using Reg_valve according to relevant PDT-081-4_SP DeltaP SP
(in manual and/or auto mode)

Start CHW_Pump, chilled water pump

Delay 30 second

Verify relevant FS (flow) Signal is on for 20 seconds

Start Chiller

           : Stop operation for each Chiller

Delay 2 minutes , safety in case user changed the operation order of chillers from HMI

Stop Chiller

Wait for signal off from motor MCC feedback

Delay 60 Sec

If current chiller is 3rd , Send signal to stop Cond_pump_2

If current chiller is 1st , Send signal to stop Cond_pump_1

Close Reg_valve, condenser regulate valve

Delay 30 Sec

Stop CHW_Pump, chilled water pump
Interlock: in any case, CHW_Pump will continue operating as long as the corresponding chiller is operating

            Consumers Pump activation

User can always choose primary/secondary pump

If demand cooling for cogen1/2 via .DI 20 for cogen 1, DI 21 for cogen 2

For first activation: Check TT-087 (supply water) is below SP +1

:Perform PID control with relevant Cogen-TT
For Cogen-1 TE-315-022, for Cogen-2 TE-316-093
according to TT_315_022_SP / TT_316_093_SP using cogen-1/2 primary pump

If PID control loop reaches >= START_HZ_SP activate secondary pump and Continue PID control loop with both primary and secondary pumps

If both primary and secondary pumps at work and PID control loop reaches <= STOP_HZ_SP deactivate secondary pump and Continue PID control loop with primary pump only

If outlet air from cogen 1 or 2 below setpoint -2°C and the pump speed in minimum for 3 minute, stop the cogen pump

When the outlet air is above set point +1°C for 1 minute start the pump

*Generator equipment is not connected to the our PLC

           :Consumers Pumps activation for generator

If number of operating chillers <= 2 then activate first pump

If number of operating chillers > 2 then activate second pump

Stop pumps using reverse order

            :Temperature control for generator valves

Perform PID control with TT-090 according to SP using TV-088, If 316-J-21A operates

Perform PID control with TT-090 according to SP using TV-089, If 316-J-21B operate

           :Start Conditions of Chiller sequence

Demand Cooling at least from one of Cogen-1 / Cogen-2 / Generator. slot 4 DI-19-20-21

            :Chiller sequence run-up

Start first chiller according ‎6

The chilled water pump in the first chiller will start all the time even if we are not receive "chiller ready to start", we do need to receive "MCC ready" and do not receive "chiller shut down" . this function are necessary when the chiller stop in" low water temperature"

Delay Run-up Start_Chiller_DelaySP delay – 10 minutes

According to demand, start next chiller

:Perform sequence control using the maximum calculated value from
:{Flow measurement} calculation and {Temp measurement} calculation

:By flow measurement

Chiller #2 operates when total flow is > CH2_FLOW_SP + CH_FLOW_OFFSET_ SP

Chiller #3 operates when total flow is > CH3_FLOW_SP + CH_FLOW_OFFSET_ SP

Chiller #4 operates when total flow is > CH4_FLOW_SP + CH_FLOW_OFFSET_ SP

Chiller #2 stops when total flow is <= CH2_FLOW_SP – CH_FLOW_OFFSET_ SP

Chiller #3 stops when total flow is <= CH3_FLOW_SP – CH_FLOW_OFFSET_ SP

Chiller #4 stops when total flow is <= CH4_FLOW_SP – CH_FLOW_OFFSET_ SP

Total flow = FM1 + FM2 + GenFM

Here are some examples of the PLCs used by Smartlogic: 6XV1830-0EH10, 6ES7131-4BF00*0AA0, 6ES7193-4CA40-0AA0, 6ES7134-4GD00-0AB0, 6ES7193-4CA40-0AA0, 6ES7138-4CA01-0AA0, 6ES7193-4CC20-0AA0, 6ES7590-1AB60-0AA0, 6ES7511-1AK00-0AB0, 6ES7954-8LP01-0AA0, 6ES7155-6AU00-0BN0, 1746-NO4V, 1769-L16ER-BB1B

 

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

ולידציה – 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

ולידציה – 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

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

ולדיציה -1 Validation Requirements – case study- part

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

Validation Requirements is a document which may be part of the validation documentation that describes the validation strategy for a system or subsystem. This document is generic; the system or subsystem may include a PC with Human/Machine Interface (HMI), a Programmable Logic Controller (PLC), virtual hardware (HW), software (SW), and other components designed to maintain the user's facility in proper conditions specified by the user.

Validation Requirements Document Contents

This document is structured in a relatively standard fashion, with predetermined chapters and sections, where the final contents are tailored according to the type and size of the system under validation.

The main chapters and sections of a Validation Requirements document are:

Responsibility

Validation Requirements

Documentation for Initial Tender

Documentation for Design Review

Documentation Prior to Factory Acceptance Test (FAT) or Pre-Delivery Inspection – PDI

Commissioning

Documentation For Installation and Operational Qualification (IQ and OQ) – to be checked at PDI/FAT

Design Qualification (DQ) Protocols (Including PC/PLC) Architecture

Installation Qualification (IQ) Protocols (Including PC/PLC

Operational Qualification (OQ) Protocols (Including PC/PLC

Performance Qualification (PQ) Protocols

Computerized System Validation

Responsibility

This section lists the responsibilities of contractor, the user, and the required contents of the documents composing the validation file

The contractor is responsible for creation and performing the DQ, Design Review, Commissioning, IQ and OQ validation protocols

The user is responsible for creation and performing the PQ validation protocols

Design Qualification (DQ) – The design of the system will be documented and checked in the Design Specification. This specification will include details of the system and must be traceable to the URS and BOD documents

Mechanical Completion Check Report (MCCR) of the system will be documented and checked only by the contractor. This document will check system readiness for the IQ

Commissioning Execution (CE) of the system will be documented and checked only by the contractor. This document will check system readiness for  OQ

Installation Qualification –IQ

IQ will establish documented evidence that the system is installed according to the manufacturers’ specifications and user requirements, and assure that the environment is appropriate for its intended purpose

Each IQ protocol will include an appendix of deviation report, which describes the deviations (if they existent) of the specific system, and the contractor will be responsible to correct them

Operational Qualification – OQ

OQ will establish documented evidence that the system is operated according to manufacturers’ specifications and user requirements, and assure that the environment is appropriate for its intended purpose

OQ will establish documented evidence that the system is operated according to manufacturers’ specifications

.Each OQ protocol will include an appendix of deviation report, which describes the deviations (if they existent) of the specific system, and the contractor will be responsible to correct them

Performance Qualification- PQ

PQ will establish documented evidence that the system performs according to manufacturers’ specifications and user requirements, and assure that the environment is appropriate for its intended purpose

The PQ protocols are user's responsibility

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

ולידציה – FSD – System Functions and Facilities

ולידציה – FDS – System Functions and Facilities

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

.The Function Design Specification (FDS) is part of the validation documentation. In this article I will continue to elaborate the  parts of the FSD of system function and the system facilities

Modes of Operation

This section details all modes of operation for the system, including

Automatic/Manual

Start-up/Shutdown

Overrides

Emergency Shutdown

System Failure and Recovery

Functional Operation

This section divides each of the sequential functions into logical areas (determined by the process), and provide complete description of each function, including

Normal Control Functions – such as normal sequencing, control, etc

Interlocks – details of all interlocks within the function

Alarms – lists of all associated alarms and actions for recovery

Operator Requirements

This section describes the interface between the operator and the detailed function. It is probably the most important to the user during the design phase, as it fully details all the functions to be supplied by the system in order to meet the user's requirements. It must be written clearly and concisely, so that operators and users without technical background can visualize the system to be supplied. Inputs from the user should be clearly detailed so that the operational requirements can be determined

Human/Machine Interface – HMI

This section describes in detail all points of operation, local terminals, remote terminal, message displays, pushbutton stations, etc

Where computerized interfaces are used, such as SCADA or HMI, a list of the screens and the proposed content should be included

Dynamic Attributes – dynamic color changes for status

Display Values – Values to be displayed on screen and resolution- No. of decimal places

Input Devices – Operator interaction devices, mouse, keyboard, touch screen, etc

Alarm and Event Displays

Security – Password Access

System Data

All the data gathered, generated or calculated by the system should be detailed. The detailed data should include

Type

Range

Accuracy/Resolution

Scaling

All the data to be stored should be detailed. This includes historical trend data, alarms and events, taking into consideration the following

Location of data to be stored – fixed disk, floppy disk, etc

Retention period – length of time for the data to be maintained

Data Archive – procedures for backup to removable medium

Data Export – export facilities to other formats, such as Excel, Access, Lotus, etc

System interfaces

This section provides complete details of all inputs and outputs from the control system. When separate I/O schedules are generated, these documents must be referenced in the FDS, or else, the complete schedules must be included in the FDS appendix

For digital and analog I/O, this section should provide details of voltage, current, etc., being specific where interfacing to 3rd party equipment. The signal states should be included as follows

Digital inputs – two states

False or Off

True or On

Analog inputs – detailed range

Detailed communication interfaces between systems should include protocols and formats, and also provide complete details of data to be transferred, paying special attention to 3rd party devices

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

אילן שעיה ilan Shaya

ולידציה – Function Design Specification – FDS

ולידציה – Function Design Specification – FDS

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

The Function Design Specification (FDS) is part of the validation documentation that details the solution to be provided to meet the user's requirements. It should be approved by the user and should form the basis of the design for both hardware (HW) and software (SW) designs.

The FDS provides the basis of the design of the system and is used to verify and validate the system during the testing, ensuring all the required functions are present and that they operate correctly. It details all the functions, operator interactions control and sequencing associated with the system, thus allowing the user to confirm, before the system is developed that the proposed solution fully meets its requirements.

FDS Contents

The FDS is structured in a relatively standard fashion, with predetermined chapters and sections, where the final contents are tailored according to the type and size of the system under validation. The FDS presented here includes only to the technical contents. It does not include commercial and contractual requirements, which may also be generally included.

The main chapters and sections of an FDS protocol are:

Relationship to Other Documents – lists all documentation used in the production of the FDS. Includes suppliers' documents (such as URS) and drawings. Each document listed should include the document/drawing number and version number. This allows traceability as documents are updated throughout the project life cycle on any impact on the FDS.

System Overview

Process Overview – includes a description of the process being controlled; this may be taken from the URS, enhancing to detail the interaction with the control system.

Control System Overview – includes detailed control system description, with all the components and interaction between the systems; block and network diagrams can be used to show in detail the system architecture

Scope and Limits of Supply

Scope of Supply – includes a list of deliverables, panels, computers, software, etc

Limits of Supply – includes all items outside the scope of the supply required by the project; where interfacing to 3rd party systems, constraints and assumptions should be included

System Functions and Facilities

Operation Modes – includes all modes of operation for the system

Functional Operation – divides each of the sequences functions into logical areas (determined by the process), and provide complete description of each area

Operator Requirements – describes the interface between the operator and the detailed function

Human/Machine Interface- HMI – details all points of operation, local terminals, remote terminal, message displays, push button stations, etc.

Report Outputs – the format of all reports generated by the system should be detailed, and that the format and explanation of the report contents should be included

System Data – all data gathered, generated or calculated by the system should be detailed

System Interfaces – provide complete details of all inputs and outputs from the control system

System Attributes

Availability – defines expected "working" time of the system between failures

Maintainability – details issues related to maintainability of the plant, in particular for systems that require regular maintenance to ensure the reliable operation

Transport and off loading

Power and services required

Connections to existing/3rd party systems

Changes to existing plant or hardware (HW) equipment

Changes to existing software (SW) systems

Training – details the formal and informal training to be supplied under the contract

Design Factors – details special factors relating to the design of the system, standards and methodologies to be followed for both the HW and SW development

Development Factors

Project Control – includes or makes reference to project plans and timescales, along with details of quality requirements, standards, test and integration and configuration management

Resource Requirements – includes the basic project team provided by the supplier, the access required to the customer's premises, and input and timing required by the customer into the project

Test procedures – including details of all test documentation and responsibilities for testing both offline and online

Module and Integration Testing

Factory Acceptance Testing (FAT) – performed at the suppliers premises

Site Acceptance Testing (SAT) – performed on completion of commissioning to demonstrate pre-handover system operation

:Note

As the final contents of the FDS are tailored according to the type and size of the system under validation, and this document is generic, it covers test procedures that may not be necessary in small or simple systems. The following sections cover the FDS issues that require further details

 About the system functions and facilities in our next article FSD System Function & Facilities

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

אילן שעיה ilan Shaya

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

ולידציה – 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