软件工程卫生经济学

为什么这对卫生经济学很重要

每一个现代卫生机构,无论是否承认,都是一个软件运营者。患者记录、处方开具、排班、化验结果、支付理赔和人群监测,全都运行在代码之上——这些代码或从供应商那里购买,或在内部构建,或从前任那里继承,或是这三者拼凑而成。所涉及的资金规模庞大且反复出现:国家电子健康记录项目已经耗费了数十亿美元的公共资金,而卫生软件的运营成本——维护、集成、升级、安全——通常远远超过最初商业方案中出现的价格。然而,大多数卫生经济学培训对软件作为一种经济资产的行为方式只字不提,而大多数软件工程培训对一个同时购买护士和药品的系统中的机会成本也只字不提。

这一差距之所以重要,是因为软件会以普通采购思维无法察觉的特有方式在经济上失败。一个系统是依据其购买价格和演示功能而被购买的;集成、数据迁移和维护负担随后才会到来,而它们所对应的预算从未被咨询过。一段供应商关系逐渐固化为依赖,使每一次续约都是在弱势地位下进行谈判。在截止日期压力下所走的捷径会不可见地累积,直到运行医院的系统再也无法被安全地修改——到那时,机构面临一笔它从未规划、也无法推迟的现代化账单,因为这个软件现在承载着临床风险。包括英国国家信息技术项目(该项目于2011年被拆除,估计花费约100亿英镑)在内的大型卫生信息技术项目历史,正是这些动态在国家规模上的重演。

对管理者而言,其利害关系有三重。第一是资金:软件是一项全生命周期的承诺,购买时的廉价选项,常常在十年间成为昂贵的选项。第二是安全:在临床环境中,一次停机、一次数据错误,或一个无法维护的系统,不是一种不便,而是一种危害,其成本归属于主题3.11《质量与安全经济学》。第三是自主权:在自建与购买之间、在专有系统与开放系统之间、在标准接口与定制接口之间做出的选择,决定了该机构五年后拥有多大的行动自由——而正如本书通篇所论证的,行动自由本身就是一种经济资产。

核心概念

软件工程是对软件进行有纪律的设计、构建和维护——而"维护"一词承载着其中大部分经济学内容。与建筑物不同,软件永远不会完工:需求在变化,法规在变化,依赖项在老化,安全威胁在演变。软件维护——对一个正在服务的系统进行纠正性、适应性和预防性的工作——通常吸收了一个系统生命周期成本的大部分。因此,经济分析的单位从来都不应是购买本身;而应是总拥有成本:在系统现实的生命周期内,采购加上集成、数据迁移、培训、托管、支持、升级、安全和最终退役的全部成本。

第二个概念是技术债务:即现在选择一种权宜的设计而非一种稳健的设计所隐含的未来成本。这一隐喻足够精确,可以在财务会议上直接使用。债务本身并非天生就是坏事——一个刻意采取的捷径,能够更快地交付一项急需的能力,可以是一笔理性的借贷——但它会产生利息:由于这笔债务,系统未来的每一次变更都会花费更多,而不加管理的债务会不断累积,直到变更变得代价高昂或危险到令人却步。一个看不见自己技术债务的卫生机构,正背负着一笔未入账的负债,就如同它有未记录的借款一样。

第三,遗留系统:一种超过了经济上可维护的临界点、却仍在服务中的软件——往往是因为它能运行、所有人都依赖它,而替换它又令人望而生畏。遗留系统是组织规模上的技术债务,它带来一个真正的评估难题:维持它的成本(不断上升的维护费用、安全暴露风险、招不到的员工、别处被阻碍的改进)是分散且渐进的,而更换它的成本却是集中的、可见的,且具有政治风险。世界各地的卫生系统在关键服务上运行着数十年前的软件,原因正在于此。

第四,依赖性。供应商锁定是这样一种状态:更换供应商的成本——数据迁移、再培训、重新集成和临床中断——如此之高,以至于买方已经丧失了有效的议价能力。在卫生领域,数据使这一问题更加严重:十年的患者记录以专有格式保存,这本身就是一份人质。锁定效应并非偶然;它是一种定价策略,而为其定价的时机应在签约之前,而非续约之时。制衡手段包括合同层面的(数据导出权、托管、退出协助)和架构层面的——尤其是标准。

第五,互操作性:系统交换信息并使用所交换信息的能力。它的经济学正是网络效应的经济学——每一个使用共同标准的系统,都会提升所有其他使用该标准的系统的价值——这正是为什么互操作性长期被市场供给不足:收益归于整个系统,而成本却落在每一个供应商和买方身上,而一个在位者可以从不实现互操作中获利。诸如快速医疗互操作性资源(FHIR)、它所属的HL7标准族,以及openEHR这样的标准存在的目的,正是降低这些交换成本,而监管机构——例如美国通过《21世纪治愈法案》的信息阻断规则,欧盟通过欧洲卫生数据空间——已经开始强制要求市场未能提供的东西。

第六,自制与购买的光谱,包括开源软件——即源代码可自由使用和修改的软件。开源软件并非免费:许可费用消失了,但实施、托管和管理成本依然存在,必须有人来维护这些代码。它的经济特性有所不同——它消除了锁定溢价,并将软件转化为许多买方可以共同出资的公共物品,这正是为什么诸如DHIS2和OpenMRS这样的平台承担着中低收入国家健康信息负荷的很大一部分。同样,自制还是购买的决策,不是一种技术偏好,而是一个投资组合问题:在能力具有差异化优势、且机构能够真正维持一支工程团队的地方自建;在需求是标准化的地方购买;绝不要构建你无法维护的东西。

最后,可靠性作为一种经济量。临床软件运行着停机会带来健康成本的服务,因此维持系统可靠所需的工程学科——包括站点可靠性工程,它依据明确的目标来管理可靠性,并为可接受的故障编列预算——最好被理解为购买一种保险,其保费就是工程工作量。超出临床场景所需的可靠性是浪费;低于所需的可靠性,其差额会以事故的形式被支付。所有这一切的评估机制仍然属于主题2.1《经济评价》和主题2.5《预算影响与可负担性》的可负担性纪律;本主题提供的是这些方法所必须被输入的软件特有成本结构。将一款数字工具作为一项健康干预来评价——这个应用程序或远程医疗服务是否以可接受的成本改善了结果——属于主题5.2《数字健康经济学》的内容;而专门针对AI模型的经济学属于主题5.3《人工智能卫生经济学》的内容。

最佳实践

1. 在系统现实的生命周期内评估总拥有成本,而绝不仅仅评估购买价格。 应要求每一份软件商业方案,在一个明确的时间跨度内——通常是十年或更长——核算采购、集成、数据迁移、培训、托管、支持、安全、升级和退役的成本,并说明每一项反复出现的费用由哪个预算承担。一笔没有任何比较对象的许可费用算不上一份商业方案;它只是一份承诺的可见冰山一角。

2. 将技术债务记入账目。 应让工程负责人维护一份登记册,记录资产中重大的捷径和老化的组件,并诚实地估算每一项所产生的"利息"——更慢的变更、更高的事故风险、别处被阻碍的改进。应以对待一项财务负债同样的严肃态度来审查它,并为偿还它编列一份常设的工程能力份额(通常是五分之一到三分之一),因为被推迟的债务偿还会使债务不断累积。

3. 从第一天起就将维护作为一项运营成本来资助。 "已完成"的软件,其实是正在衰败的软件:依赖项在老化,威胁在演变,法规在变化。应将维护支出流纳入最初的评估和常规预算之中,并将一份没有维护预算项目的提案视为不完整——这笔钱无论如何都会被花掉,唯一的问题是它是被规划出来的,还是被一场危机榨取出来的。

4. 在签约之前而非续约之时为锁定效应定价。 对每一次重大采购,应在你仍有替代选择时核算退出的成本:谁拥有数据、能以何种格式导出、供应商必须提供何种退出协助,以及一次迁移的合理成本是多少。应在合同中谈判获得数据导出权和开放接口,并将供应商对此的抵触视为关于即将到来的续约谈判的一项信息。

5. 审慎地购买互操作性,因为市场对其供给不足。 应将支持开放标准——FHIR及其同类标准——作为采购条件,依据你实际的数据流(而非宣传册)核实所宣称的合规性,并在存在标准接口的地方拒绝定制接口。你所接受的每一个专有接口,都是你赠送给供应商的一项转换成本,也是对每一次未来集成的一种税负。

6. 将自制还是购买的决策作为一个投资组合来决定,并使其与你的工程能力相匹配。 只在能力具有差异化优势、且你能够切实招募、留住并资助一支团队来维护你所构建之物的地方自建——一个没有持续团队支撑的内部系统,只是一个多走了几步的遗留系统。购买标准化的需求;在有社区或公共联盟支撑的地方考虑开源平台;无论走哪条路,都要把可持续维护计划写入决策之中。

7. 将开源软件视为一种拥有自身成本结构的采购选项,而非免费的东西。 应依据总拥有成本对其进行比较:没有许可费用,但存在真实的实施、托管、支持和管理成本,无论是在内部承担还是通过一家支持供应商承担。应权衡它的独特优势——没有锁定溢价、代码可审查、能够与其他卫生机构共同出资维护一项公共物品——以及它的独特义务:如果你依赖它,就应为维持其可持续性做出贡献。

8. 依据临床后果设定可靠性目标,并按目标投入支出。 应逐项服务地决定,一小时的停机实际上会造成什么代价——延误的照护、不安全的变通做法,以及丧失的信任——并据此设定可用性和恢复目标。然后从两个方向都坚持这一目标:为低于诊所所需的可靠性投入支出,买到的是事故;为超出所需的可靠性投入支出,买到的是过度镀金。

9. 在遗留系统的更换被迫进行之前就加以规划。 应按周期审查关键系统的老化程度和可维护性,并在现有系统仍能运行时就启动更换——在故障状态下执行的迁移是代价最高昂的一种。应优先选择渐进式迁移(逐个接口"绞杀"旧系统),而非一次性切换,后者在卫生领域的失效模式,是以取消的诊疗和丢失的记录来计量的。

10. 使数据迁移成为每一份评估中的头等大事。 患者数据的寿命超过任何一个承载它的系统,而将其干净、完整、并确保临床安全地迁移出去,通常是任何转型中最大、也最被低估的成本之一。应明确地为其核算成本,尽早用真实记录进行测试,并在系统的整个生命周期内以可导出的形式保有你的数据控制权,使迁移永远不会受制于即将离开的供应商。

11. 将临床安全工程纳入经济学考量之中。 卫生软件是与安全相关的软件:变更需要测试,发布需要回滚路径,事故需要调查,而各司法辖区正日益对卫生信息技术施加正式的临床风险标准。这些学科会消耗工程时间,理应纳入商业方案之中——一种跳过这些环节的"更便宜"交付方式,是把成本以风险的形式转嫁给了患者(伤害的成本属于主题3.11《质量与安全经济学》的内容)。

12. 让软件决策接受与任何其他卫生投资相同的价值审查。 一个软件项目与药品和人员争夺同一笔有限的预算,因此它理应接受同样的纪律:一项明确的收益、一个真实的比较对象(包括"改进我们现有的东西")、一份随时间变化的可负担性概况,以及依据所做承诺进行的实施后审查(其机制属于主题2.1《经济评价》和主题2.5《预算影响与可负担性》,而采购技艺属于主题3.10《战略性购买与购买规划》)。

需要与团队讨论的问题

1. 我们的软件资产每年的真实成本是多少,我们规划了其中的多大份额? 大多数机构能说出自己的许可费用,却说不出集成、维护、安全和变通做法的成本,这些成本隐藏在整个组织的运营预算和人员时间之中。应要求团队为最重要的几个系统整理出真实的年度数字,并将其与最初商业方案所承诺的内容相比较。张力在于,这些分散的成本没有单一的负责人,因此没有人对其增长负责,而批准购买的人往往并非承担维护费用的人。一个诚实的答案会得出一个全生命周期的数字,说明由哪些预算承担,并承认哪些支出是未经规划的——因为一项你每年事后才发现的成本,是一项你无法管理的成本。

2. 我们的技术债务在哪里,我们正在为它支付什么利息? 工程团队通常确切地知道债务在哪里——那个没人敢碰的模块、靠人工步骤维系的接口、安全支持落后两个版本的平台——但这种知识很少以经济学语言传达给董事会。应索取这份登记册:重大的债务项目、每一项分别拖慢或危及了什么,以及偿还它需要多少成本。张力在于,偿还债务与看得见的新功能相竞争,在观感上总是败下阵来,而这恰恰是债务不断累积的原因。一个诚实的答案会量化这份利息(更慢的交付速度、事故暴露风险、被阻碍的项目),承诺投入一份常设的能力份额用于削减债务,并接受某些债务承担下去是理性的——前提是这种承担是有意识的。

3. 如果我们必须在三年内离开我们的主系统供应商,我们能做到吗——这将花费我们多少? 这个问题在仍有时间减少锁定效应之时将其揭示出来。审视谁拥有数据、能以何种格式离开,合同对退出协助有何规定,需要重建多少定制接口,以及一次迁移会带来多少再培训和临床中断。张力在于,每个人都希望永远不必行使这个退出选项,因此没有人愿意为保持它的畅通而付费——然而一个无法退出的选择,已经是一场提前输掉的续约谈判。一个诚实的答案会为退出定价,识别出能够降低其成本的两三项行动(数据导出权、标准接口、文档记录),并将这个价格视为该机构主动维持的一项议价筹码。

4. 哪些系统我们应该自建,哪些应该购买,我们的工程能力是否与这个答案相匹配? 自制与购买的划分是一个投资组合决策,许多机构却是通过累积而非选择来做出这个决策的,最终自建了标准化的东西,却购买了本应使自己与众不同的东西。应追问你的哪些系统真正体现了你服务中独特的东西,哪些是市场或开源社区已经能够满足的标准化需求。然后检验这一能力主张:对于每一个内部构建的系统,是否有一支获得资助、可招募的团队承诺在其整个生命周期内维护它——而不仅仅是创建它的那个项目团队?张力在于,自建满足了雄心,购买满足了审慎,而这两种本能都算不上分析。一个诚实的答案会指明差异化因素所在,承认哪些过去的自建项目应当退役或替换为标准产品,并拒绝启动任何维护资金未获保障的自建项目。

5. 我们最关键系统中一小时的停机实际上会造成什么代价,我们的可靠性支出是否与之相匹配? 可靠性决策常常是由缺乏临床成本信息的工程师做出的,或是由缺乏工程成本信息的董事会做出的,因此支出与惯性相匹配,而非与后果相匹配。应推演一个具体情景:电子病历在繁忙的一天中瘫痪——什么会被延误,会出现什么不安全的变通做法,可能会造成什么伤害,恢复需要多少成本?然后将其与你在韧性、备份、故障切换和事故响应上的支出相比较。张力是双向的:投入不足会买到事故,但为一个低风险系统过度镀金,则会浪费另一项服务所需要的资金。一个诚实的答案会依据临床后果为每一项关键服务设定明确的可用性和恢复目标,并能够展示与之相匹配的工程支出——不多也不少。

6. 我们对那些人人都不敢触碰的遗留系统有什么计划? 每一个成熟的卫生机构都有这样的系统:超过了经济上可维护的临界点,却因为它们能运行、更换又令人望而生畏而被维持着。应说出你的那些系统的名字。追问每一个系统阻碍了什么——未能构建的集成、未能实现的改进、所承担的安全暴露风险——以及更换路径是什么:渐进式迁移、整体替换,还是刻意的、经过规划的、风险可控的保留。张力是时间性的:维持遗留系统的成本是分散且逐年累积的,而更换它的成本却是集中的、在职业生涯中显而易见的,因此看似理性的推迟成为默认选项,直到故障以最糟糕的价格强行解决问题。一个诚实的答案会在现有系统仍能运行时就安排更换,优先选择"绞杀式"的渐进迁移,而非一次性切换,并把"我们明年再决定"视为它实际上就是的那个决定。

实践中的卫生经济学案例

一个虚构的东非国家的卫生部,正面临一项续约决策。九年来,其地区医院一直运行着一套由海外供应商提供的专有医院信息系统。这套系统能够运行,但续约报价急剧上涨,每一个新接口——连接到国家保险计划、连接到实验室网络——都是一个定制的、由供应商定价的项目,而合同对数据导出问题只字未提。与此同时,卫生部的地区卫生办公室已经在运行DHIS2——用于国家卫生统计数据的开源平台,而邻国已经实施了一个开源电子病历平台,并配有一个区域支持联盟。

卫生部的卫生经济学小组将这一决策从"续约与否"重新界定为在十年时间跨度内对三个选项进行全生命周期比较:续约现有系统、短期续约同时争取退出权利,或渐进式迁移到开源平台。对这些选项进行成本核算揭示了真实的经济状况。一旦计入定制接口、强制升级项目和海外支持差旅,现有系统的许可费用只占其真实年度成本的三分之一。开源选项没有许可费用,但要求卫生部资助一支国家支持团队、区域托管,以及对该平台社区的贡献——这些都是真实的、反复出现的资金,是"免费软件"的说辞所掩盖的。然而,决定性的一项既不是这两者之一:是数据迁移。九年的患者记录保存在一个专有的架构之中,而供应商对数据提取协助的报价,实际上就是离开的价格。

该小组还是为退出定了价,而这个数字改变了谈判。有了一个已核算成本的替代方案作为后盾,卫生部谈判达成了一份两年期的低价续约,其中包含合同规定的、以有文档记录格式进行的数据导出,以及连接到保险计划和实验室网络的标准FHIR接口——从经济学角度讲,这是在购买一份关于未来更便宜退出的期权,其赋值方式与主题3.12《大流行病与应急准备经济学》为任何一份关于未来行动自由的期权赋值的方式如出一辙。在这两年间,一个试点项目将三家地区医院迁移到开源平台,测试了支持联盟、数据迁移工具,以及至关重要的一点——卫生部能否招募并留住该平台所需的工程师,这借鉴了主题3.6《卫生人力与劳动力市场》的人力经济学。

该试点在两家医院取得成功,在第三家医院则遇到困难,那里的人员配置缺口使每一次事故都变成一场危机——这是一个关于能力的警示,而非关于软件的警示。卫生部随后推进了一项为期五年、逐个医院进行的分阶段全国迁移,在每个站点的数据得到核实之前,保持现有系统并行运行。最终的评价明确指出了这一教训:制胜的举措不是选择开源而非专有系统,而是为每个选项的整个生命周期定价,在依赖性进一步固化之前购买退出权利,并使工程承诺与卫生部真正能够维持的能力相匹配。

四种部门视角

初创企业

一家卫生软件初创企业从销售方的角度经历着本主题的经济学:它的估值奖励交付速度,而这恰恰是技术债务累积的方式,而它的收入模式可能悄悄地依赖于其客户本应抵制的锁定效应。这里的纪律是有意识地承担债务——一个能够赢得一位关键客户的捷径可以是理性的——同时保持一份登记册和一个偿还计划,因为一个无法被修改的代码库,意味着一家无法转型的公司。互操作性是战略,而非合规:标准接口(尤其是FHIR)是一款小产品在由在位者主导的资产中赢得一席之地的方式。而临床安全工程不是可以推迟到规模化之后才处理的官僚事务;临床场景中的一次数据完整性事故就可能终结一家年轻的公司。

小型企业

一家规模较小但已站稳脚跟的服务提供者——一个诊所集团、一家连锁药房、一家诊断实验室——几乎购买其全部软件,也没有工程人员来弥补一次糟糕的采购,因此它的经济状况就是依赖性的经济状况。总拥有成本和退出权利在这里比在任何地方都更重要,因为一个定价错误的系统在预算中所占的比例更大,而一次失败的迁移可能使业务陷入停顿。明智的姿态是标准化:主流产品、开放标准接口、托管服务而非自行运营的服务器,以及在关注价格之前先审阅数据导出条款的合同。它独有的风险是无声的遗留问题——一套运营管理系统原地老化,直到其供应商倒闭——因此即便是一个小型买家,也应当每年都清楚知道离开自己所依赖的每一个系统需要付出什么代价。

大型企业

一家大型医院集团或保险公司运行着数百个系统,因此它面临的是投资组合问题:由不同部门购买的重叠产品、一张没有人完全绘制出来的集成网络,以及分布在一个规模太大、任何单一团队都无法完全看清的资产中的技术债务。成熟的大型企业以管理投资组合的方式来管理这一资产——一份包含所有者、全生命周期成本、债务和风险评级以及规划中的更换时间表的系统清单——并资助一支常设的工程能力用于集成、可靠性和债务偿还,而不是把每一次改进都当作一个需要单独竞标的项目来对待。规模也赋予了小型买家所缺乏的购买力:它可以要求标准接口、数据导出权和托管作为准入条件,而它的架构选择约束的是它的供应商,而非相反。

政府

一个部委或国家支付方为其他所有人塑造着这一经济学。它设定了决定市场是奖励还是惩罚开放性的互操作性规则——正如美国通过《21世纪治愈法案》的信息阻断条款以及欧盟通过欧洲卫生数据空间所做的那样——而它自身的采购行为也教会了供应商买方能够容忍什么。它独有的失败模式是国家级的巨型项目:集中化的、一次性的、按政治时间表交付的软件项目,其崩溃的代价以数十亿计——正如英国的国家信息技术项目所展示的那样。这一学问的纪律恰恰相反——标准和平台集中制定,交付则渐进式进行,并在商业市场稀薄之处认真权衡开源和可本地维护的选项(其政策机制属于主题3.2《卫生政策》,而采购技艺属于主题3.10《战略性购买与购买规划》)。

常见失败模式

• 只购买许可,不购买生命周期。 依据购买价格批准软件,而集成、迁移、维护和退出的成本却从未被核算。对策: 要求每一份商业方案都提供全生命周期总拥有成本,并为每一项反复出现的费用指定预算。

• 看不见的债务,直到它不断累积。 任由技术债务未经记录地累积,直到资产再也无法被安全地修改。对策: 保持一份债务登记册,以经济学语言报告它,并投入常设能力用于偿还。

• 不知不觉地陷入锁定效应。 接受专有格式和定制接口,直到退出变得负担不起,续约条款也任人摆布。对策: 在购买时就谈判获得数据导出权和标准接口,并每年为退出定价。

• 构建你无法维护的东西。 委托构建内部系统,却没有资助一支团队来维护它的整个生命周期。对策: 没有可持续维护计划就不自建;在能力薄弱之处购买或采用开源平台。

• 把开源当作免费的东西。 采用社区平台,却不为托管、支持和管理提供资金。对策: 依据总拥有成本评估开源选项,并为其所需的可持续维护编列预算。

• 靠祈祷来维持可靠性。 不设定可用性目标,直到一次停机揭示出停机的临床代价。对策: 依据临床后果为每一项关键服务设定可用性和恢复目标,并按目标投入支出。

• 在压力下进行一次性遗留系统更换。 推迟现代化改造,直到故障强行推动一次仓促的、整体性的切换。对策: 在现有系统仍能运行时就规划更换,并通过并行运行和经过核实的数据来实施渐进式迁移。

• 软件游离于价值纪律之外。 让信息技术项目绕开适用于药品和服务的审查。对策: 采用同样的规则——明确的收益、真实的比较对象、可负担性概况,以及实施后审查。

成熟度模型

检查清单

• 依据系统现实生命周期内的总拥有成本评估每一项软件决策,并为每一项反复出现的费用指定预算。
• 维护一份技术债务登记册,以经济学语言报告它,并投入常设的工程能力用于偿还。
• 从最初的商业方案起,就将维护作为一项经过规划的运营成本来资助。
• 在购买时就在合同中谈判获得数据导出权、标准接口和退出协助。
• 每年为离开每一个主要系统定价,并在续约之前保持一个已核算成本的替代方案。
• 要求经过核实的开放标准合规性(例如FHIR)作为采购条件。
• 将自制还是购买的决策作为一个投资组合来决定,没有获得资助的全生命周期维护计划就不启动任何自建项目。
• 依据总拥有成本评估开源选项,为托管、支持和管理编列预算。
• 依据临床后果为每一项关键服务设定可用性和恢复目标,并使支出与之相匹配。
• 在现有系统仍能运行时就安排遗留系统更换,优先选择渐进式迁移,而非一次性切换。
• 及早为数据迁移定价并加以测试,并在每个系统的整个生命周期内保持患者数据的可导出性。
• 使软件项目接受与任何其他卫生投资相同的价值审查,并进行实施后审查。

主要来源

• WHO,《2020-2025年全球数字健康战略》— 世界卫生组织关于数字健康投资的框架,包括可持续性和互操作性原则。
• HL7 International — FHIR(快速医疗互操作性资源)标准,健康数据交换领域占主导地位的开放标准。
• openEHR、DHIS2和OpenMRS — 在全球范围内广泛部署的开源健康信息平台和规范,是社区维持的卫生软件的范例。
• 美国国家卫生信息技术协调员办公室(现为ASTP)— 《21世纪治愈法案》信息阻断和互操作性规则,对互操作性供给不足问题的一种监管回应。
• DORA,《Accelerate State of DevOps》报告 — 长期研究,将软件交付和可靠性实践与组织绩效联系起来。
• 英国国家审计署 — 关于NHS国家信息技术项目的报告,大规模卫生信息技术项目失败的经典案例研究。

参考文献

1. Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
2. Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
3. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
4. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
5. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
6. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
7. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
8. Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
9. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
11. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
12. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
13. World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
14. HL7 International — FHIR specification — https://hl7.org/fhir/
15. National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
16. National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT