IEC 62304 ו-ISO 14971: אסטרטגיית סיכון משולבת למחזור חיים תוכנה

IEC 62304 (מחזור חיים תוכנת מכשיר רפואי) ו-ISO 14971 (ניהול סיכון מכשיר רפואי) בדרך כלל מופעלים כשני תהליכים נפרדים על-ידי שני צוותים נפרדים בחברות מכשירים רפואיים. תוצאת התאימות עוברת audit. ה-artefacts שהם מפיקים חופפים בערך ב-60%, לעיתים קרובות חולקים על פרטים, ודורשים עבודת התאמה מתמשכת שאף אחד לא מתקצב. הצוותים שמשלבים את שני התהליכים למחזור חיים תפעולי אחד שולחים מהר יותר ועם ראיות חזקות יותר.

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

למה הסטנדרטים בדרך כלל מופרדים

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

בחברת מכשירים רפואיים טיפוסית, זה מתבטא כ:

• קובץ ניהול סיכון בבעלות הצוות הרגולטורי או צוות האיכות, מעודכן באבני דרך מרכזיות.
• תהליך פיתוח תוכנה בבעלות ההנדסה, עם מסמכים משלו (SDP, SRS, SDD, תוכניות בדיקה, דוחות בדיקה).
• העברה בין השניים ב-design transfer, בשלב שבו ההנדסה מזהה סיכוני תוכנה שצוות הסיכון משלב בקובץ הסיכון.

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

דפוס האינטגרציה

מחזור חיים משולב של IEC 62304 + ISO 14971 מתייחס לניתוח סיכוני תוכנה (62304 §7) ולניתוח הסיכון (14971 §5) כפעילות יחידה שמפיקה מרשם אחד, עם כל המאפיינים הנדרשים של שני הסטנדרטים שנלכדים בשורה אחת.

שורה טיפוסית ברשומה המשולבת הזה כוללת:

• תיאור הסיכון (vocabulary של 14971)
• רצף אירועים המוביל לנזק (14971 §5.5)
• נזק וחומרה (14971 §5.6)
• סבירות התרחשות הנזק (14971 §5.7)
• גורם תוכנה (62304 §7.2): איזה פריט תוכנה או אינטראקציה הם הגורם
• סיווג בטיחות תוכנה של פריט התוכנה המעורב (62304 §4.3): A, B, או C
• אמצעי בקרת סיכון (14971 §6 ו-62304 §7.4)
• סיכון שיורי והחלטת קבלה (14971 §7)
• ראיות אימות (מספר test case, מספר דרישה, מספר אלמנט תכנון)

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

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

מה זה משנה במחזור החיים

שלוש פעילויות מחזור חיים משנות צורה תחת הדפוס המשולב:

ניתוח דרישות תוכנה (62304 §5.2). הדרישות חייבות להיות עם מעקב לאמצעי בקרת סיכון מהרשומה המשולבת. דרישה מהצורה "המערכת תציג אזהרה אם דופק עולה על X" חייבת להיות עם מעקב לסיכון, לנזק, לחומרה, ולרציונל לבחירת בקרה זו. דרישות שאינן עם מעקב לרשומה או צריכות הצדקה לא-בטיחותית או לא שייכות.

תכנון אדריכלי תוכנה (62304 §5.3). הארכיטקטורה חייבת לשקף את סיווגי הבטיחות. פריטים מסווגים C לא יכולים להיות מוחלפים בקלות על-ידי פריטי class A בגבול. הפרדה של פריטים לפי סיווג (62304 §5.3.5) היא תכונה מבנית שהארכיטקטורה חייבת לתמוך בה. סיווגי הרשומה מניעים החלטות ארכיטקטורה, לא רק תיעוד.

פעילויות אימות וולידציה. מקרי בדיקה עם מעקב לדרישות, דרישות עם מעקב לבקרות סיכון, בקרות סיכון עם מעקב לסיכונים. ראיות האימות הן ההוכחה שהבקרות עובדות, וזה מה ש-14971 §6 דורש ומה ש-62304 §5.7 דורש דרך שפה אחרת. בדיקה אחת מפיקה ראיות לשני הסטנדרטים.

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

מה נשאר נפרד

האינטגרציה לא טוטאלית. כמה אלמנטים נשארים נפרדים כראוי.

תוכנית ניהול הסיכון (14971 §4.4) ותוכנית פיתוח התוכנה (62304 §5.1.1). אלה מסמכי ניהול שמגדירים היקפים שונים. אסור למזג אותם. תוכנית ניהול הסיכון מכסה את כל המכשיר. ה-SDP מכסה את פעילויות פיתוח התוכנה. הם cross-reference זה לזה אבל נשארים נפרדים.

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

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

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

איפה AI מסבך את התמונה

ל-SaMD עם רכיבי AI, מחזור החיים המשולב לוקח את ממדי הסיכון הספציפיים-ל-AI שכוסו בכתבת חוק ה-AI האירופי: bias, distribution shift, automation bias, ירידת ביצועים. אלה מרחיבים את קטגוריות הסיכונים של 14971. סיווג בטיחות התוכנה של 62304 אינטראקציה עם רכיבי ה-AI ספציפית. רכיב הסקה של AI שתורם להחלטה class C הוא בעצמו class C, עם הקפדנות המקבילה של מחזור החיים.

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

איפה אנחנו נכנסים

תחום ה-MedTech של פליקן-טק בונה את מחזור החיים המשולב של 62304 + 14971 כתוכנית נמסרת, עם רשומת הסיכון המשולב, מטריצת המעקב, ו-artefacts מחזור החיים מיוצרים דרך תהליך אחד. אנחנו עובדים עם צוות ה-QMS שלנו כשמערכת האיכות הבסיסית של ISO 13485 צריכה ליישר עם מחזור החיים המשולב, ועם צוות הרגולציה ואישורים שלנו כשהראיות שמתקבלות חייבות להיאסף להגשות 510(k) או MDR.

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