אפשרויות ייבוא של FHIR

בדף הזה מוסברות האפשרויות לאחסון של קבוצות גדולות של נתוני FHIR ב-Cloud Healthcare API.

ייבוא משאבי FHIR

משתמשים ב-method‏ fhirStores.import כדי לטעון משאבי FHIR מ-Cloud Storage אל Cloud Healthcare API. השיטה פועלת בצורה הכי טובה כשמעלים נתונים למאגר FHIR ריק בלי הפרעות מאפליקציות אחרות.

הוראות להפעלת fhirStores.import מופיעות במאמר ייבוא וייצוא של משאבי FHIR באמצעות Cloud Storage.

כדאי להביא בחשבון את המאפיינים הבאים של השיטה fhirStores.import כשמחליטים אם להשתמש בה. אם fhirStores.import לא מתאים לאפליקציה שלכם, כדאי להשתמש בשיטה fhir.executeBundle לטעינת נתונים. מידע על אופן ההתקשרות אל fhir.executeBundle זמין במאמר ניהול משאבי FHIR באמצעות חבילות FHIR.

  • בשיטה fhirStores.import אפשר להעלות חבילות גדולות יותר מהמגבלה של 50MB ב-fhir.executeBundle. עם זאת, הגודל של כל משאב בנפרד בחבילה מוגבל ל-10MB.

  • השימוש ב-fhirStores.import מסיר את המורכבויות של הפעלת חבילות FHIR גדולות, כמו:

    • פיצול חבילות FHIR לחבילות קטנות יותר
    • ניהול של כמה לוחות זמנים של חבילות
    • ניהול שגיאות זמניות שאפשר לנסות שוב ברמת המשאב או החבילה

    לרוב, היתרונות האלה עולים על היתרונות של שימוש בחבילות.

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

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

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

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

  • המונים של תוצאות הפעולה לא סופרים מזהים כפולים כשגיאה. כל משאב בקלט נספר כהצלחה אחת. כתוצאה מכך, יכול להיות שמספר ההצלחות יהיה גדול ממספר המשאבים במאגר FHIR. המצב הזה קורה בדרך כלל כשמייבאים נתונים שמסודרים בחבילות שנוצרו על ידי Patient-everything, כשכל חבילה מכילה עותק משלה של משאב, כמו Practitioner, שאולי מפנים אליו הרבה משאבי מטופלים.

  • אם ייבוא של חלק מהמשאבים נכשל, למשל בגלל שגיאות בניתוח, המשאבים שיובאו בהצלחה לא יבוטלו. לדוגמה, אם 5 מתוך 100 משאבים לא מיובאים, 95 המשאבים הנותרים מיובאים למאגר FHIR.

  • כשמשתמשים בפורמט BUNDLE, שיטת הייבוא דוחה חבילות עם Bundle.type של history. שיטת הייבוא לא חלה על סמנטיקת העיבוד של חבילות או חבילות של עסקאות. בניגוד ל-fhir.executeBundle, חבילות של עסקאות לא מבוצעות כעסקה אחת, והפניות פנימיות בחבילה לא נכתבות מחדש. החבילה נחשבת לאוסף של משאבים שייכתבו כמו שהם, כפי שצוין ב-Bundle.entry.resource, תוך התעלמות מ-Bundle.entry.request. לדוגמה, אפשר לייבא חבילות של searchset שנוצרו על ידי חיפוש FHIR או פעולת Patient-everything.

שימוש בחבילות FHIR

סקירה כללית של חבילות FHIR זמינה במאמר חבילות FHIR.

מתי כדאי להשתמש בחבילות FHIR

כשמחליטים אם להשתמש בשיטה fhir.executeBundle כדי לאחסן משאבי FHIR, כדאי להביא בחשבון את המאפיינים והיתרונות הבאים שלה:

  • אם בניית צינור עיבוד נתונים שמאחסן נתונים ב-Cloud Storage ואז מייבא את הנתונים באמצעות fhirStores.import יקרה מדי, מבחינת עלויות החיוב או רוחב הפס ברשת, כדאי להשתמש ב-fhir.executeBundle.
  • כשמבצעים חבילות, אפשר לאכוף את שלמות העסקה.
  • כשמבצעים חבילות, אפשר לאכוף אימות של פרופיל FHIR.
  • אם אתם צריכים לשלוח התראות Pub/Sub כשמתרחשות פעולות יצירה, עדכון או מחיקה של FHIR, אתם יכולים להשתמש ב-fhir.executeBundle. ההתראות ב-Pub/Sub לא נשלחות כשמייבאים משאבי FHIR באמצעות fhirStores.import.
  • אם הזמן שבו צריך לעבד משאב FHIR מסוים הוא בשניות או בדקות, משתמשים ב-fhir.executeBundle. אם הזמן שבו צריך לעבד משאב FHIR מסוים הוא בשעות או בימים, משתמשים בפונקציה fhirStores.import.
  • אם בפרויקט Google Cloud שלכם יש הרבה פעולות ארוכות טווח (LRO) קיימות שמבצעות משימות אחרות, יכול להיות שתקבלו ביצועים טובים יותר עם fhir.executeBundle מאשר עם fhirStores.import.

  • אם לאפליקציה שמנהלת את פעולת fhirStores.import אין אסטרטגיה טובה לטיפול במקרים הבאים, כדאי להשתמש ב-fhir.executeBundle:

    • טיפול בשגיאות בכמות גדולה
    • טיפול בכשלים בקבוצת משנה של משאבי FHIR או בקבוצות שלמות

מתי לא כדאי להשתמש בחבילות FHIR

כשקובעים אם להשתמש ב-fhir.executeBundle לאחסון משאבי FHIR, כדאי להביא בחשבון את המגבלות הבאות של fhir.executeBundle:

  • לפעולות בחבילה מוקצה מכסת שימוש שוות ערך, והן מחויבות כאילו בוצעו מחוץ לחבילה. לדוגמה, אם בחבילה יש 10 פעולות POST, 5 פעולות GET ופעולה אחת DELETE, המכסה והחיוב שחלים על החבילה זהים לאלה שחלים על הפעולות האלה אם הן מבוצעות בנפרד.

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

  • יותר סביר שיהיו התנגשויות בטרנזקציות בחבילות גדולות של טרנזקציות, מה שמוביל למאבק על הנתונים ולפעולות שנכשלות. מידע על הסיבות האפשריות לבעיות האלה ועל פתרונות אפשריים מופיע במאמר מניעת שגיאות 429 Resource Exhausted operation_too_costly.

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

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