基于云计算的医院信息系统建设

基于云计算的医院信息系统建设

0医院信息系统的发展现状作为医疗和健康领域的核心和复杂信息系统，其技术结构和应用发展显著延迟。与物流、电子商务等行业相比，他的业务结构和“互联网+”的开发明显延迟。1数据安全整合目前，通过集成平台解决了多系统点对点对接的繁琐与协调的难题，做到了一定程度的互联互通。但对于系统本身而言，由于建设过程缺乏规范和标准约束，各种信息系统采用不同的技术和不同的标准规范，数据结构整合和差异数据一致化的处理成为集成平台构建的基础瓶颈。不同系统内部的低内聚、紧耦合的现状仍然没有改变，反而把底层（服务端、数据库端等）的架构和代码不断地集中和复杂化，构造了一个巨大的单体系统。系统内模块紧耦合在一起，为数众多的程序开发人员共同维护同一个核心需求项目，项目团队之间协同代价高，项目修改发布迭代周期长，应用处理能力扩展成本高，错误难预见、难管控、难杜绝，且信息技术（IT）人员学习成本高、人员调整成本高，数据库能力已达到上限，难以适应互联网时代业务需求的迅速变化。1.1不同系统间的切换目前，医院内部系统间集成融合问题的主流技术方案见图1。通过集成平台进行应用集成后，从用户体验来说，集成的烟囱系统仍然是烟囱系统，用户的体验仍然是割裂的，仍旧需要在各个不同系统之间进行切换。为了解决用户界面（UI）集成的问题，又催生了很多厂商打造的“一体化HIS系统”，也就是将临床系统、业务系统等的功能、流程等，在一个巨无霸的单体系统中去开发和实现的方式。1.2顶层设计和平台缺乏统一设计和统一医院信息系统建设在应用水平上，仍停留在流程化应用的水平。很多医疗机构的系统建设，是在发展过程中不断采用打补丁的建设方式，缺乏顶层设计和统一的规划、架构和平台。多年积累下来，接口繁多，问题修改、新需求开发对应用系统正常运行带来风险，信息部门的压力非常大。1.3能、移动应用等新技术的应用从新技术应用的角度上来说，传统医疗信息化企业非常了解医疗行业的核心业务，但是对于云计算、大数据、物联网、人工智能、移动应用等新技术的掌握程度非常有限，更难说得上“友好”的应用。互联网企业具有较好的新技术和能力，但是对医疗行业的复杂业务缺乏深入的了解，加上医疗机构的天然壁垒，导致互联网企业在医疗行业所能提供的服务，基本都停留在预约挂号、线上缴费、化验单查询、轻问诊等外围领域，难以将触角深入到医疗的核心业务中来，实现医疗核心业务的互联网化服务。1.4患者就医体验低，物理隔离较少出于安全考虑，多数医院采用物理隔离内外网的方式，把互联网应用和院内应用分离开，严重影响了医疗核心业务的互联网化、影响患者就医体验。物理隔离并未能很好地解决安全性问题。有些医院做了一些浅层次的尝试，把医院的物理机房托管在运营商的机房中，实现了基础架构的虚拟化和服务化（IaaS）。虽然号称实现了云计算的平台，但是实际上非但没有解决软件本身架构的问题，反而衍生出运维扯皮、故障难以定位和排查等诸多问题。2基于云计算和服务的中间云架构的hp系统2.1从第1阶段到第4阶段，进行业务中台化管理，实现医疗行业信息化的实现根据目前主流的互联网行业架构进化路线图，企业级互联网架构普遍经历了单体架构、烟囱架构、分布式架构，到基于云计算的面向服务的架构（SOA)首先，是单体业务系统/烟囱系统，如前所述，即各个医院信息系统当前所处的阶段；其次，是分布式业务系统，进行了分布式应用改造，以服务化方式将系统专业分工，在保证生产系统应用不停顿的情况下，逐步剥离后台的服务。同时，进行分布式数据库改造，突破关系型数据库处理能力瓶颈，快速扩容数据库服务能力，水平拆分、透明读写分离、平滑扩容，带来高性能、数据标准化、低成本试错，降低IT人员学习成本，业务关注力集中；再次，是业务平台化，把基础能力跟每个业务方的特性业务拆分，把业务和业务之间的逻辑进行隔离，业务抽象解决共性的80%问题，系统架构开放性解决了20%的个性化问题；最后，是业务中台化，虽然领域的平台化解决了领域内部的问题，但是很多业务都是跨领域的，面对复杂的系统协作问题，业务中台化阶段需主要解决4个问题：信息获取成本高、互联互通成本高、服务具有不确定性、低水平重复建设。借鉴互联网企业的技术和产品，可以实现医疗行业信息化的跨越式发展，从第1阶段直接发展到第4阶段。通过架构改进，最终形成医疗信息化的业务服务中台+数据服务中台的双服务中台战略2.2技术结构2.2.1医疗混合云平台通过混合云基础设施，基于规模化的云服务器，将公共云的计算、存储、安全等产品和服务输入到医院的互联网数据中心（IDC），结合公有云所提供的各种服务，构建医疗混合云平台。主要包括：弹性计算（ECS）、负载均衡、云数据库服务、云对象存储、云统一运维管理、云平台操作系统（OS）等2.2.2微服务支持业务的实现通过引入企业级的互联网分布式架构，可以足够支撑未来医院随着消费者（2C）业务和医联体业务的爆发式增长所带来业务量的几何级数增长。同时，PaaS还能为业务中台提供微服务架构所需的必要支撑。具体包括：企业级分布式应用服务（微服务平台）；分布式数据库服务；分布式事务管理服务；业务实时监控服务。2.2.3数据共享工具DaaS是属于数据中台的平台工具层。包括云数据库、对象存储软件、数据采集工具、数据治理工具、数据资产管理工具、元数据与数据模型管理工具、大数据计算服务、大数据算法、分析型数据库、数据分析BI、数据可视化工具等。2.2.4开放的业务能力中心建设医院的业务服务中台，可以实现各领域、各科室、各下属医疗机构之间、各信息系统之间的业务协同及数据共享，沉淀规范的医疗数据，满足业务敏捷性需求，支撑集团战略发展。支持将医院核心系统HIS、电子病历系统（EMR）、实验室信息系统（LIS）等改造重构为开放的业务能力中心，满足具备去中心化、服务化、异步化、高可用、数据化运营5大技术要求。业务服务中台的建设，不仅解决了烟囱系统中存在的重复建设的问题，而且解决了单体系统中存在的紧耦合的问题。通过按照业务领域进行业务服务的划分，建设和提供某个领域的后台服务，并将所有业务服务打通，形成统一的、可复用、松耦合、高内聚、无冗余、无重复的业务能力开放平台。业务服务中台的服务，以应用程序编程接口（API）和应用软件（App）的形式，即软件平台（SaaS）形式，开放给前端应用来使用，是业务资源与能力的外在表现形式。可以在PaaS工具的支撑下，采用微服务架构的方式来构建。2.2.5服务化：构建统一的中台架构，提供便捷的前端应用通过大数据云平台构建医疗数据中台，首先解决的是院内数据整合的问题，包括临床数据与运营数据的整合；其次，是梳理、建设医院统一的数据资产暨数据服务开放平台，实现数据的互联互通，避免数据多源不一致，让数据真正成为资产；最后是开发算法引擎和知识图谱，支撑诊疗辅助、临床决策支持、质量评估、阶段数据分析、多学科建设创新等智能应用。实现智能化疾病感知、智能化临床辅助、智能化的疾病诊疗，形成标准的、有序的、自学习的多学科建设创新平台。通过前后端分离，以及业务服务中台、数据服务中台的搭建，可以构建重后台、轻前台的架构，有效支持前端快速的业务创新。同时，不同的应用系统不再成为几张皮，而是在统一的中台服务能力的支撑下的统一UI展现。在服务化中台架构的支撑下，前端应用的建设模式由以前的从头到尾做一个系统，变为只需基于现有共享的核心业务和数据模型进行扩展或新的业务模式的创新，就能很快建设起来。完全避免了功能和数据设计的重复建设，因为同一领域的业务数据全部在同一服务中心里，也无需再进行业务打通的工作，同时也为后续大数据分析打下了很好的数据质量基础。例如：很多医院的桌面端医护工作站系统和移动医护站系统，基本都是两个完全不相干的烟囱系统（当然有接口连接两个系统），其中存在大量的业务逻辑重复。通过构建统一的业务服务中台以后，可以基于这个统一的后台服务来构建各种不同的前端UI展现，不仅有桌面端、移动端，还可以有网页端等。见图5。随着UI技术的飞速发展，包括虚拟现实（VR）、混合现实（MR）、增强现实（AR）的发展，也可以在已有的后台服务来快速开发基于新的UI技术的前端应用。这样的快速开发模式在原有的烟囱式建设方式下是不可想象的。2.3服务化中台的业务快速创新和成本较低服务化中台架构建设的真正价值，是面向互联网时代的医院新一代IT架构的体系化建设，包括业务架构、组织架构、人员绩效等。它能够带来应对未来所需的更快的业务创新、成本更低的业务探索，从而给医院带来提质转型、降本增效的核心竞争力。服务化中台搭建的共享服务体系能够赋予业务快速创新和试错的能力。如果创新成本高昂，将难以试错。统一的业务中台和数据中台天然地解决数据标准格式、质量、完整性的问题，可以真正地把数据变成资产，让大数据服务于医疗行业，服务于人类。2.4应用场景通过服务化中台架构的构建，可以满足的医疗应用场景非常多，以下面2个典型例子加以说明。2.4.1医疗周边业务服务受制于院内、院外系统的割裂和隔离，医疗机构目前开展的互联网应用主要停留在预约挂号、在线支付、检验检查查询、诊后随访等医疗周边的业务和服务。在建设好中台架构、打通院内外系统的底层之后，使得将互联网延伸到医疗核心业务中成为可能，可逐步发展到开展完整的互联网医院业务和服务，实现覆盖院前—院中—院后的全流程互联网服务。见图6。2.4.2算法引擎设计基于数据服务中台提供的统一数据服务，以及基于公有云开放的人工智能算法服务，用于构建临床诊疗决策支持系统。涉及的算法引擎包括：准医疗引擎、医疗影像人工智能（AI）、医疗文本结构化、疾病智能分组、商业智能（BI）引擎、资源调度优化等。通过对大量病历进行深度挖掘与学习，训练临床诊断模型，可最终实现基于人工智能的多学科联合诊断，辅助医生临床决策，规范诊疗路径，提高医生的工作效率等目标。3讨论3.1建设困难3.1.1业务请求及其他服务在后台服务化特别是微服务化以后，服务的颗粒度划分得愈来愈细。前端的一个业务请求，可能需要在后台的多个服务之间进行调用。以淘宝网的“生成订单”界面请求为例，这个操作需要在其后端触发两百多个服务调用。在这种情况下，如何确保系统的性能和用户体验，是一个巨大的考验。3.1.2分布式服务协同引入了企业级的分布式互联网架构以后，原来在单体系统或烟囱系统中单个事务中的操作，可能需要在多个分布式服务协同完成。例如：支付服务和库存扣减服务是位于不同的服务，甚至是在不同的物理服务器上完成。这就涉及分布式事务处理的完整性，以及数据一致性的问题。如何保证事务完整和数据的最终一致性，也是一个很大的课题。3.1.3管理型服务治理当后端的服务颗粒度越来越细、服务数量越来越多的时候，服务的统一资源定位符（URL）配置管理变得很困难、服务间的依赖关系错综复杂、服务上线容易但下线难，会被很多其他的服务所依赖，一旦草率下线，就会造成其他服务问题的连锁反应。此时，就需要引入PaaS层的服务治理等工具来解决问题。例如：通过服务注册中心，使服务的位置透明；通过可视化展示服务调用链来清理不合理的依赖、防止架构腐化；通过服务生命周期管理流程、服务安全策略来进行服务治理等。3.2问题3.2.1投资3.2.2医院外的患者服务系统总体的确定周期HIS的业务非常复杂，要从底层架构把遗留的HIS系统全部进行重构，建设周期会相当长。仅仅从时间上来说，院外的患者服务系统的重构相对简单，也许需要1～2年；由于院内系统非常复杂，保守估计也需要3年时间。当然，重构的人力成本投入也是很大的。3.2.3关键影响效果底层技术架构的重构，虽然未来的长远价值非常高，也很有必要，但是很难在短期内，让使用者和决策者看到实实在在的应用效果。需要考虑如何做好顶层规划和分步实施，尽可能按领域切片等方式逐步改造，在改造的同时，逐步引入和体现一些新的应用，让使用者和决策者逐步看到一些效果。4医院的本质属性是医院未来业务价值的创造和