上一篇《医疗信息化5.0：AI赋能临床，让医生重新看见患者》中，我们一起探讨了AI大模型如何重塑诊疗流程，让医生逐渐从繁重的信息录入工作中解放出来，让医疗重新回归人与人的连接。

但如果仔细想一想，就会发现一个问题：

当临床业务被AI重新定义的时候，支撑这些业务运行的软件系统，还会保持原来的模样吗？

答案显然是否定的。

医生的工作方式变了，患者的服务方式变了，医院的管理方式变了，那么医疗软件的开发模式，也必然迎来一次彻底重构。

今天，我们把视线从台前转向幕后。

聊聊AI大模型如何改变医疗软件开发，以及传统HIS厂商即将面对的最大产业变局。

一、医疗软件，为什么一直这么难做？

在IT行业里，有一种共识：

医疗软件可能是世界上最复杂的软件之一。

一个大型三甲医院的HIS系统，往往包含：

• 数百万行代码

• 上千张数据库表

• 数万个业务规则

• 成千上万个接口

• 无数个个性化需求

更重要的是，医疗软件从来不是一个标准化产品。

同样是挂号流程，不同医院可能完全不同；

同样是病历管理，不同科室可能要求完全不同；

同样一项医保政策，在不同地区又会衍生出不同的落地规则。

过去三十年，医疗软件行业本质上是一种典型的“知识密集+劳动密集”产业。

一方面需要大量程序员完成编码、测试和交付；

另一方面又高度依赖对医疗业务规则、政策规范和医院管理逻辑的长期积累。

因此行业里一直存在一个有趣的现象：

很多时候，真正稀缺的不是架构师和程序员，而是既懂医疗业务又懂技术的交付经理。

而AI未来可能改变这种不正常的局面。

二、长期积累的“代码债”，已经走到必须偿还的时候

很多医院的信息系统，看起来每天都在正常运行。

但对于研发团队而言，它们更像是一座不断扩建的老城区。

每次政策变化，就新增一个模块；

每次评级检查，就增加一个接口；

每次客户提出特殊需求，就再打一层补丁。

久而久之，系统越来越重。

研发效率越来越低。

维护成本越来越高。

形成了医疗软件行业长期存在的三大难题。

第一座大山：无休止的个性化定制

中国几乎找不到两家业务流程完全一致的医院。

每一家医院都有自己的管理模式。

每一个科室都有自己的工作习惯。

于是大量厂商陷入了一个循环：

开发一个产品；

服务一家医院；

再改出一个版本；

最后变成“一家医院一个系统”。

研发资源被大量消耗在重复劳动中。

第二座大山：越来越沉重的历史包袱

很多医疗软件的核心架构诞生于十几年前甚至二十年前。

从单体架构到SOA，再到微服务；

从本地部署到云原生；

技术不断迭代。

但由于业务连续性要求极高，大部分系统根本不敢大规模重构。

于是形成了一个行业普遍现象：

新技术不断叠加在旧架构之上。

最终形成一张庞大而复杂的系统网络。

第三座大山：昂贵的人天成本

医疗软件研发长期依赖大量人工投入。

需求分析靠人；

代码开发靠人；

测试验证靠人；

实施上线靠人。

一个中大型功能开发周期往往需要数周甚至数月。

而随着医疗行业数字化需求不断增长，这种依赖人力堆积的发展模式正在触及天花板。

三、AI重构开发模式的“三次跃迁”

很多人认为AI写代码，就是Copilot帮程序员补全几行代码。

实际上，这只是变革的开始。

AI对医疗软件开发的影响，正在经历三个阶段。

第一阶段：AI程序员——让编码从手工作坊走向工业化

这是今天已经发生的现实。

越来越多医疗软件企业开始将AI引入研发流程。

接口开发。

SQL编写。

单元测试。

代码审查。

文档生成。

Bug定位。

这些过去需要工程师花费大量时间完成的工作，已经开始由AI辅助完成。

以前开发一个医保接口。

程序员需要阅读几十页规范文档。

设计字段映射关系。

编写数据校验逻辑。

处理各种异常场景。

现在AI能够快速生成初版代码和测试脚本。

开发周期从几天缩短到几个小时。

真正发生变化的并不是代码质量本身。

而是软件生产效率第一次出现数量级提升。

过去十个人完成的工作，未来可能只需要三个人。

第二阶段：AI架构师——从政策理解到需求设计

如果说第一阶段解决的是“怎么写”。

那么第二阶段解决的是“写什么”。

医疗行业最大的特点之一，就是政策驱动。

医保支付改革。

电子病历评级。

互联互通测评。

数据治理要求。

每一次政策变化，都会引发系统改造。

过去这个过程往往需要：

政策解读；

需求分析；

架构设计；

数据库调整；

接口规划。

整个过程可能持续数周。

而如今的大模型已经具备理解复杂业务规则的能力。

它可以快速完成：

政策摘要；

影响分析；

需求拆解；

方案设计；

接口草图生成。

虽然最终决策仍然需要架构师完成。

但AI已经开始承担“高级分析师”的角色。

未来的架构师，更多是在审核AI的设计结果，而不是从零开始设计系统。

第三阶段：软件开发正在走向“能力编排”

这或许才是真正颠覆性的变化。

很多人认为未来是“AI自动生成软件”。

但我认为更准确的描述是：

软件正在从开发走向编排。

传统软件开发模式：

需求 → 设计 → 编码 → 测试 → 上线

未来的软件开发模式：

需求 → AI理解 → 服务编排 → 自动部署

对于医院而言，未来大量需求不再需要重新开发。

而是由AI自动调用已有服务能力完成组合。

举个例子。

信息科提出一个需求：

“建立一个房颤患者术后30天随访管理流程。”

过去需要：

产品经理分析需求；

研发设计模块；

开发编写代码；

测试验证上线。

整个周期可能持续数周。

未来AI可能直接调用：

电子病历能力；

患者管理能力；

消息推送能力；

专病库能力；

质控预警能力。

自动完成业务流程编排。

换句话说：

软件正在从“代码产品”变成“能力平台”。

医院真正需要的，将不再是一套固定的软件，而是一套能够持续演化的数字能力体系。

四、真正被颠覆的，不是程序员，而是研发组织

很多人最关心的问题是：

AI会不会取代程序员？

我认为答案是：

不会。

但会重新定义程序员。

过去一个医疗软件项目团队可能是：

• 产品经理 5人

• 开发工程师 30人

• 测试工程师 15人

总计50人。

未来可能变成：

• 医疗业务架构师 10人

• AI工程师 5人

• 开发工程师 8人

• 测试工程师 3人

总计26人。

人数减少了。

但对能力的要求反而更高。

未来最值钱的人，不一定是代码写得最快的人。

而是最懂业务的人。

因为AI能够生成代码。

却无法替代对临床流程的理解。

无法替代对医院管理逻辑的理解。

更无法替代对医疗场景的深刻洞察。

未来医疗IT行业最核心的人才画像可能是：

懂医疗业务的人 + 懂AI的人。

五、HIS厂商真正的护城河是什么？

过去很多厂商认为：

源码是核心资产。

代码是竞争壁垒。

但AI时代正在重新定义价值。

代码生成的门槛越来越低。

技术实现的成本越来越低。

真正稀缺的，反而是那些沉淀了二十多年的人类知识。

比如：

临床路径知识库；

医保规则知识库；

医院管理最佳实践；

专病管理经验；

医疗数据治理模型。

未来最有价值的资产，不一定是代码仓库。

而是业务知识库。

AI时代，代码正在加速贬值。

知识正在快速升值。

真正危险的，不是拥有老代码。

而是没有完成知识资产化的组织。

IT私房话

经常有人讨论：

AI会不会取代程序员？

我觉得这个问题本身可能就问错了。

就像当年汽车取代马车时，被淘汰的并不是驾驶能力，而是落后的运输方式。

今天AI改变的，也不是程序员这个职业。

而是软件生产的方式。

回顾医疗信息化三四十年。

我们经历过单机时代。

局域网时代。

互联网时代。

云计算时代。

而今天，一个新的时代已经到来。

那就是AI原生时代。

在这个时代里：

代码不再是核心资产，知识才是；

开发速度不再是核心竞争力，业务理解才是；

软件不再是静态产品，而是持续进化的数字生命体。

对于传统HIS厂商而言，这未必是一次“恐龙时刻”。

但一定是一次重新定义自身价值的时刻。

那些把AI视为工具的人，正在提升效率；

那些把AI视为基础设施的人，正在重构产品；

而那些能够把医疗知识沉淀为AI能力的人，正在定义下一代医疗信息系统。

三十年前，我们用代码把医院搬进了计算机。

三十年后，AI可能让软件重新理解医院。

而这场变革，才刚刚开始。

今日互动：

各位研发同行、信息科专家，你们所在的团队是否已经开始使用AI辅助开发？目前最成功的应用场景是什么？

我们距离“自然语言构建医疗应用”的时代，还有多久？

欢迎在评论区留下你的观点。

下期预告：

软件开发模式正在被重构，而另一场更大的变革，也已经悄然发生。

当AI开始理解服务器日志、数据库告警和业务异常时，传统运维模式是否还会存在？

下一篇《运维篇》，我们一起聊聊：

《医疗信息化6.0：半夜告警响起时，接电话的为什么不能是AI？》

声明：部分内容及图片由AI辅助完成，请知悉。