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

ניהול סיכונים (⁦Risk Management⁩) מופיע בתכן ופיתוח, בייצור, בטיפול בתלונות, בדיווח על אירועים ובכל שינוי שנעשה אחרי שהמוצר כבר בשוק. המבנה של התהליך מראה את הקשרים בין כל אלה, ולכן כדאי להכיר אותו לפני שנכנסים לפרטים. סדרת המאמרים הזאת עוברת על התקן ועל המדריך המלווה אותו, סעיף אחרי סעיף.

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

מה התקן מכסה ומה הוא משאיר פתוח

התקן קובע מינוח, עקרונות ותהליך לניהול סיכונים של מכשור רפואי. הוא חל גם על תוכנה כמכשיר רפואי (⁦Software as a Medical Device⁩) ועל מכשירי אבחון חוץ-גופי (⁦In Vitro Diagnostic Medical Devices⁩), והדרישות שלו חלות על כל שלבי מחזור החיים (⁦Life Cycle⁩), מהרעיון הראשוני ועד הוצאה משימוש ופינוי.

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

שני דברים נמצאים מחוץ לתחום:

  • החלטות על שימוש במכשיר בהליך קליני מסוים

  • וניהול סיכונים עסקי.

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

התקן גם לא קובע מהי רמת סיכון קבילה. הוא דורש מהיצרן להגדיר קריטריונים אובייקטיביים לקבילות סיכון (⁦Criteria for Risk Acceptability⁩), וההגדרה נשארת אצלו.

ההנמקה בנספח ⁦A⁩: מגוון המכשירים רחב מדי בשביל רמה אחת, וחוקים, מנהגים ותפיסת סיכון משתנים בין אזורים. לכן ההגדרה הזו היא אחד המסמכים המרכזיים בניהול הסיכונים של הארגון, ולה יוקדש המאמר הבא.

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

סעיף 7 ב-⁦ISO 13485:2016⁩ מתאר את תהליכי מימוש המוצר, ותהליך ניהול הסיכונים צריך להיות משולב בהם.

התהליך במבט אחד

סעיף 4 הוא המערכת שעוטפת את כל השאר: תהליך שמופעל לאורך מחזור החיים (4.1), אחריות הנהלה בכירה (⁦Top Management⁩) להקצאת משאבים ולמדיניות לקבילות סיכון (4.2), כשירות האנשים (4.3), תכנית ניהול סיכונים (⁦Risk Management Plan⁩) לכל מכשיר (4.4) וקובץ ניהול סיכונים (⁦Risk Management File⁩) שמבטיח עקיבות (⁦Traceability⁩) מכל סכנה עד להערכת הסיכון השיורי (4.5).

מעליה רצים הסעיפים הבאים:

  • ניתוח סיכונים (⁦Risk Analysis⁩), סעיף 5: שימוש מיועד ושימוש לרעה צפוי סביר, מאפייני בטיחות, זיהוי סכנות ומצבים מסוכנים, והערכת הסיכון.

  • הערכת סיכונים (⁦Risk Evaluation⁩), סעיף 6: השוואה לקריטריונים שנקבעו בתכנית.

  • בקרת סיכונים (⁦Risk Control⁩), סעיף 7: בחירת אמצעים, יישום ואימות, הערכת סיכון שיורי, ניתוח תועלת-סיכון, סיכונים חדשים שנוצרו מהאמצעים, ושלמות.

  • הערכת הסיכון השיורי הכולל (⁦Overall Residual Risk⁩), סעיף 8.

  • סקירת ניהול הסיכונים (⁦Risk Management Review⁩) ודו"ח ניהול סיכונים (⁦Risk Management Report⁩) לפני שחרור לשוק, סעיף 9.

  • פעילויות ייצור ופוסט-ייצור (⁦Production and Post-Production Activities⁩), סעיף 10.

מידע שמגיע מהשוק חוזר לניתוח, ותוצאות הסקירה מוזנות בחזרה לבדיקת ההתאמה של התהליך עצמו על ידי ההנהלה (4.2).

סעיפים 5 עד 7 מבוצעים לכל מצב מסוכן בנפרד, והתמונה הכוללת נבנית רק בסעיף 8.

מה השתנה במהדורה השלישית

המהדורה השלישית יצאה בדצמבר 2019 עם השינויים העיקריים הבאים:

  • הוגדרו שלושה מונחים חדשים: תועלת (⁦Benefit⁩), שימוש לרעה צפוי סביר (⁦Reasonably Foreseeable Misuse⁩) ורמת הידע המקובלת (⁦State of the Art⁩).

  • יותר דגש על התועלות הצפויות מהמכשיר. המונח ניתוח תועלת-סיכון (⁦Benefit-Risk Analysis⁩) הותאם למינוח שבו משתמשות רגולציות.

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

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

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

  • הדרישות לפעילויות ייצור ופוסט-ייצור פורטו ושונו במבנה שלהן, כולל מקורות המידע והפעולות הנדרשות.

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

מספר נספחים אינפורמטיביים עברו מהתקן אל ה-⁦TR⁩, שנוסח מחדש במקביל.

כך אפשר לעדכן את ההנחיות בתדירות גבוהה יותר בלי לפתוח את התקן.

מושגי יסוד: סכנה, מצב מסוכן, נזק וסיכון

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

מונח

הגדרה בקצרה

סעיף בתקן

נזק (⁦Harm⁩)

פגיעה או נזק לבריאות של אנשים, או נזק לרכוש או לסביבה

3.3

סכנה (⁦Hazard⁩)

מקור פוטנציאלי לנזק

3.4

מצב מסוכן (⁦Hazardous Situation⁩)

נסיבות שבהן אנשים, רכוש או סביבה חשופים לסכנה אחת או יותר

3.5

חומרה (⁦Severity⁩)

מידה של ההשלכות האפשריות של סכנה

3.27

סיכון (⁦Risk⁩)

שילוב של ההסתברות להתרחשות נזק והחומרה של אותו נזק

3.18

בטיחות (⁦Safety⁩) מוגדרת כהיעדר סיכון בלתי קביל (3.26).

הסיכון השיורי (⁦Residual Risk⁩) הוא הסיכון שנותר אחרי יישום אמצעי הבקרה (3.17).

הסכנה היא פוטנציאל בלבד.

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

  • ההסתברות שהמצב המסוכן יתרחש מסומנת ⁦P1⁩

  • וההסתברות שהוא יוביל לנזק מסומנת ⁦P2⁩.

הפירוק אינו חובה.

כשאחד משני הערכים אינו ניתן להערכה, ה-⁦TR⁩ מאפשר גישה שמרנית של הצבת הערך הלא ידוע כ-1 (סעיף 5.5.2).

הדוגמה בתמונה למעלה לקוחה מטבלה ⁦C.3⁩ בתקן.

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

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

בואו ניקח דוגמה נוספת:

תוכנת הדמיה שמציגה תמונה בהיפוך שמאל-ימין. בטבלה ⁦C.1⁩ מופיעים בקבוצת הסכנות הקשורות לביצועים (⁦Performance-Related Hazards⁩) גם מידע אבחוני ובתוכו כיוון התמונה. הסכנה היא מידע אבחוני שגוי. הרצף יכול להיות טעות בעיבוד התמונה ואי זיהוי של הטעות על ידי המשתמש. המצב המסוכן הוא קלינאי שמקבל מידע שגוי ופועל לפיו. הנזק הוא, למשל, טיפול בצד הלא נכון.

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

"באג בתוכנה" הוא סיבה אפשרית ברצף האירועים, ולא הסכנה.

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

  • אירועים ונסיבות כמו פגיעות אבטחה בתוכנה או פריקה אלקטרוסטטית שייכים לרצף האירועים (טבלאות ⁦C.2⁩ ו-⁦C.3⁩), ולא לעמודת הסכנה.

  • הרמה שבה מתארים מצב מסוכן נתונה להחלטת היצרן. כיסוי שהושמט ממסוף מתח גבוה ואדם שנוגע במסוף הם שני תיאורים אפשריים. החשוב הוא שהתיאור מאפשר להעריך הסתברות וחומרה (נספח ⁦C.4⁩).

  • לגבי תקלות שיטתיות (⁦Systematic Faults⁩) ה-⁦TR⁩ מורה להתמקד בבניית מערכות חזקות למניעתן, ולא בניסיון לאמוד את הסתברותן (5.4.5). עוד על כך במאמר על תקלות ותוכנה.

סביבת התקנים

התקן 14971 הוא תקן תהליך, והוא מתחבר לתקנים אחרים בנקודות מוגדרות.

ה-⁦TR⁩ מתאר את הקשרים האלה בנספח ⁦E⁩.

כמה מההבדלים בין התקנים מקבלים משקל מיוחד בעבודה היומיומית:

  • תקן ⁦ISO 13485:2016⁩. תקן מערכת ניהול האיכות. התקן 14971 מפנה אליו בהערות לסעיפים 4.1 ו-10.1, ובין היתר לסעיף 7 (מימוש המוצר), 7.3.3, 8.2.1, 8.4 ו-8.5. ניהול הסיכונים נטמע בתהליכי המימוש של מערכת האיכות.

  • תקן ⁦IEC 60601-1⁩, סעיף 4.2. התקן לציוד חשמלי רפואי (⁦ME Equipment⁩) דורש תהליך ניהול סיכונים לפי 14971, אך מוציא ממנו שני חלקים: התכנון והביצוע של ניטור ייצור ופוסט-ייצור (סעיפים 4.1, ⁦4.4 g⁩ ו-10 ב-14971), והסקירה התקופתית של התאמת התהליך (סעיף 4.2). התקן 60601-1 עצמו מציין שהתהליך הנדרש בו אינו מקיף כמו 14971. מכשיר שעומד ב-60601-1 עדיין צריך להשלים את שני החלקים החסרים במערכת האיכות כדי לעמוד ב-14971. בנוסף, "תנאי תקלה" ב-14971 כולל את תנאי התקלה הבודדת (⁦Single Fault Condition⁩) שמוגדרים ב-60601-1.

  • תקני ⁦IEC 62366-1⁩ ו-⁦IEC 60601-1-6⁩. תהליך הנדסת השימושיות (⁦Usability Engineering Process⁩) הוא חלק מניהול הסיכונים. התקן 62366-1 בסעיף 4.1.2 חוזר על סדר העדיפויות של 14971 בבחירת אמצעי בקרה: תכן בטוח מהותית, אמצעי הגנה, ורק אחר כך מידע לבטיחות. כשמידע לבטיחות משמש כאמצעי בקרה, בסעיף 4.1.3 נדרש לבדוק שהוא ניתן לתפיסה, מובן, ותומך בשימוש נכון. בסעיף 5.3 נדרש לזהות סכנות ומצבים מסוכנים הקשורים בשימוש, ובסעיף 5.9 נדרשת הערכה מסכמת (⁦Summative Evaluation⁩) כחלק מניהול הסיכונים. נקודה שתקבל מאמר שלם: שימוש חריג (⁦Abnormal Use⁩) מחוץ לתהליך השימושיות, ולכן הסיכונים שלו נבדקים בניהול הסיכונים עצמו. התקן 60601-1-6 מפנה ל-62366-1 וגם הוא מוציא את ניטור הפוסט-ייצור של השימושיות.

  • תקן ⁦IEC 62304⁩. תקן מחזור החיים של תוכנה. סעיף 4.2 דורש תהליך לפי 14971. סעיף 4.3 מסווג את מערכת התוכנה לפי החומרה המרבית האפשרית, לכיתות ⁦A⁩, ⁦B⁩ ו-⁦C⁩, ומניח שהסתברות כשל התוכנה היא 100 אחוז כשהסכנה יכולה להיגרם מכשל כזה. סעיף 7 מוסיף דרישות ספציפיות: זיהוי רכיבי תוכנה שתורמים למצבים מסוכנים, אמצעי בקרה ואימותם. תהליך ניהול הסיכונים של התוכנה משובץ בתהליך של המכשיר כולו.

  • תקן ⁦ISO 10993-1⁩. הערכה ביולוגית כחלק מתהליך ניהול סיכונים. לפי נספח ⁦E⁩ ב-⁦TR⁩, הערכה ביולוגית מתנהלת כמו כל סיכון אחר: ניתוח, הערכה, בקרה והערכת סיכון כוללת. ה-⁦TR⁩ מפנה לנוסח משנת 2018, ולכן לפני ציטוט מספרי סעיפים כדאי לוודא את המהדורה העדכנית של התקן.

  • מדריך ⁦ISO/TR 20416:2020⁩. מדריך לתהליך מעקב אחר מוצר בשוק (⁦Post-Market Surveillance⁩). הוא עקבי עם ⁦ISO 13485⁩ ו-14971, ותוצריו משמשים קלט לניהול הסיכונים, לתהליכי שינוי בתכן ולתהליכי שיפור.

  • מדריך ⁦ISO/TR 24971:2020⁩. המדריך שמלווה את התקן ושבו נספחי עזר: שאלות לזיהוי מאפייני בטיחות (נספח ⁦A⁩), טכניקות לניתוח סיכונים (נספח ⁦B⁩), הקשר בין המדיניות לקריטריונים (נספח ⁦C⁩), מידע לבטיחות וחשיפת סיכון שיורי (נספח ⁦D⁩), תקנים (נספח ⁦E⁩), אבטחת מידע (נספח ⁦F⁩), רכיבים ומכשירים שפותחו בלי להשתמש ב-14971 (נספח ⁦G⁩) ומכשירי ⁦IVD⁩ (נספח ⁦H⁩).

ניהול הסיכונים והדיווח לרשויות

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

מסמך ההנחיות ⁦MDCG 2023-3 Rev.2⁩ מגדיר שאירוע חמור (⁦Serious Incident⁩) מדווח מיד עם קביעת קשר סיבתי, ולא יאוחר מ-15 ימים.

מוות או הדרדרות חמורה בלתי צפויה במצב הבריאותי מדווחים תוך 10 ימים לכל היותר, ואיום חמור על בריאות הציבור תוך יומיים.

הימים הם Calendar days, והיום הראשון הוא היום שאחרי מועד המודעות (Awareness date) של היצרן.

ההבחנה בין הדרדרות צפויה לבלתי צפויה (⁦Q12⁩ במסמך) נשענת על קובץ הסיכונים.

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

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

עוד שני דברים ממסמך ⁦MDCG 2023-3⁩ יחזרו בסדרה.

  • שגיאת שימוש (⁦Use Error⁩) שנגרמת מהמאפיינים הארגונומיים של המכשיר היא אירוע (⁦Incident⁩) לפי המסמך, ואם מתקיימים בה הקריטריונים של אירוע חמור, היא מדווחת. שגיאות שימוש אחרות מטופלות במערכת האיכות.

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

לגבי ההרמוניזציה האירופית: הגרסה ⁦EN ISO 14971:2019+A11:2021⁩ מוסיפה נספחים ⁦ZA⁩ ו-⁦ZB⁩ שממפים בין סעיפי התקן לדרישות הבטיחות והביצועים הכלליות (⁦General Safety and Performance Requirements⁩, ⁦GSPR⁩) ב-⁦MDR⁩ וב-⁦IVDR⁩. פירוט ההבדלים בין נוסח התקן לדרישות ה-⁦MDR⁩, כמו ניסוח הדרישה להפחית סיכון "עד כמה שאפשר" (⁦As Far As Possible⁩), יובא במאמרים על בקרת סיכונים ועל ניתוח תועלת-סיכון.

מה כדאי לבדוק אצלכם

הרשימה הזו מתאימה לחברות בשלבים שונים, ולכן היא מפרידה לפי המצב:

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

  • חברה עם מוצר בשוק. האם סעיף 10 מחובר בפועל לתלונות, לדיווח על אירועים, למעקב אחר המוצר בשוק ולספרות? ל-14971 סעיף 10.2 יש רשימה של מקורות מידע, והיא כוללת מידע משרשרת האספקה וגם מידע על רמת הידע המקובלת.

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

  • מכשיר חשמלי או מכשיר עם תוכנה. האם השלמתם את מה ש-60601-1 משאיר בחוץ? האם סיווג התוכנה לפי 62304 תואם את החומרה שבניתוח הסיכונים?

  • קובץ הסיכונים. האם קיימת עקיבות מכל סכנה לניתוח, להערכה, ליישום ולאימות של אמצעי הבקרה ולהערכת הסיכון השיורי (סעיף 4.5)? והאם הנזקים החמורים שעלולים להתרחש מופיעים בו, כך שאפשר לתעד אותם כצפויים אם יתרחשו?

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