使用 Amazon Bedrock 和 AWS HealthLake 構建代理式醫療索賠處理流水線

在醫療行業，人工處理紙質表單仍然是一項巨大的成本。儘管掃描文件和影像的資料提取技術不斷進步，但通常仍需要人工監督。表單建立者的輸入錯誤或數字化過程中置信度較低的提取結果仍需糾正。

本文展示瞭如何利用 Amazon Bedrock 的兩項關鍵能力構建自動化索賠處理流水線：Amazon Bedrock Data Automation 用於從醫療索賠表單中智慧提取文件，以及 Amazon Bedrock AgentCore 用於託管 AI 代理，該代理將提取的資料驗證並轉換為 AWS HealthLake 中的 FHIR（快速醫療互操作資源）資源。您將學習如何結合這些服務，建立一個端到端工作流，在減少人工處理的同時，透過自動驗證檢查保持準確性。

解決方案概述

該解決方案演示了使用 AI 驅動服務處理醫療索賠表單的自動化工作流。當醫療提供者將 CMS-1500 索賠表單（PDF 格式）上傳到 Amazon Simple Storage Service (Amazon S3) 儲存桶時，會觸發一個處理流水線，從 AWS Lambda 開始，執行三項主要功能：

• Amazon Bedrock Data Automation 使用智慧文件處理從表單中提取結構化資料。
• 使用 Strands Agents（執行在 Amazon Bedrock AgentCore 上）的 AI 代理根據 AWS HealthLake 中現有的患者和提供者記錄驗證這些資料，檢查完整性和一致性。
• 如果所有驗證透過，代理會在 HealthLake 中建立標準化的 FHIR 索賠資源，併為索賠處理人員生成技術摘要，為患者生成友好易懂的索賠狀態說明，兩者均透過 Amazon Simple Notification Service (Amazon SNS) 傳送通知。

此自動化工作流有助於減少人工處理時間，同時透過 AI 輔助驗證保持準確性。

架構步驟

下圖展示了該解決方案的架構：

1. 提交者將索賠文件上傳到 Amazon 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 代理。代理使用兩個工具與 HealthLake 互動：create_fhir_claim 和 search_fhir_resources。

代理的工作流程如下：

• 在 AWS HealthLake 中查詢被保險人、患者、執業者和保險資訊，用作索賠表單的參考。第一次嘗試使用直接方法呼叫和預設搜尋引數。之後，代理執行以下提示來檢查工具呼叫，並在必要時重新嘗試搜尋：

“識別被保險人資源，首先檢視之前的工具呼叫。如果沒有匹配，嘗試最多兩次使用索賠 JSON 中的不同搜尋引數來找到匹配。重點關注高置信度分數的屬性，並報告如何找到匹配。”

• 如果找到參考，則建立索賠的 FHIR 表示併傳送到 AWS HealthLake。
• 建立一個捕獲已完成工作的 JSON 物件，包括索賠 ID（如果已建立）、給人處理器的響應和給患者的響應。處理器響應作為警報或觀察。患者響應向提交者傳送訊號，告知需要糾正錯誤。

先決條件

在部署解決方案之前，請確保擁有以下內容：

• 具有管理員許可權的 AWS 賬戶。
• 訪問 Amazon Bedrock 上的 Anthropic Claude Sonnet 4.6。更多詳情，請參閱訪問 Amazon Bedrock 基礎模型。
• NodeJS 24 或更高版本。
• 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. 對於協議，選擇“電子郵件”。
6. 輸入您的電子郵件地址。
7. 選擇“建立訂閱”。
8. 按照電子郵件中的確認連結確認訂閱。

使用解決方案

以下部分介紹了兩個場景：失敗場景和成功場景。

1. 失敗場景：透過在 AWS HealthLake 中遺漏一個必需的參考資源來模擬失敗。

專案程式碼包含一個 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 資料夾。我們故意不載入一個必需的資源。

這應該會透過 SNS 生成類似以下訊息：

“我們無法處理您的索賠，因為我們在系統中找不到您的保險資訊。請與您的保險提供商聯絡，驗證您的 AnyHealth Plus Medicare 計劃的保單號 G4683A，或致電我們的辦公室更新您的保險資訊。”

這模擬了代理如何識別問題並生成面向人類的索賠失敗響應。

2. 成功場景：透過確保必需的 HealthLake 資源存在來模擬成功處理。在此場景中，我們插入了一個資料差異供代理處理。在以下示例資料中，被保險人的 ID 號已被更改。

在 HealthLake 中建立缺失的參考：

python load_sampledata.py bda_output_insuredid_error.json Coverage

使用上述步驟重新處理 PDF。您將收到類似以下訊息：

“成功處理了患者 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 的初始查詢遵循一致的模式。由於這些需求在設計時已明確定義，我們顯式編碼了邏輯，而不是依賴模型上下文協議 (MCP) 伺服器在執行時推斷操作順序。結果是一個更可靠、更易維護的解決方案。我們使用了 Kiro（一個代理式 IDE）將自然語言規範轉換為工作程式碼。Kiro 在 Lambda 中生成了對 Bedrock Data Automation 的 API 呼叫，並在代理中構建了工具。透過在執行時生成精確的目的碼，而不是發出廣泛、探索性的提示，Kiro 減少了對 Bedrock 的呼叫次數，從而降低了運營成本並縮短了開發週期。

• 確定性監督代理：在此架構中有意使用 S3 和 Lambda。代理做兩件事：觀察明確的工具呼叫，並生成要載入到 HealthLake 的 FHIR 資源。然後它向 Lambda 函式報告，該函式作為索賠成功或失敗的最終仲裁者。

清理

可以呼叫以下命令移除解決方案：

cd agentcore python cleanup_resources.py npx cdk destroy

成本

以下列出了每項服務的成本考慮因素。

注意：以下成本考慮基於釋出時的 AWS 定價，僅供參考。實際成本可能有所不同。有關最新定價，請參閱各服務的定價頁面。

• AgentCore 執行時費用：每 vCPU 小時 $0.0895，記憶體每 GB 小時 $0.00945，每份文件成本較低。
• Amazon Bedrock Data Automation：30 個或更少欄位的藍圖每頁 $0.04，超過 30 個欄位每個額外欄位 $0.0005。
• 使用 Anthropic Claude Sonnet 3.7 V1 的代理模型費用：在我們的測試文件中，輸入約 76,000 token，輸出約 6,000 token。按需定價為輸入 $0.23，輸出 $0.09，每份文件 $0.32。
• AWS HealthLake 按儲存小時計費，前 10 GB 每小時 $0.27。
• Lambda、S3 和 SNS 在此架構中每份文件的費用可忽略不計。

結論

雖然生產級醫療索賠處理通常比此解決方案包含更多步驟，但此模式展示了將 AI 代理整合到文件工作流中的強大能力。透過讓 AI 代理直接訪問處理工具，它可以多種方式提供寶貴見解：識別潛在的索賠問題，突出需要人工審查的領域，並生成面向患者的狀態訊息。這種 AI 輔助方法可以幫助索賠處理人員更高效地工作，減少處理時間，同時保持準確性。前面的示例展示了一個可能出現的場景：字母 'o' 和數字 '0' 之間的資料差異。在此情況下，代理處理了差異並準確處理了索賠。

要了解更多關於構建智慧文件處理解決方案的資訊，請探索 Amazon Bedrock 文件或檢視 AWS 架構中心的其他醫療保健解決方案。

關於作者