使用 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 架构中心的其他医疗保健解决方案。

关于作者