510(k) של FDA ל-SaMD: תיעוד סייבר שלא יוחזר

הדרכת הסייבר של ה-FDA למכשירים רפואיים לפני שיווק, שהסתיימה בספטמבר 2023 ובאה לידי ביטוי במכתבי Refuse to Accept של 2024–2025, הרימה את הרף למה שהגשת 510(k) של Software as a Medical Device (SaMD) חייבת להכיל. שנתיים אחר כך, הדפוס בתוצאות ההגשה ברור. הגשות SaMD שמשלבות תיעוד סייבר כפרק מובנה מקבלות אישור במחזור הביקורת הראשון. הגשות שמתייחסות לסייבר כאל סעיף שמוסיפים בסוף התהליך מייצרות בקשות Additional Information שדוחות אישור ב-60 עד 180 ימים.

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

מה ההדרכה הסופית של 2023 באמת דורשת

הדרכת הסייבר לפני שיווק מציינת שישה תחומי תיעוד שחייבים להופיע בהגשת 510(k) ל-SaMD עם פיצ'רים רלוונטיים-לסייבר. רוב התחום קרא את כותרות הסעיפים. הרבה פחות הפנימו מה ה-FDA באמת מצפה בכל אחד.

1. דוח ניהול סיכון אבטחה. לא checklist. יישום מתועד של מתודולוגיית threat-model מובנית (ההדרכה נוקבת ב-STRIDE, attack trees, ובפריימוורק AAMI TIR57/SW96 כקבילים) לארכיטקטורה הספציפית של המכשיר. סוקרי ה-FDA מפורשים במכתבי משוב שהם מחפשים ראיה שה-threat model מיושם, לא רק מוצהר.

2. Threat model. artefact ספציפי: פירוק מערכת (זרימות נתונים, גבולות trust, נכסים), מניית איומים ממופה לארכיטקטורה, מיתיגציות ממופות לאיומים, ודיון ב-residual risk. הכישלון הנפוץ ביותר כאן הוא הצגת רשימת איומים גנרית שהודבקה מתבנית במקום אחת ספציפית לארכיטקטורה.

3. הערכת סיכון סייבר. ה-artefact המקשר בין סיכוני אבטחה לקובץ הסיכון הכולל של המכשיר לפי ISO 14971. עמדת ה-FDA המפורשת היא שסיכוני סייבר הם סיכוני מכשיר, וההערכה צריכה להיות ממופה לנזק למטופל, לא רק ל-compromise של נכס מידע.

4. SBOM (Software Bill of Materials). נדרש בהגשה. הפורמט חייב להיות machine-readable (SPDX או CycloneDX). הכיסוי חייב לכלול את כל רכיבי התוכנה של צד שלישי, כולל קוד פתוח. מעקב פגיעויות מול ה-SBOM משתמע. הגשות ללא תהליך מוצהר לניטור פגיעויות מתמשך מפעילות בקשות AI.

5. תוכנית ניהול פגיעויות ואירועים. השותף ה-post-market של ה-threat model. חייב לתאר coordinated vulnerability disclosure, קצב הערכת פגיעויות, פריסת patch, והודעת אירוע. חייב להיות תפעולי, לא שאיפתי.

6. תצוגות ארכיטקטורת אבטחה. דיאגרמות ותיאורים של ארכיטקטורת האבטחה של המכשיר: אימות, הרשאה, הצפנה (בתעבורה ובמנוחה), ניהול מפתחות, audit logging, מנגנון update מאובטח, secure boot אם רלוונטי. כל בקרה ממופה לאיומים מה-threat model שהיא מתמודדת איתם.

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

הדפוס שעושה את ההבדל

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

דוגמה קונקרטית: ה-threat model מזהה איום אימות. המיתיגציה מתוארת כ"המכשיר דורש אימות עם multi-factor לפעולות אדמיניסטרטיביות". סוקר ה-FDA מחפש: מסמך הדרישות שבו זה מוגדר, מסמך התכנון שבו המנגנון מתואר, פרוטוקול הבדיקה שבו זה נבדק, ודוח הבדיקה שמראה שזה עבר. אם איזשהו מאלה חסר או לא מתאים למה שה-threat model טען, ההגשה נכשלת. אם הם נמצאים וניתנים למעקב, ההגשה מתקדמת.

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

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

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

כיסוי SBOM שטחי. ספקים מספקים SBOM שמפרט את התלויות הישירות שלהם אבל לא כולל transitive dependencies, רכיבי OS, או ספריות runtime. הציפייה של ה-FDA רחבה יותר. הפיקו SBOM עם כלים נכונים (Syft, ORT, או שווה ערך) ואמתו את הכיסוי מול המכשיר הרץ, לא מול build manifest.

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

Threat model גנרי. threat model שנגזר מתבנית STRIDE מיושם על ארכיטיפ מכשיר גנרי קורא כ-boilerplate. המודל צריך להתעסק עם הארכיטקטורה של המכשיר הזה, זרימות הנתונים של המכשיר הזה, מנגנון ה-update הספציפי של המכשיר הזה. סוקרי ה-FDA יותר ויותר מפורשים בלהבדיל בין threat modelling מיושם לבין מילוי תבניות.

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

חיבור סייבר ל-ISO 14971

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

בפועל, זה אומר שה-residual risks של ה-threat model צריכים להופיע בקובץ הסיכון הכולל של המכשיר (ISO 14971) עם נזקים ממופים, חומרה, וסבירות. קובץ הסיכון צריך לשקף שיקולי סייבר, לא רק קליניים ומכניים. ספקים שמתחזקים שני רשומות נפרדות עושים את העבודה פעמיים ומפיקים artefacts לא עקביים. ספקים שמתחזקים רשומה משולבת אחת מפיקים ראיות מהר יותר.

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

תחום רגולציה ואישורים של פליקן-טק בונה הגשות 510(k) ל-SaMD עם תיעוד סייבר משולב מההתחלה, עובדים יחד עם צוות ההנדסה במקום כפונקציית תיעוד downstream. אנחנו עובדים עם צוות ה-MedTech שלנו כשההקשר הרחב של מערכת המכשיר (הערכה קלינית, design controls, מחזור חיים תוכנה לפי IEC 62304) חשוב להגשה, ועם צוות ה-QMS שלנו כשמערכת האיכות הבסיסית של ISO 13485 צריכה להיות מיושרת עם תהליכי הסייבר שההגשה מתעדת.

אם קיבלתם מכתב Additional Information על הגשת 510(k) וסעיפי הסייבר מסומנים, זה ה-engagement שצריך להתחיל איתו לפני מחזור התגובה הבא.