לאן באמת מגיע המידע של המטופלים שלכם

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

עכשיו שאלו את השאלה הבאה: אבל האם אתם יכולים?

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

מה קורה מאחורי שאלה אחת

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

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

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

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

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

חמש שאלות ששוות יותר ממצגת מכירה

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

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

ההבדל בין ״לא נסתכל״ ל״לא נוכל להסתכל״

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

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

מה צריך להתקיים כדי שבאמת לא תהיה גישה

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

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

ומה התשובה שלנו

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

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

ורגולציה?

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

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

גם לבחירה הזאת יש מחיר

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

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

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