一、防篡改是否等于病历真实
不等于。记录是否发生变化，与记录最初是否准确，是两个不同问题。即使一份记录能够验证来源，也不能仅凭技术验证认定其中的诊断、检查结果或身份信息正确。
W3C《可验证凭证数据模型2.0》明确区分“可验证”与声明真实。用于病历场景时，仍需判断签发者是否可信、记录对应谁，以及内容是否适用于当前业务，不能把验签成功当作医学内容正确的证明。
二、信息可验证是否意味着隐私安全
不意味着。W3C指出，数字信息的持久保存与跨来源关联可能加重隐私风险。病历系统因此需要分别考虑“能否核验”和“应该披露多少”，而不是为了方便核验就展示全部信息。
例如，核验某项证明时，应先明确接收方需要哪些内容。即使没有直接展示姓名，反复使用的标识也可能成为关联不同记录的线索。隐私保护需要贯穿数据表达与交换过程。
三、谁可以查看、修改或授权
以太坊智能合约安全文档强调，敏感操作需要明确的访问控制。映射到电子病历场景，查看记录、提交补充内容、调整授权与管理系统，不应被视为同一种权限。
还需区分合约操作权限和病历内容的保密措施。限制某个函数的调用者，并不等于所有相关数据都已得到保护；身份认证、数据访问与授权变更需要分别设计。
四、管理员密钥出现问题怎么办
上述安全文档指出，单一管理员账户可能形成单点风险；角色分工和多签可为敏感操作增加约束。但这并不意味着参与者越多就必然越安全。
用于病历系统时，需要预先明确账户失陷后的停用、权限移交和恢复流程。重要管理操作可以设置多人确认，但不宜未经评估就把同样流程套用到每一次正常读取。
五、合约有漏洞或记录需要纠正怎么办
智能合约部署后的修复可能受到约束，独立审查和测试也不能保证发现所有漏洞。因此，采用合约管理病历授权时，应提前考虑异常暂停、修复与升级的责任边界。
病历内容纠正与合约程序修复同样需要区分。系统设计应说明如何标记错误版本、关联补充记录，以及让使用者识别当前有效内容，避免将“保留历史”误解为“错误无法纠正”。
六、跨机构使用是否必须依赖区块链
不必须。W3C列举的可验证数据注册机制既包括分布式账本，也包括可信数据库。可验证凭证与区块链并不是必须绑定的技术。
即使记录能够交换，机构之间仍需约定字段含义、签发者信任规则与验证要求。上述问题适用于通用技术设计，不代表某个具体电子病历平台已具备相应能力；是否采用区块链，应围绕实际协作需求判断。