【应华永专栏】医院信息化自主可控的尝试：甲乙双方“平行开发”

来源：HIT专家网     作者：应华永

医院信息系统是选择自主研发还是向第三方采购？这是一个老生常谈又很难有标准答案的问题。对绝大多数医院来说，向第三方采购产品和服务显然是默认的选择。但对那些熟悉诊疗业务流程且具备一定软件开发能力的信息团队来说，要不要走自主研发之路？

把握医院核心业务系统的主导权

面对临床、管理和上级主管部门雪片般的需求和任务，面对信息技术快速的更新迭代，能否实现团队的技术更迭和产品升级？未来的信息化建设还要不要主导？能不能主导？如何主导？以及主导什么？这些问题在HIT专家网举办的一次HIT热点趋势研讨会上有过较激烈讨论。

当时，中国医院协会信息专委会王才有主任说过：“讨论医院信息化建设的‘主导’问题，实质是讨论‘方向’问题。吾辈作为躬身入局者，不但要关注实践中的问题，也要抬头看路。HIT是复杂的信息系统，这个系统的建设由谁说了算，不仅要看项目自身复杂程度，还要看当前医院所处的信息化发展阶段，更要看信息化对业务运行的相互影响作用，具体情况具体分析。如果方向错了，战术再努力也是徒劳。”

讨论医院信息系统是选择自主研发还是外购，这其实是个伪命题。因为在当今环境，没有哪家医院的信息中心能做到全院各种业务系统的自给自足。所以在此我们仅讨论医院核心业务系统的主导问题。

那么医院核心业务系统又该如何定义？笔者暂且将需要信息中心敏捷响应的、业务覆盖面广的、自主可控后能明显提升医院和其他软件公司谈判话语权的系统，定义为医院核心业务系统。按照这一定义，对应的主要就是HIS、EMR和集成平台：掌握了HIS和EMR系统研发的主导权，就意味着能更敏捷地响应业务需求和管理需求；掌握了集成平台的主导权，就意味着任何时候都可以独立承接和第三方软件的对接工作，能更好地把握项目进度并享受到更多的商务谈判红利。

笔者带领过两种类型的信息团队，和大家分享下个人心得：对于已经具备核心业务系统研发基础的团队，如果能够培养自己的人才梯队并实现技术转型，在上一代产品的基础上重新打造一套能适应未来医院或医疗集团发展的核心业务系统，显然是最丝滑、最理想的平稳迭代方式。但对于技术力量储备不足或技术转型比较困难的信息团队，即使没有能力自主研发，也要尽可能争取对医院核心业务系统具备一定的主导权或可控性。

“平行开发”是实现主导的一条可行之路

最近笔者所在医院（以下简称甲方）就和我院一体化电子病历和集成平台开发商（以下简称乙方）在基于平等、自愿、互利、共赢原则的基础上，达成了“源码共享、平行开发”的协作模式。

所谓“平行开发”，其实就是将甲方的工程师纳入乙方的产品研发团队统一培训，共同管理。大体流程是甲方发挥自己熟悉临床业务的优势，整理并提交需求文档和产品解决方案给乙方评估；在乙方给出可行性意见、所需工作量和预计完成时间后，甲方再根据自己技术团队的工作饱和度和需求紧迫度，评估该需求任务是由自己承接开发还是交由乙方开发。

现以笔者所在医院信息团队主导完成的“医保合规性智能审核插件”改造过程为例，希望能给医院信息同行们提供参考。

1.收集业务需求。随着医改的深化和医保大数据分析能力的提升，医院每年都会因为日常管理不到位导致非恶意违规收费发生，从而面临医保飞检审计风险。鉴于此，集团医疗管理部希望能够通过信息化手段将违规风险警示前移，减少或阻断违规收费的发生。

2.明确需求依据。浙江省医保局于2022年7月下发的《浙江规则清单及知识明细（20220704）》文件，对非基本医疗保险目录、限就医方式、限定儿童、限医院级别类型、限定性别诊疗、限性别用药、中药饮片审核、重复收费、项目与项目匹配等九大医保管控逻辑进行了详细解读。这份文件也就成为了我们管控的金标准和规则依据。

3.设计产品模型。将医保限定规则翻译为工程师更容易理解的语言，也即“限制类”、“重复类”和“约束性”三大管控规则，并针对这些管控方式设计出通用版的“医保合规性智能审核插件”。

4.甲乙双方沟通。甲方提交产品需求后，乙方评估后给出的响应周期和商务报价是甲方难以接受的。于是，甲方决定自己开发产品，明确需要授权改造的业务模块（包括门诊医生工作站、住院医生工作站、住院护士工作站、申请单模块、手术室收费模块等），并取得乙方HIS源码修改的授权。

5.系统自主研发。

（1）医保合规性智能审核插件开发：要求规则可维护可配置，能根据HIS提供的医嘱或收费数据作出合规性判断，并给出提醒、警告或禁止的规则明细建议，同时保存所有拦截日志，便于运行一段时间后的成果分析；

（2）HIS 拦截模块的开发：在相关业务模块的拦截点调用“医保合规性智能审核插件”，将相关业务数据（处方、医嘱、收费项等）传参给插件，然后根据插件返回的计算结果决定后续业务逻辑的处理（阻断或警告）。

6.代码合并。由于在平行开发期间，甲乙双方都对之前交付的源码进行了改动，所以甲方开发完成后，必须将修改过的源码做好标识，并发给乙方指定的源码管理者进行统一的代码合并和质控。

7.发版、测试、上线。这个过程保留乙方原流程不变。

总结

甲乙双方“平行开发”协作模式的本质是甲方“站在巨人的肩膀上跳舞”，通过培养自己的开发工程师团队来规避乙方本地化服务力量不足的风险，用最低的人力成本保证核心业务系统一定程度的自主可控；同时，因为甲方版本和乙方版本始终保持一致，不影响未来乙方对甲方产品的迭代升级。

对于乙方来说，有限的开发资源确实也很难覆盖或顾及客户的所有需求。培养甲方拥有一定的自主开发权，相当于将工程师资源由原来的集中存储变成了分布式存储，让更多的客户成为产品生态的一部分，共同打磨用户满意的产品，从而实现双赢。

“医保合规性智能审核系统”的顺利上线并取得良好效果，标志着这种“平行开发”的协作模式是切实可行的。但需要注意的是，甲乙双方要充分沟通和相互信任，同时系统框架必须能支持模块化和插件式开发。我们期待未来能有更多的HIT厂商愿意用做生态的格局做产品。

【责任编辑：秦勉】