那起长达三周却无人察觉的医院账单故障

引言

去年春天，美国中西部某地区医院系统通过常规变更流程部署了一个排班补丁。这没什么大不了的——只是对出院时间与计费模块同步方式的一次例行更新。三周后，应收账款部门有人发现，有一批索赔因时间戳不匹配而被退回。等到IT部门追查到问题根源时，这个补丁已经影响了四百多名患者的保险报销申请。严格来说，其实并没有谁做错了什么。 这次更新通过了检查清单上的每一项测试。只是，那份检查清单本身并不合适。

这个故事让我印象深刻，因为它其实并非单纯关于医院。它揭示了当组织背后默默运行的系统被当作成品，而非需要定期审查的“活体基础设施”时，会发生什么。

你两年前搭建的自动化系统，已不再是你想象中的那个系统

大多数公司构建首个工作流自动化系统，是为了解决某个具体且显而易见的难题。人力资源团队厌倦了手动分发休假申请；销售运营人员将潜在客户分配流程自动化，以防止销售代表挑肥拣瘦。这些系统通常使用类似 Power Automate 的自动化工具构建——配置迅速，易于移交给任何愿意负责的人，且一旦运行起来便基本隐形。

问题在于，“一旦运行起来”就成了永久状态。没有人安排复审。构建者可能调岗或离职。与此同时，业务环境围绕着自动化发生了变化——新的CRM字段、不同的审批层级、一次合并导致系统处理量翻倍，而该系统原本只设计处理一半的负载。自动化流程仍按设计原样运行，这恰恰是问题所在。它原本是为一家已不复存在（或已发生根本性变化）的公司设计的。

我曾目睹一家物流公司发现，由于供应商更改了一个API字段名称，一个自动化的异常处理流程竟在悄无声息中错误运行了整整十一个月。解决办法是什么？有人一直在未告知任何人的情况下手动重新录入这些失败的案例，以为这只是个别情况。这并非工具层面的失误，而是组织层面的失职——大家原本都认为系统运行稳定，却未能重新审视它。

医院面临同样的风险，但 stakes 却高得多

将同样的模式套用到医院的临床和行政系统中，容错空间便会急剧缩小。医院软件开发通常将合规性和系统可用性置于适应性之上——这可以理解，毕竟一次部署失败可能导致护士在凌晨2点无法调取用药记录。但这种谨慎也意味着，老旧系统往往在生产环境中运行的时间远超应有期限，人们只是对其进行修补而非重建，因为没人愿意成为那个破坏关键系统的“罪魁祸首”。

其结果是，系统架构中积累了无人记得曾做出的决策。某个排班模块通过2016年为某供应商构建的集成接口与计费系统通信，而该医院早在2019年就已停止使用该供应商的服务。它目前“基本”还能正常运行。“基本”绝不是你希望出现在患者数据旁的一个词。

正在缓慢发生变化的是，人们逐渐认识到：医疗保健IT领域的韧性并非在于规避变化——而在于构建足够灵活的系统，使其能够从容应对变化，而无需在每次法规调整或新增电子健康记录（EHR）模块时都依赖“小奇迹”。

为何“如果没坏就别修”是个错误的标准

这两种情况有一个共同点：系统并没有“坏”。它们完全按照配置正常运行。这正是为什么没人关注它们的原因。

按定义，出问题的系统会引起关注——有人投诉、系统停摆、工单被提交。而真正危险的系统，则是那些表面运行正常，却在悄无声息地偏离组织实际需求的东西。比如，一个仍能执行但将任务路由到错误部门的工作流自动化；又比如，一个仍能传输数据但删除了下游系统如今所依赖的某个字段的医院接口。

审计工作虽不光鲜，但替代方案也同样乏味

解决方案在概念上并不复杂，尽管实践中可能很繁琐：对所有无人值守运行的系统安排定期审查，无论其历史表现如何出色。询问当前由谁负责维护。询问自系统建成以来，上游和下游发生了哪些变化。询问如果明天它悄无声息地停止运行，是否有人会察觉。

大多数组织都会跳过这一步，因为这感觉更像是维护而非进步，而维护工作很少能获得预算或赞誉。但跳过这一步的代价并不会消失——它只是静静地等待着，直到应收账款部门有人发现账目对不上为止。