跳转至

AI 病历行为数据记录与训练闭环方案

  • 保存时间：2026-02-25
  • 来源：与助手对话记录（用户要求保存）

核心结论

这个场景（AI 病历编辑 + 可回放 + 可用于训练）本质上不是“前端埋点”问题，而是系统级“行为事件 + 状态版本”数据架构问题。结论：用 Event Sourcing（事件溯源）+ 审计日志 + 状态快照（SCD2/版本表），前端埋点只做补充，不做主数据源。

1) 为什么前端埋点不够

  • 只能看到页面行为，看不到后端真实落库结果
  • 容易丢失（网络、SDK、拦截、离线）
  • 无法保证修改前后状态完整一致
  • 医疗审计要求高（谁在何时改了什么、为什么改）

因此：以后端写入链路为准，前端行为为辅。

2) 总体方案

三层数据

  1. 业务主表（当前态）
  2. medical_record（仅最新状态，用于在线查询）
  3. 事件表（行为事实）
  4. record_events（append-only，不更新不删除）
  5. 记录：谁、何时、对哪个实体、做了什么、前后差异、来源
  6. 版本快照表（历史态）
  7. record_versions（关键变更落版本，支持回放/审计/训练抽取）

事件模型建议字段

  • event_id（UUID）
  • entity_type / entity_id
  • event_type（created/updated/status_changed/ai_suggested/ai_accepted/ai_rejected）
  • actor_type（doctor/patient/ai/system）
  • actor_id
  • timestamp
  • request_id / trace_id
  • source（web/app/api/batch）
  • before（JSON）
  • after（JSON）
  • diff（JSON Patch 或字段级差异）
  • reason
  • model_info（模型版本、prompt 版本、置信度）
  • phi_level / sensitivity_tag
  • schema_version

关键：before/after 必须在后端事务内读取并写入，保证一致性。

3) 写入链路（强一致）

  1. API 收到更新请求
  2. 开事务
  3. 读当前记录作为 before
  4. 计算 after 和 diff
  5. 更新主表 medical_record
  6. 插入 record_events
  7. 插入 record_versions
  8. 提交事务

有 Kafka 时可加 Outbox Pattern，先本地 outbox，再异步投递到流平台。

4) 训练闭环

从事件层构造训练样本：

  • 输入：AI 初始建议、上下文、用户画像（脱敏）、病历上下文
  • 标签：accepted / edited / rejected、编辑距离、最终质控结果
  • 产出：DPO/奖励模型、SFT 数据、离线评测集

补充： - 延迟标签（质量结果晚到） - 训练集版本化（按时间窗+规则版本固化）

5) 医疗治理要求

  • PHI/PII 脱敏（训练前流水线）
  • 最小权限（事件库与训练库隔离）
  • 样本可追溯（可追到事件 ID）
  • 保留期/可删除/审计导出策略
  • 传输与存储加密（含字段级）

6) 技术选型

早期（先跑通）

  • PostgreSQL（OLTP）
  • record_events 用 JSONB + 索引（entity_id, timestamp, actor_id）
  • 每日 ETL 到 ClickHouse/BigQuery

中期（规模化）

  • Kafka / Pulsar
  • Debezium（CDC）
  • S3 + Iceberg/Delta + Spark/Flink
  • MLflow/DVC 做训练集版本管理

7) MVP 落地清单

  1. 新增 record_events（append-only）
  2. 所有病历修改 API 统一事务内写 before/after/diff
  3. 增加 status_changed 专用事件
  4. 每日导出训练中间表（先脱敏）
  5. 先做三类标签：采纳/编辑/拒绝
  6. 做事件回放页（按病历 ID 看完整修改链）

如需继续：可补 PostgreSQL DDL、事件 JSON Schema、事务伪代码（Java/Node）、ETL SQL 模板。