三个失败，同一个缺口

在《从这里开始》里我说会回顾去年 Medium 文章里写错的地方。这篇就是那个回顾。

去年夏天我写：医疗 AI 卡住有三个原因——数据碎片化、审计缺失、激励错位。十个月过去，这三个问题我还是认的。但我不再觉得它们是三个问题。它们是同一个问题的三个症状。

去年夏天说了什么#

Medium 那两篇是在诊断。给问题取名字，提出各个击破：数据碎片化——靠更好的集成；审计缺失——靠更好的日志；激励错位——靠更好的经济模型。三个问题，三个方案，三条线。

我花了十个月试着解决它们，主要是通过一个叫 HAVEN 的协议和一个跑在 MIMIC-IV 上的参考实现。十个月下来我发现，名字取错了。不是症状错了，是病因只有一个。

这三个失败，你真去想怎么修，都指向同一件事：一层基础设施，目前在医疗行业哪都没有。不在某个应用里，不在某条法规里，不在某个平台里。一层夹在数据和用数据的东西之间的东西，由大家共同治理，不被任何一方独占。

医疗行业没建这一层。三个失败之所以顽固，是因为所有可能建它的人都在错的层级上忙活。

三个失败的共同点#

想想每个失败到底需要什么才能修。

数据碎片化是协调问题。每家医院的电子病历存一部分，每个消费级健康 app 存一部分，每个研究数据集是某个机构某个时间点的快照。修这个不是要更好的存储，是要让各部分能互相指向——跨越互不信任的系统，仍能被验证为同一条记录。

审计缺失是协调问题。审计日志放在被审计系统里面，只有这个系统的管理员能审。要可信，审计必须在管理员够不到的地方也能看到。这意味着要在本来没理由合作的各方之间协调。

激励错位是协调问题。患者出数据，研究者用数据，结果谁都没直接拿到。要对齐，得跨这条链追踪价值。链上没有任何一方有资格代表所有人追踪。大规模的价值归因，就是在没有共同管理员的系统之间做共享记账。还是协调，只是层面不同。

三个失败，同一个形状：都是没有共同管理员的各方之间的协调问题。现在医疗基础设施里有四个层试过做这种协调：应用层、监管层、平台层、标准层。每个都试过，每个都有自己的局限。

为什么这四层都不行#

应用层：协调不了#

今天大部分患者数据基础设施是应用层的。MyChart 管一家医院系统的病历访问，Pillpack 管药，Apple Health 存手机传感器数据。每个都有同意界面，有日志，有某种价值模型——哪怕"免费"也是模型。但它们之间不协调。在一个 app 里给的同意，另一个 app 看不见。一个 app 的审计日志，另一个 app 审不了。一个 app 里攒的价值，跨不到另一个。

你可以在一个 app 里做出最好的同意流程，但在真问题上还是会失败——因为患者不只用一个 app。患者用几十个。数据散在几十个系统里。应用层在定义上就协调不了它不包含的应用。

这不是更好的应用能解决的问题。需要的是应用可以站在上面的一层，就像 HTTP 服务器不用重新实现 TCP。

监管层：滞后#

HIPAA¹ 1996 年划的隐私边界，那时候患者数据还不是 AI 训练素材。问"谁能用这条记录训练模型"，它很难回答，因为训练不像 HIPAA 设计来管的那种披露。

GDPR² 2018 年加了删除权。删除权对数据库里的记录说得通，对已经编进模型权重里的记录就说不通了。法条里有这个权利，执行机制不存在。

21 世纪治愈法案³和后续的 ONC 互操作规则（2020–2022）要求患者能通过标准 API 拿到自己的病历。拿到数据是主权的前提，不是替代。能拿到和对拿到之后怎么用有权利，是两回事。

这些法规的共同点是：回应的是起草时看得见的问题。等法规生效，技术已经造出新问题。法规的带宽在结构上低于技术，所以法规赶上之前建起来的东西会继续跑、继续抽价值，不会被后来的法规撤掉。修复得先于法规存在，不然就没法存在。

平台层：变成另一种垄断#

平台是最近的尝试。Apple Health Records 2018 年⁴跟 12 家医疗系统合作上线，现在接了几百家。Google 在医疗数据上试过四次（Google Health 2008–2011、Google Fit、DeepMind Streams、Cloud Healthcare API）⁵，每次都关了或者转向了。电子病历厂商的患者门户在医院系统范围内也像平台。

这些平台在狭义上有效——数据确实在流。但没解决主权问题，是把主权集中了。Apple 成了统一患者数据层的管理员，患者就不是主权者了——Apple 是，患者成了用户。电子病历厂商当管理员，医院系统就成了主权者。主权被中介化，这是主权的反面。

平台不是坏东西。它只是不是修复所在的那一层。

标准层：管的事不够#

医疗行业有认真的协议层尝试。HL7 v2 1989 年⁶标准化了临床消息交换。HL7 FHIR 2014 年以来⁷标准化了 RESTful 临床数据访问。OMOP 通用数据模型⁸规定了跨机构观察研究数据的结构。SMART on FHIR⁹标准化了临床 app 的授权。

这些是真的协议层胜利。但不是缺的那个修复需要的胜利。

这些标准管的是数据怎么走。FHIR 规定怎么取记录，不规定取的人能不能拿它训练模型。OMOP 规定诊断怎么编码，不规定谁能访问队列、欠队列里的患者什么。SMART on FHIR 规定 app 怎么认证，不规定 app 的输出用于医疗时患者该得到什么。

标准层管的是数据格式。缺的那个修复要管的是数据用途。两者互补：治理协议跑在 FHIR 格式的数据和 OMOP 建模的队列上。但那些标准没提供治理本身。

"协议层"是什么意思#

协议是一组规则，参与者自愿遵守，没有任何一方拥有这些规则或存这些规则管的数据。SMTP 1981 年¹⁰让跨机构的邮件成为可能——不是因为贝尔实验室托管了邮件，是因为大家同意了怎么寻址。HTTP 1991 年¹¹让跨服务器的网页成为可能——不是因为 Tim Berners-Lee 托管了网页。DNS¹²让命名成为可能，没有统一的注册处。

每次协议层成功，都是因为它让跨系统的行为成为可能——这是任何单一管理员都提供不了的。每个协议都被发布、被使用、被认可，在没有任何一方能撤销它的情况下运行。电子邮件活过了四十年的厂商整合，因为协议比厂商老。

医疗数据没有这一层。有整合的应用。有约束披露的法规。有中介的平台。没有关于记录是什么、同意是什么意思、审计包含什么、价值怎么归因的共享规则。这些问题现在是应用一个个答、法规一条条答、平台一个个答。

赌的是：患者主权医疗数据的协议层可以像 SMTP 和 HTTP 那样运作。不是因为它比某个应用更好地解决那个应用的问题，是因为它让一类协作成为可能——没有它这类协作就不可能发生。赌的还有第二层：这层现在可以建，在法规强行推一个更差的版本之前，在任何一个平台把这片地盘圈完之前。

接下来四篇要讲什么#

如果缺的是协议层，那下一步就是说清楚这个协议得提供什么。不是"同意和审计"这种空话，是具体的原语，每个有具体的职责。

下一篇论证四个原语扛得住：内容寻址的健康资产、可编程同意、哈希链溯源、质量加权贡献。每个对应这里说的一个失败。我的主张不是这四个一定是最小集。设计空间不接受那种证明。我的主张是每个原语针对一个具体的失败模式站得住，而且这四个自然地聚在一起，不是硬凑的。

这比"最小充分"软一点。是我能守得住的那种主张。看到自然的第五个原语的读者可以写信来。这个系列经得起压力测试会更好。

我低估了什么#

去年夏天写 Medium 文章的时候，我以为这个领域需要更好的工具。现在我觉得需要的是一层这个领域还没建的东西。这是一个比我当时说的更难的问题。

在缺失的层里造更好的工具，是跑步机。

下一篇讲规范。再后面两篇讲规范过程中冒出来的缺口——这些缺口变成了单独的工作，因为它们在不同的验证体系里。第五篇承诺什么会证明整个论证是错的。