ISO 13485 מעבר ל-Audit: לבנות QMS שמאיץ שחרורים

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

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

למה רוב יישומי ISO 13485 מאטים חברות

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

שלושה דפוסים מייצרים את ההאטה:

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

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

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

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

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

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

1. קפדנות תהליך מדורגת לפי סיכון, מקודדת

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

לבקרת שינויים, זה מתבטא כמשהו כמו:

• שכבה 1 (שינויים בסיכון נמוך): עדכוני תיעוד שלא משנים את השימוש המתוכנן של המכשיר, ביצועים, או טענות בטיחות. שינויים קוסמטיים ב-UI. הבהרות שלא מציגות התנהגות חדשה. אישור סוקר יחיד, SLA של 24 שעות, סקירת audit trail פוסט-הוק חודשית.
• שכבה 2 (שינויים בסיכון בינוני): הוספות פיצ'ר לפונקציונליות קיימת, אופטימיזציות ביצועים, refactor ארכיטקטורה קל. אישור שני סוקרים (מהנדס + איכות), עדכוני קובץ סיכון אם רלוונטי, SLA של 5 ימים.
• שכבה 3 (שינויים בסיכון גבוה): טענות קליניות חדשות, שינויים בקלטי קובץ סיכון, שינויי סיווג בטיחות תוכנה, שינויים לבקרות בטיחות מאומתות. חבילת design control מלאה, סקירה רב-תחומית, התייעצות עם צוות רגולציה, מחזור מינימלי של 15 ימים.

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

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

2. תהליכים שאפשר להריץ במקביל

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

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

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

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

3. ה-QMS כ-artefact מבוקר-אבל-משתנה

המשמעת הכי לא-אינטואיטיבית: התייחסו ל-QMS עצמו כמשהו שמשתפר ברציפות, עם תהליך מוגדר לשנות אותו. ISO 13485 §4 דורש מדריך איכות ונהלים מתועדים. הוא לא דורש שהם יהיו סטטיים.

חברות שזזות מהר יש להן תהליך שינוי QMS מפורש: backlog של שיפורי QMS, מערכת שכבות לשינויי QMS (במקביל לשכבות שינוי מוצר), שיקול בסקירת הנהלה אילו שיפורים לתעדף, ומדדים על ה-QMS עצמו (זמן מחזור, שיעור עבודה מחדש, שיעור ממצאי audit לפי תהליך).

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

מה בודקים באמת מחפשים

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

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

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

איפה אנחנו נכנסים

תחום ה-QMS של פליקן-טק בונה יישומי ISO 13485 עם שלושת העקרונות התפעוליים למעלה כחלק מהתכנון, עובד עם צוותי ההנדסה והמוצר במקום מעליהם. אנחנו עובדים יחד עם פרקטיקת רגולציית ה-MedTech שלנו כש-QMS תומך בתאימות MDR או IVDR, ועם צוות הרגולציה ואישורים שלנו כשמוכנות בדיקה של FDA היא ההנעה הקובעת.

אם יישום 13485 הקיים שלכם מפיק artefacts שעוברים audit אבל מאט את קצב השחרור שלכם, זה ה-engagement שצריך להתחיל איתו לפני מחזור ה-audit ההשגחה הבא.