主题 6.4 — 治理与保证

治理的存在，是为了帮助你做出好的、快速的、安全的决定，并向你自己、你的董事会和公众证明——一项数字服务正在被负责任地运营，因此要把它当作交付的赋能者，而不是对交付征收的一种税。

为什么这在卫生与照护中至关重要#

在大多数行业，薄弱的治理会耗费金钱和声誉。在卫生与照护中，它可能耗费生命、固化不平等，并侵蚀整个系统所依赖的公众信任。一次治理不善的临床系统变更，可能在任何人注意到之前，就把一个剂量错误传播给数千名患者；一条无治理的数据流可能侵犯你所服务的最脆弱人群的保密性；一次未经保证的上线可能锁定一项悄悄排斥最需要照护者的服务。这些利害关系正是"你如何工作"是一个临床安全、公平和信任问题、而不仅仅是效率问题的原因。

与此同时，卫生与照护中的治理也有着咎由自取的名声：缓慢、仪式化，与交付脱节。团队坐在橡皮图章式批准已做决定的董事会会议上，填写没有人读的模板，看着琥珀色的风险在一次审查的前一周变成绿色，之后却惊人地失败。这就是你必须解决的悖论。答案不是更少的治理或更多的治理；而是与风险和价值相称的相称治理，给明确的人明确的问责，并产出足够快、能够据以行动的诚实信息。本主题向你展示如何构建它，以及如何在其之上叠加独立保证，使问责人——以及公众——能够相信这些控制真正有效。它与主题 1.6——临床安全与风险管理、主题 1.7——信息治理、数据保护与网络安全、主题 5.3——EPPM，以及主题 10.4——为 CEO 和高级领导者提供可见性紧密相连。

核心概念#

治理（Governance）是一个机构用来指导和控制其所做之事的决策权、问责和监督体系。在数字卫生与照护中，你实际上是在同时管理三个重叠的治理领域。公司治理（Corporate governance）涵盖董事会对整个机构的管理——财务、战略、风险和法律责任。临床治理（Clinical governance）是卫生机构对持续改善照护质量和安全负责的框架。信息治理（Information governance）涵盖机构如何合法、安全、合乎伦理地处理数据。一项数字服务触及这三者；如果你只治理其中一个，你将被其他两个打个措手不及。

单点问责是良好治理的脊梁。高级责任人（Senior Responsible Owner，SRO）是对一个项目群或重大项目实现其目标并落实其收益个人承担全部责任的那一位具名个人——这个角色由英国政府推广，但在各处都很有用。SRO 之下的决策权通过责任分配矩阵（Responsibility assignment matrix）明确化，通常是 RACI（负责、问责、被咨询、被告知）形式，这防止了两种经典的失败："每个人都以为是别人负责的"和"每个人都想自己负责"。

保证（Assurance）与治理是不同的。治理是指导和决策的行为；保证是对治理和控制是否真正按预期运作的独立、客观确认。主流的思维模型是"三道防线"：第一道防线是日常拥有和管理风险的运营管理层；第二道防线是制定政策并提出质疑的监督职能（风险、合规、临床安全、信息治理）；第三道防线是独立于前两者、向董事会报告的内部审计（Internal audit）。外部监管机构和审计人员构成了事实上的第四道防线。

另外两个概念把这个系统凝聚在一起。风险偏好（Risk appetite）是机构在追求其目标的过程中愿意接受的风险数量和类型；没有它，上报就是随意的。而风险日志——常常扩展为一份建立在与风险登记册（Risk register）相同纪律之上的 RAID 日志（风险、假设、问题、依赖关系）——是使交付保持诚实的工作记录。审查点由诸如阶段关卡流程（Phase-gate process）这样的分阶段保证提供，在英国政府中，则由 Infrastructure and Projects Authority（IPA）运行的关口式审查提供。在任何单一项目层面之上，坐落着企业风险管理（Enterprise risk management），这是识别和管理可能阻止整个企业实现其目标的风险的组织范围纪律，而不是把数字、临床、财务、网络和运营风险当作各自独立的孤岛来对待。

最佳实践#

1. 指定一位问责的 SRO，并且是真心的。 任命一位单一的、足够资深的个人，让其对结果个人承担责任，拥有做出决策的权力，并在该项目群中留任足够长的时间以便承担问责。把他们的问责写进职权范围和他们的目标之中。抵制把问责分散到一个委员会的诱惑——委员会提供建议并集体决策，但它们不能承担问责，因为共担的问责就是缺失的问责。

2. 让治理与风险和价值相匹配，而不是与日历相匹配。 一个小型、低风险的内部工具不需要与一份区域范围的电子病历相同的董事会、关卡和文书工作。设置层级，使低风险、低价值的工作流经轻量级的团队层面治理，而高风险或高价值的工作则吸引正式的董事会和独立审查。发布这些门槛，让团队知道自己处于哪个层级，能够自助判断。相称性正是防止治理变成团队绕道而行的瓶颈的关键。

3. 撰写明确决策权的职权范围。 每个董事会都应该有一份简短的职权范围文档，说明其宗旨、成员、法定人数、它能做出哪些决策、它只能提出建议的事项，以及必须上报到它之上的事项。把它与一份 RACI 配对，使反复出现的决策类型——架构选择、临床签核、预算释放、上线批准——都有一位具名的问责所有者。模糊的决策权是治理漂移的最常见单一原因，会议在此时不断增加，因为没有人确定谁真正能说"批准"。

4. 将保证与治理分开，使用三道防线。 不要让交付一个项目群的人成为唯一确认它是安全的人。确保第二道防线——临床安全官、信息治理负责人、网络安全——拥有独立的声音，并能在需要时越过 SRO 上报，内部审计能够定期检验整个系统。正是这种分离把乐观的自我报告变成了可信的保证，这在大多数卫生系统中是一项监管期望，而不是一种客气。

5. 使用集成保证和分阶段审查点。 与其委托不协调的审查，不如规划一份集成保证和批准时间表，使临床安全、信息治理、技术和商业审查对齐到相同的决策点。在重要的过渡点——在承诺资金之前、在构建之前、在上线之前——采用关口式审查，以 IPA 关口审查为模型，对于面向公众的数字服务，则采用 Government Digital Service（GDS）开创、后由 NHS 采用的服务评估。一次好的关卡是一种能为下一阶段降低风险的支持性质疑，而不是一场要被蒙混过关的考试。

6. 明确风险偏好，并让它驱动上报。 在董事会层面就每个领域——患者安全、数据、交付、财务、声誉——你愿意承担多少风险达成一致，并把它表达得足够具体，使一个团队能够判断一项特定风险是在偏好范围之内还是之外。然后将上报与偏好连接起来：任何超出偏好范围的都自动上报，配有具名的负责人和一个决策截止日期。这防止了两种失败模式：琐事堵塞董事会，以及严重风险悄悄地待在一份电子表格里。

7. 维护一份实时的 RAID 日志和一份 Board Assurance Framework。 维护一份每个交付周期都会被审查的 RAID 日志，每一条条目都有负责人、有日期、有评分并被积极处理——而不是一堆停滞不前的琥珀色条目的墓地。在机构层面，维护一份 Board Assurance Framework（BAF），将你的主要战略风险映射到已就位的控制措施，以及你对这些控制措施有效性的保证，揭示出你正在依赖希望的那些缺口。BAF 让一个董事会能在一页纸上看到，其最重要的目标是否真正受到保护。

8. 诚实报告，扼杀治理表演。 坚持要求能够及早揭示坏消息的坦诚状态报告，并保护那些提出坏消息的人。留意"西瓜式报告"——外表绿色、内里红色——仪表板保持绿色直到失败的那一刻；用保证职能和交付负责人依据同一份事实进行报告来对抗它。砍掉任何不改变决策的会议、模板或报告。产出没有人据以行动的文档的治理，不是谨慎，而是伪装成尽职调查的浪费。

9. 在企业层面、而不仅仅是项目层面管理风险。 持有一份董事会层面的企业风险登记册和一份书面的风险偏好声明，将数字、临床、财务、网络和运营风险连接起来，而不是把每一个都当作各自独立的孤岛来对待。许多真正击垮数字卫生服务的风险——一片老化的遗留系统资产、一次网络攻击、对单一供应商的过度依赖——横跨每一个项目，却不被任何一个项目所拥有，因此要为每一项跨领域风险指定一位具名的高管负责人，并在登记册中给它一个位置。这就是"知道你的每个项目群大致都在正轨上"与"知道整个机构是否在其偏好范围之内"之间的区别。

10. 将同样的风险汇总到董事会，而不加以粉饰。 布线你的三道防线，使一个交付团队看到的风险，能够以可辨认的形式一路汇总到企业登记册，而不是在每一层都被重新包装成令人安心的语言。BAF 和企业登记册的诚实程度，取决于其下方报告的诚实程度，因此要防范西瓜效应，即琥珀色在通往顶层的路上变成绿色，并使上报诸如遗留系统、网络、供应商集中度这样没有任何单一项目拥有的跨领域风险成为常规做法。一个只看到汇总、被软化数字的董事会，无法治理最重要的那些风险。

与团队讨论的问题#

1. 在我们最重要的数字化工作中，单点问责在哪些地方真正清晰，在哪些地方是一种舒适的虚构？ 逐一审视你的前三大举措，问对于每一个，如果它失败了，谁会亲自向董事会负责。如果诚实的答案是"董事会"、"这个项目群"，或一个不断变化的名字，你就有了一个缺口。检验这位具名的 SRO 是否真的拥有这个角色所要求的权威和时间，还是他们只是一个傀儡，真正的决策发生在别处。考虑问责是否被一个 SRO 无法指挥交付人员的矩阵所削弱。讨论当 SRO 离任时连续性如何被保护，因为每次重组都会重置的问责根本不是问责。目标不是指责个人，而是确保当出问题时，有一位被赋权的人负责把它纠正过来。

2. 我们的治理是否相称，还是我们对低风险工作施加了重量级流程、反之亦然？ 将你目前的董事会、关卡和批准步骤对照通过它们的工作的实际风险和价值进行绘图。寻找那个为了一个每月开一次会的董事会等了六周的低风险变更，以及那个仅凭一个团队自己的一句话就溜过去的高风险临床变更。问团队是否因为治理太慢而绕道而行，这本身就是一个严重的风险信号。考虑你是否已经发布了清晰的层级和门槛，还是出于谨慎，一切默认走最大礼仪。辩论在哪里你可以安全地下放决策以加快速度，在哪里你一直危险地轻率。目标是一个治理的分量能明显跟随风险分量的系统。

3. 我们如何知道我们的报告是在告诉我们真相？ 讨论最近具体的、状态几乎没有预警就从绿色变为红色的例子，问早期信号是什么、为什么没有浮现出来。探讨交付负责人和保证职能是依据相同的事实进行报告，还是依据两个分开的、恰好有分歧的版本。考虑在这里报告红色状态的人，从社会和职业角度会发生什么——他们会得到感谢还是惩罚？问你的董事会是否既看到独立保证，也看到管理层自己的说法，还是只看到后者。审视你的仪表板衡量的是能够预测问题的东西，还是只是容易被弄成绿色的东西。目的是建立一种诚实的坏消息能够快速传递的文化，因为一个听不到坏消息的治理系统无法治理。

4. 我们是否把风险偏好写得足够具体，使一个团队能够据此行动，还是它只是一句口号？ 拿你某个项目群中一项活跃的风险，问最接近它的人能否从你所陈述的偏好中判断出它是在界线之内还是之外。大多数机构都有一份读起来很好、却什么都决定不了的风险偏好声明——"我们对风险采取平衡的态度"没有告诉任何临床医生一个未被检测到的过敏显示缺陷是否可以容忍。讨论偏好是否按领域表达——患者安全、数据、交付、财务、声誉——因为一个单一的全局数字，会掩盖你可能对临床安全缺陷零容忍、而对进度延迟有真实容忍度这一事实。审视上报是否真的与偏好相连接，使任何超出偏好范围的都自动上升，配有具名的负责人和一个截止日期，而不是取决于某人选择去提出它。考虑谁拥有这份偏好，以及多久重新审视一次，因为一份设定一次却从不重新审视的偏好，会逐渐脱离现实世界。一个诚实的答案会指明一项最近真正被偏好声明所塑造的决策，并承认这份声明目前在哪些地方过于含糊而失去作用。

5. 我们的关卡和保证审查是否真的有牙齿，还是失败的项目群一帆风顺地通过了它们？ 回顾你最近几次关口或服务评估审查，问其中是否有任何一次真正停止、暂停，或实质性地重塑了工作——如果每一个项目群都通过了每一个关卡，你的关卡几乎肯定是表演。讨论审查是否被当作一种为下一阶段降低风险的支持性质疑，还是一场要被蒙混过关的考试，证据包被精心策划以确保通过。考虑临床安全、信息治理、技术和商业保证是否到达相同的决策点，还是作为一堆不协调的审查零散出现，耗尽了团队精力，却没有增加信心。审视一位关卡审查人实际拥有什么权威：他们能否拦下一次上线，如果他们这样做了会得到支持吗，还是商业压力会凌驾于他们之上？探讨交付的人是否实际上也是保证的人——因为由乐观主义者运行的关卡不是保证。目标是一次严重问题无法幸存的审查，因为一个从不曾让任何东西不通过的关卡，是一项没有控制作为支撑的成本。

6. 真正可能击垮我们的那些风险中，哪些没有被任何单一项目拥有，谁拥有它们？ 列出最可能阻止你数字服务的失败——一片老化的遗留系统资产、一次网络攻击、对一个供应商的过度依赖、一支无法操作新工具的员工队伍——并问，对于每一项，它记录在谁的登记册上。这些跨领域风险之所以危险，正是因为它们属于每个人，因此不属于任何人，掉落在项目层面治理的裂缝之间。讨论你是否持有一份连接数字、临床、财务、网络和运营风险的董事会层面企业风险登记册，还是每一项都在各自的孤岛中被管理，对其他的视而不见。考虑一个交付团队看到的风险，是否以可辨认的形式一路上升到董事会，还是在每一层从红色被软化为琥珀色，再到绿色，直到董事会只看到令人安心的结果。审视每一项跨领域风险是否都有一位具名的高管负责人，拥有跨项目群行动的权威。一个诚实的答案会正视"知道每个项目群大致在正轨上"与"知道整个机构是否在其偏好范围之内"之间的差距。

实践中：一个卫生与照护案例#

一个整合照护系统（ICS）正在推行一份共享照护记录，让医院、全科和社会照护领域的临床医生能够查看每位患者的统一视图。这项工作既高价值又高风险：它触及临床决策，跨组织连接敏感数据，并服务于一个数字可及性差异巨大的人群。

早期，问责是混乱的。三位首席信息官各自感到部分责任，一个供应商在驱动时间表，一个由十八人组成的项目群委员会把会议时间花在接收更新上，而不是做决定。报告是绿色的。然后一次险情浮现：一份在一个系统中记录的药物过敏，没有在另一个系统中显示，一位临床医生差一点就给患者开了一种他们过敏的药物。

各位首席执行官把这当作一个转折点，重建了治理。他们任命了一位 SRO——一位拥有足够资历来指导这个项目群、拥有地位来挑战供应商的首席医疗官。他们重写了董事会的职权范围，把它精简到决策者，并附上一份 RACI，使临床安全签核、信息治理批准和上线授权各自都有一位具名的问责所有者。风险偏好被明确化：对未被检测到的临床安全缺陷零容忍，对进度延迟有限度容忍。这一句声明重新排序了一切。

保证与交付被分开。临床安全官和信息治理负责人独立报告，能够越过 SRO 上报给各位首席执行官；共享记录的工作被加入每个合作伙伴的 Board Assurance Framework。一份集成保证时间表设置了三个关卡——在进一步构建之前、在试点之前、在全面推广之前——每一个都结合了临床安全、信息治理、技术和无障碍性审查，秉承 IPA 关口审查和 NHS 服务评估的精神。RAID 日志每两周审查一次，过敏显示缺陷被记录为一个具名负责的红色问题，有一个固定的解决日期。

第一个关卡令人不适：审查团队发现临床安全案例比绿色报告所暗示的要单薄，推广被暂停了四周。这正是旧报告所隐藏的那个西瓜。因为暂停发生在试点之前，而不是上线之后，没有任何患者受到伤害，供应商修复了数据映射，最终的推广开始得较慢，但安全得多，也更受信任。治理没有拖慢交付；它防止了一次本会彻底阻止交付的失败。

行业视角#

初创企业#

一家健康科技初创企业很少需要董事会和关口审查，但它确实需要早期具备基本要素，因为监管机构、买家和投资人会问起。指定一位对临床安全负责的问责创始人或高管，一位对数据保护负责的，保持一份轻量级的 RAID 日志，即使只有一页也要写下你的风险偏好。陷阱在于把治理当作可以之后补装的东西；在一个快速移动的产品中回溯性地补配安全、合法决策的证据是痛苦的，有时是不可能的。构建一位认真的 NHS 买家能够认可的最小可行治理，让它与你一起成长，而不是一夜之间从空白猛跳到官僚体制。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院，或一家单点诊所——承担着与一家大型信托机构相同的临床安全和数据保护法定责任，却没有审计委员会、没有内部审计，往往也没有专职 IT 人员来运行它们。这里的治理纪律是彻底的相称性：一位具名的临床安全问责人，一位信息治理问责人（在一个非常小的机构中，可能是同一位高级临床医生或合伙人），一页纸的风险偏好，以及一份真正被审查、而不是被归档的简短 RAID 日志。依靠你的监管机构已经期望的框架——Data Security and Protection Toolkit、CQC 要求，以及你的供应商必须满足的任何临床安全义务——并让你软件供应商的保证（他们的 DCB0129 安全案例、他们的认证）为你完成你自己无法完成的工作。现实的陷阱不是治理表演，而是治理忽视：安全、合法的决策被非正式地做出，从不被记录，因此当一起事件或一次检查到来时，你无法展示你决定了什么或为什么决定。保持证据链轻量但真实，因为对一家小型企业而言，目标是在有限资源下做出站得住脚的决策，而不是一台你无法配备人手的治理机器。

大型机构#

一家大型服务提供者或供应商已经拥有董事会、审计委员会和内部审计，因此大型机构的风险与初创企业的相反：治理过多、整合不良、产生表演。整合重叠的董事会，发布相称性层级，把临床、信息、技术和商业保证整合到一个单一时间表中，使团队面对一套连贯的关卡，而不是十几个不协调的审查。确保三道防线真正独立，内部审计定期检验数字交付，而不仅仅是财务。这份回报是把一台现有的、昂贵的治理机器变成一台真正加速安全决策的机器。

政府#

国家和区域机构——NHS England、ICB、独立法定机构——在法定问责、公共支出控制，以及诸如 IPA 关口审查和政府的支出控制与服务评估流程这样的正式保证制度之下运作。在这里，SRO 角色是被编纂成文的，个人对议会或其对应机构负责，透明度是一项义务，而不是一种选择。这里的纪律是让这种强制性治理变得相称，并协调众多外部保证要求，使它们为交付提供信息，而不仅仅是事后审计它。做得好，公共部门治理是一个问责的典范；做得不好，它就是整个行业所担心的"治理表演"的源头。

常见失败模式#

• 委员会式问责。 没有单一的 SRO，因此出问题时每个人都指向旁边，没有人拥有它。
• 治理表演。 接收而不是决策的董事会、没有人读的模板，以及作为一场要被通过的考试、而不是真正降低风险的关卡。
• 西瓜式报告。 状态保持绿色直到失败的那一刻，因为坏消息不受欢迎，交付报告未受到保证职能的质疑。
• 一刀切的流程。 重量级治理被套用到琐碎的工作上，驱使团队绕道而行，而真正有风险的工作却轻易溜过去。
• 保证被交付所俘获。 建造这项服务的人是唯一确认它安全的人，因此乐观主义不受检验。
• 停滞的 RAID 日志。 风险被记录一次却从未被处理；琥珀色条目在一次审查前悄悄变绿，底下却没有任何变化。
• 领域盲区。 很好地治理了交付，却错过了临床安全、信息治理或公平性维度，直到它变成一场危机。
• 没有牙齿的关卡表演。 审查点从未真正停止或重塑工作，因此失败的项目群一帆风顺地通过了每一个关卡。

成熟度模型#

检查清单#

• 每一项重大举措都有一位具名、足够资深、被赋权的 SRO。
• 每个董事会都有当前的职权范围，说明其决策权、法定人数和上报路径。
• 一份 RACI 为每一种反复出现的决策类型指定了一位具名的问责所有者。
• 治理层级与风险和价值相匹配，门槛已被发布。
• 三道防线已就位，有一个能够上报的独立第二道防线声音。
• 一份集成保证时间表将临床、信息治理、技术和商业审查对齐到分阶段的关卡。
• 风险偏好已按领域写明，上报与之相连接。
• 一份实时的 RAID 日志在每个交付周期都被审查，每条条目都有负责人和日期。
• 一份 Board Assurance Framework 将主要风险映射到控制措施、以及这些控制措施有效性的保证。
• 交付和保证依据相同的事实进行报告，提出坏消息是安全的。
• 你保留的每一次会议、每一份模板和每一份报告都会改变一个真实的决定。

关键资料来源#

• Infrastructure and Projects Authority（IPA），《项目成功的原则（Principles for Project Success）》及关口/保证审查指导——英国内阁办公室 / HM Treasury。
• NHS England，《临床风险管理标准（Clinical Risk Management Standards）》（DCB0129 和 DCB0160）——用于卫生信息技术的临床治理（另见主题 1.6）。
• Institute of Internal Auditors（IIA），《IIA 三道防线模型（The IIA's Three Lines Model）》（2020 年更新）——三道防线方法的权威声明。
• HM Treasury，《橙皮书：风险管理——原则与概念（The Orange Book: Management of Risk — Principles and Concepts）》——英国公共机构中的风险偏好、控制和保证。
• NHS England / 前 Government Digital Service，《服务标准（Service Standard）》及服务评估指导——面向公众的数字服务保证。
• UK Corporate Governance Code——Financial Reporting Council——董事会问责和内部控制。

参考文献#

1. Governance — Wikipedia — https://en.wikipedia.org/wiki/Governance
2. Corporate governance — Wikipedia — https://en.wikipedia.org/wiki/Corporate_governance
3. Clinical governance — Wikipedia — https://en.wikipedia.org/wiki/Clinical_governance
4. Information governance — Wikipedia — https://en.wikipedia.org/wiki/Information_governance
5. Senior responsible owner (Executive sponsor) — Wikipedia — https://en.wikipedia.org/wiki/Senior_responsible_owner
6. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
7. Assurance services — Wikipedia — https://en.wikipedia.org/wiki/Assurance_services
8. Internal audit (Three Lines model) — Wikipedia — https://en.wikipedia.org/wiki/Internal_audit
9. Risk appetite — Wikipedia — https://en.wikipedia.org/wiki/Risk_appetite
10. Risk register — Wikipedia — https://en.wikipedia.org/wiki/Risk_register
11. Phase-gate process — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
12. Infrastructure and Projects Authority — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_and_Projects_Authority
13. The IIA's Three Lines Model — Institute of Internal Auditors — https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/
14. The Orange Book: Management of Risk — Principles and Concepts — HM Treasury — https://www.gov.uk/government/publications/orange-book
15. Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems (DCB0160) — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Service Standard — Government Digital Service / GOV.UK — https://www.gov.uk/service-manual/service-standard
17. The UK Corporate Governance Code — Financial Reporting Council — https://www.frc.org.uk/library/standards-codes-policy/corporate-governance/uk-corporate-governance-code/
18. Enterprise risk management — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_risk_management