医院信息集成平台：如何迈过能用、敢用、好用的“三重门”？

​导读 

集成引擎本身需采用集群式架构，否则相当于“打两层楼地基，永远建不起十层楼”。 
 

为消除信息孤岛、实现系统间的互联互通，进而支持跨机构的医疗信息共享和协同，建设医院信息集成平台是重要方式之一。 为避免“几年后推翻重建”，集成平台建设需要前瞻性的架构设计； 作为集成平台核心组件的集成引擎，更需“打好地基”，从全局高度规划架构，从而长期、稳定地支撑医院业务发展。 

在医疗机构互联互通领域具备丰富经验的Odin认为，要让医院信息集成平台真正发挥作用，需要迈过从“好看”到“能用”、从“能用”到“敢用”、从“敢用”到“好用”的“三重门”。 其中一个关键要素是，集成中间件（集成引擎）本身需采用兼具高性能和高可用的集群式架构，否则相当于“只打了两层楼的地基，将永远建不起十层楼”。 

Odin之所以“敢”下这一判断，源于其一直脚踏实地面向场景解决实际问题，同时坚持技术的持续领先。 

“能用”： 功能全，才能改变集成平台“建而不用” 

目前，部分医院的集成平台存在“建而不用”的问题，造成很大的资源浪费。 究其原因，Odin认为有三方面，一是集成平台的功能不全，二是性能不足，三是容灾能力不强。 

要让医院“能用起来”，首先要解决集成平台功能不全的问题，而作为“地基”的集成引擎功能是否完备是关键之一。 纵观行业，有的医院使用集成引擎实现基于HL7（Health Level Seven，指卫生信息用户层交换协议）消息的集成，但业务可扩展性有限； 有的使用ESB（Enterprise Service Bus，企业服务总线）实现服务协同，但缺乏对医疗标准的支持，实施结果不理想。 如果医院同时部署集成引擎和ESB，又面临ESB没有专门针对医疗行业开发相关功能、二次改造成本高企的问题。 

为此，Odin自2014年创立之初就树立了“集多种数据集成和交换技术于一体”的发展方向，创造性地将各种数据交换技术（ESB、ETL、API等）融合到集成引擎中，取长补短，解决实际环境中需求多样化场景问题，开启类似苹果手机（iPhone）将电话、音乐、拍照、上网等功能整合在一起的“功能集成”之路，率先推出集成引擎、ESB、ETL “三合一”引擎 ，继而嵌入更多功能，开发了Odin “多功能引擎” 。 

其次，为解决“数据标准化程度差”这一集成平台的建设挑战，Odin 内嵌了国家电子病历共享文档规范内的标准数据集、CDA（Clinical Document Architecture，临床文档结构）数据模型，提供生成和解析CDA文档的标准映射配置，使医院能够对互联互通有着深度理解和直接参与； 支持多样可扩展的协议和终端适配，如HL7 V2、HL7 V3、FHIR（Fast Health Interoperable Resources，快捷健康互操作资源）等； 同时，Odin内嵌大数据应用支撑功能，支持物联网应用层协议MQTT、XMPP等，节省医院在“5G+”时代的二次开发时间和成本。 有医院客户评价道： “Odin将标准数据集映射到CDA标准，使医院通过互联互通标准化成熟度测评的工作流程实现标准化，大幅降低了医院的实施成本。 ” 

在不断增强集成引擎功能的过程中，Odin的策略是面向应用场景，解决医院业务中哪怕是极为细微的痛点，即便这些问题本不属于集成引擎的“分内之事”。 比如，随着互联网医院、医共体的建设提速，医院需要面对影像类、媒体类文件的实时数据转换问题，Odin针对性地开发了大文件传输、DICOM转XML、PDF文件生成等功能，大大提升了区域协同业务的时效性。 

通过功能的持续“加持”，Odin引擎对医院不同业务场景的覆盖率越来越高，解决了医院集成引擎“好看却不能用”的问题。 有HIT公司在上线Odin引擎时，本来配备多个技术人员准备做二次改造，结果发现： “想改造的功能，引擎都已内嵌好了”。 

从“能用”到“敢用”，集群式引擎是答案 

解决了“能用”的问题，医院对集成平台还存在“不敢用”的顾虑，这主要是集成引擎的性能、容灾能力、统一管理不足所致。 

一方面，随着医院信息化建设步伐加快，医院信息系统、数据和对外接口的数量都在急剧增长，集成引擎的TPS（每秒钟处理完的事务次数）并发量需达到1000TPS以上，才能基本满足三甲医院的性能要求。 如果集成引擎采用单机架构，一般难以达到这个要求，即使达到了对系统的负载压力也很大，使得故障风险大大增加。 一旦出现故障，全院业务停摆少则十几分钟，多则几个小时，这是医院难以承受的。 

另一方面，一些医院为通过互联互通测评而建的集成引擎，因标准不一等原因无法适用于实际业务，另建引擎不但增加成本，且两套引擎无法统一运维、管理。 所以曾有业内人士评论： “不上（集成）平台是等死，上了（集成）平台是找死”； 还有的称，“运维成本是集成平台不可承受之重”。 

如何解决高可用和容灾问题，让集成平台从“能用”变为医院“敢用”？ Odin认为，关键在于应将集成引擎由单机运行升级为集群架构。 

Odin新一代多功能一体化集群式架构引擎 

为此，Odin投入大量资金和时间精力进行研发，先后攻克了解决了集群架构中“顺序型集成业务独立性问题，高通量出现异常时做到无感知切换，多服务器下能够统一的运维、监控、管理等”诸多技术难点。 最终，Odin“新一代多功能一体化集群式架构引擎”应运而生，其具备以下特点： 

面向医疗： 内嵌医疗行业标准，其中包括HL7 V2、HL7 V3、FHIR及国内互联互通CDA、数据集等标准组件。

 多功能： 具备ESB、ETL、IE、APIs等多种数据交换技术，实现医疗业务全场景覆盖。 

一体化： 自主可控、开箱即用。 也即： 界面一体化，包括统一的开发、测试、管理、运维和监控界面； 组件一体化，创新地将控制组件、运行组件、API网关、用户鉴权等融为一体。 

集群式架构： 具备自修复机制、定向隔离负载、精细化故障转移等。 

还有一个问题，如果使用“双活”或“多活”模式，是否也能达到集群式引擎的容灾能力？ 

Odin认为，“双活”或“多活”模式是在独立安装多台单机后，通过负载均衡器进行转发，本质上仍属单机版引擎，在容灾策略的精细度、覆盖度，负载能力的资源利用度、性能承载度等方面，无法与集群式引擎相提并论，难以满足医院的实际生产需求。 

而采用新一代集群式架构后，医院在构建业务的“高楼大厦”时再也不用为地基的“稳固性”担忧，这样才能让集成平台真正从“能用”走向“敢用”。 

解决易用性，让集成平台从“敢用”到“好用” 

当前，三甲医院面临着互联互通、电子病历、智慧医院等评级要求，信息化建设的任务日益加重。 面对大量的碎片化集成需求，如果医院仍然采用传统“打补丁”的方式，不仅效率低，还会增加运维成本和安全风险。 

为解决医院在新时期信息化建设面临的新问题，Odin在与多家合作伙伴及相关用户交流沟通后，针对性地在“新一代多功能一体化集群式架构引擎”基础上，着力解决高性能、高可用等问题，引入了许多实用、易用的运维与管理功能，让医院不仅“能用、敢用”，并且也觉得“好用”。 比如： 

具备微服务化的API网关管理。 具有鉴权管理、流量控制、黑白名单、访问控制等API管理功能，聚合接口，降低客户端与后端的耦合度，无需二次开发就能实现API与集成服务的绑定。 

灵活的部署策略和精细化资源配置。 集成项目发布到生产服务器运行，可根据各集成业务的特点，选择性地部署到指定某个或某类服务器上，适合多院区集成平台建设。 如A院区的服务器性能更好，有相关需求的集成业务可部署到A院区，要求不高的放在B院区。 

纯Web的DevOps式规范化管理 ，实现在线开发、测试、管理、生产、运维一体化。 对于有着一定规模的医院信息化团队，存在多人同时上线进行集成平台功能拓展和二次开发等需求。 Odin引擎的集群架构在性能上能轻松支撑多人同时在线开发，并在功能上分离生产和开发环境，提供纯Web的开发界面和规范的DevOps流程管理。 

数据脱敏及安全要求。 Odin引擎中自带数据脱敏功能，无需二次开发，能在数据流转的过程中实时脱敏，并提供多个数据内容级加密保护相关组件。 

另外，还有更多“好用”功能，其中包括： 态势感知、风险监控、服务熔断、事件驱动、自定义仪表盘等。 

Odin引擎集群版界面 

Odin的“新一代多功能一体化集群式架构引擎”非常适用于三甲医院与区域全民信息化平台的实际需求，其高可用性已在 浙江省台州医院 （台州恩泽医疗集团）得到验证。 在台州医院的集成平台上，已运行了400多个集成业务及1000多个交互终端，并且遇到过服务器出现故障后，前端业务依然能平滑无感知运行的情况，更好地证实了集群架构在实际生产中的价值。 

面向未来的集成平台应该是什么样的？ 

云计算和机构上云在医疗行业的落地已呈现不可逆的趋势。 从技术发展潮流来看，以“容器+K8s（全称kubernetes，为容器服务而生的可移植容器的编排管理工具）”为代表的新型技术基础设施，将连接异构算力，实现云端一体化。 

在上云过程中随之而来的，是强调资源的精准利用、原子级集成业务的隔离、端与端之间的及时协同、集成能力的按需租赁等。 面对这些纷至沓来的“上云基本功”，医疗机构又当如何应对？ 

Odin认为，采用分布式云原生架构的集成引擎，将成为集成平台的“准终局”形态，为云上实现大规模数据交互和集成业务，提供“极致”保障，Odin已为未来的云原生时代做好了技术准备。 2019年年中，专门针对超大规模数据中心和大型云化应用需求场景设计的 Odin NeXT   (New generation eXchange Technology) 分布式云原生平台正式面世。 

2021年5月，“全球首个基础医疗数据互操作平台”—— ALEX （Application Layer EXchange），在新西兰全国范围正式上线使用，覆盖新西兰90%的基础医疗数据。 Odin NeXT作为其核心数据交换中间件搭载在微软的Azure云环境中，为ALEX平台提供大规模实时计算的高并发、低延迟、强稳定和端到端的集成扩展能力。 

从“三合一”到多功能，再到新一代集群架构引擎，以及面向未来的Odin NeXT，Odin引擎让集成平台从“建得好看”变为“医院能用、敢用、好用”，帮助医院打好集成业务的稳固“地基”，这正是国内多家HIT上市公司和300多家医疗卫生机构选择Odin引擎的原因。