查看原文
其他

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

孙婧 龚晨 HIT专家网官微 2022-11-03

导读

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

为消除信息孤岛、实现系统间的互联互通,进而支持跨机构的医疗信息共享和协同,建设医院信息集成平台是重要方式之一。为避免“几年后推翻重建”,集成平台建设需要前瞻性的架构设计;作为集成平台核心组件的集成引擎,更需“打好地基”,从全局高度规划架构,从而长期、稳定地支撑医院业务发展。
在医疗机构互联互通领域具备丰富经验的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引擎的原因。
【相关链接】
【吴坤专栏】全方位解读医疗信息集成平台系列特别篇:容灾应对之道
读者来稿】从4个典型应用场景看如何将集成平台“用到实处”?
【读者来稿】为何要为医疗信息集成平台选择集群架构?


关于 Odin
Odin Health是一家为医疗机构提供数据交换、集成、服务解决方案的新西兰创新高科技软件公司。

Odin在新西兰:荣获商业、创新和就业部(MBIE)国家级创新成长科研津贴(R&D Growth),旗下核心产品被政府授予了国家级FernMark商标,也是新西兰贸发局重点支持的NZTE Focus 700成员企业。

Odin在中国:多家主流HIT公司(包括卫宁健康、创业慧康、延华智能、万达信息金唐、华润医疗、中电万维、华卓科技、麦迪科技、易联众医疗、银江医联网、银江云计算、望海康信和创星科技等)和医疗机构使用Odin引擎,助力电子病历和互联互通测评,在国内登记了计算机软件著作权。Odin产品中既有解决医疗机构当前问题的创新多功能引擎、新一代多功能一体化集群式架构引擎,也有面向未来基于最新技术Kubernetes的PaaS层云原生分布式集群版Odin NeXT,助力新一代医院信息系统建设。

近期热文
HIT专家网∣致力推进中国卫生信息化长按二维码可申请加入HIT专家网专业交流群投稿:gong_chen@HIT180.com

商务合作:(010)82373062

本公众号原创文章,版权归原作者所有。

未经许可,谢绝转载或以其他形式使用文章内容进行传播。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存