שינוי גישה מהותי לולידציית תוכנה במערכות ייצור ואיכות - ההנחיה החדשה של ה-FDA על CSA

ה-FDA פרסם לאחרונה מסמך הנחיה חדש וחשוב שיצא כטיוטה לפני 3 שנים: "Computer Software Assurance for Production and Quality System Software" (ספטמבר 2025)

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

המסמך הזה לא מבטל את ההנחיה הקלאסית "General Principles of Software Validation", אבל כן מחליף את סעיף 6 של המסמך הקודם, אותו סעיף שעסק בולידציה של תוכנות בתהליכי איכות ואוטומציה.

כלומר, אם ביצעתם עד היום ולידציות לתוכנות כמו LMS, ERP, CAPA, PLM, MES או מערכות BI לפי סעיף 6 של ההנחיה הישנה, מהיום אתם נדרשים לפעול לפי CSA.

מה זה בעצם CSA?

CSA - Computer Software Assurance היא גישה מבוססת-סיכון שמטרתה לבסס רמת ביטחון מספקת בכך שהתוכנה עושה את מה שהיא אמורה לעשות, בהתחשב ברמת הסיכון שלה.

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

• התאמה בין סוג התוכנה והשימוש שלה, לבין

• עומק הבדיקה וההבטחה הנדרשת.

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

איך מנתחים סיכונים לפי CSA?

בגישת CSA, ה-FDA קובע בצורה מפורשת:

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

תוכנה נחשבת High Process Risk כאשר:

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

דוגמאות בולטות שצוינו ע"י ה-FDA:

• שמירה/שליטה על פרמטרים קריטיים בתהליך כמו טמפרטורה, לחץ, זמן, לחות.

• קבלת החלטות לגבי התאמה/אי התאמה של מוצר ללא ביקורת אנושית.

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

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

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

לעומת זאת, פונקציות נחשבות Not High Process Risk כאשר:

• הכשל לא צפוי להוביל לבעיה באיכות, או

• תיתכן בעיה באיכות, אבל היא לא צפויה לסכן בטיחות.

דוגמאות לפי ה-FDA:

• איסוף/תיעוד נתונים לצורך סקירה בלי השפעה ישירה על התהליך.

• מערכת CAPA שמבצעת ניתוב אוטומטי, או לוגים של תלונות.

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

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

והכי חשוב, ה-FDA מבין שסיכונים קיימים על ספקטרום, ולכן:

• מותר לזהות "סיכון בינוני" או "סיכון נמוך", ולא רק בינארי.

• עם זאת, המסמך מגדיר את הפעילות לפי “High” או “Not High” לצורך הנחיות ברורות לבדיקות.

אז איך בוחרים פעילויות ולידציה?

• High Process Risk ← נדרש עומק: תסריטי בדיקה מלאים, עקיבות, בדיקות חזרתיות, תיעוד חתום.

• Not High Process Risk ← מספיק: בדיקות גילוי (exploratory), ניתוח תרחישים, בדיקות ספק, תיעוד "קליל" יותר.

איך זה מיושם בפועל?

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

מערכת לניהול חריגות (Nonconformance Management System)

יצרן רכש תוכנת COTS (מדף) לניהול חריגות. לאחר ניתוח סיכונים, החברה זיהתה כי:

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

• לעומת זאת, פונקציה שקשורה לאיתור חריגות במוצרים שכבר הופצו עשויה למנוע ריקול ולכן היא נחשבת ל-High Process Risk.

במקרה כזה:

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

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

הכל יתועד בצורה דיגיטלית ויעילה בהתאמה לרמת הסיכון.

מערכת ERP לניהול מלאי

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

• הראשונה נחשבת לא מסוכנת (Not High Process Risk), ולכן הוולידציה יכולה להסתפק בהערכת ספק, בדיקת התקנה ובדיקות קלות.

• השנייה נחשבת מסוכנת (High Process Risk) ודורשת בדיקות מעמיקות יותר, כי כשל עלול להוביל לשימוש בחומר לא מתאים.

LMS - מערכת הדרכות

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

ולכן:

• תבוצע הערכת ספק.

• ישולבו בדיקות תרחיש פשוטות ("האם המשתמש מקבל התראה?").

• אין חובה לבצע ולידציה לכל קליק או תרחיש שולי.

אילו סוגי בדיקות מבצעים לפי CSA?

אחרי שמבצעים ניתוח סיכון לפונקציה בתוכנה מגיע השלב שבו צריך להחליט: אילו בדיקות הבטחה (Assurance Activities) באמת דרושות?

ה-FDA מבהיר:

• ככל שהסיכון גבוה יותר, כך נדרש עומק רב יותר של בדיקות, תיעוד והוכחות.

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

איך בוחרים את סוג הבדיקה?

1. Scripted Testing - בדיקות סקריפט כתובות מראש - שיטה מובנית ופורמלית:

• כל תרחיש מוגדר מראש (steps, expected results).

• ניתן לבצע ידנית או עם כלי אוטומציה.

• נדרש כאשר הפונקציה High Process Risk או High Device Risk.

לדוגמה:

• בדיקות תיוג אוטומטי של מוצרים.

• בקרת טמפרטורה בתהליך קריטי.

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

כוללת גם דרישות ל:

• עקיבות

• חזרתיות

• מוכנות למבדק

2. Unscripted Testing - בדיקות לא מתוסרטות (דינמיות) - מבוססות על ניסיון וחשיבה יצירתית ונהדרות לפונקציות עם Not High Process Risk. מתחלקות ל:

• Scenario Testing – בדיקות תרחיש (או "בדיקות אד-הוק") שבודקות רצף פעולות שימושיות לפי שימוש אמיתי, בלי סקריפט קשיח.
• Error Guessing – "ניחוש שגיאות" - בודקים על בסיס ניסיון עבר, תקלות ידועות, מאגרי באגים וכו'.
• Exploratory Testing – בדיקות גילוי/חקר - בודקים "תוך כדי תנועה" ומגלים תקלות דרך שימוש פעיל ותגובה מיידית.

איזו גישה בוחרים?

ה-FDA מציע לשלב גישות:

• High Process Risk ← לרוב יידרש בדיקה סקריפטית מלאה, או שילוב עם exploratory testing.

• Not High Process Risk ← ניתן להסתפק ב-unscripted בלבד - תיעוד קל, מהיר, מותאם לתהליך.

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

מה לא חייבים?

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

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

מה חובה לתעד?

ה-FDA מדגיש שהדגש הוא לא על הכמות, אלא על הרלוונטיות של התיעוד:

כל פעילות CSA חייבת לכלול תיעוד של:

1. השימוש המיועד של הפונקציה.

2. רמת הסיכון שנקבעה (עם נימוק).

3. סוג הבדיקה שבוצעה (סקריפט, אקספלורטורי, וכו').

4. מי ביצע, מתי, מה היו התוצאות, ואיך טופלו סטיות אם היו.

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

ומה לגבי Part 11?

המסמך מתייחס גם להיבטים של אימות תיעוד אלקטרוני וחתימות דיגיטליות תחת 21CFR Part 11:

• רק אם מדובר ברשומות שמחייבות חתימה לפי Part 820 יחולו על התיעוד הזה דרישות Part 11.

• לא כל לוג נחשב לרשומה רגולטורית.

אז מה עושים עכשיו?

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

2. מפסיקים ליישם ולידציה לפי סעיף 6 של המסמך הישן.

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

4. שואפים לנצל את CSA כדי לאמץ טכנולוגיות חדשות במקום לחשוש מהן.