בדיקות וסיכונים בתוכנה רפואית | שי גינזבורג

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

הקדמה

לאחרונה, הוזמנתי להרצות בנושא בדיקות וסיכונים בתוכנה רפואית במסגרת המפגשים של קבוצת TESTIL. המפגשים התקיימו באמצעות זום, מול קהל מגוון, שהביע עניין רב בנושא, והשאלות שלא זכו למענה בגלל קוצר הזמן, קיבלו מענה אישי דרך המייל שלי [email protected]. כמו כן, סיכמתי בכתב את הנושאים אשר הוצגו במפגש, ואני שמח להגיש אותם כאן לקהל הקוראים של המגזין. אתם מוזמנים להמשיך להפנות אלי שאלות באמצעות הדוא"ל. תודתי נתונה לכל אלה אשר עמלו בהתנדבות מלאה על-מנת לקיים את המפגשים המוצלחים ברחבי הארץ וכמובן גם לכל אלה, שבזכותם יש לקהילת התוכנה מגזין נגיש ומעודכן בשפה העברית. יישר כוחכם.

רקע

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

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

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

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

הסיכונים בתוכנה רפואית

כל מי שלמד שיעור קצר מאוד בתכנות מחשבים יודע, שאמנם המוח האנושי יכול ללמוד לקודד פקודות מחשב בשפות תכנות רבות, אבל כל פסיק מיותר בקוד המתוכנת עלול לגרום לשגיאת תוכנה (BUG), ובלי בדיקות תוכנה, העולם שלנו בשנת 2021 לא יכול לתפקד אפילו שנייה אחת. כאשר חושבים על תקלות תוכנה במוצרים רפואיים, מקובל להיזכר באסון שקרה באמצע שנות השמונים: המכשיר Therac-25 היה מערכת מתקדמת לטיפול בחולי סרטן באמצעות קרינה. המכשיר החדש החליף את המכשיר הקודם Therac-20, שהיו בו פחות פונקציות, אך היה ידוע כמכשיר אמין ומתקדם מאוד. אף אחד לא העלה על דעתו, שמכשיר חדש ומתקדם יותר מאותו פס ייצור עלול להיות קטלני. המטפלים והמטופלים שמחו לשדרג את המכשיר וקיוו לרפא חולי סרטן רבים יותר. אלא שהתוכנה של המכשיר החדש החביאה בתוכה באג, שבודקי התוכנה לא ידעו לאתר בזמן הפיתוח של המוצר, כך שהמוצר עם הגרסה הסופית של התוכנה בתוכו, הכילו למעשה פצצה מתקתקת. בתוך חדרי הטיפולים האונקולוגים, נוצרה ע"י מכשיר זה שוב ושוב קרן עוצמתית במנת יתר קטלנית. באותו זמן, בספרות המקצועית של הנדסת תוכנה ומחשבים, הבאג הזה היה ידוע כבר, והוא נקרא לרוב RACE CONDITION. 

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

SAMD

(Software as a Medical Device)

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

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

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

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

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

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

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

Safety – Critical Software

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

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

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

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

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

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

הרגולציה על הטכנולוגיה הרפואית

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

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

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

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

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

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

בדיקות ולידציה לתוכנה רפואית

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

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

ולידציה ניתן לבצע לפי מודלים שפותחו בתעשיה עוד לפני מהפכת המחשוב. הכוונה היא לחלוקת התהליך לשלבים הבאים: IQ\OQ\PQ. בשלב הראשון INSTALLATION QUALIFICATION מתמקדים בכל ההיבטים של התקנת המערכת והבאתה למצב תפעולי. בשלב השני OPERATIONAL QUALIFICATION מתמקדים בכל הבדיקות הפונקציונליות של המערכת עם תום ההתקנה. בשלב הבא PERFORMANCE QUALIFICATION מתמקדים במדדים המתארים את הביצועים של המערכת, לדוגמא, זמן תגובה, עמידה בעומסים הנובעים מריבוי משתמשים בו-זמנית, צריכת זיכרון ומשאבי מחשב אחרים, ועוד.

בודקי תוכנה רבים מוצאים את עצמם נאבקים קשות בדרישות של PART 11 מתוך Title 21 בקובץ הרגולציות הפדראלי CFR של מינהל המזון והתרופות האמריקאי FDA. סעיף זה עוסק ברשומות אלקטרוניות וחתימות אלקטרוניות (ERES). סעיף זה מגדיר את הקריטריונים לפיהם רשומות אלקטרוניות וחתימות אלקטרוניות נחשבות אמינות, תקפות, ושוות ערך לרשומות נייר.

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

סיכום

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