מדריך זה דן בתהליך הוולידציה (אימות) של מערכות מידע המותקנות בסביבת cGMP (תעשיות הפרמצבטיקה והמזון בעיקר)
התהליך כולל הנחיות כלליות שמטרתן ליצור בסוף התהליך מוצר איכותי והן נוגעות בתהליך ייצור התכשירים ובתהליך בדיקת איכותם במעבדות בקרת איכות (QC).
תהליך הוולידציה של מערכות מידע ותשתית מוכל למעשה במתודולוגית מפת"ח, בעיקר בקיט בדיקות מערכת. מנהל פרויקט שעובד לפי מפת"ח יוכל להוכיח שהמערכת שלו ולידית באמצעות הכלים והמתודולוגיה שמפת"ח מספק.
המגמה העולמית לשיפור מתמיד של איכות המוצר ובטיחותו נוצרה בעיקר עקב חוסר אמון במערכות מחשב והצורך להגביר את בטחון המשתמש במערכות המחשב אותן הוא מפעיל.
ההתמקדות של גופים רגולטוריים בדיוק ואמינות של מערכות מחשב המותקנות בסביבת cGMP (Current Good Manufacturing Practice) הוגברה עקב מקרי מוות שנבעו מתקלות במערכות בתעשיות אלה.
התמקדות זו הביאה ליצירת נורמות עבודה איכותית במפעלים המייצרים מכשור רפואי, תרופות ומזון, כשאחד הגופים העיקריים היוזמים הוא ה – FDA (U. S. Food and Drug Administration).
הנורמות כוללות הנחיות כלליות שמטרתן ליצור בסוף התהליך מוצר איכותי והן נוגעות לנושאים של ייצור מכשור רפואי ממוחשב, שימוש במערכות מחשב בתהליך ייצור תכשירי תרופות או תכשירים המשמשים לייצור תרופות ותוספי מזון ובתהליך בדיקת איכותם במעבדות בקרת איכות (QC).
ישנם קשיים מסוימים בהבנת הדרישות של ה – FDA מאחר והן כתובות כהנחיות ולא מוגדר באופן חד-משמעי מה יש לבצע על מנת להוכיח ולידיות.
הספקה של הוכחה מתועדת שמערכת מידע פועלת כפי שתוכננה לפעול - K.G.Chapman (1983) “A suggested Validation Lexicon” Pharmaceutical Technology vol. 7(8), pp. 51-55
· ולידציה של מערכות מחשב היא דרישה מנדטורית שנגזרת מ- cGMP
· הוולידציה של מערכות ממוחשבות היא פעילות המבטיחה את איכות התהליכים הנובעים משימוש במערכות מחשב בסביבת ייצור ודיאגנוזה של ציוד וחומרים המשמשים לצרכים רפואיים.
· כל מערכת מחשב שפועלת בסביבת cGMP או שיש לה השפעה על איכות המוצר, חייבת לעבור ולידציה.
· הגדרה של מאפייני מערכת המחשב
· הוכחה מספקת שמערכת המחשב איכותית ותואמת את אפיון הדרישות
· מודעות לניהול התהליך והשגת בקרה על המערכת
ולידציה פרוספקטיבית
משובצת בתהליך פיתוח מערכת המידע לאורך כל מחזור החיים של המערכת
ולידציה רטרוספקטיבית (ולידציה בדיעבד)
· הסמכה בדיעבד של מערכת שנמצאת בייצור ולא עברה תהליך ולידציה
· הכנת פרוטוקולי ולידציה וביצוע סדרה מצומצמת של בדיקות המערכת לפי השימוש המיועד ודרישות רגולטוריות של אבטחת מידע.
מסמכי הוולידציה כוללים:
· מסמכי אפיון
· מסמכי תכנון
· מסמכי בדיקות - פרוטוקולים שונים
· נהלים תומכים
לאורך כל שלבי מחזור החיים של מערכת המידע.
(בפרק תהליך הוולידציה בשיטת מפת"ח מופיעה טבלת השוואה בין תוצרים אלה לתוצרים המוכרים ע"י מפת"ח)
· מסמך ייזום - Concept Doc
· תוכנית ולידציה למערכת VMP – Validation Master Plan
· מסמך אפיון URS – User Requirements Specification
· מסמך ניתוח פערים - Gap Analysis
· מסמך עיצוב
· עדות מתועדת לאימות (Verification) בתהליך הפיתוח
· מסמכי בדיקות ותוצאות בדיקה
· מסמך מסכם לתהליך הוולידציה ואישור להסמכת המערכת
עץ המערכת האוניברסלי של מפת"ח הותאם לדרישות התיעוד של התהליך תוך אזכור סעיפי הדרישה המקוריים. לדוגמא:
2.24 Design Control Requirements
2.24.1 § 820.30(a) Design Control General
2.24.2 § 820.30(b) Design and development planning
במסמך העיצוב הושם דגש, בין היתר, על:
· רשומות אלקטרוניות
· חתימות אלקטרוניות
· ארכיון מידע
· Audit Trails
· גיבוי והתאוששות המערכת
· תהליכים/פונקציות
· קלטים/פלטים
· ממשקים לוגים
· ממשק למשתמש
· תנאי תפעול המערכת
· דוחות
· אבטחת מידע
· התאמה של מרכיבי חומרה
קיימים שלושה סוגי פרוטוקול לוולידציה:
· פרוטוקול IQ (Installation Qualification)
· פרוטוקול OQ (Operational Qualification)
· פרוטוקול PQ (Performance Qualification)
הפרוטוקולים צריכים להיכתב ולהיות מאושרים על ידי אנשים מוסמכים. לכל היבט נבדק בפרוטוקול צריך להצמיד קריטריון קבלה שיצביע אם ניתן לעבור לשלב הבא של תהליך הוולידציה.
בסיום הפרוטוקול ייכתב דו"ח סיום שישקף את תוצאות הבדיקות שנעשו על המערכת. אישור דוח הסיום יהווה טריגר לשלב הבא בתהליך הוולידציה
מתחלק לשניים:
פרוטוקול IQ לחומרה (שרתים, תחנות קצה, בקרים, מרכיבי רשת ) יכלול :
· אימות של רכיבי חומרה שנרכשו עם מפרט עיצוב המערכת
· אימות התצורה עם מפרט עיצוב המערכת
· תאימות לדרישות המינימום/המלצות הספק
· סטנדרטים מקומיים ובינלאומיים שאומצו
· דרישות חשמל לרבות מתח נדרש למכשיר גיבוי.
· כבלי תקשורת ואימות חיבורם למקומות הנכונים
· מדפסות, אמצעי אחסון ואמצעים פריפריאליים אחרים.
· נהלי אבטחה
· ממשקי חומרת תקשורת
· אבטחה פיזית של המערכת
· תנאים סביבתיים (מיזוג אויר, לחות, שמירה מפני שריפה).
המסמך יכיל גם דו"ח התקנה שיסכם את כלל הפעילויות שבוצעו על מנת להשלים את תהליך ההתקנה.
הדו"ח ייכתב ברמת פירוט שתאפשר לכל איש מערכות (System) לבצע התקנה מחודשת של המערכת
פרוטוקול IQ לתוכנה (מערכת הפעלה, היישום, קושחה ותוכניות שרות) יכלול :
· אימות של רכיבי תוכנה שנרכשו עם מפרט עיצוב המערכת
· אימות התצורה עם מפרט עיצוב המערכת
· תאימות לדרישות המינימום/המלצות הספק
· הוראות התקנה
· מדריכים למנהלן המערכת
· מדריכים למשתמש
· אבטחה לוגית
המסמך יכיל גם דו"ח התקנה שיסכם את כלל הפעילויות שבוצעו על מנת להשלים את תהליך ההתקנה.
הדו"ח ייכתב ברמת פירוט שתאפשר לכל איש מערכות (System) לבצע התקנה מחודשת של המערכת
פרוטוקול זה יכלול את הבדיקות התפעוליות שמטרתן להבטיח הפעלה נכונה של המערכת. ה – OQ יכיל:
· אימות סדר העלאת המערכת והורדתה
· בדיקות פונקציונאליות פשוטות
· בדיקות של הגדרות בתוכנה
· בדיקות של קונפיגורציות שונות
· בדיקה של הגירת מידע
· בדיקות של תוכנית ההטמעה של המערכת
· מעקב ביקורת (Audit Trail)
· גיבוי והתאוששות
· העברה לארכיון ואחזור
· אבטחת מידע
· רפליקציה
· בדיקות של אזעקות והודעות למנהל המערכת
· סקירת נהלים
במהלך ה – OQ יאומתו או יכתבו הנהלים הבאים:
· מדריכי הפעלה למשתמש
· הדרכת משתמשים
· תמיכה במערכות מידע
· נהלי עבודה
· נהלי תמיכה ותחזוקה
תוכנית מתועדת לביצוע בפועל של בדיקות על מנת להוכיח אפקטיביות ו – Reproducibility של המערכת כמערכת אינטגרטיבית. כל הבדיקות יתבצעו ויושוו אל קריטריוני קבלה שיוגדרו מראש.
סיום מוצלח של ה – PQ מוכיח קבלת המערכת כאשר היא עובדת בכפוף לנהליה, כוח אדם מיומן ותנאי הפעלה מבוקרים.
ה – PQ יכיל:
· מטרה
· היקף
· פעילויות, תוצרים ולוח זמנים
· קישור בין הבדיקות השונות למפרט הדרישות
· הגדרת אחריות לביצוע הבדיקות
· ניהול תצורה ובקרת שינויים
· מדיניות דיווח תקלות והתגברות עליהן
· מתאר את תוצאות הבדיקות השונות
· מציף את כל הסטיות ומציג המלצות לגביהן
· הדו"ח ירכז תחתיו את כל תיעוד הוולידציה של המערכת
נושאים שיכוסו בדו"ח:
· סקירה כללית
· תקציר מנהלים
· סקירה של תוצאות הבדיקות ומסקנות
· אינדקס תיעוד (מסמכי ולידציה)
· ממצאי בדיקות
· נושאים פתוחים/בלתי פתורים והשלכותיהם
· פערים ביחס לדרישות המשתמש
· כל שיפור או שינוי במערכת צריך להתבצע באופן מבוקר ומתועד.
· כל שיפור או שינוי צריך להיבדק במסגרת בדיקות פורמליות
· פרוטוקולי הוולידציה יעודכנו בהתאם לשיפורים/שינויים
· היקף השינויים ישפיע על היקף ביצוע הרה-ולידציה
תהליך הוולידציה של מערכות מידע ותשתית מוכל למעשה במתודולוגית מפת"ח, בעיקר בקיט בדיקות מערכת. מנהל פרויקט שעובד לפי מפת"ח יוכל להוכיח שהמערכת שלו ולידית באמצעות הכלים והמתודולוגיה שמפת"ח מספק.
להלן תקציר של מונחי היסוד במפת"ח:
· עץ מערכת
מחזור חיים הוא מושג הנדסי וניהולי מקובל וידוע. במפת"ח הוא מקבל הגדרה רחבה ומקיפה, הכוללת גם שלבים "מוזנחים" יחסית כמו ייזום, מכרזים, תחזוקה והערכת מערכת (תחקור). זהו מחזור חיים פשוט המכיל שמונה (8) שלבים בלבד, שגם בהם ניתן לעשות שימוש גמיש ולפי הצורך. גמישות זו גורמת לכך שלמעשה מדובר על מחזורי חיים דינמיים וגמישים, לא מחזור חיים "קשיח" אחד. ועם זאת, היסודות הם שמונה שלבים אשר מהווים את "התחנות" ו"אבני הבניין" הבסיסיים ברוב מחזורי החיים.
עץ מערכת הוא רעיון הקובע שמערכת ממוחשבת היא "מכונה" הבנויה מרכיבים אשר כל אחד מהם הוא תנאי הכרחי וביחד הם תנאי מספיק להבטחת פעילותה התקינה. רכיבים מסוימים ב"מכונה" הם פיסיים ומוחשיים (חומרה), רכיבים אחרים הם לוגיים (טרנזקציות, קבצים) ורכיבים נוספים הם מופשטים (יעדים). עץ המערכת מושתת על הרעיון ההנדסי הבסיסי של עץ מוצר. חידוש ראשון של מפת"ח הוא בעצם החלת תפיסת עץ מוצר על מערכות ממוחשבות. חידוש שני הוא בכך שמפת"ח מציג הגדרה של עץ מערכת ממוחשבת ומראה כיצד הגדרה זו מקיימת שני תנאים חשובים:
· היא עקבית לאורך כל מחזור החיים.
· היא מתאימה למגוון רחב של מערכות ממוחשבות.
התנאי הראשון הוא עקביות ברמת מיקרו (בתוך הפרויקט); התנאי השני הוא עקביות ברמת מקרו (בתוך הארגון ואף בין כל הארגונים העובדים לפי מפת"ח). בפועל, ייתכנו שינויים קלים (וריאנטים) בעץ המערכת הנובעים משתי סיבות (במקביל לשני התנאים הנ"ל):
· הדגשה/אי הדגשה של רכיבים בעץ המערכת בשלבים השונים של מחזור החיים (השפעת מחזור החיים)
· הדגשה/אי הדגשה (או אפילו הוספה/השמטה) של רכיבים בעץ המערכת בהתאם לסוג המערכת הנדונה (השפעת עץ המערכת עצמו).
וריאנטים אלה מאפשרים את הדגשת ייחודיות המערכת, תוך שמירה על התאמה מירבית עם עץ המערכת האוניברסלי. וריאנטים אלה רק מחזקים את הרעיון הבסיסי של עץ המערכת וממחישים רעיון יסודי אחר של מפת"ח - נוהל מסגרת - המאפשר ייחודיות בתוך אחדות.
שילוב עץ המערכת עם מחזור החיים לכדי מטריצה דו-ממדית המלווה את תהליך הפיתוח והתחזוקה לכל אורכו. בכל רגע ניתן לבחון את המערכת בראייה של ציר עץ המערכת: מה מצב תכני המערכת ורכיביה ושל ציר מחזור החיים: איפה נמצא הפרויקט וכיצד הוא מתקדם (יחסית לתכנון). תיתכן, כמובן גם ראייה משולבת ופרטנית יותר, משני הכיוונים. מכיוון ציר מחזור החיים: נכון לרגע נתון (שלב במחזור החיים), מה מצבו של כל רכיב בעץ המערכת. מכיוון עץ המערכת: במבט על רכיב מסוים, מה "ההיסטוריה" שלו עד היום, מה מצבו הנוכחי ומה הצפי להשלמתו. אחידות עץ המערכת לאורך מחזור החיים מקלה מאד על ניהול הפרויקט ומאפשרת הן שמירה על המשכיות קדימה (Continuity) והן בקרה ועקיבות לאחור (Traceability).
מודל המטריצה של מפת"ח מציג תפישת עולם אחת ושפה אחידה עבור כל תחום המחשוב (ובעקבותיו גם תחומים אחרים בארגון), הן ברמת הניהול והן ברמת המערכת הבודדת.
מחזור חיים עפ"י מפת"ח |
תהליך הוולידציה |
תוצר |
---|---|---|
ייזום |
ייזום - Concept |
Concept Doc Policy |
אפיון |
אפיון |
תוכנית ולידציה למערכת VMP מסמך אפיון URS SRS Quality Plan Risk Management |
בקשה להצעות |
בקשה להצעות RFP סקר ספק ניתוח פערים |
מסמך בקשה להצעות RFP Gap Analysis Document |
עיצוב ובנייה |
עיצוב בנייה/פיתוח |
Design Specification Construction & Code Unit Test |
בדיקות |
בדיקות אינטגרציה כתיבת פרוטוקולי ולידציה - IQ/OQ/PQ ביצוע IQ/OQ/PQ |
Test Plan IQ/OQ/PQ Test Results Traceability Matrix |
התקנה והרצה |
כתיבת תוכנית הטמעה והטמעה כתיבת תוכנית פריסת המערכת פריסה |
Summary Reports Validation |
תפעול ותחזוקה |
|
Configuration Management |