夜雨聆风
之前写过一篇文章，讲“软件公司是如何被拖死的”，大家有兴趣可以去找来看看。
今天讲一下，如果软件公司真的被拖死了，消失了，医院应该怎么办？
先讲一个荒诞又真实的故事。
二十年前，我还在一家小医院，病人不多，业务不饱和，医院也刚开始信息化，弄了一个简易机房，布设了网络，购买了服务器，电脑和his软件。
当时的his很原始，只有门诊挂号和收费，住院（仅限出入院和计费收费），药房，药库，以及财务统计功能。严格来说只是一个记账收费系统。
软件公司努力了很久，花了一年多的时间，也没有完全替代手工记账，结果手工一套账，电脑一套账，还要两套账相互核对，工作量直接triple，工作人员怨声载道，正式上线完全脱离手工记账的时间一拖再拖，遥遥无期。
软件工程师和医院财务收费人员之间又鸡同鸭讲，彼此不懂对方的诉求。
软件公司本来就经营困难，尾款收不到，一拖再拖就干脆跑路了。
没有交接，没有维护，没有升级，尾款没有收，甚至连源代码都不要了，直接走了。
软件公司消失了，系统却还在。
医院每天还要接诊，医生每天还要工作，患者每天还要看病，系统不能停。
不知道是否有什么隐情，院里没有理直气壮的维权，没有追究软件公司的责任，只能自己接手。
那个时代，要想重新聘用一个工程师来接替还是很贵的，于是院领导的主意打到了我的身上。
我当时还是一名年轻的小医生，也是全院唯一一个既有医学文凭又有计算机文凭的人。严格来说，应该是全院唯一一个有计算机文凭的人。
于是我被迫半脱产出来，土法上马，抱着试一试的态度来死马当活马医。
幸好软件公司的开发语言是DELPHI，是我平时用习惯的，幸好软件公司把数据库的账号密码直接明文写在程序代码里面，我能直接查看数据库结构，猜测表单和字段的意义。幸好软件公司的代码质量还不错，注释比较清楚。还幸好原来的软件功能简单，代码只有一万多行。
我接手后摸索着熟悉代码，熟悉数据库结构，找到导致数据不准确的多处bug，试着修改，重写。三个月后完全取消了手工账，正式上线。一年后因医保升级重写了医保接口。后来又把数据库从SQL Server迁到了Oracle，并在随后的六年内升级了两个系统大版本。
在那个畸形的年代，我这个外行，半罐水，既维护代码，增加新功能，还要做数据库迁徙优化以及数据库的定时备份计划，本地备份和远程备份（远程备份到另一栋楼），还要拆修电脑，更换交换机，手工打网线头。
直到这个小医院被合并到了大医院，这个系统才完全被替换，我也才完全回到我的本职工作。
现在回过头来看，那段经历，更像是一个时代留下来的特殊产物，是荒诞的现实主义。
因为那个时候，医院还是一个小医院，业务量没有今天这么大，系统没有今天这么复杂。
一个外行花几年时间，还能勉强把系统维护下来。
如果放到今天，我认为几乎已经不可能了。
今天的软件，已经不是二十年前的软件
十几年前，一个手麻系统，可能只有几个模块，几个接口，几万条数据。
今天呢？一个手麻系统。
需要连接：HIS，电子病历，LIS，PACS，护理系统，医保平台，集成平台，中央监护，麻醉机，监护仪，输注泵，AI平台，科研平台，电子病历评级，互联互通评级，医保监管……
几十上百个接口或视图，几十万行代码，几千万条数据。
它已经不是一个软件，而是医院整个信息生态的一部分。
这样的系统，已经不是一个人，甚至几个工程师，能够长期维护的。
类似的事情反复在发生，我们又遇到了类似的问题
前年，医院更换了新的手麻系统。
本来最开始是想升级原来公司的新版本，无奈价格贵不说，新版本还不兼容旧版本，旧版本的数据还无法迁移过来。
自己公司的新软件版本，不兼容旧版本，还不能迁移旧版本数据，想想也是醉了。
于是，只有彻底换新公司了。
旧系统终于可以退休了吗？答案是否定的。
直到今天，旧系统依然运行在一台老服务器上，平时几乎不用，只有需要查询历史麻醉记录的时候，大家才会登录进去。
为什么？因为数据迁不过来，原因很现实：
第一，当年签合同的时候，没有数据迁移条款。
第二，旧公司不愿意配合。
第三，新公司也不愿意投入。毕竟，低价中标，数据库结构不了解，开发迁移工作量巨大，没有人愿意为这部分工作买单。
于是，医院只能保留一台旧服务器。
它静静地放在那里，保存着历史数据。
也保存着医院这些年留下来的技术债。
我所在医院，这样的服务器还有很多：旧his，旧手麻，旧急诊系统，旧重症系统，林林总总十多台……
我相信，这样的服务器，很多医院都有。
它们没有退休，不是因为舍不得。
而是因为没人能真正把它们送走。
软件公司为什么越来越累？
很多人觉得，软件公司医院越多，赚钱越多。
实际上，很多医疗软件公司，恰恰相反。
医院越多，压力越大。
为什么？
因为很多产品，并没有真正的平台化，没有统一版本，没有统一架构，没有统一接口。
而是：一个医院，一个版本，一个需求，一套代码。
新医院上线，重新开发接口，重新部署，重新测试，重新修改。
医院上线以后，新的需求又开始不断增加。
今天改一个打印格式，明天增加一个统计，后天修改一个流程，每一个需求，都进入主程序。
几年以后，代码越来越复杂，版本越来越分裂。
很多大型医院，甚至需要长期驻院工程师。
几个工程师，常年驻扎在一家医院，维护这一套系统。
医院越来越多，维护人员越来越多，公司的固定成本越来越高。
更现实的是，现在很多医院采购，仍然以低价中标为主，新项目利润越来越低。
甚至，新签一家医院，赚的钱，还不够驻院维护工程师的工资，只能寄希望能开发二期工程来续命。
于是，软件公司越来越累，产品越来越难升级。
最终，不是停止更新，就是推倒重来。
而很多老医院，永远停留在老版本。
真正被困住的是医院
很多人认为，软件公司倒闭，最大的损失是软件公司。
其实不是，真正被困住的是医院。
因为医院的数据，几十年的病历，十几年的麻醉记录，十几年的监护数据，都在这个系统里面。
系统可以换，数据怎么办？
很多医院换系统的时候，真正困难的，不是安装新系统，而是迁移旧数据。
没有数据库文档，没有接口说明，没有字段解释，没有人愿意投入。
最后，最简单的方法就是：
旧系统继续保留，新系统重新开始。
于是，医院里同时运行着几个时代。
一个负责今天，一个负责昨天，一个负责前天。
这样的现象，其实一点也不少见。
这些问题，国外同样遇到过，比我们先遇到，所以他们有更好的解决方案。
所以，很多关键软件采购合同，从签订第一天开始。
就已经考虑：如果供应商停止服务怎么办？如果公司破产怎么办？如果产品终止维护怎么办？
合同里通常会明确：源代码托管，数据库结构，部署文档，接口文档，数据导出格式，退出机制，数据迁移权利。
这些内容，目的只有一个。
医院采购的，不是某一家公司的未来，而是医院自己的未来。
医院真正应该采购什么？
医院采购软件，采购的不应该只是功能。
更应该采购：持续升级能力，平台化架构，统一版本，开放接口，标准数据结构，数据迁移能力，退出机制，源代码托管。
以及，未来十年的持续演进能力。
因为系统真正上线那一天，不是结束，而是开始。
未来十年。
国家政策会变，医保政策会变，评级标准会变，AI技术会变，医院业务也会不断变化。
一个停止进化的软件，迟早会成为医院新的负担。
写在最后
十几年前，我曾经花了六年时间。
维护过一套已经失去开发者的软件。
今天回头看，那段经历让我明白了一件事：
医院真正需要的，从来不是依赖某一家软件公司，而是建立一套能够持续演进的软件体系。
软件可以更换，公司可以更替，技术可以更新，但医院几十年积累下来的数据，永远属于医院，也必须能够随着医院一起成长。
未来。
医院最大的风险，或许不是软件公司倒闭，而是医院的数据，随着软件公司一起被困住。
真正应该属于医院的，不是某一个软件，而是数据。
不是某一家公司的产品，而是医院自己的数字资产。
也许，这才是医院信息化建设最应该守住的底线。
知而后行，行而求知。
从手术室到机房，从临床到系统。
记录一名麻醉医生关于医疗AI、医院信息化与持续成长的探索。
—— 医路智行录