主题 4.1 — 平台与共享服务

在医疗与照护领域,一个共享平台不是一种省钱的便利,而是一种让安全、公平与信任变得可重复的方式——这样每个团队都能继承它们,而不是各自(常常糟糕地)重新发明它们。

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

当你在一个医疗与照护系统中运行数字交付时,你会很快注意到同样的能力被反复重建。每一项服务都想要验证一位患者的身份、查询一份人口统计记录、发送一条通知、记录一份审计轨迹,或核查一位临床医生的角色。放任不管,每个团队都会构建自己的版本。你最终会得到十几个登录界面、十几种处理患者身份的方式、十几份质量参差不齐的审计日志——以及十几个安全缺陷可能藏身的地方。

这种重复是昂贵的,但更深层的问题是它既危险又不公平。在医疗与照护领域,这些基础管道承载着临床风险。如果一个团队的患者匹配逻辑比另一个团队的更弱,一位患者可能被给予错误的记录。如果一项服务的无障碍性较差,一些人就会被悄悄排斥。如果审计轨迹各不相同,一次信息治理调查就会停滞。一个共享平台让你能够高标准地构建一次能力,把临床安全与无障碍性工作做扎实,然后让许多团队继承这个标准,而不是各自独立地赌自己能做对。

平台还塑造着整个系统的节奏。一个好的平台意味着一项新服务能在几周、而不是几年内触及患者,因为困难的、通用的部分已经存在。一个糟糕或缺失的平台,意味着每个团队都要承担基础设施的全部重量,交付速度会放慢到资源最匮乏团队的速度。在一个持续承受财务与劳动力压力、数百个机构需要同样国家与地方能力的行业,把平台做对是你能做出的杠杆率最高的决策之一。本主题讲的是如何良好地构建与运行它们——把它们当作拥有真实用户的产品,而不是没有人喜欢的强制性基础设施。

核心概念#

在这个语境下,平台是一组其他团队在其上构建、而不是自行构建的能力。最有用的现代框架,是把平台当作一个拥有内部用户的产品。它的客户是你自己的开发人员、交付团队与合作机构,它的成功是按照任何产品成功的方式来衡量的:通过采纳率、使用它的人的体验,以及它所促成的成果。

这背后有几个相关的理念。共享服务是更古老的组织模式,为机构的多个部分提供一次能力,而不是在每个部分中重复它。数字公共基础设施把这个理念延伸到整个社会的层面——公共与私营服务据以构建的共享、可复用、可互操作的构件(身份、支付、数据交换)。"政府即平台"——由 Tim O'Reilly 创造、被全球数字政府团队所采纳的一个短语——把同样的逻辑应用于国家:政府提供通用组件,各部门从中组合出服务,而不是各自构建完整的技术栈。

从技术上讲,平台常常通过一个应用程序编程接口(API)来暴露自己的能力——一份明确的契约,让一个系统能够使用另一个系统的能力,而无需了解其内部构造。它们常常依托云端平台即服务(PaaS)模型,共享的国家平台通常依赖多租户,即单一实例服务于许多机构,同时保持它们的数据与配置相互分离。

有三个概念决定了一个平台是帮助还是伤害。第一个是认知负荷:一个好的平台会减少一个交付团队脑海中必须持有的东西,让团队能够专注于它存在的意义所在的临床或照护问题。第二个是"铺好的路"或"黄金路径"——一种得到良好支持的、有明确主张的完成常见任务的默认方式,比绕开它更容易遵循,通过自助服务、而不是把关来提供。第三个是避免供应商锁定,这正是为什么平台应当建立在开放标准之上,让机构能够在供应商之间迁移,而不必承受高昂的转换成本。

具体到医疗领域,国家级共享服务已经是这片格局的一部分。诸如 NHS Connecting for Health 这样的历史项目建立了 NHS Spine,一套承载诸如个人人口统计服务这样核心数据的国家级服务。现代的对应物包括国家级 API、用于市民身份验证的 NHS login,以及用于消息传递的 NHS Notify——这些能力的提供,是为了让各项服务不必重新构建它们。凡是一个平台提供了一种通用方式来证明某人是谁的地方,它常常会暴露单点登录,让一位临床医生只需验证一次身份,而不必反复验证。本主题关注的是如何构建与运行这样的平台;关于你是谁、你可以做什么的细节属于主题 4.2——身份与访问管理,让系统能够交换数据的标准属于主题 4.3——互操作性与数据标准。

最佳实践#

1. 把平台当作一个产品、而不是一个项目来对待。 一个平台拥有路线图、一位产品经理、持续的资金,以及你衡量其满意度的用户——而不是一个结束日期与一次交接。项目会结束并腐朽;平台必须无限期地运行,因为团队会逐渐依赖它们。相应地为它提供资金与人员配置,并参见主题 5.0——以产品为主导的工作,了解这意味着什么样的运营纪律。

2. 从最薄可行平台开始。 构建真正能减轻团队负担的最小一组共享能力,只有在真实需求与真实痛点证明其合理时才添加更多。这个"最薄可行平台"理念,在主题 1.1——运营模式中被引入,防范着最常见的失败:一个雄心勃勃的中央平台试图做一切事情,姗姗来迟,却不适合任何人。让平台从使用的证据中成长,而不是从架构上的愿景中成长。

3. 让铺好的路成为容易的路。 一个平台通过让被支持的路径比自建更快、更简单来赢得采纳——通过自助式接入、清晰的文档、沙箱,以及内建了临床安全与无障碍性的合理默认设置。如果使用这个平台比绕开它更慢或更痛苦,团队就会绕开它,而你将花钱创造出一个瓶颈。要为开发者的第一个小时、以及他们最糟糕的一天而设计。

4. 依据采纳率与用户体验、而不是存在与否来衡量成功。 正确的指标是有多少团队愿意使用这个平台、接入需要多久、这个平台的可用性如何,以及它的用户如何评价这段体验。诸如已部署服务数量这样的虚荣指标,说明不了团队是否真正得到了帮助。为平台安装仪器,与在其上构建的团队定期开展研究,并把一条下降或停滞的采纳曲线当作一个需要修复的产品问题,而不是一个需要强制执行的合规问题来对待。

5. 建立在开放标准之上,保持退出的低成本。 优先选择开放的、被广泛采纳的标准与接口,这样无论是你、还是你平台上的团队都不会被困住。记录一个团队将如何离开,并确保他们真的能够做到。矛盾的是,让离开变得容易,正是让团队愿意加入的原因,它也让这个平台保持诚实,因为它必须靠赢得自己的位置、而不是依赖俘获来维系。这直接减少了主题 4.0——技术架构、云与遗留系统中所讨论的、更广泛资产范围内的供应商锁定。

6. 明确谁付费、谁决定。 一个共享平台需要一个预先商定的资金模式与治理模式:它是中央资助的、向用户收费的,还是混合的,以及它的路线图如何在相互竞争的租户之间排定优先级。这里的模糊性,正是让平台变成政治战场的原因。发布这个模式,给用户在路线图上一个真正的发言权,并随着平台的成长重新审视它。

7. 以清晰的职责与边界运行平台团队。 围绕一个专职的平台团队来组织,其工作是通过自助服务来赋能流对齐的交付团队,正如主题 7.0——团队结构、角色与职责中所描述的 Team Topologies 模式。让平台与消费者之间的接口保持明确——平台承诺什么、不承诺什么,以及如何获得支持——这样平台才能起到赋能、而不是把关的作用。

8. 从一开始就为多租户、隔离与安全而设计。 如果许多机构将共享一个平台,它们数据、配置与故障域的分离是一项基础要求,而不是后期功能。在医疗与照护领域,这也是一项信息治理与临床安全要求:一个租户的事故绝不能暴露或危及另一个租户的患者。把隔离、按租户的可观测性,以及依据 DCB0129 为平台本身制定的临床安全论证烘焙进去。

与团队讨论的问题#

1. 能够真正减轻我们团队负担的最薄平台是什么?我们被诱惑去构建、却不应该构建的是什么? 在白板上设计一个宏大的平台很容易,交付一个团队真正喜爱的平台很难。从你交付团队今天真实的、反复出现的痛苦出发——三个或以上团队各自都在重建的那种能力——并抵制添加任何只有一个团队需要、或还没有人要求的东西。追问哪些能力真正是通用的,哪些仅仅从远处看起来相似、却在临床上重要的细节上有所不同。考虑做错的代价:一个团队必须绕过的、过早的共享能力,比没有平台更糟糕。商定一条明确的界线,说明平台现在将拥有什么、又将刻意推迟什么。按计划重新审视这条界线,只有在需求与痛苦被证明时才把项目移过去。这门纪律,就是对尚未赢得自己位置的好想法说不。

2. 当租户意见不一致时,我们如何为平台提供资金、决定它的路线图? 一个平台服务着许多有相互竞争优先事项的团队,一旦两个重要的租户想要不兼容的东西,你的治理就会受到考验。现在就决定平台是中央资助的、向用户收费的,还是混合的,并诚实地面对每种模式所产生的激励:收费可能抑制采纳,而中央资助可能让平台脱离用户需求。决定谁掌握路线图、租户如何影响它,以及你如何在一家大型机构的紧急需求与一家小型机构的基本需求之间进行仲裁。明确地考虑公平性,因为一个收费模式可能把较小或较穷的机构从它们最需要的共享安全能力中排挤出去。商定你将如何处理一个想为一项功能付费、而其他人不想的租户。把这个模式写下来并发布,这样决策才会感觉像治理,而不是偏袒。然后承诺随着平台及其用户群的成长重新审视它。

3. 我们如何知道这个平台是被喜爱的、而不仅仅是被强制要求的?如果不是,我们会怎么做? 一个平台可能在技术上是健全的、被正式要求的,却又被悄悄地憎恨着——而一个被强制要求却不被喜爱的平台,会累积变通方案、影子系统与怨恨。提前决定哪些信号会告诉你真相:当团队有选择时的自愿采纳率、一个新团队首次成功所需的时间、可用性与事故历史,以及使用它的开发人员的直接反馈。谈一谈当你同时对你的用户拥有权力时,你将如何收集诚实的反馈,因为人们不愿批评一个他们被要求使用的平台。商定一条健康的采纳曲线是什么样子,以及什么样的门槛会触发一次认真的反思。决定如果证据要求,你是否真的愿意退役或替换这个平台。愿意听到你的平台没有起作用,正是让它保持有效的关键。另一种选择是,只有当一项重大服务绕开你时,你才发现真相。

4. 我们要如何保持退出的低成本?我们平台上的一个团队如果需要,真的能够离开吗? 声称你建立在开放标准之上很容易,证明一个团队能够在不进行一次高昂重写的情况下离开,则完全是另一回事。诚实地谈一谈锁定正在哪里悄悄滋生——一个专有接口、一种未经记录的数据格式、一项没有替代方案的国家级依赖——以及离开的成本是否随时间悄悄上升。决定谁负责记录并定期测试一条退出路径,而不是假设它存在。考虑到在医疗与照护领域,锁定风险会复合:一个建立在俘获之上的国家平台可能困住整整一代人的系统,而最没有能力吸收转换成本的,通常是最小的提供者。一个诚实的答案会说出你会难以解开的具体依赖关系,描述至少一个真实租户的一条具体退出路径,并把可移植性当作你维护的一项功能、而不是你反复重复的一句口号来对待。记住,让离开变得容易,往往正是让团队愿意加入的原因。

5. 这个平台是否拥有自己的临床安全论证?我们如何防止一个租户的失败伤害到另一个租户的患者? 当许多机构共享一个平台时,它的基础管道代表着建立在其上的每一项服务承载着临床风险,因此患者匹配中的一个缺陷或租户之间的一次泄露,不是一个团队的问题,而是所有人的问题。决定这个平台是否有自己的 DCB0129 安全论证,消费团队能够真正依赖它,还是每一项服务都在悄悄地重新评估同样的共享风险。讨论你如何隔离租户的数据、配置与故障域,以及你要如何知道这种隔离是否被破坏——按租户的可观测性,是遏制一次事故与迟迟才发现它之间的区别。也要考虑信息治理方面的后果:对一个租户的调查绝不能要求暴露另一个租户的记录。一个诚实的答案能够指出一份被维护的安全论证、一条经过测试的隔离边界,以及一份关于平台在安全性方面承诺什么、相对于每项服务自身仍然承担什么责任的清晰说明。把安全性与隔离当作基础、而不是后期功能来对待,正是让团队能够继承保证、而不是赌它的关键。

6. 平台团队与它所服务的团队之间的界线在哪里?我们如何防止平台变成瓶颈? 一个共享平台可能加速每一个团队,也可能把所有人都拖慢到一个中央队列的速度,差别在于你把平台与消费者之间的接口划得有多清晰。决定平台拥有并承诺什么,它明确不承诺什么,以及一个团队如何在不为常规工作排队等待一张工单的情况下获得支持。把自助服务谈作默认选项:如果接入、配置或一次常见变更都需要平台团队亲自出手,你构建的就是一道关卡、而不是一条铺好的路。考虑一个好平台核心的认知负荷交易——它应当减少一个交付团队脑海中必须持有的东西,让他们专注于临床问题,而不是增加一层需要协商的东西。一个诚实的答案会说出目前仍然汇聚到平台团队、成为瓶颈的任务,设定一个让它们实现自助服务的方向,并坦率承认平台在哪些地方是在赋能、哪些地方是在把关。

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

一个覆盖若干 NHS 信托机构、社区提供者,以及一个郡议会成人社会照护服务的整合照护系统(ICS)不断撞上同一堵墙。每一项新的数字服务——一个虚拟病房、一份社区物理治疗的自我转诊表格、一个养老院监督工具——都要花前三个月重建同样的基础:证明患者是谁、检查专业人员的角色、发送短信提醒,以及撰写一份审计轨迹。事实证明,虚拟病房团队的患者匹配比物理治疗团队的更弱,一次未遂事件发生在一条提醒被发送给了错误的人。该 ICS 的数字化领导层认识到了这个模式:他们正在为本应只存在一次的能力多次付费,而这种差异是一项安全风险。

他们没有委托一个宏大的 ICS 平台,而是从精简开始。他们建立了一项单一的共享服务,把一件事做好:它把 NHS login 与国家个人人口统计服务包裹在一个干净的、有文档记录的、带沙箱的 API 之后,这样任何团队都能通过一条被支持的路径核验一位市民的身份并检索一份已确认的人口统计记录。一支由五人组成的小型平台团队把它当作一个产品来对待。他们发布了一份铺好路的指南,提供自助式接入,并设定了一个目标:一个新团队应当在一天之内完成首次成功调用。至关重要的是,他们没有强制要求使用它。他们让它成为最简单的选项,让虚拟病房团队成为第一个自愿的采纳者。

资金模式被公开商定:该 ICS 在前两年为平台的核心提供中央资助,这样采纳就不会被收费抑制,并在十八个月时进行审查。一个包括议会在内的跨提供者小组掌握路线图,每月开会。当物理治疗团队接下来要求一项通知能力时,平台团队围绕 NHS Notify 添加了一个精简的包装层,而不是从零开始构建消息传递——构建一次,多处使用。一年之内,六个团队自愿采纳了这项身份服务,接入时间从数月降到了数天,平台团队公开发布了它的可用性与采纳数字。当一家信托机构的定制系统绕开这个平台时,团队把它当作研究、而不是抗拒来对待,了解了驱动这个决定的摩擦点,并修复了它。这个平台之所以成长,是因为团队选择了它,该 ICS 继承了一种单一的、经过充分测试的、具无障碍性的方式来处理那些有风险、通用的事情。

行业视角#

初创企业#

一家健康科技初创企业很少为他人构建平台;它在别人的平台上构建。你的杠杆来自使用国家与云端平台——NHS login、国家级 API、一个云提供商的托管服务——这样你的小团队就能把精力花在临床问题上,而不是重新发明身份识别或消息传递。即便如此也要留意锁定:选择开放标准,保持你的数据可移植,因为你今天廉价租用的能力,可能变成明天束缚你的依赖关系。在内部,让你自己的"平台"保持精简到几乎不可见的程度;一个两人团队不需要一个黄金路径抽象层,它需要发布东西。这门纪律在于知道你何时已经成长到一个共享的内部能力值得被提取出来。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院,或一家单一场所的诊所——几乎总是一个平台消费者,自身几乎没有数字能力,因此它所依赖的平台实际上设定了它的安全与公平底线。你实际的任务,是选择被支持的共享服务,而不是你无法配置人手去维护的定制构建,偏向已经承载着无障碍性与临床安全工作、你独自绝无可能资助的国家能力,如 NHS login、人口统计查询与 NHS Notify。坚持要求真正的自助式接入与清晰的文档,因为你没有平台团队可以上报升级,也负担不起一个漫长的集成项目。密切关注资金模式,因为一个收费平台可能把一个小型提供者挡在它最需要的安全能力之外,因此要争取公平的获取渠道,并在你能触及的任何路线图治理中提出这一点。也要留意退出,因为当你没有内部技术人员来帮你迁移时,专有的供应商锁定最难逃脱。收益在于,一个好的共享平台让你能够继承你自己无法构建的标准,履行与大型机构同样的职责,却不需要它们的资源。

大型企业#

一家大型信托机构或国家机构拥有足以证明真正平台合理性的规模,也拥有足以毁掉它们的官僚体系。风险是一个变成象牙塔的中央平台团队——在架构上很优雅,响应缓慢,与它本应服务的交付团队脱节。要用把平台当作拥有自己路线图与用户研究的长期存在的产品来资助,以采纳率与开发者体验、而不是强制合规情况来衡量它们,来对抗这一点。在这个规模上,多租户、隔离,以及平台本身的临床安全论证变得至关重要。回报是巨大的:一次高标准构建的能力,被数十项服务继承,提高了整个机构的底线。

政府机构#

在国家与系统层面,这个框架是数字公共基础设施与政府即平台:构建通用组件——身份识别、通知、人口统计查询、数据交换——供数百个机构组合成服务。开放性方面的利害关系在这里最高,因为一个建立在专有锁定之上的国家平台可能困住整整一代医疗系统。治理与资金必须公开地被解决,并让共享平台部分是为了保护的、较小与较穷的机构拥有真正的影响力。在这个层面,强制要求的诱惑最强,也最危险;一个被要求却不被喜爱的国家平台,会在全国滋生影子系统。要通过质量与支持赢得采纳,把每一个变通方案都当作一个改进的信号。

常见失败模式#

• 瓶颈。 每个团队要做任何事都必须等待中央平台团队,导致平台拖慢了交付、而不是加速了它。解药是自助服务:团队应当能够在不排队等工单的情况下接入并采取行动。
• 象牙塔。 平台是由远离交付的人设计的,在技术上令人钦佩,却不适合任何真实团队的需求。解药是把平台当作一个拥有持续用户研究的产品来运行。
• 被强制却不被喜爱。 政策要求使用这个平台,实践中却被绕开,累积影子系统与怨恨。解药是通过质量赢得采纳,并在团队绕开你时倾听。
• 无所不包的平台。 过度雄心的范围意味着平台姗姗来迟,做得太多,却没有一样做好。解药是最薄可行平台,从需求的证据中成长。
• 悄悄的锁定。 平台悄悄地把团队绑定到一个专有的供应商或接口,离开的成本变得高不可攀。解药是开放标准与一条有文档记录、经过测试的退出路径。
• 资金的模糊性。 没有人商定谁付费、谁决定,导致平台要么挨饿,要么变成一个政治战场。解药是一个明确的、已发布的资金与治理模式。
• 安全性作为事后补充。 平台没有自己的临床安全论证,导致每一项消费服务都继承了未经评估的风险。解药是把平台的 DCB0129 安全论证当作基础来对待。

成熟度模型#

检查清单#

• 该平台有一位具名的产品经理、一份路线图,以及持续的(非项目性的)资金。
• 你从最薄可行平台开始,并能说出你刻意推迟了什么。
• 被支持的路径真正比团队自行构建更快、更容易。
• 新团队能够通过自助服务接入,配有一个沙箱与清晰的文档。
• 你衡量采纳率、首次成功所需时间、可用性,以及开发者体验。
• 资金模式(中央、收费,或混合)已被商定并发布。
• 路线图治理给予租户、包括较小的机构,一个真正的发言权。
• 平台建立在开放标准之上,存在一条有文档记录的退出路径。
• 多租户的数据与故障隔离从一开始就被设计进去,而不是事后附加。
• 平台拥有自己的临床安全论证(DCB0129),消费团队能够依赖它。
• 你把绕开平台的团队当作研究、而不是反抗来对待。

关键来源#

• GOV.UK 服务手册与政府数字服务关于政府即平台与通用组件的著述。
• Matthew Skelton 与 Manuel Pais,《Team Topologies》——平台团队、最薄可行平台,与认知负荷。
• NHS England 开发者与 API 指导(NHS login、NHS Notify、国家级 API,以及 Spine 服务)。
• 健康 IT 系统的 DCB0129 与 DCB0160 临床风险管理标准。
• 世界银行与联合国关于数字公共基础设施与可复用公共构件的著述。
• Tim O'Reilly,《政府即平台》,收录于《Open Government》(O'Reilly Media)。

参考文献#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation