集成平台想要真正用于推进智慧医院建设，需要内嵌的丰富功能满足智慧医院建设基本的业务需求，具备前瞻性的架构设计。
智慧医院建设是医院迈向数字化时代的必由之路，国家卫健委也曾精确指出过它的三大工作范围：包括面向医务人员的“智慧医疗”、面向患者的“智慧服务”以及面向管理者的“智慧管理”。那智慧医院建设需要什么样的集成平台，为什么合理的集成平台架构能加速实现智慧医院建设？
如今的智慧服务建设中，医院纷纷通过自助机以及网络上接入的第三方服务平台等方式，为患者提供便民服务，但是在接入过程中医院面临着如下风险：
业务需求不同：患者服务中涉及到各种业务对于消息处理的不一样的要求（例如查询类业务要求响应速度快，响应时间不能超过3秒，有同步处理要求，支持高并发；交互类业务对于响应的速度要求相对不高，但要保证消息的传输以及传输时的顺序）
而通过集成平台内的集成引擎、ESB等多种数据集成交换技术灵活应用，以及集成平台中API网关内置的访问控制、实时数据加密等数据安全保护技术，能轻松满足外部设备和功能的接入需求，支持医院的智慧服务建设。
具体案例：台州恩泽医疗中心（集团）在对外服务项目中，提供给第三方的接口采用Odin引擎提供的对称加密和非对称加密相结合的方式，不仅有效保护了患者数据隐私，同时也保证数据在传输中的安全可靠，满足了“医院智慧服务分级评估标准体系（试行）”安全管理这一项中“互联网环境下信息系统所有数据须进行加密传输”这一智慧服务4级的基础项目(即必选项)要求。
随着智慧医院建设的不断深入，医院从通过IT技术实现流程的优化，逐渐转变为通过中台的架构思维对业务进行重构，为业务赋能。因此，集成平台也需要支持中台建设，甚至平台设计之初就能通过前瞻性的设计实现对前端业务的解耦，助力深化智慧医院建设。
三级医院（或以三级医院为建设目标的二级医院和在建医院):对平台易用性、业务承载力有需求，建议采用一体化集群架构
三级医院的规模体量大，平台承载的业务和子系统也慢慢变得多，集成平台动辄需要连接上百个服务点以及几十个集成业务流程，而且随着智慧医院建设的展开，更多智能化医疗器械、自助机等先进设备的接入也使得服务点持续增加。
这些设备的接入暴露出的，是医院在集成平台建设中缺乏自主可控能力、平台性能不足等痛点。部分医院逐渐发现对“集成平台的开发能力有限，开发效率不高，慢慢感觉力不从心”；而另一部分医院则对集成平台的性能问题颇为担忧。浙江省台州医院的信息中心集成平台项目负责人刘祉呈在分享集成平台建设经验时就坦言：对那些每日业务量超过百万级的集成平台而言，采用单/双机作为底层架构是否还合适？不合适了!
对此，部分医院采用或准备采用一体化集群架构，该架构不同于单机系统部署在多台虚拟机上形成的集群(其核心仍是单机架构)，而是集成平台中间件在设计时就根据医院平台的业务特点原生实现的集群架构，有着“双活”或“多活”模式所不具备的特点，包括:
一体化的集群架构不论是在容灾策略的精细度、覆盖度，还是负载能力的资源利用度、性能承载度、风险控制等方面，能更好地支撑集成平台的稳定运行。
集团化医院或区域医疗卫生机构：多元化、大规模集成需求，建议关注分布式云原生集群架构
集团化医院和大型区域医疗机构由于规模的逐步提升，不仅需要仔细考虑院内系统的集成，还需要转变角色，考虑医院和医院之间以及医联体/紧密型医共体之间的数据集成和交换。因此，此类医疗机构对集成平台中间件提出更多元化的要求，以满足未来大规模的集成需求，而分布式云原生的集群化部署方案就成了这种情况下的首选方案之一。
对于区域医疗机构来说，作为信息整合方，负责各医院数据的集成、存储甚至运营开发，其中一个关键的问题是对于接口实时调用量的不可预测性，对于一些核心接口（如链接了关键的第三方应用服务），如果仅维持正常的接口调用量，如果出现突发事件接口调用暴涨，很容易出现服务器宕机等故障；但是时刻保持大量冗余又是对资源极大的浪费。
基于最新容器编排技术Kubernetes (K8s)的PaaS层云原生分布式集群架构，面对接口调用量短时间内暴涨的极端情况能快速进行智能化弹性延展，提供所需资源，充分体现微服务和云原生的特性及优势，真正发挥该架构在PaaS云计算环境下的动态调动、弹性延展、精细化资源配置等特性，在面对支撑超大规模集成时将更会游刃有余，而这些能力也都是传统中间件架构所无法企及的。
2021年5月，“全球首个基础医疗数据互操作平台”—— ALEX (Application Layer EXchange)在新西兰全国范围正式上线%的基础医疗数据。其核心数据交换中间件采用分布式云原生集群架构搭载在微软的Azure云环境中，为ALEX平台提供大规模实时计算的高并发、低延迟、强稳定和端到端的集成扩展能力。
根据自身规模，找到比较合适的集成平台架构（三级医院可选择一体化集群架构、区域或大型集团化三甲医院可选择分布式云原生集群架构）