Smartlogic

Menu

תגית: ולידציה

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

ולידציה – GAMP – Hardware & Software Test Environments

Posted on by אביב צברי

ולידציה –  GAMP – Hardware & Software  Test Environments

Good Automated Manufacturing Practice (GAMP) Hardware (HW) Environment Test

HW can be categorized according to both GAMP 4 HW category (standard or custom) and its function within the test environment. It can be one o f these three things

 Part of the system under test, i.e., part of the production HW

 Test HW representing part of the production environment, which may be needed because it is not feasible to include a certain element of the production system in the test environment

A separate test system, which may be used to represent an external system

          Representative Test Environment

As started previously, the HW environment should represent as close as possible the production environment

For example, if the test environment uses a standard network hub of the same type as the production environment, then the substitution probable introduces low probability if invalid test results in the production environment. If, however, the network cabling in the test environment is uses short patch cables, whilst the real environment has cable runs close to the maximum recommended length, there is clearly a possibility of different network behavior, and additional tests on site may be needed to prove proper network performance

                    Control of Test Environment

For standard HW (per GAMP 4 HW Category 1), the manufacturer's reference and serial numbers should be recorded.

For custom HW (per GAMP 4 HW Category 2), the version of the item and its controlling specification should also be recorded.

For all test HW, any applicable calibration status should be recorded in the context of the specific

                         Removal from Production Environment

If the test HW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well

Good Automated Manufacturing Practice (GAMP)  Software (SW) Environment Test

Test SW can also be categorized according to both GAMP 4 SW category and its function within the test environment:

Part of the system under test, i.e., part of the production HW

Test SW representing part of the production environment

A separate test system

              Representative Test Environment

The SW environment should represent as close as possible the production environment

For example, if the test environment uses a process controller of the same type as the production environment, then the substitution probable introduces low probability if invalid test results in the production environment. If, however, a particular interface is simulated in the test environment, a possibility remains that different timing factors or process dynamics could affect the operation in the production environment, and additional tests on the production interface may be appropriate

                        Control of Test Environment

For standard SW (per GAMP 4 SW Category 1, 2 or 3), the manufacturer's reference and version numbers (including installed patch cables) should be recorded. Any configuration or setup parameters should be controlled

For configured or custom SW (per GAMP 4 SW Category 4 or 5), the item should be placed under configuration management and the version in use recorded

              Removal from Production Environment

If the test SW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well

ולידציה –  GAMP – Hardware & Software  Test Environments

ולידציה – Introduction to GAMP Test Environments

Posted on by אביב צברי

ולידציה – Introduction to Good Automated Manufacturing Practice (GAMP) Test Environments

The environment in which testing is conducted should be determined based on the life cycle output of the risk assessment. The following general principles apply:

  • The proposed test environment should represent as close as possible the production environment. The differences between the two should be detailed in the Test Specification or Protocol, and should be subject to impact assessment.
  • The test environment should be controlled and recorded to a level of detail that would allow it to be reconstructed if necessary. Such control includes:
  • System hardware (HW) and software (SW) components
  • Test HW (versions, serial numbers, as appropriate)
  • Test SW (version control of any simulations)
  • Test data (version control of any test data sets, test recipes, etc.)
  • Test user accounts
  • Where test HW/SW/data/user accounts are applied as they may appear in the production environment, controls should be available to ensure that they can either be removed cleanly or isolated from use (either logically or in time).
  • Where the test environment is required to undergo a temporary change to facilitate the execution of specific tests, both the change and its removal must be formally documented.

 GAMP Test Environments

In many circumstances it is undesirable to conduct all testing on the final production environment. Common examples include:

  • Non-availability of infrastructure at the point in the project life cycle when testing is carried out.
  • Non-availability of certain interfaces.
  • Requirement to test changes outside of the production environment prior to installation.
  • Requirement to carry out tests which may be destructive to the production environment.

 

The progression of SW build from a development environment through production environment depends on the risk priority associated with the system being installed or the change being made, and on factors such as the ease of possible modification removal from the system.

A change to a custom data processing module in a large business system may require progression from a development environment to a test environment, to a validation environment, and then to the production environment. This may be required because the change is a high risk priority, and, even if the if the original module could be restored easily, the test data may remain in the production environment.

Some tests, e.g., Performance Qualification (PQ), or part of it, may need to be conducted in the production environment.

 

 

ולידציה – מצגת אוטומציה ובקרה תוך שימוש ב – 21CFR Part 11

Posted on by אביב צברי

למצגת לחץ על הלינק הבא :בקרה ואוטומציה תוך שימוש ב 21 CFRPart11

להורדת סילבוס ולהרשמה לקורס 21CFR Part 11 לחץ כאן

ולידציה – Design Specification – DS

Posted on by אביב צברי

ולידציה – Design Specification – DS

The Design Specification -DS is part of the validation documentation that provides information necessary to complete the design of the project. This document covers only the DCS side and integration with ELT-GHS-150-T3 Gas Heater skid

DS Content

The DS is usually 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 this DS are

Hardware Specification

Wiring and Electrical Cabinet Drawing

Communication and Network Design

Other Documentation

ProfiBus Monitoring Values List

Running Logic

Alarms List

Alarm Response

Disaster Recovery

Programming Design

Appendixes

Hardware Specification

.This section defines the required I/O allocation, according to the wiring diagram document No. P09204-020 Rev2, and 35800SIS0-N0

8 digital inputs

1 digital outputs

ProfiBus connection

Wiring and Electrical Cabinet Drawing

:This section lists the following design information

New Electrical drawing is not needed

:All I/O should be named in a standard fashion, i.e., XXXX-YYY-ZZZ, where

XXXX – 4 prefix letters which indicates the containing system; in this case, the system is PRMS

.YYY – indicates the instrument type according to Siemens naming standard – document no

ZZZ – indicates the serial continuing number

.Siemens Engineering file update is needed in Chapters18C 18D 18E. Other chapters should be examine and discussed in the FRS

.BOP PLC must be stopped during the wiring and ProfiBus module installation. Dalkia should be supply with time table

Communication and Network Design

:This section lists the following design information

.The communication used in this project is Profibus

.The Profibus communication protocol and wiring design will be provided by Siemens

.Siemens Engineering file update is needed. All communication and network chapters should be updated

Communication and Network Design

Siemens Engineering file "stand alone skids and instruments" chapter should be update; all Heater manuals and instructions should be attached to this chapter.

ProfiBus Monitoring Values List

tSP Target Setpoint – Setpoint differential CT15/14 – CT15/13

All  Operator.MAIN items – To be later configured

All Operator. SYSTEM.StatusWords.Output) – To be later configured

Man Manual/Auto Mode 76 AUTO (0) – +VFD manual percents

Running Logic

start conditions

Heater valve V101 is open. – GS101 HEATER INDICATION.

Heater valve position V102 is open.

Heater bypass valve V103 is closed.

DCS 10EKA01CF001>1500m3h (indicating that at list one of the gas turbines is on).

DCS 25Barg<10EKA001CP001<45Barg (Gas pressure operation range).

All Heater trips are acknowledged and cleared.

Operator pressed "Start" from DCS.

Alarms List

All alarms from profibus

Alarm Response

Holding/Restart Logic

No alarm response from the DCS.

Disaster Recovery

Perform stop operations as in paragraph

  1. Power shut down
  2. Compressed air supply shut down

 Programming Design

AS (Automation system – PLC) that will be programmed in this integration will be BOP.

The synoptic screen will be programmed and be added to the PRMS screen, as described in Appendix 1 – Synoptic Screen.

All instruments, EG valves and transmitters, will be created according to Siemens standards.

All instruments will be set to READ ONLY, except the START and STOP buttons.

Appendixes

The DS appendixes present examples of design drawings.

Appendix 1 – Synoptic Programming Design.

Appendix 2 – Chapter 18E BOP Example of Electrical Drawing (to be updated)

Appendix 3 – Example of Network Drawing (to be updated)

 

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

Posted on by אביב צברי

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).

 

ולידציה – תפקידים ואחריות בתכנון וביצוע בדיקות

Posted on by אביב צברי

מבוא

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

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

בהתאם ל- GAMP, ניתן לחלק את התפקידים והאחריות שמוגדרים בהמשך לשתי קבוצות נפרדות:

תפקידים בתוך צוות הבדיקה.

תפקידי תמיכה המבוצעים ע"י צוות הפועל מחוץ לצוות, אך שאחריותו קשורה ישירות להצלחת תהליך הבדיקה .

תפקידים אלו לא בהכרח דרושים בכל צוות הבדיקה, ורק פרויקטים גדולים ומורכבים יכללו בד"כ את כל התפקידים המוגדרים בהמשך.

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

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

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

תפקידים בתוך צוות הבדיקה:

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

מנתח הבדיקה -Test Analyst- מחבר קובץ הבדיקה

test script –  מגדיר את קובץ הבדיקה , כולל את ההוראות המפורטות לבדיקת תחום פונקציונאלי ספציפי במסגרת הפרויקט.

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

בוחן קובץ הבדיקה – Test Script Reviewer

מוודא שכל הדרישות מולאו כמוגדר בקבצי הבדיקות.

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

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

בודק -Tester

מבצע את הבדיקות בהתאם לקבצי הבדיקות.

מודיע על כל חריגה למנהל -Incident Manager.

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

עד בדיקה– Test Witness

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

בוחן תוצאות הבדיקה – Test Result Reviewer

מוודא שכל מהלכי הבדיקות בוצעו כמוגדר בקבצי הבדיקות.

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

מוודא שכל החריגות נרשמו.

מאמת את כל תוצאות הבדיקות (מצב עבר/נכשל), בהתבסס על ההוכחות המתועדות.

מנהל הבדיקות – Test Manager

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

מוביל צוות הבדיקות– Test Team Leader

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

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

צוות תשתיות הבדיקה-Test Infrastructure Team

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

סגל טכני -Technical Staff

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

אדמיניסטראטור של צוות הבדיקות -Test Team Administrator

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

ניהול התיעוד.

עזרה בהקצאת משאבים ופעילויות של רישום זמנים.

רישום פרוטוקולים בפגישות רלוונטיות.

פעילויות אחרות מוקצבות ע"י מנהל הבדיקות.

 

  תפקידים מול צוות הבדיקה:

מפתח תוכנה – Software Developer

עוזר בניתוח מקרים חריגים שקשורים לתוכנה במהלך הבדיקות.

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

מנהל מקרים חריגים – Exceptions/Incidents Manager

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

עוזר בניתוח מקרים חריגים שקשורים לתוכנה במהלך הבדיקות.

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

אבטחת איכות / בקרת איכות – Quality Assurance / Quality Control – QC/QA

תפקיד זה יכול להתבצע ע"י מומחה לוולידציה של מערכות ממוחשבות או איכות טכנולוגית מידע ולמעשה ע"י אנשי אנשי צוות טכני מוסמכים מחוץ למחלקת  QC/QA:

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

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

מנהל הפרויקט – Project Manager

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

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

מנהל התוכנית – Program Manager

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

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

 בעל המערכת  – System Owner

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

 QA -גורם שבד"כ מקבל את דו"ח הבדיקה לבחינה וחתימה, בעזרת צוות ה.
  

 מבקר פנימי – Internal Auditor

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

אדמיניסטראטור המערכת – System Administrator

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

  במידה הצורך, יסייע לצוות הבדיקה במקרים של בעיות במהלך הבדיקה .

מנהל הקונפיגורציה  – Configuration Manager

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

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

.מתחזק את שורת הבסיס עבור כל מערכי המידע המתקבלים כדי לאפשר שימוש חוזר שלהם.

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

צוות ניהול המידע – Data Management Staff

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

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

בדיקות קבלה – משתמש –Acceptance Testing

משתמשי המערכת אחראים בד"כ על הביצוע הסופי של בדיקות הקבלה (Acceptance Testing) ועל הגדרת קבצי הבדיקה (Test Scripts) עבור בדיקות הקבלה.

המשתמשים נתמכים ברוב המקרים ע"י ארגון בדיקה – Test Analysis and Testers.

ספק – Supplier

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

תוצאות הערכת הספק יכולות לשמש כעזר בהגדרת היקף הבדיקות.

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

 

פונקציות בסיסיות בסביבת עבודה של תוכנת Cimplicity

Posted on by אביב צברי

Cimplicity הינה תוכנת בקרה (scada) מבית היוצר של GE-General Electric.

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

דברים בסיסיים:

איך עושים שמסך ההתראות יקפוץ בכל התראה חדשה?

  • מגדירים תג חדש בשם ALARMֹI_IS_ON
  • ב-Event Editor מגדירים Event חדש מסוג: Alarm generate.
  • ב Action של ה Event  : Absolute SP -> Alarm_is_ON=1
  • יוצרים אוביקט במסך Objects.
  • באוביקט שיצרנו עושים תנאי ב- events -> if Alarm_is_on==1 -> OpenScreen Alarm.cim
  • שמים לינק בכל מסך לאוביקט הזה.
  • במסך התראות -> OnScreenOpen -> ALARM_IN_ON=0

תקלות:

לא רואים התראות במסך ההתראות

אפשרות מס' 1: בוצעו שינויים לא במצב דינאמי.

פתרון: יש לעשות stop ו start  לפרויקט.

 

אפשרות מס' 2: הפרוייקט לא מקושר למסך התראות.

פתרון: במסך ההתראות-> כפתור ימני על הOLE -> Add Project.

 

אפשרות מס' 3: אף משתמש לא מקושר להתראה הספציפית.

פתרון: במסך של הנקודה בלשונית Alarm Routing -> העבר את כל השמות שבשדה Available roles לשדה "Configured roles for alarm" (לסמן הכל משמאל ולהעביר לשדה הימני).

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

ולידציה מה זה

Posted on by אביב צברי

הגדרת המונח ולידציה

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

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

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

קריטריונים לתהליך

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

  • Good Manufacturing Practice – GMP).
  • Current Good Manufacturing Practice – cGMP.
  • Good Automated Manufacturing Practice – GAMP.

במונח 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.