医疗 AI 项目难的不只是调用大模型，更是把模型接入审核流程，同时控制敏感数据、租户隔离、审计记录和上线节奏。MHK 在 AWS 上构建了 SmartProminence AI Orchestrator，组合 Amazon Bedrock、Amazon ECS 与事件驱动模式，形成一个符合 HIPAA 使用资格要求的智能体工作流框架。根据案例摘要，该方案将人工医疗审核工作量降低了 90%，并把新 AI 功能的部署周期从数月压缩到数周。
编排器比单次模型调用更重要
一次 Amazon Bedrock API 调用只能完成局部任务。完整的医疗审核流程通常还需要：
- 接收并验证业务请求；
- 根据租户、产品和审核类型选择工作流；
- 调用大模型提取信息、分类或生成建议；
- 调用规则引擎、内部 API 或检索工具；
- 对结果执行结构校验和置信度检查；
- 将高风险或不确定结果交给人工复核；
- 保存决策轨迹，但避免在日志中泄露受保护健康信息（PHI）。
因此，智能体不应被理解成一个可以自由行动的聊天机器人。更稳妥的设计是把它放进受约束的状态机：每一步允许调用哪些工具、可读取哪些数据、失败后如何重试，都由编排层明确控制。
结合摘要中提到的 AWS 服务，可以将参考架构组织为：
业务系统 / API
|
身份认证、租户识别与请求校验
|
事件总线或消息队列
|
Amazon ECS 上的 AI Orchestrator
|-- Amazon Bedrock：推理与结构化输出
|-- 业务规则或受控工具
|-- 人工审核队列
`-- 审计与结果存储
这是基于相关服务能力整理的实践方式，并不代表 MHK 未公开的具体实现细节。事件驱动设计的价值在于解耦：业务入口不必等待整个 AI 流程结束，工作节点也可以独立扩缩容、重试和演进。
多租户复用不能只靠一个 tenant_id
可复用编排器能够缩短新功能上线时间，但多租户架构不能仅在请求中增加一个租户字段。租户上下文需要贯穿事件、权限、数据、提示词和审计链路。
建议至少明确以下边界：
- 入口身份绑定：租户标识应从经过验证的身份或服务凭证中派生，而不是直接信任客户端提交的值。
- 数据隔离：对象存储、数据库分区、加密密钥和检索索引都要执行租户级访问控制。
- 模型配置隔离：不同租户可以使用不同的模型、提示词版本、工具白名单和人工审核阈值。
- 资源保护：按租户设置并发、令牌和成本配额，避免一个租户耗尽共享容量。
- 可追溯性：记录工作流版本、模型标识、提示词版本、工具调用结果和最终审批人，但对日志内容做最小化与脱敏处理。
编排器可以复用的是执行骨架，而不是无条件共享全部数据和权限。新增 AI 功能时，理想状态是增加一个版本化工作流定义或任务处理器，而不是复制整套基础设施。
一个可改造的 Bedrock 工作节点
下面是一个最小化示例：ECS 工作容器读取事件，验证租户上下文，然后使用 Amazon Bedrock Converse API 对一段合成医疗审核文本进行结构化分析。示例中的内容不包含真实 PHI，可直接用于连通性测试。
先安装依赖并设置模型 ID。请将 BEDROCK_MODEL_ID 替换为当前 AWS 区域中已获准使用的模型：
python -m pip install boto3
export AWS_REGION=us-east-1
export BEDROCK_MODEL_ID='replace-with-an-enabled-model-id'
创建 event.json：
{
"tenant_id": "demo-health-plan",
"workflow": "medical-review-summary-v1",
"case_id": "synthetic-001",
"clinical_text": "Synthetic example: the request includes a diagnosis, but no documented prior conservative treatment."
}
创建 worker.py：
import json
import os
import sys
import boto3
ALLOWED_TENANTS = {'demo-health-plan'}
ALLOWED_WORKFLOWS = {'medical-review-summary-v1'}
def handle(event: dict) -> dict:
tenant_id = event.get('tenant_id')
workflow = event.get('workflow')
if tenant_id not in ALLOWED_TENANTS:
raise ValueError('Unknown tenant')
if workflow not in ALLOWED_WORKFLOWS:
raise ValueError('Unknown workflow')
text = event.get('clinical_text', '')
if not text:
raise ValueError('clinical_text is required')
client = boto3.client(
'bedrock-runtime',
region_name=os.environ.get('AWS_REGION', 'us-east-1'),
)
response = client.converse(
modelId=os.environ['BEDROCK_MODEL_ID'],
system=[{
'text': (
'You assist a human medical reviewer. Do not make a final '
'clinical or coverage decision. Return concise JSON with keys '
'summary, missing_evidence, and needs_human_review.'
)
}],
messages=[{
'role': 'user',
'content': [{'text': text}],
}],
inferenceConfig={
'temperature': 0,
'maxTokens': 400,
},
)
model_text = response['output']['message']['content'][0]['text']
return {
'tenant_id': tenant_id,
'workflow': workflow,
'case_id': event.get('case_id'),
'model_output': model_text,
'status': 'PENDING_HUMAN_REVIEW',
}
if __name__ == '__main__':
with open(sys.argv[1], encoding='utf-8') as file:
event = json.load(file)
print(json.dumps(handle(event), ensure_ascii=False, indent=2))
运行：
python worker.py event.json
这个示例刻意把最终状态设置为 PENDING_HUMAN_REVIEW。在真实医疗场景中，模型输出应该先经过 JSON Schema 校验、业务规则检查和风险分级，再决定是否可以自动进入下一步。生产环境还应使用 IAM 任务角色，不要把 AWS 密钥写入镜像或环境文件。
如果将其部署到 ECS，可以让消息队列中的每条事件对应一次任务处理，也可以运行长期驻留的消费者。需要提前定义幂等键，例如 tenant_id + case_id + workflow_version，防止消息重试造成重复审核或重复写入。
“HIPAA-eligible”不等于系统自动合规
Amazon Bedrock 或其他 AWS 服务具备 HIPAA 使用资格，并不意味着部署后的应用天然符合 HIPAA。组织仍需确认适用服务是否包含在与 AWS 签订的业务伙伴协议（BAA）范围内，并完成自身的技术与管理控制。
上线前应检查：
- PHI 是否只进入经过批准的服务、区域和数据路径；
- 传输中与静态数据是否加密，密钥权限是否最小化；
- ECS 任务角色是否只能访问当前工作流需要的模型和资源；
- 日志、指标、错误栈和提示词追踪是否会意外记录 PHI；
- 是否定义数据保留、删除和审计策略；
- 模型输出是否经过确定性校验，并保留人工复核通道；
- 是否测试提示词注入、越权工具调用、跨租户访问和错误重试；
- 模型、提示词或工作流升级后，是否重新执行质量与安全评估。
采用时从窄流程开始
MHK 案例展示了复用型 AI 编排层的核心收益：团队不必为每个医疗 AI 功能重新搭建模型调用、运行环境、事件处理和治理能力。但降低 90% 人工工作量不应被简单理解为取消人工审核，更合理的目标是让系统处理信息整理和低风险判断，把人的时间集中到例外与高风险案例。
落地时可以先选择输入边界清楚、结果容易验证、现有人工流程成熟的审核任务。建立基线指标后，再衡量处理时长、人工触达率、错误率、跨租户隔离和单次工作流成本。只有当安全控制与评估流程也能复用时，从“数月到数周”的交付提速才具有可持续性。