新⼀代医院信息系统（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需要按⽤户专业分⼯和使⽤场景重新划分系统边界，做到⼦系统的⾼内聚和低zo0sko0icom性
耦合。⾯向临床医务⼈员提供专业、集成、易⽤的医护⼯作站，⼀站式解决临床服务过程中的医嘱处理、病历（护理）⽂书书写、健康档案（影像、报告）调阅、后勤物资供需链等业务需求；为医技部门提供与电⼦医嘱、电⼦病历、物资供应链、收费等系统联通的医技系统，由医嘱（申请单）驱动医技服务事项，并在医技服务过程中形成电⼦病历（报告）及费⽤信息，实现医嘱闭环管理；后勤辅助及运营管理部门，则使⽤以供应链管理、运营管理与财务管理为核⼼的医院资源计划系统（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接⼝。淘宝10.11事变
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运维管理的需要。
第⼆阶段⽬标是提供完整的医院服务总线和健康医疗云平台标准与实现，以及满⾜基层医疗机构和⼆、三级医院业务服务需要的新⼀代医院信息系统，包括电⼦医嘱、划价收费、门诊业务、住院业务、医技业务、药品管理、病案管理、电⼦病历等。
第三阶段⽬标是基于医疗健康云平台的数据资源库，开展临床决策⽀持和辅助管理决策⽀持，同时实现与更多的第三⽅管理信息系统和临床信息系统集成，为⽤户提供满⾜互联互通与互操作要求的更多应⽤系统。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议