פתרון בעיות

מידע ולמידה על שלבים לפתרון בעיות שבהן אתם עשויים להיתקל במהלך השימוש ב-Cloud Healthcare API.

לא ניתן להפעיל את Cloud Healthcare API

כשמפעילים את Cloud Healthcare API בפעם הראשונה בפרויקט ב-Google Cloud , יכול להיות שתופיע הודעת שגיאה שאין לכם הרשאה להפעיל ממשקי API של Google Cloudבפרויקט.

במאמר הפעלה והשבתה של ממשקי API מוסבר איך מפעילים ממשקי API של Google Cloud , כולל Cloud Healthcare API.

לא ניתן לבצע אימות ל-Cloud Healthcare API

כששולחים קריאה ל-Cloud Healthcare API, יכול להיות שתופיע הודעת שגיאה שלפיה "Application Default Credentials" לא זמינים.

במאמר אימות ב-API מוסבר איך להגדיר את Application Default Credentials או איך להעביר פרטי כניסה לאימות באופן ידני לאפליקציה או לפקודה.

חסר חשבון שירות של Cloud Healthcare API או תפקיד של סוכן שירות Healthcare

חשבון השירות Cloud Healthcare Service Agent נוצר באופן אוטומטי כשיוצרים את מערך הנתונים הראשון. זהו חשבון שירות שמנוהל על ידי Google. אי אפשר למחוק את חשבון השירות לגמרי, אבל בנסיבות מסוימות הוא לא יופיע בדף ניהול הזהויות והרשאות הגישה (IAM), ויכול להיות שתיתקלו בבעיות ב-Cloud Healthcare API.

כדי ש-Cloud Healthcare API יפעל כמו שצריך ויבצע משימות כמו פרסום וקבלת הודעות מ-Pub/Sub או כתיבת מדדים ב-Cloud Logging, צריך שיהיה קיים חשבון שירות של סוכן השירות של Cloud Healthcare עם תפקיד IAM של סוכן השירות של Healthcare.

אתם יכולים ליצור ידנית את חשבון השירות Cloud Healthcare Service Agent או להקצות לו את תפקיד ה-IAM‏ Healthcare Service Agent אם נתקלתם באחת מהבעיות הבאות:

  • חשבון השירות Cloud Healthcare Service Agent לא מופיע בדף "ניהול זהויות והרשאות גישה".
  • אתם יכולים למצוא את חשבון השירות Cloud Healthcare Service Agent, אבל הוא לא מכיל את התפקיד Healthcare Service Agent.

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

משתמשים ב-Google Cloud CLI כדי להוסיף את התפקיד healthcare.serviceAgent לחשבון השירות Cloud Healthcare Service Agent באמצעות המזהה של חשבון השירות, בפורמט service-PROJECT_NUMBER@gcp-sa-healthcare.. כדי למצוא את PROJECT_ID ו-PROJECT_NUMBER, קראו את המאמר זיהוי פרויקטים.

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-healthcare. \
    --role=roles/healthcare.serviceAgent

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

Updated IAM policy for project [PROJECT_ID].
bindings:
...
- members:
  - serviceAccount:service-PROJECT_NUMBER@gcp-sa-healthcare.
  role: roles/healthcare.serviceAgent
...
etag: VALUE
version: VALUE

חוזרים לדף "ניהול זהויות והרשאות גישה" ומוודאים את הפרטים הבאים:

  • בעמודה Member מופיע מזהה של חשבון שירות בפורמט service-PROJECT_NUMBER@gcp-sa-healthcare.iam.gserviceaccount.
  • באותה שורה של העמודה Member, העמודה Name מכילה את הערך Cloud Healthcare Service Agent.
  • באותה שורה של העמודה Member, בעמודה Role מופיע Healthcare Service Agent.

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

כשמפעילים חבילת טרנזקציות של FHIR, יכול להיות שתופיע הודעת השגיאה "aborted due to cumulative heavy load for executing transactional bundle".

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

כדי למנוע את הבעיה, אתם יכולים לנסות אחד מהפתרונות הבאים:

  • אם אתם לא צריכים סמנטיקה של טרנזקציות, השתמשו בחבילות של אצווה. חבילות של פעולות באצווה מונעות את הבעיה הזו לחלוטין כי הן לא אטומיות. עם זאת, הפעולה הזו מפחיתה את האכיפה של שלמות ההפניות.
  • אם אתם יכולים לזהות איזה משאב מתעדכן במקביל, בדקו אם אפשר להוציא את העדכונים האלה או להימנע מהם. ב-FHIR, זה קורה אם יוצרים משאב חדש כמו Observation, וגם מעדכנים את ה-Patient המשויך (או Organization, ‏ Location, ‏ Device וכו') שכבר קיים ולא משתנה.
  • הגבלת קצב בצד הלקוח: אם לוקח הרבה זמן להריץ את חבילות הטרנזקציות, צריך להפחית את קצב ההטמעה לפני שנגמר הזמן הקצוב לתפוגה של הבקשות.