תוכנה כמכשיר רפואי (SaMD): מתי אפליקציה או מודל AI צריכים אישור רגולטורי

המונח Software as a Medical Device (SaMD) הוגדר על ידי IMDRF, הפורום הבינלאומי של רגולטורים למכשור רפואי: תוכנה שמיועדת למטרה רפואית אחת או יותר, ומבצעת אותה בלי להיות חלק ממכשיר חומרה רפואי. אפליקציה שמנתחת צילום עור ומעריכה סיכון למלנומה היא SaMD. תוכנה שמפעילה משאבת אינסולין מתוך המשאבה עצמה היא תוכנה במכשיר (Software in a Medical Device), וזו קטגוריה אחרת.

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

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

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

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

מערכות Clinical Decision Support הן אזור אפור שמבלבל מייסדים רבים. בארה"ב, חוק 21st Century Cures והנחיית ה-CDS של FDA מוציאים מהגדרת מכשיר חלק מהתוכנות שמציגות המלצות לאנשי מקצוע. ככלל, התוכנה נוטה להיות מחוץ לפיקוח כשהיא מיועדת לאיש מקצוע, אינה מעבדת אותות או תמונות רפואיות, ומאפשרת לרופא לבדוק בעצמו את הבסיס להמלצה בלי להסתמך עליה בעיניים עצומות.

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

ב-FDA, תוכנה רפואית מטופלת במסגרת מדיניות הבריאות הדיגיטלית (Digital Health) והנחיות ייעודיות לתוכנה, ל-Wellness ול-CDS. כשהמוצר הוא מכשיר, המסלול נקבע לפי הסיכון: 510(k) כשיש מכשיר דומה שכבר אושר (Predicate), De Novo למוצר חדשני בסיכון נמוך עד בינוני בלי מקבילה, ו-PMA למוצרים בסיכון גבוה. רוב מוצרי ה-SaMD וה-AI שקיבלו אישור בארה"ב עברו במסלול 510(k) או De Novo.

באירופה, תקנת המכשור הרפואי (MDR) כוללת את כלל 11 (Rule 11), שעוסק ספציפית בתוכנה. הכלל מסווג תוכנה שמספקת מידע לקבלת החלטות אבחוניות או טיפוליות לפי חומרת הנזק האפשרי, ובפועל מעלה תוכנות רבות שהיו בסיווג הנמוך תחת הדירקטיבה הקודמת לסיווג גבוה יותר שמחייב מעורבות של גוף מאשר (Notified Body). למוצרי AI יש להביא בחשבון גם את חוק ה-AI האירופי (AI Act), שחל במקביל.

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

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

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

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

האתגר הגדול הוא שינויים אחרי האישור. מודל שמאומן מחדש הוא, מבחינה רגולטורית, מוצר ששונה. כדי לאפשר שיפור מתמשך בלי הגשה חדשה על כל עדכון, FDA פיתחה את מנגנון Predetermined Change Control Plan (PCCP): תוכנית שמוגשת מראש ומפרטת אילו שינויים מתוכננים, איך הם ייבדקו ואיך תוערך השפעתם. שינוי שנמצא בתוך גבולות התוכנית המאושרת יכול להתבצע בלי הגשה חדשה. כדאי לתכנן את זה כבר בגרסה הראשונה.

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

• IEC 62304: מחזור חיי תוכנה רפואית, כולל סיווג בטיחות, דרישות, ארכיטקטורה, בדיקות וניהול תצורה.
• ISO 13485: מערכת ניהול איכות למכשור רפואי, כולל בקרת תכן (Design Controls) ותיעוד.
• ISO 14971: ניהול סיכונים לאורך כל חיי המוצר, כולל סיכונים שנובעים מטעויות המודל.
• סייבר: FDA מצפה לתיעוד אבטחת מידע בהגשה (מודל איומים, רשימת רכיבי תוכנה SBOM ותוכנית לעדכונים), וגם באירופה האבטחה היא חלק מהדרישות הכלליות.
• פרטיות: מידע רפואי הוא מידע רגיש במיוחד. בישראל חלים חוק הגנת הפרטיות ותקנות אבטחת המידע, ובשווקים אחרים HIPAA בארה"ב ו-GDPR באירופה. שימוש בדאטה קליני לאימון מודל דורש בסיס חוקי ואישורים מתאימים.

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

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

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

WeCcelerate היא Venture Builder ישראלי שפועל מאז 2018 בתל אביב ובירושלים, ומוכרת על ידי רשות החדשנות. מסלול ה-MedTech פועל בשותפות עם לאומית שירותי בריאות ומעניק למייסדים מומחיות קלינית, ליווי רגולטורי, גישה לדאטה והזדמנויות לפיילוט.

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