主题 3.5 — 交付生命周期

一句话概括: 交付生命周期是一项数字服务所经历的一系列阶段与决策关口——探索、Alpha、Beta、上线,以及最终的退役——临床安全、信息治理与保证工作贯穿每一个阶段,而不是在最后才被附加上去。

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

生命周期是一个机构把一个想法转化为一项安全的、运行中的服务、并最终负责任地退役它的方式。在医疗与照护领域,每一次转换都承载着法定与临床上的分量:你不能在没有临床安全论证的情况下部署一个触及患者照护的系统,也不能在没有合法依据、没有完成数据保护影响评估(DPIA)的情况下处理保密患者数据。一个把这些当作项目末端文书工作的生命周期,会产出既延迟又不安全、或两者兼而有之的服务。

其利害关系是不对称的。一款消费应用发布了一个错误会惹恼用户;一份共享照护记录发布了一个错误,可能向一位临床医生展示错误患者的过敏史。这正是为什么 NHS 把 GOV.UK 阶段模型与临床风险管理标准 DCB0129 及 DCB0160 一同嵌入同一个生命周期。把生命周期做对不是一种治理上的美德——它是安全、公平与公共资金物有所值真正被交付、而不仅仅是被承诺的机制。

领导者也需要这个生命周期,因为它让进展变得可读。具名的阶段与关口让董事会能够看到一项服务处于什么位置、存在什么证据,以及有什么决策到期——把"快做完了"这样的迷雾,替换为一个站得住脚的、分阶段的公共资金承诺。

核心概念#

阶段模型:探索 → Alpha → Beta → 上线。 NHS 与 GOV.UK 的服务标准定义了四个阶段。探索(见主题 3.4——探索阶段)理解问题。Alpha 构建一次性原型来测试一个解决方案是否可能有效,并消解风险最高的假设。Beta 在生产基础设施上构建真实的服务,先私下、后公开,随着真实用户的使用规模不断增长而迭代。上线让这项服务持续运营,依然在迭代,直到它被退役。这些阶段是一个降低风险的坡道:每一个阶段都投入更多资金、暴露更多用户,由上一阶段的证据来证明其合理性。

持续迭代,而不是一条传送带。 这些阶段不是单向的瀑布式流程。一项处于 beta 阶段的服务,可能为了一个困难的功能而循环回到 alpha 阶段;一项运行中的服务会持续迭代。这个模型的价值在于它的关口,而不是承诺工作会单向流动。

敏捷、瀑布与混合模式。 *瀑布模型预先固定范围,并按顺序进行——仅适用于需求真正稳定且可知的地方(一次数据中心迁移、一项强制性的监管变更)。敏捷*以小增量交付,检视并调整——适合面向用户服务的不确定性。混合模式是大多数大型医疗项目的诚实现实:敏捷产品团队在一个机构及其监管机构所要求的里程碑与资金框架内运作。让方法与不确定性相匹配,而不是与潮流相匹配。

服务评估与标准关口。 在阶段之间的过渡处——尤其是从 alpha 到 beta,以及公开发布之前——NHS 与 GOV.UK 服务要面对一次服务评估:一个独立小组依据服务标准的各项要点(用户需求、无障碍性、安全性、可靠性、团队、技术选择)来检验这项工作。通过是花更多钱、暴露更多用户的关口。这个评估是基于证据的同行评审,而不是橡皮图章。

临床安全与信息治理作为生命周期主线。 DCB0129(面向制造商/供应商)与 DCB0160(面向部署的医疗或照护机构)要求一套临床风险管理体系、一份危害日志,以及一份由一位具名、受过培训的临床安全官(CSO)签核的临床安全论证报告。信息治理要求一个合法依据、一份 DPIA,以及对 Caldicott 原则的遵循。两者都是贯穿探索、alpha、beta 与上线的主线——而不是末端的关口。

退役。 一个生命周期有一个终点。安全地退役一项服务——依据保留法迁移或归档数据、重新引导用户、通知临床医生,并保存记录——本身就是一个阶段,也是最容易被忽视的阶段之一。

最佳实践#

1. 把这些阶段当作降低风险的关口,而不是日历里程碑来使用。 让每个阶段的决定是"是否有足够的证据来证明投入下一批资金与用户是合理的?"一个因为日期到了、而不是因为证据齐备而结束的阶段,就错过了这道关口的意义。

2. 从 alpha 阶段起、而不是上线之前,就把临床安全编织进去。 一旦一个解决方案的雏形出现,就任命一位临床安全官,并开启危害日志。在 alpha 阶段被识别出的危害,设计消除的成本很低;在上线时才被发现的危害,则是一场阻碍发布的危机。安全论证与服务一同成熟,因此 DCB0129/0160 的签核是对已完成工作的总结,而不是一场临时抱佛脚。

3. 在探索阶段就开始 DPIA 与信息治理工作,并保持它鲜活。 数据流、合法依据与 Caldicott 方面的考量塑造着架构,因此要在架构还未定型时就让它们浮出水面。一份在构建之后才写的 DPIA 是一次文书工作;一份与设计同步撰写的 DPIA,能真正降低风险,防止返工。

4. 用 CI/CD 与 DevOps 让通往生产环境的路径自动化。 持续集成与持续交付——自动化的构建、测试与部署流水线——让一个团队能够安全、频繁地发布小而可逆的变更。在一个安全攸关的领域,能够在几分钟内部署一个修复、并干净利落地回滚,其本身就是一项安全管控。把它与监测、告警与基础设施即代码配对,让运行中的服务变得可观测、可复现。

5. 让方法与不确定性相匹配。 在用户需求不确定、探索阶段仍在教你新东西的地方使用敏捷;只在需求真正固定、变化风险很低的地方才接受瀑布式的顺序安排。要明确地表明你在运行一种混合模式——一个程序框架内的敏捷团队——而不是假装某一种方法统治一切,那样谁也骗不了,只会让每个人都感到沮丧。

6. 把服务评估当作一种设计工具,而不是一场考试。 及早且频繁地让保证、临床安全、安全性与无障碍性方面的审查人员参与进来,这样正式的评估只是确认一项已经按标准构建好的服务。那些在评估前一周才第一次达到标准的团队,会缓慢而代价高昂地失败;那些内化了这个标准的团队,通过评估只是一个副产品。

7. 在上线阶段持续迭代——并为它配置资源。 一项服务上线之后,依然需要一个团队。上线阶段正是真实使用暴露出最后的不平等、罕见但严重的临床边缘情形,以及无障碍性缺口的地方。为这项服务的运营生命周期资助一支常设的产品团队(见主题 5.0——以产品为主导的工作);一项没有团队的线上服务,是正在累积临床风险的技术债。

8. 在需要退役之前就规划好它。 在构建时就决定这项服务最终将如何被退役:依据记录管理法进行数据保留与迁移、用户重新引导、临床医生通知,以及临床安全论证与审计轨迹的归档。一次没有规划的退役会让数据与用户搁浅;一次有规划的退役则是一个受控的、可审计的阶段。

与团队讨论的问题#

1. 我们的阶段关口真的是由证据治理的,还是它们已经悄悄变成了计划上的日期? 探索-Alpha-Beta-上线模型的全部价值,在于每一次过渡只有在上一阶段的证据证明其合理时,才投入更多资金、暴露更多用户;一旦一道关口是因为一个季度结束、而不是因为证据齐备而触发,这个坡道就不再降低风险,变成了"披着敏捷外衣的瀑布"。这个问题要求团队诚实地审视自己最近几次过渡,追问如果证据说"还没到时候"会发生什么——是否有空间可以暂停、让一个 beta 循环回 alpha 阶段处理一个困难的功能,还是上线日期在政治上不可动摇?值得讨论的张力,在于机构对可读的、按董事会日程安排的里程碑的需求,与安全的服务是按证据的节奏移动这一现实之间的矛盾,混合式交付恰恰生存于这种摩擦之中。具体的切入点包括说出下一道关口应有的具体决策与证据,检查"冲刺"是否真的改变了范围、还是仅仅在追踪一个固定的计划,并追问谁有权延迟一道关口而不承担职业风险。一个好的答案能够指出一个证据确实改变了计划的真实案例,并能阐明什么样的证据会证明——或阻止——下一次公共资金与用户的投入是合理的。

2. 临床安全与信息治理是贯穿每个阶段的活的主线,还是我们打算在上线之前完成的文书工作? 在医疗与照护领域,DPIA 与 DCB0129/0160 临床风险工作,不是项目末端的签核,而是必须从 alpha 阶段起就塑造架构与设计的主线,因为一个早期就被设计消除的危害成本低廉,而一个在上线时才被发现的危害,则是一场阻碍发布的危机——或者更糟,是一种迫使人们草率放行安全论证的压力。这个问题揭示出,一旦一个解决方案的雏形出现,一位具名、受过培训的临床安全官与一份开启的危害日志是否存在,以及 DPIA 与合法依据分析是否在探索阶段、数据流还足够柔软可以改变的时候就已经开始。值得讨论的取舍,是持续这样做所感受到的拖累,与事后补救的代价高得多、临床风险大得多之间的对比,对于尚未受到监管机构关注、但 DCB0129 义务无论公司规模如何都依附于制造商的小团队或初创企业而言,这一点尤其如此。考虑具体的证据:危害日志是否显示了在 alpha 阶段被发现并缓解的危害,安全论证读起来是否像是对已完成工作的总结,DPIA 是否能追溯到真实的设计决策?一个诚实的答案会区分一个正随服务同步让安全论证走向成熟的团队,与一个正走向发布前一个月文书工作大乱斗的团队。

3. 这项服务在上线阶段将如何运行,最终又将如何退役——谁获得资助来做这件事? 生命周期有一条机构常常资助不足的长尾:上线阶段正是真实使用暴露出最后的不平等、罕见但严重的临床边缘情形与无障碍性缺口的地方,它需要一支常设的产品团队、监测,以及快速、可逆的部署,而不是一个在上线时就解散、让服务腐烂并悄悄累积临床风险的团队。同样被忽视的是退役——依据记录保留法退役一项服务、迁移或归档数据、重新引导用户、通知临床医生,并保存危害日志与审计轨迹——对一个国家级系统而言,这本身就是一个重大项目,而不是替代品到来时的事后补充。值得讨论的张力,是年度资金周期与在发布时宣布一个项目"已完成"的压力,与一项安全服务真正需要的全生命周期所有权之间的矛盾。有用的切入点包括,一条带有监测与快速回滚的 CI/CD 流水线是否被当作一项线上安全管控来对待,待命与迭代预算是否在上线庆祝之后依然存在,以及一份退出计划是否在构建时就被写下、而不是在恐慌中临时拼凑。一个好的答案会说出谁在服务的运营生命周期内拥有它,并描述一次受控的、可审计的退役,而不是寄希望于以后会有人处理它。

4. 我们上一次让一个原型的失败真正阻止我们,是什么时候?我们是否依然在构建将被丢弃的东西? Alpha 阶段存在的意义,是廉价地消解风险最高的假设,这意味着一个失败的一次性原型已经完成了它的使命:它在生产资金与真实患者被投入之前,买到了一堂代价高昂的教训。这个问题探究的是,一个团队是否真的把 alpha 阶段当作一次性的学习来对待,还是因为丢弃代码感觉像是浪费,而悄悄地把第一个原型打磨成了最终产品——这是一种沉没成本陷阱,把一个降低风险的阶段变成了一次盲目做出的、代价高昂的承诺。值得揭示的张力,是"要有东西可展示"、复用每一行写过的代码的压力,与在生产基础设施上构建真实产品之前先证明一个解决方案可能有效这一纪律之间的矛盾。具体的切入点包括追问上一次 alpha 阶段实际测试了哪些假设,是否有任何原型曾依据证据被放弃,以及私有 beta 版的构建是否复用了本应被重写为生产标准的一次性代码。一个诚实的答案能够指出一个原型扼杀或证实的具体假设,并能区分团队愿意丢弃的学习成果,与它现在正在上线运行的经过保证的代码。

5. 我们运行的是一种诚实的混合模式,还是几种互相悄悄矛盾的伪装方法? 大多数大型医疗项目实际上都是混合的——敏捷产品团队在一个机构及其监管机构所要求的里程碑与资金框架内运作——失败之处不在于混合本身,而在于假装它是纯粹的敏捷或纯粹的瀑布,导致这两种逻辑在每一道关口都未经管理地相互碰撞。这个问题要求团队说出固定的、按顺序排列的承诺实际上在哪里(资金批次、监管里程碑、集成冻结),以及真正的迭代发生在哪里,而不是让"敏捷"与"计划"各自宣称拥有整个项目、让每个人都感到沮丧。值得讨论的取舍,是机构对可预测里程碑与可审计支出的合理需求,与交付团队依据证据改变范围的需求之间的矛盾,而诚实的做法是明确接缝所在,这样双方都能据此规划。有用的切入点包括,积压清单的重新排序是否曾经在与项目计划的碰撞中存活下来,供应商是否被按固定范围签约、却被要求迭代式地工作,以及董事会看到的报告是否与工作实际的完成方式相符。一个好的答案会描述一种刻意设计的混合模式,有具名的固定点与具名的灵活空间,而不是一种方法只是为了表面好看而被声称的混乱局面。

6. 我们对一项线上服务此刻正在对其用户做什么,了解得有多好?我们会在用户报告伤害之前就发现它吗? 一项线上医疗服务的安全性,取决于它的可观测性:监测、告警,以及把一项指标转化为一个危害的临床安全直觉,决定了在几分钟内发现一个陈旧数据缺陷、与几周后才从一份事故报告中得知它之间的区别。这个问题审视的是团队能否看到生产环境中的服务——错误率、集成失败、无障碍性流失、只有真实使用才能揭示的公平差距——以及是否有人带着临床风险的意识在关注仪表盘,而不仅仅是基础设施的正常运行时间。张力在于恰当的可观测性与待命所需的成本与纪律,与"没有消息就是好消息"这种一旦服务上线就悄悄存在的假设之间的矛盾,而在一个安全攸关的领域,这正是无声伤害积累的方式。具体的切入点包括,危害日志是否根据线上事故被更新,告警是否映射到临床影响、而不仅仅是服务器健康状况,以及一次糟糕的发布能否在触及许多患者之前被侦测并回滚。一个诚实的答案会描述团队关注的具体信号、监测曾捕获(或错过)的一次真实事故,以及线上证据如何反馈进下一次迭代。

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

一家社区 NHS 信托机构正在替换一个用于社区护士出诊排期的、基于纸张与电子表格的遗留系统。从探索阶段(主题 3.4)走出来后,团队进入alpha 阶段,构建了两个一次性原型来测试风险最高的假设:护士会在患者家中使用手机,以及排期表能与电子病历集成。一位临床安全官在 alpha 阶段第一天就被任命,并开启了一份危害日志;一个早期危害——一份陈旧的排期表显示一次已被同事完成的出诊——促成了一项设计决策,即显示实时同步状态。在探索阶段就开始的 DPIA,标记出独行工作者的位置数据需要一个明确定义的合法依据与保留期限。

在从 alpha 到 beta 的服务评估中,一个独立小组探究了无障碍性(有视力障碍的护士)、安全性,以及团队的推理过程。这项服务带着待办事项通过了评估。在私有 beta 阶段,十位护士在生产基础设施上使用真实系统;一条 CI/CD 流水线让团队能够每天发布,并在十分钟内回滚一次糟糕的发布。使用情况揭示出一个公平问题——没有信托机构设备的代理员工——导致了一个基于浏览器的后备方案。公开 beta 阶段扩展到三个地区;在更广泛的推广之前,临床安全论证报告依照 DCB0160 完成并获得签核。

这项服务带着一支常设产品团队、监测仪表盘,以及一个待命轮值表上线。十八个月后,当该信托机构采用一个区域平台时,这个排期系统被按计划退役:数据依保留计划表迁移,护士被重新培训并重新引导,危害日志与安全论证被归档以供审计。每一次过渡都是一个由证据支撑的决定,而不是甘特图上的一个日期。

行业视角#

初创企业#

一家初创企业的生命周期是压缩的,且很大程度上是自我治理的:没有独立的服务评估小组,因此 Alpha-Beta-上线关口的纪律必须自我施加,否则就会崩溃成"持续发布,寄予厚望"。优势在于一个小团队能够从第一天起就运行真正的 CI/CD,比任何大型机构都更快地迭代。危险在于,因为还没有监管机构在关注,就悄悄放弃了临床安全与 DPIA 主线——这在医疗领域是一个致命的错误,因为无论公司规模大小,DCB0129 义务都依附于制造商,一个未被管理的危害就能同时终结产品与公司。初创企业应当采纳阶段模型的意图——在暴露之前先有证据——即使没有那些仪式,一旦一个解决方案的雏形出现,就任命一位临床安全官(常常是兼职的)。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、社区药房、养老院,或单一场所诊所——通常是作为一个部署者、而不是构建者来遇到这个生命周期的:它正在采购或配置一个供应商的系统,因此即使没有内部数字团队,DCB0160 部署签核与一份本地 DPIA 也落在它身上。这些阶段依然适用,只是被压缩并外包:"alpha"是对少数真实患者进行的一次受监督的试点,"beta"是在诊所范围内的一次分阶段推广,"上线"就是日常业务,供应商的更新持续到达,而且在很大程度上不受诊所控制。该机构必须指定一位临床安全官(常常是一位临床合伙人在本职工作之外兼任这个角色),并为系统在本地是如何被使用的维护一份危害日志,因为制造商的 DCB0129 工作并不涵盖这次部署的具体风险。在现金紧张、没有专职 IT 的情况下,现实的纪律是依靠供应商的保证,同时拥有只有本地知识才能做出的少数几个决策——谁受过培训、系统宕机时的后备方案是什么,以及患者数据在这个具体环境中如何流动。

大型企业#

一家 NHS 信托机构或大型供应商以最完整、最有保证的形式运行这个生命周期:正式的服务评估、一位具名的临床安全官、DCB0160 部署签核、变更咨询委员会,以及敏捷工作必须适配的年度资金周期。典型的挑战是混合模式——敏捷交付团队在一个机构及其审计人员所要求的项目与里程碑框架内运作——经典的失败是"披着敏捷外衣的瀑布",关口悄悄变成了日历日期。大型企业拥有恰当地实现 CI/CD、可观测性与常设产品团队的资源,然而机构的惰性与遗留系统的集成,常常把部署拖慢成蜗牛速度。问责范围广泛,波及面大,因此从私有 beta 到上线的分阶段坡道不是可选的审慎之举,而是必不可少的风险管控。

政府机构#

一个国家机构在完整的服务标准、已发布的服务评估、支出控制,以及议会审视之下进行交付,因此每一道阶段关口同时也是一个公众问责的节点。这里的生命周期很长,暴露面巨大——一项全国性的 NHS 服务可能触及数百万人——这提高了分阶段坡道、临床安全保证,以及正在被替换的遗留系统退役的利害关系。采购规则与多年期资金安排塑造着"敏捷"在实践中能意味着什么,退役一个国家级系统(带着它几十年的记录与法定保留职责)本身就是一个重大项目。这里的取舍是保证与速度:政府交付有着重重关卡,这保护了安全与公共资金,却需要刻意的努力才能让团队保持迭代,而不是退回到前期大量设计。

常见失败模式#

• 披着敏捷外衣的瀑布。 团队运行"冲刺",但范围、日期与设计早已预先固定;迭代是一场表演。解药:让每道关口的证据真正改变计划。
• 安全性与信息治理在最后才被附加上去。 临床安全论证与 DPIA 在上线前一个月才被撰写,阻碍发布,或更糟,在压力之下被草率放行。解药:在 alpha 阶段开启危害日志与 DPIA,并持续让它们成熟。
• 大爆炸式发布。 服务跳过私有/公开 beta,直接进行全面推广,让每一位用户都暴露于未经验证的软件。解药:使用分阶段的坡道;依据证据扩大暴露范围。
• 被抛弃的线上服务。 交付团队在上线时解散;服务腐烂,临床风险悄悄累积。解药:为服务的运营生命周期资助一支常设产品团队。
• 临阵磨枪的评估。 标准被忽视,直到评估逼近,然后才被表面地满足。解药:持续地让保证与临床审查人员参与。
• 没有退出计划。 服务在替代品到来时被恐慌地退役,让数据与用户搁浅。解药:把退役规划为一个头等阶段。

成熟度模型#

检查清单#

• 这项服务有一个明确的当前阶段(探索/Alpha/Beta/上线)与一个具名的下一步决策。
• 阶段过渡由证据、而不是日期来把关。
• 一位临床安全官已被任命,一份危害日志从 alpha 阶段起就开启(DCB0129/0160)。
• 一份 DPIA 与合法依据评估(Caldicott、英国 GDPR)在探索阶段就已开始,并保持最新。
• 交付方法与不确定性的程度相匹配,任何混合安排都是明确的。
• 服务评估已被规划,保证/安全/无障碍性审查人员及早参与。
• 一条带有监测与快速回滚的 CI/CD 流水线在公开 beta 之前已经到位。
• 服务以分阶段的坡道(私有 beta → 公开 beta → 上线)、而不是大爆炸式地暴露给用户。
• 一支常设产品团队为这项服务的运营生命周期获得资助(见主题 5.0)。
• 一份退役计划涵盖数据保留/迁移、用户重新引导,以及安全与审计记录的归档。

关键来源#

• GOV.UK 服务手册 ——一个敏捷项目的各个阶段(探索、Alpha、Beta、上线)与政府服务标准。
• NHS England ——NHS 服务标准与 NHS 数字服务手册;NHS 服务评估。
• NHS England Digital ——DCB0129(临床风险管理:在健康 IT 系统制造中的应用)与 DCB0160(在健康 IT 系统部署与使用中的应用)。
• NHS England ——数字临床安全保证;临床安全官角色、危害日志与临床安全论证报告。
• NHS England ——数字技术评估标准(DTAC)。
• 英国 Caldicott 原则;《2018 年数据保护法》/ 英国 GDPR 与数据保护影响评估。
• NICE ——数字健康技术证据标准框架。
• DevOps 与持续交付实践(例如 DORA 能力:持续集成、部署自动化、监测);GOV.UK 服务手册关于持续交付与运营一项服务的指导。

参考文献#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health