黄明清：掌握“品性”，用好平台

​如今建设集成平台逐渐成为医院实现信息整合、数据共享乃至各异构系统信息的无缝衔接的主要方法之一，本文分享了笔者在长治医学院附属和平医院近年来医院集成平台的建设历程和体悟，供各位业内同仁参考。 

平台建设的历程 

长治医学院附属和平医院成立于1946年7月1日，是一所具有悠久历史和光荣革命传统的红色医院，也是山西省1995年首批通过评审的综合性三级甲等医院。 

1.2015年： 伊始，初探 

2015年以前，我院HIS系统（包括收费、住院登记、护理站、药房、药库等）的开发和维护，很多系统接口以及数据上报等工作，都是由医院自己负责。 但是此类点对点的系统对接方式存在大量、重复的接口工作，而且是网状交互，出现一个问题涉及到交互双方，也难以追溯问题的源头。 同年，医院的CIS升级，PACS系统上线，我院改变了传统的点对点接口的方式，自行采用C#开发了一套简单的接口集成平台，新上线的业务接口采用星型方式、服务拆分、抽象接口的方式进行集成，并收到了良好成效。 与此同时，我院在做预约挂号业务时接触到了第三方厂商使用的开源ETL工具Kettle。 同年，由于全国互联互通的数据集成上报，发现上级要求提供从2003年到2010这些年的数据，无论哪个系统，一提数据就几乎是死机状态，因为每个数据都是几十个G的业务量，而通过excel、access等进行少量数据复制、粘贴的方式，数据量大了根本不可行。 于是我们决定开始通过Kettle进行数据的抽取与上报，收到了良好的效果，效率和开发的便捷性都得到了很大的提升。 

2.2018年： 双平台，规范化 

随着系统越来越多，接口集成越来越复杂，工作量也越来越大。 同时各种评测要求以及业务扩展方面的需求也纷至沓来。 2018年以后，我院开始用Kettle尝试做业务集成，主要方式是将业务事件采用事件表的方式进行拆分规范化，然后对业务事件的处理抽象化为对一个个事件数据流的处理，并将接口方式统一化为简单的表读写及存储过程的调用，极大简化和降低了接口对接工作及成本。 但是此模式也存在很多弊端，如稳定性不够，问题排查比较难，尤其在监控跟踪这块，日志追溯欠缺很多。 于是在2019年我院引入了集成平台，明确了业务集成（采用Odin引擎）和数据集成（采用Kettle工具）的双平台概念，即逻辑上两套平台，实际上是一套平台。 

3.2019年： 全院，互联互通 

2019年，以全院HIS系统切换为契机，我们也开始将业务集成服务逐步迁移到集成平台上。 随着对平台的熟悉，逐渐发现这种架构和工具的优势，不仅功能很友好，并且稳定性要比Kettle好多了。 于是在2020年开始对医院全部业务进行迁移，开启了我院真正的ESB之旅，并且按照互联互通标准进行标准化改造。 

截至目前，集成平台已经稳定运行了700多天，证明了平台能在高强度、高负载、业务多、数据量大的系统处理需求下保证高可用。 平台接入了69个项目，534个终端，日消息量方面，接收量是26万条，发送量是45万条。 历史总接收量是8232万，历史发送消息总数1.3亿条。 

4.2022年—未来： 深化，扩展 

未来随着医联体、医共体建设的推进和业务、系统的不断增加，对平台的性能和稳定性等方面也将有更高要求，我院计划： 在功能方面对集成平台进行更深入的挖掘（例如统一界面的多人协同开发、尝试通过容器技术实现业务的微服务化）； 在架构方面根据集成平台的核心中间件在产品设计时已经预设的升级路径，在需要时平滑快速地将集成平台升级为集群架构，甚至是性能更强的云原生平台，为今后医院业务的大规模扩展夯实基础。 

集成平台建设中的体会和感悟 

1.医院层面 

（1）放得下——分清角色 

由于我院地处山西，相比沿海或发达城市信息化人才资源比较少，想实现完全自研开发人手不足，且成本较高。 因此需要转变观念、分清角色，专业的事需要由专业的人来做。 医院则是做好监管工作，在日常运维中使用简单、学习比较容易的集成平台产品功能满足业务场景需求，提升工作效率。 

（2）拿得起——提高自主权 

集成平台不能为了评级过级而建，而是为了医院的业务集成标准化规范化建真正集成“平台”，借助该平台来促进医院的信息化建设。 专业的事应该由专业的人来做，该放手的放手，该抓住的也要抓住，对于医院的业务来说，整个“医疗业务流程设计规划”这个专业的事情就要由医院信息部门（专业的人）来做，医院信息部门要有主导和掌控能力。 集成平台仅仅只是“工具”，医院要了解这个工具适合做什么，了解到、了解透，平台工具用在何处，怎样使用，怎样发挥工具的最大效率这是医院的信息化部门所深思熟虑的，这样在信息化建设过程中才能避免无论大小事都要找厂商、被厂商牵着鼻子走，真正建好符合地域背景、医院背景的“集成平台”。 

（3）两手抓——理论实践相结合 

医院需要有自己思想、熟悉工具，将理论和实践联系起来，比如： 日常运维中曾经遇到体检系统影像结果回传不了，以前每次定位问题查询要花10多分钟，借助集成平台核心引擎内置的功能自主开发做个小工具解决，不仅开发过程（开发测试1个小时）很快很方便，效果也非常好，做出来后提供查询服务让用户自己查。 可见集成引擎产品提供的不仅是基本的集成平台能力，还是一个强有力的工具，还有着更多能力及应用场景待医院日常发掘。 

（4）多思考——先思而后行 

无论大小项目，前期一定要先规划好设计好再开始动手，掌握好经典的二八原则，前期考虑的越完善，后期节约的时间越多。 

（5）慎选型——选对合适的工具很重要 

工欲善其事必先利其器，用合适的工具在信息化建设过程中可以起到事半功倍的效果。 在医院平台建设过程中，我们将集成分离成业务集成和数据集成两部分，针对业务集成重点考虑的是集成的及时准确可追溯，针对数据集成重点考虑的则是数据的量级及传输效率，针对不同的两个应用场景，我们分别用了Odin引擎（业务）和Kettle（数据）两种不同的集成工具和方式，并收到了良好的成效，将来也计划让平台的核心引擎承担更多集成业务。 

（5）勿拖延——核心遗留问题“今日事今日毕” 

项目初期时需要尽可能减少核心遗留问题，而非拖到日后再进行优化，因为一旦上线再改造成本很高，带来的业务中断风险也大，“日后优化”就会慢慢变成“不优化”。 因此核心问题尽量在事前进行解决，做到“今日事今日毕”。 

2.产品层面 

（1）简单易用的工具 

集成产品作为工具应该能非常简单的上手使用，例如我院的集成平台能支持各种终端或者路由，有很多封装好的工具，可以很方便地去做这种数据库终端、WEB服务终端、HTTP终端等，还能通过傻瓜式的界面拖拽方式实现开发和运维，快速便捷，不仅能帮助医院解决人手问题，还提升了开发效率、缩短开发周期等。 还是专业的事情交给专业的工具去做，在对第三方的接口开发适配效率成本等方面，集成引擎给我们带来了质的飞跃。 

（2）完备的基础功能 

集成平台的基础功能也必不可少，例如在标准对接上，符合HL7、互联互通等标准格式，相当于通过核心引擎在集成平台上把这些标准一层一层加上了，对于其他第三方的系统是完全不知情且无感知的，但最终在集成平台上的标准就越来越先进、越来越标准化了。 用户使用的过程中越简单有效，其背后的设计及技术支撑越复杂。 

（3）前瞻的集成架构 

好的软件公司能够有一定前瞻性，不仅能让医院在当下用好平台，更应该有前瞻性，能让医院在未来也能用好平台，例如集成消息引擎，解决消息的重复消费； 实现对最新国际数据互操作标准FHIR的支持等； 架构上也要有非常明确的升级路线图，可以保护基础投资，不用通过打补丁的方式进行平台性能和稳定性等方面的升级。 实现医院信息化集成的可持续的快速发展，为医院信息化建设提供有力的支持，提升信息部门的公信力。 

结语 

想要真正建设好集成平台，离不开医院和平台产品两方面的共同努力。 医院不仅需要了解平台“品性”，更需要在建设过程中不盲目跟风，清楚自身业务诉求，并且有自己的想法和思路。 产品方面也尽可能简单易用，在保证集成平台基本功能的基础上，最好有一定的前瞻性，为医院今后的发展打好“地基”。 

作者简介：黄明清，软件设计师，管理科学与工程硕士，长治医学院附属和平医院医学信息中心副主任