新一代医院信息系统（NGHIS）设计（1）——体系结构篇

一、前言

我国的医院信息化建设，始于上世纪80年代中末期，经过90年代的*繁荣（ye man）发展和本世纪初的政策扶持、引导规范与市场培育，历经30多年的发展，目前已经遇到瓶颈。其中最根本的原因是系统架构问题，由于缺乏系统互操作标准，大多数HIS厂商之间的系统互连互通成为困扰行业用户的头疼问题；同时，几乎所有HIS厂商都走大而全的系统架构路线，大有HIS包罗万象之势，随着系统的“生长”和研发人员的流动，系统维护升级的难度越来越大，响应用户需求变更的周期越来越长，系统变更的风险越来越高，最终落得产品实施效果差、用户满意度低、甲乙双方技术人员两头受气的尴尬境地。

新技术的出现，为医院信息系统突破瓶颈带来了福音。基于医院信息平台的医院服务总线，采取松耦合的方式，重新设计医院信息系统的各业务功能，将无所不包的传统HIS解构成一个个小而精、可以独立开发部署、系统间基于服务总线标准实现互连互通与互操作的专业子系统，是我们新一代医院信息系统（Next Generation Hospital Information System, NGHIS）的设计思路。

本文是新一代医院信息系统（NGHIS）设计的开篇之作，向读者介绍系统的架构思路，后续将陆续送出各分系统的深化设计方案。

二、系统总体架构

（一）总体架构

新一代医院信息系统（NGHIS）划分为电子医嘱系统、电子病历系统、门诊系统、住院系统、医技系统、药品管理系统、病案管理系统、划价收费系统等独立的子系统，通过医院服务总线（HSB）实现松耦合的系统互联，并与医院基础集成平台和健康医疗云平台实现互连互通与互操作。医院管理、医疗质控、临床决策支持、辅助管理决策等应用，既可以针对医院服务总线开发，作为独立的应用系统在院内部署，也可以针对健康医疗云平台的开放接口与开发环境进行开发并在云端部署。

其中，门诊、住院和医技系统，还可以进一步分解成业务管理和不同临床岗位的工作站，比如，门诊系统包括导医、预约、挂号、分诊、叫号等业务子系统，而门诊医护工作站包括门诊医生工作站、急诊医生工作站、门诊护士工作站等子系统；医技系统则进一步细分为实验室检验、放射线检查、超声检查、心电图、病理等专业的业务流程管理和不同的技师工作站以及诊断报告工作站。

（二）医院服务总线（HSB）

医院服务总线（HSB）是根据医疗服务的行业特性，为满足医院管理与医疗服务协同需要进行定制的企业服务总线（ESB），医院信息系统之间、医院信息系统与平台（医院基础集成平台和健康医疗云平台）之间均通过医院服务总线（HSB）实现系统之间的数据交换和服务协同，实现系统与系统之间的松耦合，从而提高各系统的独立性和可维护性。同时，医院服务总线（HSB）也为将来需要开发或采购的系统，制定了开放、标准的系统交互要求，为新系统的设计开发与产品选型、兼容性测试提供指引，大大提高医院系统间的互连互通与互操作水平，避免形成新的信息孤岛或信息烟囱。

（三）基础集成平台

基础集成平台实现统一用户管理、统一用户认证、统一授权管理、集中配置监控、单点登录等信息系统的公共基础设施与功能，减少新应用程序开发所需的基础共性重复工作量，简化运维管理，改善用户体验。此外，还专门针对医疗机构及医疗服务的信息化应用，提供主数据（机构、科室、人员、患者、物料、术语等）管理和主索引（机构主索引、患者主索引、术语主索引、医务人员主索引）服务。

（四）健康医疗云平台

健康医疗云平台是基于云计算技术架构的医院信息平台的升级扩展，采用多租户技术、弹性架构和大数据解决方案，对内通过医院服务总线与医院信息系统互联，对外与区域人口健康信息平台互通，形成医院及医院集团（或医联体/医共体）内部的医疗数据中心，汇聚运营管理、临床服务、医疗文档和健康档案等服务功能与数据，为医院开展医疗、教学、科研、健康管理以及辅助决策支持提供支撑。

健康医疗云平台可以作为医院的私有云部署在医院内部，满足医院或医院集团的业务协同与管理需要，也可以作为行业云部署在区域卫生信息数据中心，为区域内的医疗机构信息系统（如基层医疗机构管理信息系统、公共卫生系统等）提供公共服务，实现更好的互连互通、业务协同与数据共享效果，也可以部署到公有云环境，成为互联网医院的信息系统基础设施。

健康医疗云平台负责医院内部信息系统与区域人口健康信息平台、费用结算平台等外部的统一接口，使得医院内部业务系统与外部系统之间的数据交换与业务协同实现标准化和透明化，尽量减少院内业务系统受到外部系统（如医保结算）接口变化的影响。

三、系统设计思路

（一）HMIS重构

传统的包罗万象的HMIS需要按用户专业分工和使用场景重新划分系统边界，做到子系统的高内聚和低耦合。面向临床医务人员提供专业、集成、易用的医护工作站，一站式解决临床服务过程中的医嘱处理、病历（护理）文书书写、健康档案（影像、报告）调阅、后勤物资供需链等业务需求；为医技部门提供与电子医嘱、电子病历、物资供应链、收费等系统联通的医技系统，由医嘱（申请单）驱动医技服务事项，并在医技服务过程中形成电子病历（报告）及费用信息，实现医嘱闭环管理；后勤辅助及运营管理部门，则使用以供应链管理、运营管理与财务管理为核心的医院资源计划系统（HRP），实现精细化、信息化管理；教学、科研及职能管理部门，使用更加专业化的科研管理、质控管理等业务系统。

（二）健康医疗云平台

健康医疗云平台围绕临床数据资源库（CDR）、运营数据资源库（ODR）、临床文档（CDA）以及电子健康档案（EHR）的信息采集、数据管理和跨机构的业务协同与数据共享提供共性支撑，实现数据标准化清洗、健康大数据挖掘、辅助决策支持与人工智能服务等先进功能。

1.临床数据资源库（CDR）

临床数据资源库包含从事医疗服务所产生或记录的会诊、观测、检查、诊断、治疗、评估、病历等客观及主观数据，既有结构化的数据，也有非结构化的数据。

2.运营数据资源库（ODR）

运营数据资源库以记录医院医疗服务与管理产生的费用（收入、支出）、成本（时间消耗、资源消耗）、效率以及患者满意度等运营数据。

3.临床文档（CDA）

医疗服务产生的内容与格式合一的医疗护理文书，以非结构化或半结构化的形式存在，根据病种、人群特征进行分类标注，便于科研病例检索，并建立全文检索索引。

4.电子健康档案（EHR）

以服务对象个体为中心，建立个体从出生到死亡的所有健康数字信息，通过区域人口健康信息平台的CDA文档交换和健康医疗云平台的居民电子健康档案管理工具，采集包括公共卫生、医疗服务、健康体检、专项筛查、监护仪器及穿戴设备等个人健康数据，并为健康档案的访问授权、共享、调阅提供支持。

5.健康大数据

通过对CDR、ODR、EHR和CDA的数据挖掘，以发现新的线索或证据，用于临床决策支持和辅助管理决策支持。

6.人工智能

通过自然语言理解技术，对非结构化的CDA及CDR进行后结构化处理，并采用机器学习算法，不断丰富知识库，优化人工智能辅助临床决策支持的效果。

（三）互连互通与互操作

院内各系统均遵循医院服务总线（HSB）的业务协同标准，通过医院服务总线（HSB）实现系统间的数据交换与业务协同，同时，通过医院服务总线实时向健康医疗云平台推送事件消息，使得云平台的临床数据中心可以实现实时的数据更新。

各系统基于医院基础集成平台实现统一用户认证、统一授权管理、统一配置监控和单点登录，并使用医院基础集成平台的主数据与主索引服务。

（四）数据共享与业务协同

1.数据共享

院内各系统共享医院基础集成平台的主数据（包括人员、机构、患者、物料、术语、数据元及数据集标准等），通过医院服务总线的主索引服务实现对主数据的查询、注册与更新。各系统需要在系统内部单独保存主数据副本时，应该通过订阅或者定期同步的方式，从基础集成平台同步主数据，更新主数据应该通过调用平台的相关主索引服务进行，尽量避免在系统内部独立维护更新副本的主数据记录。

健康医疗云平台的数据中心，汇聚了各业务系统的关键业务数据（主要包括ODR、CDR和CDA），这些数据可以被各业务系统共享查询和调阅。

EHR则对关注的服务对象（患者）的健康档案进行动态跟踪管理，通过医院服务总线自动汇聚患者接受院内医疗服务的各类电子健康档案，如电子病历、医学影像报告、实验室检查等，同时，EHR还通过区域人口健康信息平台的互联互通，订阅该患者在其他医疗机构产生的医疗文档，动态更新患者电子健康档案，保持健康档案记录的连续性和完整性，避免形成“死档”、“断档”。

2.业务协同

医院内部各系统之间的业务协同均基于医院服务总线（HSB）的异步消息传递实现；跨院的业务协同操作，基于远程医疗协同平台、分级诊疗服务平台、急诊救治平台的开放标准，由医院服务总线统一封装后对院内系统开放。

四、主要技术路线

（一）中间件选型

医院服务总线（HSB）原则上不依赖于特定厂商的ESB中间件，为了降低用户采购成本，本项目至少支持开源社区的Mule ESB，并尽可能兼容JBoss ESB和Ultra ESB，消息中间件优选Apache的ActiveMQ。

（二）开发工具

医院服务总线、健康医疗云平台选择平台支持最广泛，社区最活跃的Java开发语言环境；医院业务系统客户端可以是B/S、C/S、C/S/S等程序架构，建议人机交互频繁、需要进行硬件资源操作的子系统，选用Windows桌面程序，其余尽可能选用H5开发以便支持更多的终端类型。

医院服务总线和健康医疗云平台，采用SpringCloud的云服务架构，向应用开放基于http/JSON/XML的RESTful接口、WebService/RPC接口和JMS/MQ接口。

Windows桌面程序优选.Net C#，其次是Visual Basic、Delphi、C++Builder、PowerBuilder等可视化开发工具。

（三）数据库选型

考虑到数据量大小与系统伸缩性、运行平台广泛性、用户使用习惯、开发与运维便利性等需要，选择9i以上版本的Oracle RDBMS作为主要目标数据库，MySQL/SQL Server作为第二选择。对于电子病历、个人健康档案、医疗文档、图文报告等半结构化或非结构化和关联关系低的内容以及访问并发量大、更新频率低的内容，采用NoSQL存储，NoSQL优选MongoDB，其次是HyperTable或HBase。

（四）报表工具与数据仓库

考虑到大部分用户有数据报表输出的个性化需求，需要引入一个功能强大的数据报表工具，能够实现形式多样的统计报表与图表的定义、发布和授权访问。强烈建议增加数据仓库系统，使得OLAP数据库与OLTP数据库分离，提高数据挖掘能力。

（五）全文检索服务

知识库、医学术语、医嘱、病案等都需要通过全文检索支持基于关键词的快速搜索改善用户体验，本项目将采用开源社区的ElasticSearch建立全文检索搜索服务。

（六）PaaS架构

云服务及Web应用计划使用Docker容器进行应用开发测试和分发部署，简化服务及应用的测试与部署。

五、计划展望

本项目计划分三个阶段提交：

第一阶段目标是提供一个业务无关的基础集成环境，实现集中用户管理、统一用户认证、集中用户授权、集中应用配置和单点登录。交付内容包括基础集成平台（含用户管理中心、集中授权、集中配置和单点登录）、用户集成桌面工具（含单点登录、即时消息和应用配置）和医院服务总线基础设施，并提供一些经过集成、能对用户IT运维带来便利的工具（如运维工单系统、电子邮件系统、论坛系统等）。可以满足一些存在严重信息系统孤岛或烟囱的医院改善用户体验和加强IT运维管理的需要。

第二阶段目标是提供完整的医院服务总线和健康医疗云平台标准与实现，以及满足基层医疗机构和二、三级医院业务服务需要的新一代医院信息系统，包括电子医嘱、划价收费、门诊业务、住院业务、医技业务、药品管理、病案管理、电子病历等。

第三阶段目标是基于医疗健康云平台的数据资源库，开展临床决策支持和辅助管理决策支持，同时实现与更多的第三方管理信息系统和临床信息系统集成，为用户提供满足互联互通与互操作要求的更多应用系统。