有人问病历被谁看过，我不能只拿出一条登录记录。

一项资料访问需要回查，日志却只写着某个服务账号在上午登录成功。那次操作究竟由谁发起，助手查了哪些记录，整理后的内容有没有再发到其他服务，单靠这条日志都回答不了。系统能运转，与事后能解释发生了什么，是两件事。

如果院内审计网关已经完整覆盖这些问题，应直接使用已有证据。需要补充的通常是几个系统之间的断点：聊天入口知道提问者，旧系统只知道共享账号，外部处理服务又使用另一套请求编号。多存几份日志，不会自动把它们连起来。

假设一个获准助手代工作人员查询检查进度。可以在请求进入时记录经认证的工作人员身份与用途，在受控查询函数中关联 EasyNet 的调用标识和旧系统事件编号。EasyRemote 提供的调用上下文能参与这条关联；谁是实际工作人员，仍要通过医院已有身份系统确认，不能采用模型自行填写的姓名。

查询程序应记录实际执行的查询范围和输出去向，而不是只记录“请求查进度”。若还调用了另一项汇总服务，就继续保留父子请求关系。这样审查人员有机会从一次提问追到原系统操作；未接入记录的下游仍是证据缺口，需要直接标明。

记录也会成为敏感资料。通常应优先保存必要的标识、范围和状态，原文证据留在获准位置，并单独控制谁能审查。调用收据能说明某次运行事实，却不能替代业务访问日志，更不能仅凭它断言整条链已经满足医院的审查要求。

验收时不要只展示一次成功查询。让一名无权人员发起请求，再模拟旧系统超时，看审查人员能否区分“被拒绝”“已经读取但后续失败”和“没有足够记录判断”。能如实重建这些不同情况，才比一页全是绿色成功状态的演示更接近实际需要。