先把资料形成与资料访问分开
讨论区块链医疗合作时，不能只问资料是否已经上链。接收方还需要知道收到的是哪个版本、经过了什么转换，以及相关访问是否有记录。把这些问题混成一个时间戳，容易得到一条看似完整、实际无法解释业务过程的记录。
本文采用HL7发布的FHIR R4 4.0.1文档作为阅读范围，不把它称为最新版本。FHIR是医疗信息交换规范，不是区块链协议。下文的协作流程是用于理解数据关系的假设案例，不代表任何医院已经采用，也不讨论诊断、治疗或疗效。
Provenance解释这个版本怎样形成
Provenance关注创建、修订、删除或签署某个资源版本的活动，以及参与活动的主体和所用资料。它通过target关联目标资源，还可以记录活动发生时间、记录时间和相关参与者。因此，知道一份资料来自哪里，不只是保存一个机构名称。
例如，假设机构甲将一份资料转换为双方约定的格式，再交给机构乙。整理来源关系时，可以分别记录转换前资料、转换活动和输出版本，避免把甲的原始记录与转换后的副本当成同一件东西。若判断依赖具体版本，引用也应能明确区分该版本。
AuditEvent解释系统发生过什么事件
AuditEvent侧重事件审计。R4文档列出的范围包含读取、查询等资料操作，以及登录、访问控制决定等系统事件；其结构可以表达事件类型、发生时段、记录时间、参与者和结果。一次读取没有修改资料，也仍可能形成需要保留的事件记录。
同一个协作过程可能由发起端、服务端等不同参与方分别记载。文档指出，出现多条相关审计记录是正常现象。整理时不宜因为时间接近就直接删除所谓重复行，而应先核对它们记录的是同一环节，还是不同系统观察到的各自环节。
链上记录不能替代业务对应关系
在一个假设的多方协作方案中，共享账本可以被讨论为记录某项版本指纹的候选组件。但原始资料、指纹、来源记录和访问记录仍是不同对象。即使指纹能够对上，也不能仅凭这一点推出原始内容准确、访问理由充分或共享范围适当。
以一份后来更正的资料为例，接收方需要知道旧版本与新版本的关系，而不只是再次看到同一个文件名称。本文建议把版本替换关系与接收确认分开记录，并保留原始资料系统的检索线索；这是一种资料组织思路，不是FHIR强制的区块链部署方案。
验收时用四个问题检查记录是否够用
可以用不含真实患者信息的虚构记录做一次桌面核对：能否定位目标版本，能否说明形成过程，能否区分访问成功与失败，能否追到记录它的系统。只要其中一项说不清楚，就应先补齐数据关系，而不是通过增加记录条数宣称协作能力已经完成。
还要区分审计原始数据与面向业务人员的报告。R4文档说明AuditEvent通常服务于审计与系统管理，其原始内容并非默认向所有医疗用户开放。使用某个标准本身也不等于满足全部隐私要求；真实项目的数据范围、访问授权和保留安排仍需另行论证。