使用 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 架構中心的其他醫療保健解決方案。

關於作者