אוטומציה של בדיקת ניצול של תביעות ביטוח בריאות באמצעות AI גנרטיבי

Last reviewed 2024-08-19 UTC

במסמך הזה מתוארת ארכיטקטורת הפניה לחברות ביטוח בריאות שרוצות להפוך לאוטומטיות את תהליכי הטיפול בבקשות לאישור מראש (PA) ולשפר את תהליכי בדיקת הניצול (UR) שלהן באמצעות Google Cloud. הוא מיועד למפתחי תוכנה ולאדמינים של תוכניות בארגונים האלה. הארכיטקטורה הזו עוזרת לספקי תוכניות בריאות לצמצם את העלויות האדמיניסטרטיביות, לשפר את היעילות ולשפר את תהליך קבלת ההחלטות באמצעות אוטומציה של הטמעת נתונים ושל חילוץ תובנות מטפסים קליניים. היא גם מאפשרת להם להשתמש במודלים של AI כדי ליצור הנחיות ולקבל המלצות.

ארכיטקטורה

בתרשים הבא מתוארת ארכיטקטורה וגישה לאוטומציה של תהליך העבודה של הכנסת נתונים ולאופטימיזציה של תהליך הבדיקה של ניהול השימוש (UM). הגישה הזו מבוססת על שירותי נתונים ו-AI ב- Google Cloud.

סקירה כללית של תהליך הטמעת הנתונים ותהליך הבדיקה של UM.

הארכיטקטורה שלמעלה מכילה שני זרימות של נתונים, שנתמכות על ידי מערכות המשנה הבאות:

  • ‫Claims data activator (CDA), שחולץ נתונים ממקורות לא מובנים, כמו טפסים ומסמכים, ומזין אותם למסד נתונים בפורמט מובנה שניתן לקריאה על ידי מכונה. ב-CDA מיושם תהליך של הטמעת נתונים כדי להטמיע טפסים של בקשות לגישה לנתונים.
  • שירות לבדיקת ניצול (UR), שמשלב נתונים של בקשות PA, מסמכי מדיניות והנחיות אחרות לטיפול כדי ליצור המלצות. שירות ה-UR מיישם את זרימת הנתונים כדי לבדוק בקשות PA באמצעות AI גנרטיבי.

בקטעים הבאים מתוארים זרימות הנתונים האלה.

זרימת הנתונים ב-CDA

בתרשים הבא מוצגת זרימת הנתונים בתהליך של שימוש ב-CDA כדי להזין טפסים של בקשות PA.

זרימת הנתונים של מנהלי תיקים ב-PA.

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

  1. מנהלי הטיפול בבקשות לאישור מראש מקבלים את טופסי הבקשה לאישור מראש (pa_forms) מספק שירותים רפואיים ומעלים אותם לקטגוריה של Cloud Storage‏ pa_forms_bkt.
  2. שירות ingestion_service מאזין לשינויים בדלי pa_forms_bkt. שירות ingestion_service אוסף טפסים pa_formsממאגר pa_forms_bkt. השירות מזהה את מעבדי Document AI שהוגדרו מראש, שנקראים form_processors. מעבדי המידע האלה מוגדרים לעיבוד הטפסים pa_forms. ingestion_service השירות מחלץ מידע מהטפסים באמצעות המעבדים.form_processors הנתונים שחולצו מהטפסים הם בפורמט JSON.
  3. שירות ingestion_service כותב את המידע שחולץ עם ציוני מהימנות ברמת השדה לאוסף מסד הנתונים של Firestore, שנקרא pa_form_collection.
  4. אפליקציית hitl_app שולפת את המידע (JSON) עם ציוני מהימנות ממסד הנתונים של pa_form_collection. האפליקציה מחשבת את ציון המהימנות ברמת המסמך מתוך ציוני המהימנות ברמת השדה שזמינים בפלט של מודלים ללמידת מכונה (ML) של form_processors.
  5. אפליקציית hitl_app מציגה את המידע שחולץ עם ציוני רמת סמך ברמת השדה והמסמך למנהלי ניהול בקשות התמיכה של PA, כדי שהם יוכלו לבדוק ולתקן את המידע אם הערכים שחולצו לא מדויקים. מנהלי תיקים של PA יכולים לעדכן את הערכים השגויים ולשמור את המסמך במסד הנתונים pa_form_collection.

זרימת הנתונים בשירות UR

התרשים הבא מציג את זרימת הנתונים בשירות UR.

זרימת הנתונים של מומחה ל-UR.

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

רצף האירועים הוא כזה:

  1. אפליקציית ur_app מציגה למומחי UR רשימה של בקשות PA וסטטוס הבדיקה שלהן. הסטטוס שמוצג הוא in_queue,‏ in_progress או completed.
  2. הרשימה נוצרת על ידי אחזור הנתונים של pa_form information ממסד הנתונים pa_form_collection. מומחה ה-UR פותח בקשה בלחיצה על פריט מהרשימה שמוצגת באפליקציית ur_app.

  3. אפליקציית ur_app שולחת את נתוני pa_form information למודל prompt_model. הוא משתמש ב-Gemini API של Agent Platform כדי ליצור פרומפט שדומה להנחיה הבאה:

    Review a PA request for {medication|device|medical service} for our member, {Patient Name}, who is {age} old, {gender} with {medical condition}. The patient is on {current medication|treatment list}, has {symptoms}, and has been diagnosed with {diagnosis}.

  4. ההנחיה שנוצרה מוצגת בבקשה למומחי UR לבדיקה ולמשוב.ur_app מומחים ל-UR יכולים לעדכן את ההנחיה בממשק המשתמש ולשלוח אותה לאפליקציה.

  5. אפליקציית ur_app שולחת את ההנחיה למודל ur_model עם בקשה ליצור המלצה. המודל יוצר תשובה וחוזר לאפליקציה. האפליקציה מציגה את התוצאה המומלצת למומחים של UR.

  6. המומחים ל-UR יכולים להשתמש באפליקציה ur_search_app כדי לחפש את clinical documents, care guidelines ו-plan policy documents. האפליקציות clinical documents, care guidelines וגם plan policy documents עוברות אינדוקס מראש וזמינות לאפליקציית ur_search_app.

רכיבים

הארכיטקטורה כוללת את הרכיבים הבאים:

  • קטגוריות של Cloud Storage. שירותי האפליקציות של UM דורשים את הקטגוריות הבאות של Cloud Storage בפרויקט Google Cloud :

    • ‫pa_forms_bkt: קטגוריה להעלאת טפסים של הרשאות גישה שצריכים אישור.
    • ‫training_forms: קטגוריה לאחסון טפסים היסטוריים של PA לצורך אימון מעבדי הטפסים של DocAI.
    • ‫eval_forms: באקט להחזקת טפסים של PA לצורך הערכת הדיוק של מעבדי הטפסים של DocAI.
    • ‫tuning_dataset: מאגר (bucket) לאחסון הנתונים שנדרשים לכוונון של מודל שפה גדול (LLM).
    • ‫eval_dataset: קטגוריה לאחסון הנתונים שנדרשים להערכת ה-LLM.
    • ‫clinical_docs: באקט לאחסון המסמכים הקליניים שהספקים שולחים כקבצים מצורפים לטופסי אישור מראש או לאחר מכן לתמיכה בבקשה לאישור מראש. המסמכים האלה מאונדקסים על ידי אפליקציית החיפוש בשירות חיפוש מבוסס סוכנים.
    • ‫um_policies: קטגוריה להכללת מסמכים בנושא הצורך הרפואי והנחיות לטיפול, מסמכי מדיניות של תוכניות ביטוח בריאות והנחיות לכיסוי. המסמכים האלה נוספים לאינדקס על ידי אפליקציית החיפוש בשירות חיפוש מבוסס סוכנים.

  • ‫form_processors: המעבדים האלה אומנו לחילוץ מידע מטפסים של pa_forms.

  • ‫pa_form_collection: מאגר נתונים של Firestore לאחסון המידע שחולץ כמסמכי JSON באוסף מסד הנתונים של NoSQL.

  • ‫ingestion_service: מיקרו-שירות שקורא את המסמכים מהקטגוריה, מעביר אותם לנקודות הקצה של DocAI לצורך ניתוח, ומאחסן את הנתונים שחולצו באוסף של מסד נתונים ב-Firestore.

  • ‫hitl_app: מיקרו-שירות (אפליקציית אינטרנט) שמביא ומציג ערכי נתונים שחולצו מ-pa_forms. בנוסף, הוא מציג את ציון רמת הסמך שדווח על ידי מעבדי הטפסים (מודלים של ML) למנהל התיקים של PA, כדי שהוא יוכל לבדוק, לתקן ולשמור את המידע במאגר הנתונים.

  • ‫ur_app: מיקרו-שירות (אפליקציית אינטרנט) שמומחי UR יכולים להשתמש בו כדי לבדוק את בקשות ה-PA באמצעות AI גנרטיבי. הוא משתמש במודל שנקרא prompt_model כדי ליצור הנחיה. המיקרו-שירות מעביר את הנתונים שחולצו מטפסים של pa_forms למודל prompt_model כדי ליצור הנחיה. ההנחיה שנוצרה מועברת למודל ur_model כדי לקבל המלצה לגבי פנייה.

  • מודלים גדולים של שפה (LLM) שעברו התאמה רפואית ב-Agent Platform: ב-Agent Platform יש מגוון של מודלים בסיסיים של AI גנרטיבי שאפשר להתאים כדי להפחית את העלות ואת זמן האחזור. אלה המודלים שבהם נעשה שימוש בארכיטקטורה הזו:

    • ‫prompt_model: מתאם ב-LLM שמכוונן ליצירת הנחיות על סמך הנתונים שחולצו מ-pa_forms.
    • ‫ur_model: מתאם ב-LLM שמכוון ליצירת טיוטה של המלצה על סמך הנחיית הקלט.

  • ‫ur_search_app: אפליקציית חיפוש שמבוססת על Agent Search ומיועדת למומחי UR כדי למצוא מידע רלוונטי ומותאם אישית במסמכים קליניים, במדיניות UM ובקווים מנחים לגבי כיסוי.

המוצרים שהשתמשו בהם

הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud

  • ‫Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת לכם ליצור סוכני AI ברמה ארגונית, להרחיב את השימוש בהם, לנהל אותם ולבצע אופטימיזציה שלהם.
  • ‫ Agent Search: פלטפורמה שמאפשרת ליצור ולפרוס סוכנים ויישומים מבוססי-AI ברמה ארגונית.
  • ‫ Document AI: פלטפורמה לעיבוד מסמכים שמקבלת נתונים לא מובְנים ממסמכים והופכת אותם לנתונים מובְנים.
  • ‫ Firestore: מסד נתונים מסוג NoSQL לאחסון מסמכים שמיועד להתאמה לעומס (automatic scaling), לביצועים גבוהים ולפיתוח אפליקציות בקלות.
  • ‫ Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ להם, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ‫ Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.
  • ‫ Cloud Monitoring: שירות שמאפשר לראות את הביצועים, הזמינות והתקינות של האפליקציות והתשתית שלכם.

תרחיש שימוש

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

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

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

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

שיקולים בתכנון

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

אבטחה, פרטיות ותאימות

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

בארצות הברית, חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA, כולל התיקונים, לרבות Health Information Technology for Economic and Clinical Health Act – חוק HITECH) מחייב עמידה בדרישות של כלל האבטחה, כלל הפרטיות וכלל הודעת הפרצה של HIPAA. Google Cloud תומך בתאימות ל-HIPAA, אבל בסופו של דבר, אתם אחראים להערכת התאימות שלכם ל-HIPAA. האחריות לתאימות ל-HIPAA היא משותפת לכם ול-Google. אם הארגון שלכם כפוף ל-HIPAA ואתם רוצים להשתמש במוצרים כלשהם של Google בקשר למידע רפואי מוגן (PHI), אתם צריכים לעיין בהסכם השותפות העסקית (BAA) של Google ולאשר אותו. Google Cloudהמוצרים של Google שמכוסים בהסכם BAA עומדים בדרישות של HIPAA ותואמים לאישורי ISO/IEC 27001,‏ 27017 ו-27018 ולדוח SOC 2 שלנו.

לא כל מודלי ה-LLM שמתארחים ב-Model Garden תומכים ב-HIPAA. להעריך את מודלי ה-LLM שתומכים ב-HIPAA ולהשתמש בהם.

כדי להעריך איך מוצרי Google יכולים לעזור לכם לעמוד בדרישות התאימות ל-HIPAA, תוכלו לעיין בדוחות הביקורת של צד שלישי במרכז המשאבים בנושא תאימות.

מומלץ ללקוחות לשקול את הנקודות הבאות כשבוחרים תרחישי שימוש ב-AI, ולתכנן את השימוש בהתאם:

המוצרים של Google פועלים בהתאם לעקרונות של AI אחראי.

עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security (נקודת מבט על AI ו-ML: אבטחה) ב-Well-Architected Framework.

אמינות

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

‫Document AI form_processors הוא שירות אזורי. הנתונים מאוחסנים באופן סינכרוני בכמה אזורים בתוך אזור מסוים. תעבורת הנתונים מאוזנת אוטומטית בין האזורים. אם מתרחש הפסקת חשמל באזור, הנתונים לא אובדים1. אם מתרחש שיבוש באזור מסוים, השירות לא זמין עד ש-Google פותרת את השיבוש.

אפשר ליצור קטגוריות של Cloud Storage באחד משלושת המיקומים הבאים: אזורי, אזורי כפול או רב-אזורי, באמצעות קטגוריות pa_forms_bkt,‏ training_forms,‏ eval_forms,‏ tuning_dataset,‏ eval_dataset,‏ clinical_docs או um_policies. נתונים שמאוחסנים בדליים אזוריים משוכפלים באופן סינכרוני בכמה אזורים בתוך אזור. כדי להשיג זמינות גבוהה יותר, אפשר להשתמש בקטגוריות בשני אזורים או במספר אזורים, שבהן הנתונים משוכפלים באופן אסינכרוני בין האזורים.

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

השירותים של Cloud Run‏, ingestion_service,hitl_app ו-ur_app, הם שירותים אזוריים. הנתונים מאוחסנים באופן סינכרוני בכמה אזורים בתוך אזור מסוים. התעבורה מאוזנת אוטומטית בין האזורים. אם מתרחש הפסקת חשמל באזור, משימות Cloud Run ממשיכות לפעול והנתונים לא אובדים. אם מתרחש שיבוש באזור, המשימות של Cloud Run מפסיקות לפעול עד ש-Google תפתור את השיבוש. יכול להיות שמשימות או משימות משנה ספציפיות ב-Cloud Run ייכשלו. כדי לטפל בכשלים כאלה, אפשר להשתמש בניסיונות חוזרים של משימות ובשמירת מצב (checkpointing). מידע נוסף זמין במאמר בנושא שיטות מומלצות לניסיונות חוזרים של משימות ולנקודות ביקורת. במאמר טיפים כלליים לפיתוח ב-Cloud Run מפורטות כמה שיטות מומלצות לשימוש ב-Cloud Run.

‫Agent Platform היא פלטפורמה מקיפה וידידותית ללמידת מכונה, שמספקת סביבה מאוחדת למחזור החיים של למידת מכונה, מהכנת הנתונים ועד לפריסת המודל ולמעקב אחריו.

עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.

הוזלת עלויות

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

‫סוגי אחסון ב-Cloud Storage: כדאי להשתמש בסוגי אחסון שונים (Standard,‏ Nearline,‏ Coldline או Archive) בהתאם לתדירות הגישה לנתונים. ‫Nearline,‏ Coldline ו-Archive הם פתרונות חסכוניים יותר לנתונים שניגשים אליהם בתדירות נמוכה יותר.

כללי מדיניות בנושא מחזור החיים של Cloud Storage: הטמעת כללי מדיניות בנושא מחזור החיים כדי להעביר אובייקטים באופן אוטומטי לסוגי אחסון (storage class) בעלות נמוכה יותר או למחוק אותם על סמך הגיל ודפוסי הגישה.

התמחור של Document AI מבוסס על מספר המעבדים שנפרסו ועל מספר הדפים שעובדו על ידי המעבדים של Document AI. כמה נקודות שכדאי לחשוב עליהן:

  • אופטימיזציה של מעבדים: ניתוח של דפוסי עומס עבודה כדי לקבוע את המספר האופטימלי של מעבדי Document AI לפריסה. אל תקצו יותר מדי משאבים.
  • ניהול נפח הדפים: עיבוד מראש של מסמכים כדי להסיר דפים מיותרים או לבצע אופטימיזציה של הרזולוציה יכול לעזור להפחית את עלויות העיבוד.

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

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

החיובים ב-Cloud Run מחושבים על סמך השימוש במעבד (CPU) על פי דרישה, הזיכרון ומספר הבקשות. כדאי לחשוב היטב על הקצאת המשאבים. הקצאת משאבי מעבד (CPU) וזיכרון על סמך מאפייני עומס העבודה. כדאי להשתמש בהתאמה אוטומטית לעומס כדי להתאים את המשאבים באופן דינמי לפי הביקוש.

Agent Platform בדרך כלל, על מודלים של שפה גדולה (LLM) נגבה תשלום על סמך הקלט והפלט של הטקסט או המדיה. מספר הטוקנים של הקלט והפלט משפיע ישירות על העלויות של מודל שפה גדול (LLM). אופטימיזציה של ההנחיות ושל תהליך יצירת התשובות כדי לשפר את היעילות.

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

  • ‫Search Standard Edition, שמציע יכולות חיפוש לא מובנות.
  • מהדורת Search Enterprise, שמציעה יכולות חיפוש לא מובנה וחיפוש באתר.
  • תוסף LLM לחיפוש, שמציע סיכום ויכולות חיפוש רב-שלביות.

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

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

התייחסות מדוקדקת לגורמים האלה ויישום האסטרטגיות המומלצות יכולים לעזור לכם לנהל ולשפר את העלות של הפעלת ארכיטקטורת האוטומציה של PA ו-UR ב- Google Cloud.

עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.

פריסה

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

קוד ההתחלה של ארכיטקטורת ההפניה הזו זמין במאגרי ה-Git הבאים:

  • מאגר ה-Git של CDA: המאגר הזה מכיל סקריפטים לפריסת Terraform להקצאת משאבים בתשתית ולפריסה של קוד האפליקציה.
  • מאגר Git של שירות UR: במאגר הזה יש דוגמאות קוד לשירות UR.

אפשר לבחור באחת משתי האפשרויות הבאות להטמעה של תמיכה ושירותים לארכיטקטורת ההפניה הזו:

המאמרים הבאים

שותפים ביצירת התוכן

Author: Dharmesh Patel | Industry Solutions Architect, Healthcare

תורמי תוכן אחרים:

  1. מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.  ↩