מה ה-FDA מחדד ב-2026 לגבי Clinical Decision Support Software, ומה זה אומר עבור מערכות AI רפואיות?
יותר ויותר חברות מפתחות כיום מערכות AI שמטרתן לתמוך בהחלטות קליניות: להציג אפשרויות טיפול, להתריע על אינטראקציות בין תרופות, לנתח מידע רפואי, או לספק המלצות שמסייעות לרופא בקבלת החלטות.
במקרים רבים, המוצרים האלה מוגדרים כ-Clinical Decision Support, או בקיצור CDS. אבל כאן בדיוק מתחיל הבלבול.
לא כל מערכת שמוגדרת כ-CDS נשארת מחוץ לרגולציית מכשור רפואי. Guidance שפורסם על ידי ה-FDA בינואר 2026, ואשר חודד שוב ב-Town Hall ייעודי שנערך במרץ 2026, מבהיר בצורה ברורה יותר מתי תוכנת CDS יכולה להיחשב כ-Non-Device, ומתי היא כבר תסווג כ-Medical Device לכל דבר.
המשמעות לחברות היא מהותית. זו לא רק שאלה משפטית או רגולטורית, אלא החלטה שמשפיעה על הגדרת המוצר, על תהליך הפיתוח, על התיעוד, על הוולידציה, ועל מסלול החדירה לשוק.
האם כל CDS הוא Medical Device?
לא.
ה-FDA מבהיר שלא כל פונקציית תוכנה שמוגדרת כ-CDS נחשבת אוטומטית למכשיר רפואי. כדי שתוכנה תיחשב כ-Non-Device CDS, עליה לעמוד בכל ארבעת הקריטריונים המוגדרים ע”י הרגולטור.
אם אפילו אחד מהקריטריונים אינו מתקיים, הפונקציה כבר לא תיחשב ל-Non-Device CDS, והיא עשויה להיכנס להגדרת Medical Device ולהיות כפופה לדרישות רגולטוריות מלאות.
זו נקודה קריטית. בפועל, הרבה חברות נשענות על ההגדרה השיווקית של המוצר כ-“תומך החלטה”, מבלי לבחון לעומק האם הפונקציונליות עצמה באמת עומדת בתנאים שה-FDA מציב.
ארבעת הקריטריונים שקובעים אם CDS נשאר מחוץ לרגולציית מכשור רפואי
1. התוכנה לא מיועדת לרכוש, לעבד או לנתח תמונה רפואית או אות ביו-רפואי
אם המערכת מנתחת תמונות כמו CT, MRI או X-ray, או עובדת ישירות על אותות כמו ECG, סיגנלים פיזיולוגיים או פלט ממערכות IVD, היא לא תעמוד בקריטריון הזה.
זהו אחד המקומות המרכזיים שבהם מערכות AI רפואיות נופלות. ברגע שהתוכנה לא רק מציגה מידע רפואי אלא מנתחת אותות או דפוסים שמקורם במדידה רפואית, הסבירות שתסווג כ-Device עולה משמעותית.
2. התוכנה מיועדת להציג, לנתח או להדפיס מידע רפואי
כאן מדובר במידע כמו תוצאות בדיקות מעבדה, מידע על המטופל, ספרות רפואית, הנחיות קליניות, או מידע רפואי מקובל אחר.
כלומר, הפונקציה יכולה לעבוד עם מידע רפואי, אבל לא עם raw signals או imaging data במובן שמכניס אותה לעיבוד ביו-רפואי ישיר.
3. התוכנה מיועדת לתמוך באיש מקצוע רפואי, לא להחליף את שיקול דעתו
התוכנה יכולה לספק המלצה, הצעה או תמיכה בהחלטה. אבל היא לא אמורה לכוון את ה-HCP לפעולה באופן שמייתר שיקול דעת קליני עצמאי.
ככל שהפלט יותר חד-משמעי, יותר אבחנתי, יותר טיפולי, או יותר time-critical, כך קשה יותר לטעון שמדובר רק בתמיכה בהחלטה.
4. איש המקצוע חייב להיות מסוגל לבחון באופן עצמאי את הבסיס להמלצה
זהו אולי הקריטריון המשמעותי ביותר בעולם של AI.
ה-FDA מחדד שהרופא צריך להיות מסוגל להבין, לבקר ולהעריך את ההיגיון או הבסיס שעליו נשענת ההמלצה. לא מספיק שהתוכנה תאמר מה לעשות. צריך שה-HCP יוכל להפעיל שיקול דעת עצמאי ולא להסתמך על הפלט באופן עיוור.
כאשר הבסיס להמלצה אינו שקוף מספיק, כאשר המודל אינו ניתן להבנה מספקת, או כאשר ממשק המשתמש דוחף להחלטה מהירה מבלי לאפשר בחינה אמיתית, קשה יותר לעמוד בקריטריון הזה.
דוגמאות לפונקציות שיכולות להיחשב Non-Device CDS
פונקציות שעשויות להישאר מחוץ לרגולציית מכשור רפואי הן בדרך כלל כאלה שבאמת תומכות ב-HCP, מבלי לנתח אותות רפואיים ומבלי להחליף שיקול דעת.
לדוגמה:
- התראות על אינטראקציות בין תרופות
- תזכורות לטיפול מונע
- order sets המבוססים על evidence
- סיכומי מידע קליני
- דו”חות מידע על מטופל לצורך תמיכה בהחלטה
- הצגת אפשרויות טיפול לשיקול קליני
גם כאן חשוב לזכור:
לא מספיק שפונקציה תיראה “פשוטה”. היא חייבת לעמוד בפועל בכל ארבעת הקריטריונים.
דוגמאות לפונקציות שסביר יותר שייחשבו Device CDS
ברגע שהמערכת עוברת מעולם של תמיכה כללית לעולם של עיבוד רפואי ישיר, פלט אבחנתי או המלצה שלא באמת ניתנת לביקורת עצמאית, היא כבר נעה לכיוון Device.
דוגמאות בולטות כוללות:
- תוכנות שמנתחות CT, MRI או ECG
- מערכות שמפיקות אבחנה ישירה למחלה ספציפית
- תוכנות שמזהות שבץ, אוטם או מצבים אקוטיים אחרים
- מחשבוני מינון תרופתי דוגמת אינסולין
- מערכות שפועלות בסביבה time-critical ומובילות לפעולה מיידית
במקרים כאלה,
ההגדרה של המוצר כ-“CDS” לא תספיק כדי להוציא אותו מתחום הרגולציה של מכשור רפואי.
מה באמת חדש ב-2026
ה-CDS עצמו לא חדש, וגם לא עצם קיומם של ארבעת הקריטריונים. מה שהתחדד ב-2026 הוא בעיקר אופן הפרשנות והיישום שלהם, במיוחד בעידן של AI ו-ML.
שקיפות ויכולת ביקורת של ה-HCP
ה-FDA שם דגש חזק יותר על השאלה האם הרופא באמת יכול להבין את הבסיס להמלצה. זו לא שאלה תיאורטית. זו שאלה מעשית שמשפיעה ישירות על סיווג המוצר.
Automation bias
ה-FDA מתייחס במפורש לסיכון שרופאים עלולים לסמוך יותר מדי על פלט של מערכת, גם כאשר הם אמורים להפעיל שיקול דעת עצמאי. לכן, גם אם HCP נשאר “בלולאה”, זה לא בהכרח מספיק. אם בפועל המערכת דוחפת אותו להסתמך על הפלט בלי יכולת ביקורת אמיתית, קשה יותר להצדיק סיווג כ-Non-Device CDS.
הבחנה חדה יותר בין מידע רפואי לבין signals, patterns ו-imaging
ה-Guidance מחדד שעיבוד של אותות, דפוסים ותמונות רפואיות הוא קו גבול משמעותי. מערכות רבות שמבוססות AI עושות בדיוק את זה, ולכן מתקשות להישאר מחוץ לרגולציית מכשור רפואי.
משמעות ישירה למערכות AI
בעולם של מודלים מורכבים, black box מסוים, או תהליכי inference שקשה להסביר ברמת המשתמש הקליני, העמידה בקריטריון 4 הופכת למאתגרת יותר. לכן, חלק גדול ממערכות ה-AI הרפואיות המתקדמות לא יוכלו להישען בקלות על חריג ה-Non-Device CDS.
הטעות הנפוצה שחברות עושות
אחת הטעויות הנפוצות ביותר היא לנסות להישאר מחוץ לרגולציה דרך ניסוח.
במקום לשאול מה המערכת עושה בפועל, איזה דאטה היא מנתחת, מה מידת העצמאות של ה-HCP, ומה רמת ההסבריות בפלט, חברות רבות מתמקדות בשאלה איך לקרוא למוצר: CDS, clinical assistant, recommendation engine או decision support.
אבל ה-FDA לא בוחן את השם. הוא בוחן את הפונקציונליות האמיתית.
המשמעות היא שהחלטה רגולטורית נכונה חייבת להתקבל כבר בשלבים הראשונים של הפיתוח, ולא רק כאשר מגיעים להגשה או לשלב המסחור.
מה נכון לעשות מוקדם בפיתוח?
כדי להימנע מהפתעות בהמשך, כדאי להכניס חשיבה רגולטורית כבר בשלבי ההגדרה הראשונים של המוצר.
זה כולל בין היתר:
- הגדרה מדויקת של Intended Use
- ניתוח של סוג הדאטה שהמערכת מקבלת ומעבדת
- בחינה של nature of output והאם הוא תומך או מכוון החלטה
- הערכה של explainability ושל יכולת independent review מצד ה-HCP
- בחינה מוקדמת של המסלול הרגולטורי מול FDA ולעיתים גם מול EU MDR
- התאמה של הארכיטקטורה, התיעוד וה-V&V למסלול הצפוי
השלב הזה קריטי במיוחד עבור חברות שמפתחות AI רפואי, כי שינוי מאוחר באסטרטגיה הרגולטורית כמעט תמיד מייצר עיכובים, עלויות נוספות ולעיתים גם צורך בשינוי מוצר.
איך MedDev Soft מסייעת?
ב-MedDev Soft אנחנו מלווים חברות בדיוק בנקודה הזו: בין ההגדרה של המוצר לבין הסיווג הרגולטורי.
אנחנו מסייעים לחברות לבצע מיפוי נכון בין CDS ל-SaMD, להגדיר Intended Use מדויק, להבין מה הסיווג הרגולטורי הסביר של הפונקציה, ולבנות מוצר שהוא regulatory-ready כבר מהשלבים הראשונים.
העבודה הזו לא מתחילה בהגשה לרגולטור. היא מתחילה הרבה קודם, בשאלות הנכונות על פונקציונליות, דאטה, workflow קליני, ושיקול הדעת שנשאר בידי המשתמש.
לסיכום
Guidance 2026 של ה-FDA לא משנה רק את הדרך שבה מגדירים CDS. הוא מחדד בצורה ברורה יותר את הגבול בין תוכנה שיכולה להישאר מחוץ לרגולציית מכשור רפואי לבין תוכנה שכבר נחשבת Device.
עבור חברות שמפתחות מערכות AI רפואיות, זו הבחנה קריטית.
לא מספיק לקרוא למוצר “תומך החלטה”. צריך לבחון לעומק מה הוא עושה, איזה מידע הוא מנתח, איזה פלט הוא מייצר, ועד כמה איש המקצוע באמת יכול להבין ולבקר את ההמלצה.
מי שעושה את זה נכון מוקדם, בונה מוצר מדויק יותר, מפחית חיכוך רגולטורי, ומגיע מוכן יותר לשוק.
