主题 4.3 — 互操作性与数据标准

在医疗与照护领域,互操作性不是一种技术上的美德,而是一项临床安全与公平要求:当系统无法在照护现场以正确的形式、以明确的含义共享正确的数据时,人们会受到伤害,不平等会被放大。

为什么这在医疗与照护领域很重要#

一个人的照护很少发生在一个地方。单一一次病程可能触及一家全科诊所、一项救护车服务、一个急诊科、一个医院病房、一位社区护士、一家药房、一个社会照护团队,以及一位在家的照护者。每一个都持有记录的一部分。如果这些部分无法被安全、快速地整合在一起,临床医生就会在信息缺失的情况下做出决策:一种没有被看到的过敏史、一次重复开具的用药、一项不必要重复的检验、一个对需要它的团队而言不可见的保障工作标记。

互操作性正是把一组彼此断开的系统,转化为在患者看来表现得像一项连贯服务的东西。它是整合照护之下的基础管道。当它奏效时,一个机构的临床医生能够看到另一个机构记录了什么,并能信任它意味着他们所以为的意思。当它失效时,这种失效常常是无声的,直到有人受到伤害。

这也是一个公平问题。需求最复杂的人——虚弱的老年人、患有多种长期病症的人、在服务之间流转的人——恰恰是数据最碎片化的人。因此,糟糕的互操作性最沉重地伤害着最脆弱的人。这也是公众信任的问题:人们合理地假设 NHS 已经在明智地共享他们的信息,当发现事实往往并非如此时,他们会感到沮丧。

最后,互操作性保护着公共资金。无法交换数据的专有系统,把机构锁进昂贵、难以替换的合同,并迫使代价高昂的点对点集成。按开放标准构建,是你保持选择余地、让供应商保持诚实,并避免反复付费解决同一个问题的方式。

核心概念#

互操作性是不同系统交换信息并使用它的能力。把它区分为两层会很有帮助。句法或技术互操作性意味着两个系统能够交换一条消息,双方都能解析其结构——信封抵达了,能够被打开。语义互操作性意味着接收系统以与发送方相同的方式理解内容的含义——一个"青霉素过敏"的编码在双方那里的解读是一致的。没有语义互操作性的技术互操作性是危险的:数据在流动,但含义丢失或被扭曲了。

健康数据使用标准来交换。Health Level 7(HL7)是医疗领域使用最广泛的标准家族。它较旧的 HL7 第 2 版(v2)消息传递,使用竖线与脱字符分隔的文本,如今依然支撑着大量的医院消息传递,并将持续数年。它的现代标准 HL7 快速医疗互操作性资源(FHIR),把临床信息建模为通过网页风格应用程序编程接口(API)交换的"资源",这让现代开发人员的工作变得容易得多。

仅有消息标准是不够的;你还需要针对内容的标准词汇表。SNOMED CT(临床医学系统命名法——临床术语)是整个 NHS 照护范围内被强制要求用来记录诊断、症状、操作等的临床术语。NHS 药品与设备词典(dm+d)是药品与医疗设备的标准词汇表,支撑着电子处方。由世界卫生组织维护的国际疾病分类第 10 版与第 11 版(ICD-10 与 ICD-11),用于分类、统计与报销,而不是日常临床记录。openEHR是一份开放规范,通过共享的、临床治理的"原型"来构建健康记录本身的结构,被一些机构用来让临床数据模型独立于任何单一供应商。

还有两个理念是基础性的。NHS 号码是让关于同一个人的记录能够可靠地在各机构之间被关联起来的通用患者标识符;没有一个共享标识符,匹配就是靠猜测。而医疗企业整合(IHE)发布"配置文件",精确规定了如何组合既有标准来解决诸如共享文档这样的具体问题,让不同的供应商能以相同的方式实现它们。

支撑这一切的是一个战略选择。按照开放标准构建、拥有已发布的可复用 API,能保持一个市场的竞争性,让你的数据保持可移植。依赖专有接口会造成供应商锁定,更换供应商变得代价高昂到你实际上无法做到。然而,如果没有数据质量——准确、完整、及时、一致编码的数据——这一切都无法创造价值,数据质量是互操作性的前提条件,而不是事后补充。

最佳实践#

1. 区分语义互操作性与技术互操作性,并为两者而设计。 庆祝一条消息现在能在两个系统之间流动、却忽略了接收方临床医生无法安全地依赖其含义,这很容易发生。始终追问:对方对这些编码、单位与否定语的解读,是否与我们完全一致?投资于共享的术语体系(SNOMED CT、dm+d)与值集,而不仅仅是消息格式,因为一次被正确传输、却被误解的过敏史,比根本没有消息更危险。

2. 按开放标准构建,复用平台,而不是重新发明。 采纳这条被广泛认可的原则:按开放标准构建,并在构建自己的东西之前先复用既有的国家平台与服务。在 NHS,这意味着优先选择 HL7 FHIR API,使用 NHS 号码作为标识符,并连接到诸如 Spine、GP Connect 与共享照护记录这样的国家服务,而不是创建定制的点对点链接。复用能降低成本,分摊维护负担,并意味着你的数据能够流动。

3. 让 NHS 号码在每一份记录与每一条消息中都不容商量。 可靠的记录关联依赖于一个可信的共同标识符。确保 NHS 号码被捕捉、依据国家人口统计服务进行核验,并附加在每一份相关记录与接口上。在它缺失或未经核验的地方,把这当作一项需要解决的数据质量缺陷来对待,因为仅凭姓名与出生日期进行匹配,既会产生危险的错配,也会产生遗漏的关联。

4. 把数据质量当作一项头等交付物来对待。 互操作性会把你的数据质量问题输出给下游的每一个人。分析你的数据,衡量完整性与编码一致性,并建立管理机制,让错误在源头被发现并修复。编码漂移、本应结构化数据却用自由文本记录,以及不一致的单位,会悄悄地腐蚀每一个下游分析与临床视图,因此要明确地为这项工作提供资金,而不是假设它会自行发生。

5. 优先选择 API 优先、松耦合的架构,而不是紧耦合的集成。 设计使能力通过有良好文档记录的、有版本管理的 API 暴露,让其他人无需定制协商就能使用它们。这在一开始比一条直接的数据库链接更慢,但它是让你能够在不重建其周围一切的情况下替换一个组件的关键。它也与国家服务及现代供应商如今期望的集成方式相一致,并支持主题 3.5——交付生命周期中的交付方法。

6. 使用已发布的配置文件与合规性测试,而不是本地化的解读。 标准是灵活的,两个团队可能以不兼容的方式实现"同一个"FHIR 资源。采纳能够固定细节的国家实施指南与 IHE 配置文件,并要求供应商在上线之前对照它们展示合规性。合规性测试把"我们支持 FHIR"——一句本身几乎没有意义的声明——变成一个可验证的、合同性的事实。

7. 把互操作性与开放标准要求写进采购与合同。 避免锁定最廉价的时机是在你签约之前。要求开放的、有文档记录的 API、以标准格式提取自己数据的权利、遵守指名的标准,并对标准集成不收费。与你的商务同事合作(见主题 6.3——采购与商务),让这些成为强制性的评估标准,而不是日后被谈判掉的愿景。

8. 让临床安全与信息治理参与互操作性治理。 每一条新的数据流都会改变临床风险与保密信息的处理方式。从一开始就把临床安全官与信息治理负责人纳入设计决策,而不是作为最终签核,这样共享记录才能既安全又合法。这与主题 1.6——临床安全与风险管理和主题 1.7——信息治理、数据保护与网络安全直接相关。

与团队讨论的问题#

1. 在我们的照护路径中,缺失或被误解的数据如今在哪里造成了最大的临床风险? 互操作性投资应当跟随伤害与价值,而不是架构上的潮流。绘制出你最复杂的患者实际经历的旅程,找出信息丢失、延迟,或抵达时含义不可信的交接环节。追问临床医生在哪些地方常规地处于盲目工作状态——转移、非工作时间的缺口,以及卫生与社会照护之间的边界。区分数据根本不流动的地方,与数据流动但不可信的地方,因为这些需要不同的修复方式。考虑哪些人群受影响最大,因为碎片化往往最沉重地落在需求最复杂的人身上。这个答案会告诉你从哪里开始,并给你一个比任何技术论证都更有分量的临床安全论证。

2. 我们在供应商锁定方面暴露程度如何?更换我们主要的临床系统实际上要花多少代价? 许多机构只有在尝试离开一个封闭系统时才发现它的真实价格。具体地梳理以可用的、标准的形式提取你的数据、迁移到另一个供应商需要什么。审视你的合同,了解谁拥有数据、存在哪些标准接口,以及你是否为本应是常规操作的集成付费。识别出需要被解开的专有接口与数据格式。把这与替代方案的开放性,以及你本可以复用的国家平台相权衡。这不是在为频繁更换供应商辩护;而是关于理解你的筹码,减少一个单一供应商的路线图变成你唯一选择的风险。

3. 我们的数据是否足够好、可以安全地共享?我们要如何知道? 共享糟糕的数据不仅仅让你难堪——它会把错误传播进其他临床医生的决策之中。追问你是否真的衡量了你打算暴露的数据的完整性、准确性、及时性与编码一致性。讨论数据质量在你的机构中由谁负责,以及他们是否有时间与授权在源头修复问题。考虑有多大比例的记录携带一个经过核验的 NHS 号码,以及有多少临床上重要的信息仍然存放在自由文本中、而不是结构化字段中。想一想你要如何在一次系统性编码错误抵达一份共享照护记录之前侦测到它。如果你无法用证据回答这些问题,把这本身当作一个发现,并在扩宽管道之前为数据质量工作提供资金。

4. 当一位供应商说"我们支持 FHIR"时,我们在上线之前要如何真正核实它? 一个标准标签在被对照一份具体的实施指南测试之前,只是一种营销声明。讨论你的机构是否拥有自己的任何合规性测试能力,还是仅仅相信供应商的话。两个系统可能各自都"符合 FHIR",却依然无法交换一条可用的消息,因为这个标准被刻意设计得灵活,含义存在于固定它的配置文件与值集之中。追问哪些国家实施指南与 IHE 配置文件适用于这个特定接口,以及你这一方谁有能力阅读它们。考虑合规性是否作为连接的一项条件被写进合同,还是在集成过程中痛苦地才被发现。一个诚实的答案会说出你将对照测试的具体配置文件、将运行这项测试的人或职能,以及在时间线上一位不合格的供应商被拒之门外、而不是被放行的那个节点。

5. 在我们的机构中,标准、术语与合规性由谁拥有,他们是否有权说不? 互操作性如果没有专人管理就会腐化:值集会漂移,本地指南会分化,每一个新项目都会悄悄发明自己的解读。追问是否有一个具名的职能负责标准、SNOMED CT 与 dm+d 子集,以及合规性,还是这些知识存在于少数几个人的脑海中。考虑中央一致性与地方交付速度之间的张力——承压的团队会构建最快的东西,除非一个标准职能拥有要求复用的真正权力。讨论术语维护是如何获得资助的,鉴于它既不光鲜、又是持续性的,却让每个人受益、而不是任何单一项目。审视你如何在 FHIR、SNOMED CT 与国家指南演进时保持实现方式的一致,而不是冻结在你最初采纳的版本上。一个诚实的答案会指出负责任的负责人、他们的资金来源,以及一个近期他们要么强制执行了一项标准、要么未能强制执行的例子。

6. 我们正在整合起来的这些记录所属的人,是否被告知并对他们数据的流动方式感到满意? 互操作性不仅是一个技术与临床事项,也是一个关于公众信任与合法依据的问题。人们合理地假设 NHS 已经在明智地共享他们的信息,当它没有这样做、以及以他们未曾预料的方式这样做时,他们都会感到沮丧。讨论患者是否理解哪些机构能够看到他们的共享记录,一份国家数据退出选项或本地同意模型如何在整个流程中被遵守,以及访问是如何被记录与可审计的。考虑公平维度:数据最碎片化的人——那些有复杂需求的人——也是最没有能力驾驭退出选项与信息通知的人。把信息治理、以及在相关之处的患者或其代表带入设计,而不是把同意当作最后打的一个勾。一个诚实的答案能够描述每条数据流的合法依据、一个人将如何发现谁看过他们的记录,以及他们的选择在整个流程中是如何被端到端地尊重的。

实践中:一个医疗与照护案例#

英格兰北部的一个整合照护系统,在一次严重事故审查发现一位患者被两个无法看到彼此记录的团队分别开具了两种相互作用的药物之后,着手为临床医生提供一份跨全科诊所、医院与社区药房的共享用药统一视图。

诱惑是从一家供应商那里购买一个"用药仪表盘",直接把它连接进每个系统的数据库。互操作性负责人拒绝了这一点。相反,该项目采用了按开放标准构建的方法。每个源系统都把用药数据暴露为 HL7 FHIR 资源;每一种药物都用 dm+d 编码,这样"同一种药物"在各处的含义就是一致的;每一份记录都以一个经过核验的 NHS 号码为键,这样正确的用药就能附加到正确的人身上。全科医生的数据通过 GP Connect 提取,而不是一条定制数据流,复用一项国家能力,而不是发明一个本地方案。

早期的数据分析立刻证明了它的价值。一个诊所的系统一直在用自由文本、而不是编码的 dm+d 条目来记录某些药物,这意味着它们本会对任何自动化的相互作用检查而言是不可见的。这在上线之前就在源头被修复了。团队还发现了一批 NHS 号码未经核验的记录,把它们导向国家人口统计服务进行匹配。

临床安全官与信息治理负责人自始至终都是设计小组的一部分。他们共同精确地定义了哪些数据被共享、与谁共享、依据什么合法依据,以及一位临床医生的访问是如何被记录的——这正是主题 1.7——信息治理、数据保护与网络安全所关注的问题。供应商必须在连接之前通过针对国家 FHIR 实施指南的合规性测试。十二个月后,这份整合的用药视图已经上线,一次此前本会被遗漏的相互作用已经被捕获——而且,因为一切都是按开放接口构建的,第二个用例(共享过敏信息)以原始成本的一小部分复用了大部分同样的基础管道。

行业视角#

初创企业#

一家数字医疗初创企业的生死取决于它接入既有系统的容易程度,因此要把互操作性当作核心功能、而不是合规上的苦差事来对待。从一开始就构建 FHIR API、使用 SNOMED CT 与 dm+d,能让你更容易被采购与集成,并向审慎的 NHS 买家传递出成熟的信号。当一个标准已经存在时,要抵制发明自己数据模型的冲动;你的差异化应当是你的产品,而不是一种会变成负债的专有格式。及早把 NHS 号码处理与信息治理做对,正是让你能从试点走向采购的关键。设计得让一位客户原则上能够提取自己的数据并离开——矛盾的是,这种开放性正是赢得让他们留下的信任的关键。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院,或一家单一场所的诊所——承担着与最大信托机构同样的安全共享数据的职责,却只有一小部分技术能力。这里,互操作性主要是一门采购与配置学科,而不是工程学科:选择已经支持 FHIR 的系统,连接到诸如 GP Connect 与 Spine 这样的国家服务,并开箱即用地使用 SNOMED CT 与 dm+d 进行编码,这样你就继承了标准,而不是构建它们。让经过核验的 NHS 号码捕捉成为日常实践的一部分,因为没有集成团队在日后协调不匹配,在注册时就把标识符弄对是你最廉价的保障措施。依靠共享照护记录项目与你整合照护系统的共享基础设施,而不是委托你无法维护的定制链接。当你签署或续签一份系统合同时,坚持要求用平实的措辞明确数据提取权利与开放接口,因为一个小机构最深切地感受到供应商锁定,而且在事后最没有筹码去摆脱它。

大型企业#

一家大型提供者或供应商通常承载着数十年的遗留系统:HL7 v2 接口、多个电子记录系统,以及把这一切维系在一起的集成引擎。现实的策略不是把一切都拆掉重来,而是在这片资产之前铺设一层 API 优先的、基于标准的层,逐步把数据流迁移到 FHIR,同时在必须的地方保持 v2 继续运行。在每一次续约时都要严格防范锁定,并坚持要求合规性测试,让"符合标准"是被验证的、而不是被断言的。建立一个内部标准与合规性职能,这样各个项目就不会各自发明自己的解读。这与你在主题 5.4——企业资源规划(ERP)中管理核心运营平台的方式密切相关,同样的复用与开放接口纪律在那里同样适用。

政府机构#

国家与区域机构制定了市场的规则,因此它们关于标准的选择会波及每一个机构。政府能做的最有价值的事情,是强制要求开放标准、发布清晰的实施指南与合规性要求,并提供可复用的国家平台——Spine、GP Connect、共享照护记录框架、NHS 号码服务——这样地方机构只需构建一次、便可复用。一致性比完美更重要:一个被坚定强制执行的、足够好的标准,胜过一个理论上更优、却被每个人以不同方式实现的标准。政府还必须为术语维护与数据质量改进这些不光鲜的工作提供资金,因为这些是没有哪个单一机构会独自出资的公共物品。这种管理者角色与主题 9.1——与地方及中央政府合作,以及主题 9.0——与合作伙伴组织协作中合作伙伴如何协作相关联。

常见失败模式#

• 把技术连接与语义理解混为一谈。 一条消息开始流动时就宣告胜利,却没有确认双方对其编码、单位与否定语的解读是否一致。结果是看起来已整合、实则被悄悄误读的数据。
• 更快地共享糟糕的数据。 在修复数据质量之前就扩宽管道,导致编码错误、自由文本与缺失的 NHS 号码传播进其他临床医生的决策与每一个下游分析之中。
• "我们支持 FHIR"作为一句空洞的声明。 接受一个标准标签、却不对照一份具体的实施指南进行合规性测试,导致两个"合规"的系统依然无法相互对话。
• 定制的点对点集成。 在每一对系统之间构建直接链接,产生一张随着规模增长而维护成本呈指数级上升的脆弱网络。
• 默认的锁定。 签约带有专有接口、没有数据提取权利的合同,只有在尝试更换供应商时才发现这个陷阱的代价。
• 把治理当作最后一道关卡。 只在最后才引入临床安全与信息治理来签核,导致问题在后期、以高昂代价浮现,或在交付压力下被放行。
• 没有管理的标准。 采纳了术语与配置文件,却没有为维护值集、监测合规性,或在标准演进时保持实现方式一致而提供资金给任何人。

成熟度模型#

检查清单#

• 每一份相关记录与接口都携带一个经过核验的 NHS 号码,并有一个流程来解决缺失或未匹配的情况。
• 新接口使用 HL7 FHIR 与指名的国家实施指南,只有在尚未证明迁移合理的地方才保留 HL7 v2。
• 临床内容使用 SNOMED CT 编码,药品使用 dm+d 编码,对照商定的值集。
• 任何你打算共享的数据,其数据质量在管道扩宽之前已在源头被分析、衡量、拥有负责人并加以改进。
• 供应商在连接之前必须通过针对一份具体配置文件的合规性测试——"支持 FHIR"从不单独被接受。
• 在构建任何定制集成之前先复用国家平台(Spine、GP Connect、共享照护记录)。
• 合同强制要求开放的、有文档记录的 API、以标准格式提取数据的权利,以及对标准集成不收费。
• 临床安全与信息治理负责人从一开始就在设计小组中,而不仅仅是在签核时。
• 架构是 API 优先且松耦合的,这样一个组件就能在不重建其周围一切的情况下被替换。
• 一个具名的职能拥有整个机构范围内的标准、合规性与术语维护。

关键来源#

• NHS England ——互操作性标准、Spine、GP Connect,与共享照护记录项目。
• HL7 International ——FHIR 标准与 HL7 v2 规范。
• SNOMED International ——SNOMED CT 术语与实施指导。
• NHS 商业服务局 ——药品与设备词典(dm+d)。
• 医疗企业整合(IHE)——互操作性配置文件。
• openEHR International ——构建健康记录结构的开放规范。
• 世界卫生组织 ——国际疾病分类(ICD-10 与 ICD-11)。

参考文献#

1. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipedia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipedia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipedia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipedia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipedia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipedia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipedia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases