將生成式 AI 用於利用率管理

Last reviewed 2024-08-19 UTC

本文件說明醫療保險公司的參考架構，這些公司希望使用 Google Cloud自動處理事前授權 (PA) 要求，並改善使用率審查 (UR) 程序。適用於這些機構的軟體開發人員和計畫管理員。這項架構可協助健康保險公司減少行政管理費用、提高效率，並自動擷取臨床表單的深入分析，進而做出更明智的決策。還能使用 AI 模型生成提示和建議。

架構

下圖說明自動化資料擷取工作流程的架構和方法，以及如何最佳化使用量管理 (UM) 審查程序。這個方法會使用 Google Cloud中的資料和 AI 服務。

資料擷取和 UM 審查程序概要總覽。

上述架構包含兩個資料流，由下列子系統支援：

  • 理賠資料啟動器 (CDA)：從非結構化來源 (例如表單和文件) 擷取資料，並以結構化、機器可讀取的格式匯入資料庫。CDA 會實作資料流程，以擷取 PA 要求表單。
  • 使用情況審查服務 (UR 服務)：整合 PA 要求資料、政策文件和其他照護指南，產生建議。UR 服務會實作資料流程，以使用生成式 AI 審查 PA 要求。

以下各節將說明這些資料流程。

CDA 資料流程

下圖顯示使用 CDA 擷取 PA 要求表單的資料流程。

PA 案件管理員的資料流程。

如上圖所示，PA 案件管理員會與系統元件互動，擷取、驗證及處理 PA 要求。PA 案件管理員是業務營運團隊的成員，負責接收 PA 要求。事件流程如下：

  1. PA 案件管理員會收到醫療服務提供者傳送的 PA 要求表單 (pa_forms)，並上傳至 pa_forms_bkt Cloud Storage bucket。
  2. ingestion_service 服務會監聽 pa_forms_bkt bucket 的變更。ingestion_service 服務會從 pa_forms_bkt 值區擷取 pa_forms表單。這項服務會識別預先設定的 Document AI 處理器，也就是 form_processors。這些處理器定義為處理 pa_forms 表單。這項ingestion_service 服務會使用form_processors 處理器從表單中擷取資訊。從表單擷取的資料為 JSON 格式。
  3. ingestion_service 服務會將擷取的資訊和欄位層級的信賴分數寫入 Firestore 資料庫集合 (稱為 pa_form_collection)。
  4. hitl_app 應用程式會從 pa_form_collection 資料庫擷取資訊 (JSON)，並取得信賴分數。應用程式會根據form_processors機器學習 (ML) 模型在輸出內容中提供的欄位層級信賴分數，計算文件層級信賴分數。
  5. hitl_app 應用程式會向 PA 案件管理員顯示擷取的資訊，以及欄位和文件層級的信賴分數，方便他們審查並修正資訊 (如果擷取的值不正確)。PA 案件管理員可以更新不正確的值，並將文件儲存至 pa_form_collection 資料庫。

UR 服務資料流程

下圖顯示 UR 服務的資料流程。

UR 專家的資料流程。

如上圖所示，UR 專員會與系統元件互動，對 PA 要求進行臨床審查。UR 專員通常是護士或醫師，在特定臨床領域有豐富經驗，並受聘於醫療保險公司。本節所述工作流程不包含 PA 要求案件管理和轉送工作流程。

事件流程如下：

  1. ur_app應用程式會向 UR 專員顯示 PA 要求清單和審查狀態。狀態會顯示為 in_queue、in_progress 或 completed。
  2. 這份清單是從 pa_form_collection 資料庫擷取 pa_form information 資料所建立。使用者研究專員會開啟要求，方法是點選 ur_app 應用程式中顯示的清單項目。

  3. ur_app 應用程式會將 pa_form information 資料提交給 prompt_model 模型。這項功能會使用 Vertex AI Gemini API 生成提示，類似於下列提示：

    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_app 應用程式會向 UR 專家顯示生成的提示，供他們審查及提供意見回饋。UR 專家可以在 UI 中更新提示，然後傳送至應用程式。

  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 bucket。UM 應用程式服務需要您 Google Cloud 專案中的下列 Cloud Storage 值區：

    • pa_forms_bkt：用來擷取需要核准的 PA 表單。
    • training_forms：用來保存歷來 PA 表單的值區，可訓練 DocAI 表單處理器。
    • eval_forms：這個值是儲存 PA 表單的 bucket，用於評估 DocAI 表單處理器的準確度。
    • tuning_dataset：用來存放微調大型語言模型 (LLM) 所需資料的值區。
    • eval_dataset：用於保存評估 LLM 所需資料的 bucket。
    • clinical_docs：這個資料夾會存放醫療服務提供者提交的臨床文件，這些文件會以附件形式隨預先授權表單一併送出，或在之後提交，做為預先授權案件的佐證。這些文件會由 AI 應用程式服務中的搜尋應用程式編入索引。
    • um_policies：用來存放醫療必要性和照護指引、健康計畫政策文件和給付範圍指引的儲存空間。這些文件會由 AI Applications 服務中的搜尋應用程式編入索引。

  • form_processors：這些處理器經過訓練，可從 pa_forms 表單中擷取資訊。

  • pa_form_collection：Firestore 資料儲存區，可將擷取的資訊儲存為 NoSQL 資料庫集合中的 JSON 文件。

  • ingestion_service：這項微服務會從值區讀取文件，將文件傳遞至 DocAI 端點進行剖析，並將擷取的資料儲存在 Firestore 資料庫集合中。

  • hitl_app：微服務 (網頁應用程式)，可擷取並顯示從 pa_forms 擷取的資料值。此外，這項服務也會向 PA 案件管理員顯示表單處理器 (機器學習模型) 回報的信賴度分數，方便管理員檢查、修正及儲存資料存放區中的資訊。

  • ur_app：微服務 (網頁應用程式)，UR 專家可使用這項服務，透過生成式 AI 審查 PA 要求。這個模型會使用名為 prompt_model 的模型生成提示。微服務會將從 pa_forms 表單擷取的資料傳遞至 prompt_model 模型，以生成提示。然後將生成的提示傳送至 ur_model 模型，取得案件的建議。

  • Vertex AI 醫療調整 LLM：Vertex AI 提供各種生成式 AI 基礎模型，可進行調整以降低成本和延遲時間。這個架構使用的模型如下：

    • prompt_model：LLM 上的介面卡，經過調整後可根據從 pa_forms 擷取的資料生成提示。
    • ur_model：LLM 上的轉接程式，經過調整後可根據輸入提示生成建議草稿。

  • ur_search_app：使用 AI 應用程式建構的搜尋應用程式，可從臨床文件、UM 政策和保險範圍指南中，為 UR 專員尋找個人化且相關的資訊。

使用的產品

這項參考架構使用下列 Google Cloud 產品：

  • Vertex AI：機器學習平台，可讓您訓練及部署機器學習模型和 AI 應用程式，並自訂 LLM 用於 AI 輔助的應用程式。
  • AI 應用程式：這個平台可讓開發人員建立及部署企業級 AI 輔助代理和應用程式。
  • Document AI：文件處理平台，可將文件中的非結構化資料轉為結構化資料。
  • Firestore：專為自動調整資源配置、提供高效能及便利開發應用程式所建構的 NoSQL 文件資料庫。
  • Cloud Run：無伺服器運算平台，可讓您在 Google 可擴充的基礎架構上直接執行容器。
  • Cloud Storage：適用於多種資料類型的物件儲存庫，成本低廉且沒有限制。 資料在 Google Cloud 內外都能存取，且會複製到多個位置，以便提供備援機制。 Google Cloud
  • Cloud Logging：即時記錄管理系統，提供儲存、搜尋、分析和快訊功能。
  • Cloud Monitoring：這項服務可讓您掌握應用程式和基礎架構的效能、可用性和健康狀態。

用途

UM 是健康保險公司採用的程序，主要在美國實施，但全球醫療保險市場也採用類似程序 (稍有修改)。UM 的目標是確保病患在適當時間和地點獲得適當照護，並盡可能降低成本。UM 也有助於確保醫療照護有效、效率高，且符合實證照護標準。PA 是 UM 工具，病患必須先獲得保險公司核准，才能接受醫療照護。

許多公司採用的 UM 程序會阻礙及時提供和接受照護。這類做法不僅耗時費力，而且行政程序過於繁瑣。 而且過程複雜、緩慢，需要手動操作。這個程序會大幅影響健康計畫有效管理照護品質的能力，並改善供應商和會員體驗。不過，如果這些公司修改 UM 程序，就能確保病患獲得高品質且具成本效益的治療。健康保險公司可透過加快事前授權要求處理速度，縮短 UR 流程，進而降低成本和拒絕率，同時提升病患和醫護人員體驗。這個方法有助於減輕醫療服務提供者的行政負擔。

當健康計畫收到事前授權要求時，事前授權案件管理員會在案件管理系統中建立案件，以追蹤、管理及處理要求。我們收到大量這類要求，其中附有臨床文件，並透過傳真和郵寄方式送達。不過，健康保險公司無法輕易存取這些表單和文件中的資訊，以進行資料分析和商業智慧。目前將這些文件中的資訊手動輸入案件管理系統的程序效率不彰且耗時，還可能導致錯誤。

健康保險公司可透過自動化資料擷取程序，降低成本、減少資料輸入錯誤，並減輕員工的行政負擔。從臨床表單和文件中擷取有價值的資訊，有助於健康保險公司加快 UR 程序。

設計須知

本節提供指引，協助您運用這個參考架構開發一或多個架構，以滿足安全性、可靠性、作業效率、成本和效能方面的特定需求。

安全性、隱私權和法規遵循

本節說明使用這項參考架構時應考量的因素，有助於設計及建構架構，Google Cloud 以滿足安全性、隱私權和法規遵循需求。

在美國，《健康保險流通與責任法案》(簡稱「HIPAA」) 係指修訂後的版本，包括依據《經濟與臨床健康資訊科技法》(HITECH) 修訂的內容。該法案要求遵守 HIPAA 的安全規則、隱私權規則和資料外洩通知規則。Google Cloud 支援 HIPAA 法規遵循，但您最終仍須自行評估是否符合 HIPAA 規範。遵守《健康保險流通與責任法案》是您與 Google 共同的責任。如果貴機構需要遵守《健康保險流通與責任法案》規定，而且想使用任何 Google Cloud產品處理受保護的健康資訊 (PHI)，則必須詳閱並接受 Google 的《業務合作協議》(BAA)。適用《業務合作協議》的 Google 產品皆遵守《健康保險流通與責任法案》規定，且符合我們的 ISO/IEC 27001、27017 和 27018 認證，以及 SOC 2 報告。

並非所有 Vertex AI Model Garden 中託管的 LLM 都支援 HIPAA。 評估及使用支援《健康保險流通與責任法案》的 LLM。

如要評估 Google 產品如何達成《健康保險流通與責任法案》法規遵循的需求，請參閱法規遵循資源中心的第三方稽核報告。

建議客戶在選取 AI 用途時，考量下列事項，並根據這些考量因素進行設計：

Google 產品遵循負責任的 AI 技術原則。

如要瞭解 AI 和機器學習工作負載專用的安全性原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：安全性」。

可靠性

本節說明您應考量的設計因素，以建構及運作可靠的基礎架構，自動處理 PA 要求。

Document AI form_processors 是地區性服務，資料會同步儲存在區域內的多個可用區。系統會自動在可用區之間進行負載平衡。如果發生區域中斷，資料不會遺失1。如果發生區域性中斷，服務將無法使用，直到 Google 解決中斷問題為止。

您可以使用 pa_forms_bkt、training_forms、eval_forms、tuning_dataset、eval_dataset、clinical_docs 或 um_policies 值區，在下列三種位置中建立 Cloud Storage 值區：區域、雙區域或多區域。儲存在區域值區中的資料，會在區域內的多個可用區之間同步複製。如要提高可用性，可以使用雙區域或多區域值區，資料會以非同步方式在區域間複製。

在 Firestore 中，從 pa_form_collection 資料庫擷取的資訊可以分散在多個資料中心，確保全球擴充性和可靠性。

Cloud Run 服務 ingestion_service、hitl_app 和 ur_app 都是區域服務。資料會同步儲存在區域內的多個可用區。系統會自動在各可用區之間進行負載平衡。如果發生區域中斷，Cloud Run 工作仍會繼續執行，資料也不會遺失。如果發生區域中斷，Cloud Run 工作會停止執行，直到 Google 解決中斷問題為止。個別 Cloud Run 工作或工作可能會失敗。如要處理這類失敗情形，可以使用工作重試和檢查點。詳情請參閱「作業重試和檢查點最佳做法」。Cloud Run 一般開發提示說明使用 Cloud Run 的一些最佳做法。

Vertex AI 是全方位且容易使用的機器學習平台，提供統一的環境，可支援機器學習生命週期，從資料準備到模型部署和監控，都能輕鬆完成。

如要瞭解 AI 和機器學習工作負載的專屬可靠性原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：可靠性」。

成本最佳化

本節提供指引，說明如何最佳化建立及執行架構的成本，以自動處理 PA 要求並改善 UR 程序。妥善管理資源用量並選擇適當的服務層級，可大幅影響整體成本。

Cloud Storage 儲存空間級別： 根據資料存取頻率，使用不同的儲存空間級別 (標準、Nearline、 Coldline 或 Archive)。對於不常存取的資料，Nearline、Coldline 和 Archive 更具成本效益。

Cloud Storage 生命週期政策：實作生命週期政策，根據物件的存取模式和存在時間，自動將物件移至費用較低的儲存空間級別，或刪除物件。

Document AI 的定價取決於部署的處理器數量，以及 Document AI 處理器處理的頁面數量。請考量下列事項：

  • 處理器最佳化：分析工作負載模式，判斷要部署的最佳 Document AI 處理器數量。避免資源過度佈建。
  • 管理頁面數量：預先處理文件，移除不必要的頁面或調整解析度，有助於降低處理成本。

Firestore 的定價依據是與文件、索引項目、資料庫使用的儲存空間，以及網路頻寬量相關的活動。請考量下列事項：

  • 資料模型：設計資料模型，盡量減少索引項目數量，並根據效率最佳化查詢模式。
  • 網路頻寬：監控及最佳化網路用量，避免產生額外費用。考慮快取經常存取的資料。

Cloud Run 費用是根據隨選 CPU 用量、記憶體和要求數量計算。請仔細思考資源分配方式。根據工作負載特性分配 CPU 和記憶體資源。企業可以運用自動調度資源功能，依需求動態調整資源。

Vertex AI LLM 通常會根據文字或媒體的輸入和輸出內容收費。輸入和輸出詞元數量會直接影響 LLM 成本。提高提示和回覆生成效率。

AI 應用程式搜尋引擎的費用取決於您使用的功能。為協助您管理費用，我們提供下列三種選項：

  • 搜尋標準版，提供非結構化搜尋功能。
  • Search Enterprise 版，提供非結構化搜尋和網站搜尋功能。
  • 搜尋 LLM 外掛程式，提供摘要和多輪搜尋功能。

此外，您也可以考慮下列事項，進一步節省費用：

  • 監控和快訊：設定 Cloud Monitoring 和帳單快訊，追蹤費用並在用量超過門檻時接收通知。
  • 費用報表：定期查看控制台中的費用報表，找出趨勢並盡量提高資源用量效益。Google Cloud
  • 考慮承諾使用折扣：如果您有可預測的工作負載，可以考慮承諾在特定期間使用這些資源，以取得折扣價。

仔細考量這些因素並採用建議策略，有助於有效管理及最佳化在 Google Cloud上執行 PA 和 UR 自動化架構的成本。

如要瞭解 AI 和機器學習工作負載專用的成本最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：成本最佳化」。

部署作業

這項架構的參考實作程式碼已開放原始碼授權。這段程式碼實作的架構是原型，可能不包含生產環境部署所需的所有功能和強化措施。如要實作及擴充這項參考架構，以更貼近您的需求，建議您與 Google Cloud 諮詢服務聯絡。

您可以在下列 Git 存放區中找到這個參考架構的範例程式碼：

  • CDA git 存放區： 這個存放區包含 Terraform 部署指令碼，用於佈建基礎架構和部署應用程式程式碼。
  • UR 服務 Git 存放區： 這個存放區包含 UR 服務的程式碼範例。

您可以選擇下列其中一個選項，為這個參考架構導入支援和服務：

後續步驟

貢獻者

作者：Dharmesh Patel | 醫療照護產業解決方案架構師

其他貢獻者：

  1. 如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。↩