AWS Architecture Blog

How MHK built a HIPAA-eligible agentic AI solution on Amazon Bedrock

7.1内容质量
How MHK built a HIPAA-eligible agentic AI solution on Amazon Bedrock

TL;DR · AI 摘要

How MHK built a HIPAA-eligible agentic AI solution on Amazon Bedrock AWS Architecture Blog How MHK built a HIPAA-eligibl...

核心要点

  • 主题聚焦:How MHK built a HIPAA-eligible agentic AI soluti
  • 来源:AWS Architecture Blog,建议结合原文判断细节。
  • AI 分析暂不可用,本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

MHK如何在Amazon Bedrock上构建符合HIPAA的智能AI解决方案 | AWS架构博客

MHK如何在Amazon Bedrock上构建符合HIPAA的智能AI解决方案

医疗健康机构面临日益复杂的挑战:在处理海量医疗文件(包括临床记录、索赔、预授权、申诉和药房数据)的同时,必须严格遵守HIPAA合规性和安全标准。传统方法需要专门的工程团队为每个用例构建独立的AI系统,每个系统都需要自己的合规基础设施、审计追踪和安全控制。能够跨用例扩展的智能框架可以缩短冗长的开发周期并降低高昂的运营成本。

作为Hearst Health旗下的公司,在2024年KLAS最佳软件与服务报告中排名第一的payer care管理解决方案提供商MHK,正面临这一确切挑战。其医疗管理解决方案服务于多个工作流程(医疗、药房、申诉和投诉)的健康计划,每个流程都需要智能文档处理和决策支持。随着需求增长,为每个工作流程单独构建AI系统变得不可持续。

为解决这一问题,他们开发了SmartProminence AI Orchestrator,这是一个基于AWS构建的符合HIPAA标准的智能工作流框架,将人工医疗审查工作量减少了90%。过去需要3个月以上才能部署的新AI功能,现在只需2周即可上线。

在本文中,我们将介绍MHK如何使用Amazon Bedrock、Amazon弹性容器服务(Amazon ECS)和事件驱动模式,构建了一个可重复使用的多租户医疗AI编排器。

MHK完全使用Amazon Bedrock进行基础模型推理。他们自行构建了编排、检索和验证层,因为医疗工作流需要特定领域的控制:基于DAG的多步骤执行、与案例上下文关联的临床文档检索,以及超越通用防护措施的HIPAA特定验证逻辑。这种方法使Bedrock专注于可扩展的模型访问,而MHK则保留对工作流行为和合规性执行的完全控制。

背景

MHK为美国各地的健康计划提供医疗成本管理和合规解决方案。其医疗管理系统支持护理决策的完整生命周期,从医疗提供者提交服务请求到最终解决。这包括预授权、索赔结算、申诉处理、药房福利验证和医疗主任审查。

每个工作流程都涉及将非结构化的医疗文件(如临床笔记、实验室结果、影像报告和多页传真记录)与结构化政策标准进行比对。在MHK推出SmartProminence AI Orchestrator之前,案件管理员需要花费5到10分钟手动处理每份传入文件,而医疗主任则需要更长时间审查需要政策合规性判断的复杂案件。

MHK需要在保持医疗审计追踪和合规要求的同时自动化这些研究工作,并且要在所有产品模块中实现这一点,而无需为每个模块单独构建AI基础设施。

业务挑战

当MHK评估如何将AI能力扩展到整个产品套件时,出现了三个核心挑战。

  • 碎片化的AI基础设施。每个AI功能都需要独立的部署流程、HIPAA合规认证、安全控制和监控。每新增一个AI路线图项目就意味着需要新建一个集群、启动一次合规审查并承担新的运营负担。对于需要为多个健康计划的多个模块提供服务的公司来说,这种模式无法实现扩展。
  • 周期漫长的开发流程。通过传统工程方法部署新的AI工作流需要3到6个月时间(不包括需求收集阶段)。工程团队无法跟上产品路线图的节奏。
  • 高昂的人工成本。案例管理员、护士、药师和医疗主任需要为每个案例耗费数小时时间手动查阅患者记录。对于医疗主任(医生)和药师来说,这种成本尤为突出,因为他们的时薪极高,即使节省少量时间也能带来显著的ROI回报。

解决方案概述:SmartProminence AI Orchestrator

MHK构建了SmartProminence AI Orchestrator,这是一个基于AWS的多租户代理工作流框架。与为每个使用场景单独构建AI系统不同,MHK创建了一个统一的编排平台,通过配置即可部署各种AI工作流。只需定义提示词、指定输入/输出模式并注册代理,解决方案即可自动处理HIPAA合规性、加密、审计追踪、扩展性和编排等所有其他环节。

该方案采用控制器-代理架构模式,其中工作流引擎控制器负责解析工作流依赖关系,并将单个步骤分发给LLM处理代理。整个系统是无状态的、事件驱动的,并且可以独立扩展。

下图展示了该方案的高层架构。

Figure 1: MHK SmartProminence AI Orchestrator在AWS上的架构

架构核心是作为中枢神经系统的代理编排核心,基于Spring Boot构建并运行在AWS Fargate上。它通过REST API提供作业提交、工作流管理、LLM代理和令牌管理功能。关键的是,它是唯一直接访问数据库的组件:控制器和代理只能通过编排核心的API进行交互,从而严格限定数据访问边界。

架构概述

本节将探讨编排器用于大规模处理多样化医疗工作流的关键架构模式。

基于Amazon Bedrock的控制器-代理模式

MHK选择Amazon Bedrock作为其解决方案的核心,因为它通过单一API提供多模型访问能力,使其能够根据每个工作流步骤选择最佳模型而无需单独集成。作为AWS托管服务,Bedrock继承了现有的AWS身份和访问管理(IAM)、亚马逊虚拟私有云(Amazon VPC)和加密控制功能,避免了建立新的信任边界。内置的内容过滤和调用日志满足医疗审计需求,其模型无关的架构使MHK能够采用新模型而无需重新设计整个解决方案。

编排器严格区分工作流编排和LLM处理。工作流引擎控制器决定需要执行的操作及其顺序,而LLM处理代理执行具体步骤。这种分离使代理处理能够独立于工作流逻辑进行扩展,同时使工作流成为单一事实来源,而代理仅对特定的可操作步骤进行操作。

当任务到达时,控制器会加载固定版本的工作流定义,使用Kahn算法将步骤依赖关系解析为DAG,并预先创建处于等待状态的步骤执行。它通过条件Spring表达式语言(SpEL)判断需要运行还是跳过哪些步骤,然后逐层派发代理。相同深度的步骤会并行执行,控制器会在进入下一层深度前轮询确认完成状态。

每个代理都运行标准化的处理流程:输入绑定(解析表达式获取前置步骤结果)、对扫描文档的可选视觉处理、结合丰富上下文的提示组装、通过Amazon Bedrock(Claude)调用大语言模型,以及字段提取、类型转换和结构化输出的后处理。

对于单个步骤内的并行工作负载,代理会为每个执行使用Java虚拟线程。这使它们能够同时处理多个项目,例如可以同时从多页文档的每一页中提取数据。

基于Amazon SQS的事件驱动编排

编排核心、控制器和代理之间的通信通过Amazon简单队列服务(Amazon SQS)队列进行。要触发工作流,编排核心会在控制器调用队列中放置一个ControllerTaskMessage。要派发单个步骤,它会在代理调用队列中放置一个AgentTaskMessage。每个消息都通过仅针对该操作数据的权限令牌进行安全保护。

这种设计实现了四个特性。无状态处理使可用实例能够拾取待处理消息。独立扩展使代理可以通过ECS Fargate实现横向扩展。故障隔离确保失败任务不会阻塞并行步骤,死信队列会捕获失败情况。解耦部署可以在不进行系统范围重启的情况下部署新代理版本。

管道中唯一需要阻塞的调用是向Amazon Bedrock的大语言模型调用。其他所有操作都是异步且事件驱动的,因此系统可以处理数百个并发任务而不会产生资源竞争。

基于DAG的并行执行

工作流引擎使用基于深度的并行执行来最大化吞吐量。以医疗政策审查工作流为例:在深度0,代理同时提取患者人口统计数据和获取索赔历史。在深度1,当两者都完成后,策略查询代理会识别相关标准。在深度2,证据收集代理会搜索患者的临床历史以查找满足每个政策标准的文档。只有当前深度的所有步骤完成,控制器才会进入下一层深度。

条件表达式可以根据上游结果动态跳过步骤。例如,如果初始分类步骤确定案件不涉及处方药,那么下一层深度的药房验证步骤会自动被跳过,从而节省时间和令牌成本。这种条件逻辑由控制器使用Spring表达式语言(SpEL)针对已完成步骤的结构化输出进行评估。

动态代理注册

当MHK需要新的代理类型时,无论是为了新的医疗管理模块还是新的分析类型,这个过程都是由配置驱动而非工程驱动的。

开发人员定义代理配置(提示模板、输入/输出模式和模型选择),然后通过编排核心的API进行注册。Terraform会自动部署支持性基础设施:SQS队列、IAM角色和ECS任务定义。由于代理在已通过认证的编排器内运行,因此无需新的合规认证即可立即用于工作流步骤分配。

这种转变显著提升了MHK的开发速度。工程团队专注于提示设计和工作流逻辑,而非基础设施搭建。

会话记忆与案例关联

编排器会在相同患者案例的多次工作流执行之间保持上下文。每次执行都会返回一个作业ID,上游系统将其与案例记录关联。一个案例的生命周期内可能有三次或更多次执行(初始录入、政策审查和申诉处理),每次执行都会生成结构化输出,供后续执行使用。

一旦30页的临床记录被分析,其结构化输出即可用于后续针对该案例的查询,无需重新运行数据摄入。当医疗主管数周后审查申诉时,患者的病史已整理完毕并可搜索。

先前的上下文保留在Amazon Simple Storage Service(Amazon S3)中,并使用客户专用的AWS Key Management Service(AWS KMS)密钥进行加密。

负责任的AI控制

MHK通过每个代理处理流程中的应用层验证来确保LLM输出的安全性。每个代理都会将模型响应后处理为预期的输出模式,将提取的数据与源文档进行交叉核对以检测幻觉,并拒绝未通过置信度阈值的响应。领域特定检查确保输出仅引用患者自身的临床记录并符合特定政策的医疗标准。LLM的输入和输出均带有完整的审计跟踪,支持对每个AI辅助决策的合规审查和可重复性。

使用的AWS服务

下表总结了组成SmartProminence AI编排器的AWS服务及其在架构中的作用。

| 服务 | 架构中的作用 | |------|--------------| | Amazon Bedrock | 基于IAM角色身份验证的模型推理 | | Amazon ECS (Fargate) | 容器化编排核心、工作流控制器和处理代理 | | Amazon SQS | 基于死信队列的组件间事件驱动通信(具备容错能力) | | Amazon RDS (MySQL 8.4) | 工作流定义、执行状态跟踪、多AZ高可用性 | | Amazon S3 | 作业工件、文档存储、不可变工作流配置(KMS加密) | | AWS KMS | 能力令牌签名与验证、多租户数据隔离的客户专用加密密钥 | | Amazon Cognito | API访问和用户身份的OAuth2/JWT认证 | | Amazon CloudWatch | 日志记录、指标、令牌使用跟踪和警报(不含PHI) | | Elastic Load Balancing | TLS 1.3终止的应用负载均衡器 | | Amazon VPC | 私有子网网络隔离、服务访问的VPC端点 |

安全与合规

医疗健康数据需要最高安全标准,MHK架构在每一层都实现了纵深防御。编排器同时为多个健康计划客户处理受保护的健康信息(PHI),因此多租户数据隔离是基础特性。

  • 按客户端加密。每个客户端都拥有独立的AWS KMS密钥。存储在Amazon S3中的文档采用双重加密:S3服务器端加密加上客户端专用的KMS加密。即使某个任务意外被路由到错误位置(令牌系统可防止此类情况),接收代理也无法解密其他客户端的数据,因为其无法访问对应客户端的KMS密钥。数据库层在Amazon Relational Database Service (Amazon RDS)存储级加密基础上增加行级加密,为静态数据提供纵深防御。
  • 能力令牌模型。最小权限令牌系统限制每个组件的访问范围。控制器作用域的令牌可读取工作流定义和任务数据、调度代理任务、创建步骤执行记录。代理作用域的令牌仅能读取自身步骤的输入、写入自己的结果、通过代理调用LLM并上传工件。令牌通过KMS按调度请求生成,即使代理被攻破,也无法访问其他步骤、工作流或客户端的数据。
  • 网络隔离。数据库子网无法访问互联网。AWS服务通信(Amazon S3、Amazon SQS、AWS KMS、AWS Secrets Manager、Amazon CloudWatch、Amazon Elastic Container Registry (Amazon ECR))通过VPC端点传输,确保数据永不经过公共互联网。连接使用TLS 1.3进行传输加密。
  • 合规控制。LLM请求和响应内容不进行日志记录,仅记录令牌数量和内容哈希值。工作流配置以不可变方式存储在S3中,保留完整的版本历史。代理仅接收执行其步骤所需的最小上下文信息,遵循数据最小化原则。

结果与影响

SmartProminence AI Orchestrator在MHK内部运营和健康计划客户中均实现了可衡量的业务成果。

人工审核工作量减少90%。在文档接收工作流中,处理时间从每份文档5-10分钟(人工)缩短至不到1分钟(带人工复核的自动化)。对于复杂的医疗主任审核,系统预先收集相关证据并生成结构化摘要,将医生的任务从数小时的文档检索缩短为30秒的批准或拒绝决策。

AI功能部署速度提升85%。过去需要3-6个月工程周期的新AI功能,现在可在约2周内部署。工程团队无需为每个功能构建定制基础设施、合规管道或安全控制,即可定义工作流配置和提示逻辑。

统一的合规立场。MHK不再需要单独验证每个AI功能,而是通过单一的协调器级HIPAA和SOC 2验证覆盖所有代理。新代理会自动继承协调器的安全控制:按客户端加密、审计日志、基于令牌的访问和数据最小化。

多租户可扩展性。健康计划客户可通过该框架运行AI工作流,无需构建符合HIPAA的基础设施。由于协调器是配置驱动的,MHK可为现有客户快速上线新用例,或以最小的工程投入部署全新的健康计划客户。

结论

协调器的控制器-代理架构为需要在多个使用场景中扩展AI能力而不增加合规负担的组织提供了蓝图。关键洞察在于,合规基础设施应作为协调器级别的关注点,而非每个功能模块的独立关注点。当从底层设计医疗级安全机制时,智能代理编排模式既能发挥强大功能,又具备可审计性。

展望未来,MHK正在为协调器扩展对话式界面,使案件管理人员和医疗主管能够通过交互式查询案件数据,同时使用相同的流程记忆和安全基础设施。随着新的医疗管理模块采用人工智能驱动的决策支持,动态代理注册表持续扩展。MHK还在探索通过AWS Marketplace作为分发渠道,将符合HIPAA标准的智能代理框架推广至医疗行业以外、需要类似合规门槛的组织。

在评论区分享您构建符合HIPAA标准的AI工作流程的经验,或如果您正在探索受监管行业的智能代理架构,欢迎与我们联系。

欲了解更多信息,请从Amazon Bedrock入手,通过探索Amazon Bedrock代码示例,在AWS上构建自己的智能代理AI解决方案。

关于作者

'"`