医疗保健领域的人工智能作为重要的数字健康基础设施：一个应对系统性风险的公共卫生准备框架 尼古拉·利普斯基（Nikolay Lipskiy）与斯蒂芬·V·弗劳尔代（Stephen V. Flowerday）

《Future Internet》：Healthcare AI as Critical Digital Health Infrastructure: A Public Health Preparedness Framework for Systemic Risk Nikolay Lipskiy and Stephen V. Flowerday

　　摘要 医疗保健领域的人工智能（AI）正从实验室走向医疗服务的基础设施。随着这些系统被应用于影像诊断、电子健康记录、分诊和临床决策支持中，它们的故障不仅会影响个别患者的治疗过程，还会波及整个医疗机构和患者群体。然而，当前的治理机制主要集中在模型开发、局部验证以及一次性合规性上，对于系统部署后的跨站点故障关注较少。本文探讨了公共卫生准备如何有助于弥补这一不足。文章通过两个案例进行了概念性分析：一个是用于肺炎筛查的卷积神经网络，它学会了识别医疗机构特有的混杂因素而非可移植的临床信号；另一个是广泛应用的败血症预测模型，其实际性能和警报负担与开发者的宣称存在差距。这两个案例揭示了系统性医疗AI风险的五个治理特征：群体层面的暴露风险、在共享基础设施中的连锁效应、不平等的脆弱性、识别延迟以及需要跨机构协调的问题。为了解决这些问题，我们提出了一个三方框架，包括加强部署前的保障措施、部署后的监控及升级机制，以及通过调查、回滚、补救和跨站点学习来进行三级响应。本文的观点并不是说AI故障本身会引发“流行病”，而是指高影响力的临床AI系统已成为重要的数字化医疗基础设施，因此需要相应的准备措施和全生命周期的监管。

1. 引言
1.1. 医疗保健AI作为关键数字化医疗基础设施
人工智能（AI）正从概念验证研究阶段迈入常规临床应用。这些系统已被用于影像诊断、分诊、风险预测、质量保证、公共卫生监测和运营决策支持等方面[1,2]。这种转变的规模和速度非常迅速，体现在FDA不断扩大的AI支持医疗设备范围内[3]。国际上各国也开始关注相关监管：欧盟的AI法案将诊断和临床决策支持AI视为高风险系统，要求进行符合性评估、市场后监测和透明度要求[4]。然而，重要的变化不仅仅在于AI工具数量的增加，更在于这些系统已经嵌入到了临床决策制定的基础设施中——它们存在于影像平台、电子健康记录以及同时服务于数十家或数百家医院的供应商分布式系统中[5,6,7]。随着这些系统成为医疗基础设施的一部分，现有的治理框架未能跟上其部署风险的步伐，从而产生了治理问题。

1.2. 治理缺口：从模型监管到准备应对
当前的治理框架大多仍以模型为中心，关注设计质量、预期用途、验证和生命周期管理等方面[1,4,8]。但一个更为复杂的问题尚未得到充分解答：如何让医疗机构为那些难以在本地察觉、可能在多个地点反复出现的故障模式做好准备、做出响应？一旦AI成为常规医疗服务的组成部分，治理机制就需要超越上市前审查或一次性验证，而建立一个结合部署前保障与部署后评估的框架[11,12]。这种风险源于系统的部署方式：集成到病理影像存档与传输系统（PACS）中的诊断模型、嵌入电子健康记录（EHR）中的分诊工具，或在整个医疗机构网络中推广的败血症预测模型，不再仅仅是独立的研究模型[13,14,15]。它们已经成为关键数字化医疗基础设施的组成部分，因此其故障可能在多个机构间出现。高影响力的医疗AI具有网络物理系统的核心特征：软件输出通过紧密耦合的社会技术工作流程塑造物理临床过程和患者的治疗路径[5,6,16]。正如其他安全关键领域所发现的那样，提高效率和标准化的措施也可能导致系统故障的同步发生。

两个典型案例揭示了系统性脆弱性的两个反复出现的模式：Zech及其同事的研究表明，一个深度学习的肺炎模型学习了医院特有的信号和患病模式，导致不同机构间的性能差异显著[13]；Wong及其同事的研究指出，一个广泛应用的专有败血症预测模型在现实世界中的验证效果不佳，灵敏度低、阳性预测值低且警报负担重[14]。第一个案例揭示了异构临床环境中的潜在脆弱性；第二个案例则凸显了由供应商大规模扩散带来的集中式供应链风险。在这两个案例中，核心问题不仅仅是技术性能不佳，而是识别、解释和应对这种系统性故障的难度。

“系统性医疗AI风险”这一概念有助于理解这一治理挑战。它指的是当与AI相关的故障通过相互关联的结构、组织、技术、认知和文化途径传播时，对患者或群体造成的伤害，其后果无法归结为单一的局部故障或一次性实施缺陷。图1总结了这些途径，并构成了本文的因果框架。

1.3. 研究问题、分析顺序和贡献
本文通过提出一个具体问题来探讨上述治理缺口：如何借鉴公共卫生准备的概念来管理医疗AI中的系统性风险？文章的目标是制定一种面向准备工作的治理框架，适用于那些故障可能相互关联、识别延迟且分布在多个机构中的高影响力临床AI系统。为此，文章采用了一种结构化的分析方法：首先定义治理缺口，并将问题置于相关文献背景中；其次通过两个案例揭示不同的系统性故障模式；然后从这些案例中提取治理相关要素；最后将这些要素转化为预防、监控和响应的三方框架。本文在概念和规范层面进行了创新，基于比较案例研究而非实证试验或系统评价。

本文主要有四个贡献：将某些医疗AI系统重新定义为关键数字化医疗基础设施而非独立模型；提出了“系统性医疗AI风险”这一治理概念；将流行病学和监测的语言应用于这一领域；并提出了一个结合外部验证、部署后监控、升级和协调响应的三方框架。这些贡献在特定且有限的意义上是新颖的：现有的算法监控框架主要关注单个机构的部署后监控，但没有规定升级阈值、跨机构协调机制或三级响应功能；欧盟的AI法案和NIST的AI风险管理框架虽然为高风险AI制定了监管和风险管理的术语，但未将公共卫生准备逻辑应用于医疗AI治理；ISO 5477:2023[11]提供了公共卫生应急准备的信息化标准，但未将医疗AI视为危险类别。目前尚无框架将部署前保障、部署后监控及升级机制与跨机构协调响应整合到一个统一的治理架构中。理解为何需要这种准备架构需要结合四个交叉领域的文献：医疗AI治理、社会技术风险、关键数字化基础设施和公共卫生准备。

2. 相关文献和理论基础
第1节中提到的治理问题涉及四个学术领域：一是现有的医疗AI治理方法及其局限性；二是系统性和社会技术风险以及复杂故障如何源于相互作用的组件而非孤立缺陷；三是利用关键数字化基础设施和网络物理系统理论解释为何基础设施规模的AI需要相应的保障措施；四是将公共卫生准备逻辑应用于需要跨机构传播和管理的风险。这三个领域共同构成了第5节提出的治理框架的理论基础。

2.1. 医疗AI现有的治理方法
关于医疗AI的治理文献发展迅速。世界卫生组织（WHO）强调了在AI开发和应用过程中应遵循伦理、人权、问责制、透明度和治理原则[1]。《WHO数字健康全球战略》也将互操作性、数据治理和组织能力视为医疗系统的核心功能[2]。欧盟的AI法案虽然涵盖范围更广，但强调了高风险系统的监管重要性，因为这些系统的故障可能影响安全和基本权利[4]。同时，NIST的AI风险管理框架为该领域提供了围绕“治理、映射、测量和管理”的信息系统术语，提醒我们部署、监控、文档记录和组织问责是AI风险管理不可或缺的部分[8]。特别值得关注的是算法监控方面[9,10,11]，该领域借鉴了药物警戒的经验，认为部署的医疗AI应在实际环境中持续监测其有效性、公平性和安全性。实际性能可能因病例组合差异、工作流程变化、编码或文档更新、新用户行为或人口特征变化而发生变化。然而，许多讨论仍主要将部署后的监管视为组织或局部问题[17,18,19]。虽然鼓励医疗机构跟踪自身系统的性能和公平性，但这通常不够全面，因为一个机构可能只能看到更广泛故障模式的一部分，尤其是当问题与共享的供应商基础设施、标准化部署逻辑或隐藏的混杂因素相关时。在这种情况下，准备应对措施尤为重要，它不仅关注单个机构如何管理自身系统，还关注多个机构如何共同检测、比较和应对相关故障。

2.2. 系统性和社会技术风险
当医疗AI被视为更广泛的社会技术系统的一部分时，治理挑战变得更加明显。Macrae关于自主和智能系统的研究指出，严重故障源于技术组件、组织安排、专业实践和组织环境之间的相互作用[7]。Leveson的系统理论强调了当安全约束措施不完善或执行不力时，危险事件更容易发生[5]。这些观点对于医疗AI尤为重要，因为模型错误往往只是更深层次治理问题的表面现象。肺炎和败血症案例[13,14]进一步说明了这一点：肺炎模型的性能受到特定医院的影像处理流程和标记方式的影响；败血症模型的性能受供应商文档、工作流程负担和部署规模的影响。这些都属于社会技术故障，因为它们源于人员、组织、基础设施和软件之间的相互作用。

3. 研究问题、分析顺序和贡献
本文通过一个具体问题来解决上述治理缺口：如何将公共卫生准备的概念应用于医疗AI中的系统性风险管理？具体目标是开发并论证一种适用于高影响力临床AI系统的治理框架，这些系统的故障可能相互关联、识别延迟且分布于多个机构。文章通过以下分析顺序来回答问题：首先定义治理缺口，并将其置于相关文献背景中；其次通过两个案例揭示不同的系统性故障模式；然后提取与治理相关的特征；最后将这些特征转化为预防、监控和响应的三方框架。本文具有概念性和规范性，基于比较案例研究而非实证试验或系统评价。

本文的四个贡献包括：将某些医疗AI系统重新定义为关键数字化医疗基础设施；引入“系统性医疗AI风险”这一治理概念；适应该领域的流行病学和监测语言；提出一个结合外部验证、部署后监控、升级和协调响应的三方框架。这些贡献在特定且有限的意义上是新颖的：现有的算法监控框架主要关注单个机构的部署后监控，但没有规定升级阈值、跨机构协调机制或三级响应功能；欧盟的AI法案和NIST的AI风险管理框架为高风险AI制定了监管和风险管理术语，但未将公共卫生准备逻辑应用于医疗AI治理；ISO 5477:2023[11]提供了公共卫生应急准备的信息化标准，但未将医疗AI视为危险类别。本文填补了这一空白。理解为何需要准备框架需要结合四个交叉领域的文献：医疗AI治理、社会技术风险、关键数字化基础设施和公共卫生准备。以下部分将进一步阐述这一框架的理论基础。

2. 相关文献和理论基础
第1节中提出的治理问题涉及四个学术领域：一是现有的医疗AI治理方法及其局限性；二是系统性和社会技术风险以及复杂故障如何源于相互作用组件；三是关键数字化基础设施和网络物理系统理论；四是将公共卫生准备逻辑应用于需要跨机构传播和管理的风险。这些领域为第5节提出的治理框架提供了概念基础。

2.1. 医疗AI现有的治理方法
关于医疗AI的治理文献发展迅速。WHO强调了在AI开发和应用过程中应遵循伦理、人权、问责制、透明度和治理原则[1]。《WHO数字健康全球战略》也将互操作性、数据治理和组织能力视为医疗系统的核心功能[2]。欧盟的AI法案虽然涵盖范围更广，但强调了高风险系统的监管重要性，因为这些系统的故障可能影响安全和基本权利[4]。NIST的AI风险管理框架为该领域提供了信息系统方面的术语，强调了部署、监控、文档记录和组织问责的重要性[8]。特别重要的是算法监控方面的研究[9,10,11]，这些研究借鉴了药物警戒的经验，认为应持续监测部署的医疗AI在现实环境中的有效性、公平性和安全性。实际性能可能因多种因素而变化，因此AI治理不能在模型验证或批准后就停止。然而，许多讨论仍将部署后的监管主要视为组织或局部问题[17,18,19]。虽然鼓励医疗机构跟踪自身系统的性能和公平性，但这通常不够充分，因为一个机构可能只能看到更广泛故障模式的一部分，尤其是当问题与共享的供应商基础设施、标准化部署逻辑或隐藏的混杂因素相关时。在这种情况下，准备应对措施尤为关键，它不仅关注一个机构如何管理自身系统，还关注多个机构如何共同检测、比较和应对相关故障。

2.2. 系统性和社会技术风险
当医疗AI被视为更广泛的社会技术系统的一部分时，治理挑战变得更加明显。Macrae关于自主和智能系统的工作指出，严重故障源于技术组件、组织安排、专业实践和组织环境之间的相互作用[7]。Leveson的系统理论指出，当安全约束不明确或执行不力时，危险事件更容易发生[5]。这些观点对于医疗AI尤为重要，因为模型错误往往只是更深层次治理问题的表面现象。肺炎和败血症案例[13,14]进一步说明了这一点：肺炎模型的性能受特定医院的影像处理流程和标记方式影响；败血症模型的性能受供应商文档、工作流程负担和部署规模的影响。这些都属于社会技术故障，因为它们源于人员、组织、基础设施和软件之间的相互作用。这种系统视角还解释了为何某些AI风险在初期难以被发现：医疗机构通常在内部测试模型，因此可能忽视在外部条件下才会显现的性能下降[20,21]。临床医生可能会因警报疲劳而忽视问题的根本原因，而无法将其归因于模型故障[22]。采购团队可能依赖于未经异构环境下独立测试的供应商文档[18,21]。因此，医疗机构只能看到症状而无法看到完整的因果结构。准备性架构之所以有价值，正是因为它是为那些因果模式分散且在使用点仅部分可见的危害而设计的。这种社会技术框架也与安全关键工程领域对基础设施故障的理解相一致。2.3 关键数字基础设施和信息物理系统 关键基础设施的框架进一步增加了精确度。医疗保健AI系统越来越多地在网络化数字环境中运行，在这些环境中，算法输出影响物理临床过程。这使它们属于信息物理系统（CPS）的广泛类别，其中软件、数据、设备、接口和人类操作者通过反馈循环相互作用以塑造现实世界的结果[6]。在成熟的安全领域，CPS风险不会像处理普通软件错误那样被管理。它们通过危害分析、控制结构、冗余、配置管理和与潜在后果相称的备用模式来进行管理。这种比较揭示了一个重要的不对称性。安全关键工程领域通常为危险故障定义了结构化的保证机制。医疗保健AI仍然缺乏广泛认可的完整性分类，将这些保证期望与系统的严重性、影响范围、耦合性和备用选项联系起来。因此，嵌入在电子健康记录（EHR）中并在许多医院部署的败血症预测模型可能面临比工业控制系统中的相对简单组件更少的系统化保证。重点不是全盘引入工程标准，而是要认识到一个熟悉的治理问题：一旦数字组件成为基础设施的一部分，治理就必须从孤立错误转向系统级韧性。已建立的安全工程工作进一步强调了这一点。在系统理论安全分析中，当安全约束在交互控制结构中定义不明确或执行不严格时，就会发生事故，而不仅仅是单个组件发生故障[5]。这一观点直接与医疗保健AI相关，因为肺炎和败血症病例是交互失败的结果：模型设计、验证实践、界面设计、工作流程集成、供应商透明度不足以及机构监督共同造成了这些危害。这也阐明了共模故障的重要性。一个有缺陷的模型、阈值变化、接口更新或上游数据依赖都可能使多个地点的错误同步，这正是为什么其他安全关键领域坚持对可能广泛传播的组件进行相应保证的原因[16]。因此，将医疗保健AI视为关键数字基础设施提出了另一个治理问题：当故障可以在不同机构之间传播时，需要什么样的协调架构来检测、升级和应对这些故障。公共卫生准备性使这种治理逻辑得以实施。2.4 公共卫生准备性作为治理类比 公共卫生准备性为这个问题提供了一个有用的治理类比。国际卫生规则（IHR）、仙台灾害风险减少框架、世界卫生组织（WHO）的卫生紧急情况和灾害风险管理框架，以及WHO最近关于合作监测的工作，都基于一个共同的见解：能够传播、潜伏或超出单一机构管辖范围的危害需要持续的监测基础设施、共享的术语、分层的响应以及跨组织边界的协调[23,24,25,26,27]。对于医疗保健AI而言，这些框架的价值不在于整体引进理论，而在于适应它们随着时间推移而完善的治理功能。准备性思维进一步通过灾害风险减少逻辑得到加强。仙台框架将技术和社会危害视为风险减少的合法对象，而不是超出公共治理范围的问题[24]。WHO的HEPR工作通过其对所有危害的关注——包括预防、准备、响应和恢复——并明确关注脆弱性和整个系统的协调，也体现了这一点[23,27]。对于医疗保健AI来说，这一点很重要，因为一旦算法故障影响到大规模的诊断、分诊、分配或工作流程，它就不再仅仅是一个技术缺陷，而变成了暴露、脆弱性、韧性和响应能力的问题。除了通用准备性逻辑之外，公共卫生学说中的三个具体监测理念对医疗保健AI治理尤为重要。首先，准备性依赖于持续的基础设施，而不仅仅是临时的反应。在事件发生之前，需要存在报告渠道、病例定义、升级路径和观测功能[20]。其次，监测不是一种单一技术。WHO的流行病情报模型整合了基于指标的监测和基于事件的监测，而CDC的指南说明了为什么在目标是及时信号检测而不是彻底捕获所有病例时，哨兵网络会很有价值[18,19]。对于医疗保健AI，常规性能和结果仪表板适用于基于指标的层面；临床医生的关注点、供应商通知、事件报告和发布的验证适用于基于事件的层面；而选定的高容量医院可以作为更全面病例审查的哨兵站点。第三，监测系统应根据实用性、及时性、敏感性、预测价值、代表性、稳定性和可接受性来判断，而不仅仅是数据量[28]。这些正是卫生系统在部署最具影响力的AI形式时常常缺乏的能力。这里提出的论点是有意有限的，但仍然很有意义。本文并不声称疫情法已经适用于AI事件，也不认为医疗保健AI故障应该以任何字面意义上的传染病来处理。相反，它认为某些AI故障与公共卫生 telah建立最成熟准备能力的危害类别具有重要的治理特征。这些对应关系足够强，足以证明有必要将准备性、合作监测和协调响应逻辑适应医疗保健AI的监督。总的来说，这四组学术成果精确地定义了治理问题，足以支持一个具体的提案：在后续章节中将开发的针对系统性医疗保健AI风险的三方准备性框架。3. 方法论 3.1 研究设计 本文提出了基于比较案例研究的概念性和规范性分析。它没有提出新的临床试验、基准实验或系统评价。相反，它通过将文献中的案例证据与关于医疗保健AI监督、社会技术安全、公共卫生准备性和数字流行病学的学术研究结合起来，发展了一个治理框架。目的是从问题识别谨慎地走向具体的治理提案。这种概念性和规范性文章需要与实证研究相同的方法论透明度，因为治理提案的有效性取决于其分析路径的明确性。为了使这一路径明确，分析首先定义了问题空间和关注单位：系统性医疗保健AI风险。然后它通过将流行病学概念适应医疗保健AI来建立术语基础。接下来，它检查了两个因治理相关性而被选中的已记录的临床AI故障，从中得出重复的治理属性，并将这些属性映射到准备性功能上。最后一步是将这些功能综合成一个三方治理架构。3.2 来源领域 分析借鉴了四个来源领域。第一个领域包括医疗保健AI治理文件，如WHO的材料、欧盟AI法案、NIST AI RMF和关于算法监控的文献[1,2,4,8,9,10]。第二个领域包括社会技术安全和关键基础设施的学术研究，特别是关于系统事故、安全约束和信息物理系统的工作[5,6,7,16]。第三个领域包括公共卫生准备性、监测和应急响应框架，如仙台框架、HEPR、IHR、GOARN、合作监测、流行病情报、CDC监测指南和事件管理原则[23,24,25,26,27,28,29,30,31,32]。第四个领域包括关于医疗保健AI故障的已记录案例研究，特别是Zech等人进行的跨机构肺炎筛查研究和Wong等人对Epic Sepsis模型的外部验证[13,14]。选择这些领域是因为这个论点本质上是跨学科的。没有单一文献能够充分描述局部AI性能问题如何变成population-level的治理问题。因此，该框架需要技术案例证据、安全理论和公共卫生治理原则之间的桥梁。3.3 案例选择 两个核心案例是有意选择的，而不是基于统计的，因为每个案例都捕捉到了一种独特且互补的故障模式。肺炎筛查案例代表了分布式潜在脆弱性。该模型在内部或部分汇总的条件下似乎成功，但在外部条件下失败，因为它学习了特定于机构的线索、流行率梯度和流程缺陷。这个案例具有分析价值，因为它表明，除非机构在不同地点比较证据，否则临床意义上的故障可能是看不见的。Epic Sepsis模型案例代表了集中式供应链传播。一个广泛部署的专有模型通过一个共同的供应商平台传播，但后来的实际表现比内部文档所暗示的要差得多。这个案例很有价值，因为它表明规模、供应商不对称性、工作流程负担和性能透明度如何结合在一起，创造出类似基础设施的暴露。这两个案例共同捕捉到了两个分析上重要的模式：只有通过跨地点比较才能看到的隐藏的局部混淆，以及由广泛供应商传播引起的共模暴露。这两个案例的设计是有意为之。目的不是在AI故障样本中建立实证流行率，而是识别出足够精确的结构上不同的治理模式，以支持框架的发展。这两个案例并不冗余：分布式潜在脆弱性只有通过跨地点比较才能显现，而集中式供应链传播需要独立的外部挑战供应商的说法。这些模式也意味着不同的治理响应——在第一个案例中是部署前的环境审计和流行率协调，在第二个案例中是独立的供应商验证加上供应链监控——这些共同支持了所提出的框架的所有三个层次。增加更多案例会使文章转向案例系列或系统评价，这是不同的贡献。在信息系统和治理研究中，有意设计两个案例的做法已经很成熟，用于从结构上不同的实例中构建理论[33,34]。2026年对Epic Sepsis Model版本2的多中心前瞻性验证进一步支持了该框架的适用性，该验证发现原始ESM案例中识别的治理漏洞，包括机构差异性、低阳性预测值和高警报负担，在更新后的系统中仍然存在[15]。3.4 分析程序 分析程序按连贯的顺序进行，而不是作为检查清单。首先，核心流行病学和准备性概念——如病因、 agents、宿主、环境、传播、危害、暴露、脆弱性、病例定义和监测——被适应于医疗保健AI风险。目标不是修辞上的华丽，而是术语上的规范性：治理需要共享的定义。其次，每个案例都被重建得足够详细，以确定故障机制、基础设施和组织背景的作用以及局部可见性的限制。第三，将案例与公共卫生准备性文献进行比较，得出了系统性医疗保健风险的五个重复属性：population-level暴露、级联传播、不平等的脆弱性、潜伏期以及超出单一机构的协调。第四，这些属性被映射到一个围绕初级预防、二级预防和三级响应组织的三方治理框架上[35]。图1提供了一个紧凑的视觉总结，展示了论点如何从治理问题识别通过术语适应、案例重建、治理属性的推导到三方治理框架的构建过程。3.5 范围和界限 该框架是有意限定的，并且只做出有限的声明。首先，它关注的是医疗保健AI，而不是所有AI。其次，它将“结构对应”或“结构同源性”视为关于治理功能的声明，而不是生物学上的等同性。第三，它不声称提供医疗保健AI事件的实证国家负担估计。这里使用DALY和QALY概念作为解释性桥梁，并作为未来监测要求的指导，而不是证明这两个案例已经在全国范围内建立了population负担。第四，所提出的观测站和协调机制是规范性的设计提案。它们的机构可行性、成本和法律嵌入仍然是未来研究和政策发展的问题。以下部分将报告这一分析程序的结果。4. 结果 下面的四个小节介绍了术语基础、两个案例重建、疾病负担的解释性视角，以及共同构成第5节提出的框架的五个治理属性。4.1 系统性医疗保健AI风险监测的术语基础 对系统性医疗保健AI风险的有效监测需要语言，将已建立的流行病学推理与AI介导的伤害的社会技术动态联系起来。现有的治理讨论通常依赖于“安全”、“偏见”、“漂移”或“可信度”等宽泛的术语，但这些术语本身不足以进行跨机构监测或协调响应。当危害被明确、暴露的人群被定义、脆弱性被描述、病例可以比较以及监测责任被明确时，公共卫生治理才能得以实施。表1提供了一个紧凑的术语映射。它将核心流行病学概念适应于医疗保健AI，同时保留了原始概念的逻辑。在这种表述中，流行病学变成了研究指定人群中AI相关健康危害的分布和决定因素，以及将这些知识应用于预防和控制。病因学变成了研究这些危害在结构、组织、技术、认识论和文化途径中的原因和起源。“代理”（Agent）指的是与人工智能相关的有害机制，例如有偏见的模型、脆弱的分类器、产生幻觉的生成组件或不安全的反馈循环，这些机制一旦在医疗护理中投入使用，就会直接造成伤害。“宿主”（Host）主要指的是暴露在风险中的患者群体以及系统影响决策的临床环境。“环境”（Environment）则包括周围的基础设施、工作流程、激励机制、监管条件以及机构能力，这些因素共同决定了风险暴露的程度和缓解措施。表1展示了将流行病学概念与医疗保健人工智能风险进行对应的关系，这种对应关系也符合当前的国际监测原则。国际卫生组织（IHR）围绕检测、评估、通知、验证和响应来组织治理工作[25]；世界卫生组织（WHO）的协作监测工作强调跨数据源、部门和治理层级的系统性加强，而不是依赖任何单一的证据流[27]。WHO的流行病情报架构同样整合了基于指标和基于事件的监测方法[29]。对于医疗保健人工智能而言，常规性能仪表板、子群体指标和与结果相关的警报属于基于指标的层面；而临床人员投诉、供应商通知、患者安全报告以及外部验证研究则属于基于事件的层面。因此，调整后的流行病学概念不仅提供了概念上的清晰度，还使得不同机构和司法管辖区之间的事件描述具有可比性。经典的流行病学三要素在这里尤为重要，因为它避免了仅凭模型就能解释所有危害的错误假设。在医疗保健人工智能中，“代理”“宿主”和“环境”是紧密交织在一起的：一个在某种环境中表现不佳的模型在另一种环境中可能会有不同的表现；在高容量医疗机构中相对受保护的患者群体，在低容量环境中可能更加脆弱；同样的技术问题也可能因监控安排、临床人员的工作负荷、备用选项或供应商的透明度等因素而产生截然不同的后果。传播途径、发病机制、病例定义和监测方式也会相应地发生变化。“传播”（Transmission）并非指生物传染，而是指人工智能带来的风险通过何种途径影响患者，例如嵌入式临床决策支持、API依赖性、复制的工作流程、复制的阈值、复制的文档或共享的供应商基础设施。“发病机制”（Pathogenesis）指的是技术或社会技术缺陷如何导致后续危害。“病例定义”（Case Definition）是指为了支持跨机构比较和升级处理而需要的最低标准证据。扩展后的数字流行病学（Digital Epidemiology）涵盖了通过互操作的常规指标、事件报告、开源信号和跨机构汇总来进行的群体规模的监测[29,36]。这种术语基础有两个作用：分析上，它使后续的案例研究具有可比性；机构层面上，它明确了未来观测系统所需的功能。如果没有统一的术语，事件描述将局限于特定机构，无法进行比较和分析，也难以汇总。有了统一的术语，与人工智能相关的危害就可以以支持监测、验证、升级和政策学习的形式进行描述。同样重要的是，评估一个监测系统时，不应仅看它收集了多少数据，而应看它是否能够产生及时、可用的行动依据[28]。图2展示了第1.2节中介绍的五种社会技术路径（结构性、组织性、技术性、认知性和文化性）如何相互作用并共同导致医疗保健人工智能风险，这进一步证明了没有单一路径能够单独解释治理挑战。

4.2. 案例研究1：基于CNN的肺炎筛查与隐藏的制度性混杂因素
Zech及其同事评估了经过训练用于检测胸部X光片上肺炎的卷积神经网络（CNN）在三个不同医院系统中的泛化能力：美国国立卫生研究院（NIH）临床中心、西奈山医院和印第安纳大学医院网络[13]。这项研究常被引为关于外部有效性的案例，但其治理意义远不止于模型可能无法泛化的观察结果。关键的经验模式不仅仅是外部验证的重要性，还在于该任务受到了制度性信息的干扰。西奈山医院的肺炎发病率高达34.2%，而NIH临床中心和印第安纳大学的发病率分别为1.2%和1.0%。一个联合训练的西奈山-NIH模型在内部数据集上的AUC为0.931，但在完全外部数据集（印第安纳大学）上的AUC降至0.815（p = 0.001）。一个仅根据医院肺炎发病率对病例进行排序的简单基线模型在联合测试集上的AUC为0.861。因此，明显的成功很大程度上可以归因于医院内的发病率差异，而非模型的稳健性。实验表明，当各训练机构的发病率平衡时，模型的表现更加稳定；当存在十倍的发病率差异时，内部表现改善而外部表现恶化，这证实了治理过程中存在对混杂结构的系统性利用。从治理角度来看，跨机构发病率的一致性是一个可调节的泛化决定因素，因此是一个可行的初级预防目标，而不仅仅是纯粹的技术考量。

这项研究还显示，该模型能够以极高的准确性识别医院的身份。针对不同医院系统的CNN模型在识别医院来源方面的准确率超过了99.9%。技术人员放置的标记Beans等横向特征是最具解释性的线索之一，但它们并不是全部原因。在抽样的NIH X光片中，72.9%的局部图像区域能够以至少95%的确定性独立预测出图像的来源。来源特定的信息分布于整个采集和处理过程中，包括扫描仪特征、存储格式差异和标注流程。这表明，混杂因素可能是广泛的、基础设施层面的，并且难以通过单一特征来解决。从治理角度来看，三个关键因素至关重要：首先，这种失败在正常情况下是隐性的；内部使用该模型的医院可能对其性能有高度信心，却对潜在的脆弱性视而不见；其次，这种失败是环境性和基础设施层面的，涉及扫描仪硬件、存储格式、处理流程和标注程序；最后，这种失败与患者群体有关，一旦集成到临床 workflow 中，错误分类的风险将不再只是一个抽象的基准错误，而是会影响临床决策。肺炎案例说明了公共卫生领域所说的“暴露前控制”和群体监测的必要性。没有单一机构能够仅凭内部验证就可靠地评估模型的泛化能力，跨机构比较才是有效的检测手段。这正是准备逻辑发挥作用的地方：危害是真实存在的、有严重后果的，并且通常是看不见的，除非监测基础设施能够检测到它。

表2将调整后的流行病学概念应用于这个案例，以此说明该案例已经包含了标准化监测语言所需的要素。研究中的患者群体、决定因素、因果路径、数字环境、暴露途径和病例定义逻辑都可以被明确界定，从而有助于治理行动的开展。

4.3. 案例研究2：Epic脓毒症模型与供应商规模带来的风险
Wong及其同事对外部验证了Epic脓毒症模型（ESM），这是一种嵌入在Epic电子病历（EHR）生态系统中的专有逻辑回归模型，该模型在美国各地医院广泛部署[14]。这个案例特别具有启示性，因为它结合了三个使医疗保健人工智能治理变得复杂的因素：大规模部署、依赖供应商提供的性能声明以及无法仅通过判别统计来捕捉的工作流程效应。当一个供应商通过共同的电子病历生态系统分发风险评分模型时，所有采用该模型的医院都会继承相同的验证假设、阈值逻辑、界面生态和性能边界。研究涵盖了2018年12月至2019年10月期间密歇根医学院27,697名成年患者中的38,455次住院治疗，其中2,552次住院发生脓毒症。外部验证显示，该模型在住院层面的AUC为0.63，远低于模型报告的0.76至0.83。在选定的阈值下，模型的敏感性为33%，特异性为83%，阳性预测值为12%。该模型在18%的住院病例中发出了警报，这意味着临床人员必须评估大量被警报的患者才能识别出少数真正的脓毒症病例。因此，这种模型既导致了漏检，又带来了沉重的警报负担。专有模型的部署加剧了信息不对称性：下游机构可能面临警报负担和临床后果，但他们往往无法完全访问模型的训练数据、验证设计、更新逻辑或失败边界。在这种情况下，供应商的内部文档实际上成为了每个连接机构的保障。在信息系统领域，这是一种常见的“共模失败”问题：上游节点的弱点会在整个下游网络中同步显现。

这些数字的治理意义不仅限于模型质量本身。该案例暴露了当一个广泛分布的供应商模型在没有足够独立审查的情况下进入常规医疗护理时可能出现的问题。如果模型的部署是通过一个公共平台进行的，许多机构可能会同时遇到相同的弱点，从而形成类似其他基础设施漏洞的共模暴露问题。此外，这个案例还常被误解，这在治理方面具有重要意义：即使没有因果关系的估计，模型的失败也会带来重大影响。在1709例被模型漏检的脓毒症病例中，有1,030例仍接受了及时的抗生素治疗；通常被讨论的183例是指那些被模型标记但未及时接受抗生素治疗的病例，而不是被两者同时漏检的病例。这种区别很重要，因为它表明，当重叠指标被视为因果估计时，失败的影响可能会被误解。即便没有因果关系的估计，其治理影响也是巨大的：首先，模型外部表现的差距表明了为什么对于高影响力的大规模系统来说，独立验证是必要的；其次，其低敏感性和高警报负担表明治理必须关注流程和工作流程的结果，而不仅仅是判别指标；最后，模型的大规模部署意味着表现不佳不仅仅是局部问题，而是整个平台的问题。

与肺炎案例不同，脓毒症案例突出了供应链中的暴露问题。相关失败不仅存在于模型内部，还体现在更广泛的治理结构中。内部声明未经充分的外部审查就传播到了各个机构，导致地方机构无法完全了解模型的性能边界，由此产生的警报负担也成为临床风险的一部分。这两个案例都提出了进一步的问题：它们揭示的伤害有多严重、有多普遍？这两者有什么共同点，足以引出应对准备措施？

4.4. 疾病负担指标作为解释工具，而非简单的标题估计
本文的一个初衷是展示疾病负担工具如何帮助用公共卫生术语理解与人工智能相关的危害。这一目标仍然具有价值，但目前案例提供的证据主要支持一个方法论观点：疾病负担指标是一种有价值的解释工具，而不仅仅是简单的统计数字。对人工智能相关事件进行DALY（Disability-Adjusted Life Years）风格的评估至少需要五个输入：暴露人群、可归因的不良后果发生率、相关情况下的死亡率、非致命性发病率或生活质量损失，以及可辩护的影响持续时间。这些信息无法仅从性能指标中可靠推断出来[37,38]。QALY（Quality-Adjusted Life Years）提供了一个补充视角，因为它不仅涵盖了死亡率，还反映了生活质量损失、功能下降和恢复时间延长。对于医疗保健人工智能事件而言，这一点尤为重要，因为危害可能通过延迟诊断、不必要的治疗、持续的警报负担或信任侵蚀等方式产生，即使没有立即导致死亡。Epic脓毒症案例只提供了部分相关信息，包括模型性能指标、警报负担、验证队列中的脓毒症发病率以及漏检警报与延迟抗生素治疗之间的重叠情况，但没有提供模型本身造成的危害的因果归因分数。因此，这个案例证明了方法论的相关性，而不是一个可验证的全国性负担估计。虽然情景建模在透明处理的情况下仍有其价值，但它仍然属于假设生成阶段，而非决策级别的估计。分析应当明确区分案例所确立的事实、监控需要测量的内容，以及在此期间治理可以合理推断的信息。一个简单的归因负担计算框架是将暴露人群数量与估计的归因危害比例相乘，然后再乘以结果的严重程度或持续时间，同时明确表示每个步骤的不确定性。即便如此，这种负担视角还是增加了三个方面的考虑：它将关注点从模型行为转移到患者和人群的影响上；它强制人们考虑诸如警报疲劳、诊断延迟、功能衰退以及亚组不平等等结果；并且它揭示了监控的缺口，因为可信的负担估算需要标准化病例定义、分母、结果关联、纵向随访和协调的报告机制。

关于败血症的文献说明了这一点的重要性。国家对败血症发病率的估计[39]以及严重败血症幸存者长期功能衰退的证据[40]表明，这一临床领域已经与较高的发病率和死亡率相关。这并不允许直接从模型遗漏中推断出全国范围内的 Disability-Adjusted Life Years (DALYs)；然而，它确实表明，在这一临床领域的失败可能会带来严重的人体后果，并且当监控系统成熟时，疾病负担方法是评估这些后果的适当概念工具。

更为谨慎的结论虽然较为谦逊，但仍很重要：公共卫生负担指标应该被纳入未来的医疗保健人工智能观测站中，作为以结果为导向的监控工具。一个成熟的观测站需要标准化病例定义、分母、结果关联、暴露与危害的时间关系、亚组分布，理想情况下还需要患者报告的结果或功能随访。表3总结了这些数据元素、它们的潜在来源以及各自的关键注意事项。在这里，它们的作用是方法论和治理方面的。这些数据元素表明了一个成熟的监控体系需要了解什么，以确定一个人工智能事件仅仅是一个技术缺陷、患者安全问题，还是一个群体层面的治理事件。

4.5 系统性医疗保健人工智能风险的五个治理相关特性

将这两个案例与准备工作相关文献结合起来解读，可以发现系统性医疗保健人工智能风险的五个重复出现的特性。这些特性并不意味着人工智能失败与传染病在生物学上是等同的，但它们支持在治理功能层面进行有意义的比较：
4.5.1 群体层面的暴露与监控要求
高影响力的临床人工智能系统在嵌入影响众多患者的工作流程中时，会在群体层面造成暴露。暴露程度取决于实施范围、工作流程的中心性以及早期发现危害的难度。在公共卫生领域，类似的情况需要建立持续的监控基础设施和分层报告机制，因为问题无法在事后逐个病例处理[25,41]。在医疗保健人工智能中，这意味着需要部署注册系统、报告基础设施、为高影响力模型预设上线条件，并设计协作监控机制，结合常规指标、基于事件的信号和哨点站点审查。

肺炎案例清楚地展示了这一点。在内部条件下看似成功的系统掩盖了一个漏洞，而这个漏洞只有在模型遇到新环境时才会显现出来。等到面向患者的错误变得明显时，暴露已经发生了。因此，准备工作逻辑表明，外部验证和报告能力必须先于大规模部署。

4.5.2 跨共享基础设施的级联传播与控制要求
一些医疗保健人工智能风险是通过基础设施耦合而不是生物学过程传播的。共享的供应商、复制的工作流程、相同的PACS环境、云服务或重复的实施实践可能会在多个站点产生相同的失败模式。就信息系统而言，这是共模或供应链传播。从准备工作的角度来看，这引发了控制要求：一旦发现共同问题，治理措施必须能够暂停、回滚、关闭接口、切换到安全备份模式，或者以其他方式中断传播路径，而不仅仅是观察它。

ESM案例是最明显的例子。通过共享平台分发的模型会导致相关的机构暴露。如果后续独立验证或监控发现重大性能问题，治理措施必须能够中断传播路径。仅依靠本地监控是不够的，因为没有单一站点可以看到整个网络。

4.5.3 不平等的脆弱性与公平性要求
系统性医疗保健人工智能风险分布不均。当模型针对开发环境中的特定人群进行调优，或者在不同组织之间的治理资源存在差异时，危害很可能集中在代表性不足的患者群体、非典型机构或容量较低的设置中。公共卫生准备工作早就认识到脆弱性梯度是危害治理的核心。人工智能监管也必须认识到这一点。大型健康算法如果代理指标与实际需求不一致，可能会产生严重的种族偏见[42]。更广泛地说，任何仅跟踪总体性能的监控机制都可能掩盖集中的危害。因此，准备工作需要与健康不平等监控的逻辑相一致的分层监控、亚组审查，并明确关注机构能力，因为那些最无力验证或监控模型的机构可能最容易受到其失败的影响。

4.5.4 延迟性与不可逆性及预防性要求
识别通常会延迟。在两个案例研究中，核心问题都是通过外部评估才显现出来的。隐藏的混杂因素、漂移、校准问题、工作流程不匹配以及供应商透明度不足可能会长期存在。一旦危害累积，就无法完全消除。公共卫生治理将延迟视为采取预防措施和早期监控的理由。医疗保健人工智能治理也应如此。这加强了在群体暴露变得不可逆之前进行预防性外部验证和预定义停止条件的必要性。

延迟性还与不可逆性相互作用。模型可以暂停或移除，但漏诊、治疗延迟、信任丧失和组织技能下降等问题可能会持续存在。这就是为什么人工智能事件不仅需要技术修复，还需要补救措施、审计、沟通和组织学习。

4.5.5 超出单一机构的协调性与协调要求
某些类型的人工智能失败超出了单一医院或单一司法管辖范围的可见性和权限范围，特别是当涉及共用供应商、云基础设施或多国部署链时。采购合同、事件响应、模型更新、报告义务和跨站点学习通常涉及多个供应商、多个医疗系统、监管机构，在某些情况下还包括国际标准制定机构。公共卫生准备工作的相关性在于它有协调应对单一机构无法独自处理的危害的经验。

因此，类似GOARN的医疗保健人工智能治理机制更应被视为一种协调职能，而不仅仅是对疫情法规的简单移植。其核心思想是，广泛部署的临床人工智能失败可能需要共享的案例定义、汇总的信号检测、升级路径和协调的技术支持。如果这种机制得以发展，最有用的公共卫生先例不是笼统的应急措辞，而是谨慎使用决策工具来判断事件是否严重、是否不寻常、是否跨越司法管辖范围，以及是否可以从协调响应中受益[25,26]。法律和制度形式尚未确定，但治理需求已经显而易见。图3将本节中提出的五个治理特性与其相应的准备工作职能进行了映射，展示了群体层面的暴露、级联传播、不平等的脆弱性、延迟性以及协调要求如何直接转化为监控、控制、公平性、预防性和协调性的治理义务。

4.6 医疗保健人工智能的三方准备工作框架
4.6.1 预防性措施：部署前的保障
预防性措施旨在在模型进入常规护理之前减少可避免的暴露。对于医疗保健人工智能而言，这包括风险分类、在不同机构环境中进行独立验证、记录数据来源和工作流程假设、进行亚组性能审查、人为因素评估，以及包含透明度、监控义务和回滚条款的采购要求。

肺炎案例说明了这一点的重要性。强制性的跨站点验证本可以暴露出由分布不平衡和环境异质性造成的脆弱性。部署前的环境审计，包括扫描仪硬件、存储格式和标记流程的审核，应将部署环境视为危害的一部分，而不仅仅是背景噪声。更广泛地说，预防性措施将治理工作向前移，从对故障的反应转变为限制故障可能发生的条件。

对于供应商级系统，预防性措施还意味着不能仅依赖内部文档作为高影响力部署的唯一保障。当群体暴露量大且工作流程依赖性强时，外部验证应被视为治理要求，而不仅仅是最佳实践的愿景。

4.6.2 二级预防：哨点监控与早期干预
二级预防旨在在危害达到不可逆规模之前发现并中断它。在医疗保健人工智能中，这包括与临床结果相关的常规性能监控、定期重新验证、亚组监控、事件分类和升级阈值。一个成熟的系统结合了基于指标的监控、基于事件的监控和选定的哨点站点。

ESM案例清楚地说明了这一需求。一个能够汇总跨站点分散性能数据的观测站本可以在任何单一机构之前发现外部性能与供应商声明之间的差异。监控还必须与权力相结合：应提前定义暂停阈值、审计触发条件、回滚标准和升级路径。与公共卫生监控一样，观测站应以其实用性、及时性、敏感性、代表性、稳定性和可接受性来评估[19,20]。

二级预防也关注公平性。仅跟踪总体性能的监控系统可能会在最需要准备工作的地方失效。因此，分层监控、亚组审查和机构背景指标是早期检测的核心组成部分。在实际操作中，选择哨点站点时不仅应考虑分析能力，还应考虑患者构成的多样性、工作流程条件和资源设置，以便边缘化群体中的弱信号不会被忽视。

4.6.3 三级预防：响应、补救与学习
三级预防针对已经发生的危害。在医疗保健人工智能中，这包括事件调查、临时暂停或回滚、患者安全审查、供应商通知、与受影响利益相关者的沟通、适当的补救措施以及结构化的跨站点学习。对于严重事件，这些行动应与现有的事件管理或应急操作结构相连接，而不仅仅是依赖即兴的数据科学工作流程[32]。

事件后的响应不能简化为技术修复。一旦模型在规模上影响了护理，恢复还可能涉及重建工作流程、恢复安全的备份能力和修复信任。在这种情况下，GOARN启发的协调层变得尤为恰当。重点不是WHO的应急法规应自动适用于所有人工智能事件，而是一些事件可能需要汇总的技术调查、共享的信号传播、协调的供应商参与和补救支持，因为它们超出了单个机构的可见范围。公共卫生类比在这里体现在协调职能和应急能力方面最为突出。

4.6.4 以两个案例为基础的框架
三方框架不是抽象的概念，而是直接基于案例证据构建的。肺炎案例揭示了预防性措施的失败：机构孤立的培训数据、隐藏的环境异质性以及对内部验证的过度依赖导致了一个看似更强大的模型。ESM案例揭示了预防性和二级预防的失败：供应商级别的部署在没有足够严格的独立审查的情况下进行了，而且一旦模型投入使用，没有固定的跨机构观测站来早期发现和解决系统性能问题。

三级预防在不同情况下的表现有所不同。在两个案例中，一旦问题被识别，治理任务不再仅仅是“改进模型”，而是要确定哪些患者或机构受到了影响，需要哪些补救或审计措施，如何共享本地学习结果，以及如何防止类似事件在其他地方发生。这正是公共卫生准备工作旨在在事件发生后提出的问题。

4.7 三方准备工作框架在医疗保健人工智能中的应用
三方框架不是抽象的叠加，而是直接基于案例证据构建的。肺炎案例揭示了预防性措施的失败：机构孤立的培训数据、隐藏的环境异质性和对内部验证的过度依赖导致了一个看似更强大的模型。ESM案例揭示了预防性和二级预防的失败：供应商级别的部署在没有足够严格的独立审查的情况下进行了，且模型投入使用后没有现有的跨机构观测站来早期发现和解决问题。三级预防则以不同的方式体现出来：在两个案例中，一旦问题被识别，治理任务不再是简单地“改进模型”，而是要确定哪些患者或机构受到了影响，需要什么补救或审计措施，如何共享本地学习结果，以及如何防止类似事件在其他地方发生。

图4展示了完整的三方准备工作框架，展示了预防性措施、二级监控和三级响应如何在三个层面上相互关联，包括各自的目标、核心机制和与两个案例的关联。表4详细列出了它们的目标、核心机制和与两个案例的关联。

5.**讨论**

以下小节将解释该框架的附加价值，将其置于现有治理方法背景下进行定位，确定实际的实施优先事项，并总结本文在理论、方法论和实践方面的贡献。

**5.1 公共卫生视角的附加价值**

本文的核心观点是，公共卫生准备为医疗保健人工智能（AI）治理增添了一个缺失的层面。现有的方法仍然至关重要，但它们本身无法提供针对人群暴露、基础设施传播、延迟识别和多机构协调的治理语言。这种视角将问题从“模型技术是否强大”转变为“系统成为医疗基础设施的一部分后，暴露情况是否得到有效治理”。即使模型表现良好，如果缺乏外部验证、可观测性、升级路径以及中断部署的授权，其治理也可能不足。公共卫生准备还涉及到标准评估通常忽略的人群层面问题：有多少人受到暴露、哪些人尤其脆弱、病情恶化能多快被检测出来，以及出现信号时应当采取何种响应措施。然而，这种流行病学框架也有明显的局限性，需要明确说明。

**流行病学框架的边界与差异**

这种类比也有其局限性。AI故障不会通过人际接触自我复制，暴露通常取决于采购、配置、整合或工作流程的采用，而不是非自愿的生物传播。因此，控制措施依赖于回滚、界面抑制、阈值调整或安全模式运行，而不是隔离。此外，该框架并不意味着爆发现象的规律可以机械地应用于AI事件。其价值在于在不确定性下实现监督、早期预警、升级和公平保护的制度逻辑。因此，这种框架最适合具有高影响力、规模化、耦合性和工作流程中心性的临床AI系统，而不适用于低风险工具、仅用于研究的模型或孤立的原型系统。

**5.2 与算法监控、安全工程和监管的关系**

该框架并非算法监控、安全工程或监管的替代方案，而是一种整合架构。算法监控关注的是已部署系统的局部性能、漂移、不良事件和更新周期；而公共卫生准备则关注共同暴露、共模脆弱性、升级阈值以及多个站点面临同一危险时的协调响应。因此，公共卫生准备在操作上将这些现有工具连接起来，并将其扩展到单个组织之外。近期文献也指向这一方向：呼吁进行重复的本地验证[44]、围绕预期触发效果设计的监控系统[45]、如FAIR-AI这样的机构审查框架[46]，以及包含部署后监控的部署路径[47]，所有这些都在强调一个结论：治理不应在初次批准后结束。相关概念性研究还列举了数字医学AI在设计、评估和部署过程中反复出现的“问题”，强调即使单个模型在技术上看起来很强，这些系统性缺陷也可能削弱安全性和可靠性[48]。

安全工程方面的联系尤为重要，因为它将注意力重新引向了控制结构、反馈循环、升级权限、配置管理和回滚能力，而不仅仅是模型本身。这就是为什么采购条款、界面设计、警报治理、变更管理记录和部署后报告在这里开发的框架中与验证指标并列的原因。用STAMP的概念来说，问题不仅仅是一个组件是否失败，而是更广泛的控制结构是否及时检测并限制了不安全行为[5]。

同样的观点也适用于关键基础设施框架。将某些医疗保健AI系统描述为关键数字基础设施并非夸大其词。这是一种识别治理负担最高的系统类别的方式：这些系统在临床上有重要意义、在操作上处于中心地位、难以观察，并且在多个基础设施之间广泛耦合。并非所有模型都属于这一类别。有限范围的本地质量改进模型可能不需要观测级别的监督，而嵌入常规护理中的供应商分发型脓毒症预测器则需要。这种有限的范围是一个优势。该框架对于那些因规模、耦合性和局部可见性低而导致故障模式复杂的高影响力AI系统最具说服力，因为这正是常规治理工具最可能失效的领域。这些实际优先事项直接源于本文的核心理论、方法论和实践贡献。

**5.3 实际实施优先事项**

在机构层面，有三个实际步骤值得注意。首先，卫生系统应维护一份正式的已部署和试点AI系统清单，按照临床领域、临床重要性、实施范围、基础设施耦合性、供应商依赖性以及安全回退模式的可用性进行分类。其次，高影响力系统在上线前应进行特定站点的验收测试和独立于机构的第三方证据验证。第三，部署后的监控应直接与患者安全、质量改进和事件指挥结构相关联，而不仅仅作为独立的数据科学练习。采购条款还应确保数据访问、版本透明度、变更记录可见性和事件协作义务，这些都是有意义部署后评估所必需的。

最近的证据加强了脓毒症案例的研究，而非削弱其重要性。在2026年的一项多中心前瞻性验证中，Epic Sepsis Model 2的整体表现优于版本1，但仍显示出显著的机构间差异、低阳性预测值和高警报负担。这一发现进一步证明了重复本地验证、工作流程整合和部署后警报抑制策略的必要性[15]。

在区域或国家层面，最有前景的下一步是开发医疗保健AI的哨兵观测功能。这些功能不必以新官僚机构的形式出现，可以通过专业协会、健康信息交换平台、监管机构支持的网络或多机构合作来建立，这些合作可以定义最低限度的监控数据集和事件类别。其架构应该是协作的，并在可能的情况下采用联邦化方式：可比的本地指标、共享的病例定义和汇总的信号解释无需集中所有患者级别的数据。关键要求是可比性。如果没有标准的病例定义、模型版本控制、阈值元数据和共享的报告规则，观测平台就无法区分本地噪声和跨站点的信号。

一个现实的第一步是建立一个涉及五到十个不同卫生系统和小范围高影响力工具的试点哨兵观测网络。这种渐进式设计与更广泛的治理趋势一致：FUTURE-AI强调整个生命周期的可信度和可部署性，而更新后的经合组织AI原则则强调问责性、鲁棒性、互操作性和国际合作[49,50]。公共卫生研究所、患者安全机构或受信任的学术联盟可以承担协调职能。参与机构可以在本地保留患者级别数据，同时共享标准化的性能信号、事件报告和模型版本元数据。像HL7 FHIR和OMOP Common Data Model这样的通用互操作层可以支持这种联邦化设计[51,52]。同样的逻辑也适用于用于文档和通信的生成系统，因为共享模型、提示模板或集中推送的更新可能会在不同站点间传播错误模式或遗漏。资金可能需要一种结合公共基础设施支持、报告期望和与采购及上市后义务相关的供应商参与的混合模式。

在国际层面，最可信的近期目标并不是建立一个完全成熟的“数字IHR for AI”。那还为时过早。一个更合理的目的是针对具有共同供应商、云服务或部署依赖性的广泛部署的临床AI故障，采用GOARN启发的协调机制。这样的机制可以支持事件分类、信号共享、汇总的技术调查、协调的供应商参与以及缓解措施的传播。其最终的法律定位仍不确定，应视为未来治理设计的问题，而不是既定的原则。

**5.4 理论、方法论和实践贡献**

总体而言，本文提出了一个理论贡献、一个方法论贡献和两个实践贡献。

理论贡献是采用治理术语而非单纯的技术术语来定义系统性的医疗保健AI风险。通过将风险置于相互作用的结构、组织、技术、认知和文化路径中，本文阐明了某些医疗保健AI故障无法仅仅作为孤立软件缺陷来理解的缘由。

方法论贡献是将流行病学推理作为一种规范化的桥梁，用于连接技术事件和人群层面的治理。这包括将流行病学和监控概念适应于医疗保健AI，区分基于指标的、基于事件的和哨兵检测功能，并将DALY/QALY推理更谨慎地定位为结果导向的框架，而不是作为过早得出结论的工具。

第一个实践贡献是识别出系统性医疗保健AI风险的五个与治理相关的属性。这些属性有助于区分普通的实施问题和需要准备逻辑处理的危害。第二个实践贡献是三方准备的框架本身。通过围绕一级预防、二级监控和三级响应来组织治理，该框架提供了连接验证、监控、升级和跨站点学习的具体方法。

**5.4 限制与未来工作**

本节指出了分析的五个方法论和范围上的限制，并将每个限制映射到具体的未来研究重点。

本文有几个局限性。首先，这不是一项系统性回顾。该框架是基于治理文件、安全文献和两个广泛讨论的案例的 purposeful 综合，而不是基于详尽的证据审查。这种选择适合于概念发展，但限制了关于全面性的主张。框架本身的证据基础进一步加剧了这一范围限制。其次，该框架通过两个美国案例进行研究说明，这些案例涵盖了不同的故障模式、分布式的潜在脆弱性和集中式的供应商规模暴露，但无法建立完全的普遍性。基础研究也反映了特定模型代际和临床实践时期的特点。CNN架构、数据管理实践和供应商模型已经发展，因此后来的系统可能会通过不同的技术机制失败，即使治理逻辑仍然适用。未来的工作应在自然语言系统、生成型临床辅助系统、强化学习应用和多供应商决策支持生态系统中测试该框架。

除了案例证据外，本文对公共卫生语言的运用也有其方法论上的限制。结构对应性仅在治理功能层面进行了论证，并未作为数学同构的正式证明。需要额外的实证工作来具体化这里提出的五个属性，并确定哪些规模、耦合性、延迟和脆弱性的组合应触发特定的治理行动。

第四，疾病负担的讨论仍然是方法论层面的，而非实证性的。本文认为DALY和QALY是未来观测平台的正确概念工具，但它并未从现有的脓毒症案例证据中得出明确的全国性负担估计。这种克制是经过深思熟虑的。在能够将负担估计视为决策级证据之前，需要进行前瞻性的多机构监控和结果关联。

对于作为框架实践成果提出的机构机制也存在类似的限制。第五，这里提出的机构设计——包括哨兵观测平台、更强的外部验证要求和GOARN启发的协调机制——尚未经过实际测试。它们的可行性、成本、法律基础和潜在的意外后果（包括对小型开发者和医院的合规负担）仍需通过实施研究和利益相关者参与来评估。未来的工作应专注于医疗保健AI事件的标准化案例定义、最低限度的监控数据集、校准的升级阈值、基于指标和事件的报告路径的比较评估，以及不同司法管辖区的治理模型比较评估。

**7. 结论**

本文探讨了如何将公共卫生准备的概念应用于治理医疗保健AI中的系统性风险。答案是，当高影响力的临床AI成为关键数字健康基础设施的一部分时，准备措施增添了一个缺失的治理层面。模型中心的评估仍然是必要的，但这还不够；治理还需要对外部验证、监控、升级、补救和共享学习制定明确的安排。两个案例说明了这一点：肺炎筛查模型展示了分布式的潜在脆弱性；机构特定的患病率梯度、获取过程中的问题和流程差异可能在跨站点评估之前隐藏，直到系统学习了错误的信息。Epic Sepsis Model展示了集中式的供应链暴露；一个供应商规模的系统在现实环境中表现不佳，并可能给工作流程带来沉重的负担，单个机构难以单独解读。

由此形成的框架做出了四个相互关联的贡献：它通过相互作用的结构、组织、技术、认知和文化路径定义了系统性的医疗保健AI风险；将流行病学概念适应于监控词汇；明确了DALY/QALY推理可以作为结果导向的桥梁，而不至于超越证据范围；并识别出五个支持三方准备架构的治理属性。

从实践角度来看，高影响力的医疗保健AI系统应在机构独立的设置中进行独立的部署前验证。卫生系统和监管机构还应开发能够通过基于指标的监控、基于事件的报告和选定的哨兵站点聚合可比较的部署后证据的哨兵观测功能，并针对广泛部署的故障采用GOARN启发的协调机制。

这一结论仍然是有意限定的：医疗保健AI故障在生物学上并不等同于流行病，爆发现象的规律并不自动适用于软件事件。但一些临床人工智能系统如今已经具备足够的覆盖范围和影响力，可能会对整个群体造成危害。治理措施应当反映这一现实，首先可以建立试点性监督机构，并结合独立的外部验证机制和共享的病例报告系统来进行管理。