MDSAP רוויזיה 11 יצאה לדרך. מה עושים עכשיו?

ב-3 באוגוסט 2026 פורסם MDSAP AU P0002.011, המסמך שמגדיר איך מתבצע מבדק MDSAP.

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

MDSAP AU P0002 הוא לא תקן והוא לא רגולציה.

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

כשהוא מתעדכן, המבדק מתעדכן איתו.

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

בימים האחרונים ליוויתי לקוח דרך המעבר הזה.

אני רוצה לתאר את הדרך שעבדנו בה, כי היא מתאימה לכל חברה שנמצאת בתוכנית MDSAP.

למה לא מספיק לקרוא את רשימת השינויים

בסוף המסמך, בעמוד 163, יש פרק שנקרא Summary of Changes from Prior Revisions.

הוא מפרט את השינויים מ-010 ל-011 ב-17 שורות.

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

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

שתי דוגמאות מהעבודה אצל הלקוח:

רשימת השינויים אומרת שדרישות סייבר של ה-FDA נוספו ל-Design and Development Task 7.

בגוף המסמך, ב-Task 7, אין דרישת סייבר.

הטקסט נמצא ב-Task 5.

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

מי שעובד רק מול הרשימה יחפש דרישת סייבר ב-Task 7 ולא ימצא אותה, ולא יגיע לדרישה שכן קיימת ב-Task 5.

הערכת הפערים צריכה להיעשות מול הטקסט של שתי הרוויזיות.

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

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

כדאי לחזור למקור.

דוגמה מהרוויזיה הזאת היא ה-Predetermined Change Control Plan: ברוויזיה 010 הפסקה התייחסה למכשירים מבוססי AI, וברוויזיה 011 ההתייחסות הזאת הוסרה והפסקה חלה על כל מכשיר שמכוסה בתוכנית שינויים מוגדרת מראש.

שלב ראשון: הערכת פערים

הערכת הפערים היא השוואה בין 010 ל-011, שינוי אחר שינוי. לכל שינוי שלוש שאלות:

1. מה השתנה בפועל בטקסט? לא מה כתוב ברשימת השינויים, אלא מה כתוב ב-Task עצמו בשתי הרוויזיות.

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

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

הכלי לתיעוד ההערכה הוא טבלה עם שלוש עמודות: השינוי ברוויזיה 011, מה זה אומר עבורנו, ואיפה זה מטופל.

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

שלב שני: תוכנית המעבר

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

מה שהיה בתוכנית שכתבנו:

1. מטרה וסקופ. מה נבחן, מול מה, ומה מחוץ לסקופ.

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

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

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

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

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

שלב שלישי: ביצוע

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

עדכון המסמכים לפי הנספח.

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

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

מה שהוחלט שלא לשנות

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

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

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

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

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

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

איפה נמצאת רוב העבודה

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

• סייבר. הרוויזיה הכניסה דרישות אבטחה לכמה מקומות במקביל: לקלטי התכן, לתכן התוכנה, ולמידע לאחר השיווק (Post-market). חלק מהדרישות תלויות בתאריך אישור המכשיר וחלק חלות ללא תלות בתאריך. ההבחנה הזאת חשובה, כי היא קובעת מה חל עליכם עכשיו.

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

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

מה לעשות השבוע

הורידו את רוויזיה 011 — היא זמינה בעמוד MDSAP Audit Procedures and Forms באתר mdsap.global.

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

אחרי זה יהיה לכם מושג כמה עבודה יש.