不同规模的医疗机构如何选择合适的集成平台中间件（前篇）

选择集成平台中间件时应考虑什么 

随着国家对于医疗机构互联互通要求和医疗大数据应用的不断深入，建设集成平台来实现医疗系统的流程再造和数据治理已然成为很具实践价值的方式。 此时集成平台中的核心中间件（如ESB、集成引擎等）就非常重要了，因此怎么样选择适合自身情况和应用场景的集成技术和架构是医疗机构需要仔细考虑的。 

“知己”- 分析自身情况和需求 

机构规模 

医疗机构有二级、三级、集团医院、区域、医共体/医联体等，不同规模的机构涉及到的系统厂商也不一样，比如： 三级医院相对二级医院可能会涉及到更多的供应商和业务复杂度，区域、医共体考虑可能更多是跨机构协同等。 

机构承载的业务 

平台和数据集成中间件承载的业务涉及到很多方面，比如是核心业务还是非核心业务，是否有涉及到大数据方面的对接，是否需要对接Kafka、MQ、IOT等方面的应用，在国家互联互通标准化这块是否有需求，对实时性、并发性、可用性的要求如何，等等。 这些均需要考虑集成平台中间件（集成引擎）本身的功能和性能是否匹配和满足。 

集成平台的定位 

平台建设的定位对于选择集成平台中间件（集成引擎）也很重要，是仅解决评级所需的业务场景，还是希望搭载大部分或者全部经由集成平台核心中间件实现数据交换和集成的“真”集成业务。 

另外，医院对集成平台建设项目要需要有规划设计，如考虑适应机构短期目标（3到5年）还是长期的成长发展诉求。 选择集成平台中间件（集成引擎）的时候就要考虑如何匹配、解决这些问题，这也使医院在评估集成平台中间件（集成引擎）的可持续发展和升级路线上能有一个更明确的方向。 

“知彼”- 了解数据交换引擎具备的功能特性和性能 

场景覆盖度 

不同机构和业务对于集成平台中间件（集成引擎）的技术诉求也会不同，有时候我们需要从HIS发消息到LIS、PACS等实现顺序传输和保证消息送达，也会有从多个数据中心通过报告索引快速检索患者报告的场景，也可能有数据同步等诉求。 因此选择集成平台中间件（集成引擎）时，需要考虑其数据交换技术是否能覆盖足够广的业务场景，是用ESB、IE（集成引擎）还是用ETL、MQ等。 

易用性 

• 全流程中文支持： 产品不仅开发时就设计了全中文界面，还具有纯中文帮助文档、使用手册、视频教程和纯中文的售后技术支持服务 
• 易使用： 开箱即用的纯Web的开发、监控界面，会让开发运维人员更容易接入使用。 
• 易开发： 拖拽的图形化配置开发能提高效率，简单易用的在线实时开发让使用者对集成平台中间件（集成引擎）具有更强的自主可控性和对需求的敏捷响应。 
• 易运维： 快速安装和多维度的监控界面能够实时观察运行状态，对于每个数据流转和消息内容可精确定位和追踪。 

架构完整度和前瞻性 

一个产品的架构完整才能满足在不同机构场景的适应，同时也不用担心当机构业务成长，产品架构升级时所带来的风险。 集成平台建设不是一蹴而就，刚开始可能承载业务不多或者需求不高，采用冷、热备部署架构即可实现。 随着业务增长和机构角色所承担的能力增强，性能和容灾需求就需要产品过渡到集群化架构甚至是云原生架构，这时候就要求选择的集成平台中间件（集成引擎）能够满足这些诉求。 

稳定可靠性 

据统计，稳定可靠一向是集成平台支撑机构各业务运行和数据流转重要的诉求之一。 集成平台中间件（集成引擎）是否经受过各类项目历练和场景考验，并且有足够的自修复（Robustness）机制和避险机制，也是医疗机构需要考虑的。 不同机构和承载业务在容灾方面也是有不同选择的，如果对于非核心类实时度不高业务完全可以用冷备方式承载，涉及部分核心业务并且响应也要及时的时候，则可采用热备方式。 当数据交换的业务量和消息量达到一定规模时，比如大三甲或者集团化医院时，则选用原生设计实现的集群方式或云原生分布式集群架构会更可靠。 

兼容性 

协议和技术的兼容对接及可扩展会让开发人员进一步加快项目推进和规范化建设。 HL7 V2、V3、FHIR、DICOM等医疗协议，Kafka、ZooKeeper等分布式应用，Hadoop、MongoDB等大数据，ActiveMQ、RabbitMQ等消息队列，XMPP、MQTT等物联网协议，符合国家互联互通的CDA、数据集等标准组件...这些在规划平台建设时需要结合业务场景切实考虑。 另外一旦有遇到非常特殊的对接需求，集成平台中间件（集成引擎）是否具备这种扩展能力和服务支持也是机构需要留意的。 

高性能 

• 产品自身性能： 通过产品功能设计更好地提升单机性能，如内置的内存数据库、添加分布式缓存等设计，减少与外部I/O交互，提高数据获取速度。 
• 横向扩展： 集成平台中间件（集成引擎）也需要具备横向扩展能力，通过添加计算节点大幅提升性能以应对高并发环境下的海量数据处理需求。 

开放性和成熟度 

集成平台中间件（集成引擎）作为中间件不应是黑箱运行，需要保证数据的透明可追溯。 其自身的API和对消息记录存储的访问也要有高度开放性，能助力医院的技术人员快速上手使用，自主进行二次开发（如快速响应全国健康码），使医院真正接管平台，实现对集成平台中间件（集成引擎）的自主可控。 

同时选择时需要考虑产品成熟度，建议选择有大量成功落地应用案例或主流HIT厂商使用的集成平台中间件。 

本土化价值凸显 

除了以上几个基本要素外，本土化也非常重要，主要分为： 

本土标准的适应性 

面对国际上大量医疗数据交换协议，部分国外的特有标准和法案并不适合国内环境，需要更有针对性地选用在国内实用度高的协议标准和规范，如国家在互联互通中提出的CDA标准、数据集标准、交互服务标准以及编码集，国密算法SM3、SM4等，并在满足这些本土化标准要求的前提下，对于这些标准提供更细致，易用性更高的配套功能（如自带相关标准的数据映射），让集成平台中间件（集成引擎）的每一个功能都真正体现出其应用价值而非沦为“作秀”工具。 

另外随着国家对于国产化服务器和操作系统的推广和普及，集成平台中间件（集成引擎）应该要兼容适应这种趋势，比如对于Arm、Mips等CPU架构的支持，麒麟和UOS等操作系统的支持。 

对项目实施人员的本土化支持 

国内项目压力大，进度紧张，项目人员工作强度大，集成平台中间件（集成引擎）如果提供全程中文界面和学习技术材料，会大大降低项目人员的负担，将更多精力放在实现业务本身上。 

另外国内开发运维的水平高低不一，集成平台中间件（集成引擎）更应该兼具国内用户习惯和医疗场景复杂多变等特点，针对性的提供良好工具。 比如内嵌简单的测试工具，提供Dispatcher功能等。 

满足当下和未来的政策标准 

随着2020互联互通标准的出台，也逐步对微服务化架构，API 网关等提出了要求，集成平台中间件（集成引擎）是否具备上述标准中所需架构和功能，产品的成长发展是否紧跟国家政策甚至预先打好基础并做好准备，也需要机构更细致地考虑和关注。