שאלות תשובות

יש שני ערכים רלוונטיים לייצוג קטגוריה של מרשם בקהילה:

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.

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

במרשמים – יש לכלול את כל מה שנרשם ע"י המטפל שהפיק את המרשם.

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

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

הפרופילים הם:

פרופיל DeviceRequest - ישמש לייצוג המרשמים

פרופיל DeviceDispense - ישמש לייצוג ניפוק האביזרים.

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

פרופיל MedicationRequest מייצג תרופה במרשם ולא את המרשם עצמו.

בד"כ מייצגים מרשם כרשימה של MedicationRequest אשר מאוגדת תחת משאב MedicationRequest ראשי המזהה את המרשם.

ע"מ שאפשר יהיה לדעת מי המרשם אליו שייך כל MedicationRequest ברשימה, ניתן לתעד באלמנט groupIdentifier את מס' המרשם (מזהה MedicationRequest האב), וכך לשמור על הקשר בין תרופה במרשם למרשם עצמו.

המידע מופיע באתר הקהילה בלינק הבא: https://www.fhir-il-community.org/projects/il-core-medication-request-profile

מדובר בדברים שונים:

dosageInstruction

הוראות המינון למטופל, הוראות של הרופא איך המטופל צריך לקחת את התרופה.

dispenseRequest

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

חידוד דרישות המידע - אם לא ניתן לתת כתובת מדויקת כיוון וליישות אין כתובת מדויקת, אפשר לשים data absent reason

עבור organization שהוא יחידה ארגונית שאין לו כתובת והוא לא נמצא במיקום של יחידת האב, למשל מחלקה שנמצאת בכתובת של בית החולים, נדרש לייצג בכתובת data absent reason + reason code= not applicable

בקופות - ביקור קהילתי רגיל צריך להיות מיוצג על ידי COMMUNITY-OR-HMO

ביקורי בית (שאינם במסגרת אשפוז) - HH

במקרים בהם מדובר בביקור וירטואלי בטלפון או זום - VR

ביקור ברפואה דחופה (מוקד או מיון) - EMER

במקרה של אשפוז בית - HH או INPATIENT

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

תשובת צוות האגף לבריאות דיגיטלית:

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

הסבר נוסף:

לצורך ניוד מידע, הוגדר שאבחנות מקומיות ימופו למושגי SNOMED מהסוגים הבאים בלבד: finding, disorder, event, situation. כלומר, אין למפות מונחי אבחנות מקומיים למושגי SNOMED מסוג procedure

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

למשל, "בדיקה גניקולוגית שגרתית": אסור למפות אל Routine gynecologic examination (procedure).

אבל כן אפשר למפות אל Routine gynecologic examination done (situation).

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

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

נ

לגבי זיהוי יחידות (identifier) - ניתן לייצג מזהה יחידה פנים ארגוני, כל עוד הוא יציב, ואין חובה לייצג קוד מב"ר.

לגבי סיווג יחידות (type) - בבתי החולים נכון להשתמש בקודי מב"ר לסיווג היחידות. במידה ואין קוד מב"ר מתאים, ניתן לייצג data absent reason.

המשרד רכש רישיון לאומי לשימוש בSnomed ולכן כולם רשאים לעשות שימוש בקטלוג.

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

בכל שאר המקרים (כלומר – כאשר נלקחת דגימה חדשה לצורך החקירה האבחנתית), יש לאכלס הפניה ממשאב Specimen אל ServiceRequest, וזאת רק לאחר שנוצר משאב Specimen.

ל-HL7 יש הנחיות ספציפיות בעניין זה: https://hl7.org/fhir/R4/servicerequest.html#notes 

המחשבה מאחורי ייצוג השיוך של מטפל ליחידה הארגונית אליו היא שהוא מאפשר לשייך את הטיפול שקיבל המטופל בצורה טובה יותר, כיוון שהחפיפה בין ה qualification(ההתמחות של המטפל) וה-specialty  (התפקיד שממלא ביחידה) לא תמיד קיימת.

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

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

מקור אבחנה - המקור לפריט מידע זה הוא סעיף 3.1 במסמך שעוסק באחריות על שיתוף המידע ובדרישה לסמן מידע שהוא משתף אך מקורו בספק/גורם חיצוני לארגון. לא נדרש להתייחס לפריט זה כחלק מהסל בביצוע המיפוי (מסמך דרישות המידע יעודכן בהתאם).

2.      סוג אבחנה - הכוונה לתיאור התפקיד שהאבחנה ממלאת, למשל אבחנה אקוטית (כמו אירוע לבבי) לעומת אבחנת רקע (כרונית, כמו סכרת או יתר לחץ דם).

המיפוי הוא ל- condition.category שם יש שימוש ב CodeSystem עם ערכים מוגדרים לשימוש: problem-list-item עבור אבחנה קבועה, encounter diagnosis עבור אבחנה אקוטית.

לא. נדרש להשתמש גם כן ב Patient.identifier ואם מדובר במזהה ישן לייצג עבורו use->old ואת הperiod

פרופילים אלו נמצאים באתר הקהילה: https://www.fhir-il-community.org/profiles , ובsimplifier של הcore https://simplifier.net/ilcore/ilcorehealthcareservice , https://simplifier.net/ilcore/ilcorecareteam

שיוך לגורם מבטח ייושם על ידי שימוש ב- extension HMO

הכוונה לפרופיל, להלן קישור: https://simplifier.net/ilcore/ilcorecommunication.

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

אחוז המאצ'ינג נקבע כ-30% מתוך עלות התכנית עבור בתי חולים כלליים וקופות החולים, ו10% מתוך עלות התכנית עבור בתי החולים השיקומיים, פסיכיאטריים והמר"גים.

כלומר -  במידה ועלות התכנית המלאה עבור השנה הראשונה בבית חולים כללי מסוים היא 2 מיליון שקלים - בית החולים יידרש להעמיד 600,000 שקלים במימון עצמי ומשרד הבריאות יתמוך בו בסכום של 1.4 מיליון. תמיכת המשרד תהיה עד לסכום המקסימלי שהוגדר במבחן עבור כל סוג ארגון.

נדרש לייצג מופע של ביקור נפרד לכל מטופל שלקח חלק בביקור הקבוצתי

נכון להיום מוגדרות בפרופיל Condition של הCORE שלוש מערכות הקידוד הנ"ל, כאשר המועדפת לשימוש מביניהן היא SNOMED-CT (אם לא מסופק קוד snomed, הוולידטור של HL7 נותן אזהרה).

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

הפירוט הזה נמצא בפרופילים עצמם + בתיעוד בפרופילים הנמצא באתר הקהילה https://www.fhir-il-community.org/profiles .

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

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

עבור כל מטופל (פעיל/לא פעיל) שיש לו לפחות סל אחד עבורו נדרש להביא מידע במסגרת החוק, נדרש להביא מידע דמוגרפי.

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

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

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

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

התחילית מייצגת את המקצוע/התחום שהרשיון מייצג והיא חובה לייצוג. 

רשימת קודי מב״ר לתחיליות ברישוי עוסקים ניתן למצוא בקישור

ההגדרה 0…1 על אלמנט  specimen תחת Observation מגיעה מה- base. 

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

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

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

כך שכל אחד מהם יפנה לאחד מהפרופילים של Specimen (ראו איור). במקרים בהם יש תוצאת ביניים לכל אחת מהדגימות, ניתן להשתמש ב-ObservationLab 1 ו-2 כדי לבטא תוצאה זו. אם אין תוצאת ביניים, ניתן להשתמש ברכיב dataAbsentReason. (תרשים באתר הקהילה)

לגבי communication – האלמנט עצמו אינו חובה, אבל אם מחליטים לממש אותו נדרש לייצג את ה - language.

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

יש פרופילים של הcore שעברו רק 'גיור' (התאמות בסיסיות) ולא נדרשו לאפיון/התאמות מעמיקות. פרופילים אלו נמצאים רק בsimplifier. בימים אלו אנחנו מעדכנים גם את רשימת הפרופילים באתר הקהילה כך שתכלול גם את כל הפרופילים הללו.

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

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

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

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

נדגיש כי כפי שהוצג במפגש שנערך ב15/10, חשוב להתייחס גם להגדרות שהוגדרו עבור כלל הסלים ובהן תדירות העדכון הנדרשת, מקורות המידע ומערכות המידע בארגון, המידע המגיע לארגון ממקורות חיצוניים (ספקים/מכונים) הנדרש לשיתוף הלאה.

נדרש להביא את המידע המלא, מכלל מערכות הארגון.

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

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

כן. הקטלוג בו מבצע הארגון שימוש צריך להיות אחיד עבור כלל אבחנות הארגון (אשפוז ואמבולטורי כאחד).

כן, השרת יכול לשבת בענן, בכפוף לאישור ועדת ענן ארגונית

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

אנחנו מפתחים את הכלי כך שיהיה נגיש לארגונים כ-open source המבוסס על כלים ותשתיות שאינם דורשים רישוי נוסף או תשתית ייעודית כך שלא נדרש לתמחר את הכלי כחלק מתכנית העבודה המוגשת (ניתן למצוא פירוט במסמך תיאור כלי הבדיקה

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

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

הסלייס הקיים נועד לשמש לייצוג כל הרישיונות למעט סיעוד ועו"ס (לכן חשוב ה-Prefix, שנאכף באמצעות Invariant).

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

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

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

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

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

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

הקרדינליות ורשימת הערכים המחייבת המוגדרים עבור האלמנטים clinicalStatus, verificationStatus מגיעים מHL7, כך שלא ניתן לשנות את הקרדינליות שלהם או להרחיב את רשימת הערכים הניתנים לתיעוד עבורם.

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

למשל, ייצוג אבחנה שהיא פעילה ולא פעילה במקביל.

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

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

- במידה ויש חשש שתיווצר סתירה בין ערכי הסטטוס/מידת הוודאות השונים - מומלץ שלא לאכלס את המידע כלל

לגבי sevirity - כיוון שרשימת הערכים תחת האלמנט ניתנת להרחבה (Binding = preferred), הארגון יכול להוסיף ערכים. ניתן גם להוסיך ערכים שהם שילוב של שתי דרגות חומרה יחד כדוגמא moderate-severe

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

כאשר נעשה שימוש בפאסאד FHIR הנתונים לא נשמרים בשרת הFHIR אלא מועברים בהתאם לשאילתות שהשרת יקבל.