随着国家对医疗机构互联互通和医疗大数据应用要求的不断深入，搭建一体化平台，实现医疗系统流程再造和数据治理，成为具有实用价值的方法。这时，集成平台中的核心中间件（如ESB、集成引擎等）就非常重要了。因此，如何选择适合自身情况和应用场景的集成技术和架构，是医疗机构需要慎重考虑的问题。
不同规模医疗机构建设重点
在选择集成平台的中间件（如集成引擎、ESB）时，医疗机构要做到“知己”（即分析自身情况和需求）和“知敌”（即了解集成平台中间件的功能和特点），针对不同规模的医疗机构，它们的建设重点是什么？
1.二级医院
1.1知己：二级医院搭建一体化平台兼顾需求和成本
1.1.1 医院规模
二级医院一体化平台建设人员少，甚至可能出现整个信息科只有一名员工的情况，可以分配到医院信息化的物资建设资金也有限。统计显示，北京三级医院实际床位数3.是二级医院的24倍，但医疗信息化投入是二级医院的7.59倍。政府财政资金5.是二级医院的53倍。可以看出，除了规模因素外，三级医院信息化建设的资金配置和投入意愿仍高于二级医院。
1.1.2轴承业务
承载的业务量比较小，整体构建复杂度也较低，但仍需要通过各种数据交换技术实现基础业务场景（如医院门诊挂号、内网服务分发、数据提取和上报等）通过平台等），需要在有限的人力财力下保证日常业务的正常运行。
1.1.3 综合平台定位
由于大多数二级医院都有升级为三级医院的愿望，现有的系统和设备也会不断更新和完善。但是，整合平台的建设并没有系统的规划，更多的时候只是解决电子病历和互联互通评级所需的场景。后续集成建设缺乏连续性，难以快速实现对新业务系统的接口和协议支持。
因此，结论是：钱不够，人不够，规划不够
1.2知敌：2 一级医院重点从以下几点认识集成平台中间件
1.2.1 IE（集成引擎）、ESB、ETL、API“一体化”考虑成本和业务需求
二级医院要兼顾成本和业务场景需求，Odin引擎集成了IE（集成引擎）、ESB、ETL、APIs等多种数据交换技术的集成平台中间件。医院做到了无需购买多套产品即可满足现场需求，维护更简单方便，缓解“钱不够”的问题。
1.2.2 稳定性和易用性
二级医院缺乏专业的信息化人才，因此产品的稳定性和易用性也更为关键。
Odin引擎针对二级医院的需求，提供AO热备、双活等高可用容灾方案，保障各系统正常运行。同时，Odin拥有纯Web界面、图形化拖拽操作、全面详细的消息跟踪视图等易用性功能，可帮助运维人员快速上手、快速定位、解决错误，大大降低人手短缺对日常业务运营的影响。 ，以缓解“人不够”的问题。
1.2.3 易于扩展和开发
由于部分二级医院缺乏长远规划，很可能没有提前考虑设备系统的完善。这就需要集成平台随着系统设备的更新而扩展，为未来的二次开发或升级留有空间。
Odin引擎提供对包括HL7 v2/v3、FHIR、DICOM等在内的多种协议的支持，同时引擎还提供准开发平台。保障新服务的快速接入（如疫情期间“健康码”应用的快速上线），缓解“规划不足”问题。
2.三级医院
2.1知己：三甲医院业务建设需求更全面
2.1.1 医院规模
三级医院信息科人员较多，科室系统设备更齐全；相应的床位数和日门诊量也有所增加，能力和投入更多人力财力的意愿在整合平台建设上是现阶段整合平台建设的主力军。
2.1.2轴承业务
三级医院子系统较多，集成平台一般需要连接数百个服务点和数十个集成业务流程，接入服务点需要随着需求的变化而增加。因此，需要更多的个性化改造和定制服务，开放更多的功能。
2.1.3 集成平台定位
集成平台定位基本明确，除了最基本的通过IE（集成引擎）、ESB、ETL实现的各种复杂医疗业务场景，集成多源异构数据，还需要规范数据处理和二次应用，并根据医院情况和外部环境提出其他新的信息整合要求，如：
以高水平互联互通和电子病历评级为目标，更多系统可以通过平台交换和整合数据，实现海量信息共享（各类标准支持和满足评级要求的配套功能）；
集成平台中间件不允许计划外停机（更严格的灾难恢复解决方案）；
进一步推广互联网医院（打通线上线下业务数据）；
希望在现有系统和设备中合理利用大数据、物联网等新技术（新技术支持）；
...
2.2 知敌：集成 平台如何实现对新集成需求的更全面支持
2.2.1 协议标准的本地化及其支持功能
一些国外的具体标准和法案不适合国内环境，国内医院花很多钱，但这些标准根本用不上。而互联需求中的CDA标准、数据集标准等国内通用标准，由于缺乏配套功能（如数据映射），需要医院进行二次开发。
Odin 进行了大量本地化开发，具有国内通用但国际知名品牌不具备的功能和易用性，包括内置CDA、数据集等符合国家标准的标准组件互联互通ibms集成平台是啥，内置各种标准化定义、数据处理和转换工具、PDF导出等组件，兼容国内服务器和操作系统。
2.2.2 专注集群解决方案
Odin提供的集群解决方案是指在产品设计时根据医院平台业务特点原生实现的集群架构，而不是单机系统部署在多个虚拟机上形成的“集群”（其核心仍然是单机架构）。
它具有以下特点：
二级自动容灾迁移确保高可用
当模块发生异常时，原生实现的集群可以自动检测到异常并自动在其他服务器（节点）上启动任务的模块进行处理，实现业务服务秒级自动故障转移，展现更好灾难恢复能力。
横向扩展和负载均衡确保高性能
横向扩展是目前实现高性能的最佳解决方案。通过增加服务器数量，可以大大提高系统性能；负载均衡可以基于不同业务场景下的动态任务分配，最大限度地利用集群中的计算节点。通过Odin集群架构实现横向扩展，通过负载均衡实现合理的动态任务分配机制后，集成平台TPS可达数千。
统一的开发监控界面保证易用性
Odin集群方案还可以将处理不同任务的服务器集成到一个逻辑界面中，实现一个配置，多点操作，数据一致的效果，统一配置监控管理界面，实现消息跟踪、消息传递等功能监控和日常消息一页检索，操作更方便，使用更方便。
2.2.3 互联网医院建设支持
集成平台中间件提供多种满足互联网需求的协议支持，可以帮助在线互联网医院离线连接各种系统和设备。
Odin引擎集群版已内嵌API网关服务，可在外部访问互联网医院时提供权限管理、访问控制、设置黑名单/白名单等功能，在线预约互联网医院、线下复诊、床位预定等服务提供协同支持。
2.2.4 新技术支持
三甲医院都希望在信息化建设中融入“云、大物、移动智能”等新技术。相应的集成平台中间件也需要为不断变化的新技术和新的应用场景需求提供支持。
Odin引擎支持多种新技术，包括用于流数据处理的Kafka分布式流平台、面向大数据应用的服务和系统架构、面向物联网的MQTT、XMPP等应用层协议...... .这些可以使集成平台中间件为先进技术的应用打下坚实的基础。
3.集团医院和大型区域医疗机构
3.1知音：集团医院对集成平台中间件的高性能、高可用要求更高
3.1.1 医院规模
由于集团医院和大型区域医疗机构的规模进一步扩大，不仅需要考虑院内系统的整合，还需要转移角色，考虑医院之间的数据整合和交换以及医院和医疗联盟/密切的医疗社区之间。
3.1.2轴承业务
通过集成平台核心中间件实现数据交换和集成的“真”集成业务也将由医院向外部延伸，以浙江省某集团医院为例，集成项目上百个，需要建立终端连接和自助终端来完成多个院区的整合，每天的消息处理量也是几百万。如果所有业务都基于该平台，理论上每天的消息处理量甚至可以达到数千万。
3.1.3 综合平台定位
医院内不仅需要集成HIS、EMR、LIS、PACS、PDA、自助机等各种系统和系统。设备还需要对接预约平台、省级质控平台、申报平台、微信等外部平台。此外，还要注意多医院之间信息数据的交换与整合。这些目标不可能一蹴而就。在大多数情况下，此类集团医院或区域医院都有相对长期（5年以上）的综合平台建设计划。
因此，上述情况将对一体化平台中间件的高性能、高可用提出更高的要求，集群部署方案成为医院实现一体化平台高可用、高性能的首选方案。一个。
3.2 知己知彼：如何整合平台中间件实现真正的集群部署
3.2.1 传统集群架构的局限 性能：资源利用率低；性能还是有上限的
传统的集群架构只能以服务器为单位水平扩展。在许多情况下，扩展的服务器中只会使用单个应用程序资源。因此，下面要提到的云原生分布式集群方案相比，资源利用率要低很多。
同时，随着服务器的增加，集群节点管理和调度的难度也会大大增加，性能提升越来越少，很难完全满足集团医院或地区医疗机构。需要。
3.2.2 云原生分布式集群：面向未来的前瞻性解决方案
除了集群解决方案，Odin 还针对医疗财团和团体医疗机构提供基于 K8s 等容器化技术的云原生分布式集群。云原生是未来医院业务快速变化背景下的必然技术趋势，容器编排和具有代表性的容器技术支持云原生分布式集群。
与传统集群相比，融合最新容器技术的云原生分布式集群进一步深化了传统集群架构的技术特点。作为实现微服务的最佳载体，容器可以更细致地监控和管理服务器中运行的任务，这是传统集群架构无法实现的。这种监控管理粒度的突破，使得云原生分布式集群能够打破传统集群架构的性能局限，具体体现在以下几点：可以轻松满足医联体等区域医疗机构日常数千万甚至数亿的数据处理和调用请求。
精细化的资源配置大大提高了资源利用率：容器技术的轻量化特性可以极大的解耦，提高应用的整体敏捷性和可维护性，还可以根据不同应用的资源需求分别扩展，扩展粒度更细，整体资源利用率更高，容易面对超高并发环境。
容器化分布式部署缩短响应时间：通过容器化分布式部署，不同的进程独立存储在不同的容器中，分别管理和监控，更适合微服务。事务处理时也可以明确分工，将消息请求的响应时间缩短到毫秒级。
此外，Odin的云原生分布式集群解决方案还具备分组、互联网化、区域化、灰度发布、多人协作、中间件租赁等大规模数据交换所需的微服务支持。改造等优秀特性的应用，这也是传统架构无法比拟的。
【结论】
集成平台中间件（如集成引擎、ESB）的特点和架构要求医院根据自身情况慎重选择，医疗机构需要审视自身需求，先做“认识自己”是无敌的，进而深入了解集成平台中间件，“识敌”，才能在选择集成平台中间件、搭建集成平台的道路上走得更稳更远。
【关于奥丁】
公司简介：Odin 位于新西兰奥克兰，是一家充满活力、快速发展的创新型高科技公司。我们的愿景是用工匠精神做最适合中国的产品，与合作伙伴紧密合作，为医院、医疗社区和区域医疗提供技术先进、面向未来的数据交换、集成、创新解决方案。和符合中国国情的服务。
Odin 在新西兰：新西兰政府的大力支持。由于表现出色，Odin 于 2018 年获得新西兰商业、创新和就业部以及 (MBIE) 国家创新增长研究资助 (R&D)，金额高达 1500 万新西兰元（近 7000 万人民币） ）。其核心产品已被新西兰政府授予国家级商标，是新西兰政府部门在全球范围内使用的商标。获得银蕨认证的产品代表了新西兰的国家形象，肩负着新西兰的国际声誉，代表了新西兰政府对奥丁产品的承诺。和信用审批。 Odin 在开发全球市场方面还获得了新西兰贸易与发展局 (NZTE) 的人力和财政支持，并且是 NZTE Focus 700 的成员。
奥丁的核心产品被新西兰政府授予国家商标
Odin 与一些世界领先的医疗开发组织（ 、 和 HL7 New）合作，成功实施了一个名为 ALEX (Layer) 的项目，该解决方案涵盖了新西兰 90% 以上的初级保健数据，使 GP 诊所能够通过 FHIR API 与第三方应用程序安全地共享实时医疗数据和记录。作为ALEX项目的核心中间件组件，Odin NeXT云原生平台提供强大的集成和扩展能力，实现异构数据的标准化映射，以及超高并发和低延迟的承载能力。这个项目在新西兰有很大的影响力，HL7新西兰年中会议让这个项目成为了一个专题。
Odin在中国：目前，大多数顶级或主流HIT公司都转用或直接选择了Odin引擎，包括威宁健康、创业汇康、燕华智能、万达信息金堂、华润医疗、中电万维、华卓科技、麦迪逊科技、亿联众医疗、银江医疗网、银江云计算、望海康信、创兴科技等，用户体验极佳。 Odin引擎在数百家医院稳定运行，帮助医院对电子病历系统功能和应用水平进行分级评估，互联成熟度评估和认证。奥丁的软件在中国注册了计算机软件著作权，拥有自主知识产权。
产品创新：奥丁产品在功能上实现了从集成引擎到“三合一”到“多功能”到“多功能+”的四级飞跃，也完成了从从单机冷备到高可用（High，HA）再到集群和国内少见的全球领先的云原生架构。奥丁对产品进行了深入的本土化二次开发，增加了国内常用但国际知名品牌没有的功能和易用性。
Odin既有解决医院机构当前问题的创新Odin多功能引擎，又有集成引擎（IE）、服务总线（ESB）、数据提取、转换、报告三合一功能（ ETL），并包含大数据、物联网支持等其他功能；还有Odin NeXT（新），未来基于K8s最新技术的PaaS层云原生分布式集群版本，助力未来20-30年新一代医院信息系统建设.
目前，Odin引擎和数据服务平台不仅广泛应用于医院的集成平台，也应用于医院财务中台的建设，还可用于各类数据的互联互通。医院平台，以及医院一体化平台建设。建设集管理、运营、财务、临床为一体的大平台。 Odin 产品还可以用于非医疗行业的数据集成和服务。
