审计与操作日志
复杂业务系统里的审计通常包含两类：业务操作审计和内容变更留痕。DirectSurface UI 提供命令、上下文、病历编辑器留痕和调试日志能力，但最终审计口径需要业务系统定义。
两类记录
业务操作审计记录用户动作：
- 打开患者。
- 保存文档。
- 提交审核。
- 接受或退回任务。
- 打印、导出或删除。
内容变更留痕记录文档内容变化：
- 插入文本。
- 删除文本。
- 修改数据元值。
- 修改批注内容。
- 锚定内容发生变化。
这两类记录的保存位置、展示形式和合并策略可以不同。业务操作审计通常进入服务端审计表，内容变更留痕通常跟随文档或业务对象保存。
何时产生审计
框架不强制“实时审计”或“保存时审计”。推荐按业务状态决定：
- 草稿未保存阶段：可以只保留本地编辑状态。
- 已保存但未归档阶段：是否留痕由业务配置决定。
- 归档后修改：通常需要开启留痕和操作审计。
- 上级医生批注或质控意见：建议写入独立意见记录，并保留处理状态。
编辑器侧只根据业务传入的开关决定是否启用留痕。是否启用、何时保存、如何归并，应该由业务状态控制。
病历编辑器中的具体开关、批注状态、审阅侧栏和锚点状态说明见 病历编辑器接入。
批注与修改记录
批注不是简单文本框。它通常代表一次沟通或质控意见，应包含作者、时间、状态、内容、处理记录和锚定关系。
建议规则：
- 新建批注时先创建意见草稿。
- 同一次打开批注框内的连续编辑，不必每个字符都生成审计。
- 批注框失焦或用户确认时，再生成一次修改记录。
- 批注关联的正文被修改后，应标记锚定内容变化，而不是默默失效。
这样既保留医疗信息追溯能力，又避免审计项膨胀到不可读。
与命令系统结合
命令可以成为操作审计的统一入口。按钮、菜单和快捷键都走命令后，业务服务就能统一记录动作来源、命令编号、操作者和页面上下文。
不要把所有低层输入事件都写成业务审计。键盘输入、鼠标移动、hover 这些事件通常不是业务审计对象。它们最多进入调试日志，不应进入正式审计表。
展示建议
审计展示要服务医生和管理人员，不是展示所有技术细节。
- 对医生：展示谁改了什么、意见是否处理、是否需要响应。
- 对质控：展示关键节点、责任人和处理状态。
- 对开发：通过对象查看器和运行时诊断查看技术状态。
正式 UI 和开发诊断 UI 应分开，避免把调试信息暴露给业务用户。