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

ה- Client, ביה"ח, שולח לקופה בקשה לבדיקת סטאטוס/להפקת התחייבות באופן הבא:

POST [server]/CoverageEligibilityRequest/$submit

זוהי בקשה לבדיקה/הפקת ההתחייבות, באמצעות submit$ של CoverageEligibilityRequest.

מבחינת תקן FHIR ניתן להפעיל את פעולת submit$ באמצעות ריסורס CoverageEligibilityRequest בודד, או באמצעות Bundle המכיל אותו וכן ריסורסים נוספים הרלוונטיים לבקשה. לצורך האחידות הוחלט כי המימוש במסגרת פרויקט זה יהיה תמיד באמצעות Bundle, גם אם לא מועברים ריסורסים נוספים ל-Request. כלומר, נשלח Bundle המכיל את הריסורס הייעודי לבקשה, ביחד עם ריסורסים נוספים (על פי מידת הרלוונטיות) הקשורים אליו באמצעות reference.
שליחת הבקשה הינה סוג של "הזנקת" תהליך, כך שהבקשה והריסורסים הנלווים נשלחים, ובאופן סינכרוני מוחזר מענה מה- Server, מהקופה. המענה יתכן אישור / סירוב / כשל / בבחינה.
המענה מורכב ממספר וריאציות של ריסורסים, כתלות בתשובת הקופה לקיום התחייבות. להלן תרשים התהליך, כולל כל הריסורסים הרלוונטיים, המייצג מצב של בקשה להפקת התחייבות וכתגובה מתקבל מענה של אישור, עם מספר ההתחייבות:

במצב של בדיקת סטאטוס התחייבות ישלח CoverageEligibilityRequest ויוחזר CoverageEligibilityResponse. במידה וקיימת התחייבות, יוחזר גם Coverage.

דגימת סטאטוס של בקשה להפקת התחייבות

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

ה- Client, ביה"ח, דוגם את הקופה באופן הבא:

GET [server]/CoverageEligibilityResponse/id

ה- id של ה- CoverageEligibilityResponse ידוע ל- Client מהבקשה המקורית, לכן הדגימה על פי המזהה הלוגי.

במידה והסטאטוס התעדכן, ביה"ח בודק האם הבקשה אושרה או סורבה. אם אושרה – ביה"ח בודק האם התקבל גם מספר ההתחייבות המאושרת, באלמנט הבא:
CoverageEligibilityResponse.insurance.coverage.reference

במידה והתקבל מספר ההתחייבות, ביה"ח יתשאל את הקופה לקבלת ריסורס ההתחייבות + מסמך ההתחייבות עצמו: Coverage + DocumentReference.

GET [server]/Coverage?_id=[resource_id]&_revinclude=DocumentReference:related

ה- id של ה- Coverage כפי שהתקבל במענה העדכני מהקופה. בתגובה ל- GET יתקבל Bundle מסוג searchset אשר יכיל את שני ה- resources המייצגים את ההתחייבות.

עדכון בקשה להפקת התחייבות

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

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

הקישור לבקשה המקורית נעשה על ידי האלמנט: CoverageEligibilityRequest.supportingInfo.

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

• האיבר supportingInfo[n].information.type – קיים איבר אחד במערך עם ערך מסוג "CoverageEligibilityRequest", כלומר ניתן לזהות שהבקשה מקושרת לבקשה אחרת, אותה היא באה להחליף.

• האיבר status – ערך הסטאטוס הינו active ולא cancelled.

ניתן להיעזר גם בתרשים בסעיף Request - עץ החלטות

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

ביטול בקשה להפקת התחייבות

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

הקישור לבקשה המקורית נעשה על ידי האלמנט: CoverageEligibilityRequest.supportingInfo.

כיצד ניתן לזהות שמדובר בבקשה לביטול בקשת התחייבות, ולא בקשה חדשה או בקשה מעודכנת?

• האיבר status – ערך הסטאטוס הינו cancelled. זהו המצב היחיד בו יהיה ערך ביטול בבקשה להתחייבות.
• האיבר supportingInfo[n].information.type – קיים איבר אחד בלבד במערך, והערך שלו יהיה מסוג "CoverageEligibilityRequest", כלומר ניתן לזהות שהבקשה מקושרת לבקשה אחרת, אותה היא באה לבטל.

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

תגובת הקופה לבקשת ביה"ח החדשה תהיה ללא קישור לריסורסים נוספים (ללא Coverage או DocumentReference), ובאלמנט של CoverageEligibilityResponse.disposition יהיה תיאור מילולי שייצג את ביצוע הביטול.

* שימו לב - במצב של מענה לביטול שהסתיים בהצלחה, CoverageEligibilityResponse.status יהיה "active" ולא "cancelled", וכן CoverageEligibilityResponse.outcome יהיה “complete” (המענה אינו מבוטל, אלא מגיב להודעת ביטול).

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

ישנם שני מזהים אשר גם ה- Client וגם ה- Server צריכים לשמור:

1. המזהה העסקי של הבקשה: CoverageEligibilityRequest.identifier הסיבה לכך: נדרש למצב של עדכון או ביטול, במקרה כזה תישלח בקשה להתחייבות חדשה עם reference למזהה העסקי של הבקשה אותה מעוניינים להחליף/לבטל.

2. המזהה הלוגי של המענה: CoverageEligibilityResponse.id הסיבה לכך: נדרש למצב של דגימת מענה מביה"ח לקופה, כאשר התקבל מענה שאינו סופי (בהמתנה, אישור ללא מספר ההתחייבות).