שאלות תשובות
כאן מרוכזות השאלות והתשובות בנושאים השונים הקשורים לתקן ולהטמעתו
חיפוש
5.11.25
ישנן אבחנות שנרשמות בבית חולים ע"י רשמות, שעוברות על האבחנות שנכתבו על ידי הרופא ומדייקות אותן.
האם יש צורך לנייד את האבחנות שהוזנו ע"י הרשמות? או שצריך ליצא רק את האבחנות שנרשמו ע"י הרופאים?
האבחנות שנדרש לנייד הן אלו שנכתבו על ידי הרופאים, ואין צורך לייצג גם את אלו שנכתבו על ידי הרשמות.
ההנחיה לנושא מופיעה במסמך דרישות המידע, סעיף 3.3.3 'מערכות מידע':
"במידה והמידע מנוהל במספר מערכות, יש להביא את המידע מהמערכת בה המידע הינו האיכותי והעדכני ביותר, ולדאוג לכך שהמידע אותו רואים מטפלי הארגון זהה למידע שישותף ויוצג למטפלים בארגונים מקבלי המידע."
27.10.25
ב specimen pathology, יש שדה של bodySite שאמור להיות בטרמינולוגית snomed.
האם זה בסדר להעביר אותו במקום בקוד בודד, של bodySite, במספר קודים, כמו איבר, צד, מיקום בגוף, ציר?
26.10.25
An institute (hospital) department identifier consisting of five alphanumeric cahracters, a hyphen ("-") and five alphanumeric cahracters once again
moh-hospital-department
רק להבהיר ההגדרה של מספר מחלקה של מבר זה 5 תווים מייצגים מספר מוסד ואז - ואח"כ 5 ספרות של מבר למחלקה האם צודק
ראשית, נדרש לייצג מזהה חזק ארגוני לייצוג היחידה הארגונית.
נוסף אליו, ניתן לייצג מזהים נוספים ביניהם גם המזהה תחת הסלייס המתואר moh-hospital-department, אשר נוצר במטרה לתת מענה לפרויקטים קודמים בקהילה.
21.9.25
שאלה לגבי האלמנט courseOfTherapyType בפרופיל MedicationRequest האלמנט הוא חובה לאחר דיון שנעשה אצלנו עם הצוות הקליני אין לנו דרך לסווג כל הוראה בטח שלא תרופה ע"פ ה-VS הקיימים זה יותר מתאים לקהילה אשמח להבהרה לגבי האלמנט ומחשבה על הורדת החובה.
17.9.25
האם אני צריך לייצג מטפלים לא פעילים או מטפלים שנפטרו? כנ"ל לגבי יחידות ארגוניות שנסגרו בעץ הארגוני
ככל שקיים מידע שתועד בארגון ומקושר ליחידה ארגונית שנסגרה או למטפל שאינו פעיל או נפטר, נדרש לייצג מידע זה כחלק מסלי המאסטר דאטה
9.9.25
יש לנו צורך בייצוג ה-TYPE של ההוראה הרפואית בפרופיל MedicationRequest הסוגים שאנו צריכים לייצג הם: ONCE,PERIODICALLY,CONTINUOUS,SOS קיים אלמנט בשם courseOfTherapyType אבל לא קיימים שם כל הערכים הנחוצים לנו האם ניתן להוסיף לרשימת הערכים עוד ערכים שיתאימו לייצוג הסוגים של מערכת המקור?
4.9.25
איך מתייחסים לאיזור זמן בשדה מסוג datetime
כתשובה לנושא זה פורסמה הנחיה בנושא במסמך הנחיות היישום, תחת סעיף 2.3.12 העוסק ב- safety
3.9.25
היכן ניתן לייצג בפרופיל MedicationRequest את הקטגוריה של התרופה אך הכוונה היא לקטגוריות כמו : OTHER,NUTRITION,FLUIDS , DRIPS , ANTIBIOTICS
מה שמופיע באלמנט CATEGORY לא מתאים לערכים הללו.
2.9.25
כיצד מייצגים מקרה בו ישנה הוראה לתרופה שעל המטופל לקבל, הכוללת מינונים שונים שנדרש לתת בשעות שונות לאורך היום של אותה התרופה? מהו הפתרון לכך במסגרת הMedicationRequest?
ניתן לייצג מינונים שונים בשעות השונות כאיברים נפרדים בתוך ה-dosageInstruction של אותה ההוראה.
1.9.25
לגבי סל המטופל — בטבלה Identifier Type Codes אין את כל סוגי התעודות שבהם אנחנו משתמשים (למשל תעודת זהות פלסטינית).
מאיפה ניתן להשיג רשימה מלאה של כל סוגי התעודות, לפי משרד הבריאות או לפי תקן FHIR ?
ת.ז פלסטינאית נדרש לייצג על ידי שימוש בSystem המתאים שהוגדר בפרופיל, תחת הסלייס pna-id : http://fhir.health.gov.il/identifier/pna-national-id
בנוסף לSystem הנכון, ניתן לייצג את סוג המזהה (השימוש עבורו נועד המזהה) גם על ידי ה- הType. כרגע אין ערך מתאים לייצוג סוג של ת.ז פלסטינאית. נושא ההוספה נמצא בדיון בcore
27.8.25
ארגונים רבים התלוננו על זה שיש בפרופיל practitioner ביה עבור מטפלים שיש להם יותר מרישיון אחד (נניח רופא שהוא אח, או עובד סוציאלי שהוא פיזיו). אין לזה מקום בפרופיל הקיים, ובסלייס של הרישיון יש מקום לפרופיל אחד בלבד. נשמח לשינוי קרדינליות או לכל פתרון אחר שיש לכם.
ראשית, נדרש לוודא ששני מספרי הרישיון תקינים ושייכים למטפל, ושאין בלבול בין מספר רישיון ומספר תעודה.
שימו לב: עבור כל מקצוע (כגון רפואה, רפואת שיניים, סיעוד) יכול להיות מספר רישיון אחד בלבד למטפל.
במקרים בהם יש למטפל מספר רישיונות המשמשים כמזהים של המטפל בארגון, והם נדרשים לייצוג ע"י הSystem: http://practitioners.health.gov.il/Practitioners (לדוגמא רופא שהוא גם טכנאי US), ההמלצה היא לייצג מספר ריסורסים עבור המטפל בהתאם
הנחיה מתאימה פורסמה במסמך הנחיות היישום
18.8.25
בפרופיל HDPSpecimen יש אובייקט בשם collection. האובייקט כולו הוא לא חובה, אבל משום מה יש חובה על שדה bodySite בתוך האובייקט. לא הגיוני לי, אין לנו bodySite, אבל יש לנו שדות אחרים חשובים בתוך האובייקט כמו זמן צום, קישור למטפל וכו'. האם אפשר להוריד את החובה ב bodysite, אחרת לא נאכלס את כל האובייקט וחבל.
7.8.25
האם נכון שבשנת 2026 אלא הפרופילים שמשתמשים בהם? AllergyIntolerance, Encounter, DocumentReference,
MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement, Dosage
מיפוי הריסורסים הנדרשים ומומלצים לכל סל מופיע במסמך 'מיפוי סלי מידע לפרופילים ולאלמנטים'. שם ניתן לאמת את הפרופילים שנדרש להשתמש בהם
6.8.25
כיצד נדרש לסמן מידע פיקטיבי/ טסט ב-FHIR, כך שהוא לא ינויד?
באופן כללי, כל ארגון יכול לבחור כיצד לממש את הנושא. (בגרסה הקרובה של הנחיות היישום תפורסם הנחיה לשיתוף סלקטיבי של מידע שת וכל לסייע בנושא).
ניתן להשתמש במנגנון הmeta.security (המשמש לייצוג שיוך לסלי מידע ולחיסיון מידע), ולאתר את הערכים התואמים את הצורך. שימו לב שהערך 'HTEST' נדרש לשימוש לטובת תיוג שני מטופלי טסט שעל כלל ארגון לייצג לטובת הPCM (סעיף 3.8 במסמך הדרישות הטכנולוגיות) ולכן לא ניתן יהיה להחריג תיוג זה באופן גורף.
בפגישת המיישמים מתאריך 06/08/25 נציגי הארגונים ביקשו לקבל הנחיה מצוות ה- Core בנושא, על מנת שתהיה אחידות באופן היישום. סוכם שלשם כך הארגונים יעבירו usecases מייצגים בעבורם נדרש ההנחיה.
6.8.25
האם עלינו להשתמש בפרופילים מתוך ILCore, ILHDP, או בשילוב של שניהם?
פרופילי הILHDP הינם פרופילים יורשים מפרופילי הILCORE, כלומר כוללים את כלל ההגדרות המופיעות בILCORE. ההבדל הוא שפרופיל הILHDP תואמים גם את דרישות הרגולציה לניוד מידע כדוגמא תיוג לסלי מידע או חיוב מימוש אלמנטים מסויימים בפרופיל.
6.8.25
האם נכון שבשנת 2025 נדרש להשתמש בפרופילים הבאים:
Patient
Practitioner
PractitionerRole
Organization
Condition
הפרופילים הללו הן אכן הפרופילים המחייבים למימוש הדרישות ב2025.
נוסף אליהם, ישנם פרופילים נוספים שניתן לבצע בהם שימוש במידה וקיים מידע נוסף בסלי המידע של 2025 שנדרש לייצג, כגון:RelatedPerson, DocumentReference, CareTeam, Location, OrganizationAffiliation
(פירוט הפרופילים המחייבים ומומלצים לשימוש תחת כל סל מופיע בקובץ 'מיפוי פרופילים לסלי מידע' https://www.fhir-il-community.org/legislation)
6.8.25
מהו ההבדל המרכזי בין ILCore ל־ILHDP, ומתי נכון להשתמש בכל אחד מהם?
במידה ואתם כפופים לניוד המידע, נכון לממש את המידע על פי המוצג בפרופילי הHDP, כיוון שאלו הם הפרופילים שמולפ יתבצעו בדיקות הסרטיפיקציה לבדיקת עמידת הארגונים בדרישות ניוד מידע.
במידה ותממשו לפי פרופילי הHDP, תהיו תואמים וולידיים גם אל פרופילי הILCORE
4.8.25
אם אני רוצה לחבר בין תרופה במרשם למרשם, אני מבין שיש אובייקט של BasedOn, אבל הוא מקושר רק לפרופילים שה medication בהם חובה, ככה שאין לי אפשרות לבצע את החיבור, כי המרשם עצמו לא מכיל תרופות.
האם יש לזה משמעות, או שאפשר להשאיר את כל התרופות במרשם ללא אבא מאגד? כי אם חייב לאגד את התרופות במרשם תחת טופס מרשם, נדרש לשנות את הקישור ולהוסיף Medication Request בו אין חובה להכניס פרטי תרופה.
פרופיל MedicationRequest מייצג תרופה במרשם ולא את המרשם עצמו.
בד"כ מייצגים מרשם כרשימה של MedicationRequest אשר מאוגדת תחת משאב MedicationRequest ראשי המזהה את המרשם.
ע"מ שאפשר יהיה לדעת מי המרשם אליו שייך כל MedicationRequest ברשימה, ניתן לתעד באלמנט groupIdentifier את מס' המרשם (מזהה MedicationRequest האב), וכך לשמור על הקשר בין תרופה במרשם למרשם עצמו.
המידע מופיע באתר הקהילה בלינק הבא: https://www.fhir-il-community.org/projects/il-core-medication-request-profile
עדכון מיום 4.8.24:
ב- FHIR קיימים מספר מנגנונים בהם ניתן להשתמש בכדי לאגד תרופות למרשם : אלמנט groupIdentifier מאפשר לכל MedicationRequest שהוא שורה במרשם להצביע על MedicationRequest שהוא המרשם הראשי, משאב List מאפשר לשלוח ביחד רשימת תרופות ממויינות , וישנו גם requestGroup אשר מאפשר במקרים יותר מורכבים לקבוע את הסדר של התרופות במרשם (למשל בפרוטוקול תרופות ביולוגיות). ההמלצה העיקרית היא להשתמש
ב groupIdentifier כיוון שמדובר בשימוש באלמנט קיים בפרופילים ולכן הוא הכי פרקטי ולא דורש ליצור משאבים חדשים לשם האיגוד (כמו במקרה של List או requestGroup ), אך כמובן זה תלוי ביוז קייס ולכן ההחלטה נקבעת ברמת היישום.
3.8.25
סל מטפל- אלמנט specialty: הקרדינליות לא מופיעה כ-1 בסימפליפייר, אבל באקסל פריטי מידע מופיע מחייב (מתאריך 3.4.25) לפי מה לעבוד?
פריט המידע התמחות בסל מטפל הינו פריט מ ידע מחייב, וכך זה מופיע גם במיפוי שפורסם. יכול להיות שיש טעות בפרופיל. נבדוק ונעדכן אם נדרש.
חשוב לשים לב שישנם מקרים בהם פריט מידע מוגדר במחייב בסל מידע, אך בפרופיל האלמנט לא יוגדר כמחייב (קרדינליות מתחילה ב1) כיוון שישנם אילוצי תקן שלא מאפשרים זאת. לכן חשוב למלא אחר הדרישות במסמכי דרישות המידע והמיפוי שפורסמו והעדכונים שלהם מעת לעת.
3.8.25
האם קיים מידע על כמות הפניות שהארגון יקבל מבחוץ?
קשה להעריך את כמות הפניות שצפויה להגיע לכל ארגון, ולכן לא ניתנה הנחיה בנושא.
המטרה היא שהתשתית המוקמת תתאים לכל מיני תרחישי שימוש, בהם ניוד מידע, ולכן פורסמו דרישות ביצועים וזמינות בהן הארגון נדרש לתמוך (סעיף 3.4 במסמך הדרישות הטכנולוגיות).
3.8.25
הקטלוג שלנו הוא Icd9 עם הרחבות של קודים מקומיים, הקודים המקומיים הם עבור קודי icd9 שלא מספיק מפורטים כאשר יש תיעוד לקוד icd9 המקורי בצד, האם יש עוד גורמים שעובדים בתצורה זו? + האם אתם מעבירים גם את קודי המקור שעליו בוצעה ההרחבה, בנוסף ולקודי ה snomed והקודים המקומיים?
לצד קוד snomed מומלץ וחשוב לייצג גם קוד ותיאור פנים ארגוני. אם מערכת הקידוד הפנימית אינה ICD9 סטנדרטי, משמע שישנה מערכת קידוד ארגונית לה יש להגדיר system ולייצג קודים ותיאורים מתאימים תחתיו.
3.8.25
האם בפרופיל ארגון Organization האלמנט partOf הוא מייצג היררכיה בין יחידות? והאם היא תהיה כלפי מעלה? כלומר, תמיד היחידה הכי קטנה תצביע על יחידה מעליה, ועל יחידה מעליה, וכו' .. או רק רמה אחת של יחידה מעל יחידה?
אלמנט ה- partOf נועד לייצג את המבנה הארגוני. ה- partOf של כל יחידה צריך להכיל ייצוג של היחידה הארגונית שמעליה, ולא את כלל ההיררכיה
3.8.25
ביישום סל מטופל מה עשיתם במקרים בהם היה שינוי במספר הת.ז. של המטופל? לדוגמא תייר שעלה לארץ ושונה ממספר דרכון למספר ת.ז?
עבור מקרים בהם מתבצע שינוי במזהה העסקי של מטופל (למשל החלפת מזהה זמני לת.ז. קבועה, החלפת ת.ז. קבועה לקבועה אחרת או טעות בהקלדת ת.ז ואח"כ איחודה עם הת.ז. הנכונה),יש לעדכן את ריסורס המטופל כך שיכיל את המזהה החדש ולמחוק ממנו את המזהה הישן.
שימו לב: אם המזהה הלוגי של מטופל היה מבוסס על מזהה עסקי שהוחלף, למשל מבוסס על ת.ז מוצפנת, על הארגון לוודא שהוא יודע לנהל ולשמור על הקשר בין הריסורס ליישות המידע במערכות הקליניות והתפעוליות שלו.
במקרה ששויך מידע רפואי למטופל הלא נכון (למשל, תיעוד בטעות של מידע קליני לתיק בן משפחה לא נכון) יש להעביר "כירורגית" את הנתונים ממטופל אחד לשני ע"י עדכון ההפניות בריסורסים למזהה הלוגי המתאים של הרשומה.
הנחיה מתאימה תפורסם גם במסמך הנחיות היישום
31.7.25
שאלה על מזהה מספר רישיון prac-lic: האם אפשר להגדיר מספר רישיונות למטפל אחד? לפי הסימפליפייר מוגדר 1...0. האם זה אומר שניתן לאכלס רק מספר רישיון אחד?
ראשית, נדרש לוודא ששני מספרי הרישיון תקינים ושייכים למטפל, ושאין בלבול בין מספר רישיון ומספר תעודה.
שימו לב: עבור כל מקצוע (כגון רפואה, רפואת שיניים, סיעוד) יכול להיות מספר רישיון אחד בלבד למטפל.
במקרים בהם יש למטפל מספר רישיונות המשמשים כמזהים של המטפל בארגון, והם נדרשים לייצוג ע"י הSystem: http://practitioners.health.gov.il/Practitioners (לדוגמא רופא שהוא גם טכנאי US), ההמלצה היא לייצג מספר ריסורסים עבור המטפל בהתאם
הנחיה מתאימה פורסמה במסמך הנחיות היישום
31.7.25
האם אפשר להגדיר מספר רישיונות למטפל אחד תחת identifier? לפי הסימפליפייר, הקרדינליות מוגדרת 1...0. האם זה אומר שניתן לאכלס רק במספר רישיון אחד
ניתן לאכלס רק מספר רישיון אחד תחת ריסורס. אם נדרש לייצג יותר ממספר רישיון אחד כמזהה של מטפל, יש לייצג עבורו יותר מריסורס אחד (ראו סעיף 2.3.3 במסמך הנחיות היישום)
24.7.25
בסל מידע סיכומים ישנם ארבעה פריטי מידע מינימליים:
אבחנה מבדלת, סיכום ביקור, התרשמות הגורם המטפל, והנחיות טיפול.
האם קיימת חשיבה למימוש שדות אלו בתקן ואם כן, מה הכיוון ?
ההתלבטות שלנו זה האם ליצור Resource שמקושר לסיכום או לייצר הרחבה. ואז אם מייצרים הרחבה, עדיף שההרחבה תהיה מוגדרת לאומית.
בכדי לחדד, הכוונה היא לכלול את כלל הסיכומים שנכתבו בביקור ביניהם התרשמות הגורם המטפל, התייחסות למצבו של המטופל, תיאור בדיקות שביצע, הנחיות לטיפול וכל טקסט נוסף שנכתב במהלך הביקור.
במסמך הנחיות היישום, סעיף 2.3.5 ישנה הנחיה לייצוג טקסטים ומסמכים שתוכל לסייע.
בנוגע לאופן מימוש האבחנה המבדלת, נבדוק ונייצר הנחיה מתאימה
24.7.25
האם מספיק לייצג את ההוראה (MedicationRequest) באמצעות ה-Group Identifier או שיש צורך ליצור Medication Request שיאגד את כל ההוראות שניתנו יחד?
נדרש ליצור מופע של Medication Request שיאגד את כל ההוראות/המרשמים שניתנו יחד, והמזהה שלו הוא זה שיופיע תחת groupidentifier במופעי ה-medicationRequests המייצגים את התרופות בהוראה/במרשם
15.7.25
האם מוכנות סל מידע לסרטיפיקציה היא בהכרח בסביבת יצור?
האם מוכנות סל מידע בהכרח כוללת טעינה היסטורית מלאה?
בדיקת הסרטיפיקציה תתבצע אל מול סביבת הייצור הארגונית.
ייבדקו דרישות שונות (דרישות מידע, טכנולוגיות, הנחיות יישום), ביניהן גם מילוי הדרישה של העומק ההיסטורי המוגדר עבור על סל שייבדק.
15.7.25
כיצד ניתן לזהות אבחנות אדמיניסטרטיביות בכדי שלא לכלול אותן תחת סל האבחנות?
אבחנות "אדמיניסטרטיביות" הן מונחים שתועדו ברכיב האבחנות של התיק הרפואי למרות שאינם מהווים אבחנה רפואית קלינית Diagnosis או סימן / סימפטום קליני – Clinical finding (לרוב מדובר במשהו שנעשה למטופל או עבורו, ולא במשהו שיש למטופל) שאין לכלול תחת סל האבחנות.
מצורפת רשימת תיאורי אבחנות לדוגמא שתשמש כהכוונה.
יולי 2025
איך לייצג תיעוד בתיק המטופל (למשל, תיעוד אבחנה) שהוא תוצר של תהליך אוטומטי או אלגוריתם ולא תועד על ידי גורם מטפל?
במידה ותיעוד במערכת הקלינית נוצר כתוצאה מתהליך אוטומטי ולא בוצע ע"י גורם מטפל אנושי (כדוגמא, יצירת אבחנה באופן אוטומטי במערכת בעקבות קבלת תשובת מעבדה), הדרך לייצג את המידע היא ע"י הצבעה על ריסורס Device (שימוש בalternate-reference) ולא ע"י הצבעה על Practitioner.
לשם כך נוספה ההרחבה alternate-reference תחת האלמנט condition.recorder בפרופיל Condition.
15.7.25
ב obervationlab חובה להכניס יחידת מידע לתוצאה כמותית בפרופיל רגולציה, אבל הובא לידיעתי שיש מקרים של תוצאות כמותיות (מספר דצימלי), ללא יחידת מידה. האם אפשר להוריד משם את החובה?
יחידת מידה היא מידע חשוב לייצוג כחלק מתוצאה של בדיקת מעבדה, ועל כן נכון להשאירו כמחייב.
במקרים בהם ישנן תוצאות כמותיות בהן סופרים דברים שלמים, ויחידת המידה עצמה היא 'יחידה', ניתן לייצג תחת אלמנט quantity את הקוד '1'
15.7.25
עד כמה להכריח מידע חובה בהקשר של ביקורים, אם מייצרים מופע לאינטראקציות שאינן ביקור בפועל, ואין להם בהכרח את כל האינפורמציה הנדרשת לייצוג עבור הביקור.
פריטי המידע שהוגדרו במסגרת סל ביקורים הם אלו שהוגדרו בעלי ערך גבוה לניוד מידע. נכון לייצג את המידע הנדרש ככל שקיים, ובמידה שלא ניתן לייצג Data Absent Reason
יולי 2025
כיצד נדרש לקודד סוגי יחידות?
עבור בתי החולים, נדרש לקודד סוגי יחידות לפי קוד מב"ר (DepartmentTypeMoH)
עבור הקהילה, הוגדרה רשימת ערכי סוג יחידות ארגונים מייצגת (ILCoreCommunityUnitType)
בשני המקרים, אם אין קוד סוג יחידה מתאימה ברשימות הערכים המוגדרות בפרופיל, נדרש לייצג את קוד פ נים-ארגוני המייצג את סוג היחידה
9.7.25
מהי הקטגוריה הנכונה לייצוג תחת האלמנט category ב-MedicationRequest לייצוג מרשם בקהילה? האם זה Community-other?
יש שני ערכים רלוונטיים לייצוג קטגוריה של מרשם בקהילה:
community-hmo :Includes medications to be administered or consumed in HMOs (this would include HMO clinics, doctor offices, ect.
community-other:Includes medications to be administered or consumed in community care settings (this would include long term care or nursing homes, hospices, patient’s home, and home hospitalization etc.
הראשון מהם רלוונטי להתנהלות בתוך מתקני קופת החולים , והשני להתנהלות של הקופה המתבצעת במתקנים אחרים (בבית המטופל, מרכז גריאטרי וכו').
9.7.25
האם ב medicationDispense וב medicationRequest מצפים לקבל כל קוד שיש בבית המרקחת לתוך אובייקט medication? כולל אביזרים, תכשירים, משחות שיניים, או רק תרופות? בעיקרון, כל מה שקונים בבית מרקחת, גם אם זה לא תרופה ונמצא על המדף (יכול להיות גם מסטיק), יכול להירשם כניפוק (גם אם ללא מרשם).
לגבי מרשם, ניתן לתת מרשם לאביזרים, שאין להם שדות חובה כמו medication, route. האם גם מרשמים אלו צריכים להיות מיוצגים כחלק מסל התרופות?
במרשמים – יש לכלול את כל מה שנרשם ע"י המטפל שהפיק את המרשם.
בניפוקים – אביזרים שמנפקים כנגד מרשם ואביזרים שהם עם הפניות (כמו כסא גלגלים) – הם אלו שצריך לכלול תחת הסל. לעומתם, מוצרי מדף שהקופה מוכרת בבית המרקחת כמו משחת שיניים אין צורך לכלול.
לגבי אופן היישום – יישום מרשמים וניפוקים עבור אביזרים צריך להתבצע על ידי פרופילים אחרים שאינם פרופילי Medications.
הפרופילים הם:
פרופיל DeviceRequest - ישמש לייצוג המרשמים
פרופיל DeviceDispense - ישמש לייצוג ניפוק האביזרים.
צוות CORE מידל את הפרופילים הללו והם יפורסמו כחלק מפרופילי ה CORE. בנוסף, יוגדרו עבורם פרופילי HDP רלוונטיים לרגולציה.
9.7.25
dosageInstruction- הוא חובה בפרופילים, אבל במרשמים נראה ש dispenseRequest מתאים יותר. האם לא מעדיפים שנשתמש ב dispenseRequest במרשמים במקום, או שזה לא אחד שבא על חשבון השני?
מדובר בדברים שונים:
dosageInstruction
הוראות המינון למטופל, הוראות של הרופא איך המטופל צריך לקחת את התרופה.
dispenseRequest
איך בית המרקחת אמור לספק את התרופה. מדובר בדרך כלל במידע אופציונאלי, לשימוש הרוקח.
9.7.25
הערות לכתובת (לדוגמא:" אחרי העץ בסוף הרחוב יש לפנות ימינה") – האם לאכלס ב address.text? או ב extension מתחת ל Line?
ומה הסיבה שה Line הוא 0…* ? מה המשמעות של מספר Lines בכתובת אחת
- האלמנט line הוא מערך כי התפקיד שלו לאפשר לשים את כל המידע הדרוש להגעה אל הכתובת.
- הדרך המומלצת ליישום, היא לממש את כל המידע של הכתובת תחת הextension של ה line, כולל הstreet name, house number, וגם את ההנחיה של אופן ההגעה לכתובת שציינת.
- אם בנוסף לline אתם מייצגים את המידע גם תחת address.text, חשוב לוודא שהוא לא יכיל מידע שלא קיים באחד מהאלמנטים האחרים תחת address.
9.7.25
סימון איש קשר ראשי למטופל. ב 5R יש patient.contact.rank אבל ב R4 לא.
האם להוסיף ל extension ב patient.contact ?
בכדי לייצר איש קשר ראשי, יש להשתמש ב-patient.contact.relationship אשר לו binding ל- http://hl7.org/fhir/ValueSet/patient-contactrelationship
אם יש קוד מתאים סמנטית בVS יש להשתמש בו, אחרת ניתן להגדיר קוד מותאם אישית.
19.6.25
אחד מפריטי המידע בסל יחידה ארגונית הוא "מיקום".
במסמך הישן (נספח ג' – מיפוי פרופילים לסלי מידע),Organization הוא פרופיל חובה ול location הוא פרופיל ממולץ למימוש הסל הזה.
במסמך ה"לפרסום" מיפינו רק ל Organization ובאופן כללי לדעתי בכל המיפויים לא התייחסנו לשאלה האם פרופיל היעד הוא מומולץ או מחייב.
נתקלתי בשאלה איך לממש את הדרישה ל"מיקום" עבור יחידה ארגונית שאין לה מיקום מדויק, למשל "מחוז דרום" ועלתה הצעה לתת לה את הכתובת של מנהלת המחוז.
אני נגד פתרון זה כי:
1. מנהלת/מטה המחוז היא לרוב יחידה ארגונית בפני עצמה
2. כתובת המנהלת/מטה היא מטעה וגם חסרת ערך - פעילות שקרתה במחוז דרום יכלה להתרחש באילת כך שהכתובת של המנהלת בבאר שבע אינה רלוונטית
אני חושב שצריך לעשות אחד מהשניים:
1. לסייג את הדרישה הזו כך שתהיה רלוונטית רק למקרים בהם יש כתובת אחת רלוונטית לכל היחידה הארגונית (למשל "בית חולים רמבם")
או
2. לתת הנחיית יישום שבמקרים האלו ב Organization.address אפשר להספק כתובת כגון "מחוז דרום"
חידוד דרישות המידע - אם לא ניתן לתת כתובת מדויקת כיוון וליישות אין כתובת מדויקת, אפשר לשים data absent reason
עבור organization שהוא יחידה ארגונית שאין לו כתובת והוא לא נמצא במיקום של יחידת האב, למשל מחלקה שנמצאת בכתובת של בית החולים, נדרש לייצג בכתובת data absent reason + reason code= not applicable
15.3.25
כיצד נכון להשתמש בערכים תחת encounter.class?
תשובה:
בקופות - ביקור קהילתי רגיל צריך להיות מיוצג על ידי COMMUNITY-OR-HMO
ביקורי בית (שאינם במסגרת אשפוז) - HH
במקרים בהם מדובר בביקור וירטואלי בטלפון או זום - VR
ביקור ברפואה דחופה (מוקד או מיון) - EMER
במקרה של אשפוז בית - HH או INPATIENT
בקופות - ביקור קהילתי רגיל צריך להיות מיוצג על ידי COMMUNITY-OR-HMO
ביקורי בית (שאינם במסגרת אשפוז) - HH
במקרים בהם מדובר בביקור וירטואלי בטלפון או זום - VR
ביקור ברפואה דחופה (מוקד או מיון) - EMER
במקרה של אשפוז בית - HH או INPATIENT
20.4.25
ביקורים ללא המטופל, נדרשים ליישום? בין מטפל למטפל על המטופל, התייעצות בין רופא משפחה והמטולוג על תרופה שרוצים לתת למישהו. נכנס תחת ביקורים?
כן. גם ייעוצים בין מטפלים לגבי המטופל נדרש להכניס תחת סל ביקורים
18.6.25
בתיק הרפואי בארגון שלנו מתעדים בשדה האבחנות מלבד מחלות וסימפטומים גם מונחים שהם פרוצדורות בהם ניתוחים ופעולות כמו "כריתת תוספתן" ו-"קולונוסקופיה", "ביופסיה" ושירותים ובדיקות כמו "בדיקה גניקולוגית שגרתית" ו"מתן מרשם". האם אנחנו אמורים לשתף את המונחים האלה בסל מידע "אבחנות"? אם כן, איך נכון למפות אותם ל SNOMED?
תשובת צוות האגף לבריאות דיגיטלית:
פרוצדורות, שירותים ובדיקות אינם אמורים להיות חלק מסל מידע "אבחנות" אלא אמורים להיות משותפים במסגרת סל "פרוצדורות", אפילו אם הם תועדו בשדה "אבחנות". המשמעות היא שנדרש לזהות את הפרוצדורות ולתייג אותן לסל המתאים ולא לסל אבחנות.
הסבר נוסף:
לצורך ניוד מידע, הוגדר שאבחנות מקומיות ימופו למושגי SNOMED מהסוגים הבאים בלבד: finding, disorder, event, situation. כלומר, אין למפות מונחי אבחנות מקומיים למושגי SNOMED מסוג procedure
יחד עם זאת, עבור חלק מהפרוצדורות אפשר למצוא מושג SNOMED מקביל מתוך הסוגים המותרים.
למשל, "בדיקה גניקולוגית שגרתית": אסור למפות אל Routine gynecologic examination (procedure).
אבל כן אפשר למפות אל Routine gynecologic examination done (situation).
שימו לב, המיפוי הזה הוא תקין רק אם מניחים שהפרוצדורה תועדה בהקשר מסוים – שהיא אכן בוצעה, ולא שהיא "תוכננה", או "בוטלה", למשל.
לכן, אם מיפיתם מונח מסוג פרוצדורה למושג SNOMED שהוא מקבול (בד"כ situation), ניתן לשייך אותו לסל מידע אבחנות, אך אפשר גם לסנן החוצה את המונחים מסוג פרוצדורה מראש.
נ
18.6.25
איך אפשר לטעון אנשי צוות אדמיניסטרטיבים (הנהלת חשבונות לדוגמה, מזכירות וכ"ו) שאין להם קישור ליחידה שיש לה קוד מב"ר.
כי לא ניתן ליצור יחידה שאין לה קוד מב"ר (שדה חובה ביחידה) וכתוצאה מזה לא ניתן ליצור מטופל ללא שיוך ליחידה (שדה חובה במטופל)
לגבי זיהוי יחידות (identifier) - ניתן לייצג מזהה יחידה פנים ארגוני, כל עוד הוא יציב, ואין חובה לייצג קוד מב"ר.
לגבי סיווג יחידות (type) -
בבתי החולים - נכון להשתמש בקודי מב"ר לסיווג היחידות.
בקהילה - פורסמה רשימת סוגי יחידות מותאמת.
במידה ונדרש לייצג סוג יחידה שאינו חלק מרשימות הערכים האלו המוגדרות בפרופיל, וכיוון שמדובר בעוצמת קשירה extensible, ניתן לייצג את סוג היחידה הארגוני.
16.6.25
אבחנות במשפחה שמתועדות בתיק המטופל - האם נכללים בסל האבחנות של המטופל? אם כן כיצד מסמנים שהאבחנה היא של בן משפחה ולא של המטופל עצמו?
תוספת - 16.7.25 - בינתיים ראיתי שיש בכלל resource אחר לנושא אבחנות במשפחה – FamilyMemberHistory
הנושא נמצא בבדיקה. ייתכן שכדי לתת מענה לצורך זה, יהיה צורך להרחיב את סל האבחנות ב2026 כך שיכלול גם אבחנות במשפחה
10.6.25
כיצד מתמודדים עם האתגר ביישום סל האבחנות המלא, כאשר נדרש ליישם את סל הביקור ים אחריו, וישנה הפניה מהאבחנה אל הביקור?
להלן הסבר כללי לגבי טיפול בהפניות בעת טעינת סוגי משאבים שונים, שייתן מענה גם למקרה של החיבור בין אבחנות וביקורים:
כמעט בכל משאב FHIR ישנן הפניות למשאבים אחרים. במהלך תהליך הטעינה, ייתכן שחלק מהמשאבים טרם יעלו לשרת.
לפניכם מספר דרכים אפשריות להתמודדות:
1. ניהול ידני של מזהים לוגיים למשאבים
בהינתן שניהול המזהים מתבצע ידנית, ניתן לייצר מראש מזהים לוגיים ולהשתמש בהפניות מילוליות (literal references) גם אם המשאב המופנה עדיין לא קיים בשרת.
שימו לב: חלק מהשרתים כמו (HAPI FHIR) אוכפים שלמות הפניות, ולכן יש לוודא שהגדרה זו מושבתת לצורך יישום הגישה. בנוסף, ייתכן שהשרת ייכשל באינדוקס הפניות למשאבים שאינם קיימים — מומלץ לבדוק את הנושא מול ספק שרת ה-FHIR שלכם.
2. שימוש בהפניות לוגיות (logical references)
אם קיים מזהה עסקי יציב עבור המשאבים העתידיים, ניתן לאכלס בשלב הראשון הפניה לוגית ולאחר הוספת המשאבים להשתמש בכתיבה חוזרת כחבילת טרנזקציה (transaction bundle) עם הפניה מותנית (conditional references) כדי להשלים את ההפניה המילולית. התהליך דורש כתיבה מחדש, אך הלוגיקה פשוטה ואוטומטית יחסית.
3. שימוש ב-PATCH לעדכון ממוקד
אם אתם יודעים לקשר בין המזהים הלוגיים של המשאב הקיים לבין המשאבים החדשים שנוספו, אפשר לבצע עדכון ממוקד של אלמנטי ההפניה באמצעות FHIR PATCH ללא צורך בקריאת המשאב כולו.
פברואר 2025
האם שימוש בטרמינולוגיה עולה כסף? ראיתי עלויות של משרד הבריאות ל- SNOMED – האם רוכש עבור כל מדינת ישראל? או שנדרש לרכוש פר ארגון/שימוש?
המשרד רכש רישיון לאומי לשימוש בSnomed ולכן כולם רשאים לעשות שימוש בקטלוג.
מאי 2025
לפי המידול הקיים specimen (דגימה) מצביע על service request (הפנייה) בקשר של 1 לרבים וזה אומר ההצבעה חייבת להיות מהדגימה להפניה. האם המשמעות היא שהורדתם את האופציה ההפוכה - להצביע מההפניה לדגימה בלבד?
תחת ServiceRequest קיים אלמנט specimen ממנו ניתן להצביע על הדגימה עצמה, אבל הוא נועד רק למקרים בהם מתבצעת בקשה לחקירה אבחנתית על דגימה קיימת (לדוגמה – כאשר במעבדה כבר קיימת דגימת דם ומבקשים לבצע תרביות נוספות על אותה דגימה קיימת) – מצב שככל הנראה הוא נדיר וכמעט ואינו מתרחש.
בכל שאר המקרים (כלומר – כאשר נלקחת דגימה חדשה לצורך החקירה האבחנתית), יש לאכלס הפניה ממשאב Specimen אל ServiceRequest, וזאת רק לאחר שנוצר משאב Specimen.
ל-HL7 יש הנחיות ספציפיות בעניין זה: https://hl7.org/fhir/R4/servicerequest.html#notes
מאי 2025
לפי מסמך דרישות המידע, נדרש לייצג שיוך של מטפל ליחידה ארגונית כאשר בקופה זה סניף. כמו כן, בקופת חולים רופאים/מטפלים מנויידים בין הסניפים לעיתים קרובות.
בסל "ביקורים" אנו מפנים לPRACITIONER ומציינים היכן הביקור התרחש בפועל ולא מפנים לתפקיד.
מה הערך בשיוך ליחידה הארגו נית והאם דיווח תפקיד ברמת הקופה ללא פירוט לסניפים תקין מבחינת הסרטפיקציה?
המחשבה מאחורי ייצוג השיוך של מטפל ליחידה הארגונית אליו היא שהוא מאפשר לשייך את הטיפול שקיבל המטופל בצורה טובה יותר, כיוון שהחפיפה בין ה qualification(ההתמחות של המטפל) וה-specialty (התפקיד שממלא ביחידה) לא תמיד קיימת.
אם אין ערך שניתן לייצג אשר יש בו היגיון, או שלא קיים שיוך של המטפל ליחידה ארגונית, ניתן לייצג את רמת הארגון עצמו.
כלומר, במקרים אלו דיווח ברמת קופה ללא סניפים תקין מבחינת הסרטיפיקציה.
פברואר 2025
פריטי מידע במסמך הדרישות תחת אבחנות שלא ברור לנו לאילו אלמנטים בפרופיל ה- FHIR הם מכוונים: 1. מקור אבחנה 2. סוג אבחנה
מקור אבחנה - המקור לפריט מידע זה הוא סעיף 3.1 במסמך שעוסק באחריות על שיתוף המידע ובדרישה לסמן מידע שהוא משתף אך מקורו בספק/גורם חיצוני לארגון. לא נדרש להתייחס לפריט זה כחלק מהסל בביצוע המיפוי (מסמך דרישות המידע יעודכן בהתאם).
2. סוג אבחנה - הכוונה לתיאור התפקיד שהאבחנה ממלאת, למשל אבחנה אקוטית (כמו אירוע לבבי) לעומת אבחנת רקע (כרונית, כמו סכרת או יתר לחץ דם).
המיפוי הוא ל- condition.category שם יש שימוש ב CodeSystem עם ערכים מוגדרים לשימוש: problem-list-item עבור אבחנה קבועה, encounter diagnosis עבור אבחנה אקוטית.
פברואר 2025
סל מידע דמוגרפיה - האם מזהה מטופל ישן מוגדר כ - extension?
לא. נדרש להשתמש גם כן ב Patient.identifier ואם מדובר במזהה ישן לייצג עבורו use->old ואת הperiod