医疗影像 SOAP note 自动生成：HIPAA 合规红线下的工程化

去年 9 月一个朋友在美国做医疗影像中心的 CTO 找到我，说他们一直想搞读片报告自动生成，但合规一块总过不了关。他们规模不大，12 个放射科医生，日均 320 份读片报告，主要做 CT 和 MRI。

医生读片本身快，真正耗时的是写 SOAP note——Subjective（主诉）、Objective（客观发现）、Assessment（评估）、Plan（计划）四段。一份报告医生要敲 12 到 18 分钟。他说：「我们医生下班前都是先读完片，然后吃晚饭再回来写报告到晚上 9 点。」

这个项目我做了 6 个月，中间合规过了 3 次。最后跑到生产上，单份报告生成时间 2 分 40 秒（含医生确认），医生日均多看 27 个案子。下面写核心架构和关键取舍。

为什么选 Claude 而不是 open weight 自托管

这是项目最早期就要定的路线。医疗数据涉及 HIPAA，三条路：

路线 A：用 OpenAI / Anthropic 的公开 API——直接被否，HIPAA 合规缺 BAA（Business Associate Agreement）就是违规。

路线 B：自托管 open weight 模型（Llama 3.3 70B 这种）——合规上没问题，数据完全在自己机房。但要投 A100 集群、招 MLOps 工程师、做监控和 eval，年成本估算 $340K。

路线 C：用 Claude 走 AWS Bedrock。Bedrock 提供 HIPAA BAA，数据不出 AWS，合规层面等同于自己机房。年成本估算 $52K（API 调用 + S3 + 一点运维）。

CTO 选了路线 C。他原话：「我们 12 个医生的中心，养不起 MLOps 团队，但 Claude 的医学推理能力又是必须的。」

这里有个关键细节：不是所有 Claude 模型都自动享受 Bedrock 的 HIPAA 覆盖，要走 Anthropic 的企业协议或 Bedrock 的 BAA 产品。他们具体怎么签的我不参与，但工程架构是围绕这个合规前提搭的。

架构：语音 → ASR → 结构化模板 → 4 段 SOAP

医生读片的习惯是边看边说（dictation），不是先写字再整理。所以入口是语音。

完整链路：

1. 语音输入：AWS Transcribe Medical（专门的医学 ASR，识别肿瘤、结节、解剖部位这些词比通用 ASR 准很多）
2. 实体抽取：Claude Haiku 抽出关键实体（部位、大小、形态、对比既往片）
3. 结构化模板：按影像类型（CT/MRI）和部位（胸部/腹部/颅脑……）调不同模板
4. SOAP 4 段生成：Sonnet 按模板生成四段报告
5. 医生确认：医生在 UI 上看生成结果，可编辑、确认或重做
6. 审计日志：每一步调用、每一次编辑都写审计日志（HIPAA 要求）

模板这块我做得比较细。不同影像类型的 SOAP 结构差别很大——胸部 CT 的 Objective 段要覆盖肺叶、纵隔、胸膜、骨结构四个部分，颅脑 MRI 要覆盖幕上、幕下、脑室、白质、血管五个部分。我做了 23 个模板，覆盖他们 94% 的日常业务。

合规：三条红线

红线一：PHI（受保护健康信息）隔离

每个客户的工作流完全独立：

• 独立 AWS account：不同客户在不同的 AWS account 下，物理隔离
• 独立 Bedrock project key：每个 account 配独立的 Bedrock key，账单、访问日志都分开
• 独立 S3 bucket：病历、语音、生成报告分别在不同 bucket，带 KMS 加密和 bucket policy 限制

这样即使出事，blast radius 也只限在单一客户。

红线二：敏感信息脱敏

生成 SOAP 时，模型只拿影像发现，不拿患者姓名、生日、SSN 这些。脱敏层在 prompt 注入前跑，把 John Smith, DOB 1967-03-14 这种替换成 [PATIENT]。生成完之后再反向替换回去，贴到医生 UI 展示。

模型本身永远看不到 PHI。这是合规审计时最关键的一条。

红线三：审计日志 + 可追溯

每一次模型调用记一条 audit log：调用时间、医生 ID、患者 ID（加密后的）、输入 hash、输出 hash、模型版本、延迟、token 消耗。

医生的每一次编辑也记录（原文 → 改后）。这些日志保留 7 年（HIPAA 要求）。

审计日志这块我没用 Claude，就是传统的日志系统。但写日志的时机跟 Agent 生命周期绑死，这个在 Agent SDK 生产部署 里讲过。

医生反馈闭环：错误标记 → prompt 微调 → 版本灰度

这个项目跟普通 Agent 最大的区别是：医生不能接受明显的错误。

一个漏诊或误诊，就算再小概率，都可能变成医疗事故。我做的是让模型的边界充分暴露给医生，让医生做最终决策。

具体做法：

生成的每一段带 confidence：模型输出时要求标注「Objective 段 - confidence: high/medium/low」。Low confidence 的段落 UI 上会飘黄，提示医生重点审核。

标记错误 → 回流：医生确认前会勾选「正确 / 需修改 / 明显错误」。被标「明显错误」的案例每周回流一次，我人工看一遍，如果是系统性问题就调 prompt，调完之后灰度 10% → 50% → 100%。

灰度用的是简单的 feature flag，版本切换在 Claude 模型 ID 层面：claude-sonnet-4-6 → claude-sonnet-4-7。不同医生可能跑在不同版本上，审计日志能追溯。

这个闭环做了 6 个月，系统误差率从 4.7% 降到 0.8%（医生标「明显错误」的比例）。

模型选型：为什么用 Sonnet 不用 Opus

最早我想全用 Opus，医生建议太专业，Sonnet 会不会 hold 不住。跑了两周对比：

• Sonnet 4.7：SOAP 生成质量评分 4.3/5（医生盲评），单份成本 $0.018
• Opus 4.7：质量评分 4.5/5，单份成本 $0.094

差 0.2 分，但成本贵 5 倍多。医生讨论之后决定用 Sonnet，关键理由是「再好的 AI 我们也要人工审核，那 Sonnet 足够了」。

只有在一种情况下用 Opus：复杂多病灶案例（比如多发转移瘤），Haiku 前置分类判断为复杂，自动升档到 Opus。这类案例占 6%，单独走一条链路。这种分级思路我在 Claude 家族选型 里写过。

成本账

月均 9600 份报告（320 × 30），3 月账单：

• Bedrock Claude 调用：$1427.18
• Transcribe Medical：$487.32
• S3 存储：$96.44
• 其他（Lambda、CloudWatch）：$38.17
• 总计：$2,049.11

单份报告综合成本 $0.21。对比医生时间：医生人力成本大约 $2.4/分钟，原来一份报告 14 分钟 = $33.6，现在 2 分 40 秒 = $6.4，净节省 $27.2/份。月度净价值约 $261K。

Prompt caching 这里发挥很大，23 个模板都做了 cache，23 个模板的 system prompt 加起来 180K token，cache 命中率 83%。Prompt Caching 深度指南 有完整配置。

踩过的其他坑

坑一：医学术语。ASR 识别「pneumothorax」（气胸）有时会识别成「new motor x」。我加了个医学术语 post-processor 做拼写纠正。

坑二：单位不一致。同一个 CT 报告，「5 mm」和「0.5 cm」混用。模板里统一强制成 mm。

坑三：对比既往片。放射科医生很看重「对比 2024-08-12 片，结节无明显变化」这种话，得让 Agent 能拉历史报告做对比。这涉及跨报告的 context，我用了类似 长期 Agent 记忆 的结构，每个患者维护一份压缩后的既往发现摘要。

坑四：法律措辞。医生不能说「没有肺癌」，必须说「未见明显恶性征象」。这种措辞模板里写死了，Claude 不允许自由发挥。

医生的反馈

上线 4 个月之后，我去现场回访。一个资深放射科医生跟我说：

以前下班前最怕写报告，现在下午 5 点基本能走。我反而有时间多看几个疑难病例了。

CTO 给我看他们排班数据：医生日均读片量从 24 份涨到 51 份，多看的这 27 份里有 4 份查出了需要进一步复查的病灶——按他们的口径，这 4 份就可能是救命的。

这个项目让我对医疗 AI 的想法变了。真正的价值不是替代医生，是把医生从打字员解放出来做他们该做的判断。