新型医院信息系统设计

王士泉，侯志国，陈忠民，于慧杰，李 伟*

（1.东华软件股份公司，北京 100191；2.火箭军特色医学中心核辐射损伤与监测研究室，北京 100088）

0 引言

国家“十四五”规划中强调“高质量发展”，按照这一指导思想，着眼未来，医院信息化建设必将进入新阶段。在十几年的行业市场化过程中，多家医院在系统更新、更换过程中面临诸多挑战，更有由于数据资源难以迭代导致的遗憾，医院信息系统（hospital information system，HIS）能够稳定、持续地支撑医院发展是用户的最大利益所在，同时将医院的各类生产要素（人、财、物等）的基础信息进行统一管理，并把一个城市内（或区域内）医院中的各项实体业务进行全面数字化，打通物理世界和现实世界的沟通渠道，是医疗行业面临的新任务。尤其是2020年新型冠状病毒肺炎疫情这一世界性公共卫生事件为反思和推进医院信息化提供了历史性机遇。可以说，整个医疗卫生行业正处于一个压力、动力、支撑力和约束力都十分强劲的“力场”之中。用系统科学的理念指导医院信息化实践，以智能化技术手段实现医院数字化转型升级，是医院信息化所面临的重大机遇[1]。

HIS 发展至今，普遍存在的问题是集成困难，这是由长期以来“烟囱式”的医院信息化建设路径所致。尽管众多医院信息化厂商大力推广利用医院集成平台、信息平台、临床数据中心等方式来解决异构系统间交互及数据集成等问题，但是治标不治本，医院为打通各系统业务壁垒所花费的协调时间及开发费用依然高昂。

为了切实提高医院信息化水平，针对医院信息化的短板和不足，加快信息技术与医院业务的融合应用，实现医院“上云”，并让智慧和智能在医院信息化建设的过程中自然地融入HIS 的业务流程，成为新型HIS 的重要内涵。因此，“烟囱式”系统亟待终结，医院需要一个灵活、开放、可拓展的信息系统架构体系。本文提出打造新型HIS——医院操作系统（hospital operating system，HOS），其核心是把实体医院搬到云上数字空间中，完成医院实体元素的数字化映射及描述，构建全新连接，打通“烟囱式”系统间的壁垒，更好地整合医院内各类资源，提高医院运行效率[2]。

1 HOS 分层设计

HIS 已从解决医院数据采集和业务流程电子化，向业务场景全面IT 表达和全场景协作的数字化方向加速发展。因此，HOS 设计应采用服务化架构（如图1 所示），通过前端与后端分离，解放前端应用，从而提高开发效率、提升局部性能、降低运维成本。HOS通过数据平台、基础技术平台、开放平台的建设，规范业务平台和应用系统的开发，从而提高系统的稳定性和可扩展性，并促进应用生态繁荣发展[3]。

图1 HOS 分层架构图

1.1 数据平台

数据平台为上层业务提供数据支撑和数据存储服务，主要包括临床数据中心、资源数据中心、管理数据中心、基础数据中心、科研数据中心、患者数据中心及其他业务数据存储服务。

1.2 基础技术平台

基础技术平台包括各类基础技术组件，为业务平台提供开发框架、用户组织、日志审计、人工智能（artificial intelligence，AI）能力、业务引擎支撑。其中AI 能力包括智能视觉、智能推荐、智能语音、文本处理等基本能力，可利用医学知识和数据平台的数据不断训练并优化模型；业务引擎包括门户引擎、工作流引擎、搜索引擎、规则引擎、批处理引擎、分布式数据库引擎及流计算引擎等[4]。

1.3 业务平台

业务平台即系统的业务层，通过业务的解耦和服务的聚合，建设患者中心、临床中心、运营中心、决策中心、人力中心、资源中心、权力中心等。每个业务中心对业务流程、作业的最终表达是http 服务，通过提供http 服务实现业务层的对外开放。

1.4 开放平台

开放平台基于能力开放的要求，简化服务的复杂性，屏蔽系统之间的差异，形成平台级标准服务输出，在保证安全、稳定的前提下，支撑各种前端应用。开放平台是前后端分离的关键组件，其核心组件是应用程序编程接口（application programming interface，API）网关，支持服务注册、发布、订阅、下架的生命周期管理，通过服务路由、服务调度、服务鉴权、负载均衡、流量控制、服务降级、服务熔断，实现服务安全可控地开放，并支撑前端应用开发。开放平台同时也是一个API 市场，提供了开发者门户，为前端应用开发者提供开发指南、服务调试、服务分析等[5]。

1.5 前端应用

前端应用面向系统最终用户，基于不同的用户需求和业务场景，支撑不同的前端产品。前端应用包括HIS、CIS、EMRS、HRP、互联网医院、大数据应用等，这些前端应用的后台服务可以支撑第三方应用开发，例如医院的多个自助机厂商、多个互联网厂商等[6]。

1.6 生态服务

生态服务的价值在于可联合业内生态伙伴快速创新，打造新业务应用，具体包括：

（1）低代码开发平台M-Builder：可通过少量代码甚至不用代码就能快速构建各类应用系统，即时修改，马上生效；支持实时预览、快速部署，业务需求实现更简单，较传统开发方式效率提升5 倍以上。

（2）连接平台M-Linker：可在公有云、混合云、私有云环境下连接各类应用、数据、设备，帮助医院信息化建设技术人员设计、构建API 和实现应用之间的集成，从而实现低成本、快速、便捷的应用连接和集成，促成业务、流程及体验的一体化，并可轻松连接产业链上的行业应用、社会化应用，支撑业内的快速创新。

（3）应用市场M-Store：是应用的发布和订阅平台。用户可以发现应用、使用应用，开发者可以发布应用，包括Web 应用、移动应用。

（4）标准体系：用于项目技术体系的全面管理，保障项目技术在建设过程中的规范性、可控性及标准性，指导软件项目开发工作有序、有效开展，降低项目技术实施的风险和难度，确保项目实施进度。

（5）安全体系：安全设计主要包含6 个方面的内容，分别是物理与环境安全、主机与存储安全、网络安全、虚拟化安全、数据安全、应用安全。其中，应用安全包括验证用户身份、防止跨站请求伪造（cross site request forgery，CSRF）和跨站脚本（cross site scripting，CSS）攻击、防范结构化查询语言（structured query language，SQL）注入、防御分布式拒绝服务（distributed denial of service，DDoS）攻击。

（6）DevOps 管理：DevOps 是指通过自动化的工具协作和沟通来完成软件的生命周期管理。利用DevOps 管理工具，根据研发场景和能力诉求，形成从需求开始，到代码管理、持续集成、自动化测试，再到应用配置管理、部署交付、运维运营的IT 研发运营全生命周期的一体化平台[7]。

1.7 外部系统

外部系统实现基于监管需求的数据上报、异构系统的集成，通过集成平台实现协议的转换和数据标准的处理。其中异构系统通过Web Service 服务发布到开放平台，供前端应用系统使用。

2 HOS 技术架构设计

随着云计算的发展，将云原生技术体系应用于医疗信息化领域已成为行业的必然选择。此类技术架构的特点是采用开源堆栈（如K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、提高资源利用率的目的。

结合国内医院信息化建设及信息科技术人员实际情况，HOS 中的技术架构选型应满足如下要求：广泛使用、商业化程度高、技术成熟、稳定可靠、跨平台、开源可控，并且不违背信创国产化趋势，并可持续演进。HOS 技术架构图如图2 所示。

图2 HOS 技术架构图

2.1 中间件环境

中间件包括数据库（MySQL、Oracle、KingBase）、消息队列（RocketMQ、RabbitMQ）、内存缓存（Redis）、文件存储（FastDFS、MinIO）、对象数据库（MongoDB）、搜索引擎（Elasticsearch）等。研发人员通过技术选型，选择合适的中间件组件，容器化并提交到容器镜像仓库Harbor，数据层、服务层、API 网关可根据需要拉取容器镜像、启动容器、使用容器。

2.2 数据层

数据层主要包括事务型数据库（on-line transaction processing，OLTP）和分析型数据库（on-line analytical processing，OLAP）。

（1）事务型数据库：常用于交易数据存储和业务数据查询领域。常用的事务型数据库包括MySQL、Oracle 等。MySQL 是一种开源的关系型数据库管理系统（relational database management system，RDBMS）。Oracle 是老牌商用级数据库，具备成熟的企业级架构，可轻松应对各种复杂业务环境。

（2）分析型数据库：常用于数据查询和大数据分析环境中。其中Hadoop 是一个能够对海量数据以一种可靠、高效、可伸缩的方式进行分布式处理的生态环境。金仓分析型数据库（KingBase analytics DB，KADB）是符合信创要求的国产分析型数据库，在政府行业已有较多应用案例。

2.3 服务层

服务层采用主流的开发语言Java、PHP 均可，可使用Spring Boot 框架为基础框架。根据国内医院信息化行业现状及国产化的趋势，服务层属于核心系统的建设范围，不建议使用.NET 技术体系。部分服务层开发需要使用特殊语言，例如即时通信一般使用Nodejs 开发、AI 领域可以采用Python 开发。

2.4 API 网关

API 网关是关键部分。作为前后端的连接器，部署环境可以在基于Linux2.6+所有的操作系统中运行，或者直接拉取Harbor 的容器化镜像运行，建议使用K8S 集群容器化部署。API 网关的开发方案有3 种：

（1）使用Java 语言、Spring Boot 框架，设计开发环节应着重考虑网关的高并发处理、流量控制、服务熔断、服务自动实现消息队列和缓存服务。

（2）采用基于Golang 开发的API 网关，例如Goku API Gateway。如使用开源网关，需要自行处理消息队列和缓存服务。

（3）使用PHP+Symfony+Swoole+Hyperf+Lua 组合开发，其中，Swoole 可以实现调度协程，Hyperf 可以构建高性能网关，Lua 和Nginx 结合可实现负载均衡。

2.5 Web 服务端

Web 服务端采用主流的开发语言Java、PHP 均可，也可以使用.NET 技术体系。如果选择Java 语言，建议使用Spring Boot；如果选择PHP，可以使用Symfony。Web 服务端为Web 端和H5 客户端，前端框架使用Vue。Web 端客户端运行环境以Windows 为主，浏览器可为IE、Chrome。H5 客户端可选择iOS 或Android，浏览器可为WebKit。

2.6 移动端

移动端的使用场景和使用量都很多，以互联网连接方式为主，主要分为患者和医护人员2 类应用。

（1）患者端以客户端H5 和小程序实现的方式最多。客户端H5 通过Web 服务端开发实现，主要入口载体为微信、支付宝等具有支付能力的入口，小程序以微信为主流，可以使用微信Web 开发工具加WePY框架开发。

（2）医护人员端以原生应用为主，Android 环境使用Java 语言和Android Studio 开发，iOS 环境采用Swift 语言和Xcode 开发。

2.7 统一运维平台

统一运维平台以统一部署、统一监控、统一告警为目标，主要实现2 类业务目标：服务器中间件的运维管理和应用业务系统日志监控与预警。

（1）服务器中间件的运维管理使用Prometheus、Grafana 和AlterManager 实现。其中Prometheus 是一个开源的服务监控系统和时间序列数据库；Grafana是一个开源的度量分析与可视化平台，可实现多源数据查询、分析、可视化处理以及配置告警；AlterManager 主要用于接收Prometheus 发送的告警信息，支持丰富的告警通知渠道，能够做到告警信息的去重、降噪、分组、策略路由。

（2）应用业务系统日志监控与预警使用Logstash、Elasticsearch 和Kibana 实现。其中Logstash 是一款开源的数据收集引擎，具备实时数据传输能力，能够将数据信息从管道的输入端传输到管道的输出端；Elasticsearch 是一个分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据；Kibana 是一个为Logstash和Elasticsearch 提供日志分析的Web 接口，可使用其对日志进行高效搜索、可视化、分析等各种操作。

2.8 其他应用

其他应用包括自助机应用、物联网应用和第三方应用，HOS 的生态环境开发者可通过开放平台订阅服务实现相应的产品功能。

3 HOS 应用架构设计

HOS 的应用架构从业务层面可划分为医院数智底座（应用支撑平台）、基础核心业务、综合业务工作站、移动智能、医疗管理、运营管理、数据中心、科研教学、区域协同、应急部署共十大模块。其中，基础核心业务包括信息平台、数据分析与决策支持，患者管理，临床诊疗，患者服务，药事管理，医技辅助6 个业务功能。HOS 应用架构图如图3 所示。

3.1 医院数智底座

3.1.1 统一医学术语体系

医学术语是临床诊疗过程中的重要生产要素，全院的医学术语统一、规范、精细化表达是保障医疗数据质量的前提。HOS 应采用统一医学术语体系，打破医院各IT 系统的信息交流障碍，为后续科研教学及临床研究做好底层支撑，并能够在临床诊疗的过程中，支撑临床人员能够精细化诊断、选择最优治疗方案、避免误诊漏诊、有效监管临床诊疗行为的安全性。同时，打造医学术语体系知识库系统，支持通过智能检索、直播、文章科普、病例讨论等方法聚合传播医学知识，内容涵盖疾病、药品、检查、检验、护理、手术等医学相关领域。

3.1.2 知识图谱

采用自然语言处理（natural language processing，NLP）和知识图谱技术，帮助用户快速、准确检索知识，为医疗机构提供专业医学内容、版权合作等基础服务，横向打通现有互联网医院的业务场景，助力医生开展临床科研及患者宣传教育，满足不同群体、不同业务场景对医学知识的需求[8]。

3.1.3 AI 基础设施

通过建设AI 基础设施，将成熟的AI 技术能力赋能给临床。包括以下几个方面：

（1）支持利用光学字符识别（optical character recognition，OCR）技术实现纸质单据内容的电子化。

（2）具备NLP 技术，可提供电子病历后结构化服务，支持医学常见的中文命名实体识别及关系提取。

（3）提供医学影像识别、临床诊断辅助等医疗服务，为早期筛查、诊断、康复、手术风险评估等场景提供基础技术支撑。

（4）支持语音识别服务，可将语音识别为文字，适用于手机应用语音交互、语音内容分析和呼叫中心智能客服等多种场景。

（5）支持建立疾病风险预测模型，通过机器学习算法，构建患者的预后预测模型，为患者的治疗提供帮助。

3.1.4 统一用户管理

以用户为中心汇集各业务系统中的工作信息，以数据来驱动用户完成相应的工作，实现各业务系统间的无缝衔接操作。

3.1.5 统一生产要素管理

（1）组织及人员数据治理。根据医院愿景及年度工作目标，结合医院学科专业的分类，参照国家卫生健康委下发的诊疗目录及国家人力资源和社会保障部下发的政策文件，梳理并规范医院的组织架构及人员档案信息的全息视图，内容包含组织架构，人员职务、职称、技能、排班等相关数据。

（2）土地及房屋数据治理。提供医院土地及房屋利用情况的数据梳理，将位置信息进行更准确的表示，为围绕地理位置开展的业务工作提供数据支撑，主要包含土地信息、土地使用规划信息、房屋及建筑物登记信息、房间信息、床位信息等。

（3）设备要素数据治理。提供医院的关键医疗设备、关键移动医疗设备、特种设备等相关数据的信息化表示，并对每个医疗设备能开展的项目进行表示，实现对设备的运行监控，主要包括设备运行监控、设备院内租赁监控、设备维修、效能分析等。

3.1.6 业务流程管理

通过流程节点的原子化，将业务流程转化成作业单元，即最小颗粒度的流程节点，然后将资源消耗的情况绑定到流程节点上，以便于通过流程化的表示，揭示成本的发生和形成过程，并对影响成本的各种因素条件施加影响和管控，以实现全院全面成本的管控目标。通过业务流程的管理，实现3 个溯源和2 个对比，即人工的溯源、资财的溯源、设施的溯源，流程间消耗的对比、流程间执行效率的对比。

3.1.7 权力系统

通过权力系统介入应用系统的运行，按照医院管理职责的要求，对系统的配置进行干预调整、确认，在系统上线、用户权限、产品配置、基础数据、接口对接等发生变化时，能通过权力系统进行有序审批、监管、控制，以支撑医院完成数据治理的目标。

3.1.8 IT 监管体系

从以下6 个维度建设IT 监管体系：

（1）基础资源监控：主要从物理层、虚拟化监管、系统层、网络层、数据层、中间件层等层面进行监控；

（2）应用监控：主要从应用系统日志分析、医疗应用系统对象、特色应用（在线人数、访问量等）等角度进行监控、调度；

（3）业务运行监控：主要从数据库作业、医保接口、病床周转率、门诊量、互联网接口、业务系统服务质量等方面进行监控、管理，保障业务应用系统的平稳运行；

（4）医疗服务监控：主要从医疗服务质量、互联网医疗服务等方面进行监控；

（5）操作监控：主要对访问数据库、服务器、网络设备等操作行为进行监控；

（6）安全监控：根据等级保护标准对服务器等各类安全策略实时监控，发现安全策略违规实时告警。

3.1.9 统一项目管理体系

以项目为原点，对医院所有的项目从立项验收结题、项目招投标、合同管理、项目预算、项目发生过程的记录、项目评价等环节进行集中管理，按项目管理的重点将体系划分为项目级、过程级和人员级3个层次，并通过这三者的集成管理和相互促进，不断提高项目的执行质量和效率。

3.2 基础核心业务

基础核心业务（HIS、EMRS、LIS 等）是医院信息化治理的重点，通过对医院内部业务流程的不断梳理，满足系统互联互通和数据共享需求，为医院运行提供基础的信息化支撑。

3.3 综合业务工作站

为院内各角色用户建立各自的工作站，通过平台主动推送的方式，将与用户相关的各类指标及工作信息呈现给用户。用户只要登录工作站，就能及时了解当前的工作状况，并根据相关指标数据及时调整工作方式和内容。

3.4 移动智能

通过移动通信技术来提供医疗服务和信息，包括实现超声检查的移动化及远程实时操控功能，实现远程会诊的高清视频传输及实时动态检查信息同步，实现手术教学的高清视频传输及实时体征监测数据同步等。

3.5 医疗管理

依据医疗质量与安全规范，建立检验、检查、用药、用血、危急值等闭环，结合质量规则校验、流程规范，进行统计分析并反馈，从而改善医疗质量，降低医疗风险，提高流程效率。

3.6 运营管理

建立以财务为核心，预算为控制主线，物流、资产、药品、人力、合同等为运营基础，成本为数据分析中心，绩效为导向的一体化运营管理模式，实现物流、资金流、信息流的全面一体化融合，最终为医院卓越运营、精益管理提供全新的管理手段。其中运维管理模块提供对信息技术保障部门的建设管理支持，包括IT 基础设施的运维、终端设备的运维、应用软件的运维、科室需求处理、信息项目的建设等内容。

3.7 数据中心

为深入探索、挖掘结构化医学数据和非结构化文本医学数据所蕴藏的医学规律和重要医学知识与证据，提供技术支撑环境，帮助科研者“多、快、好、省”地开展临床研究。

3.8 科研教学

利用系统提供的海量数据资源，对医疗教学、科研管理等应用进行支撑，全面管理人员及科研、教学工作中的各种事务。

3.9 区域协同

通过区域协同建设，实现医院下辖多院区之间的数据、信息、资源的全面共享和管理，实现患者服务的连续化和综合化，实现总部统一决策支持与决策分析，加强对各分支机构的管控。

3.10 应急部署

HOS 支持云部署，在低等级医院，或者是疫情应急保障的情况下，5G 网络联通后几小时内就可以快速完成部署，适用于应急医院、应急医疗队等各级医疗救治机构[9]。

4 HOS 物理部署架构设计

HOS 采用两地三中心环境部署，如图4 所示。其中，主节点机房承担核心业务，备节点机房在主节点机房发生故障时接管业务，也可以承担统计分析类业务，主、备节点对外通过域名提供服务，节点的切换通过更新域名系统（domain name system，DNS）信息完成。当主节点机房和备节点机房都发生故障时，异地备份节点机房接管业务。

图4 HOS 部署架构图

（1）Kubernetes 集群：用于部署Web 应用、Redis缓存服务、Kafka/RabbitMQ 消息队列及工具类服务，可动态伸缩扩容。Kubernetes 集群采用Federation V2架构，管理3 个机房节点的Kubernetes 集群，3 个节点都可对外提供服务。一般情况下，主节点Kubernetes 集群对外提供服务，剩余2 个Kubernetes 集群作为备份节点。

（2）数据库集群：数据库采用传统架构，每个机房部署1 套Oracle，采用4 节点应用集群（Oracle RAC），数据同步采用Data Guard 方案。

（3）数据库备份：数据库备份采用本地备份+异地备份。本地备份采用同步备份方式，异地备份采用异步备份方式。

（4）服务监控：3 个节点均部署Prometheus 服务组件，每个节点内部部署2 台Prometheus，做双机的同时互相监控。Prometheus 集群采用Thanos 架构，采用开源可视化工具Grafana 提供监控视图。

（5）安全管理：运维采用虚拟专用网络（virtual private network，VPN）+堡垒机；主机、数据库、应用系统定期进行漏洞扫描，并安装防病毒软件；内外网严格隔离，如果需要内外网互联须采用隔离网闸；使用专业日志审计和数据库审计软件；操作系统、数据库、业务系统账号密码由专人管理，并定期更换；应安排专人每日、每周、节假日巡检，并提交相关巡检报告。

5 HOS 开发环境设计

HOS 软件开发的代码库使用GitLab。GitLab 是一个自托管的Git 项目仓库，拥有与Github 类似的功能，能够浏览源代码、管理缺陷和注释，并提供代码片段收集功能，可以轻松实现代码复用，便于日后有需要的时候进行查找。

代码构建打包、代码质量检查、自动化测试、自动化部署等步骤可采用Jenkins、PipLine、Sonar、Jmeter、JFrog 开源工具组合，建立自动化测试框架，实现持续集成与自动编译部署。

项目管理方面建议采用商业化的项目管理软件，如禅道等工具，其具有需求管理、任务管理、bug管理、缺陷管理、用例管理、计划发布等功能，可助力构建软件全生命周期管理环境。

6 结语

医疗行业的高质量发展对下一阶段的医院信息化建设提出了新的挑战，只有通过重构HIS 架构，才能有效支持医疗行业的全面数字化转型。采用云原生技术体系研发HOS 技术架构，可为医院数字化建设打下坚实的基础。但各家医院面对的实际情况各不相同，应根据自身情况具体分析，采用适宜的技术路径，在开放、可扩展的前提下，确保核心系统稳定可靠[10]。本文提出的技术架构对设计新一代的数字化医疗产品具有一定的参考价值。但本项目未进行HOS 开发管理、系统评估等，下一步须深入研究。