לעדן

חזרה למסמך הראשי

מקורות המידע של בית החולים

נכתב בידי עוזר AI שעובד עם יוסף, מתוך תיעוד העבודה במרכז, כרקע לפגישה ב־20.10.

העמוד הזה מתאר את מערכות הרשומה של שיבא שהמוצרים של המרכז קוראים מהן, ואת הדרך שבה המרכז מגיע אליהן. כל מה שאליס, SmartER ו־TMR ו־AI Flows יודעים על מטופל מגיע בסוף מכאן, דרך רוזטה. ההיסטוריה של רוזטה עצמה, כשירות, נמצאת בעמוד רוזטה ו־Wildfire; כאן הדגש הוא על המקורות: מה כל אחד מחזיק, איך ניגשים אליו, מה מופה ובידי מי, ומה מגביל את העבודה מולו.

למה צריך שכבה בין המוצרים למקורות

עד 2025 כל מוצר במרכז הגיע לנתונים הקליניים בעצמו, בשאילתות SQL שנכתבו ביד ונשמרו כמחרוזות בקובץ אחד. ב־9.5.2025 גל גושן, מנהל ה־hub, ניסח את האילוץ שכל העבודה נבנתה סביבו: אי אפשר לחלק גישה ישירה למסדי הנתונים של בית החולים, וכל גישה כזו צריכה מטרייה מסודרת. באותה תקופה כבר פעל במרכז אגם הנתונים NEXUS, שניצן חלבי מובילה מאז 2022, ובו ETL־ים מסודרים למחקר. רוזטה לא באה להחליף אותו. היא יושבת לצידו, כשכבה שקוראת את המקורות החיים ומגישה אותם למוצרים שצריכים מידע עדכני על מטופל ברגע נתון.

השכבה עצמה לא שומרת עותק של המידע. כך תיאר אותה שי גנכיל לצוות פוטון ב־7.10.2026, וכך חזר גיא דולינסקי ב־11.10: רוזטה היא חזית מעל המקורות, עם cache למבנה ובלי מאגר נתונים קליני משלה. היא מתרגמת בקשת GraphQL לשאילתת SQL מול המקור המתאים, ומחזירה את התוצאה עם הקישור למקור שממנו הגיעה.

קמיליון: איך הרשומה בנויה

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

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

מתחת לגיליון יש sections וכותרות, וכאן נמצא הקושי העיקרי. המסכים של כל מחלקה נבנים בבית החולים, והם כותבים את הנתונים ל־DB של קמיליון תחת field ו־folder שמשתנים ממחלקה למחלקה. בסשן לצוות פוטון ב־11.10 נתן יוסף דוגמה: ״מחלה נוכחית״ יושבת תחת field אחד ביולדות ותחת field אחר בקרדיולוגיה, ולכן מיפוי קבוע שנכתב מראש מצליח במחלקה אחת ונכשל באחרת. ב־7.1.2026 הוא הוסיף שאותו סוג שדה יכול לייצג מחלה נוכחית או ביקור מרפאה, תלוי בהקשר. ב־26.12.2025 נמצא שרוב הכותרות תחת רופא הן תיאור או אבחנה עם field קבוע, וכבר למחרת, ב־27.12, התגלה שהשדה שמתחת לכותרת אינו קבוע בין רשומות. מכאן נולד הצורך בשאילתות דינמיות, שנבנות לפי המבנה של כל רשומה ולא לפי מיפוי קבוע.

נקודת המפנה הייתה ב־22.11.2025. בזמן שחיפש משהו אחר מצא יוסף בכונן משותף תיעוד פנימי של קמיליון מהדרכה שנערכה ב־2015, ומתוכו הבין איך קמיליון מרכיב את המסכים שלו מתוך הרשומה. הלב של זה הוא טבלת ה־file folders: לפי ההסבר של גיא ב־11.10, היא מה שמקשר בין הביקור לבין התוכן, ואומרת לכל section שרואים במסך מאיפה מגיע המידע שלו. גיא כתב ב־23.11.2025 שכבר הצביע קודם על ה־file folders, ושמה שלא היה ידוע לו הוא ה־join; שתי הגרסאות נשמרות ברשומה. אלון קבע באותו ערב שהממצא הוא הזדמנות לבנות את השליפה מחדש בצורה נכונה. בסוף דצמבר 2025 כמעט כל שדה בקמיליון היה נגיש.

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

בצד הכלים, יוסף מתחזק מאז מאי 2026 מאגר תיעוד של טבלאות קמיליון, MetaVision ו־QFlow, עם DDL, מפתחות זרים ודוגמאות. שי כתב מאוגוסט 2026 מסמכי ייחוס מובנים לכל טבלה, עם מטרה, גרעיניות, עמודות ומיפוי שדה־לכותרת. מרים ג׳בלי, מצוות הדאטה, היא סמכות ה־SQL על טבלאות קמיליון ו־QFlow; ב־3.2.2026 היא מצאה שנתוני תוכנית טיפול יוצאים לא נכון, כתבה את השאילתה הנכונה וביקשה לתקן יחד את הקוד של רוזטה. רחל ויטיס, מצוות הדאטה סיינס, הגדירה את הדרישות הקליניות של המיפוי עד ינואר 2026, כולל ההכרעה לפצל כל section במקום לשרשר.

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

המרכז לא קורא מקמיליון הייצורית. הוא קורא מרפליקה שבית החולים מחזיק, ושבה המרכז הוא אורח. מזה נובעים רוב האילוצים. ב־17.6.2026 אלון ניסח את זה כך ב־Rosetta Engineering Team: משך הזמן של משימה תלוי ברפליקה, ולכן הקצב המרבי נקבע מבחוץ ולא רק בקוד. ב־17.9 יוסף הוסיף ששרתי QFlow ו־RIS חלשים אפילו מהרפליקה.

הקיץ של 2026 הפך את האילוץ הזה לממשי:

בצד הרינדור: קמיליון מרנדרת את המסכים שלה בצד השרת, ב־HTML שנבנה ב־PHP. קוד המקור שייך לספק, ולמרכז יש רק את ה־HTML וה־JavaScript כפי שהם נראים מבחוץ. בסשן של 11.10 יוסף תיאר איך הוא משתמש בזה: דרך gateway שבנה, Codex שולף את ה־HTML של מסך, משווה אותו למיפוי הקיים ולטבלאות, ופותח pull request ל־Wildfire. לדבריו, מה שלפני שלושה חודשים היה עבודה ידנית קשה הפך כמעט לאוטומטי. עוד לפני כן, ב־8.6.2025, נעשה ניסיון ראשון ללכת מהמסכים אל הטבלאות; הוא לא הצליח, והשאילתות נכתבו אז ביד. הרעיון חזר והצליח אחרי ממצא התיעוד בנובמבר.

הקשר עם הספק מנוהל בידי גיא. ב־7.9.2026 הוא דיווח בקבוצה על שיחה עם נציג הספק: קמיליון 9 נפרסת בשיבא לבדיקות בזמן שהמרכז עובד מול גרסה 5; מגרסה 8 יש שני רכיבים, גלריית אפליקציות בתשלום שיכולות לקרוא מרכיבי קמיליון ולכתוב לחלקם, וקטלוג של ממשקי REST לקריאה, ולעיתים גם לכתיבה; ודור הבא של קמיליון צפוי ב־2027. לפי הספק השדרוגים שומרים על מבנה ה־DB הקיים, אבל התשובה לא הייתה מדויקת, וגיא חובר לארכיטקט שלהם להמשך. גיא תיאר גם ב־29.12.2025 את הטופולוגיה שמול קמיליון, כולל proxy שעומד לפניה.

נאמנות למקור: למה לא FHIR ולא סכמה משלנו

השאלה הזו עלתה כמעט בכל פגישת חפיפה, והתשובה המלאה ביותר ניתנה בסשן Wildfire לצוות פוטון ב־11.10.2026.

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

היו שלוש אפשרויות: להמשיך עם FHIR, להמציא סכמת ביניים של המרכז, או להיצמד לסכמת המקור. נבחרה האחרונה, והיא נקראת במרכז true to source. המשמעות לפי גיא: מבינים איך קמיליון עובדת ואילו חיבורים היא עושה מאחורי הקלעים, ומציגים את המידע כך שרופא או אחות שרגילים לקמיליון יזהו אותו. הכותרות זהות, האבחנות והתלונה העיקרית נקראות באותו שם, והתוכן מפורמט כמו במקור. כשנשאל אם צרכן קורא ״field 22״ או ״מהלך בדיון״, גיא ענה שהצרכן בוחר ״מהלך בדיון״, והמערכת יודעת איזו שאילתה מביאה אותו. יערה הוסיפה באותו סשן שהגמישות הזו היא העיקר: אפשר למדל בדיוק איך קמיליון, MetaVision או כל מקור אחר נראה, כגרף, והשאלה אם זה ב־GraphQL או ב־SQL משנית.

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

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

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

מזה נגזר ״מקור המידע שיבא״ ברוזטה: לוגיקה של המרכז שאינה קיימת באף מקור. גיא נתן דוגמה: current encounter אינו ביקור מסוים לפי רשומה, אלא לוגיקה שמקבלת מטופל ותאריך ומחזירה את שרשרת האשפוזים של אותו אירוע. את ה־resolver המאוחד של ״Sheba encounter״ כתב שי, לפי ההגדרה של גיא (ספטמבר 2026). באותו סשן הוסכם שהלוגיקה הזו, שהיום כתובה בקוד, צריכה להפוך לרכיב שאפשר להוסיף ולהגדיר; לא נקבעו לכך בעלים ומועד. דוגמה נוספת לבעיית הקישור: בפגייה, מידע ב־MetaVision יכול להיות של האם או של התינוק, והקישור ביניהם עובר דרך קמיליון. וב־15.10 יוסף תיאר מקרה הפוך: אותו מדד, למשל דופק, מופיע גם כמדידה וגם בתוך מכתב השחרור, ושני העותקים מתנגשים. אלון הציע לפתור את זה בינתיים בצורה הפשוטה ביותר, ולהתייחס אליהם כשני אירועים.

המקורות האחרים

מערכת MetaVision (טיפול נמרץ). מערכת הטיפול הנמרץ, וגם של מיון כללי, מיון ילדים ופגייה, עם אותה סכמה ומחרוזת חיבור שונה לכל יחידה. הגישה עוברת בטפסי הרשאת תוכנה ומחייבת לציין לאיזו יחידה (גיא, 14.3.2026). ב־17.1.2026 שי ציין שקיים תיעוד ל־MetaVision, אצל ניצן חלבי, שמחזיקה גם את מיפויי ה־ETL. בסוף פברואר גיא ובר סבר פתחו PR ראשון ברמת הביקורים; ב־2.3 יוסף דיווח ש־MetaVision עובדת ב־Wildfire, וב־6.3 נוספה רשמית לרוזטה. ב־22.3 יוסף ואופיר אליאס מצאו בה הרבה יותר מידע מאשר בקמיליון. ב־15.5 נוסף מעבר בין יחידות QFlow ו־MetaVision. גיא סיפק ב־18.5 את ה־SQL שממפה את סטטוסי התרופות, מתוכנן ועד ניתן. אלון מיפה בעצמו הערות וסימנים חיוניים לקראת פגישה עם הספק (24.7), וב־31.7 יוסף דיווח שהמבנה הבסיסי פוצח, עם מסך תואם MetaVision בדרך. ב־5.8 הכריעו הקלינאים שאין ב־MetaVision תוצאת מעבדה שאין בקמיליון. ד״ר רועי טונק הוא הפוסק הקליני במחלוקות מיפוי. המצב באוקטובר: הנתונים קיימים ברוזטה, אבל MetaVision עוד לא נגישה ב־Studio, ולפי גיא ב־18.10 היא לא עובדת כראוי אצל הצרכנים. בדיון ב־15.10 הוגדרה כפחות דחופה מקמיליון 9, Studio ואיתן.

מערכת QFlow (מרפאות חוץ). מערכת התורים והביקורים במרפאות. ב־2.3.2026 גיא קבע שהרחבת SmartER למרפאות מחייבת מיפוי של DB ה־QFlow, וב־8.3 יערה הכניסה את QFlow לרוזטה כעבודת ספרינט בצד הדאטה. ב־5.4 גיא הגדיר אותה כדחופה, וב־7.4 יוסף דיווח שמיפה אותה במלואה. ב־17.6 החליף יוסף את המיפוי ההיוריסטי בין יחידות QFlow ליחידות קמיליון במיפוי הנכון, כך שמדדים והוראות תרופות תואמים את המקור. אלירן כתב את ה־worker של QFlow בצד אליס, שמחמם מראש מטופלים עם תור למחרת, וגם עבד על מיפוי היחידות. האילוץ כאן הוא החוזק של השרת: ב־10.9 טהר אברג׳ל דיווח על timeouts רבים מ־QFlow, ונמצא ששאילתה שנקראה על שם קמיליון שלפה גם מ־QFlow ומ־MetaVision; ב־17.9 יוסף כתב ששרתי QFlow ו־RIS חלשים מהרפליקה.

מערכות RIS, Medcon ו־Ada. ב־RIS נמצאים ההזמנות והתיעוד של הדימות. ב־26.3.2026 יוסף ציין שאין לו הרשאות משלו ל־RIS; הנתונים הגיעו לכונן משותף דרך מי שהייתה לו גישה, והחיבור של גיא חושף רק views. ב־11.5 הוא דיווח שפיצח את RIS כמעט במלואו וביקש דוגמאות לאימות, ובאותו ספרינט נסגר סיפור הפניות RIS. ביולי הגרף כבר כלל תחת המטופל הזמנות דימות, מחקרי PACS והנחיות רדיולוגיה. את Medcon הוסיף יוסף לרוזטה ב־6.3.2026, על בסיס המכתבים שהמערכות החיצוניות כותבות לקמיליון; גיא היה זה שדחף אותה כמקור הבא. Ada הוא שירות ה־OCR של הפניות סרוקות, פרויקט שהחל ב־2024 אצל ניצן חלבי ושי, ושרפאל מוביל מפברואר 2026. ב־13.5.2026 גיא הגדיר את Ada כמקור גלובלי מחוץ לקמיליון, שנשלף לפי מזהה בלי פילטר; יוסף הציע להכניס את ההפניות ל־Wildfire כדי לצמצם את שירות Ada הישן, וב־14.5 Ada הייתה זמינה ב־Wildfire. בפועל, SmartER עדיין מגיעה להפניות הסרוקות ב־SOAP ישירות לשרת Ada ולא דרך רוזטה (ספטמבר 2026).

מכתבים. מכתבים הם מקור בפני עצמו, משני סוגים: מכתבי קמיליון, שיוסף שחזר במאי 2026 מתוך ה־sections שמרכיבים אותם, ומכתבים ממערכות חיצוניות, שיוסף חיבר ל־MetaVision ול־Medcon במרץ. ב־3.8.2026 הוא הסביר למה מכתבים כבדים בשליפה המונית: כל מכתב נשלף, ואז מחלצים מה־DB מאילו טבלאות הוא הורכב. ביוני עלה באג בצד אליס שחייב הגבלה על שליפת מכתבים חיצוניים, וביולי הועלתה השערה שהשינוי בשליפת המכתבים תרם לעומס בחימום. באמצע אוקטובר עלתה ההתנגשות בין מדדים במכתבים למדדים הגלובליים, שתוארה למעלה. ב־15.7 יוסף ציין השלכה מעשית: פיילוט של אליס בבית חולים אחר לא מחייב לפרוס שם את רוזטה, רק את המכתבים.

מערכת איתן. איתן מביאה מידע מחוץ לשיבא, ובראשו תרופות; SmartER משתמשת בה למשל לתרופות של חצי השנה האחרונה. שי חיבר את איתן לרוזטה ב־13.1.2026, ויערה אמרה אז שכניסת איתן לרוזטה תקבע את מעמדה. ב־16.2 הבנייה של resolvers דינמיים הוצגה גם כתקדים שיאפשר לחבר את איתן לצד קמיליון. באוקטובר יוסף הרחיב את המיפוי: ב־15.10 דיווח שיש לו כמעט את כל המידע, כולל ביקורים במוסדות אחרים ומסמכי PDF, ותיאר את השרת כשירות SOAP. ה־resolver עדיין לא היה מוכן לפי דבריו, והוא שקל למזג אותו עם עבודת ה־Studio. הבעיה העיקרית של איתן היא יציבות וגישה. ב־14.10 יוסף גילה שבסביבת SHOW הגישה לאיתן תלויה ב־node שעליו רץ הפוד, ולכן לפעמים עבדה ולפעמים לא. גיא הסביר שההסכם עם איתן לא אפשר לפתוח את הגישה באופן רחב, ולכן היא צומצמה. לפי יאיר גינת ויערה איתן עובדת רק בבטא ובפרוד. ב־18.10 גיא ושי דיווחו ששליפות מאיתן ב־AI Flows לא עובדות טוב, ויוסף כתב ששיאל, שעבד מולה קודם, נהג לעטוף כל קריאה בעשרות ניסיונות חוזרים. גישה מסודרת לאיתן ממחשבי המפתחים עדיין נבדקת.

מערכת Cato. גיא ובר הוסיפו את Cato ל־Wildfire ב־22.2.2026, ישירות מהמערכת ולא מאגם הנתונים.

קמיליון 9 ונפטון

בית החולים עובר מקמיליון 5 לקמיליון 9, ולצידה נבנית שכבת API של הספק. במרכז קוראים לפרויקט נפטון. לפי מה שיערה הציגה ב־weekly של 4.10.2026, נפטון כולל שלוש נקודות כניסה מתוך קמיליון: Scribe, שצוות אחר בונה והמרכז מחבר, עם יעד של 15.10; כפתור של אליס על מטופל; וחלון מצומצם של SmartER. ההחלטות על אליס ו־SmartER נקבעו לאופק של 1.1.2027. ב־14.10 יערה פתחה בלוח פריט ״Neptune - Data in Rosetta״ לספרינט 34, בעדיפות גבוהה וללא בעלים מוגדר.

הכרונולוגיה של המיפוי:

מה מגביל עכשיו, ומה הסוכן ממליץ

המצב נכון לאוקטובר 2026, בקצרה:

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

המלצות הסוכן, לפי סדר:

  1. בדיקות חוזה לכל מקור. שאילתה קבועה אחת לכל מקור, עם תוצאה צפויה, שרצה אחרי כל שינוי ובכל סביבה. כך ״MetaVision לא עובדת אצל הצרכנים״ הופך מדיווח בעל פה למדידה. הצורך הזה עלה כבר ב־18.10, כשאלירן ביקש בדיקות אינטגרציה ורגרסיה לתלות המרכזית של המרכז.
  2. דוח מסודר לספק על קמיליון 9. אלון כבר ביקש לאפיין את אי־העקביות. דוח עם דוגמאות לא מזהות, דרך הקשר שגיא מחזיק עם הספק, יקדים את הבעיה לפני שהיא מגיעה לייצור.
  3. בקשה רשמית אחת על אינדקסים ועל מסלול גישה לאיתן. שתי השאלות פתוחות מהקיץ: האם אפשר להוסיף אינדקס ברפליקה, והאם יש מסלול מסודר לאיתן ממחשבי המפתחים. להערכת הסוכן, תשובה כתובה, גם אם היא שלילית, עדיפה על המשך עבודה סביב הנחה.
  4. תיעוד מקור אחד במקום אחד. הידע על המקורות מפוזר היום בין מאגר התיעוד של יוסף, מסמכי הייחוס של שי, התיעוד של ניצן ל־MetaVision ו־AI-Docs. צוות פוטון הם מי שירוויח מכך ראשון.

חזרה לתשובות

רוזטה ו־Wildfire · הסטודיו · הצוותים והתפקידים · מה קורה עכשיו ומה פתוח (אוקטובר 2026)