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

תרשים

להלן תרשים של ה- flow, בהתייחס לאינטראקציות, לפרופילים ולמשאבים, בחלוקה של Client/Server

הסבר נלווה לתרשים

התרשים מתייחס להעברת מידע של הפניות ותוצאות בדיקות מעבדה בין בי"ח לקהילה. לצורך הבנת התרשים יש להתייחס ל: - צד שמאל מייצג את ביה"ח, וצד ימין מייצג את הקהילה. בכל אחד מהם ישנה חלוקה ל- Client/Server

- מלבנים כתומים – מציינים את האינטראקציה: מתודה, סוג המשאב ושם הפרופיל.

- מלבנים לבנים – תהליך פנימי, מידע חוזר בתגובה לשאילתה.

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

- מיספור השלבים נועד להתייחסות נוחה בהסברים עבור כל שלב.

שלבי התהליך:

1. GET Patient – ביה"ח מתשאל את הקהילה, לקבלת פרטי המטופל.
2. אם המטופל קיים בשרת של הקהילה, יוחזר Bundle מסוג searchset עם משאב המטופל
3. אם המטופל לא נמצא בשרת של הקהילה, יוחזר Bundle מסוג searchset ריק (ללא entry, ועם total=0).
4. POST ServiceRequest - ביה"ח שולח לקהילה את פרטי ההפניה, כל הפניה בנפרד. ההפניות נוצרות בפועל בשרת הקהילה רק לאחר מימוש המתודה עבור ההפניה המאגדת, כפי שמתואר בסעיף הבא.

5. POST ServiceRequest - בסיום שליחת ההפניות לבדיקות מעבדה, ביה"ח שולח הפניה מאגדת, עם references לכל ההפניות שנשלחו עד כה. זהו הטריגר ליצירת ההפניות האטומיות/סוללות וליצירת ההפניה המאגדת בשרת הקהילה.

   • המתודות של סעיפים 4 ו-5 אמנם זהות, אבל לכל אחת מהן מוגדר פרופיל ייעודי, והן מתקיימות על פי סדר כרונולוגי. תחילה נשלחות כל ההפניות האטומיות/סוללה, ורק בסיומן נשלחת ההפניה המאגדת (בניגוד לסעיף 8, למשל, בו אין תלות בסדר הכרונולוגי של השליחה).
6. POST DiagnosticReport – לאחר שהתקבלה ההפניה המאגדת, הקהילה שולחת לביה"ח פקודה ליצירת דוח מסכם, כאשר הסטאטוס שלו מוגדר כ- registered (זאת בהנחה שהתהליך התבצע באופן תקין. לפרטים נוספים אודות סטאטוסים- ר' פרק “Status”). הדוח המסכם, בשלב זה, אינו כולל עדיין תוצאות. שליחת הדוח כ- registered הוגדרה משתי סיבות: (1) זהו אישור לביה"ח שהטיפול בהפניה החל. (2) באופן זה מועבר המזהה של הדוח, אשר ישמש לצורך מעקב אחר סטאטוס התוצאות.
7. POST Observation – שליחת התוצאות של בדיקות המעבדה מהקהילה לביה"ח. שלב זה כולל גם את התוצאות האטומיות וגם את תוצאות הסוללה, מכיוון שאין סדר כרונולוגי ביניהן. כל התוצאות ומשאבי הסוללות נשלחים ללא הפרדה או סדר מחייב.
8. PUT Observation – במידת הצורך, ניתן לעדכן תוצאות קיימות. מומלץ לבצע את העדכון בעזרת conditional update, ובכך לבצע עדכון על פי מזהה עסקי, ולא לפי המזהה הלוגי. רלוונטי גם לתוצאות האטומיות וגם לסוללת התוצאות.
9. PUT/POST ServiceRequest – לצורך שלמות הנתונים בשרת ביה"ח, ובכדי לאפשר לביה"ח ליצור דוח מסכם מלא עם references מקומיים להפניה המאגדת ולכל ההפניות האטומיות, הקהילה שולחת פקודת יצירה עבור כל הפניה מהתהליך. POST – ליצירת ההפניה. PUT – לעדכון ההפניה. מומלץ לבצע את העדכון בעזרת conditional update, ובכך לבצע עדכון על פי מזהה עסקי, ולא לפי המזהה הלוגי.
10. PUT DiagnosticReport – עדכון הדוח המסכם עם כל התוכן הרלוונטי (קישורים לתוצאות, קישורים להפניות, מסמך PDF). גם פה מומלץ להשתמש ב- conditional update מאותן הסיבות שתוארו בסעיפים הקודמים.

טבלת סטאטוסים

האלמנט status הינו אלמנט עם קארדינליות מסוג 1..1, כלומר שהוא מוגדר כחובה בשלושת המשאבים בתהליך זה (ServiceRequest, Observation, DiagnosticReport). ישנה חשיבות גבוהה להתייחסות לסוגי הסטאטוסים השונים לאורך התהליך.

להלן טבלה מרכזת עבור כל הסטאטוסים המעורבים בתהליך בחלוקה ל- Resources הרלוונטיים:

Resource	Profile	Status	Used for
ServiceRequest	lrc-referral	active	רק משאבים בסטאטוס זה יטופלו על ידי הקהילה
	lrc-referral-group	active
Observation	lrc-result	final	ערך ברירת המחדל של התוצאה הבודדת
		entered-in-error	עבור תוצאה לא תקינה, למשל בעקבות תקלה טכנית
		cancelled	עבור ביטול תוצאה שכבר שודרה
	lrc-panel-result	final	עבור מאגד או סוללה לאחר קבלת כל התוצאות
		preliminary	עבור מאגד או סוללה עם תוצאות חלקיות.
DiagnosticReport	lrc-panel-report	registered	סטאטוס בעת יצירת הדוח המסכם
		cancelled	במקרים של כשל בעיבוד (ביטול הטיפול בהפנייה)
		partial	במקרים בהם הדוח המסכם עדיין לא הושלם
		final	כאשר מתקבלות כל התוצאות במלואן
		amended	כאשר נוספו בדיקות אשר לא נכללו בהפניה המאגדת

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