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

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

2020-08-11T12:34:29+00:00נובמבר 29th, 2015|

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

כאשר מדובר באמ”ר בעל רכיבי תכנה, מומלץ כי מפתחי המכשור הרפואי והיצרנים ינהלו רישום ותיעוד מדויק של כל המידע הקשור בתכנה כפי שנדרש ע”י מערכות האיכות (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.

מחקר ופיתוח

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

קרא עוד

תכנון והנדסה

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

קרא עוד

ייצור ואריזה

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

קרא עוד

GXP, איכות וולידציה

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

קרא עוד

רגולציה ורישום

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

קרא עוד

תוכנה ומערכות

יעוץ בתחומי הבריאות הדיגיטלית, פיתוח תוכנות ואפליקציות רפואיות בהתאם לדרישות ה- 21CFR part 11/Annex 11/HIPAA/GDPR, ISO 13485/27001/27799, CE marking, Risk Assessment, וריפיקציה וולידציה לתוכנה ומערכות בקרה ועד לקבלת אישור שיווק.

קרא עוד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לפרטים נוספים






For further details






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

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

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

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

מאמר זה נכתב ע"י ערן יונה CEO, מומחה GXP וטכנולוגיות יצור

למעלה מ- 20 שנות ניסיון רב-תחומי מתעשיות הפארמה והמדיקל

אנו בחברת Bio-Chem מייעצים כבר יותר מ- 13 שנה לחברות ביו-מד.

לייעוץ בנושא רישום אמ"ר, פנו אלינו.

ליצירת קשר לחץ כאן

072-2337710

info@bio-chem.co.il

מאמרים אחרונים

אסטרטגיית הבטחת איכות ובדיקות QA לתוכנה רפואית

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

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

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

חוק הגנת הפרטיות ואבטחת מידע רפואי

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

מהי ביקורת GMP וכיצד ניתן להתכונן אליה?

מה זה GMP? GMP הנו ראשי התיבות של המונח “Good Manufacturing Practice” אשר בשפה העברית קרוי "תנאי יצור נאותים". ה- GMP כולל בתוכו את כל האספקים התיאורטיים של תחום [...]

קרא עוד

מזמינים אותך ליצור קשר

צור קשר