このドキュメントでは、Google Cloud を使用して事前承認（PA）申請処理を自動化し、利用審査（UR）プロセスを改善したい医療保険会社のリファレンス アーキテクチャについて説明します。このガイドは、これらの組織のソフトウェア デベロッパーとプログラム管理者を対象としています。このアーキテクチャにより、医療保険会社は、データの取り込みと臨床フォームからの分析情報の抽出を自動化することで、管理オーバーヘッドを削減し、効率を高め、意思決定を強化できます。また、AI モデルを使用してプロンプトの生成と推奨事項を取得することもできます。
アーキテクチャ
次の図は、データ取り込みワークフローを自動化し、利用管理（UM）審査プロセスを最適化するアーキテクチャとアプローチを示しています。このアプローチでは、Google Cloud のデータと AI サービスを使用します。
上記のアーキテクチャには 2 つのデータフローが含まれています。これらのフローは、次のサブシステムによってサポートされています。
- 申請データ アクティベーター（CDA）: フォームや文書などの非構造化ソースからデータを抽出し、構造化された機械読み取り可能な形式でデータベースに取り込みます。CDA は、PA 申請フォームを取り込むデータフローを実装します。
- 利用審査サービス（UR サービス）: PA 申請データ、ポリシー ドキュメント、その他の治療指針を統合して、推奨事項を生成します。UR サービスは、生成 AI を使用して PA 申請を審査するためのデータフローを実装します。
以降のセクションでは、これらのデータフローについて詳しく説明します。
CDA のデータフロー
次の図は、CDA を使用して PA 申請フォームを取り込む場合のデータフローを示します。
上記の図に示すように、PA ケース マネージャーはシステム コンポーネントとやり取りして、PA 申請の取り込み、検証、処理を行います。PA ケース マネージャーは、PA 申請を受け取るビジネス オペレーション チームのメンバーです。イベントのフローは次のとおりです。
- PA ケース マネージャーは、医療機関から PA 申請フォーム（
pa_forms）を受け取り、pa_forms_bktCloud Storage バケットにアップロードします。 ingestion_serviceサービスは、pa_forms_bktバケットの変更をリッスンします。ingestion_serviceサービスは、pa_forms_bktバケットからpa_formsフォームを取得します。このサービスは、事前構成された Document AI プロセッサ（form_processors）を識別します。これらのプロセッサは、pa_formsフォームを処理するように定義されています。ingestion_serviceサービスは、form_processorsプロセッサを使用してフォームから情報を抽出します。フォームから抽出されたデータは JSON 形式です。ingestion_serviceサービスは、フィールドレベルの信頼スコアとともに抽出された情報を Firestore データベース コレクション（pa_form_collection）に書き込みます。hitl_appアプリケーションは、pa_form_collectionデータベースから信頼スコアを含む情報（JSON）を取得します。アプリケーションは、form_processorsML モデルの出力で利用可能なフィールドレベルの信頼スコアから文書レベルの信頼スコアを計算します。hitl_appアプリケーションは、抽出された情報にフィールドと文書レベルの信頼スコアを付けて PA ケースマネージャーに表示します。抽出された値が不正確な場合は、情報を確認して修正できます。PA ケース マネージャーは、誤った値を更新してpa_form_collectionデータベースにドキュメントを保存できます。
UR サービスのデータフロー
次の図は、UR サービスのデータフローを示します。
上記の図に示すように、UR スペシャリストはシステム コンポーネントとやり取りして、PA 申請の臨床審査を行います。UR スペシャリストは通常、特定の臨床分野の経験を持ち、医療保険会社に雇用されている看護師または医師です。PA 申請のケース管理とルーティング ワークフローは、このセクションで説明するワークフローの範囲外です。
イベントのフローは次のとおりです。
ur_appアプリケーションが、UR スペシャリストに PA 申請のリストとその審査状況を表示します。ステータスには、in_queue、in_progress、completedのいずれかが表示されます。- このリストは、
pa_form_collectionデータベースからpa_form informationデータを取得して作成されます。UR スペシャリストは、ur_appアプリケーションに表示されたリストの項目をクリックして、申請を開きます。 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}.ur_appアプリケーションは、確認とフィードバックのため、生成されたプロンプトを UR スペシャリストに表示します。UR スペシャリストは、UI でプロンプトを更新して、アプリに送信できます。ur_appアプリケーションは、推奨事項を生成するために、申請と一緒にプロンプトをur_modelモデルに送信します。モデルがレスポンスを生成してアプリケーションに返します。推奨される結果が UR スペシャリストに表示されます。UR スペシャリストは、
ur_search_appアプリケーションを使用してclinical documents、care guidelines、plan policy documentsを検索できます。clinical documents、care guidelines、plan policy documentsは事前にインデックスに登録され、ur_search_appアプリケーションからアクセスできます。
コンポーネント
このアーキテクチャは、次のコンポーネントで構成されます。
Cloud Storage バケット。UM アプリケーション サービスを使用するには、Google Cloud プロジェクトに次の Cloud Storage バケットが必要です。
pa_forms_bkt: 承認が必要な PA フォームを取り込むバケット。training_forms: DocAI フォーム プロセッサをトレーニングするための過去の PA フォームを保持するバケット。eval_forms: DocAI フォーム プロセッサの精度を評価するための PA フォームを保持するバケット。tuning_dataset: 大規模言語モデル（LLM）のチューニングに必要なデータを保持するバケット。eval_dataset: LLM の評価に必要なデータを保持するバケット。clinical_docs: 医療従事者が PA フォームに添付ファイルとして送信するか、PA ケースをサポートするために後で送信する診療文書を保持するバケット。これらの文書には、Vertex AI Agent Builder サービスの検索アプリケーションによってインデックスが作成されます。um_policies: 医療の必要性と治療指針、健康保険プランのポリシー ドキュメント、保険対象のガイドラインを保持するバケット。これらのドキュメントには、Vertex AI Agent Builder サービスの検索アプリケーションによってインデックスが作成されます。
form_processors: これらのプロセッサは、pa_formsフォームから情報を抽出するようにトレーニングされています。pa_form_collection: 抽出された情報を NoSQL データベース コレクションに JSON ドキュメントとして保存する Firestore データストア。ingestion_service: バケットからドキュメントを読み取り、解析のために DocAI エンドポイントに渡し、抽出されたデータを Firestore データベース コレクションに保存するマイクロサービス。hitl_app:pa_formsから抽出されたデータ値を取得して表示するマイクロサービス（ウェブ アプリケーション）。また、フォーム プロセッサ（ML モデル）によって報告された信頼スコアが PA ケース マネージャーにレンダリングされるため、ケース マネージャーはデータストアで情報を確認、修正、保存できます。ur_app: UR スペシャリストが、生成 AI を使用して PA 申請を確認するために使用できるマイクロサービス（ウェブ アプリケーション）。prompt_modelという名前のモデルを使用してプロンプトを生成します。マイクロサービスは、pa_formsフォームから抽出されたデータをprompt_modelモデルに渡して、プロンプトを生成します。次に、生成されたプロンプトをur_modelモデルに渡して、ケースの推奨事項を取得します。医療分野向けにチューニングされた Vertex AI の LLM: Vertex AI には、コストとレイテンシを削減するためにチューニングできるさまざまな生成 AI 基盤モデルがあります。このアーキテクチャで使用されるモデルは次のとおりです。
prompt_model:pa_formsから抽出されたデータに基づいてプロンプトを生成するようにチューニングされた LLM のアダプタ。ur_model: 入力プロンプトに基づいて推奨案のドラフトを生成するようにチューニングされた LLM のアダプタ。
ur_search_app: Vertex AI Agent Builder で構築された検索アプリケーション。診療文書、UM ポリシー、保険適用ガイドラインから、UR スペシャリストに関連するパーソナライズされた情報を検索します。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Vertex AI: ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する LLM をカスタマイズできる ML プラットフォーム。
- Vertex AI Agent Builder: デベロッパーがエンタープライズ グレードの AI を活用したエージェントとアプリケーションを作成してデプロイできるプラットフォーム。
- Document AI: ドキュメントから非構造化データを取り出して構造化データに変換するドキュメント処理プラットフォーム。
- Firestore: 自動スケーリングと高性能を実現し、アプリケーション開発を簡素化するように構築された NoSQL ドキュメント データベースです。
- Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloud の内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
- Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
- Cloud Monitoring: アプリケーションとインフラストラクチャのパフォーマンス、可用性、動作状況を可視化するサービス。
ユースケース
UM は、主に米国の医療保険会社で使用されるプロセスですが、若干の違いはあるものの、医療保険市場では同様のプロセスが世界的に使用されています。UM の目標は、患者が適切な環境で、最適なタイミングで、可能な限り低コストで適切な治療を受けられるようにすることです。UM は、医療が効果的かつ効率的であり、エビデンスに基づく治療の基準に準拠したものであることを保証するうえでも役立ちます。PA は、患者が医療を受ける前に保険会社の承認を必要とする UM ツールです。
多くの企業が使用している UM プロセスは、タイムリーな治療の提供と利用の障害となっています。コストと時間がかかり、管理が過剰になります。また、複雑で自動化されていないため、時間がかかります。このプロセスは、医療保険会社が医療の質を効果的に管理し、医療提供者と加入者のエクスペリエンスを改善する能力に大きく影響します。しかし、UM プロセスを変更することで、患者が質の高い費用対効果に優れた治療を受けられるようにすることができます。UR プロセスを最適化することで、PA 申請を迅速に処理することができます。健康保険プランのコストと不承認の件数を減らし、患者と医療提供者のエクスペリエンスを向上させることができます。このアプローチにより、医療機関の管理負担を軽減できます。
健康保険会社が PA 申請を受け取ると、PA ケース マネージャーはケース管理システムでケースを作成し、申請を追跡、管理、処理します。これらの申請の多くは、診療文書が添付されたファックスや郵便で届きます。しかし、これらのフォームと文書に含まれる情報は、医療保険会社が簡単にアクセスして、データ分析やビジネス インテリジェンスに使用できるものではありません。これらの文書からケース管理システムに手作業で情報を入力する現在のプロセスは非効率的で時間がかかり、エラーにつながる可能性があります。
データ取り込みプロセスを自動化することで、費用、データ入力のエラー、スタッフの管理負担を軽減できます。臨床フォームと文書から有用な情報を抽出することで、健康保険会社は UR プロセスを迅速化できます。
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たす 1 つ以上のアーキテクチャを開発する際に役立つガイダンスを示します。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、プライバシー、コンプライアンスの要件を満たす Google Cloud アーキテクチャを設計して構築する際に考慮すべき要素について説明します。
米国では、医療保険の相互運用性と説明責任に関する法律（Health Insurance Portability and Accountability Act（HIPAA）（「経済的および臨床的健全性のための医療情報技術に関する法律」（HITECH）などにより改正）により、HIPAA のセキュリティ ルール、プライバシー ルール、侵害通知ルールへの準拠が義務付けられています。Google Cloud は HIPAA コンプライアンスをサポートしていますが、最終的にはお客様が自身の HIPAA コンプライアンスを評価する必要があります。HIPAA への準拠はお客様と Google の共同責任です。組織が HIPAA の対象であり、保護された医療情報（PHI）を Google Cloud プロダクトで扱う場合は、Google の業務提携契約（BAA）をご確認のうえ、同意していただく必要があります。BAA の対象となる Google プロダクトが HIPAA の要件を満たし、ISO/IEC 27001、27017、27018 認証および SOC 2 報告書に適合しています。
Vertex AI Model Garden でホストされているすべての LLM が HIPAA をサポートしているわけではありません。HIPAA をサポートする LLM を評価して使用します。
Google プロダクトによる HIPAA コンプライアンスの準拠状況を確認するには、コンプライアンス リソース センターで第三者機関による監査報告書をご覧ください。
AI のユースケースを選択する際は、以下の点を考慮して設計することをおすすめします。
- データ プライバシー: Google Cloud Vertex AI プラットフォームと Document AI は、基盤モデルの改善やトレーニングに顧客データ、データ使用量、コンテンツ、ドキュメントを使用しません。Google Cloud の保護されたテナント内のデータとドキュメントを使用して、基盤モデルをチューニングできます。
- Firestore サーバー クライアント ライブラリは、Identity and Access Management（IAM）を使用してデータベースへのアクセスを管理します。Firebase のセキュリティとプライバシーに関する情報については、Firebase のプライバシーとセキュリティをご覧ください。
- 機密データを保存するために、
ingestion_service、hitl_app、ur_appサービス イメージを顧客管理の暗号鍵（CMEK）で暗号化できます。また、Secret Manager と統合することもできます。 - Vertex AI には、モデルとトレーニング データを保護するために Google Cloud セキュリティ管理が実装されています。一部のセキュリティ管理は、Vertex AI の生成 AI 機能でサポートされていません。詳細については、Vertex AI のセキュリティ管理と生成 AI のセキュリティ管理をご覧ください。
- IAM を使用して、クラウド リソースで最小権限と職務分担の原則を実装することをおすすめします。この制御により、プロジェクト、フォルダ、データセットのレベルでアクセスを制限できます。
- Cloud Storage は、データを自動的に暗号化された状態で保存します。データを暗号化するその他の方法については、データ暗号化オプションをご覧ください。
Google のプロダクトは、責任ある AI に関する原則に準拠しています。
信頼性
このセクションでは、PA 申請処理を自動化するための信頼性の高いインフラストラクチャを構築し、運用する際に考慮すべき設計要素について説明します。
Document AI form_processors はリージョン サービスです。データはリージョン内の複数のゾーンに同期的に保存されます。トラフィックは、ゾーン間で自動的にロードバランスされます。ゾーンが停止しても、データは失われません。リージョンが停止した場合、Google が問題を解決するまでサービスは使用できません。
Cloud Storage バケットは、pa_forms_bkt、training_forms、eval_forms、tuning_dataset、eval_dataset、clinical_docs、または um_policies バケットを使用して、リージョン、デュアルリージョン、マルチリージョンの 3 つのロケーションのいずれかに作成できます。リージョン バケットに格納されたデータは、リージョン内の複数のゾーン間で同期的に複製されます。高可用性を実現するには、デュアルリージョンまたはマルチリージョン バケットを使用します。この場合、データはリージョン間で非同期で複製されます。
Firestore では、pa_form_collection データベースから抽出された情報を複数のデータセンターに配置し、グローバルなスケーラビリティと信頼性を実現できます。
Cloud Run サービス ingestion_service、hitl_app、ur_app はリージョン サービスです。データはリージョン内の複数のゾーンに同期的に保存されます。トラフィックは、ゾーン間で自動的にロードバランスされます。ゾーンが停止しても、Cloud Run ジョブは引き続き実行されます。データは失われません。リージョンが停止した場合、Google が問題を解決するまで Cloud Run ジョブは実行を停止します。個々の Cloud Run ジョブまたはタスクが失敗する可能性があります。このような障害に対処するには、チェックポイントを設定してタスクを再試行します。詳細については、ジョブの再試行とチェックポイントに関するベスト プラクティスをご覧ください。Cloud Run 信頼性ガイドでは、Cloud Run の使用に関するベスト プラクティスについて説明しています。
Vertex AI は、データの準備からモデルのデプロイとモニタリングまで、ML ライフサイクル全体を網羅した環境を提供する、ユーザー フレンドリーで包括的な ML プラットフォームです。
費用の最適化
このセクションでは、PA 申請処理を自動化し、UR プロセスを改善するためのアーキテクチャの作成と実行にかかる費用を最適化する方法について説明します。リソース使用量を慎重に管理し、適切なサービスティアを選択することで、全体的な費用に大きな影響を与えることができます。
Cloud Storage ストレージ クラス: データアクセス頻度に応じて、さまざまなストレージ クラス（Standard、Nearline、Coldline、Archive）を使用します。Nearline、Coldline、Archive は、アクセス頻度の低いデータに費用対効果の高いストレージです。
Cloud Storage ライフサイクル ポリシー: ライフサイクル ポリシーを実装して、経過時間とアクセス パターンに基づいてオブジェクトを低コストのストレージ クラスに自動的に移行したり、削除します。
Document AI の料金は、デプロイされたプロセッサの数と、Document AI プロセッサによって処理されたページ数に基づいて請求されます。次の点を考慮してください。
- プロセッサの最適化: ワークロード パターンを分析して、デプロイする Document AI プロセッサの最適な数を決定します。リソースのオーバー プロビジョニングを回避してください。
- ページ数の管理: ドキュメントを事前に処理して不要なページを削除したり、解像度を最適化することで、処理コストを削減できます。
Firestore の料金は、ドキュメント、インデックス エントリ、データベースが使用するストレージ、ネットワーク帯域幅の量に関連するアクティビティに基づいて決定されます。次の点を考慮してください。
- データ モデリング: インデックス エントリの数を最小限に抑え、効率性を高めるためにクエリパターンを最適化するようにデータモデルを設計します。
- ネットワーク帯域幅: ネットワーク使用量をモニタリングして最適化し、過剰な請求を回避します。アクセス頻度が高いデータは、キャッシュに保存することを検討してください。
Cloud Run の料金は、オンデマンドの CPU 使用率、メモリ、リクエスト数に基づいて計算されます。リソースの割り当てについては慎重に検討してください。ワークロードの特性に基づいて CPU とメモリのリソースを割り当てます。自動スケーリングを使用して、需要に応じてリソースを動的に調整します。
Vertex AI LLM は通常、テキストまたはメディアの入力と出力に基づいて課金されます。入力トークンと出力トークンの数は、LLM のコストに直接影響します。効率性を高めるため、プロンプトとレスポンスの生成を最適化します。
Vertex AI Agent Builder 検索エンジンの料金は、使用する機能によって異なります。費用を管理するには、次の 3 つのオプションから選択できます。
- Search Standard Edition（非構造化検索機能を提供）
- Search Enterprise Edition（非構造化検索とウェブサイト検索機能を提供）。
- 検索 LLM アドオン（要約とマルチターン検索機能を提供）。
費用を最適化するために、次の追加の考慮事項も検討してください。
- モニタリングとアラート: Cloud Monitoring と課金アラートを設定して費用を追跡し、使用量がしきい値を超えたときに通知を受け取ります。
- 費用レポート: Google Cloud コンソールで費用レポートを定期的に確認して傾向を把握し、リソース使用量を最適化します。
- 確約利用割引を検討する: ワークロードを予測できる場合は、指定した期間、これらのリソースを使用することで割引料金が適用されることを検討してください。
これらの要素を慎重に検討し、推奨される戦略を実装することで、Google Cloud で PA と UR の自動化アーキテクチャを実行する費用を効果的に管理し、最適化できます。
デプロイ
このアーキテクチャのリファレンス実装コードは、オープンソース ライセンスに基づいて提供されます。このコードが実装するアーキテクチャはプロトタイプであり、本番環境のデプロイに必要な機能と強化が含まれていない場合があります。このリファレンス アーキテクチャを実装して、要件にさらに適合させるには、Google Cloud コンサルティングにご相談ください。
このリファレンス アーキテクチャのスターター コードは、次の git リポジトリで入手できます。
- CDA git リポジトリ: このリポジトリには、インフラストラクチャのプロビジョニングとアプリケーション コードのデプロイ用の Terraform デプロイ スクリプトが含まれています。
- UR サービスの Git リポジトリ: このリポジトリには、UR サービスのコードサンプルが含まれています。
このリファレンス アーキテクチャのサポートとサービスを実装するには、次の 2 つのオプションのいずれかを選択します。
- Google Cloud コンサルティングに相談する。
- このアーキテクチャで説明されているプロダクトとソリューション コンポーネントを使用して、パッケージ化されたサービスを構築したパートナーに相談する。
次のステップ
- Vertex AI を使用して RAG 対応の生成 AI アプリケーションのインフラストラクチャを構築する方法を学習する。
- GKE を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ
- 生成 AI レスポンスのグラウンディングに関する Google Cloud のオプションを確認する。
- Cloud Run 用に Python アプリケーションを最適化する方法を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
作成者: Dharmesh Patel | 業界別ソリューション アーキテクト、ヘルスケア
その他の寄稿者:
- Ben Swenka | キー エンタープライズ アーキテクト
- Emily Qiao | ネットワーキング プロダクト スペシャリスト
- Luis Urena | デベロッパーリレーションズ エンジニア
- Praney Mittal | グループ プロダクト マネージャー
- Lakshmanan Sethu | テクニカル アカウント マネージャー