主题 1.0 — 数字医疗与照护的工作方式

一句话概括: 工作方式是一套刻意选择、共同遵守的习惯——你如何组建团队、做出决策、管理风险、交付价值——它们让一个医疗与照护机构能够将意图转化为对患者与市民而言安全、公平、循证的成果。

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

每个机构都有自己的工作方式,无论是主动选择的还是被动继承的。在数字医疗与照护领域,那些被继承下来的工作方式往往并不适合这项工作:它们是为范围固定的建筑式项目而设计的,而不是为涉及临床安全、法定职责与公共资金的适应性服务而设计的。把它们做对,不是后台部门的锦上添花,而是决定了一份共享照护记录究竟是临床医生信任并使用的东西,还是被闲置不用的摆设。

医疗与照护领域的独特之处,塑造了本书中的每一项实践。安全是不可妥协的——数字服务中的一个缺陷可能伤害患者,因此临床风险管理(见主题 1.6——临床安全与风险管理)应贯穿交付全过程,而不是事后附加。公平之所以重要,是因为一项只对数字素养高的人有效的服务会加剧健康不平等;必须为 Core20PLUS5 人群以及数字接入有限的人群而设计,而不是把他们排除在设计之外。法定职责——NHS 提供全面照护的承诺、数据保护法、保密义务——限制了你可以如何使用数据以及必须如何进行咨询。公共资金要求与之相称的支出控制与可证明的价值。而且几乎没有任何服务是由单一机构独立交付的:跨整合照护系统(ICS)、地方政府、社会照护提供者与供应商的伙伴合作是默认的运作条件。

安全、公平、职责、资金——这四种压力正是你无法简单照搬消费科技行业操作手册的原因。你需要的工作方式,既要敏捷又要负责,既要快速又要安全,既要以用户为中心又要对全体人群公平。

核心概念#

工作方式在三个层面运作。在团队层面,它们是日常实践:站会、用户研究、迭代交付、结对工作。在组织层面,它们是运营模式——战略如何转化为价值流、能力、资金与决策权(见主题 1.1——运营模式)。在系统层面,它们是独立机构之间如何对齐:整个 ICS 范围内的共享标准、互操作性与共同治理。本书会刻意地在这三个层面之间往返穿梭。

**以用户为中心的设计**意味着从使用服务的人——患者、照护者、临床医生、行政人员——的需求出发,而不是从一个预设的解决方案出发。英国政府数字服务(GDS)与 NHS 已将这一点写入服务标准:在动手建设之前先理解用户及其需求,并在整个过程中持续与真实用户进行测试。

**敏捷、迭代式交付**意味着尽早让一个可运行的服务出现在真实用户面前,从中学习并加以调整——而不是事先把一切都规定死。NHS 数字服务手册明确指出,敏捷的、以用户为中心的工作方式能降低"造出错误的东西"的风险。在这里,敏捷既是一种交付方法,同样也是一种风险管理策略。

**多学科团队(MDT)**将一项服务所需的各种技能汇聚到一个被赋予自主权的团队中:产品与交付管理、用户研究与设计、工程、临床与信息治理专长,以及运营知识。NHS 服务标准要求团队包含多学科的技能与视角——包括获得专科临床、法律或政策方面意见的渠道。MDT 是数字交付的基本单元;大多数失败都可以追溯到团队桌上缺少了某个学科的声音。

产品优先于项目。 项目有开始、有结束、有交接;而产品在其整个生命周期中都持续获得资金与管理。从项目思维转向产品思维(见主题 1.1 与主题 5.0——以产品为主导的工作)会改变资金、团队与问责方式,而这远比一次性项目更适合医疗服务——因为医疗服务是长期存在、持续演进的。

最佳实践#

1. 从有研究证据支撑的用户需求出发。 在着手建设之前,先理解用户是谁、他们试图完成什么,以及当前服务在哪些地方让他们失望。为探索阶段(discovery,见主题 3.4——探索阶段)投入资源,并将"我们假设……"视为一个危险信号。用户需求,而非内部偏好,才是此后每一个决策的锚点。

2. 组建多学科的、被赋权的、稳定的团队。 汇聚全套所需技能——包括临床安全与信息治理——并在清晰的护栏之内授予团队决策权。让团队围绕一项服务持续存在,而不是在每个项目边界解散重组;稳定的团队能够积累医疗服务所要求的领域知识与安全知识。

3. 公开地工作,并以小步骤迭代。 发布薄切片,测量,调整。小而频繁的发布比大爆炸式上线更安全,因为问题会在还很小的时候就浮现出来,而且能让临床安全与信息治理审查跟上变化的节奏,而不是变成末端的一道关卡。

4. 从第一天起就把安全与公平当作头等大事。 让临床风险管理(DCB0129/DCB0160)与平等/健康不平等分析与交付并行开展,而不是作为末端的签核环节。及早追问谁可能被排除或受到伤害,并为最困难的情形而设计——辅助数字化路径、无障碍访问(WCAG)与离线备用方案。

5. 依据证据决策,并记录决策过程。 区分临床证据(它有效且安全吗?)与交付证据(我们建得好吗?有人在用吗?),并保留一份轻量级的决策日志,让推理过程在人员流动之后依然留存(见主题 1.3——循证决策)。证据胜过薪酬最高者的意见。

6. 为互操作性与复用而设计。 医疗与照护数据必须能在机构之间安全流动;按照开放标准(HL7 FHIR、SNOMED CT)构建,并复用现有平台而不是重新发明(见主题 1.1 的"最薄可行平台"与主题 4.3——互操作性与数据标准)。一项无法共享数据的服务,就是一个等待变成风险的孤岛。

7. 按比例治理。 让保证工作的分量与风险等级相匹配。高风险的临床变更值得深入审查;低风险的内容变更不应该等上几周才能提交董事会。按比例的治理能让你既安全又快速。

8. 公开地工作。 分享计划、决策、路线图,以及——在安全的前提下——代码,让合作伙伴、临床医生与公众能看到选择是如何以及为什么做出的。公开透明能建立信任,减少在一个碎片化系统中的重复劳动,并在错误固化为生产服务之前就邀请质疑。在医疗与照护领域,坦诚说明一项服务如何使用数据、为何这样使用,本身就是一种信任与安全实践。

9. 为长远与交接而设计。 医疗领域的数字服务往往比建设它们的团队与合同存在得更久,因此要把决策记录下来,避免未经记录的"英雄式"知识,并为将来数年运营和变更该服务的人而设计(见主题 10.3——知识管理与文档)。把可持续性——团队、技术与资金模式的可持续性——当作头等约束条件,而不是事后才想起的东西。

与团队讨论的问题#

1. 我们当前的哪些工作方式是被继承下来的,而不是主动选择的?其中哪一个继承而来的习惯,在安全、公平或资金浪费方面让我们付出的代价最大? 这个问题迫使团队诚实地审视那些没有人真正决定过、却人人遵循的做法——范围固定的项目式资金安排、在项目之间解散再重建的团队、只在上线时才被咨询的治理。它之所以重要,是因为继承而来的习惯通常要到被明确指出时才会被看见,而在医疗与照护领域,它们会带来实实在在的代价:临床医生不信任的共享记录、把 Core20PLUS5 人群排除在外的服务,或是用公共资金重新建设同一套登录管道。值得讨论的张力在于,继承下来的做法往往因为熟悉、可审计而显得"安全",所以淘汰它们看起来像是在承担风险,而不是在消除风险。将讨论建立在具体证据之上——看看你们最近三份商业论证、项目之间的团队流失率,以及临床安全是何时首次被纳入的——而不是交换看法。一个好的答案会指出一两个有明确成本证据的具体习惯,区分哪些值得保留、哪些正在切实损害结果,并承诺由一位高级领导来担责推动改变。

2. 我们的团队是否真正拥有完整的多学科技能组合——包括临床安全与信息治理——就坐在团队内部,还是这些学科仍然作为末端关卡被附加上去? 本主题认为 MDT 是数字交付的基本单元,大多数失败都可以追溯到桌上缺少某个学科,因此这个问题检验的是这一原则在你的机构中是真实存在的,还是仅仅停留在愿景层面。它之所以重要,是因为一位只在上线时才介入的临床安全官或 Caldicott Guardian,要么迫使返工,要么迫使不安全的走捷径,而一位从第一周就融入团队的临床安全官,则能维护一份与交付节奏同步的实时危害日志。值得摆到台面上的取舍是成本与稀缺性:专科临床、法律与信息治理方面的人手确实有限,因此"让每个团队都配齐所有人"会与真实的资源约束相冲突,团队必须决定在哪些地方可以接受兼职或共享角色,在哪些地方不可以。看看当前的一项服务,梳理清楚谁是真正的常设团队成员,谁只是作为外部签核被咨询,并检查团队是否拥有在护栏内自主决策的权力,还是不断需要上报升级。一个诚实、良好的答案会具体说明缺少或借用了哪些学科,坦率承认资源紧张这一张力,并提出一个具体的模式——全职、兼职或按需待命——来弥合差距,而不是假装稀缺性不存在。

3. 我们曾在何时把一项数字服务当作一个带有交接环节的项目来对待,而不是当作在其整个生命周期中被悉心管理的产品?这让我们在领域知识与安全知识上付出了怎样的代价? "产品优先于项目"是本主题中一个具有支撑性的转变,这个问题促使团队正视自己在哪些地方仍然是为结束、而不是为延续而进行资金安排和人员配置。它之所以重要,是因为医疗服务是长期存在、持续演进的;在项目边界解散的团队,恰恰带走了让一项服务保持安全所积累的临床与运营知识,而"试点炼狱"正是反复出现的症状。真正的张力在于财务与结构层面:产品化资金需要常设预算,这会挑战财务与治理体系所依赖的年度投标、限时项目模式,因此这与其说是一场关于交付的对话,不如说同样是一场关于资金与问责的对话。可以考虑一项经历过交接的具体服务——追溯它的危害日志、用户研究与团队后来发生了什么——并将其与产品化资金所要求的纪律加以权衡。一个好的答案会指出一个具体案例,量化或至少描述所损失的知识,并坦率说明要让持续存在的产品团队成为常态,哪些组织性障碍(资金周期、资源配置规则、治理结构)必须改变。

4. 我们所构建的服务最有可能将谁排除在外或对谁造成伤害?我们能否指出自己在何处优先为他们而设计,而不是最后才想到他们? 本主题坚持认为公平是不可妥协的,一项只对数字素养高的人有效的服务会加剧健康不平等,因此这个问题检验的是"为最困难的情形而设计"究竟是一种活生生的实践,还是一句口号。它之所以重要,是因为医疗与照护领域的排斥不仅仅是不便,而是一种安全与可及性上的伤害:Core20PLUS5 人群、数字接入有限的人、健康素养低的人,或没有智能手机的人,恰恰是需求最大的人群,而一项把他们排除在外的服务,会把伤害集中在最无力承受的地方。值得摆到台面上的张力在于,为边缘群体而设计需要前期投入时间与金钱——辅助数字化路径、符合 WCAG 的无障碍访问、离线与非数字化备用方案、翻译——而当交付期限逼近、信心十足的多数人已经能够使用该服务时,这些成本很容易被推迟。看看一项真实的服务,追问谁被纳入了其用户研究样本、一项平等与健康不平等分析是否真正影响了某个设计决策,以及一个无法或不愿上网的人会遭遇什么。一个诚实的答案会为这项服务具体指出处于风险中的群体,展示至少一个为他们而做的具体设计选择,并坦率承认团队曾在压力下在哪些地方牺牲了包容性,以及下次将如何为这一取舍辩护。

5. 我们在哪些地方正在重新发明已经存在的基础管道?在哪些地方,按照开放标准构建并复用共享平台真正会改变我们交付的东西? 为互操作性与复用而设计是本主题的最佳实践之一,这个问题促使团队正视那种想要定制构建、而不是复用的冲动——登录、通知、记录集成,这些别的十几个团队也都建过。它之所以重要,是因为在一个碎片化的系统中,每一个被重新发明的组件都意味着公共资金被花费了两次,也意味着一个无法安全交换数据的新孤岛;反过来,按照 HL7 FHIR 与 SNOMED CT 构建,并复用最薄可行平台,才是让一项服务能够通过采购、并在整个 ICS 范围内共享数据的关键。真正的取舍在于,复用意味着依赖:一个共享平台可能更慢、不够定制,或者由别人的路线图来治理,因此团队必须权衡共享组件带来的拖累,与定制孤岛所带来的长期成本和风险。审视当前的一项建设,列出哪些是真正新颖的,哪些是在重复已有的平台、标准或开放组件,并检查"我们无法复用它"究竟是有证据支撑的约束,还是一个未经检验的假设。一个好的答案会区分值得构建的部分与值得复用的部分,对所提供平台的成熟度与治理情况保持诚实,并承诺对任何需要交换数据的部分采用开放标准。

6. 我们如何让治理的分量与风险等级相匹配?目前在哪些地方,保证工作对低风险变更而言过重,而对高风险变更而言又过轻? 按比例治理是本主题中一个具有支撑性的理念——高风险的临床变更值得深入审查,而低风险的内容变更不应该等上几周才能提交董事会——这个问题检验的是机构究竟是根据风险来校准保证工作,还是对一切都套用同一套生硬流程。它之所以重要,是因为治理设置失当会双向造成伤害:一个沉重的一刀切关卡会让团队把变更积攒起来批量处理,从而拖慢正是那种能保持服务安全的迭代节奏;而一律轻描淡写的处理方式,又会让一个真正高风险的临床变更绕过它本应接受的临床安全与信息治理审查。张力在于,按比例处理需要判断力,而对于那些觉得单一强制性清单比按风险分级的路径更容易辩护的董事会与审计人员来说,判断力是令人不安的。看看你们最近十几次变更是如何获得保证的,按实际的临床与数据风险对它们排序,看看所投入的精力究竟跟随的是风险,还是日历。一个诚实的答案会指出治理过度与治理不足的具体例子,提出按风险分级变更的清晰标准,并指明谁拥有决定分级、并对此负责的权力。

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

一个整合照护系统希望为三家急症信托机构、社区服务与地方政府社会照护领域的临床医生提供一份共享照护记录。老办法会是委托一个范围固定的项目,事先规定好每一个界面,并在后期才进行集成。

相反,该 ICS 组建了一个多学科团队:一名产品经理、一名交付经理、一名用户研究员、一名交互设计师、两名工程师、一名临床安全官与一名信息治理负责人,并可获得一名 Caldicott Guardian 与一名社会照护从业者的支持。他们开展了为期八周的探索阶段,观察一名社区护士、一名急诊顾问医生与一名社工在今天实际是如何查找信息的。他们发现,真正的痛点并不是"没有数据",而是"他们无法信任数据的时效性"。

团队交付了一个范围狭窄的 alpha 版本:对某一条临床路径中的过敏史、用药与当前照护计划状态提供只读访问,并附有一个可见的"最后更新时间"标记。临床安全工作与之并行开展;一份危害日志从第一周起就被维护。他们测量的是,临床医生是否不再打电话给其他团队核实信息。只有当这个薄切片被证明既有价值又安全之后,他们才扩大记录的范围——并将其作为一项持续的产品来资助,而不是一个封闭的项目。

行业视角#

安全、公平、职责、资金——这四种压力作用于每一个机构,但应对它们的工作方式会随着规模、资金与问责制而变化。

初创企业#

一家小型数字医疗公司的生死取决于专注度,因此它的工作方式出于必要而精简:一个多学科团队,扁平化决策,与用户保持日常接触。制约因素是资金存续期(runway),而不是人头数规则,因此探索阶段以周为单位来衡量,证据的收集也很廉价——几次临床访谈、一个可点击的原型、由兼职临床安全官维护的一份诚实的危害日志。危险之处在于为了赶上投资人的里程碑而跳过安全与信息治理的严谨性;能经受住审视的纪律,是把 DCB0129 与数据保护影响评估当作试点的准入条件,而不是推迟到某个信托机构问起时才补办的文书工作。从第一天起就考虑互操作性(FHIR、SNOMED CT)也是一项商业资产,因为一家无法交换数据的初创企业永远无法通过 NHS 采购。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院或居家照护机构、一家单一场所的诊所,或是一家已过预收入阶段的小型健康科技供应商——承受着与大型信托机构同样的安全、公平、职责与资金压力,但能用来应对这些压力的能力却只是零头。这里的工作方式必须极度讲求相称性:很少有专门的数字或信息治理团队,因此"多学科团队"往往是几个身兼数职的人,再加上一份共享的或外包的临床安全与数据保护资源。陷阱在于假设法定职责会随机构规模而"缩水"——事实并非如此,因此即便只有一名执业经理对所有事情负责,DCB0129/DCB0160 临床安全、数据保护影响评估与无障碍访问依然必须全面适用。切实可行的纪律,是大力倾向于复用而不是自建:采用经过认证的现成系统,坚持要求供应商满足 DTAC 与开放标准(FHIR、SNOMED CT),并使用国家级或 ICS 提供的平台,这样安全性、互操作性与信息治理就是继承而来的,而不是靠捉襟见肘的资源重新发明的。

大型企业#

一家 NHS 信托机构或 ICS 面临的是相反的问题:流程过多而所有权碎片化。这里的工作方式很大程度上关乎忘掉旧习——淘汰范围固定的项目习惯,撤销解散再重建的项目团队——与采纳新实践同等重要。问责是正式且具体到个人的(一位高级责任所有者、一位 Caldicott Guardian、董事会层面的临床安全签核),因此制胜之道在于将这些角色嵌入交付团队内部,而不是作为关卡附加上去。一家大型健康科技或制药供应商面临的是镜像问题:工程成熟度很强,但与一线临床现实之间存在距离,而配备真实临床医生时间的多学科团队正是为弥合这一距离而存在的。

政府机构#

一个国家级或地方公共机构——NHS England、DHSC、UKHSA、一个地方政府——制定的标准是其他所有机构都要遵循的,因此它的工作方式会向外扩散影响。它对议会与公众负责,这提高了透明度、支出控制与公平性方面的标准:服务标准、公开的保证路径与 Core20PLUS5 职责,都是这种问责制的工具,而不是可有可无的附加项。在这个规模上的风险,是为一个并不存在的"平均市民"进行中央化设计,并在理解地方需求之前就强制推行某个解决方案。纠正之道与其他任何地方一样,是同样的以用户为中心、迭代式的纪律,只是应用时要更倾向于制定开放标准与可复用平台,让各联邦成员机构能够在其之上继续建设——治理的是整个系统,而不仅仅是交付一项服务。

常见失败模式#

• 解决方案先行的交付。 在理解需求之前就承诺某个具名的产品。解药:为探索阶段投入资源,并把用户需求作为建设的准入条件。
• 治理成为末端关卡。 临床安全与信息治理只在上线时才被咨询,迫使返工或不安全的走捷径。解药:从第一天起就把两者嵌入团队。
• 项目式的人员流失。 组建团队又将其拆散,损失来之不易的领域知识与安全知识。解药:产品化资金与持续存在的团队。
• 试点炼狱。 无穷无尽的试点却始终无法规模化,因为采纳、培训与业务变更从未获得资源(见主题 8.1——变革管理)。解药:在试点之前就规划好通向规模化的路径。
• 把公平当作事后补充。 只为信心十足的多数人而设计,把最需要照护的人排除在外。解药:优先为最困难的情形而设计。

成熟度模型#

检查清单#

• 每项服务都有一个具名的、稳定的多学科团队,具备临床安全与信息治理技能。
• 没有任何一项建设是在缺乏探索阶段证据支持的用户需求下启动的。
• 临床风险管理(DCB0129/DCB0160)从第一天起就运行,并维护一份实时危害日志。
• 已完成公平/健康不平等分析,并且存在辅助数字化路径。
• 交付以小而频繁、可衡量的切片方式推进。
• 决策被记录在案,区分临床证据与交付证据。
• 服务按照开放互操作性标准构建,并复用共享平台。
• 治理的分量与风险相匹配,且团队对此知情。
• 存在一条从试点到规模化、且已获得资助的路径,包括培训与变革管理。

关键来源#

• NHS 数字服务手册 ——NHS 服务标准及其各项要点,包括"采用敏捷的工作方式"与"组建一个包含多学科技能与视角的团队"(service-manual.nhs.uk)。
• GOV.UK 服务手册与政府服务标准——政府数字服务(gov.uk/service-manual)。
• NHS England / NHSX ——数字技术评估标准(DTAC)。
• 临床安全标准DCB0129与DCB0160(NHS England / 原 NHS Digital)。
• NICE ——数字健康技术证据标准框架(nice.org.uk)。
• NHS England ——用于减少健康不平等的Core20PLUS5方法。

参考文献#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/