ISO 14971: מדריך מעשי לניהול סיכונים במכשור רפואי

למה רוב קבצי ניהול הסיכונים נכשלים בביקורת NB

בעשרים וחמש שנה שעבדתי כ-Lead Auditor וכ-Regulatory Affairs Director, ראיתי מאות Risk Management Files. אחוז הדחיות בביקורות NB שנוגעות ל-Risk Management גבוה בצורה עקבית — ולא בגלל סיבות טכניות מורכבות. הסיבה הנפוצה ביותר: הצוות לא מבחין נכון בין שלושה מושגים שה-ISO 14971 מגדיר בדיוק, ואת ה-NB Deficiency Letter שמגיע אחרי זה אף אחד לא אוהב לראות.

המושגים האלו הם: Hazard, Hazardous Situation, ו-Harm. נתחיל משם.

הבחנה יסודית: Hazard, Hazardous Situation, Harm

ISO 14971:2019 מגדיר אותם בסעיף 3 (Terms and Definitions):

• Hazard (§3.45): מקור פוטנציאלי לנזק — potential source of harm. לדוגמה: מתח חשמלי גבוה, חומר ביולוגי פעיל, אנרגיה לייזר.
• Hazardous Situation (§3.46): נסיבות שבהן אנשים, ציוד, או סביבה נחשפים ל-Hazard. לדוגמה: "מטופל הנוגע בחלק מוליך של המכשיר בזמן תקלת בידוד."
• Harm (§3.49): פגיעה פיזית או נזק לבריאות, לרכוש, או לסביבה. לדוגמה: "שוק חשמלי הגורם לפרפור חדרי."

הטעות הנפוצה: צוותים כותבים "Hazard: electric shock" — וזה לא Hazard, זה Harm. או "Hazard: software failure" — זה גם לא Hazard, זה Hazardous Situation. ה-NB מחפש שרשרת מלאה וקוהרנטית: Hazard → Hazardous Situation → Sequence of Events → Harm. כשהשרשרת לא מלאה, ה-Deficiency Letter מגיע.

ISO 14971:2019 + Amendment 1 (2024): מה השתנה

ISO 14971 עבר revision ב-2019, וב-2024 פורסם Amendment 1 (ISO 14971:2019/Amd 1:2024). השינויים לא שוליים:

• Benefit-Risk Analysis: ה-Amendment מחזק את הדרישה לניתוח benefit-risk מפורש — לא רק כ-checkbox בסוף ה-Risk Management File, אלא כתהליך מתועד שמקושר ישירות לסעיפי GSPR של ה-MDR (Annex I). ה-NB יבדוק שהניתוח מבוסס על clinical data ממשי, לא על הערכה כללית.
• Post-Production Information: §10 ב-ISO 14971:2019 דרש מידע פוסט-שיווקי. ה-Amendment מחדד שה-Risk Management Process חייב לכלול feedback loop פורמלי מ-PMCF (Post-Market Clinical Follow-Up) ומ-PMS (Post-Market Surveillance) — ולא רק לאסוף מידע אלא לקשר אותו לסיכונים ספציפיים בטבלה.
• Software as a Medical Device (SaMD): ה-Amendment מבהיר שסיכוני תוכנה — כולל סיכוני cybersecurity — חייבים להיות משולבים ב-Risk Management File הראשי, לא בדוקומנט נפרד שמוסב עליו רק כ-reference. ה-NB ירצה לראות integration ממשי.
• Reasonably Foreseeable Misuse: הרחבה של ההגדרה לכלול שימוש לרעה שנובע מממשק משתמש לא אינטואיטיבי — relying on IEC 62366-1 integration.

מבנה ה-Risk Management File — כפי שה-NB מצפה לראות

ISO 14971:2019 §4 מגדיר את ה-Risk Management Process, אבל לא מגדיר את מבנה ה-File. הנה המבנה שעבד בביקורות שליוויתי:

1. Risk Management Plan (§4.4): מסמך שמגדיר scope, risk acceptability criteria, תדירות reviews, ואחריות. זה לא מסמך חד-פעמי — הוא חי לאורך מחזור החיים. ה-NB יבדוק שה-Plan מוצלב עם ה-QMS SOP שלך.
2. Intended Use + Intended Users + Use Environment: לא פסקה כללית — תיאור ספציפי של הפציינט, המשתמש (רופא? טכנאי? מטופל ביתי?), והסביבה (ICU? בית? מרפאה?). ה-NB ישתמש בזה כדי לבדוק שכל ה-Hazardous Situations שזיהית אכן רלוונטיות לנסיבות הספציפיות.
3. Hazard Identification (§5.4): טבלת סיכונים מלאה. כל Hazard → Hazardous Situation → Sequence of Events → Harm. לא "חשמל — סכנה." כל שרשרת מלאה, מתועדת ומנומקת.
4. Risk Estimation (§5.5): הערכת Probability וSeverity לכל Harm. הקריטריון לקביעת ה-Probability חייב להיות מוגדר ב-Plan — לא שרירותי לכל Harm.
5. Risk Evaluation (§6): האם הסיכון מקובל? לפי Risk Acceptability Matrix שנקבעה ב-Plan. כאן רוב הצוותים טועים: הם משתמשים ב-FMEA כ-Risk Management — אבל FMEA הוא כלי לזיהוי failure modes, לא ל-risk acceptability decision. ה-NB יבדוק שה-Decision מבוסס על קריטריון מוגדר מראש, לא על שיקול דעת ad hoc.
6. Risk Control (§7): לפי סדר עדיפויות: inherently safe design → protective measures → information for safety (הוראות שימוש). כל risk control measure חייב להיות מאומת שהוא אפקטיבי (§7.6) ושהוא לא יצר סיכון חדש (§7.7).
7. Residual Risk Evaluation (§8): הערכת הסיכון השיורי לאחר הבקרות. אם הסיכון השיורי עדיין מעל סף הקבילה — חייב benefit-risk analysis מפורש.
8. Overall Residual Risk + Benefit-Risk Analysis (§9): ניתוח כולל. כאן ה-Link ל-Clinical Evaluation Report (CER) הוא קריטי — ה-CER מספק את ה-clinical benefit data שמאפשר לך לומר שהסיכון הכולל מקובל לאור היתרון הקליני.
9. Risk Management Review (§4.5): תיעוד של review לפני שחרור המוצר + תיעוד של ongoing reviews.
10. Production and Post-Production Information (§10): פרוצדורה לאיסוף מידע פוסט-שיווקי, ניתוחו, והחזרתו למעגל ה-Risk Management. זה ה-feedback loop שה-Amendment מחזק.

הקשר ל-MDR Annex I — GSPR 1 עד 9

MDR 2017/745, Annex I מגדיר את ה-General Safety and Performance Requirements (GSPR). הסעיפים 1–9 עוסקים ספציפית בניהול סיכונים, וה-NB יבדוק cross-reference ישיר בין ה-Risk Management File לכל אחד מהם:

• GSPR 1: מכשיר חייב להיות בטוח ולהשיג את הביצועים המיועדים. ה-Risk Management File צריך להוכיח זאת.
• GSPR 2: פתרונות ידועים לצמצום סיכונים חייבים להיות מיושמים (state of the art). אם קיים תקן הרמוני (כמו IEC 60601-1) — יישומו צריך להיות מתועד ב-Risk Control section.
• GSPR 3: יצרן חייב לקבוע risk acceptability criteria ולדבוק בהם. זה חייב להיות ב-Risk Management Plan, עם נימוק מדוע הקריטריון נבחר.
• GSPR 4: Known and foreseeable risks — כולל Reasonably Foreseeable Misuse — חייבים להיות מזוהים.
• GSPR 6: אם הסיכון השיורי הכולל מקובל — זה חייב להיות מוצדק ב-Overall Benefit-Risk Analysis המוצלב עם ה-CER.

הנקודה הפרקטית: ה-NB לא מסתכל על ה-Risk Management File ועל ה-GSPR Checklist כמסמכים נפרדים. הוא מצפה לראות שה-Technical Documentation שלך מקשר ביניהם. אם ה-GSPR Checklist שלך כולל רק "Yes/No" ללא pointer ל-Risk Management File, תקבל Deficiency.

הפערים הנפוצים ביותר שמוצאים NBs

מניסיוני כ-Lead Auditor ב-BSI Group ובחברות שאני מלווה כיום, אלו הפערים שחוזרים שוב ושוב:

1. Post-Production Information Loop לא מחובר: החברה מנהלת PMS ו-PMCF תקינים, אבל אין פרוצדורה כתובה שמגדירה מה קורה כשנמצא Signal חדש — כיצד הוא מוחזר ל-Risk Management File ומה טריגרים Risk Management Review.
2. Benefit-Risk Analysis ריקה מתוכן: "The benefits of the device outweigh its risks" — זה לא benefit-risk analysis. ה-NB מצפה לניתוח כמותי (או לפחות חצי-כמותי) שמציין את ה-clinical benefit הספציפי (הפחתת תמותה ב-X%, שיפור QoL) מול הסיכון השיורי המוגדר.
3. תוכנה מטופלת כ-reference בלבד: "Software risks — see Software Risk Management File." זה לא מספיק. ה-NB ירצה לראות שסיכוני התוכנה הספציפיים (כולל cybersecurity threats לפי IEC 81001-5-1) משולבים בטבלת ה-Hazards הראשית.
4. Risk Control Effectiveness Verification חסרה: הוספת Warning להוראות השימוש היא Risk Control לפי §7. אבל §7.6 דורש שתוכיח שהיא אפקטיבית — בדרך כלל דרך usability testing לפי IEC 62366-1. בלי זה — ה-Risk Control לא מושלם.
5. Risk Acceptability Matrix לא מוגדרת מראש: חברות שמגדירות את ה-Matrix אחרי שכבר ידועים הסיכונים — זה conflict of interest ברור. ה-NB יבדוק שה-Plan (שנכתב בתחילת הפרויקט) הגדיר את ה-Matrix לפני הזיהוי.

FMEA: כלי שימושי — אבל לא ה-Risk Management שלך

FMEA (Failure Mode and Effects Analysis) הוא כלי מצוין לזיהוי failure modes ולניתוח השפעתם. אבל ראיתי פעמים רבות מדי חברות שמגישות FMEA תחת הכותרת "Risk Management File" — וזו טעות שה-NB יתפוס מיד.

ה-FMEA לא מגדיר Hazards בשרשרת הנדרשת על ידי ISO 14971. הוא לא כולל Intended Use analysis, לא מגדיר risk acceptability criteria, ולא מתחבר ל-GSPR. הוא יכול להיות חלק מה-Risk Management File — כמקור מידע לזיהוי Hazardous Situations — אבל לא תחליף לו.

הקשר ל-Clinical Evaluation Report

ה-CER וה-Risk Management File הם שני מסמכים שצריכים להיכתב בדיאלוג. ה-CER — שנדרש לפי MDR Annex XIV — צריך לספק שני דברים לתהליך ה-Risk Management:

• Clinical benefit data שמאפשר את ה-Overall Benefit-Risk Analysis (§9 ב-ISO 14971)
• Post-market clinical evidence שמזין את ה-Post-Production Information feedback loop (§10)

כשה-CER כתוב בלי קשר ל-Risk Management File — ה-NB יראה זאת. שני המסמכים צריכים לצטט זה את זה ברמת ה-specific risk, לא רק ברמה הכללית.

צ'קליסט מהיר לפני הגשה ל-NB

• כל Hazard מוגדר כ-source of harm — לא כ-harm עצמו ולא כ-failure mode
• כל שרשרת Hazard → Hazardous Situation → Sequence → Harm מלאה ומתועדת
• Risk Acceptability Matrix הוגדרה ב-Risk Management Plan לפני תחילת ה-Hazard Identification
• כל Risk Control Measure כולל תיעוד Effectiveness Verification
• סיכוני תוכנה ו-cybersecurity משולבים בטבלה הראשית, לא כ-reference בלבד
• Overall Benefit-Risk Analysis מפנה ל-clinical data ספציפי מה-CER
• קיים feedback loop מתועד מ-PMS/PMCF לחזרה ל-Risk Management File
• Cross-reference מלא בין ה-Risk Management File ל-GSPR 1–9

ISO 14971 הוא לא מסמך שממלאים בסוף הפרויקט — הוא תהליך שמתחיל ביום הראשון של הפיתוח. NB שמוצא Risk Management File שנכתב "בדיעבד" יבקש rewrite מלא. ראיתי את זה קורה — וזה עיכוב של 6–12 חודשים שאפשר למנוע לחלוטין.