שאלות תשובות
כאן מרוכזות השאלות והתשובות בנושאים השונים הקשורים לתקן ולהטמעתו
חיפוש
מאי 2026
האם בארגון המיישם Encounter מסוג InPatientCareSegment נדרש לקשור את כל המשאבים קליניים (Resources) שתועדו במהלך האשפוז ל-Encounter זה? וקישור ל hospitalization encounter יבוצע אך ורק כאשר לא קיימת חלוקה לשתי רמות או במידה ומשאבים מקושרים במערכות מקור רק אליו?
התשובה תלויה בסוג השדה המקשר בין המשאב ל-Encounter:
1. שדה הקישור Resource.encounter (היכן האירוע התרחש)
הכלל: הקישור חייב להתבצע ל-CareSegment הספציפי ביותר שבו התרחש האירוע.
דגש: ברוב המוחלט של המקרים, קישור של משאב קליני לרמת ה-HospitalizationEncounter (העליונה) בלבד, כאשר קיימת חלוקה למקטעים, ייחשב כבעיית איכות נתונים.
2. שדות Encounter.diagnosis או Encounter.reasonReference
הכלל: כאן מותר ואף רצוי לבצע קישור כפול.
דגש: מכיוון שניתן לקשר משאב קליני אחד למספר Encounters, יש לקשר אותו לכל ה-Encounters הרלוונטיים – גם לרמת ה-HospitalizationEncounter (העליונה) וגם ל-CareSegment הספציפי, בהתאם להקשר הקליני.
דוגמא:
אם נוצר אבחון (Condition) במיון (ER):
ה-Condition.encounter (השיוך הפיזי של המשאב) יצביע על ה-ER CareSegment.
לעומת זאת, בשדות ה-diagnosis או reasonReference, ה-Condition יופיע כקישור בשני המקומות: גם ב-HospitalizationEncounter וגם ב-ER CareSegment, כדי לשקף את הקשר לשתי הרמות.
אפריל 2026
במידה שיש גם טקסט וגם PDF - האם הם צריכים להיות מיוצגים על ידי ריסורס אחר (ID אחד) או תחת ריסורסים שונים?
נדרש לייצר שני ריסורסים שונים, בעלי ID שונה, עבור כל טקסט או כל מסמך, גם אם נוצרו באותו הביקור
אפריל 2026
כיצד ניתן למדל ביקורים אבלטוריים היררכיים באמצעות ILHDP Encounter Community/HMO?
אפשר למדל ביקורים אמבולטוריים בבית חולים עם ILHDP Encounter Community/HMO tu ע"י היררכיה של ביקורים כמו באשפוז (שימוש בILHDP Encounter Hospitalization ובILHDP Encounter Inpatient Care Segment), כתלות באופן בו הביקור ממודל בארגון. הדגש החדש הוא שה-class חייב להיות תואם לקטגוריית הביקור - "ambulatory"
אפריל 2026
מה עושים כאשר תרופות קבועות מופיעות בכפילות? כלומר, ישנה חזרה על התיעוד שלהן בתיק של המטופל?
ככל שידוע איך למזג את המידע ושאכן מדובר בכפילות של אותה תרופה, נכון לייצג את המידע פעם אחד ולא בכפילות. ככל שהארגון לא יודע להתמודד עם הכפילויות האלו או לא יודע להגיד שמדובר בדיוק באותה התרופה, נכון לייצג את המידע גם אם הוא מופיע מספר פעמים ככפילויות (נכון גם לאבחנות ולסלים אחרים)
אפריל 2026
האם נדרש לייצג תרופות קבועות שהופסקו?
תרופות קבועות נדרש לייצג בעומק היסטורי מלא, גם כאשר מדובר בתקופות קבועות שהופסקו
פברואר 2026
כיצד אמורים לייצג בסל מידע סיכומים דנו את האלמנט masterIderntifie שלא הוגדר כמחייב ואת האלמנט identifier שהוגדר כחובה.
בייחוד לאור העובדה שבגרסת R5 של FHIR האלמנט masterIdentifier הוסר.
באופן כללי, בגרסת R4:
הidentifier הוא מערך שמטרתו לייצג מזהה מסמך (ניתן להשתמש בו גם בכדי לייצג מזהה גרסה של המסמך)
בעוד שהmasterIdentifier נועד לייצוג גרסה ספציפית אחת של המסמך.
מתוך ההבנה שלא כל הארגונים מנהלים גרסאות של מסמכים, וייתכן כי לארגון תהיה רק גרסה אחרונה ועדכנית ביותר של מסמך, החלטנו לחייב רק את הidentifier תחת DocumentReference.
כלומר המינימום הנדרש לייצוג הוא הidentifier ואם קיימות גרסאות למסמך, נכון לעשות שימוש גם בmasterIdentifier.
בכל הנוגע לשינויים בגרסת R5 והלאה:
הidentifier נשאר כשהוא, בעוד שהmasterIdentifier הוחלף באלמנט version שנועד לייצוג הגרסה אבל בניגוד ל masterIdentifier הוא מסוג string (ללא סיסטם).
בעצם, יש הקלה במעבר לR5 ונראה שכאשר נעבור לגרסה מתקדמת יותר של HL7 מולה הפרופילים יהיו מיושרים, לא יידרש שינוי מורכב בהקשר
אפריל 2026
מה נדרש לעשות במקרים בהם אין תאריך סיום לביקור?
ראשית, נדרש לייצג עבור כל ביקור סטטוס עדכני. עבור ביקור שהסתיים נדרש לייצג את הערך finished. בנוסף, כיוון שלא נכון לייצג ביקורים כפתוחים כאשר בפועל הסתיימו (מה שיקשה על בניית ציר זמן בצד ארגונים מקבלי מידע בניוד מידע), נדרש לאכלס את תאריך סיום הביקור בזמן בו סטטוס הביקור השתנה להסתיים (finished) או בתאריך סיום לפי לוגיקה מוגדרת בצד הארגון (ראו IG של enocunter)
פברואר 2026
בסל תרופות (על כל בניו) - האם יש/מתכוננת דרישה של ניוד מידע למערכת קידוד מסוימת?
הטרמינולוגיה הנדרשת בעולם התרופות עבור ניוד מידע היא SNOMED-CT
(הוצג בוובינר ב- 29.12.25 להקלטה)
פברואר 2026
כיצד נכון לייצג בביקור שאבחנה שנכתבה במסגרתו היא גם 'אבחנה ראשית' וגם 'אבחנה באשפוז'?
האפשרות הפשוטה ביותר היא לחבר את האבחנה פעמיים לביקור עם diagnosis.use שונה: פעם אחת כאבחנה ראשית ופעם נוספת כאבחנה באשפוז
פברואר 2026
בסל סיכומים, האם ניתן להניח שרק סיכומים שקיימים כמסמך רלוונטיים לסל?
אני שואל כי האובייקט של ה attachment חובה גם בפרופיל הבסיסי.
זה אומר שאם יש לי סיכום בטקסט חופשי שמטפל כתב, אבל לא נכנס למסמך, הוא לא אמור להיות בסל?
גם טקסטים צריכים להיות מיוצגים תחת הסל, ולא רק סיכומים בתצורת מסמך.
במידה וטקסט מתאים לייצוג תחת סל הסיכומים (ולא תחת סל אחר), הדרך הקלה ביותר במקרה זה היא להזין את הטקסט ישירות בתוך השדה DocumentReference.content.attachment.data עם ה-MIME type המתאים.
(חשוב לשים לב שאלמנט ה-Narrative (כלומר - Resource.text) אינו רלוונטי במקרה זה, כיוון שה-Narrative אמור להכיל את סיכום המשאב עצמו (המטא-דאטה של המסמך))
פברואר 2026
בסל מטופלים כאשר במטופל דרכונאי אין לי את רץ הנפקת הדרכון מה אני יכול לשים? מישהו יכול לכוון?
אם אין ארץ הנפקת דרכון, לא נכון לבצע שימוש בסיסטם הקיים בפרופיל, ונדרש לייצר סיסטם מותאם.
שימו לב שהוגדר אילוץ על האלמנט identifier שמחייב להגדיר סיסטם
פברואר 2026
במידה וקלינאי יצא ונכנס מחדש לאותו התפקיד (כגון אחות חיסונים שפועלת בעיקר במהלך חודשי החורף).
כרגע האלמנט period מוגדר שם עם קרדיונאליות 0...1
האם להשאיר את הperiod שלו ריק? האם להשאיר את הstartdate לפי התאריך הראשון שהוא נכנס לתפקיד או הפעם האחרונה שבה נכנס לתפקיד?
האם אתם עשויים לשנות למערך כך שנוכל לכתוב במדויק באיזו תקופות הוא עבד במשרה?
הדרך הנכונה לייצג תקופות העסקה של עובד היא באמצעות PractitionerRole, ולייצר ריסורס נפרד לכל תקופת העסקה, כולל שימוש באלמנט active כדי לייצג האם הRole פעיל או לא.
אם לא ניתן לעשות זאת, יש לממש PractitionerRole אחד לעובד, מבלי לייצג את תקופת ההעסקה שלו (להשאיר את האלמנט period ריק), אך חשוב לייצג תחת הריסורס את כל ההתמחויות של המטפל גם אם הן ללא תקופות זמן.
פברואר 2026
האם ביקור במכון דימות (עם או בלי פעולה פולשנית) בקהילה צריך להיכנס גם לסל ביקורים, או שיהיה חלק מסל דימות בהמשך ככה שאין צורך?
רשומת הביקור צריכה להופיע גם תחת סל הביקורים
פברואר 2026
בביקורים של הקהילה: האם באלמנט קטגוריה Encounter.class נדרש להכניס ערך של
"COMMUNITY-OR-HMO" או ניתן לייצג רשימה פנימית של סוגי ביקור הקיימת בארגון?
COMMUNITY-OR-HMO זה אכן הערך המתאים לייצוג תחת קטגוריית הביקור, אלא אם יש ערך מתאים יותר כמו EMER עבור ביקור במרכזי חירום המופעלים על ידי הקופה, או HH עבור ביקורי בית המתרחשים בבית המטופל וכו'.
אם אתם רוצים לייצג גם סוגי ביקור פנימיים שלכם – ניתן לייצג אותם תחת האלמנט type.
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
איך בית המרקחת אמור לספק את התרופה. מדובר בדרך כלל במידע אופציונאלי, לשימוש הרוקח.