ביוכם - Bio-Chem לוגו

הנחיות לשלב טרום הגשה לרישום אמ”ר מכשור וציוד רפואי המכיל רכיבי תוכנה, תוכנה ואפליקציות רפואיות ב- FDA

הנחיות לשלב טרום הגשה לרישום אמ”ר מכשור וציוד רפואי המכיל רכיבי תוכנה, תוכנה ואפליקציות רפואיות ב- FDA

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

כאשר מדובר באמ”ר בעל רכיבי תכנה, מומלץ כי מפתחי המכשור הרפואי והיצרנים ינהלו רישום ותיעוד מדויק של כל המידע הקשור בתכנה כפי שנדרש ע”י מערכות האיכות (Quality System), הרגולציה ובדרישות התיעוד של ה-FDA המופיעות ב-CFR part 820 21. כמו כן, יש לבצע תהליך Design Control עבור כל שלבי הפיתוח של המכשור הרפואי.

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

המאמר עוסק בהבדל בין וריפיקציה לולידציה (V&V), אלו רמות סיכון של מכשור רפואי קיימות וכיצד קובעים את רמת הסיכון? ועוד.

 

מאמר ראשון בסדרה

מטרתו של מאמר זה לפרט ולהסביר את הדרישות של רשויות הבריאות האמריקאית.

CDRH- Center for Devices and Radiological Health ו-CBER- Center for Biologics Evaluation and Research לחברות המייצרת אמ”ר, אביזרים ומכשירים רפואיים (Medical Device) או תרופה (drug) לפיכך אמורות לעמוד במסגרת בקשת הרישום עבור ציוד/מכשור רפואי הכולל בתוכו רכיבי תוכנה בין אם הם עומדים בפני עצמם (לדוגמא אפליקציה סלולרית או תוכנה רפואית) או אם מהווים חלק מהציוד הרפואי.

 

לאיזה סוג מכשור רפואי מיועד מאמר זה?

מאמר זה מיועד עבור כל ציוד רפואי (אמ”ר) המכיל רכיב אחד או יותר של תוכנה, חלקים, אביזרים נלווים או המורכבים ככלל כ-”ציוד תוכנה”, הכוללים בין היתר:

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

 

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

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

  • הודעות טרום שיווק K510 כאשר מדובר על הגשות רישום רגילות, מקוצרות או מיוחדות
  • Premarket Approval Application – PMA – כאשר מדובר על הגשת רישום למכשור רפואי מסיווג של Class 1 הקשורים לתמיכה ו/או לחיי אדם
  • Investigational Device Exemption – IDE – כאשר מדובר במכשור רפואי שאמור לשמש בהליך בדיקה במסגרת הניסויים הקליניים טרם הגשת ה – PMA
  • Humanitarian Device Exemption – HDE – כאשר מדובר במכשור רפואי אשר אמור להיות בשימוש מצומצם בפחות מ – 4000 חולים בשנה או אמור לסייע בגילוי מוקדם ו/או בתמיכה בחולים בשלב בו המכשיר עדיין נבדק לשימוש

 

כאשר מדובר באמ”ר בעל רכיבי תכנה, מומלץ שמפתחי המכשור הרפואי והיצרנים ינהלו רישום ותיעוד מדויק של כל המידע הקשור בתכנה כפי שנדרש ע”י מערכות האיכות (Quality System), הרגולציה ובדרישות התיעוד של ה-FDA המופיעות ב- 21CFR part 820.

כמו כן, יש לבצע תהליך Design Control עבור המכשור הרפואי. ההמלצות במאמר זה כוללות גם המלצות, הנחיות וסטנדרטים נוספים כפי שמתוארים ב-ISO 14971 ו-AAMI SW6.

 

ההבדל בין וריפיקציה לולידציה (V&V)

במאמר זה מופיעים שני מושגים יסודיים: וריפיקציה (Verification) וולידציה (Validation) אשר לרוב מכונים Verification Quality System regulation-QSR, אולם מהו ההבדל ביניהם?

וריפיקציה עונה על השאלה הבסיסית “האם אנחנו מתכננים/בונים את המערכת כנדרש?” משמעותו של תהליך הוריפיקציה של תוכנה או אפליקציה הנו תהליך בדיקה אובייקטיבי ומתועד שמטרתו לוודא כי המערכת הממוחשבת/התוכנה/האפליקציה נבנתה כראוי, חסרת באגים וכל הדרישות המפורטות ב-21CFR 820.3 התקיימו.

כאשר מדובר על סביבת פיתוח, אזי תהליך וריפיקציה שהושלם בהצלחה משמעותו כי אופן הפעולה של התכנה או האפליקציה בסוף שלב הפיתוח, עומד בכל דרישות התכנון שהוגדרו בתחילת שלב הפיתוח במסגרת מסמכי האפיון של המוצר ובעקר במסמך ה-System Design Description-SDD שנכתב ע”י החברה.

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

  • הערכה
  • בדיקות סטטיסטיקה ודינאמיקה
  • בקרת קוד ותיעוד קוד
  • בדיקות מודולים
  • בדיקות אינטגרציה

 

אם וריפיקציה עונה על הבסיסית “האם אנחנו מתכננים/בונים את המערכת כנדרש?” הולידציה תענה על השאלה “האם אנחנו מתכננים/בונים את המערכת הנדרשת (עבור הפציינט/הלקוח)?” תהליך הולידציה של תוכנה, אפליקציה או מערכת ממוחשבת הנו תהליך בדיקה אובייקטיבי, מבוקר ומתועד שמטרתו לוודא ברמת סבירות גבוהה כי המערכת הממוחשבת/התוכנה/האפליקציה עומדת בדרישות המשתמש שהוגדרו קודם לכן במסגרת מסמך ה-System Requirements Specifications -SRS.

הטסטים שיכללו בולידציה יכילו לכל הפחות את הטסטים שהוגדרו במסגרת מסמך ה-STP-System Test Plan. תהליך ולידציה שהסתיים בהצלחה מהווה קביעה אובייקטיבית כי מפרטי המכשיר/התוכנה/המערכת עומדים בקנה אחד עם צרכי המשתמש שהוגדרו ועם מטרות השימוש היעודי שלו (כפי המפורט ב- 21CFR 820.3) וכי תכנית הבדיקות (STP) בוצעה במלואה וכל התוצאות עמדו בקריטריוני הקבלה.

כמובן, שאם התוצאות לא עמדו בקריטריוני הקבלה, יש לפתוח חריגות, לבצע חקירות ולהמשיך טיפול במסגרת CAPA-Corrective And Preventive Actions (למידע נוסף ראה מאמר “מערכות הבטחת איכות ו-CAPA“).

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

תוכנית הולידציה אמורה לכסות את כל מחזור החיים של המוצר, כולל לאחר הכנסת והטמעת שינויים כפי שמפורט במסמך ה-SDLC-System Development Life Cycle. ולידצית התוכנה אמורה לבדוק ולאמת את אופן הפעולה של התכנה, המערכת או האפליקציה, והיא מהווה חלק בלתי נפרד מתהליך הולידציה של המכשור הרפואי/המוצר הרפואי הסופי (אמ”ר).

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

 

הגדרה של נזק (פגיעה) מינורי או חמור

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

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

 

הגדרה של רמת הסיכון וסיווג רמות הסיכון של המכשור הרפואי

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

גורמי הסיכון ינותחו וידונו במסגרת ניהול והערכת הסיכונים (Risk Management) ו-ניתוח הסיכונים (Risk Analysis). רמת הסיכון של המכשור הרפואי (אמ”ר) בכללותו תקבע תוך התייחסות גם למקרים של כישלון בפעילות המכשיר, אשר בין היתר יכולים לנבוע מתוכנה או מערכת ממוחשבת לא ולידית, פגמים בתכנונו ועיצובו של המוצר הרפואי או שימוש במכשיר שלא על פי ההתוויה המפורשת.

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

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

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

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

 

רמת סיכון גבוהה

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

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

 

רמת סיכון בינונית

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

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

 

רמת סיכון נמוכה

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

 

קביעת רמת הסיכון

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

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

 

שאלות לקביעת רמת סיכון גבוהה

מספיקה תשובה אחת חיובית המצריכה קביעה של רמת סיכון גבוהה

  1. האם התקן התוכנה/אפליקציה נחשב למוצר בשימוש של אבחון ובדיקה של דגימות דם?
  2. האם התקן התוכנה/אפליקציה מיועד לשימוש בשילוב עם תרופה או תרופה ביולוגית?
  3. האם התקן התוכנת/אפליקציה מהווה אביזר נלווה למכשיר רפואי בעל רמת סיכון גבוהה?
  4. האם כישלון של התקן התוכנה/אפליקציה (לפני הפחתת מפגעים או פעולות מתקנות) עשוי לגרום למוות או פציעה חמורה, לחולה או למפעיל המכשיר? לדוגמא במצבים:
    • התקן התוכנה/אפליקציה של מכשיר המיועד לבקרה על תמיכה בחיי חולה או הארכת חיי חולה
    • התקן התוכנה/אפליקציה יכול לגרום להעברת אנרגיה שעלולה לגרום למותו של החולה דוגמת טיפולי קרינה, דהפיברילטורים, מכשור להסרת גידולים
    • התקן התוכנה/אפליקציה השולט על מתן טיפולים או עירויים היכולים לגרום למוות או לפגיעה חמורה
    • התקן התוכנה/אפליקציה קשור למתן מידע אבחוני שעל בסיסו נקבע טיפול ובמקרה של שגיאה במידע יכול להיגרם מוות או פגיעה חמורה
    • התקן התוכנה/אפליקציה מספק ניטור והתראה על סממני חיים במצבים שנדרשת התערבות רפואית מיידית

 

שאלות לקביעת רמת סיכון בינונית

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

  1. האם התקן התוכנה/אפליקציה קשור לאמ”ר המוגדר ברמת סיכון בינונית?
  2. האם כישלון של התקן התוכנה/אפליקציה (לפני הפחתת מפגעים) יכול לגרום לפגיעה מינורית, לחולה או למפעיל המכשיר?
  3. האם תפעול לקוי, או עיצוב פגום של התוכנה/אפליקציה יכול לגרום לדיאגנוסטיקה שגוייה או לאיחור במתן טיפול רפואי הולם העלול לגרום לפגיעה מינורית בחולה?

 

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

תוכן עניינים

שתפו את המאמר