מה הסיפור של MBD? ואיך זה מתקשר לתעשיית המכשור הרפואי?
וואו, כמה אתגרים עומדים בפני מפתחים מרגע בו ניצת רעיון ועד לפיתוח של המוצר בפועל. לו רק הייתה מתודה סדורה באמצעותה יכלו לפתח את המוצרים באופן פשוט יותר……
אם נמקד את האתגרים איתם מתמודדים מפתחים ומהנדסים בתעשיית המדיקל, נוכל לומר ש:
- כמו בפיתוח של כל מוצר, אבל בפרט עבור מוצרים רפואיים – מדובר במוצרים מאוד מורכבים .
יש להם מספר גבוה של חיישנים, אלגוריתמים מתקדמים, ומצריכים יכולות חישוב מאוד גבוהות. המורכבות הזו, מעלה את הסיכון לטעויות בתכנון ובפיתוח מאוד. - מכשירים רפואיים כוללים מספר רב של דיסציפלינות, רכיבים חשמליים, מכניים, כימיים, רכיבי תוכנה ועוד. מה שמוביל לאתגר מאוד משמעותי בנושא האינטגרציה והשילוב ביניהם.
- בנוסף לכל, כמו שאנו יודעים גופי הרישוי מחייבים את חברות הפיתוח הרפואיות לפעול בצורה מאוד מסוימת, כלומר עליהם לשלב תהליכי וורפיקציה ובדיקות סבוכים מאוד תוך כדי הפיתוח עצמו.
כשלא עובדים לפי תהליך עבודה מסודר, מאוד קל בפרט בפיתוח של מוצרים מורכבים כמו מוצרים רפואיים, "להתבדר". משמעות הדבר יכולה לבוא לידי ביטוי בהפסדים עצומים של כסף, recalls, וזאת מבלי לדבר כלל על פיתוח מוצרים עם השלכות מסכנות חיים.
במסגרת מחקר של ה-FDA שחקר כיצד ניתן להפחית את כמות ה-recalls והשגיאות של מוצרים רפואיים ולשפר את הפיתוח עצמו של המוצרים, ה-FDA חבר לחברת MathWorks, והם שיתפו פעולה על מנת לחקור כיצד ניתן לשפר את תהליך הפיתוח של מוצרים רפואיים בצורה שתבטיח פחות שגיאות כבר במהלך הפיתוח עצמו, בשלבים מוקדמים ככל הניתן.
הפתרון אשר נחקר והתקבל על ידי ה-FDA הוא פיתוח בגישת MBD (Model-Based Design) כדרך לשפר את הבטיחות של המוצרים הרפואיים, תוך שימוש בשיטות פורמליות ותהליכי V&V סדורים בתהליך הפיתוח.
אז מה הרעיון שעומד מאחורי MBD?
כשאנחנו מסתכלים על תהליך פיתוח מסורתי, הוא כולל את שלב המחקר, הדרישות, המעבר לצוותי הפיתוח השונים ולאחר מכן למימוש ולאינטגרציה – ואנחנו נתקלים לאורכו בהמון מצבים של חומות ומחסומים בין השלבים השונים בפיתוח:
- הדרישות כתובות לרוב בצורה טקסטואלית והרבה פעמים באופן לא ברור. צוותי הפיתוח לא תמיד מבינים מה עליהם לעשות במדויק (באופן מובן, המפרט הוא בסופו של דבר מסמכי נייר, וקל לפירוש שגוי).
- כמו כן, קשה לעקוב אחר המפרט לתכן וקשה לנתח ולנהל את הדרישות המורכבות, שכן הן משתנות (בהכרח) במהלך מחזור התכנון והפיתוח
- צוותי הפיתוח השונים – עובדים בכלים שונים ובשיטות שונות, ולרוב לא משתפים פעולה אחד עם השני – ולמעשה האינטגרציה מתבצעת רק כאשר כל קבוצה כבר סיימה את העבודה שלה.
- בשלב הזה, עבור כל בעיה שמתגלית לוקח המון זמן לתקן אותה, ורק בשלב זה צוותי הפיתוח מתאחדים כדי לפתור אותה.
- בשלב המימוש או המעבר מאלגוריתם לקוד שיכול לרוץ על גבי מעבד, נתקלים באתגר נוסף: במעבר משפת תוכנה או מידול אחת לשפת קוד – קידוד מחדש זה נעשה באופן ידני על ידי צוותים שונים של אנשים – מה שעלול לגרום לתקלות ולשגיאות שנגרמים מכך שהתכנון אינו מתפרש כהלכה, שגיאות ששוב – יתגלו רק בשלב הבדיקות הסופי – ושמגיעים לשלב האינטגרציה והבדיקות לכל בעיה ושגיאה לוקח הרבה זמן רב לעלות על המקור שלה ולתקן אותה. האם מדובר בתקלת קידוד? בעיית אלגוריתם? דרישות מתנגשות?
- בדיקת המערכת המלאה לא מתרחשת עד לשלב האינטגרציה – בשלב הבדיקה הסופית , מופיעות רוב הבעיות, מכיוון שזו הפעם הראשונה שבה מערכות משולבות. השגיאות שנמצאו בשלב זה הן מאוחרות והן יקרות לתיקון. וכאן כבר מדובר על עלויות מאוד גבוהות של שגיאות – ייקח המון זמן למצוא אותן, זמן ששווה המון כסף.
הרעיון בMBD הוא להצליח ליישם את הקוד\פרויקט\מוצר שלנו בצורה יעילה ומהירה יותר – תוך שימוש בכלים ויזואליים לבניית הארכיטקטורה, הרצת סימולציות ומציאת שגיאות, וכן הורדת טעיות האנוש בקידוד על ידי יצירת קוד בצורה אוטומטית.
כך, ניתן לעלות על הבאגים והשגיאות בשלבים הרבה (הרבה) יותר מוקדמים – כבר בשלב התכן ועם Shift left לשלב התחלתי כמו בניית הדרישות.
והדובדבן שבקצפת: מתודת העבודה הזו יושבת אחד לאחד על הציפיות והנקודות שהגופים הרגולטוריים צריכים לבדוק על מנת לאשר מוצרים, ולמעשה מקלה על תהליך קבלת הסרטיפיקציה של המוצרים לעמידה בתקנים השונים (כולל בתקני הבטיחות, כמו למשל IEC 62304).
איך זה נראה בפועל?
יש לנו מודל דיגיטלי שנמצא בלב הפיתוח.
למשל בדוגמא הבאה ניתן לראות מודל של מערכת הנשמה רפואית. (והיא זמינה לשימושכם! זו נקודת פתיחה מעולה לעבודה).
המודל כולל תתי מערכות של השסתומים, בקרי Real-Time, מסכת ההנשמה, והמידול של הפציינט (ריאות וקנה הנשימה).
בגישת MBD, המודל נולד ונוצר מתוך הדרישות – למעשה, הוא מהווה למסמך חי ובר הרצה של דרישות המוצר.
הדרישות מקושרות בקישור דו כיווני למודל, מה שמאפשר מעקב מלא בין המימוש לבין הדרישה.
כל קבוצה בתורה מצוותי הפיתוח – ובמקביל לקבוצות האחרות – נחשפת לדרישות המתאימות, אך רואה גם את כלל הקונטקסט ולא רק את החלק שלה.
למעשה כבר כאן מתחילה אינטגרציה של מודלי הסימולציה במערכת – גם של הרכיבים הפיזיים השונים במערכת וגם של האלגוריתמים.
המעבר למימוש על גבי מעבדים מבוצע באופן אוטומטי, בהתאם להגדרות הפרויקט והבטיחות, והקוד שנוצר הוא מתועד בהתאם לתקן, וכמובן מקושר בצורה מלאה למודל שממנו נוצר – ומשם חזרה עד לדרישות.
האינטגרציה למעשה כבר בוצעה בשלב המודלים וכעת בבדיקות הסופיות כל מה שנותר הוא לאשש את תקינות המערכת והימצאות שגיאות.
אבל אל תסמכו עליי, תראו איך חברת Weinmann Emergency Medical הגרמנית פיתחה מכונת הנשמה ניידת על ידי שימוש בגישת MBD, ומה יש לה להגיד על זה.
תרצו לשמוע עוד על הנושא? צרו אתנו קשר ונשמח לעזור לכם להגיע למטרות שלכם
למידע נוסף:
