מסגרת עולמית לניהול מחזור החיים של מכשירים רפואיים מבוססי בינה מלאכותית: מה פרסם IMDRF ומה זה אומר עבורכם

מה קרה ולמה זה חשוב

בתחילת אפריל 2026 פרסם ה-IMDRF, הפורום הבינלאומי של רגולטורים למכשירים רפואיים, טיוטת מסמך הנחיה בשם:

IMDRF/AIML WG/N93 DRAFT: Technical Framework for Artificial Intelligence Life Cycle Management

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

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

הגיון המסגרת: מחזור חיים

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

שמונת שלבי מחזור החיים הם:

1. Planning and Design - תכנון ועיצוב

2. Data Collection and Management - איסוף וניהול נתונים

3. Model Building and Tuning - בניית וכיוון המודל

4. Verification and Validation including Clinical Evaluation - אימות, תיקוף והערכה קלינית

5. Deployment - פריסה

6. Operations and Monitoring - תפעול וניטור

7. Real-World Performance Evaluation - הערכת ביצועים בעולם האמיתי

8. Sunsetting - פרישה מהשוק

המבנה הזה מזכיר מאוד את הגיון ה-Total Product Life Cycle שכבר מוכר מה-FDA ומ-IEC 62304, אבל כאן הוא מותאם לאתגרים הייחודיים של AI: נתונים משתנים, מודלים משתנים, והאינטראקציה בין המכשיר לבין מקבלי ההחלטות הקלינית.

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

מה חדש ומה שונה לעומת מה שכבר ידוע

אחת השאלות הראשונות שעולות היא: מה המסמך הזה מוסיף מעבר למה שכבר מוכר מ-ISO 13485, IEC 62304 ומהנחיות SaMD של IMDRF?

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

דוגמה 1 - סיכוני המידע: המסמך מגדיר קטגוריה נפרדת של סיכונים שנקראת "Risks Related to Information" שכוללת פלטים מטעים ואי-הצגה מלאה של הסתברות לשגיאה. זה לא קיים בניהול סיכונים סטנדרטי לפי ISO 14971.

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

דוגמה 3 - Data Drift: מה קורה כשהנתונים שמגיעים למכשיר בשטח שונים ממה שהמודל אומן עליהם? המסמך מגדיר את ה-Data Drift כסיכון ייחודי ל-AI שדורש ניטור שוטף ומנגנוני תגובה מוגדרים מראש.

נתונים: הלב הפועם של כל מכשיר AI

אחד הפרקים המפורטים ביותר במסמך עוסק בניהול נתונים. זה לא מקרי: AI is only as good as its data, וה-IMDRF מבין את זה לעומק.

הדרישות המרכזיות שעולות מהפרק:

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

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

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

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

הבנייה וכיוון המודל: מפשטות ועד LLMs

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

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

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

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

פריסה ומה שקורה אחרי: הניטור הוא לא אופציה

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

Deployment Approach. המסמך ממליץ על פריסה בשלבים (Phased Release). הסיבה: ביצועי המכשיר על אוכלוסיות אמיתיות יכולים להיות שונים משמעותית מהביצועים שנמדדו בפיתוח. פריסה הדרגתית מאפשרת לזהות בעיות לפני שהן מגיעות לכל המשתמשים.

Predetermined Change Control Plans (PCCPs). זהו כלי שה-FDA פיתח ומשקף כעת גם ב-IMDRF: יצרן יכול לתאר מראש אילו שינויים במודל יאושרו ללא בקשת אישור רגולטורי חדשה. זה מאפשר גמישות תפעולית תוך שמירה על פיקוח רגולטורי.

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

שקיפות ותיוג: יותר ממה שרגילים

פרק השקיפות ממחיש כמה ה-AI משנה את מה שציפינו מ-IFU ותיוג.

לפי המסמך, תיוג מכשיר AI צריך לכלול בין היתר:

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

• ביצועי המכשיר לפי תתי-קבוצות (Subgroup Performance)

• תנאי הבדיקה לפני השוק והנתונים שנעשה בהם שימוש

• הסבר כיצד לפרש את הפלט ומה המגבלות

• פרטים על שימוש במודלים כלליים חיצוניים

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

מה זה אומר בפועל: נקודות פעולה לארגונים

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

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

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

אם אתם כבר בשוק: המסמך מחייב לחשוב מחדש על תוכניות ה-PMS הקיימות שלכם. האם הן מכסות drift detection? האם הגדרתם Performance Indicators כבר בשלב הרגולטורי?

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

לסיכום - מסמך שמחייב קריאה

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

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

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