כיצד ליישם ניתוח פערים בתוכנה מדור קודם כנדרש על ידי IEC 62304-2015?

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

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

מהי תוכנה מדור קודם?

תוכנה מדור קודם היא סוג של תוכנה שכבר קיימת במכשיר רפואי שהוצג לשוק לפני 2006, כאשר הגרסה הראשונה של IEC 62304 נכנסה לתוקף, והיא עדיין משווקת כיום. למרות שחלפו כבר 15 שנה, עדיין ניתן להיתקל במצבים כאלה.

תוכנה מדור קודם לעומת SOUP

לעיתים תוכנה מדור קודם מזוהה בטעות כ-SOUP (תוכנה ממקור לא ידוע). הבלבול נובע מכך ששתיהן פותחו ללא עמידה ותיעוד של תהליכי מחזור החיים של התוכנה.

כיצד להתאים תוכנה מדור קודם לתקן IEC 62304?

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

1. לא יהיו שינויים בתוכנת המכשיר הרפואי, כולל תוכנה מדור קודם

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

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

הרשה לי להמחיש זאת בדוגמה. נניח שלפני 15 שנה חברה כלשהי שחררה מכשיר רפואי המשמש להצגת נתונים חזותיים, כמו מוניטור ECG. הדרייבר של מכשיר זה לא נבנה בהתאם לדרישות IEC 62304 מכיוון שהתקן טרם היה בתוקף. כעת עולה צורך לשנות את הצבעים שהוא מציג. במקרה כזה, אין צורך לבצע שינויים כלשהם בדרייבר מכיוון שהוא יתקשר עם המוניטור באותו אופן, פשוט הפקודות הנוגעות לצבעים המוצגים יהיו שונות. דרייבר כזה יכול להיחשב כ-SOUP.

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

2. יחולו שינויים בתוכנת המכשיר הרפואי ו/או בתוכנה הוותיקה

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

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

גישה נוספת היא לנתח ולהעריך את תוכנת המורשת בהתאם לתקן IEC 62304, בפרק 4.4 ליתר דיוק. הוא אומר שתוכלו לבצע פיתוח עיצוב מלא בהתאם לכל הדרישות המתוארות בפרקים 5-9, ולכן אין צורך לעשות דבר נוסף בנוגע לתוכנת המורשת. עם זאת, יש חיסרון משמעותי אחד לגישה זו: היא מייצרת עלויות גבוהות מאוד.

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

כיצד להתאים את התוכנה הוותיקה ל-IEC 62304?

שלב 1: הערכת סיכונים של תוכנה מדור קודם

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

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

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

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

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

השלב הבא הוא ביצוע ניתוח פערים.

שלב 2: ניתוח פערים בתוכנה מדור קודם לפי IEC 62304

לאחר קביעת מחלקת הסיכון של התוכנה הוותיקה שלנו, עלינו לבצע ניתוח פערים ולבדוק שלא חסר לנו תיעוד נדרש בהתאם לפרק 5.2 (דרישות תוכנה), 5.3 (עיצוב ארכיטקטורת תוכנה), 5.7 (בדיקות מערכת תוכנה) ו-7 (תהליכי ניהול סיכוני תוכנה).

לכל הפחות, התוכנה הוותיקה שלנו צריכה:

• לעמוד בדרישות בנוגע לפונקציונליות, יעילות, בטיחות וכו' כפי שמתואר בפרק 5.2;

• ייכלל בתיעוד הארכיטקטורה של התוכנה עם תיאור ברור של גבולותיו, של רכיבי הבידוד והאינטגרציה וכן של תוכנית האינטגרציה עם רכיבים אחרים, כולל סיכונים אפשריים הקשורים למחלקותיהם בהתאמה, בהתאם לפרק 5.3;
• כל הבדיקות הנדרשות מבוצעות ומתועדות בהתאם לפרק 5.7;
• לקיים את תהליכי ניהול הסיכונים כנדרש בפרק 7.

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

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

לסיכום

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

למידע נוסף על ביצוע ניתוח פערים בתוכנה מדור קודם, אנא עיין ב-IEC 62304.

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