איך הופכים פעולה מתקנת ממילוי טופס למעורבות אמיתית

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

איפה זה מתחיל

בכל חברה שעברתי בה יש נוהל פעולה מתקנת וטופס מסודר.

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

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

הסיבה כמעט תמיד זהה.

הטופס תפס את מקום התהליך.

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

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

ההדרכה הזו עוסקת במה שקורה בין הפתיחה לסגירה.

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

מה הרגולציה דורשת — כל מסגרת בנפרד

המסגרות דומות במבנה ושונות בהיקף ובנקודות ההשקה. חברה יכולה להיות כפופה לאחת מהן, לכמה מהן, או רק ל-ISO 13485, ולכן כדאי לקרוא כל אחת בנפרד.

ISO 13485:2016

סעיף 8.5.2 מגדיר את השלד:

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

שלושה סעיפים נוספים מזינים את התהליך ומכתיבים את איכותו:

• 8.2.1 (משוב, כולל מידע מייצור ומפעילות שלאחר השיווק)

• 8.2.2 (טיפול בתלונות)

• ו-8.4 (ניתוח נתונים, המקום שבו מגמה מזוהה)

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

הבחנה שכדאי שתופיע במפורש בנוהל

תיקון (correction) מטפל באי-ההתאמה עצמה, פעולה מתקנת מטפלת בסיבה, ופעולה מונעת (8.5.3) מטפלת בסיבה של אי-התאמה שטרם התרחשה.

שלושתן נדרשות, והן אינן מחליפות זו את זו.

EU MDR 2017/745

הדרישה למערכת פעולה מתקנת ולאימות אפקטיביות מופיעה ב-Article 10(9), כחלק ממערכת ניהול האיכות.

הייחוד של MDR הוא במיקום של הפעולה המתקנת בתוך מעגל רחב יותר:

חיבור למערכת PMS (Articles 83-86, Annex III) -

הנתונים שמזינים את ההחלטה מגיעים מתוכנית ה-PMS, והתוצאות חוזרות לדוח ה-PMS או ל-PSUR.

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

דיווח מגמות (Article 88) -

עלייה משמעותית בתדירות או בחומרה של אירועים שאינם בני-דיווח עצמאי מחייבת דיווח.

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

FSCA

כשהפעולה כוללת פעולה בשטח (הודעת בטיחות, עדכון, החזרה מהשוק), חלות חובות דיווח נפרדות לרשות המוסמכת.

ההחלטה אם מדובר ב-FSCA מתקבלת בתוך הפעולה המתקנת ומתועדת בה.

חזרה להערכה הקלינית ולקובץ הסיכונים -

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

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

MDSAP

מודל המבדק של MDSAP בנוי סביב שבעה תהליכים, ופעולה מתקנת יושבת בתוך תהליך מספר 3, Measurement, Analysis and Improvement, יחד עם טיפול בתלונות, מוצר לא מתאים, ניתוח נתונים ומבדקים פנימיים.

מי שמתכונן ל-MDSAP ומחפש פרק CAPA נפרד במודל לא ימצא אותו.

זה משנה את אופן הבדיקה.

המודל מגדיר קישורים (linkages) שיוצאים מתהליך 3 אל שאר התהליכים, והמבקר עובר דרכם: מהתלונה אל ההחלטה על דיווחיות (תהליך 4, Medical Device Adverse Events and Advisory Notices Reporting), אל שינוי בתכן (תהליך 5) או בייצור ובשירות (תהליך 6), אל הספק כשמקור הבעיה שם (תהליך 7), ובחזרה אל סקר ההנהלה (תהליך 1).

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

בנוסף, נוהל הדיווח (תהליך 4) צריך להתייחס במפורש ללוחות הזמנים של כל מדינה aמשתתפת בסקופ ההסמכה בנפרד, ולא רק לאלה של ה-FDA.

FDA

מאז כניסת ה-QMSR לתוקף (2 בפברואר 2026), ה-FDA מאמץ את ISO 13485:2016 בהפניה, וסעיף 820.100 שהיה מוכר כ-CAPA אינו קיים עוד כדרישה נפרדת.

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

מה שנשאר ייחודי לארה"ב וממשיך להשפיע ישירות על ניהול פעולות מתקנות:

דרישות רשומות לפי 820.35, כולל דרישות ספציפיות לרשומות תלונות ולרשומות שירות, ולזיהוי מי ביצע ומתי.

תקנה 21CFR Part 803. דיווח אירועים ל-FDA. ההחלטה אם אירוע הוא בר-דיווח מתקבלת במקביל לחקירה, וההחלטה שלא לדווח חייבת להיות מתועדת ומנומקת. זו נקודה שנבדקת כמעט תמיד.

תקנה 21CFR Part 806. דיווח על תיקונים והסרות מהשוק, נוהל נפרד מ-Part 803, עם לוח זמנים משלו. גם כאן, החלטה שאין חובת דיווח דורשת תיעוד ושמירה.

תקנה 21CFR Part 11. אם הפעולות מנוהלות במערכת ממוחשבת: audit trail, בקרת גישה, חתימות אלקטרוניות.

מה שמשותף לכל ארבע המסגרות: אף אחת מהן לא דורשת טופס.

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

הטופס הוא רק המקום שבו זה נרשם.

הפער בין הדרישה למה שקורה

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

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

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

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

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

ארבע הנקודות שקובעות אם תהיה מעורבות

ההחלטה לפתוח פעולה מתקנת

זו הנקודה הראשונה, והיא נקבעת לרוב לפי תחושה.

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

חברה שלא פותחת עד שמישהו מתעקש מפספסת מגמות.

הקריטריון צריך להיות כתוב בנוהל ומופעל על נתונים:

• חומרה (פוטנציאל לפגיעה, אירוע בר-דיווח, השפעה על בטיחות או על ביצועים), או

• מגמה (חזרתיות מעל סף מוגדר, על פני חלון זמן מוגדר, ביחס להיקף השימוש בפועל).

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

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

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

בדיקה שכדאי לעשות בחברה שלך

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

אם התשובה בכל החמש היא "הבנו שיש בעיה", הקריטריון קיים בנוהל ולא בתהליך.

מי יושב בחדר

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

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

מי שדיבר עם המשתמש ויודע מה הוא באמת תיאר.

מי שמכיר את התכן ויודע באילו תנאים התופעה מתרחשת.

מי שמחזיק את קובץ ניהול הסיכונים ויכול לומר אם התרחיש הזה נצפה מראש.

מייל שמבקש הערות משלושתם אוסף מידע.

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

זה קורה בשיחה של ארבעים דקות, לא בשרשור תגובות.

לכן כדאי שהנוהל יגדיר

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

הטופס מתמלא אחרי הישיבה.

ניסוח סיבת השורש

"טעות משתמש" ו"טעות אנוש" הם הניסוחים שעוצרים את החקירה במקום להתחיל אותה.

במכשיר רפואי, ובמיוחד במכשיר המיועד לשימוש על ידי הדיוט (Lay user), האופן שבו משתמש טועה הוא נתון של תכן והנדסת שימושיות, וההתייחסות אליו שייכת ל-IEC 62366-1 ולקובץ ניהול הסיכונים לפי ISO 14971. כשסיבת השורש היא המשתמש, הפעולה תהיה תמיד עדכון הוראות שימוש או הדרכה, כי שום דבר אחר לא נגזר מהניסוח הזה.

אותו כלל חל על "כשל חד-פעמי" ועל "אירוע נדיר".

שניהם מתארים תדירות, לא סיבה.

הבדיקה הפשוטה:

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

אם לא, זה עדיין תיאור של התופעה.

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

האם התרחיש קיים בקובץ ניהול הסיכונים?

ואם כן, האם אמצעי הבקרה שנרשם לו מטפל בו?

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

אימות האפקטיביות

הכשל הנפוץ ביותר: סגירה ברגע שהפעולה בוצעה, אושרה ותועדה.

ביצוע הוא תנאי לאפקטיביות ולא ראייה לכך.

אימות אפקטיביות דורש שלושה דברים שנקבעים בפתיחה:

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

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

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

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

ותוצאה שלילית באימות היא לא כישלון של המערכת.

ומה עושים כשהמדד לא משתפר?

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

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

פתיחה מחדש, מנומקת ומתועדת, מראה שהבדיקה היתה אמיתית.

מבקר שרואה אותה מקבל ראיה שהמנגנון עובד.

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

מה משנים בנוהל כדי שזה יקרה מעצמו

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

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

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

• מדד אפקטיביות כשדה חובה בפתיחה ולא בסגירה, כולל בסיס ההשוואה וחלון הזמן.

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

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

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

שתיהן יחד הן הסימן שהמערכת התחילה לעבוד.

תרגול

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

יש לך 5 צמתי החלטה, ובכל צומת שלוש אפשרויות שכולן סבירות.

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

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