פיתוח מערכת AI לפרמקוביג'ילנס (Pharmacovigilance AI)

פרמקוביגילנס AI: היכן ניתוח דיווחים ידני נשבר

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

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

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

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

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

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

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

השפעות מדידות: מהירות, שלמות, עקיבות

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

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

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

חלק הפעולות הידניות יורד прежде всего במיון ובניתוח ראשוני — השלבים ההמוניים ביותר. נעלם גם סוג הכשלים הקשורים לגורם האנושי בשגרה: מועדים שחלפו במקרים עם חומרה לא ברורה, כפילויות אבודות של אותו מטופל, אי-התאמות בין טופס E2B(R3) לכרטיס הפנימי. בסוף נשאר לצוות סט מדדים אחד שמראה היכן בדיוק נדרש שכלול.

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

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

השוואת תוכניות

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

שלבי הטמעה: מביקורת תהליכים ועד מסירה

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

1. ביקורת תהליכי פרמקוביגילנס. עוברים על כל המקורות — דואר, פורטלים, ספרות, פניות למוקד — ומתעדים פורמטים, היקף, עיכובים ומי מקבל החלטה בכל שלב. הפלט הוא מפת מקורות עם שכיחות ואיכות נתונים.
2. תרשים זרימות נתונים. מאשרים תרשים יעד: מה מחולץ אוטומטית, מה עובר לבדיקה ידנית, היכן נמצאות נקודות הבקרה וכיצד נשמרת היסטוריית שינויים לכל מקרה.
3. הגדרת מילונים. מחברים מילונים רפואיים ומדריכים, מגדירים התאמת מונחים, כללים לקביעת חומרה, כפילויות וצפיות — על דוגמאות אמיתיות מהארכיון של הלקוח.
4. כללי ניתוב מקרים. מתעדים למי ובאיזה זמן עובר כל מקרה, כיצד פועלת אסקלציה באיחור, מי תורן ומה קורה כאשר עובד אינו זמין.
5. בדיקות קבלה. מריצים את המערכת על מקרים היסטוריים עם תשובה נכונה ידועה: בודקים שיעור מקרים שנותחו נכון, מספר התראות שווא והזמן עד להעברה הלאה בתהליך.
6. מסירה והדרכה. מוסרים קונפיגורציות, תרשימים ונהלים, מדריכים את הצוות, מפעילים מצב מקביל: המערכת והמומחים עובדים במקביל, אי-התאמות נבחנות, ורק אחר כך מכבים את המסלול הידני.

מה נשאר אצל הלקוח: קונפיגורציות ונהלים

ההטמעה מסתיימת לא בהדגמה של שירות עובד אלא במסירה של ערכה שלפיה כל צוות יוכל לתפעל את המערכת. כל המפורט נמצא במאגר משותף ובבסיס ידע פנימי — בלי הסכמות בעל פה ובלי "הידע של מהנדס אחד".

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

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

ניתוח מקרה בוחן: לפני ואחרי בזרם דיווחים

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

מה שינו

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

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

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

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

במה שונה ניהול סיגנלים מניתוח מקרים?

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

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

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

ספקות נפוצים: פרמקוביגילנס, AI ובדיקות

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

מה קורה עם דיווחים שלא זוהו?

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

כיצד מסוננות כפילויות של דיווחים?

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

כיצד מתבצעת ולידציה ומה עושים עם בסיס נתונים פעיל?

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

נדון במשימה: מהיכן להתחיל במתחם שלכם

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

• ערוצי קליטה: רשימת מקורות לדיווחים על תגובות לוואי — פניות ספונטניות, תוכניות קליניות, ספרות — ובאיזה צורה הם מגיעים היום.
• דוגמאות נתונים: 30–50 כרטיסים אנונימיים ו-2–3 סיגנלים שנותחו במלואם — עליהם בודקים את שלמות החילוץ שאפשר להגיע אליה.
• תקן: אם המומחים כבר סימנו מקרים ידנית, דרושים זוגות "קלט — תשובה מאומתת", אחרת אין במה למדוד איכות.
• גישות: מתחם בדיקות, חשבונות לקריאה בלבד, מדריכי תרופות וטרמינולוגיה רפואית, כללי עיבוד נתונים אישיים.
• מתחם רגולטורי: אילו דוחות ובאילו מועדים נוצרים כיום, מי מאשר שינויים וכיצד בנויה ולידציה של המערכת.
• נקודת חיבור: לאן מחזירים את התוצאה — למערכת בטיחות פעילה, לניהול מסמכים אלקטרוני או בהחלפת קבצים.

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