This page is part of the T17 IG (v1.0.0: draft-1 Draft) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
אודות הפרויקט
סקירת פרוייקט
להלן שני תרשימים עסקיים המתייחסים לשלושת תהליכי ממשק התחייבויות.
תרשים עסקי - בדיקת סטאטוס התחייבות
בדיקת הסטאטוס רלוונטית הן כשלב מקדים לבקשה להפקת התחייבות, והן לבדיקת סטאטוס התחייבות כאשר המטופל מגיע פיזית לביה"ח. בדיקת סטאטוס התחייבות מתבצעת על ידי ביה"ח, אשר יוזם שליחת בקשה לקופה. הקופה מחזירה לבית החולים מענה הכולל מידע על קיום או אי קיום התחייבות עבור המטופל, לקודי השירות המבוקשים בתאריך התור המבוקש.
תרשים עסקי – בקשה להפקת התחייבות
תהליך בקשה להפקת התחייבות כולל מספר תתי תהליכים: 1) שליחת בקשה להפקת התחייבות, ביוזמת בית החולים. הקופה מקבלת את הבקשה ומחזירה מענה. אם התקבלה החלטה סופית – הקופה תחזיר אישור עם או בלי מספר התחייבות, או סירוב לבקשה. אם המענה אינו סופי, או שהתקבל אישור ללא מספר התחייבות: 2) ביה"ח יבצע דגימה חוזרת של סטאטוס התשובה. הדגימה תתבצע בהפרשים של X ימים (על פי החלטה בין שני הארגונים), החל מהבקשה להפקת ההתחייבות ועד לקבלת מענה סופי.
אופן המימוש
מדריך יישום זה (ImplementationGuide) מתייחס לממשק התחייבויות דיגיטלי בין בית חולים לקופה וכולל מספר תרחישים אפשריים, החל מבדיקת סטאטוס התחייבות ועד לבקשה של ביה"ח להפקת התחייבות וקבלת אישור/סירוב מהקופה. כל הממשק נעשה ללא התערבות נדרשת מצד המטופל*. התהליך נקרא Tofes-17, ובקצרה t17.
שלבי התהליך מצד ה- Client
תהליך בדיקת הסטאטוס נעשה בנקודת זמן מסויימת, בודדת, בה ביה"ח בודק מול הקופה האם קיימת או לא התחייבות עבור שירותים מסויימים בתאריך מסוים, והקופה משיבה בהתאם.
תהליך בקשה להפקת התחייבות הינו תהליך עם אפשרות למספר שלבים עד לקבלת מענה סופי מהקופה להפקה או סירוב של התחייבות למטופל.
להלן שלבי התהליך:
נקודת ההתחלה הינה קביעת תור בבית החולים בהתאם להמלצת המטפל. ברגע זה נוצרת בקשה להפקת התחייבות הכוללת מספר resources:
מטופל* – הפרטים החיוניים לזיהוי מטופל / תור – פרטי התור שנקבע (תאריך, מטופל ומטפל) / מיקום – פרטי ביה"ח והמרפאה או המחלקה / מסמך – כולל את ההמלצה המפורשת של המטפל לזימון חוזר / הבקשה – מזהה הבקשה, מטופל ומטפל (במידה והמידע קיים), קודי השירות הרלוונטיים וקשרים ל- resources האחרים.
ביחד מתקבלת תמונה שלמה של כל המידע הרלוונטי לבחינת הבקשה להפקת התחייבות ע"י הקופה.
* מטופל – ישנן שתי אפשרויות לזיהוי מטופל, ראו סעיף GET Patient
להלן ריכוז ה- resources היכולים לשמש בשליחת ה- request, כולל שם ה- resource ושם הפרופיל בהתאמה:
| סוג המידע | שם ה- resource | שם הפרופיל |
|---|---|---|
| פרטי הבקשה | CoverageEligibilityRequest | t17-request |
| פרטי המטופל | Patient | * IL-Core Patient |
| פרטי התור שנקבע | Appointment | t17-booked-appointment |
| פרטי המיקום בו יתקיים התור | Location | t17-requested-location |
| מסמך סיכום ביקור הכולל המלצה לביקור חוזר | DocumentReference | t17-visit-summary |
| מארז הישויות לשליחת הבקשה | Bundle | t17-bundle-req |
* פרופיל מטופל הוגדר ע"י IL Core. הגדרות הפרופיל תואמות את צרכי הפרוייקט ולא נדרשו התאמות. יהיה בשימוש רק במידה וה- Client לא ביצע
שלבי התהליך מצד ה- Server
עם קליטת הבקשה בקופה, מוחזר מענה לביה"ח, כאשר תכולתו מותנית בסוג הבקשה: במצב של בדיקת סטאטוס התחייבות, המענה יהיה אחת משתי האפשרויות:
- ההתחייבות קיימת – יוחזרו שני resources: פרטי המענה + פרטי ההתחייבות
- ההתחייבות לא קיימת – יוחזר resource של פרטי המענה בלבד. במצב של בקשה להפקת התחייבות, המענה יהיה אחת מהאפשרויות הבאות:
- אישור לבקשה להפקת ההתחייבות, כולל מספר התחייבות - יוחזרו שלושה resources לביה"ח: פרטי המענה + פרטי ההתחייבות + מסמך ההתחייבות.
- סירוב, כשל, בחינה, או אישור ללא מספר התחייבות – יוחזרו לביה"ח רק פרטי המענה.
(במקרה של אישור ללא מספר התחייבות - המספר ישלח במועד מאוחר יותר על פי הסכמה בין הצדדים).
להלן ריכוז ה- resources היכולים לשמש בהחזרת ה- response, כולל שם ה- resource ושם הפרופיל בהתאמה:
| סוג המידע | שם ה- resource | שם הפרופיל |
|---|---|---|
| פרטי המענה | CoverageEligibilityResponse | t17-response |
| פרטי ההתחייבות | Coverage | t17-obligation |
| מסמך ההתחייבות | DocumentReference | t17-obligation-doc |
| מארז הישויות להחזרת המענה לבקשה | Bundle | t17-bundle-res |
אופן זיהוי המטופל
יש שתי אפשרויות להעברת פרטי המטופל לצורך זיהויו בקופה:
- העברת Patient Resource כחלק מה- Bundle של הבקשה. במקרה זה הבקשה תכלול את כל פרטי המטופל הנחוצים לצורך הזיהוי שלו במערכות הקופה.
- ביצוע שליפה של המטופל משרת הקופה באמצעות GET Patient, סעיף GET Patient.
במידה וה- Client ביצע שליפת מטופלים באמצעות GET Patient אין צורך לכלול את המטופל כחלק ממארז ה- request, אלא להגדיר ב- reference למטופל את הכתובת היחסית שלו ב- Server (על פי התבנית: Patient/<logical id>).