用 Amazon Bedrock 与 AWS HealthLake 构建智能体医疗理赔流水线

使用 Amazon Bedrock 与 AWS HealthLake 构建智能体 AI 医疗理赔处理流水线

人工处理纸质表单仍然是医疗行业的一项重大成本。尽管扫描文档与图像的数据提取技术已不断进步，但通常仍需要人工监督。表单填写者的录入错误，或数字化过程中置信度较低的提取结果，仍然必须予以纠正。

在本文中，我们将展示如何利用 Amazon Bedrock 的两项关键能力构建自动化理赔处理流水线：使用 Amazon Bedrock Data Automation 对医疗理赔表单进行智能文档提取，以及使用 Amazon Bedrock AgentCore 托管一个 AI 智能体（agent），对提取的数据进行校验，并将其转换为 AWS HealthLake 中的 FHIR（Fast Healthcare Interoperability Resources，快速医疗互操作性资源）资源。您将了解如何组合这些服务，创建一条端到端的工作流，在通过自动化校验保持准确性的同时减少人工处理。

方案概览

本方案演示了一个使用 AI 驱动服务处理医疗理赔表单的自动化工作流。当医疗服务提供者将 CMS-1500 理赔表单（PDF 格式）上传到 Amazon Simple Storage Service（Amazon S3）存储桶时，会触发一条处理流水线，起点是 AWS Lambda，它执行三项主要功能：

1. Amazon Bedrock Data Automation 使用智能文档处理技术从表单中提取结构化数据。
2. 一个基于 Strands Agents 构建、运行在 Amazon Bedrock AgentCore 上的 AI 智能体，将提取的数据与 AWS HealthLake 中已有的患者和医疗服务提供者记录进行比对校验，检查数据的完整性与一致性。
3. 如果所有校验都通过，智能体会在 HealthLake 中创建标准化的 FHIR 理赔资源。它还会生成一份面向理赔处理人员的技术摘要，以及一份面向患者的理赔状态通俗说明。两者都通过 Amazon Simple Notification Service（Amazon SNS）通知发出。

这一自动化工作流有助于减少人工处理时间，同时通过 AI 辅助校验保持准确性。

_图 1：方案的架构视图。_

上图说明了以下步骤：

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 中创建文档时被用作事件触发器，并作为智能体工作流的确定性监督者（deterministic supervisor）。它校验每个文档是否已被处理，或将文档发送到死信队列（dead letter queue）以进行异常处理。

Bedrock Data Automation 简化了生成式 AI 开发，并能自动化涉及文档、图像、音频和视频的工作流。在文档处理方面，Bedrock Data Automation 将传统光学字符识别（Optical Character Recognition，OCR）、机器学习（Machine Learning，ML）模型与生成式 AI 相结合，实现数据的精准提取。您可以使用蓝图（Blueprints，即工件）来指定要从文档中提取哪些数据以及如何提取。您可以使用预置模板，也可以构建针对自身用例的自定义配置。输出结果包含所提取字段和表格的置信度分数（confidence score）与边界框（bounding box）数据。此处的自定义输出为格式各异的 CMS-1500 理赔表单生成可预测的 JSON 表示。

AgentCore 托管 Strands 智能体。该智能体使用两个工具与 HealthLake 交互：create_fhir_claim 和 search_fhir_resources。

该智能体使用以下工作流：

1. 在 AWS HealthLake 中查找被保险人（Insured）、患者（Patient）、执业医师（Practitioner）和保险覆盖（Coverage）信息，作为理赔表单中的引用依据。首次尝试使用直接方法调用（direct method calls）和默认搜索参数。除此之外，智能体会运行以下提示词（prompt），检查工具调用结果，并在必要时重新尝试搜索：

首先查看先前的工具调用，识别被保险人资源。如果没有匹配项，请使用理赔 JSON 中的不同搜索参数再尝试两次以寻找匹配。重点关注高置信度分数的属性，并报告你是如何找到匹配的。

2. 如果找到引用资源，则创建理赔的 FHIR 表示并发送到 AWS HealthLake。
3. 创建一个 JSON 对象，记录已完成的工作。该对象包括理赔 ID（如果已创建）、给人工处理人员的响应，以及给患者的响应。处理人员响应起到提醒或观察记录的作用；患者响应则在需要更正错误时向提交人发出信号。

前提条件

在部署本方案之前，请确保您具备以下条件：

• 拥有管理员权限的 AWS 账户。
• 可在 Amazon Bedrock 上访问 Anthropic Claude Sonnet 4.6。更多详情请参阅 Access Amazon Bedrock foundation models（访问 Amazon Bedrock 基础模型）。
• NodeJS 24 或更高版本。
• Node 包管理器（Node Package Manager，npm）11.5 或更高版本。
• Python 3.13 或更高版本。
• AWS 云开发工具包（AWS Cloud Development Kit，AWS CDK）2.1025 或更高版本。

部署方案

部署使用 AWS Cloud Development Kit（CDK）和 AgentCore 命令行界面，步骤如下：

1. 克隆代码仓库：

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

2. 在仓库根目录运行以下命令：

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. 选择 Topics（主题）。
3. 选择 Agent-Notifications。
4. 选择 Create subscription（创建订阅）。
5. 协议（protocol）选择 email（电子邮件）。
6. 输入您的电子邮件地址。
7. 选择 Create subscription（创建订阅）。
8. 按照邮件中确认通知里的链接确认您的订阅。

使用本方案

以下各节将演示两个场景：失败场景和成功场景。

1\. 失败场景：通过在 AWS HealthLake 中省略一个必需的引用资源来模拟失败。

项目代码中包含一个 sampledata 文件夹。使用 load_sampledata.py 预先载入一些数据，其中 <data_store_id> 是 cdk deploy 输出中的 HealthLakeDatastoreArn：

python load_sampledata.py <data_store_id> 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 <data_store_id> bda_output_insuredid_error.json Coverage

按照前述步骤重新处理该 PDF。您将通过 SNS 收到一条类似如下的消息：

_已成功处理患者 John Doe 的 CMS 1500 理赔表单，诊断为背痛（Back Pain）M54.9。患者通过出生日期（1960-10-10）识别。被保险人 Jane Doe 在 ID 搜索失败后通过姓名搜索识别——失败原因是理赔单 ID（11-2234-10190）与数据库 ID（11-2234-1019O）之间存在差异，末位字符不同。Dr. 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）服务器在运行时推断操作顺序。其结果是一个更可靠、更易维护的方案。在构建过程中，我们使用了 Kiro——一款能将自然语言规格说明转化为可运行代码的智能体式 IDE（agentic IDE）。Kiro 生成了 Lambda 内部对 Bedrock Data Automation 的 API 调用，并构建了智能体内部的工具。通过在设计时生成精准、有针对性的代码，而不是在运行时发出宽泛的探索性提示，Kiro 减少了对 Bedrock 的调用次数。这有助于降低运营成本并缩短开发生命周期。

以确定性方式监督智能体。 在此架构中使用 S3 和 Lambda 是有意为之的。智能体只做两件基本的事情：观察显式的工具调用，以及生成要载入 HealthLake 的 FHIR 资源。然后它向 Lambda 函数汇报结果，由 Lambda 函数充当理赔成功或失败的最终裁决者。

清理资源

可运行以下命令来移除本方案：

cd agentcore
python cleanup_resources.py
npx cdk destroy

成本

以下列出了各所用服务的成本考量。

注意： 以下成本考量基于本文发布时的 AWS 定价，仅供参考。实际成本可能有所不同。有关最新定价，请参阅相应服务的定价页面。

• AgentCore Runtime 的收费为每 vCPU-小时 0.0895 美元，内存为每 GB-小时 0.00945 美元，单文档成本很小。
• Amazon Bedrock Data Automation 对于字段数不超过 30 个的蓝图为每页 0.04 美元，超出 30 个字段后每增加一个字段加收 0.0005 美元。
• 智能体使用 Anthropic Claude Sonnet 3.7 V1 的模型费用。在我们的测试文档中，令牌（token）大约为 7.6 万输入和 6 千输出。按按需定价计算，即输入 0.23 美元、输出 0.09 美元，合计每文档 0.32 美元。
• AWS HealthLake 按每小时存储量收费，前 10 GB 为每小时 0.27 美元。
• 在此架构中，Lambda、S3 和 SNS 的单文档费用可以忽略不计。

结论

虽然生产环境中的医疗理赔处理往往涉及本方案之外的更多步骤，但这一模式展示了将 AI 智能体集成到文档工作流中的强大能力。通过让 AI 智能体直接访问处理工具，它可以以多种方式提供有价值的洞察：识别潜在的理赔问题、标记需要人工审核的环节，以及生成面向患者的通俗状态消息。这种 AI 辅助方法可以帮助理赔处理人员更高效地工作，在保持准确性的同时缩短处理时间。前面的示例展示了一个很可能的场景：字母 _o_ 与数字零之间的数据差异。在这种情况下，智能体成功化解了该差异并准确处理了理赔。

要了解有关构建智能文档处理方案的更多信息，请查阅 Amazon Bedrock 文档，或浏览 AWS Architecture Center（AWS 架构中心）中的其他医疗行业方案。

关于作者

本文由 AWS 机器学习博客团队发布（原文未列出具体作者署名信息）。 PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/build-an-agentic-ai-healthcare-claims-pipeline-with-amazon-bedrock-and-aws-healthlake