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

IMDRF פרסם לאחרונה את המסמך הסופי בנושא PCCP, תוכניות בקרת שינויים מתוכננות מראש (Predetermined Change Control Plans). N90:2026 הוא המסמך שאמור לתת לתחום הזה שפה משותפת בין תחומי השיפוט השונים, אחרי כמה שנים שבהן כל רשות התייחסה לנושא קצת אחרת. אם יש לכם תוכנה רפואית שמתעדכנת, ובטח אם מדובר במוצר מבוסס AI או למידת מכונה, הגיע הזמן להכיר את הכלי הזה לעומק, לא רק ברמת הכותרת.

מה זו בעצם PCCP, ומה הבעיה שהיא פותרת

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

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

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

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

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

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

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

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

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

5. פרספקטיבת TPLC (Total Product Lifecycle). ה-PCCP היא ,תכנית חיה לאורך כל חיי המוצר, עם משוב מתמשך ממשתמשים ושילוב נתונים חדשים ככל שהם מצטברים.

שלושת המרכיבים שכל PCCP חייבת לכלול

תיאור השינויים (Description of Changes)

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

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

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

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

תוכנית השינוי (Change Plan)

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

• שיטות הערכת ביצועים. כאן נדרש פירוט אמיתי ולא הצהרות כלליות: סיכום ביצועי התוכנה בעת ההגשה מול הביצועים הצפויים לאחר השינוי, תיאור הנתונים ושיטות ניהול הנתונים, קלטים ופלטים רלוונטיים, מדדי ביצועים, קריטריוני קבלה כמותיים ובעלי משמעות קלינית, ובדיקות סטטיסטיות ספציפיות לכל שינוי מתוכנן. "המודל ישתפר" - זו לא רמת פירוט מספקת. "הרגישות לא תרד מתחת ל-92% על סט אימות עצמאי בן 500 מקרים, נבדק במבחן t חד-צדדי ברמת מובהקות של 0.05" - כן.

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

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

הערכת השפעה (Impact Assessment)

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

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

• דיון בתועלות ובסיכונים של כל שינוי בודד, כולל סיכונים שנוצרים מעצם תהליך השינוי בשלב שלאחר השיווק (לא רק מהשינוי עצמו)

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

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

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

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

היתרונות, לפי מי שנהנה מהם

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

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

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

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

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

האתגרים, כולל אלה שנופלים על הרגולטור

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

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

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

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

מעבר לגבולות, לא כל תחום שיפוט זהה

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

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

• תחומי שיפוט שמשתמשים במסלולי הצהרה עצמית (self-certification) לעמידה ברגולציה, שם באחריותכם לוודא שה-PCCP תואמת למסלול הזה.

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

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

מה זה אומר ברמת מערכת האיכות שלכם

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

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

• האם יש לכם מנגנון מעקב (traceability) שמקשר כל שינוי בתיאור השינויים לתוכנית האימות הספציפית שלו בתוכנית השינוי?

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

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

• איך אתם מתעדים ומנהלים גרסאות של ה-PCCP עצמה, כך שברור בדיוק מה אושר ומתי?

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

מתי PCCP באמת שווה את המאמץ

מי שבאמת ירוויח מ-PCCP:

• מוצרי SaMD מבוססי AI/ML שמתעדכנים באופן שוטף עם נתונים חדשים

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

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

מי שכנראה לא צריך להתאמץ בשביל זה:

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

• שינויים שחורגים מהייעוד המקורי וידרשו הגשה חדשה בכל מקרה, ללא קשר ל-PCCP

נקודת המוצא הפרקטית

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

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