London Ambulance CAD 与患者安全问责

摘要

伦敦救护车服务于 1992 年 10 月 26 日将尚不完整的运营模式投入全面运行。调查发现软件未完成且测试不足，全负荷弹性和回退未测试，状态和位置数据不可靠，通信受限，培训不一致，用户所有权薄弱，以及控制室变更取消了熟悉的纸质和人工纠正路径。
10 月 26 日和 27 日的事件必须与 11 月 4 日的崩溃区分开来。根据调查，前两天计算机在狭义技术上并未失效；设计缺陷和运营缺陷相互作用，产生了系统故障和不可接受延迟的症状。11 月 4 日，一个微小的编程错误确实导致了崩溃，而未经充分测试的自动切换未能维持服务。
问责制遵循对就绪证据的实际控制。供应商有责任提供真实的实施和质量证据；LAS 管理层控制需求、集成、培训、回退和切换；董事会和区域卫生当局控制审查；部长承担公共监督。工作人员和控制室用户是运营证据的重要来源，而不是为一个假定可预测不完美存在的系统提供方便的借口。
调查并未拒绝自动化。它认为 LAS 和公众可以受益于 CAD，建议继续规划并提出逐步推进的路径。后来关于服务转机的研究同样指出了用户参与、现实的时间安排、原型设计、充分测试、简单的分阶段实施、基础设施信心和信任作为修复机制。

紧急调度是一个状态估计问题

紧急调度系统不仅需要知道其软件进程是否在运行。它必须知道呼叫已被理解，事件位置可用，特定救护车可用，其记录的位置可信，动员消息已到达工作人员，并且工作人员的下一个状态更新已返回控制中心。它必须在需求、地理和人为情况变化时保持该运行图景的一致性。在中等负载下的令人信服的演示不能证明在困难轮班期间该图景仍将保持真实。

伦敦救护车服务调查描述了四个核心指挥功能：接听和验证呼叫、识别适当资源、传达动员以及管理救护车资源的位置。预期的计算机辅助调度系统将这些功能连接到地名录、地图、移动数据终端、自动车辆定位、无线电通信和管理信息。每个组件在局部可能看起来合理，而综合图景却是错误的。定位可能已经过时，车辆可能已更改状态，数据消息可能失败，或者呼叫可能返回到队列而控制器看不到原因。

这就是为什么 1992 年的故障不能简单地描述为一个糟糕的应用程序。CAD 正在成为服务的控制面：来自呼叫者、工作人员、无线电和数据库的不完美报告被转化为关于真实救护车的决策的地方。因此，其就绪性取决于整个调度机构。软件质量重要，但通信容量、房间布局、人员配备、培训、工作实践、异常处理以及当这些要素不一致时停止过渡的权力也同样重要。

这种框架也保护了该案例免受反自动化的结论。手动调度过程有严重的局限性。纸质事件表格在控制室内物理移动；分配器依赖于地图、无线电报告和维护的车辆记录；语音信道可能排队；识别重复呼叫依赖于记忆和判断。调查发现人们对使用技术改善服务有广泛支持。失败不是自动化的雄心。而是允许自动化在机构拥有令人信服的证据表明其运行状态、人员和恢复路径准备就绪之前行使实时权力。

项目试图一次性跨越自动化鸿沟

LAS 此前已尝试计算机化指挥控制。一个始于 1980 年代的早期项目在 1990 年因负载测试显示无法满足预期需求而被放弃。替代工作始于 1990 年秋季至 1991 年 2 月制定的新系统需求规格说明书。合同随后于 1991 年签订，全面实施最初定于 1992 年 1 月。这段历史本应使系统负载、不断变化的需求和集成风险成为核心验收问题。

新概念比计算机化接听辅助工具更为雄心勃勃。LAS 寻求一个高度自动化的系统，其中大部分呼叫将收到计算机生成的最合适救护车建议。只有复杂病例需要专业分配器。自动车辆定位和移动数据将提供资源图景；接听员可将事件推进到分配；调度最终将在伦敦范围内运作，而非通过熟悉的分区模式。调查将这种从完全手动流程到一次性完全自动化的转变定性为高风险跳跃。

需求工作也存在所有权和边界方面的弱点。规格说明书详细且规定性强，但救护工作人员早期参与很少，而他们的工作将发生变化。与现有通信系统及其他 LAS 系统的接口未完全定义，调查未发现需求规格说明书正式签收的证据。一份精确的文件仍可能不完整，如果决定成功的人员、接口和运营假设未接受它的话。

在安全关键型服务中，需求并非在功能列出时就完成了。它们必须规定系统在车辆报告失败、无线电覆盖不佳、两位呼叫者不同方式报告同一事件、工作人员使用另一车辆、工作站锁定或队列超出屏幕可见空间时的行为。它们还必须说明哪些证据允许每个自动化步骤替代现有的人工控制。LAS 指定了一个强大的理想工作流，但未将该工作流绑定到其必须运作的不完美条件上。

近乎完美的数据并非安全的运营假设

调查反复指出系统依赖于近乎完美的车辆位置和状态信息。如果系统知道每辆救护车的位置和每个工作人员在做什么，自动化建议可能有用。如果不知道，它可能自信地推荐一个资源，而一个更近或更合适的资源却存在于其记录图景之外。分配例程无需在数学上出错，运营答案就可能错误。

存在许多通往不完美状态的常见途径。工作人员可能在事件压力下错过或错误定时状态按钮。传输可能遇到无线电盲点或拥塞信道。移动终端可能显示成功交换，而控制屏幕却持有另一状态。呼号可能缺失或交换。工作人员可能使用未记录的车辆。定位设备和安装可能不可靠。一些员工也可能错误或故意使用系统，但调查未发现支持管理层将 CAD 问题广泛归咎于故意滥用的直接证据，并将此类行为最多视为众多因素之一。

相反，不完美成倍增加了工作。错误状态导致糟糕的建议和异常消息。未解决的异常会产生更多异常。已覆盖的呼叫可能在预期状态周期未完成时返回到注意列表。随着列表增长，消息移出视野，处理变慢，员工纠正导致消息的状态的时间减少。延迟促使公众再次呼叫，在系统前端增加工作量。因此，运营负载是内生的：系统对不完美数据的响应为同样受限的人员和信道创造了更多需求。

这种反馈机制是该案例的核心。数据质量不是可以在上线后修复的维护指标。它决定了服务认为可以派遣哪辆救护车。异常容量不是次要的用户界面偏好。它决定了操作员能否比错误累积更快地恢复真相。需求真理意味着证明服务能够承受真实比例的缺失、延迟和冲突信息，而不是记录理想输入将产生理想输出。

采购使时间和价格成为技术设计的一部分

采购遵循了区域卫生当局的常设财务指示，包括公开招标和除非有充分理由否则倾向于最低投标。调查未发现正式规则被简单忽略。它发现规则对重大信息技术采购几乎没有提供定性指导，更强调价格而非供应商和综合设计能否安全完成工作。

最初有 35 家公司表达了兴趣，17 家提供了全部或部分系统的建议书。许多潜在供应商对全面实施的时间表表示担忧。他们被告知这是不可协商的。尽管评估协议对功能能力、吞吐量、可用性和弹性进行排名，但调查发现无法满足全部要求或截止日期实际上会使投标无效。因此，时间表作为更高层次的技术要求运作：承认需要更长验证或阶段的设计处于劣势。

主要供应商规模较小，承担了比其以往工作更大的项目。然而调查也得出结论，在强加的时间限制和广泛要求下，没有软件公司能够交付可行的解决方案。这一发现阻断了唯一缺陷供应商的便利故事。其他供应商有延迟的组件和技术问题；LAS 拥有雄心勃勃的概念、截止日期、集成环境和实时服务；区域采购规则塑造了选择；项目领导层必须决定交付的证据是否充分。

合同还使项目管理责任模糊不清。LAS 期望主要供应商管理整个集成，但合同未明确分配该角色，供应商难以管理自身贡献。LAS 人员默认承担了更多控制权。在多供应商安全系统中，模糊的集成商是一个运营缺陷。必须有人拥有跨 CAD 软件、硬件、无线电接口、定位服务和移动终端的端到端行为。采购不能仅仅购买组件并希望问责制在其接缝处出现。

项目管理将压力转化为乐观保证

LAS 选择了 PRINCE 项目管理方法，但服务方和供应商均未带来丰富的应用经验。调查未发现适当结构的 IT 执行委员会、项目委员会、项目管理团队和保证团队。早期没有全职 LAS 参与者，项目计划未留出审查和修订空间，会议中记录的担忧未能可靠转化为决策或升级证据。

项目报告通常依赖于乐观保证。供应商报告进展；执行董事向 LAS 董事会和西南泰晤士区域卫生当局保证；已知问题被描述为正在纠正。1992 年 3 月的内部审查要求对通信进行容量测试、签署的实施策略、受控的软件更改和培训审查。该审查未按董事会要求提交给董事会。首席执行官随后的报告称没有证据表明完整软件不会证明可靠。调查用一个持久的安全原则回应：不存在不可靠的证据并不是对关键任务系统将执行的积极保证。

变更控制进一步削弱了证据基础。供应商有时在正式的项目问题报告流程之外进行所请求的软件更改。因此，先前测试过的代码可能在项目组不知情的情况下发生变化，新缺陷可能进入。到 10 月 26 日，已提出 1,513 份问题报告，其中 81 份仍未解决。其中两份属于服务中防止在真实环境中运行的严重降级类别，四十四份属于与患者服务较差相关的类别。全面部署进行时，LAS 自身的问题分类仍记录着严重的运营故障。

董事会和 RHA 确实看到了持续困难，但都没有委托独立深入的技术审查，而模式表明这是必要的。保持距离的治理变成了被动接受管理层信心。董事会不需要调试软件，但它必须要求可读的就绪证据：集成测试结果、未解决的高严重性缺陷、培训完成、回退演练、通信容量、用户验收以及明确谁可以说“不”的签署决定。没有这些材料，监督就变成了一条向上传递乐观而非风险真相的链条。

测试从未排练过完整的调度服务

功能测试和负载测试在整个项目中都有讨论。1992 年 1 月的首次尝试因软件不完整且并非所有组件可用而无果而终。后来的几个月，CAD、定位跟踪和通信的各个部分得到测试，但调查发现完整的集成系统从未作为一个整体进行测试。软件、移动数据、定位技术和无线电接口的持续变化意味着没有稳定的基线可以信任完整的服务排练。

差距不仅限于代码覆盖率。全负荷下的硬件弹性未经验证。切换到第二个文件服务器未得到充分测试。通信容量在实施前未系统计算。延迟或缺失车辆状态的后果未以真实比例呈现。测试脚本未充分注入已知在伦敦实际运营中发生的位置不一致和通信故障。因此，系统是在一个比其被要求控制的世界更干净的环境中进行测试的。

现实负载不仅仅是每小时的目标呼叫次数。它包括需求形状和错误产生的工作：轮班变更使许多工作人员登录、无线电拥塞、重复呼叫、寻求预计到达时间的呼叫者、状态过时的车辆、重试的终端、运营商纠正分配以及产生更多异常的异常。它包括列表移出屏幕的认知负载以及资源搜索扩展到更远救护车时产生的延迟。系统可以通过合成交易率，但可能无法通过其为人员创造的工作量。

部署路径提供了警告证据。在错过 1 月截止日期后，计算机化接听和地名录被引入，事件详情打印出来用于手动分配和语音调度。这种部分使用带来了好处，但屏幕锁定、服务器偶尔故障，一次事件在打印机关闭时保持在打印机缓冲区中。后来的分区试验揭示了不完整的状态报告、不可靠的定位、通信过载、移动终端问题和建议错误。这些不是放弃技术的理由。它们是本应控制进展的测试发现。

无线电和车辆状态构成了安全关键的控制回路

系统的资源图景依赖于一个回路：从工作人员和车辆通过移动终端、无线电基础设施和接口软件进入 CAD，然后通过动员消息返回。调查发现，CAD 对通信基础设施的影响未得到适当和系统的考虑。没有正式计算显示新系统将如何负载现有通信。在全面实施后审查无线电网容量的建议颠倒了所需顺序；容量必须在服务依赖之前得到证明。

运营环境使完美通信不切实际。伦敦包括无线电盲点、移动车辆和高峰期。在轮班变更时，工作人员登录可能拥塞信道。失败或延迟的状态传输使 CAD 拥有过时的图景。终端和中央屏幕可能因确认例程中的问题而不一致。用于解决不确定性的语音流量本身可能增加拥塞，而限制语音可能消除暴露错误或重复分配的人工交叉检查。

自动车辆定位也有类似限制。即使组件大致可用，城市传输和位置推断有时也可能出错。调查的前瞻性观点并非定位技术必须被丢弃。而是 CAD 必须识别并安全处理这类技术将不可避免地提供的的不完美位置信息。因此，组件边界的可靠性需要具有不确定性意识的系统响应，而非组件永远不会不确定的承诺。

10 月 26 日，最小化语音通信的指示提高了成功数据动员的报告率。然而，没有语音联系，错误或多次分配更不可能得到纠正。这说明了为什么局部指标可以向正确方向移动而系统安全性却恶化。更多消息标记为成功并不能证明控制中心持有正确图景或预期的工作人员实际前往预期事件。

同样的教训适用于工作人员状态报告。按下一系列按钮不是孤立的用户职责；它是反馈控制的一部分。培训、界面设计、事件压力、设备状态、通信覆盖范围和信任都影响它。当管理层将不完整状态主要视为劳动力行为时，它低估了使正确报告变得困难的系统条件以及报告失败时安全降级的设计职责。一线合规可以改善输入，但不能治愈一个在输入不理想时变得不稳定的设计。

培训和用户所有权是系统的一部分

调查发现员工普遍对使用信息技术改善救护服务持积极态度。他们缺乏信心是针对当前系统和引入方式。这很重要，因为它拒绝了对员工原则性抵制自动化的讽刺。人们经历过锁定屏幕、不一致的车辆信息、不成功的传输和变化中的程序。不信任部分是对运营证据的观察。

培训不完整且不一致。有些培训在延迟实施之前很久就进行了，导致技能在使用前退化。不断的软件更改使培训材料和已学习的例程不稳定。控制室人员接受了不同能力水平的培训，但覆盖范围不一。工作人员和控制室人员基本上分开培训，尽管成功调度要求每一方理解其行动如何影响另一方。调查建议联合要素，以便双方都能理解共享的控制回路和每个角色面临的压力。

全面实施还改变了物理和社会运营环境。控制室重新配置。资源分配器与无线电操作员和异常纠正者分离。员工在不熟悉的岗位上工作，没有部分操作期间使用的纸质备份，并且与以前一起解决问题的同事接触更少。技术上未改变的应用程序被放置在一个新变化的工作系统内部。测试旧的房间布局不能证明新的布局。

用户所有权有时被简化为态度或变革沟通。在这个案例中，它具有更尖锐的安全含义。用户需要在需求、终端设计、操作程序、排练和验收中拥有合法角色。他们需要看到故障得到解决，并信任报告问题可以改变截止日期。没有这种权力，“买账”变成了对已做出决定的压力认可。

管理层还期望 CAD 强制执行工作实践的变化，包括资源选择和跨站点区域的移动。调查将该系统描述为运营上的紧身衣，员工仍在其内尝试局部灵活性。软件可以支持商定的更改，但不能通过规范制造协议或抹去情境知识。如果工作人员使用另一辆车或本地工作人员识别出更好的资源，系统必须要么适应有效实践，要么机构必须通过咨询、培训和负责任的运营政策在自动化依赖之前改变实践。

10 月 26 日和 27 日产生了故障，但没有狭义的技术崩溃

1992 年 10 月 26 日 07:00，LAS 首次将预期系统全面推广至全伦敦使用。代码在前几周没有突然改变。决定性的变化是运营层面的：没有纸质记录或激活箱作为备份，重新配置的控制室，分离的角色，自动化建议作为分配基础，以及接听员能够分配部分资源。在半手动操作期间帮助员工补偿不可靠信息的控制措施被一并移除。

调查明确指出，CAD 系统及其用户都未准备好。软件不完整、调整不足且未充分测试。全负荷硬件弹性和回退到第二个服务器未测试。移动数据传输问题仍然存在；对自动定位的信心是有限的；员工未得到全面培训；设计未针对足够多的不准确或不完整信息进行测试。在这种情况下仅使用计算机生成的资源分配，在调查的判断中是一个高风险决策。

随着活动从轻负载开始增加，系统对更少车辆保持正确状态和位置。新房间和工作流程使人工纠正更加困难。由于明显可用的资源更少，建议变得不太合适，搜索范围更广。错误、重复或延迟的分配产生了更多异常。已覆盖的呼叫在预期状态序列未完成时返回到注意列表。队列堆积，处理变慢，消息滚动到可见屏幕之外。面对更多工作的操作员修复底层状态的能力下降。

然后，面向公众的回路加剧了内部回路。延迟或未覆盖的事件促使呼叫者再次拨打电话。重复报告和回拨增加了电话量。接听员太少和系统变慢延长了应答时间，这可能导致更多呼叫和进一步延迟。调查驳回了声称 10 月 26 日和 27 日事件或运送患者数量异常繁忙的说法。表面上的增加大部分来自响应延迟产生的未识别重复和回拨。

这种时间线支持两个必须同时成立的陈述。首先，计算机系统在 10 月 26 日和 27 日没有在狭义技术上崩溃。它大致执行了其设计用途。其次，设计和运营缺陷不断累积，直到服务表现出系统故障的症状，包括不可接受的响应延迟。仅说计算机“持续运行”会错误地将进程可用性视为成功的紧急控制。说它在技术上崩溃会抹去更具启发性的故障机制。

就患者安全而言，即使没有未经支持的伤亡声明，后果也很明确。紧急呼叫被延迟，救护车到达时间有时变得不可接受，控制人员无法维持可靠的事件和资源图景。一个安全关键型服务失去了及时的命令证据。在最终伤害统计能够确定之前，危险就已出现：患者和呼叫者暴露于不确定性之中，即帮助是否已分配、是否在移动以及何时可能到达。

因此，切换决策是核心的问责关口。领导者知道软件不完整、存在未解决的严重问题、通信担忧、培训差距、不信任和未测试的回退。他们也面临改进绩效的合法压力。压力解释了为什么早期结果有吸引力；它不能证明准备就绪。决策者需要优先考虑证据而非宣布日期的权力，以及一份显示哪些验收条件已满足的记录。调查无法理解为什么在存在如此多已知缺陷的情况下全面实施得以进行。

11 月 4 日崩溃是另一种故障

在 10 月 26 日和 27 日的问题之后，控制回到大致类似于早期的半手动安排。呼叫和位置查找仍使用计算机，事件详情被打印，人工识别资源，动员可使用 CAD、站点打印机或移动数据。语音信道帮助解决误解。员工对这种组合更为舒适，它相当成功地运行到 11 月 4 日凌晨。

11 月 4 日 02:00 刚过，系统变慢然后锁定。调查将这次实际崩溃追溯到约三周前引入的一个微小编程错误。与动员相关的代码消耗少量服务器内存而未释放；重复使用最终耗尽了可用内存。调查批评了代码更改方面的粗心和质量保证不足，同时也指出该故障不太可能通过常规程序员或用户测试单独发现。

这种区分很重要，因为它防止整个案例被简化为那个错误。内存缺陷不能解释 10 月 26 日和 27 日的反馈回路。它也不应成为关于一个程序员的道德故事。关键服务具有变更审查、独立质量保证、监控、容量告警和恢复，正是因为一个小的局部缺陷可能逃脱。问责制在于为什么一个缺陷能够在未被发现的情况下累积到服务损失，以及为什么恢复未能控制住它。

自动切换到备份服务器未能保留运行模式。回退是为预期的无纸化系统指定的，而打印机是在最初截止日期错过之后作为临时权宜之计添加的。服务器故障对该基于打印机配置的影响未经测试，调查未发现自动回退本身得到充分证明的记录。当崩溃发生时，员工使用录音记录呼叫并恢复到完全手动、基于纸张的控制。运营中断受限于低夜间负载，而非成功演示的技术恢复。

问责制遵循对关口的实际控制

供应商控制实施细节、代码质量、进度报告以及更改行为如所称的证据。它应承担纪律严明的配置控制和诚实披露，当时间表超出其能力时。但供应商不控制整个服务、选择每个需求、培训每个用户、拥有无线电资产或拥有将 CAD 投入全伦敦运营的单方面权力。供应商问责是真实且有限的。

LAS 执行管理层控制雄心、时间表、集成环境和推进决策。它控制纸笔和语音保障是否保持可用、培训是否完成、运营是否接受了新程序，以及是否有经验丰富的独立项目经理和质量职能参与。管理者在压力下努力工作的事实并不能消除这些控制。它使明确的就绪标准更为重要，因为个人承诺可能被误认为是客观保证。

项目和运营领导层必须将组件报告转化为端到端声明。这意味着协调未解决问题、软件版本、通信性能、位置准确性、人员配备、房间配置和回退结果。指定的切换权威需要看到该证据，听取独立的技术和用户反对意见，并拥有明确的延迟权利。如果没有人同时拥有系统图景和停止权，项目就可能推进，因为每个参与者假设另一个参与者拥有剩余风险。

LAS 董事会控制治理审查。调查发现它收到了关于相关供应商经验的误导性安慰，并未收到不利参考信息。更广泛地说，它接受了执行保证，而没有独立审查测试项目的真实状态。董事会问责制不要求成员选择编程工具。它要求他们询问一个开创性的紧急控制系统是否有独立保证、现实的负载结果、经过测试的回退和明确的未解决风险。

西南泰晤士 RHA 保持距离地管理 LAS。正式采购规则得到遵守，LAS 未寻求区域技术帮助。然而 RHA 反复遇到担忧，并接受了它们将得到解决的保证。调查得出结论，问责制在纸面上看起来很稳固，但未能为董事会或区域提供足够信息以行使职责。保持距离的监督不能意味着与被委托的安全关键型服务的证据保持距离。

部长责任在另一个层面运作。议会不是主要技术调查者，党派辩论中的声明不应被视为关于软件因果关系的调查结果。Hansard 确实显示了公共问责链。10 月 28 日，国务大臣宣布直接语音支持、外部调查以及代理 LAS 领导层通过 RHA 和 NHS 管理层的定期报告，以便部长们随时了解情况。在调查于 1993 年 2 月报告后，她质疑对部长的问责是否足够有力，寻求加强问责的建议，并注意到 IT 总监和分阶段 CAD 实施的计划。

一线员工控制特定行为，如报告状态和响应动员，但他们不分享对采购、测试范围、房间设计或切换的同等控制。他们的经验也是领导者需要使用的证据。将员工视为仅仅抵制将关于终端、无线电信息和运营适配性的警告转化为行为叙事。问责制需要区分用户遵循可行程序的职责与管理层证明程序和技术在出现普通人为和通信错误时仍然安全的职责。

患者安全风险不需要虚构的死亡人数

伦敦案例经常以归因于延迟救护车的具体死亡人数被重述。调查提供了更严格的边界。它指出，只有验尸官法庭能确定延迟是否导致死亡，且在当时考量的案例中，没有验尸官法庭得出救护车延迟到达导致患者死亡的结论。1993 年 2 月的议会回应重复了这一立场。

该发现不能被扩大为“无人死亡”、“无人受伤”或“故障无害”。它是关于验尸官对因果关系的结论的陈述，而不是对所有结果的普查。调查还强调了延迟应答、调度和到达造成的痛苦。它记录了不可接受的响应性能和不合格的紧急服务。这些已经足够成为患者安全分析的理由。

安全问责始于暴露于不受控制的风险，而不仅仅是有证据的致命终点。当控制中心不知道事件是否已覆盖、动员被重复或延迟、或呼叫因先前呼叫者没有可靠答案而累积时，领导者已失去了保护患者所需的证据。不确定性本身在运营上具有重要意义。在机构必须调查和修复之前，不需要后来的法律或临床因果关系发现。

谨慎的伤亡语言也改进了因果分析。一个戏剧性的死亡人数可能将注意力吸引到最情绪化的指控上，而离开有证据记录的控制措施。调查支持对中断的呼叫、不可接受的延迟、不可靠的分配、公众痛苦和信心受损的有力说明。这些发现使就绪失败变得严重，而无需将指控转化为事实。

回退和切换权威是治理控制

LAS 经验表明为什么连续性计划必须与主系统一起设计。纸质备份、语音联系、站点知识和手动分配不仅仅是技术之外的旧方法。在部分操作期间，它们允许人们检测不良状态、运用判断并保持事件可见。移除它们改变了整个服务的故障容忍度。这种改变需要自身的验收理由。

降级模式必须说明触发因素、由谁宣布、哪些功能继续、如何进行飞行中的事件协调以及员工如何知道哪个记录是权威的。必须在实际负载下进行排练。切换服务器只是其中一层。如果打印机、终端、队列或工作分配在切换后表现不同，技术可用性可能无法保持指挥。如果员工无法恢复完整的事件列表，即使硬件在线，回退也失败了。

切换权威是这些控制措施变得具有约束力的点。决策应基于预定义的证据：没有可能导致严重服务降级的未解决问题；稳定的配置；全负荷集成测试；跨无线电、位置和终端的故障注入；当前角色培训和观察到的能力；用户和运营验收；配备人员的异常处理能力；以及经过演示的与手动或半手动模式的转换。任何未满足的条件应指定风险负责人和记录为什么暴露是可接受的。

权威还必须能够停止而免受组织惩罚。调查描述了一种将截止日期视为刚性且难以挑战的文化。仅存在于组织架构图上的“不”路并非运营控制。领导者需要保护技术和一线的异议，要求以书面形式处理反对意见，并防止公开日期或沉没成本默默改变验收阈值。

修复证据表明自动化可以赢得权威

调查的第一个 CAD 建议是 LAS 应继续规划计算机辅助调度系统。它发现人们对能够改善救护服务的技术有普遍支持，并描述了纸张流程的低效率。其前进计划要求系统适应商定的组织结构和程序，可靠且有弹性并经过测试备份，由管理层和员工拥有，以及以允许咨询、质量保证、测试和培训的时间表引入，并逐步部署。

提议的序列将日益增加的权威与日益增加的证明联系起来。临时的第一阶段只能在软件质量审查、测试、更强的打印和再培训之后恢复计算机接听和地名录功能。事件详情将仍可供人工分配器使用。第二阶段将在人工分配器仍选择资源的同时提供可靠的车辆定位和状态可用。它需要专业的通信审查和对基础设施更有信心。

只有在阶段被验收和经历之后，动员才会从语音转向移动数据。计算机资源建议首先可以是给人分配器的建议。接听员只有在建议、通信和底层状态赢得信心后才能获得分配权。在每个阶段，弹性、应急计划和回退都必须匹配持续服务的需求。这不是为慢而慢。每个阶段隔离了一个可以在实时条件下观察到的声明，然后再添加下一个依赖项。

治理修复伴随着技术分阶段进行。调查建议有经验的项目经理、一个涵盖服务各方的董事会项目小组委员会、可能来自有经验的外部人士的建议，以及一个可以直接接触董事会的 IT 总监。它还呼吁更好的定性采购指导、通信审查以及向公共机构和伦敦议员公开响应绩效的报告。这些措施将证据置于权威可以看到并采取行动的地方。

Hansard 记录了该修复的公共方面。1993 年 2 月，政府表示 IT 总监将监督分阶段实施，并寻求从 LAS 通过 RHA 到部长们的更强路线。10 月，一份书面答复报告了关于有效信息系统采购的新 NHS 指导以及关于调查建议执行情况的定期区域报告，包括未来的 CAD。议会声明不能证明每次修复都有效，但它们表明技术就绪已成为制度监督的一个明确事项。

后来一份经过同行评审的案例研究将一次更为成功的 LAS CAD 实施描述为转机。其比较识别了管理层对用户需求的关注、用户参与、更多资源、由验收驱动的更宽松时间表、建立信心的基础设施项目、参与和原型设计、充分测试、分阶段和简单的实施以及信任建立。这些发现是对后来计划的二次分析，不能替代调查对 1992 年的描述。

它们也不能证明一项干预导致了后来的成功。组织转机有多重影响，后来的条件也不同。它们的价值在于比较：后来的实施解决了几乎所有曾经有问题的类别。对比展示了当修复以运营条件而非口号表达时是什么样子。用户参与；基础设施赢得信心；测试充分；首次实施更简单；时间表跟随验收；信任通过交付的证据增长。

制度合法性依赖于可观察的调度状态

紧急服务要求公众信任呼叫者无法检查的决策。呼叫者看不到分配队列、无线电交换或状态数据库。因此，制度合法性取决于服务内部证明和向公众解释那些隐藏机制保持可靠指挥。当服务无法判断救护车是否真正可用或动员是否到达时，信心会因合理原因而动摇。

问责制不是出现故障后的集体指责。它是事先分配产生、质疑和采取证据的职责。实施者证明组件。集成者证明服务。运营者证明工作可以执行。领导层保护时间、资源和停止权。董事会独立质询就绪性。监督机构要求透明的绩效和修复。

London Ambulance 使 CAD 成为患者安全问责的考验，因为调度自动化被允许在服务图景脆弱时变得具有权威性。持久的答案不是拒绝计算机。而是使权威有条件：没有自动化控制真实的呼叫、工作人员和救护车，直到机构能够展示它在负载下如何保持真实、当它不真实时人员如何恢复，以及当证据不足时谁有权停止。

摘要