Ambient Scribe 接入 EHR：如何审计 AI 生成病历草稿

Ambient Scribe 的链路不复杂：诊室录音，ASR 转写，LLM 按 SOAP 或院内模板生成病历草稿。演示时容易关注“写得像不像”，真正接入 EHR 后，系统更该追问：这句话从哪里来，谁看过，谁改过，谁确认过。

如果只落一份 final note，后续追溯会很困难。比如“胸痛缓解”是患者原话、ASR 结果，还是模型归纳？“依从性差”是医生判断，还是模型把“有时忘了吃药”改成了更强表述？医生签名覆盖整份 AI 草稿，还是只覆盖已确认段落？这些问题不能靠事后口头解释。

图1：AI 生成病历旁叠加医生红色修改痕迹

先拆对象，再写入 EHR

一条可审计链路，至少要拆出几类对象：

对象	FHIR 中的可能落点	需要记录
audio / transcript	DocumentReference	采集时间、访问权限、保留策略
draft note	Composition draft	模型版本、prompt 版本、生成时间
section diff	Provenance	修改范围、操作者、前后版本 hash
final note	Composition final	确认时间、签名时间、写入位置
操作日志	AuditEvent	查看、编辑、退回、签名、更正

不同医院的 EHR、FHIR profile、权限和留存制度差异很大，不必强行套同一个模板。但“草稿、修改、确认、签名”不要混在一个字段里，否则后续质控、编码、纠错都会变成猜测。

图2：泳道图——患者就诊、录音、ASR、LLM、医生确认、EHR 写入、编码质控

UI 不要只剩“保存”

只给医生一个“保存”，等于让医生为整份 AI 草稿背书；逐句弹窗又会打断诊间节奏。更现实的做法是按段确认：主诉、现病史、评估、计划、用药、随访分别展示状态；高风险句子高亮；医生编辑后自动展开 diff；确认后再进入签名。

状态流可以先做成这样：

generated -> reviewed -> edited -> attested -> signed
                              \-> returned
signed -> amended

generated：模型生成草稿
reviewed：医生已查看
edited：医生修改过
attested：医生确认某一版本
signed：正式签名
amended：签名后更正

另外，addendum 和 amendment 不建议混用。前者偏追加说明，后者是修改既有内容，审计展示和权限控制通常不同。

一个最小字段示例

下面是模拟结构，只用于说明审计设计，不代表真实患者数据或真实系统日志：

{
  "note_id": "sim_enc_001",
  "section": "assessment_plan",
  "state": "edited",
  "source": {
    "audio_ref": "DocumentReference/audio_003",
    "transcript_ref": "DocumentReference/asr_v2",
    "draft_ref": "Composition/llm_draft_v1"
  },
  "provenance": {
    "agent": "ambient_scribe_llm",
    "model_version": "2026-05-01",
    "prompt_version": "soap_prompt_12",
    "generated_at": "2026-05-20T10:25:00Z"
  },
  "doctor_action": {
    "user_id": "Practitioner/17",
    "action": "edit_and_attest",
    "diff_range": ["sentence_4", "sentence_7"],
    "attested_at": "2026-05-20T10:31:22Z"
  },
  "ehr_target": {
    "resource": "Composition",
    "field": "section.assessment_plan"
  },
  "audit_event": "AuditEvent/sim_note_001_edit_003",
  "boundary": "documentation_audit_only"
}

字段名可以按院内规范调整，关键是能回答四个问题：模型生成了什么，医生改了什么，医生确认了哪个版本，最终写进了 EHR 哪个位置。

文献检索要变成测试项

调研 Ambient Scribe 时，文献检索不能只停留在“查过”。可以用 PubMed 直接跑一个可复现 query：

("ambient scribing" OR "AI scribe" OR "clinical note generation")
AND ("electronic health record" OR EHR)
AND ("physician documentation burden" OR "clinical documentation")

OpenAlex 可用类似关键词组合，再按年份、文献类型、被引量筛选。也可以用超能文献做中文问题入口，整理 PubMed、OpenAlex 来源中的部署场景、样本量、错误类型、医生编辑负担和签名耗时。这里只把它当文献入口和证据管理工具，不用于生成真实病历，也不提供诊疗建议。

研发排期里应落下这些测试项：是否统计段落级编辑时间，错误集中在哪类句子，风险提示是否改变医生行为，编码或质控能否回溯到原始来源。

先做 50 条模拟审计集

别急着调 prompt。先拿 50 条模拟就诊记录，标注 audio / transcript / draft / final note 的对应关系；跑通 generated / reviewed / edited / attested / signed / amended 状态；做一版段落确认 UI，让医生完成签名、退回、补录、更正四个动作。

最后记录三类指标：每个动作多花多少秒，哪些风险句子被漏看，哪些字段无法追溯。等这些问题回答清楚，再决定 Ambient Scribe 应写入 EHR 的哪一层。

注：本文的文献收集、分析处理、文献翻译，采用超能文献(suppr.ai)

posted @ 2026-05-20 16:43 JaxGo 阅读(47) 评论(0) 收藏举报

刷新页面返回顶部

JaxGo