收到材料不等于已经决定赔付
讨论区块链技术与保险理赔，可以先把流程拆成四种记录：报案接收、损失材料、处理决定和支付回执。本文构造的是多机构协作的数据模型，不宣称任何保险公司已经部署它。四类记录即使使用同一个案件编号，也不能因为前一项完成，就自动把后一项状态改成完成。
美国保险监督官协会在二〇二二年的房屋保险理赔说明中指出，理算人员会核对保单、免赔额及保障限额，并计算损失。这份美国消费者资料说明了损失材料与合同条件都要考虑；本文不把它当作中国保险规则，也不推定其他险种采用相同手续。
案件编号负责关联，材料版本负责定位
设一个完全虚构的案件，上午收到受损物品清单，下午补交一张维修估价单。记录可以分别保存接收时间、提交方、文件版本和所对应的案件编号，再由评估记录指向实际采用的材料。若估价单后来被修订，新版本应有自己的标识及修订说明，不能让查询者误以为早先决定已经看过后来的内容。
处理决定还需要明确适用的保单版本、已考虑的材料以及仍有争议的事项。支付回执则连接具体决定和对应款项。上述字段是本文提出的整理方法，不是通用法定表格；它的作用是让不同环节能够相互核对，不能替评估人员认定损失金额或承保责任。
共同核对记录不要求人人看到全部原文
Hyperledger Fabric 的私有数据文档区分了两个部分：实际数据只分发给获授权组织，相关哈希则进入同一通道各节点的账本。实际私有数据通过节点间通信传送，排序服务不接收这些内容。这为协作模型提供了技术参考，但是否采用、哪些机构有权读取，仍要根据真实业务另行设计。
在假设案件中，照片、联系方式和详细估价可以保留在受控材料区域，其他参与方只接触其职责所需的记录。后来获准读取材料的人，可以按约定核对版本及哈希。哈希相符支持的是所拿到材料与记录之间的对应关系，不能单独证明照片反映的损失真实，更不能自动证明某项费用应获赔付。
结案状态与款项明细还要分别保存
同一份美国协会说明指出，房屋理赔可能分多次支付，用途也可能不同。因此，模型不宜只保留一个已付款开关；可让每份回执说明对应决定、款项类别和支付状态。这是从机构资料得到的建模启发，不据此断言每份保单都必须分期付款，也不把支付金额直接等同于最初提交的损失估计。
材料保存也不能只看账本是否仍有哈希。Fabric 文档说明，私有数据可以按安排清除，而哈希仍留在链上；清除后，原文的可查询性会改变。项目应另行明确材料由谁保存、需要多久以及争议时如何提供。只有把资料可用性、处理依据与款项记录一起设计，留痕才方便核对，而不会被误读成自动赔付承诺。