关于信息平台/数据中台技术，你应该知道的八件事

查看原文

近日，国家卫健委统计信息中心发布了两则通知——

2021年10月25日，国家卫健委统计信息中心发布《关于开展国家医疗健康信息互联互通标准化成熟度评测工作的通知》，这意味着新一年的评测工作开始启动。

2021年11月5日，国家卫健委统计信息中心发布了“关于2020年度国家医疗健康信息互联互通标准化成熟度测评结果(第二批)公示的通知”，公布了第二批10个区域和92家医院的测评结果。

这两则通知，再次将“互联互通”带到了医疗IT人的面前。而每每谈到互联互通，就不可避免地要谈到集成平台、信息平台和数据中台等项目建设问题，本文将从供应商选择、技术选型等从八个核心问题，浅谈关于平台和中台的那些事。

一、如何选择供应商？

 

如上图所示，如果我们把平台/中台项目的实施方称作解决方案提供商，那么每一家解决方案提供方背后还会有一家产品技术提供方解决方案，因为解决方案提供方往往需要借助成熟的产品来实现信息平台和数据中台项目，以聚焦所服务医院客户的具体需求，并加速实施效率，所以一个平台/中台供应链条相对比较长。也因此，医院/医疗集团需要花费更多的精力在产品和解决方案的组合中进行选型。选型的标准也成为许多信息中心或者CIO们关注的首要问题。

首先要考虑平台/中台解决方案提供方本身的品牌和实力：通常而言，选择全国性的解决方案提供方更安全一些，这类厂商的解决方案相对成熟、成功案例多，技术能力强，实施经验丰富；但是对于一些规模略小的医院而言，可能会顾虑这些厂商的客户太多，对本院的支持力度不够，或者是在该厂商在当地没有分公司，存在技术服务跟不上等问题，也可能会更倾向于初创企业或者本地解决方案提供方来做项目的集成或者实施，这两种选择都没有问题，关键是所选择的合作伙伴要值得信赖。

另外要考虑厂商背后的产品技术提供方：通常产品技术提供方不直接面向最终客户提供实施服务，而是通过本地合作伙伴向最终客户(即医院或者医疗集团)提供服务。但是作为解决方案的基础，该产品或者技术本身的先进性、可靠性以及未来的可扩展性都是需要重点衡量的因素。例如医院建设集成平台或者互联互通平台通常都会本着以评促建以评促用的目的，利用信息平台的建设契机，打通院内的信息和数据流程。此时，产品技术提供方有多少业务建模和流程整合的案例与经验也将在很大程度上影响项目的交付质量。

同样，医院也可以参考该产品技术提供方的行业积累、案例详情、服务承诺以及业界口碑等等。

总结一下，在选择方案时，需要考虑的实际上是产品本身的技术能力和对应的解决方案提供方的服务能力。因此，我们建议大家基于成熟的产品，选择能提供较好技术服务的解决方案提供方。如果产品并不成熟，那么即使解决方案提供方愿意常年提供驻场技术服务，也很难应对故障，也难以制订预案保障平台稳定运行。

 

二、技术路线的选择

在医疗行业进行业务和数据整合时，用户常常会需要在点对点集成模式、消息路由模式以及SOA架构模式进行技术决策。

事实上，从来就未曾出现过集成模式的最终解决方案。医院和医疗集团用某种特定的集成模式搭建自己的数字化高速公路时需要充分考虑该模式是否适合自己的场景，投入产出比是否符合自己的预期，以及是否能够充分利用该模式的优势。

举例而言，当医院考虑采用SOA架构时，需要考虑到遗留系统是否能够提供服务接口；在当前的业务运行条件下，是否能够承受由于接口的侵入式设计引入的风险，是否可能通过预案规避风险；以及医院是否已经或者将在平台投产前后具有实时数据分析的需求和技术储备。否则就将面临投入无法得到回报的质疑，甚至是规划无法落地的尴尬。

再看一个例子，如果要采用点对点模式集成，那么医院就需要考虑在平台投产可预见的周期(如3～5年)内，是否会面临跨部门跨系统数据利用需求快速增长的前景。如果有，那么，由于缺乏SOA架构能够提供的业务抽象和整合的能力，爆炸性增长的接口数量和数据整合需求会成为信息科难以应对的直接威胁。

正是由于集成模式的高度个性化，我们认为作为基础设施的集成平台类产品必须能够支持所有集成模式。一方面是满足各种不同类型的医院的需要，另一方面，医院也需要认识到，基础设施的建设从来都不是一蹴而就的“一锤子买卖”。您完全可以在集成需求数量较低时选用点对点模式快速投产，在需要进行流程和数据整合时应用SOA架构以获得企业全景视图的整合优势。而一个能够支持所有模式的产品才能赋能于客户，使之具备进行策略选择的优势。

 

三、开源策略的潜在风险

采用开源组件迅速获得能力，结合DevOps快速迭代开发是应对快速变化的市场环境和需求，进行产品化开发时的优先选择。在进行应用开发时，这样的策略通常有效。

然而优势与代价总是如影随形。借助开源组件的优势是能够快速获得能力，但开源组件的稳定性、可靠性和安全性则是每一个技术决策者都需要考察的关键风险，甚至开源组件许可证的更新都有可能为企业引入巨大的知识产权风险。

例如久负盛名的ElasticSearch，作为一款企业级搜索和分析引擎，它对于文本检索的能力和效率都有保障，被许多产品集成用于检索。但ElasticSearch及其依赖的其他组件已被检测出大量的安全性漏洞，例如可以引入中间人攻击的CVE-2021-22138，可以允许用户查看未授权敏感信息的CVE-2021-22147，以及可以允许用户通过ElasticSearch在服务器上运行任何OS指令的CVE-2014-3120等，风险列表每年都在更新。(风险列表可参见https://www.elastic.co/community/security)同样是ElasticSearch，在将开源授权更新为SSPL之后，如果业务用到了ElasticSearch并打包为可盈利产品，则ElasticSearch公司有权要求用户开放源码并收取费用。

因此，在使用大规模集成开源组件构建的产品时，医院需要评估产品技术提供方是否能够及时更新开源组件以获得安全性更新，并评估产品技术提供方是否能够及时跟踪和处理因授权变化会引入的法律风险。

集成平台、数据中台甚至是数据库这样的基础设施如果构建在大量的开源组件上，频繁的版本变动通常意味着组件集成风险的大幅升高，而跟踪和处理版本变更的技术和法务影响也将成为需要持续投入的持有成本。因此，一体化、完整知识产权的集成平台或数据中台产品在简化技术堆栈的同时也将大幅降低长期持有成本。对于医院用户来说，需要平衡评估一体化商业产品和开源集成产品的购买和持有成本，更需要考察产品技术提供方对开源组件的跟踪、更新和维护能力。

 

四、关注稳定与可靠性保障

核心业务系统、集成平台和数据中台这一类的关键系统，事关医院业务是否能持续运行，其运行稳定性与可靠性的重要意义不言而喻。基于主备、多活等冗余技术的平台高可用和灾备方案仍是为平台运行保驾护航的关键手段。

在市场上可见到的诸多产品中，有采用原生高可用方案的产品，也有集成第三方或开源技术高可用方案的产品。在这里，各位信息中心负责人或者技术决策者不得不考虑一个问题，即高可用方案的责任归属问题。

因此，即使一些非核心部件采用第三方技术，高可用方案也应采用产品原生技术。即使退一步来说，在没有原生高可用方案的情况下，您的解决方案提供方也应当承担起解决平台可用性和可靠性问题的技术服务角色。试想，当高可用方案失效或处于故障状态时，解决方案提供方采用了非原生高可用方案，届时难道能依赖开源社区的随机问答解决问题？

 

五、跨越技术门槛

医疗数字化进程与人工智能等目前的热点技术有很大不同，即必须基于当前业务。但由于医疗业务本身面临与新技术的融合，因此数字化进程也必须具备足够的灵活性，能够迅速应对业务过程的演化。而医疗业务流程或数据流程的演化，是需要业务专家、开发工程师、运维保障团队协作共同完成的，每一种角色都需要在平台上工作。因此，纯粹面向开发工程师的技术平台将无法有效应对业务流程本身的快速迭代。我们认为，一个成熟的集成平台/数据中台，需要为团队中不同角色的成员提供适合他们的开发/维护/测试工具，使各成员能以较低的成本各施所长。这些工具至少包括：

· 图形化的流程、数据转换和业务规则建模工具，使得业务专家即使不了解业务组件的技术实现，也能利用平台上的组件搭建出适合医院的业务/数据流

· 专业的IDE和管理工具，供研发工程师扩展业务组件和对现有组件进行跟踪和组件级调优

· 监控和管理工具，供运维工程师监控平台运行的健康状况和性能，必要时对平台运行参数进行调优

 

六、集群的选择

我们理解一些工程师非常关心产品是否支持负载均衡。需要注意的是，对于现代的集成平台和数据中台而言，它们本身应当是由一系列的集群共同构成的分布式系统。

比如院内集成平台拥有基于Web的操作管理页面，运行API实现或数据流程的容器，有消息引擎，有数据库，因此，可以构成一个典型的由Web程序，API/应用服务器，消息引擎和数据库分层构建的分布式系统，而其中的每一层，都可以根据高可用与负载需求以不同目的的集群形态搭建出来。

以集成平台产品为例，通常，集成平台的Web管理程序由于并发操作的人很少，不需要单独进行集群化；而API/应用服务器层默认会采用高可用集群，对于业务量极大的用户，则可以采用负载均衡+高可用集群；数据库层同样如此，必要时还可以考虑部署读写分离+负载均衡+高可用集群；消息引擎则比较特别，如果不需要保障消息的先进先出特性，可以部署高可用和负载均衡集群，而对于需要保障消息处理时序的场景，则通常不能依赖负载均衡集群，或即使部署了负载均衡集群，也需要控制消息分规则，由单一实例处理这样的消息。

但是否采用及采用何种集群架构，则完全应当基于业务的实际需要和产品能力。举例而言，InterSystems产品可以支持负载均衡+高可用集群，还可以部署为读写分离+负载均衡+高可用集群，但通常我们并不会作为默认配置推荐给集成平台用户。原因在于，我们的产品在单台服务器上经性能测试可以达到20亿消息/天的处理效率。而根据我们对国内数百家三家医院的实际调查，即使在国内顶尖的三甲医院中，也未发现超过2千万消息/天的性能需求。因此，对于单体医院，高可用集群已足够使用。基于奥卡姆剃刀原理和成本控制的基本需求，负载均衡集群并无必要，反而会由于加大了架构的复杂性使持有、维护成本都大幅提升。而对于医疗集团客户，由于需要集成数十家三甲与二级医院，同时还需要控制单个服务器的成本，因此我们的一部分医疗集团客户部署了负载均衡+高可用集群并可进行弹性横向扩展。

当然，不同的产品有不同的性能指标，如果产品的本身性能表现无法支撑医院业务量，那么部署为负载均衡集群支撑医院的实际需求还是非常必要的。

 

七、技术服务保障

相比开源产品，基于商业产品搭建平台/中台解决方案最显著的附加价值主要来源于技术服务。无论是最终用户还是解决方案提供方，都能受益于产品提供方的技术服务。技术服务也是项目能否成功上线、持续稳定运行或者二次开发的重要保障，对于技术服务，需要考虑产品技术提供方是否能够提供下面的三种或者以上的方式：

·  故障处理和技术支持：对于产品应用、二次开发的疑问，是否可获得技术支持资源以解决疑问？对于在产品运行过程中可能遭遇的软硬件故障，尤其是系统崩溃、宕机等高等级事件，是否能够获得直接的技术支持解决、定位和调查问题？

· 产品培训：是否具备成体系的产品应用、二次开发和维护培训体系

· 在线课程

· 产品文档库

· 开发者社区：非工程师的客户往往不重视开发者社区的力量。实际上，作为可供全球开发者沟通的场所，在开发者社区往往能找到常见问题的解决方案，具体问题和场景的最佳实践，前瞻性技术研究等非常有价值的资料。

对于医院或是医疗集团客户来说，如果需要掌握信息平台或数据中台，能够达到自主维护、持续演进的目标，那么，无论是通过解决方案提供方还是通过产品技术提供方，都需要获得上述的多种技术服务支持。

 

八、选型中的常见问题

对于采用商业产品这一策略本身，需要经过大量的选型工作。产品技术提供方和解决方案提供商都会积极宣传自己的产品，而医院则需要对产品的特性，服务体系，性能表现，案例的代表性，综合实施效果等做出评估，方可得出对自己有利的评估结果。在这个过程中，客户往往还是需要综合运用多种手段，包括自行评估、走访典型案例和开展验证测试等手段，避免常见的一些问题，例如：

· 技术的可执行性评估不足

例如对于仅支持消息引擎的集成平台，往往需要按照一种特定的消息类型进行通信，使系统间交互具备统一协议，并且系统都需要改造以接入消息引擎。这样的规划不能说不好，但医院的遗留系统能不能都配合平台进行改造或医院有没有足够的预算支撑改造项目落地，以及业务系统现场改造的风险，都会影响实施效果。因此需要切实评估和核实。

·  产品特性不能达到预期

例如对于具有ETL能力的产品，需要评估其对于大容量数据(例如初始化数据加载过程)进行批量采集、转换和落盘的处理效率，以便与借助简单的SQL JDBC连接逐条抽数和转换的SQL适配器相区别。由于两种模式在处理速度上通常有数量级的差别，如果使用SQL适配器模式，在大批量对数据进行ETL操作时将不可避免地遭遇瓶颈。

· 产品对主流技术的覆盖不全面

在现在的技术条件下，即使对同一类型的接口，也往往有多种技术选择。如产品不能提供对这些技术的覆盖，则用户需要投入额外的成本和风险完成接入。例如对常见的负载均衡方案而言，通常对于推模式接口(由外部调用触发的接口)，例如SOAP WebService或者REST API，往往都能提供负载均衡；而对于拉模式接口(由产品自身自动触发)，例如SQL扫描或一些CDC功能接口，则无法直接受益于负载均衡技术。假如实际业务中有大量需要通过SQL获取数据的接口，则负载均衡集群并没有多少意义。

再如SQL接口可以基于JDBC或ODBC连接，如果产品只能支持其中一种连接，那么对于遗留系统的接入能力将大打折扣。

·  缺乏技术验证过程和约束

对于架构和技术的落地，通常需要验证过程，用户才可能获得预期的效果。例如市场上存在对架构模式进行过度简化与概念偷换的现象。例如将SOA架构等价于ESB、将ESB的概念偷换为接口引擎、或将集成平台概念偷换为消息引擎，而在实施时更进一步地简化为接口的注册和连接，实际上变成了点对点模式。由于集成架构将影响未来3～5年的医院数字化转型过程中的难度和成本，点对点模式的后续实施成本将随接口的数量增加指数上升，导致后期的实施成本居高不下。

当然，充分了解到以上关于供应商选择与技术选型的8个问题，才是真正的互联互通建设的起点，更重要的是，医院信息负责人还需要真正读懂评测要求，并了解本院建设互联互通的整体目标以及医院管理层、临床业务部门等相关部门的不同述求，把这些目标与述求一一映射到平台/中台解决方案中，才是成功通关的秘籍。