AI News HubLIVE
サイト内リライト7 分で読了

Amazon Bedrock と AWS HealthLake を使用したエージェンティック AI 医療保険請求パイプラインの構築

この記事では、Amazon Bedrock Data Automation を使用したインテリジェントな文書抽出と、Amazon Bedrock AgentCore でホストされる AI エージェントがデータを検証し AWS HealthLake の FHIR リソースに変換することで、手動処理を削減しつつ自動検証チェックで正確性を維持する、自動化された保険請求処理パイプラインの構築方法を紹介します。

ソースAWS Machine Learning Blog著者: Troy Parrett

医療業界では、紙ベースのフォームを手動で処理することは依然として大きなコストとなっています。スキャン文書や画像のデータ抽出技術は進歩していますが、通常は人間による監視が必要です。フォーム作成者の入力ミスや、デジタル化時の信頼度の低い抽出結果は、依然として修正が必要です。

この記事では、Amazon Bedrock の 2 つの主要機能を使用して自動化された保険請求処理パイプラインを構築する方法を紹介します。Amazon Bedrock Data Automation は医療保険請求フォームからのインテリジェントな文書抽出を行い、Amazon Bedrock AgentCore は抽出されたデータを検証し AWS HealthLake の FHIR（Fast Healthcare Interoperable Resources）リソースに変換する AI エージェントをホストします。これらのサービスを組み合わせて、手動処理を削減しつつ自動検証チェックで正確性を維持するエンドツーエンドのワークフローを作成する方法を学びます。

ソリューション概要

このソリューションは、AI 駆動サービスを使用して医療保険請求フォームを処理する自動化ワークフローを示します。医療提供者が CMS-1500 保険請求フォーム（PDF 形式）を Amazon Simple Storage Service (Amazon S3) バケットにアップロードすると、AWS Lambda で始まる処理パイプラインがトリガーされ、3 つの主要機能を実行します。

  • Amazon Bedrock Data Automation はインテリジェントな文書処理を使用してフォームから構造化データを抽出します。
  • Amazon Bedrock AgentCore で実行される Strands Agents を使用する AI エージェントは、AWS HealthLake の既存の患者および提供者記録に対してこのデータを検証し、完全性と一貫性をチェックします。
  • すべての検証に合格すると、エージェントは HealthLake 内に標準化された FHIR 請求リソースを作成し、請求処理者向けの技術サマリーと、患者向けのわかりやすい請求ステータス説明を生成します。これらは両方とも Amazon Simple Notification Service (Amazon SNS) 通知として送信されます。

この自動化ワークフローは、AI 支援検証を通じて正確性を維持しながら、手動処理時間の削減に役立ちます。

アーキテクチャのステップ

次の図はソリューションのアーキテクチャを示しています。

  1. 提出者が S3 に請求文書をアップロードします。
  2. ファイルが到着すると AWS Lambda がトリガーされます。
  3. Amazon Bedrock Data Automation が文書から情報を抽出し、JSON 形式で結果を出力します。
  4. AWS Lambda が AgentCore を呼び出し、処理のために文書を渡します。
  5. AgentCore が AWS HealthLake にクエリを実行し、請求を作成し、サマリー JSON レスポンスを生成します。
  6. AWS Lambda が Amazon SNS を呼び出し、エラーレスポンスまたは成功レスポンスを配信します。

Lambda は S3 で文書が作成されたときのイベントトリガーとして機能し、エージェンティックワークフローの確定的な監督者として、各文書が処理されるか、例外処理のためにデッドレターキューに送信されるかを検証します。

Bedrock Data Automation は、生成 AI の開発を合理化し、文書、画像、音声、ビデオを含むワークフローを自動化します。文書処理のために、Bedrock Data Automation は従来の光学文字認識 (OCR)、機械学習 (ML) モデル、および生成 AI を組み合わせてデータを正確に抽出します。ブループリント（アーティファクト）を使用して、文書から抽出するデータとその抽出方法を指定できます。事前構築済みテンプレートを使用するか、ユースケースに合わせてカスタム構成を構築できます。出力には、抽出されたフィールドとテーブルの信頼度スコアとバウンディングボックスデータが含まれます。ここでのカスタム出力は、CMS-1500 保険請求フォームのさまざまな形式バリエーションに対して予測可能な JSON 表現を生成します。

AgentCore は Strands エージェントをホストします。エージェントは 2 つのツールを使用して HealthLake と対話します：create_fhir_claim と search_fhir_resources。

エージェントのワークフローは次のとおりです。

  • AWS HealthLake で被保険者、患者、診療者、補償情報を検索し、請求フォームの参照として使用します。最初の試行では直接メソッド呼び出しとデフォルトの検索パラメータを使用します。それ以降、エージェントは次のプロンプトを実行してツール呼び出しを確認し、必要に応じて検索を再試行します。

「被保険者リソースを特定します。最初に以前のツール呼び出しを確認します。一致しない場合は、請求 JSON の異なる検索パラメータを使用して、最大 2 回の試行で一致を見つけます。高い信頼度スコアの属性に焦点を当て、一致をどのように見つけたかを報告します。」

  • 参照が見つかった場合、請求の FHIR 表現を作成し、AWS HealthLake に送信します。
  • 完了した作業をキャプチャする JSON オブジェクトを作成します。オブジェクトには、請求 ID（作成された場合）、人間の処理者向けの応答、患者向けの応答が含まれます。処理者応答はアラートまたは観察として機能します。患者応答は、エラーを修正する必要がある場合に提出者に信号を送ります。

前提条件

ソリューションをデプロイする前に、次のものを用意してください。

  • 管理者権限を持つ AWS アカウント。
  • Amazon Bedrock 上の Anthropic Claude Sonnet 4.6 へのアクセス。詳細については、Amazon Bedrock 基礎モデルへのアクセスを参照してください。
  • NodeJS バージョン 24 以降。
  • Node Package Manager (npm) バージョン 11.5 以降。
  • Python バージョン 3.13 以降。
  • AWS Cloud Development Kit (AWS CDK) バージョン 2.1025 以降。

ソリューションのデプロイ

AWS CDK と AgentCore コマンドラインインターフェースを使用してデプロイします。手順は次のとおりです。

  1. リポジトリをクローンします。

git clone https://github.com/aws-samples/sample-agenticidptohealthlake.git

  1. リポジトリルートから次のコマンドを実行します。

npm install python -m venv .venv source .venv/bin/activate pip install -r requirements.txt pip install -r requirements.txt --python-version 3.12 --platform manylinux2014_aarch64 --target ./packaging/_dependencies --only-binary=:all: cd agentcore agentcore configure --entrypoint claimsprocessor.py agentcore launch python ./bin/package_for_lambda.py npx cdk bootstrap npx cdk deploy

SNS トピックにサブスクライブして通知を受け取る

  1. Amazon SNS コンソールにアクセスします。
  2. 「トピック」を選択します。
  3. 「Agent-Notifications」を選択します。
  4. 「サブスクリプションの作成」を選択します。
  5. プロトコルとして「Eメール」を選択します。
  6. メールアドレスを入力します。
  7. 「サブスクリプションの作成」を選択します。
  8. 確認メールのリンクをクリックしてサブスクリプションを確認します。

ソリューションの使用

次のセクションでは、失敗シナリオと成功シナリオの 2 つのシナリオを説明します。

1. 失敗シナリオ: AWS HealthLake 内の必須参照リソースの 1 つを省略して失敗をシミュレートします。

プロジェクトコードには sampledata フォルダが含まれています。load_sampledata.py を使用してデータをステージングします。HealthLakeDatastoreArn は cdk deploy の出力から取得します。

python load_sampledata.py bda_output_insuredid_error.json Patient,Insured,Practitioner

sample1_cms-1500-P.pdf を S3 バケットの /input フォルダにアップロードします。必須リソースの 1 つを意図的にロードしません。

これにより、SNS を通じて次のようなメッセージが生成されます。

「お客様の保険情報がシステム内に見つからなかったため、請求を処理できませんでした。AnyHealth Plus Medicare プランのポリシー番号 G4683A については、保険会社にご連絡いただくか、当オフィスまでお電話いただき、保険情報を更新してください。」

これは、エージェントが問題を認識し、請求失敗に対して人間にわかりやすい応答を生成する方法をシミュレートしています。

2. 成功シナリオ: 必要な HealthLake リソースが存在することを確認して、正常な処理をシミュレートします。このシナリオでは、エージェントが処理するデータの不一致を挿入します。次のサンプルデータでは、被保険者の ID 番号が変更されています。

HealthLake に不足している参照を作成します。

python load_sampledata.py bda_output_insuredid_error.json Coverage

上記の手順を使用して PDF を再処理します。SNS を通じて次のようなメッセージを受信します。

「患者 John Doe の CMS-1500 請求フォーム（診断：背痛 M54.9）の処理に成功しました。患者は生年月日 (1960-10-10) で特定されました。被保険者 Jane Doe は、ID 検索が失敗したため名前検索で特定されました。請求 ID (11-2234-10190) とデータベース ID (11-2234-1019O) の間で不一致があり、最後の文字が異なります。紹介医の Jane Smith 医師は ID 123456 で特定されました。補償は AnyHealth Plus が発行する Medicare ポリシー G4683A のもとで確認されました。この請求には 4 つの手順が含まれています：2005-10-15 の CPT 97810（$170）、2005-10-20 の CPT 73521（$120）、2005-10-30 の CPT 98940（$250）、2005-10-30 の CPT 97124（$120）、合計 $660。」

このメッセージは、人間のレビュー担当者に、成功した請求とエージェントによるその他の観察結果の簡単な概要を伝えることができます。

ベストプラクティス

  • 設計時 AI は実行時 AI よりも優れている: このソリューションでは、オーケストレーションロジックは事前にわかっています。文書処理の手順は予測可能であり、HealthLake への最初のクエリは一貫したパターンに従います。これらの要件は設計時に明確に定義されているため、Model Context Protocol (MCP) サーバーに実行時の操作順序を推論させるのではなく、明示的にロジックをコード化しました。その結果、より信頼性が高く、保守しやすいソリューションが得られました。構築には、自然言語仕様を動作コードに変換するエージェンティック IDE である Kiro を使用しました。Kiro は Lambda 内の Bedrock Data Automation への API 呼び出しを生成し、エージェント内のツールを構築しました。実行時に広範で探索的なプロンプトを発行する代わりに、設計時に正確でターゲットを絞ったコードを生成することで、Kiro は Bedrock への呼び出し数を削減し、運用コストを削減し、開発ライフサイクルを短縮しました。
  • エージェントを確定的に監視する: このアーキテクチャで S3 と Lambda を使用することは意図的でした。エージェントは基本的に 2 つのことを行います：明示的なツール呼び出しを観察し、HealthLake にロードする FHIR リソースを生成します。その後、Lambda 関数に報告し、Lambda 関数が請求の成功または失敗の最終的な判定者として機能します。

クリーンアップ

次のコマンドを実行してソリューションを削除できます。

cd agentcore python cleanup_resources.py npx cdk destroy

コスト

以下に、各サービスのコストに関する考慮事項を示します。

注：以下のコスト考慮事項は公開時の AWS 料金に基づくものであり、参考目的でのみ提供されています。実際のコストは異なる場合があります。最新の料金については、各サービスの料金ページを参照してください。

  • AgentCore ランタイム料金：vCPU 時間あたり $0.0895、メモリ GB 時間あたり $0.00945。文書あたりのコストはわずかです。
  • Amazon Bedrock Data Automation：30 フィールド以下のブループリントは 1 ページあたり $0.04、30 フィールドを超える場合は追加フィールドあたり $0.0005。
  • Anthropic Claude Sonnet 3.7 V1 を使用するエージェントのモデル料金：テスト文書では、入力約 76,000 トークン、出力約 6,000 トークン。オンデマンド料金では、入力 $0.23、出力 $0.09、文書あたり $0.32。
  • AWS HealthLake は 1 時間あたりのストレージで課金され、最初の 10 GB は 1 時間あたり $0.27。
  • このアーキテクチャでは、Lambda、S3、SNS の文書あたりの料金は無視できる程度です。

結論

本番環境の医療保険請求処理にはこのソリューション以外にも追加の手順が必要になることがよくありますが、このパターンは AI エージェントを文書ワークフローに統合する力強さを示しています。AI エージェントに処理ツールへの直接アクセスを提供することで、潜在的な請求問題の特定、人間によるレビューが必要な領域の強調表示、患者にわかりやすいステータスメッセージの生成など、さまざまな方法で貴重な洞察を提供できます。この AI 支援アプローチは、請求処理者がより効率的に作業し、正確性を維持しながら処理時間を短縮するのに役立ちます。前述の例は、文字 'o' と数字 '0' の間のデータ不一致という、よくあるシナリオを示しています。この状況で、エージェントは不一致をナビゲートし、請求を正確に処理しました。

インテリジェント文書処理ソリューションの構築の詳細については、Amazon Bedrock ドキュメントを参照するか、AWS アーキテクチャセンターの他のヘルスケアソリューションを確認してください。

著者について