在选择集成平台中间件时医疗机构做到“知己”和“知彼”，那具体到不同规模的医疗机构，它们的建设侧重点又分别是什么？
随着国家对于医疗机构相互连通要求和医疗大数据应用的不断深入，建设集成平台来实现医疗系统的流程再造和数据治理已然成为很具实践价值的方式。此时集成平台中的核心中间件（如ESB、集成引擎等）就很重要了，因此怎么样选择比较适合自身情况和应用场景的集成技术和架构是医疗机构需要仔细考虑的。
在选择集成平台中间件（例如集成引擎，ESB）时医疗机构做到“知己”（即分析自身情况和需求）和“知彼”（即了解集成平台中间件具有的功能和特性），那具体到不同规模的医疗机构，它们的建设侧重点又分别是什么？
二级医院集成平台建设方面配备的人员少，甚至会出现整个信息科只有一个员工的情况，可供调配给医院信息化建设的物力、财力资源也有限。有统计显示，北京地区三级医院的实际床位数为二级医院的3.24倍，但医疗信息化投入是二级医院的7.59倍，同时三级医院获得的政府财政资金为二级医院的5.53倍，可见在除去规模因素外，三级医院的信息化建设的可调配资金和信息化投入意愿仍然都高于二级医院。
承载的业务量相对较少，总体建设的复杂度也较低，但仍一定要通过各类数据交换技术实现基本的业务场景（如医院门诊挂号、内网服务分发、抽取数据通过平台上报等），并且需要在有限的人力财力条件下保证日常业务的正常运转。
由于大部分二级医院有着升三级医院的诉求，现有系统和设备也将会一直更新完善。但对于集成平台建设没有系统规划，更多时候仅为解决电子病历、相互连通评级所需的场景，后续集成建设缺乏连续性，也难以快速实现对新业务系统的接口和协议支持。
1.2.1 IE（集成引擎）、ESB、ETL、APIs“多合一”兼顾成本和业务需求
二级医院想兼顾成本和业务场景需求，而Odin引擎融合了IE(集成引擎)、ESB、ETL、APIs等多种数据交换技术的集成平台中间件，不仅满足场景需求，医院也不用购买多套产品，而且维护更简单方便，缓解”钱不够“的问题。
Odin引擎针对二级医院需求提供AO热备、双活等高可用容灾方案，保证各系统正常运作。同时Odin具有纯Web界面、图形化拖拽式操作、全面精细的消息跟踪视图等易用性功能则能帮助运维人员快速上手，快速定位并解决错误，大幅度降低人手短缺对于日常业务运行的影响，缓解”人不够“的问题。
由于部分二级医院缺乏长期规划，很可能没有预先考虑到完善设备系统时的配套设施，这就需要集成平台随着系统设备的更新而扩展，为未来二次开发或升级改造留下余地。
Odin引擎提供包括HL7 v2/v3、FHIR、DICOM等各类协议支持，同时引擎内也提供准开发平台，保证新业务的迅速接入（如疫情期间的“健康码”应用的快速上线），缓解“规划不够”的问题。
三级医院的信息部门人员更多，科室的系统和设备更完善；相对应的床位数和日门诊量也水涨船高，也有能力且愿意在集成平台建设上投入更多人力财力，是现阶段集成平台建设的主力军。
三级医院子系统更多，集成平台普遍需要连接上百个服务点以及几十个集成业务流程，且接入服务点需要随着需求的变更持续不断的增加。因此就需要更多个性化改造定制服务，并开放更多功能。
基本明确集成平台定位，除了最基础的通过IE(集成引擎)、ESB、ETL实现的各种复杂医疗业务场景，整合多源异构数据，还需要对数据来进行标准化处理和二次应用，并根据医院情况和外界大环境提出其它新的信息集成需求，如：
以高级别相互连通和电子病历评级为目标，让更多系统通过平台做数据的交换和集成，实现海量信息共享 （各类符合评级要求的标准支持和配套功能）；
部分国外的特有标准和法案并不适合国内环境，国内医院花大价钱，这些标准却完全用不到。而像相互连通要求中的CDA标准、数据集标准等国内常用标准，却由于缺乏配套功能（如数据映射）需要医院二次开发。
Odin进行了大量本土化开发，具备国内常用而国际著名品牌不具备的功能和易用性，包括内嵌符合国家相互连通的CDA、数据集等标准组件、内置各种标准化定义、数据处理转换工具、PDF导出等各类组件，并兼容国产服务器和操作系统。
Odin提供的集群方案是指在产品设计时根据医院平台的业务特点原生实现的集群架构，并非单机系统部署在多台虚拟机上形成的“集群”（其核心仍是单机架构）。
当模块出现异常时，原生实现的集群能自动侦测到异常并在其它服务器(节点)自动启动该任务的模块来做处理，实现业务服务秒级自动故障转移，展现更好的容灾能力。
横向扩展是目前实现高性能的最优解决方案，通过增加服务器数量，大幅度的提高系统性能；负载均衡则能根据不同业务场景进行动态任务分配，最大化利用集群中的计算节点。通过Odin集群架构实现横向扩展，并通过负载均衡实现合理的动态任务分配机制后，集成平台的TPS能达到数千。
Odin集群方案还能将处理不同任务的服务器整合至一个逻辑接口，实现了一处配置、多点运行、数据相同的效果，统一配置监控管理界面，在一个页面中实现消息追踪、消息监控以及日常消息检索等功能，操作更便捷，易用性高。
集成平台中间件提供符合互联网要求的多种协议支持，能帮助线上互联网医院连接线下的各种系统和设备。
Odin引擎集群版中已内嵌API网关服务，能在互联网医院受到外部访问时提供权限管理、访问控制、设置黑名单/白名单等功能，为互联网医院的线上预约、线下复诊、预约床位等业务提供协同支持。
三级医院在信息化建设中都希望融入“云大物移智”等新技术，相对应的集成平台中间件也需要为一直在变化的新技术和新的应用场景需求提供支持。
Odin引擎支持多种新技术，包括流式数据处理的Kafka分布式流平台，大数据应用的ZooKeeper、Hadoop等服务和系统架构，物联网的MQTT、XMPP等应用层协议......这些都能让集成平台中间件为先进的技术的应用打好基础。
集团化医院和大型区域医疗机构由于规模的逐步提升，不仅需要仔细考虑院内系统的集成，还需要转变角色，考虑医院和医院之间以及医联体/紧密型医共体之间的数据集成和交换。
经由集成平台核心中间件实现数据交换和集成的“真”集成业务也将由院内延伸至院外， 以浙江省某集团化三甲医院为例，完成多个院区集成所要建立的集成项目、使用的终端连接和自助机终端有数百个，日消息处理量也有好几百万，如果全部业务都走平台理论上的日消息处理量甚至能达到上千万。
不仅需要集成院内的HIS、EMR、LIS、PACS、PDA、自助机等各类系统和设备，还需要连接预约平台、省质控平台、上报平台、微信等外部平台，此外还需要注重多个院区间的信息数据交换和集成。这些目标不是一朝一夕就能达成的，多数情况下这类集团医院或区域医院都有着较为长期（5年以上）的集成平台建设规划。
因此，上面讲述的情况会对集成平台中间件的高性能和高可用性上提出更高的要求，而集群化部署方案就成了医院实现集成平台高可用和高性能的首选方案之一。
传统集群架构只能以服务器为单位做横向扩展，很多情况下扩展的服务器中只有个别应用资源会被使用到，因此和下面即将提到的云原生分布式集群方案相比，资源利用率低很多。
同时随着服务器的增加，对于集群节点管理和调度的难度也会大幅度上升，对性能提升的幅度会慢慢的少，难以完全满足集团化医院或区域医疗机构的性能需求。
除了集群方案，Odin针对医联体和集团化医疗机构提供了基于K8s等容器化技术实现的云原生分布式集群。云原生是未来医院业务快速变化背景下的必然技术趋势，而支撑起云原生分布式集群的就是Kubernetes容器编排和以Docker为代表的容器技术。
和传统集群相比，融入最新容器技术的云原生分布式集群进一步深化了传统集群架构的技术特点。容器作为实现微服务的最佳载体，能对服务器中的运行的任务一一进行更细致的监控和管理，这是传统集群架构中所不能够实现的。这种监控管理粒度上的突破使云原生分布式集群打破了传统集群架构的性能局限，具体能体现在以下几点：
更强大的横向扩展能力满足海量数据处理需求：新的监督管理模式让弹性扩容成为可能，TPS跃升至数万，可以轻松满足医联体等区域医疗机构每天数千万甚至上亿的数据处理和调用的请求。
精细化资源配置大幅度的提高资源利用率：容器技术的轻量级特性能大幅解耦，提升应用程序的整体敏捷性和可维护性，扩展时也能根据不同应用的资源需求分别进行扩展，扩展粒度更细，整体资源利用率更高，轻松面对超高并发环境。
容器化分布式部署缩短响应时间：通过容器化的分布式部署将不同进程独立存放到不同的容器中分别管理监控，更加适配微服务。在事务处理时也能明确分工，对消息请求的响应时间更是缩短到毫秒级。
此外Odin的云原生分布式集群方案还具有集团化、互联网化、区域化等大规模数据交换所需的微服务化支持，灰度发布，多人协同，中间件租赁化等优秀特性应用，这也是传统架构不能够比拟的。
集成平台中间件（例如集成引擎，ESB）特点和架构均需要医院依据自己情况谨慎选择，医疗机构需要审视自身需求，先做到“知己”而立于不败之地，再进一步探索集成平台中间件，做到“知彼”，才能在选择集成平台中间件和建设集成平台的道路上走得更稳、更远。
公司简介：坐落于新西兰奥克兰，Odin Health是一家充满了许多活力、快速成长的创新型高科技公司。我们的愿景是用工匠精神做最适合中国的产品，与合作伙伴紧密合作，为医院、医共体、区域医疗提供技术先进并且符合中国国情的数据交换、集成、服务的面向未来的创新解决方案。
Odin在新西兰：得到新西兰政府的全力支持。由于卓越表现，Odin于2018年荣获新西兰商业、创新和就业部Ministry of Business， Innovation and Employment （MBIE）国家级创新成长科研津贴（R&D Growth），金额最高达新西兰币1500万（人民币近7000万）。旗下核心产品被新西兰政府授予了国家级FernMark商标，FernMark是新西兰政府部门在全世界内使用的商标，带有FernMark银蕨认证的产品代表新西兰国家形象，肩负着新西兰的国际声誉，代表着新西兰政府对Odin产品和信用的认可。Odin 在开拓全球市场方面也得到了新西兰贸易发展局（NZTE）提供的人力和财力的支持，是NZTE Focus 700成员企业。
Odin Health 与一些世界领先的医疗发展组织（Medtech Global、Microsoft 和 HL7 New Zealand）合作，成功实现了名为 ALEX（Application Layer EXchange）的项目，该解决方案涵盖了新西兰 90% 以上的初级医疗数据，允许全科医生诊所通过 FHIR API 与第三方应用程序安全共享实时医疗数据和记录。Odin NeXT 云原生平台作为ALEX项目的核心中间件组件，提供了强大的集成扩展能力，实现了异构数据标准化映射，超高并发低延迟的承载能力。此项目在新西兰影响很大，HL7新西兰年中会议特别将此项目作为专题。
Odin在中国：目前绝大部分头部或主流HIT公司改用或直接选用了Odin引擎， 这中间还包括卫宁健康、创业慧康、延华智能、万达信息金唐、华润医疗、中电万维、华卓科技、麦迪科技、易联众医疗、银江医联网、银江云计算、望海康信和创星科技等，使用者真实的体验极佳。Odin引擎在数百家医院稳定运行，助力医院开展电子病历系统功能应用水平分级评价、相互连通成熟度测评认证。Odin的软件已经在国内登记了计算机软件著作权，拥有自主知识产权。
产品创新性：Odin产品在功能上实现了从集成引擎到“三合一”到“多功能”到“多功能+”的四级跳，在架构上也完成了从单机冷备到高可用（High Availability，HA）到集群以及国内极少见的全球领先的云原生架构的转变。Odin Health 对产品做深度的本土化二次开发，增加了国内常用而国际著名品牌不具备的功能和易用性。
Odin既有解决医院机构当前问题的创新的Odin多功能引擎，具备集成引擎（IE）、服务总线（ESB）、数据抽取转换上报（ETL）三合一功能和包括对大数据和物联网支持等其它功能；也有面向未来基于最新技术的K8s的PaaS层云原生分布式集群版Odin NeXT (New generation eXchange Technology)，助力面向未来20-30年的新一代医院信息系统的建设。
目前Odin引擎和数据服务平台不但被大范围的使用在医院的集成平台，还用于医院财务中台的建设，同时也可用于医院各平台数据的互联互通，以及构建医院集管理、运营、财务、临床等为一体的大平台建设。Odin产品也可用于非医疗行业的数据集成和服务。