基于全民健康信息平台的死亡管理系统建设方案
一、项目概述
(一)项目名称
xx市基于全民健康信息平台的死亡管理系统项目
(二)建设单位
xx市卫生和计划生育局
(三)建设目标
1.总体目标
围绕xx市医疗卫生事业发展,全市人民群众健康水平不断提高的大局,立足现有资源条件,着眼未来医疗卫生服务能力、服务效率、服务水平、服务质量的全面提升,建成xx市互联互通、功能完备、标准统一、安全可靠的区域卫生信息化体系。
以“4631”为整体框架,以深化基层医疗卫生机构综合改革为基础,以医疗优质资源共享协同为手段,以健康服务产业作为政府职能的有效补充,以信息化为支撑,以居民健康管理为核心,按照省人口健康信息平台总体规划,按照《省统筹区域人口健康信息平台应用功能指引》要求,规划建设xx市基于全民健康信息平台的死亡管理系统,实现人人享有电子健康档案,医生、居民有效共享利用健康信息,支撑公共卫生机构、医院、基层医疗机构、卫生行政机构提供方便、高效、优质的医疗卫生服务。
2.具体目标
- 建设xx市基于全民健康信息平台的死亡管理系统,实现市、县、乡镇三级医疗服务网络全覆盖,打通各医疗卫生机构之间的业务鸿沟,卫计局与医疗卫生机构的管理鸿沟,以及居民与医疗机构之间的健康鸿沟,实现线上资源的互联互通互认,线下服务支撑的高速高质高效。
- 建设基于平台的区域医疗协同应用,构建以居民为中心的智慧医疗新模式,建立预约、转诊通道,实现医疗卫生区域化服务模式,发挥优势医疗资源的辐射作用,逐步形成“健康进家庭、小病在基层、大病到医院、康复回基层”的分级诊疗格局。
- 建设面向管理者的卫生综合管理应用,对真实客观的行业生产数据进行整合和分析挖掘,建立多维度指标体系,推动卫生综合管理指标展示与分析应用建设,并逐步构建动态、科学的医改监测评估模型。
- 建设互联网+健康服务应用,为居民提供全生命周期的健康相关信息,实现居民自我健康评估,目标人群的自我健康管理,获知医疗资源信息、健康知识和健康咨询。
3.分期目标
具体目标分两阶段实现,具体如下:
一阶段:
- 升级全民健康信息平台,建设死亡信息管理系统,接入全市6家市级医院、25家乡镇卫生院、11家社区卫生服务中心和605家村卫生室,实现二、三级医院与基层医疗卫生机构相关数据的统一采集、统一存储、统一利用,打通xx市医疗服务网络信息互联的通道。
- 建设基于平台的区域影像诊断中心、区域检验中心、区域心电中心、双向转诊系统,依托市人民医院为诊断中心,辐射25家乡镇卫生院和11家社区卫生服务中心,建立分级诊疗机制,提高基层服务能力和服务水平。
- 依托全市医疗行业真实客观的生产数据,建设区域综合管理平台,建立医疗服务与质量的业务监管、基本公共卫生服务监管和基本药物监管指标体系,进行统计分析及动态展示,辅助领导决策。
- 建设互联网+健康服务应用,在医院开展互联网就医服务、互联网健康服务和互联网诊疗服务应用的部署,初步实现互联网诊疗、居民健康档案的自我管理等互联网+健康服务。
二阶段:
- 完善综合管理平台,建立医疗保障监管、卫生资源监管两大类指标体系,建设监控驾驶仓应用,进行统计分析及动态展示,辅助领导决策。
- 完善区域业务协同应用,建设远程联合门诊、远程会诊等应用,促进市医院与基层医疗机构之间的业务协同。
- 利用移动互联网技术建设互联网家医服务应用,落地家庭医生签约制度。
(四)建设内容
xx市基于全民健康信息平台的死亡管理系统项目将覆盖全市各级卫生计生机构,构建统一数据交换平台,建立居民电子健康档案、电子病历和全员人口、死亡人口四大数据库,整合现有卫生信息资源,形成信息高度集中的医疗卫生监督、管理和服务的信息网络系统。为了更好的解决项目中遇到的问题,快速优质的完成本项目,我们以科学技术的态度、方法和知识作为手段,以创造、创新和集体协作精神为宗旨,把工程施工上的具体问题作为任务加以分解,组织全体技术人员并身体力行地予以合理的解决。
(五)项目设计方案
建设原则
1.实用性和接口良好性
以业务需求为主导,完整地实现系统预期功能为目标,并充分考虑发展的需要来确定系统规模。系统能够提供比较良好的接口,便于系统的维护与修改,同时可以比较方便的进行业务流程的修改。
2.成熟性和先进性
系统结构设计、系统配置、系统管理方式等方面采用国际上先进同时又是成熟、实用的技术。
3.开放性和标准化
在设计时,要求提供开放性好、标准化程度高的技术方案;设备的各种接口满足开放和标准化原则。
4.可扩充和可管理性
所有系统设备不但满足当前需要,并在扩充模块后满足可预见将来需求,如带宽和设备的扩展,应用的扩展和办公地点的扩展等。保证建设完成后的系统在向新的技术升级时,能保护现有的投资。
整个系统的设计应易于管理,易于维护,操作简单,易学,易用,便于进行系统配置,在设备、安全性、数据流量、性能等方面得到很好的监视和控制,并可以进行远程管理和故障诊断。
5.集中性和统一性
所有系统满足管理的集中性和设计的统一性,以便在设计、开发、实施、维护各阶段易于管理和掌控。
6.完整性和系统性
所有系统在设计是应考虑到完整性和系统性,满足各条线业务的需求,高度符合日常业务开展的完整性和系统性。
(六)系统架构
1.总体架构
本次项目的整体架构设计按照原有信息平台的整体架构,主要实现医务人员及时获取必要的诊疗信息,以支持高质量的医疗服务;公共卫生工作者能全面获悉居民健康信息,高效开展疾病预防、控制和健康促进工作;居民能掌握和获取自己完整的健康资料,参与健康管理,享受持续、跨地区、跨机构的医疗卫生服务;卫生管理者能动态掌握卫生服务资源和利用信息,满足卫生行政、卫生监督管理工作需求,实现科学管理和决策。
信息交互平台,也是跨市业务数据交换的支撑平台。信息平台可提供基本业务处理和应用之间的数据交换,为业务联动类应用和辅助决策类应用提供支撑。数据交换平台为整个信息平台的原始数据来源提供技术基础和保障。通过信息标准、交换原则的制定,对业务系统提供标准的信息交换服务,确保数据交换过程的安全性、可靠性,实现区域内的数据自由、可靠、可信的交换,为实现区域内部各卫生机构之间的信息资源共享以及与医保中心、民政部门等外部机构之间的信息资源交换共享提供支持。
信息平台是全市卫生数据的统一管理与整合平台。平台负责对全市所有居民身份的唯一识别及数据统一存储与交换形式的制定和管理;对区域所有卫生信息进行抽取和整合,通过数据仓库,为各级领导决策提供各种数据分析利用资源。
2.功能架构
本项目的功能架构基于居民死亡登记信息系统建设:
3.网络拓扑
4.部署架构
说明:
本项目涉及到应用系统即部署,对于新建应用系统部署在数据中心处理区的应用服务器之上,依据相关应用系统的业务量申请政务云服务资源。
本项目中与其他单位对接,实现数据交互和共享技术路线
(七)体系架构
采用面向服务的体系结构(SOA)的技术路线。在SOA体系结构中,服务即可以是传统的基于Web Service的服务,也可以是目前面向互联网的基于REST的轻量级服务。
1.技术框架图
展现服务层
展现服务层由企业信息门户(EIP)中可配置、可重用的门户组件(Portlets)组成,用于支持门户应用的开发;支持人机交互组件、网页组件、报表组件、实现对不同需求服务的支持,并提供丰富的客户端展现方式以及移动客户端的展现支持。在基于信息平台的应用中,健康档案浏览器、居民健康公众服务等主要在展现服务层体现。
2.服务组合层
服务组合层通过对下层的访问服务、数据服务、业务服务的编排来实现,流程编排的规则在该层内定义,通过服务的编排组合就可以快速搭建出新的业务应用系统。在信息平台中,健康档案调阅服务、健康档案协同服务等服务主要在服务组合层体现。
3.业务服务层
业务服务层定义那些可重用的业务处理过程,用于支持复合的业务处理需求。这层定义的业务处理过程服务可能是单个原子事务的无状态处理操作服务,也可能是多个业务应用或异步服务之间交互的有状态处理操作服务。业务服务层之上的开发者无需知道具体某项业务的逻辑处理过程。在信息平台中,注册服务、健康档案存储服务、健康档案管理服务等服务主要在业务服务层体现。
4.数据服务层
数据服务层定义的服务支持把异构的、孤立的企业数据转变成集成的、双向的、可重复使用的信息资源。数据服务通过访问服务层以统一的方式访问企业的所有数据,数据服务层之上的开发者可以集中精力处理数据的加工问题,而不必关注访问不同来源的数据的实现细节。在信息平台中,健康档案整合服务、数据仓库等主要在数据服务层体现。
5.访问服务层
访问服务层实现与底层数据资源、应用资源的通信功能,使用通用标准接口,定义整合企业信息资源(数据资源与应用资源)的各种访问服务。访问服务屏蔽了企业信息资源(现在的或未来的)的技术和实现方式,访问服务层之上的开发者无需知道数据的位置、类型以及应用程序的编程语言等。
6.消息交换和传输
服务间的消息交换和消息传输贯穿各个服务层。消息交换和传输可以采用企业服务总线ESB。服务间的消息交换需要基于通用的交换标准和行业的交换标准。消息传输层可以提供HTTP、HTTPS、SMTP、JMS、FTP等通用的传输协议支持。
7.安全与服务管理
安全管理和服务管理贯穿各个服务层。在信息平台中,信息安全与隐私保护主要在安全与服务管理层体现。
服务安全管理支持认证和授权、不可否认和机密性、安全标准等。基于Web服务的安全管理遵循Web服务规范中WS-Security规范。
8.总体技术架构
提供一个以健康档案数据为核心的开发和运行平台,可以使用此平台快速地定制、开发和部署信息平台项目,来满足日益增加的区域电子健康信息共享与管理需求。因此平台构架设计的目标是建立一个能够容纳管理个人健康档案的可扩充的、开放的、可持续发展的构架,其包括以下方面:
1.管理业务的扩充:能够围绕电子健康信息建立扩展新的健康管理业务,从公共健康管理的角度来看可以建立不同的疾病监控系统,从医疗服务者的角度看,可以查询、调用以不同组织方式呈现的个人电子医疗档案。
2.存储健康信息的扩充:能够在系统中增加新的健康信息种类的存储。能够根据每种存储信息的特点对信息内容进行优化,但通过统一的接口对新的健康信息可以和已有的健康信息进行查询、调阅。
3.接入方式的扩充:电子健康档案信息中心面对的数据源和用户是各个医疗机构及个人用户,所以能够接纳各种现有的和未来的应用系统的数据上传及使用相当重要。中心构架需要能够扩充对各种接入方式的支持。
4.系统容量的扩充:区域电子健康信息中心是一个数据量庞大的信息系统,在设计时需要考虑对数据存储容量的横向扩充。
5.系统处理能力的扩充:随着全员人口库、电子病历、健康档案数据库的使用者的增加,系统将承受大量的服务请求压力。系统将使用分布式服务和集群等方式实现系统处理能力的扩充。
为了实现上述的要求,满足本项目信息化的基本需要,同时还要满足全民健康信息化持续性发展的需求,因此将信息平台的总体技术框架设计如下:
信息平台的总体技术框架设计图
如上图所示,信息平台主要包括硬件网络基础设施层、数据中心数据层、业务服务层、数据交换层四个层次,还包括贯穿四个层次的标准规范体系和安全保障体系两大体系。
硬件网络层是指支撑信息平台的硬件设备和网络平台,也是信息平台的基础设施。数据中心层主要是实现信息平台的数据存储,需要解决数据存储的结构、模型、内容、数据库管理软件的选型等。数据交换层和业务服务层主要实现信息平台的数据采集、交换与共享,数据交换层是直接与外部系统进行沟通的技术层,业务服务层是基于数据交换层根据数据结构设计各种业务服务组件来完成平台数据的采集,存储与共享。标准规范体系是信息平台中必须遵循和管理的数据标准,是平台运行和应用的数据基础。安全保障体系是从物理安全到应用安全保障整个平台的正常运营。
9.软件架构
管理平台各应用子系统采用基于JAVA语言的B/S/S三层分布架构,使用SSH(Struts + Spring + Hibernate)集成框架进行开发,充分保证平台的先进性及健壮性。
10.软件架构图
应用系统采用分层架构模式设计(Layerd Architecture),将整个系统分为终端层、表现层、业务逻辑层、数据访问层4层,以及底层的基础设施。分层架构模式的优点在于风险分散在各层组件上,每一层只处理这一层承担的逻辑。架构中明确定义了各层的接口和有限的影响范围。分层架构模式核心概念“层的隔离”意味着架构中每一层的改变不会波及到其他层的组件,设计变化被隔离在本层组件之间。
11.基础设施
基础设施包括计算机及网络基础设施、操作系统、J2EE运行时环境、中间件和数据库等系统。这些基础设施组件都构建在国家卫生计生委数据中心的网络计算平台上。
12.数据访问层
数据访问层设计为使用Hibernate技术,经过ORM映射,将数据库表转换为对象,并对上层提供数据访问接口以供调用。
13.业务逻辑层
业务逻辑层负责系统中的业务逻辑处理,以Spring MVC框架为骨干建设。当表现层接收请求时,从数据访问层获取数据并对这些数据执行业务逻辑处理。
14.表现层
基于Servlet技术,采用开源的RESTful组件,将系统中业务模块资源化并对终端层提供服务。数据交互同时支持JSON格式和XML格式。
基于JSP技术对终端层实现动态页面呈现。
15.终端层
采用一系列先进的浏览器前端开发技术(Web2.0、AJAX、JQuery、Bootstrap、EasyUI、HTML5和CSS3等),使系统同时支持PC和移动设备上各种主流浏览器对界面进行展现。
16.数据存储
存储系统采用FC SAN平台构建,结构见下图,包括网络层、存储层和服务器层。
平台存储结构图
17.存储层
由磁盘阵列、备份一体机、NAS等组成。
SAN网络层
采用冗余的网络设计,配置双光纤通道交换机,为服务器和存储备份系统提供冗余的连接路径。
服务器层
服务器层由访问SAN网络的服务器等构成。关键数据库服务器配置2块以上HBA卡用于数据存储。通过数据通道管理软件,实现多通道之间的流量负载均衡,确保高性能的数据访问。
存储系统由磁盘阵列、NAS及其管理软件构成。依据信息平台应用的系统性能、信息存储量需求,结合当前存储技术的发展,信息平台业务专网和公众服务网需采用高性能、高可靠性、可扩展的中高端磁盘阵列构建存储资源池,支持块虚拟化、自动精简配置、动态分级存储以及动态管理能力。磁盘阵列裸容量考虑文件系统损失、数据库系统损失,磁盘快照、克隆、数据复制损失、RAID损失的存储空间。对于磁盘性能要求较高的应用,使用SSD磁盘和SAS磁盘搭配配置。在做数据库规划时,可将Index,log等读写频率高的数据分布在SSD盘中,将Tablespace分布在传统的磁盘中,以提高应用系统的性能。对非关键的应用使用SATA磁盘存储。
考虑到整个系统的主要数据包括数据库形式的结构化数据、虚拟机镜像文件数据和PACS影像数据格式及电子病历中的非结构化数据,为了优化资源,提高投资回报,建议不要采用单一的存储设备,而是通过搭配不同规格的存储设备建立层次化的一体化存储平台,以适应不同的业务需求,并按需建立不同的数据保护机制。
(1)配置中高端存储设备,存放核心业务系统的数据库
(2)配置中端存储设备,存放专网虚拟机映像文件、放专网非关键系统的业务数据和各业务系统的历史数据、以及开发测试数据
(3)配置中低端存储设备,用于公众服务网的数据库
(4)配置NAS存储设备,用于存储XML格式的就医记录、PACS图像影像文件及电子病历中的非结构化数据等。
安全性设计
本项目是一个涉及范围广、业务复杂的大型信息化工程,在平台架构设计过程中要充分考虑系统安全性要求。安全是信息化系统业务开展的基础,针对信息平台的特点,可从数据安全、应用安全和隐私与权限保护等方面考虑。
数据安全:从数据库、数据传输、应用系统等多个层次,构建基于权限管理、访问控制、数据库审计、系统日志、加密传输、加密存储等过个手段的数据安全体系。
应用安全:信息平台应用级安全包括统一身份认证,统一权限管理等,对信息平台应用系统提供认证管理、权限管理以及访问控制等功能。
隐私与权限保护:在保证居民健康档案信息共享的同时,需要提供对居民隐私的安全保护,充分考虑对居民电子健康档案信息提供安全的权限管理与认证管理机制。
基于浏览器/服务器结构(B/S)技术
本项目采用基于浏览器/服务器结构(B/S)技术,实现信息平台及应用系统,采用中间层来适应平台的高并发访问与数据集中存储的技术特点。
在Browser/AppServer/DBServer三层体系结构下,将复杂的商业逻辑从传统的双层结构(Client-Server)应用模型中分离出来,并提供了可伸缩、易于访问、易于管理的方法,可以将多种应用服务分别封装部署于应用服务器,同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性,使用户在管理上所花费的时间最小化,从而实现了便捷、高效、安全、稳定的企业级系统应用。如下图所示:
三级技术架构图
B/S/S系统三层技术架构包括用户表现层、控制逻辑层、业务层、持久化层和数据服务层。用户表现层采用浏览器模式,为用户展现一个方便快捷的可视化操作界面,将用户的操作请求通过表现层与系统框架通讯的接口传递给控制逻辑层;控制逻辑层对客户端的请求进行协议识别、编码处理、任务分发等处理;业务层进行业务逻辑处理,提供可复用的业务服务;持久化层,负责应用程序与数据库之间的数据存取工作;数据服务层负责持久化的业务数据的存储。
成熟的中间件技术
在本项目建设中,将采用第三方成熟的商业中间件,支撑平台的运行,提高信息平台及各应用系统的可用性、稳定性、独立性及成熟度。
数据类的标准确定了信息平台中有关数据的业务规范。数据涵盖的范围包括:数据元目录、代码目录、分类目录和数据类资源目录。
☆ 数据元目录确定了信息系统中涉及的所有的数据指标的定义;
☆ 代码目录确定了信息系统中数据项所采用的代码标准;
☆ 信息分类目录确定了信息系统中对信息的基本分类方案的;
☆ 数据类资源目录确定了信息系统中各类业务实体的数据结构。
数据元规范明确了系统中最小的数据单元。它是构成业务知识的基础,通过数据元的规范,可以明确本项目中的各类对象和每一个对象的特性,并且在此基础上进一步明确了对象的特性的表示。代码规范是从最小数据单元的角度统一了对于最小数据的代码值的使用,为业务知识共享提供了基础的、必要的条件。
数据类标准是在充分的业务分析、业务与应用需求分析的基础上,运用信息分类方法、信息建模方法(HL7 RIM)、信息编码方法以及数据标准化方法进行制定的,用于保障数据一致性、数据共享性和可交换性的一组数据集。同时还包括用于指导区域医疗卫生信息资源规划和数据设计的规范。
流程类资源目录标准规范了信息系统各种业务操作的流程的过程定义、明确了流程的提供者、流程的使用情况、涉及的其他服务类资源等信息。
- 元数据描述规范
元数据是用于描述业务数据的数据,根据前面提到业务数据涉及的内容包括:数据元、代码、分类、服务、流程等方面,因此元数据描述也包括相关的五个方面的内容,因为描述的对象不同,所以采用的描述方法也将不同,有些领域已经有相关的国际或者国内标准,例如:对于数据元的描述,国际标准有iso-11179。
元数据描述规范的确立为上层制定业务标准时对于业务知识的表达有了方法和技术的支持,例如:采用iso-11170的描述规范可以规范化的描述信息系统中所有的数据项,例如:优抚对象姓名、优抚对象家庭住址等。
正式采用这些规范的方法作为支撑,上层的业务标准才具备标准化的基础,才能够实现对于业务标准的有效维护和管理。
- 元数据注册管理标准
在一个系统中基于业务知识所确立的业务标准在内容上非常多,从时间方面来看业务知识的变动也是比较频繁的,特别是应政策的调整。业务标准的内容不能仅停留在纸面上或者标准的文档中,这种方式无法适应业务的需要。
通过提供对元数据的注册和管理服务系统可以把业务知识有效的组织和管理起来,通过元数据注册管理的服务,其他系统很容易提交、更新业务知识,例如:提交优抚对象基本信息的定义,更新优抚对象家庭住址的定义等。
元数据注册管理标准的确定规范了其他系统对于整个平台中业务知识的检索、提交、更新的技术接口规范。
- 元数据访问标准
元数据注册标准是从业务知识的提供者、管理者的角度定义的访问接口标准,而元数据访问标准则是从业务知识的使用者的角度确定的对于元数据的检索接口标准。
业务标准要充分发挥内在价值就是要鼓励其他系统、人员能够尽量多使用业务标准中的相关规定,通过确定一套面向业务标准使用人员的业务知识的检索接口可以为检索的系统或者人员提供便捷的业务知识获取通道。
元数据访问标准针对不同的元数据种类,例如:数据元、代码、服务类资源等确定不同的接口访问方式。
- 业务数据表示规范
在信息交换过程中如果对于业务表示没有统一的规范,互联互通只能停留在数据的层面。这种情况下,各个系统无法理解彼此交换的业务数据和业务操作,各个异构的系统间难以有效的实现政务信息资源的交换。
业务数据在不同的系统间进行交换时需要遵循统一的表示规则,基于统一的业务数据表示规则系统间可以容易的理解和处理彼此传递的信息。
业务表示规范的确立可以保证异构的系统间对于业务信息有一个一致的统一的理解,是实现信息资源交换的重要内容之一。
- 业务数据访问标准
业务数据在存储和使用方面通常存在一些普遍的问题,例如::分散存储、分散使用;集中存储、分散使用;存储类型多样化;这些情况造成对于业务数据在访问方面带来的很大的复杂性。
业务数据访问标准的确立为数据的提供方和使用方明确了各自的行为模式和结果数据格式。通过对于业务数据访问标准的遵循,数据的使用者无需关心数据提供者提供的数据存储在哪里、采用什么数据库存储等这些基本的、关键的问题。而作为数据的提供方也无需为每一个使用方根据不同的要求开发不同的数据使用的服务。
在区域卫生信息化建设中,最关键是健康档案基本框架和数据集标准、电子病历基本框架和数据集标准、卫生字典以及用于区域内医学文件共享资源目录体系。数据类标准主要基于卫生部的三大基础标准(健康档案、电子病历和数据字典),并结合xx市基于全民健康信息平台的死亡管理系统项目建设实际进行本地化实施(增加或裁剪)。
(八)技术类标准
技术类标准是一组指导医疗卫生信息系统开发的规范标准。
技术标准规范包括:数据交换技术标准与接口规范、业务系统功能规范、软件开发与编码规范、平台网络接入规范、信息安全与隐私保护规范等。
- 安全规范
安全标准包括物理安全规范、系统安全规范、网络安全规范、应用安全规范和安全管理标准。
1) 物理安全规范
物理安全,主要提供对系统内部关键设备、存储介质的物理运行环境安全,确保设备能正常工作。物理安全规范的主要内容包括:门禁、物理隔离、链路加密、抗侦收、视频监控等。
2) 系统安全规范
系统安全主要是从操作系统的角度考虑系统安全措施,防止不法分子利用操作系统的一些BUG、后门取得对系统的非法操作权限。系统安全规范的主要内容包括:口令、身份认证、生物特征、安全操作系统、SSL协议、端端加密、主机防病毒、主机入侵检测 、数字签名、审计跟踪、系统容灾等。
3) 网络安全规范
网络安全提供对系统内部网络系统、广域网连接和拨号访问网络的运行安全保障,确保各类应用系统能在统一的网络安全平台上可靠地运作。网络层安全规范的主要内容包括:IPSec协议、防火墙、路由器、端端加密、网络病毒防护、网络入侵检测、审计跟踪、抗毁网络设计、网络容灾等。
4) 应用安全规范
应用安全体系,作为整个安全系统架构中最高一级的安全,是与最终用户密切相关、最体现系统特色的部分。该体系以密码技术为基础,建立一个统一的应用层的安全平台,针对各类具体的子系统统一提供相应的应用层安全保护,包括数据资源的保护和应用系统处理过程的保护。应用层安全规范的主要包括:口令、Kerberos、X.509协议、应用级网关、RBAC、PEM、PGP、S/MIME、SNMPv3协议、https数字摘要、数字签名、应用审计、容错设计、应用容灾等内容。
5) 安全管理标准
所谓“三分技术、七分管理”,任何安全措施都需要安全管理来保证其顺利的实现,因此还需要制定安全管理机构从行政体系上保证管理的人员;依靠安全管理平台提供技术管理手段,依靠安全管理制度来提供管理规范。基本的安全管理制度包括:
- 机房管理制度
- 人员管理制度
- 系统维护管理制度
- 数据备份管理制度
- 事件处理管理制度
- 数据恢复管理制度
- 全审计管理制度
- 消息整合标准
有很多系统间采用消息的机制完成数据的交换,而消息的负载和消息所期望接收方的处理要求在很多场合下是需要明确告知消息的接收方的,例如:希望对方收到消息后根据消息中携带的查询条件执行查询并且把结构返回给发送者。
实际的业务应用中需要消息的发送方和接收方根据应用的特定情况进行特定的约定,而约定的方式可能因为不同的应用而不同。当系统交换的应用越来越多时这种私有的约定的增长也会很快,增加了系统维护和进一步整合的复杂性。
消息整合类标准确定系统间采用消息机制进行通讯时应当遵循的技术要求,它包括消息格式规范、消息寻址规范、消息安全规范和消息可靠规范。通过消息整合标准的确立可以在一个协作的领域内为系统间松散耦合提供技术保证。消息整合类标准规范能够确保异构系统间互联和互通。
- 服务集成标准
传统的服务调用方式是必须要使用服务提供者提供的服务调用客户端。这种方式有很多问题,最突出的问题就是集成的服务越多,则需要使用的客户端也越多,而且有些客户端对机器的环境要求可能还产生冲突。
服务整合类标准确定了服务的统一调用格式和监管接口。统一服务调用格式的目的是将服务提供者和服务调用者解耦。基于统一服务调用格式的服务调用客户端可以无需服务提供者的客户端进行服务调用,这种服务调用机制需要借助统一的服务描述机制。服务监管接口是一种特殊类型的服务,通过这个接口服务集成中心可以统一监管运行中的服务。
- 数据整合标准
数据整合主要是解决分布在异地的、异构存储上的数据的采集、汇总、转换的问题。数据整合标准则是为这些数据处理服务规定统一的行为模式。如果没有数据整合标准,则很多复杂的数据交换流程在实施的成本和稳定性方面都会存在一定风险。
数据整合类标准确定了对于数据处理的接口。确定数据整合的接口的意义在于可以为不同的系统接受数据处理请求和返回数据处理结果时可以有一个明确的依据,而这个依据是采用标准化的方式固化下来,从而使数据整合服务提供者和使用者间形成松散耦合的关系。
另外,通过各个系统能够遵循统一的数据整合的服务规范,可以为在更大范围内通过流程驱动的方式构建一个复杂的数据交换流程提供服务支撑。
- 流程整合标准
在系统间的整合中有些是简单的两点间的一个请求/响应方式完成的,这种可以通过消息整合或者服务集成完成,但是也有一些是具有一定的复杂性。
流程整合类标准确定了流程协同所采用的描述和流程在事务方面所要遵循的标准。流程协同涉及到流程所有的参与者、参与者提供的业务服务、流程的流转结构、流程中数据的传递方式等。这些内容需要按照某种方式关联起来描述一个业务过程,流程协同描述标准就是确立了一种统一的流程描述语言。这种统一可以保证所描述的业务过程可以被不同的人读懂,也可以被不同的系统部署和运行。流程事务是业务过程中一个非常重要的方面,采用流程事务的业务过程可以有效的支持业务数据或者操作的一致性,确定统一的流程事务规范有助于实现跨多个系统间的事务的协作问题。
在本项目中作为平台开发商最重要是提出用于指导整个项目的数据交换、数据采集接口规范,这不仅仅是平台本身使用,更重要的是指导基层医疗卫生机构、医院、政府相关部门业务系统等对接接口的开发,从而保证项目的整体目标得以实现。
(九)管理类规范
管理规范确定了应用系统在建设、运营阶段的各种要求、制度等。管理标准涉及的范围也是非常广泛,例如:软件工程过程标准、验收与监理标准、系统测试与评估体系标准等。
(1)项目规划管理标准
系统建设需要考虑近期、中期和长期的目标相结合,只有这样系统的信息化道路才是一个可持续发展的科学的道路。在规划中需要确定信息化系统的远景目标,特别是中期的目标规划需要相对明确。
项目规划本身是一个比较复杂的过程,包括了战略规划、建设规划和运作规划三个基本方面,每一个方面都涉及到一系列的管理流程和管理活动。如果没有相应的管理标准,则整个组织对于完成一个高质量的规划的成果则充满了
规划阶段的标准主要包括战略规划标准化、建设规划标准化、运作规划标准化。
(2)项目准备管理标准
项目准备阶段需要考虑项目的立项、项目招标和项目启动相关事宜。
项目立项阶段主要的任务是由建设方完成项目建设可行性的分析,可行性分析的结果对于后续的工作影响非常大,标准化在这里的作用在于能够为可行性报告的产生提供科学化、制度化的方法,保证可行性报告的质量。例如:在立项阶段对于立项依据的分析和考虑就非常重要,在该部分标准化我们可以结合财税的实际情况,把一些常用的、必须的各种规章、法规、技术标准等作为规范的内容提供给立项依据分析的活动。
项目招标流程按照国家的有关规定已经比较成熟,一般分为招标、评标和签订合同三个阶段。本标准在这部分的主要任务是细化招标文件的编制要求、评标过程的过程方法等。通过对于这些活动提供规范化的要求可以提升招标的有效进行,一方面能够保证提出合理、科学的招标要求,另一方面能够把握好公开、公平和公正的原则。
(3)项目建设管理标准
软件工程规范规定在整个项目的开发过程中,所必须遵循的软件工程规范,从内容上一般包含软件工程(软件需求分析、设计、编码、测试、验收)、系统集成、项目管理这三部分。
- 软件需求分析要求
必须符合用户的需求以及将来业务发展的设想,最后要得到最终用户的确认;
- 设计要求
是在业务模型重构的基础上,对业务流程、界面、功能、数据结构、代码、表单等内容进行设计,设计应以需求文档作为基础;
- 编码要求
必须遵照应用开发规范、接口标准等要求进行开发,做到程序代码的可读性和易维护性;
- 测试要求
包括对应用软件的白盒测试、黑盒测试,由于本系统是一个大型复杂的信息系统,因此必须在上线之前进行系统联调测试,系统联调将组织开发商、最终用户、信息系统管理部门共同进行,对系统性能和功能进行测试,以满足试运行的要求。
- 验收要求
系统验收包括对系统、代码、文档、功能、性能、安全等内容的验收,验收工作一般通过内部验收和专家验收的过程,验收标准将依据用户确认的需求说明书进行。
验收与监理规范是明确信息化系统的验收和监理的程序、规程和指标要求。这部分可借鉴和参考国家电子政务信息系统工程监理规范。
系统评估标准是对项目建设后取得效益的一种评估方法,这里的效益既有经济的效益也有社会的效益。对于政务的信息化项目社会效益是一个非常重要的方面。要能够较为准确的评估一个项目建设是否达到当初立项时的预期目标是需要提供一套标准的评估方法,对于经济效益的评估要明确计算统计准则,对于社会效益的评估需要明确方法手段。
(4)系统运行管理标准
系统运行管理活动主要的内容有IT 资产的管理、IT外包的管理和软件部署管理。系统运维是保证系统正常工作的保证,因此需要给与足够的重视。对于各种类型的管理活动都需要从人员、制度和资金各个方面做好相应得规定。
系统运行管理标准化将在充分细分管理对象的基础上,对于管理的方法、人员配置、投资估算等给出规范性、指导性的意见,这对于提升系统运行管理的成熟度具有很大的意义。系统运行管理制度要充分考虑用户单位的组织架构、职责分工和系统运作模式等因素,因此将根据项目建设的推进不断提出和完善。
管理类规范主要是用于xx市基于全民健康信息平台的死亡管理系统的项目实施和维护的一组规范。它包括验收规范、文档编制规范、安全管理规范、运行维护规范等。
一级类目 |
二级类目 |
发布单位 |
引用与指导类 |
基础引用类标准 |
标准委等 |
卫生信息数据元标准化规则 |
卫生部 |
|
卫生信息数据模式描述指南 |
卫生部 |
|
卫生信息数据集元数据规范 |
卫生部 |
|
卫生信息数据集分类与编码 |
卫生部 |
|
基于健康档案的区域医疗卫生信息平台建设指南(试行) |
卫生部 |
|
电子病历基本数据集编制规范(试行) |
卫生部 |
|
健康档案基本数据集编制规范(试行) |
卫生部 |
|
健康档案公用数据元标准(试行) |
卫生部 |
|
区域医疗卫生信息化术语 |
卫生部 |
|
区域医疗卫生标准化指南 |
卫生部 |
|
…… |
|
|
数据类标准 |
健康档案基本架构与数据标准(试行) |
卫生部 |
健康档案基本数据集标准(试行)---32个 |
卫生部 |
|
电子病历基本架构与数据标准(征求意见稿) |
卫生部 |
|
电子病历基本内容架构图(征求意见稿) |
卫生部 |
|
电子病历数据组与数据元(征求意见稿) |
卫生部 |
|
电子病历基础模板:(试行)—19个 |
卫生部 |
|
国家卫生数据字典与元数据管理(试行) |
卫生部 |
|
三级综合医院医疗质量管理与控制指标(2011年版) |
|
|
…… |
|
|
技术类标准 |
妇幼保健信息系统基本功能规范(试行) |
卫生部 |
社区卫生信息系统功能规范(试行) |
卫生部 |
|
新型农村合作医疗信息系统基本规范(2008年修订版) |
卫生部 |
|
基于健康档案的区域医疗卫生信息平台建设技术解决方案(试行) |
卫生部 |
|
基于健康档案与区域医疗卫生信息平台的妇幼保健信息系统技术解决方案(试行) |
卫生部 |
|
综合卫生管理信息平台建设指南(试行) |
卫生部 |
|
卫生系统电子认证服务规范(试行) |
卫生部 |
|
卫生系统数字证书应用集成规范(试行) |
卫生部 |
|
卫生系统数字证书格式规范(试行) |
卫生部 |
|
卫生系统数字证书介质技术规范 |
卫生部 |
|
卫生系统数字证书服务管理平台接入规范(试行) |
卫生部 |
|
《劳动和金保工程核心应用系统结构通则(LB001-2000)》 |
人社部 |
|
《金保工程核心应用系统指标体系—业务部分(LB101-2000)》 |
人社部 |
|
《社会保障(个人)卡规范(LB002-2000)》 |
人社部 |
|
…… |
|
|
业务类规范 |
国家基本公共卫生服务规范修订稿(2011年版) |
卫生部 |
健康档案基本卫生服务记录表单参考用表 |
卫生部 |
|
…… |
|
针对本次项目,还将根据xx市的实际情况和业务需求制定平台功能规范、业务协同功能规范和服务调用规范。
(十)平台功能规范
本项目将制定平台功能规范,对平台应具备的基本功能进行了分别描述,应包括功能模块的定义、使用范围及功能要求,用于规范和指导平台建设。
基于健康档案的全民健康信息平台,是连接区域内各级各类医疗卫生机构基本业务信息系统的数据交换和共享平台,是不同系统间进行信息整合的基础和载体。平台的使用对象主要是医疗卫生人员,最终的服务对象是居民和患者。按照功能和定位,平台大致可分为基本服务、扩展服务和数据交换三个部分。
l 平台基础服务:包括注册服务、个人身份识别服务、健康档案采集服务、健康档案整合服务、健康档案存储服务、健康档案调阅服务、基于居民健康档案的区域医疗卫生业务协同服务、信息安全与隐私服务。
l 平台扩展服务:包括标准管理、数据质量控制、运维监控管理、后台管理。
l 数据交换服务:采用企业服务总线等符合SOA技术路线的产品搭建,提供任何授权应用服务数据访问的统一网关。
(十一)业务协同功能规范
通过采集、存储区域内各医疗卫生机构中居民健康档案相关信息,有效整合医疗卫生业务应用系统,通过平台向各业务系统、各医疗机构自动产生、分发、推送工作任务清单,为区域内各类医疗卫生机构开展医疗卫生服务活动提供支撑,构建一个互联互通的卫生业务协同体系。
从业务使用者的角度包括:公众健康服务、区域医疗协同业务、区域公共卫生管理、卫生行政管理四类,范围涉及区域内各医疗卫生服务机构、公共卫生管理机构、卫生行政管理部门和其他业务相关部门。
(十二)服务调用规范
根据平台提供的通用应用及服务,本次还将制定服务调用类标准规范文档,包括健康档案调阅、智能提示、双向转诊、检验检查结果互联互通等,供医院、公卫、基层医疗卫生机构及其他政府行政部门发生业务协同时使用。
一、项目实施方案
(一)项目建设周期
由于项目建设涉及面广、工程复杂、不确定因素较多、建设难度大。因此,围绕总体建设目标,充分利用xx市现有医疗信息化基础,本项目建设周期从2019年6月至2020年6月,共12个月分两个阶段进行建设,具体实施计划安排详见以下章节内容。
(二)实施计划安排
一阶段(2018年6月-2018年12月):夯实基础,互联互通,激活应用
搭建xx市基于全民健康信息平台的死亡管理系统,实现全市6家市级医院、25家乡镇卫生院、11家社区卫生服务中心数据采集,实现与xx市基层医疗卫生系统、省全民健康信息平台等外部平台与系统的互联互通。同时基于全民健康信息平台开展医疗业务协同(影像中心/检验中心/心电中心/双向转诊),综合监管等建设,为辖区患者提供同质化高质量的协同服务、为辖区内卫计委的日常工作提供信息化支撑,同时从微信公众号、手机APP等角度开展互联网+健康服务应用,使居民、医务人员、卫生行政管理人员均快速感受到建设成效。
第一阶段建设内容将在2019年12月前按照以下步骤进行:
(1) 全民健康平台上线:完成本期全民健康信息平台上线,实现平台医疗协同应用、卫生综合管理应用体系、信息惠民应用亮点的建设。
(2) 互联互通建设:完成全民健康信息平台相关标准制定,实现与全市6家市级医院、25家乡镇卫生院、11家社区卫生服务中心和605家村卫生室对接,实现与省人口健康信息平台、xx市基层医疗卫生系统对接。
(3) 区域协同应用建设:以医院为诊断中心、连接20家基层医疗卫生机构,推进双向转诊、影像中心、检验中心、心电中心等医疗协同工作开展。(需同步配套业务协同机制、业务规范建设)
(4) 互联网+健康服务应用:以医院为试点开展互联网就医服务、互联网健康服务、互联网诊疗服务应用部署。
(5) 项目整体试运行:全民健康信息平台互联互通、共享协同应用、卫生监管、互联网+健康服务等应用体系全面试运行,并持续改进和完善。
二阶段(2019年1月-2019年6月):深化扩展,广泛推广,丰富应用
推广并深化基于全民健康信息平台的区域业务协同应用、互联网+健康服务应用、卫生综合管理等应用。
(1) 完善综合管理平台,建立医疗保障监管、卫生资源监管、健康扶贫监管三大类指标体系,建设监控驾驶仓应用,进行统计分析及动态展示,辅助领导决策。
(2) 完善区域业务协同应用,建设远程联合门诊、远程会诊等应用,促进医院与基层医疗机构之间的业务协同。
(3) 利用移动互联网技术建设互联网家医服务应用,落地家庭医生签约制度。
实施计划表
信息系统 |
子模块 |
一阶段 |
二阶段 |
基于全民健康信息平台的死亡信息管理系统 |
数据交换共享平台 |
|
|
区域卫生数据资源中心 |
|
|
|
平台服务 |
|
|
|
互联互通建设 |
|
|
|
基于平台三大应用 |
|||
区域业务协同应用 |
双向转诊 |
|
|
区域检验 |
|
|
|
区域影像 |
|
|
|
区域心电 |
|
|
|
远程联合门诊 |
|
|
|
远程会诊 |
|
|
|
卫生综合管理应用 |
医疗服务运营监管 |
|
|
药品监管 |
|
|
|
公共卫生监管 |
|
|
|
医疗保障监管 |
|
|
|
卫生资源监管 |
|
|
|
健康扶贫监管 |
|
|
|
监控驾驶仓 |
|
|
|
互联网+健康服务应用 |
互联网就医服务 |
|
|
互联网健康服务 |
|
|
|
互联网诊疗服务 |
|
|
|
互联网家医服务 |
|
|
(三)组织保障
1、领导小组
本项目是一个有“生命力”的系统工程,涉及到各级、各类卫生部门、医疗机构的业务协调,因此在项目建设初期需要成立以xx市委、市政府主管领导负责信息化领导小组,在政府协调和技术路线两方面为项目建设提供决策支持。
2、建设管理办公室
以卫计委为主,协调市领导、卫计委领导、医院领导等成立项目建设管理办公室。负责对项目建设和业务应用建设进行审核,并依据项目建设总体规划,根据工作的重要性和需求的紧迫度,合理安排各阶段任务顺序。负责将项目建设所需资金列入年度建设总预算中。组织专业队伍对项目建设进行可行性分析,在充分论证的基础上立项,报信息化领导机构审批,列入规划,经决策部门审议后实施。
1)专家组
由信息化专家、卫生领域专家、xx市本地相关专家组成,担负研究和制定项目发展战略、技术规划、设计方案。在充分调研论证的基础上,提出项目建设可行的短期、中期和远景规划及实施方案,制定相关应用建设标准及推行。
2)协调组
由公共卫生业务骨干、医院业务骨干、信息技术骨干组成,担负组织协调总体规划、公共标准、医疗信息化项目与个性化业务系统的关系;协调辖区内跨机构、跨业务的建设;协调各系统及部门信息共享的关系;协调项目建设配套的机制问题。
3)计划组
按照项目建设周期要求,在总体规划的框架下制定阶段性的实施计划,统筹管理各机构、业务部门在项目建设上的步调一致,既保证项目建设和业务应用建设的成功,又要兼顾平衡,充分利用医疗卫生资源,实现项目建设的预定目标。
4)实施组
由专家、技术骨干组成,承担项目建设的技术保障、管理和维护工作。按照预先制定的项目总体计划,配合项目承包商完成必要的技术保障工作,控制项目变更范围,规避项目过程风险,承担系统运行期间的维护工作。
5)规范编制组
由用户专家组及相关的标准机构负责编制系统的标准规范和管理制度,保障系统建设和运维期间有标准可依据,有制度可依遵循。
6)质量保障组
根据预先编制的项目质量目标和相关质量标准规范,完成项目建设质量评估,确保项目最终产品在质量目标控制范围内。如果发生严重质量问题,有权向领导小组直接汇报权利。
3、项目承建单位
项目承建单位一般由一个总集成商和多个开发商组成。总集成商直接对建设方负责,其他开发商商对总集成商负责,这样可以减少项目建设的复杂性和风险。考虑到本项目建设的复杂性,建议选择有经验的承建商为妥。
4、项目建设监理单位
项目监理的目的是协助业主实现项目工程的总目标。通过制定计划,建立组织,配备合适的监理人员,进行有效的领导,实施工程的目标控制。主要工作包括确定监理工作目标,制定监理工作程序,确定目标控制、合同管理、信息管理、组织协调等各项措施和确定各项工作的方法和手段。
(四)风险控制措施
1.外部风险及措施
该系统需要与本市现有的多家卫生机构互联,且目前市卫计委尚有核心应用系统,如何将这些信息系统和公共卫生信息系统有机融合起来,优势互补,是摆在系统建设面前的一个难题。
针对项目实施的外部风险建议采取以下控制措施:
l 在设备选型、技术路线等方面采用成熟、先进、灵活、可靠的技术;
l 项目建设前期即组织一支合理、高效的领导小组和实施小组等;
l 项目建设前期的规划、需求调研、设计方案论证等工作做深、做透;
l 循序渐进,分布实施。
2.内部风险及措施
l 1、系统开发风险
由于系统建设涉及多个卫生机构,进行详细的调研和需求分析显得尤为重要,如果需求调研不充分,开发工作就会很被动,所开发出的系统可能与业务需求和领导的期望不一致。
l2、数据采集风险
如果相关数据采集机制不完善,或者采集不到相应的资料数据,数据完整性差;或者因为多头采集、重复采集,导致数据的不一致性和冗余度高等,系统建设得再好,因为数据采集问题不能得到有效地解决,也难以运行和推广。
针对项目实施的内部风险建议采取以下控制措施:
☆ 采用国际上流行的项目管理模式;
☆ 在供应商和服务商选择方面公开竞争、择优录取。
3.长期运行风险及措施
系统建成后,业务模式始终存在着不断更新和发展的需求,这会给项目带来以下长期运行风险:
l 系统使用风险
系统建成后,各部门要将原来的业务流程转变到规范后的业务流程中,这需要相关部门的积极配合。如果没有强有力的组织机制来推动系统的应用;没有相应的运行维护机制来保证系统的正常运行,则不能充分发挥系统的应有功能。
l 系统更新升级风险
由于业务框架设计和技术路线方案不合理将会导致平台系统在更新换代或升级时遇到不可逾越的困难。
l 运行维护上的风险
由于系统用户众多,这可能为维护平台正常运行带来未可知风险。
针对以上风险,可以采用如下控制策略计划予以降低或化解。
l 对系统业务框架进行严格把关;
l 尽量采用成熟、商业化、市场上主流的信息技术;
l 寻求专业队伍对整个系统进行运行维护;
在项目建设初期即注重内部人员的业务和技术培训,加强自身力量。
4.数据质量控制平台
目前国内大部分区域卫生信息平台存在的数据质量问题是:业务系统上传的数据完整性、准确性、稳定性、及时性、关联性没有方案和手段进行监控,从而导致平台上来的数据没有可用性,基于平台的业务应用和综管监管的数据没有权威性。针对上述问题,xx市基于全民健康信息平台的死亡管理系统建设需强化平台数据质量控制体系建设。
5.建设目标
数据质量监管系统是人口健康信息平台健康档案索引中心的核心组件,主要实现以下目标:
1)网络监控
网络监控主要是监控前置机与中心的网络通信情况,用以保证物理线路的通常,同时,还能够对连接异常的记录进行统计,阶段性的监测网络情况。
2)质量分析
对数据从医疗机构到前置机,前置机到中心端的数据交换传输情况进行跟踪,按照校验规则对数据进行字段级及表级关系进行校验,同时输出数据校验结果报表,提供给各个医疗机构对不符合规则的数据进行排查。
3)质量评估
质量评估是数据监管系统的重要组成部分,从数据的完整性,一致性,一致性,规范性四个维度对数据质量进行评估。以业务信息为基础,将所有可监控、可计算的数据指标在质控平台中统一管理,为每个指标做出明确的定义,这些定义包括:指标类型, 指标名称、计算公式,计算频次等。数据质量管理根据需要将所有相关数据质指标分为两大类:原子指标、复合指标,指标类别分为监督指标, 评估指标和考核指标,这些分类中有重叠部分,只是根据不同的目标在指标源中抽取不同的指标。
4)路径追踪
当质量评估评测出数据的问题后,需要将分类将错误信息反馈给各个医疗机构,各个医疗机构要修改数据的错误,然后重新提交给质控中心进行二次评测,这个过程可能要反复多次。路径追踪通过状态面板详细跟踪评审报告生成时间,报告下发时间,数据重传时间,重新评审时间等重要的流程节点,提供给管理者使用。
5)运营维护
运营维护主要包括交换节点维护,指标体系维护,机构交换表维护等基础功能。用以保障整个系统的正常运行。
6.质量控制管理机制
1)确定专人、明确职责
数据质量是建立区域卫生信息平台的基础,各平台接入单位对此必须高度重视。
卫计局需明确专人负责各单位上传数据质量管理,平台接入医院要明确专人负责本单位的上传数据质量管理工作。
各单位数据质量管理员负责每天登陆“数据质量监控平台”,查看本单位数据上传情况。
各单位数据质量管理员如发现当日数据未上传至平台,须当日将情况反馈到数据交换平台软件开发商,由其在当日解决。
卫计局数据中心质量管理员要每天负责查看数据采集作业执行情况,并填写《数据采集监控日志》。
2)制定数据评分规则
数据上传前由各医院如实填写《数据上传确认表》,确认本单位可上传的数据表。
承建方协助卫计局建立数据质量及时性、准确性、关联性、稳定性、完整性的评分规则,对数据质量进行评分排名。
医院数据质量管理员负责对本院上传的数据质量进行管理核对,卫计局数据质量管理员对平台各接入医院的数据质量进行监控。
3)定期通报
卫计局数据交换平台接收到各医院上传的数据后,通过数据质量核对的分析结果填写《数据质量周报》。对各医院的数据上传情况进行分析、评分及排名。产生一份数据质量报告。卫计局将依据此《报告》考核各单位的数据上传情况,并于每周将《报告》通报至各单位。
4)及时解决、提高质量
区域卫生信息平台数据质量主要表现在数据完整性、准确性、及时性、稳定性。为保证卫生综合管理平台正常使用,各单位需保证数据质量的及时性、准确性、关联性、稳定性、完整性达到卫生局的要求,发现问题及时整改。
7.数据准确性及核对机制
1)指标统计口径确认
平台厂商提供区域卫生信息平台指标集,并于业务科室确认指标统计口径,全市统一口径的指标集合。
平台厂商根据确认的指标统计口径完成区域卫生信息平台统计算法调整。
卫计局将确认统计口径的指标集下发到各平台接入医院,并协调医院按照确认的统计口径上传指标数据。
2)指标数据核对
HIS厂商负责按照确认的指标统计口径上传可采集的指标数据。
HIS厂商每天上传3级汇总表,通过数据质量核对界面进行明细数据核对。
核对有差异,需HIS厂商检查上传的明细数据是否正确。
平台厂商与HIS厂商确认汇总值的统计口径与平台指标计算口径是否一致。
主要功能说明
1)质量评估
质量评估分别从完整性,一致性,规范性和及时性四个维度对数据质量进行分析和评估。四个维度支撑构成了评分体系指标库,通过对评分指标体系分数的定义和权重的平衡,以周,月,季,年的频次对区县及各个机构进行评分。
关联性评估:关联性评估以业务子事件报告可以按照一定规则追溯到业务父事件报告作为评估标准来评测数据的质量。
业务约束性评估:业务约束性评估以存在业务子流程的业务父事件报告需存在至少一笔的业务子事件报告作为评估标准来评测数据的质量。
业务运营明细报告-业务运营统计报告评估:以监测各机构上传的业务运营明细报告是否与业务运营统计报告总值相符作为评测标准。
诊疗文档明细报告-业务运营明细报告评估:以监测各机构上传的诊疗文档明细报告是否与业务运营明细报告总值相符作为评测标准。
医保文档-诊疗文挡评估:以监测各机构上传的医保文档是否与诊疗文档总值相符作为评测标准
规范性-基础信息评估:以基础信息类相关接口表的字段值与对应的数据字典是否一致作为评测标准。
规范性-业务信息评估:以业务信息类相关接口表的字段值与对应的数据字典是否一致作为评测标准。
及时性评估:及时性监测主要记录各机构上传的业务表单数据中,最后一次上传时间与业务发生时间的日期差距天数作为评测标准。
2)质量分析
质量分析用来分析数据交换及数据校验的质量情况。
数据交换监控:查看各机构数据交换结果报告。
数据校验监控:查看各机构数据校验结果报告。
路径追踪:追踪问题排错的状态和流程。
3)业务指标核对
用以核对各医院汇总数据和上传到平台的明细数据统计值是否相同。
业务指标说明:用以说明各个指标的作用。
业务指标统计:以月或者自定义查询时间的方式来统计指标的值。
4)流程管理
流程管理用来配置数据校验的规则。
校验规则流程配置:提供数据校验规则及指标评分规则配置功能。
校验规则查询:查询校验规则。
平台数据质量核对流程
平台数据质量核对流程
1)数据交换通讯点监控
查看各通讯点的实时状态。
2)网络拓扑图监控
查看各个前置机与平台中心数据交换的连接状态。
3)数据交换流程监控
提供可视化界面,查询数据交换平台当前运行的状态,包括各前置机的作业执行情况。
4)数据交换结果报告
监控各家机构数据上传情况的总体状态。
5)数据校验结果报告
监控各家机构数据上传质量,具体到某一条表记录。
6)机构评分排名报告
根据制定的数据质量评分指标对各家机构上传的数据质量进行评分计算并排名。
7)数据指标核对
各级数据质量管理员通过区域卫生信息平台中的数据质量核对功能进行核对。
8)数据指标审核
数据质量经过数据质量管理员确认无误后通过审核功能对已核对确认的数据进行审核,审核的数据无法更改。
互联互通接口
与全民健康信息平台的对接
全民健康信息平台从xx市基于全民健康信息平台的死亡管理系统获得所需的卫生数据,如xx市医疗卫生数据和健康档案数据,为区域决策和卫生管理提供数据支持,也将区域整合的数据分发给xx市基于全民健康信息平台的死亡管理系统,实现数据的垂直共享。市级卫生信息平台从省级平台获得更完善的健康档案数据,通过省级平台获得其他平行系统的数据,实现系统的数据横向共享。对接方案如下:
指标 |
描述 |
实施范围 |
全民健康信息平台与xx市基于全民健康信息平台的死亡管理系统进行对接。 |
对接方式 |
数据采集建议采用前置机接口库交换方式 协同服务建议采用共享服务交换方式、 |
对接内容 |
以电子健康档案为核心,进行个人/患者信息、电子健康档案信息、医疗卫生资源信息的交换。 |
与基层医疗卫生机构信息系统对接
通过xx市基于全民健康信息平台的死亡管理系统与xx市基层医疗卫生信息系统的对接,可以将区域卫生横向信息资源整合到市全民健康信息平台,实现跨业务域的数据综合分析,实现跨业务条线的互联互通与业务协同协作。对接方案如下:
指标 |
描述 |
实施范围 |
xx市基于全民健康信息平台的死亡管理系统与xx市基层医疗卫生信息系统的对接 |
对接方式 |
建议采用文档共享服务交换方式、前置机接口库交换方式 |
对接内容 |
以电子健康档案为核心,与基层医疗卫生信息系统主要进行个人/患者信息、电子健康档案信息中公共卫生服务记录、基本医疗服务记录等的对接; |
与二三级医院系统对接
平台和医院信息系统的对接,实现平台和医院信息系统间的数据共享,通过平台可以调阅不同医疗机构生成的医疗业务数据,为领导决策和监管提供数据支持,也为医务人员调阅完整的健康档案进行治疗提供基础。对接方案如下:
指标 |
描述 |
实施范围 |
与需接入平台的医院的信息系统进行对接。 |
对接方式 |
建议采用文档共享服务交换方式、前置机接口库交换方式 |
对接内容 |
以电子健康档案为核心,主要进行个人/患者信息、医疗卫生服务记录(如门诊信息、住院信息、检查检验信息、影像信息)、医疗卫生资源(卫生技术人员数据、床位数据、设备数据、药品数据、财务数据)的对接。 |
医院业务系统与全民健康信息平台互联时,需要对医院业务信息系统进行必要的改造,医院信息系统中的数据作为健康档案中的核心数据,医院端的数据是否能够接入平台则成为了xx市基于全民健康信息平台的死亡管理系统建设成功的关键。而且医院信息化相对于其他卫生相关机构信息化建设起步更早,系统开发商也更多,系统更加复杂多样,如何能够有效的整合辖区内各家医院的系统,成为了项目的核心,也是难点,推进过程中需要市卫计局相关部门大力协助。
- 自身业务管理的改进和完善
按照xx市人口健康信息化的统一的技术体制和标准规范,对接入的医院信息系统进行集成改造或开发健康档案调阅、病人转院等功能,完成业务的纵向业务集成。
- 标准接口和功能
通过应用xx市基于全民健康信息平台的死亡管理系统提供的各类服务和构件,按照统一的技术体制和标准规范要求进行集成改造,使需要接入的医院信息系统支持数据交换、数据共享和时间统一等功能,能够接收和使用全市统一的个人基本信息、医疗机构基本信息、医疗卫生人员基本信息和术语/字典等基础信息。
- 环节衔接
医院信息系统与xx市基于全民健康信息平台的死亡管理系统的衔接包括门诊电子病历环节、住院电子病历环节、病人入出转环节等。
- 功能扩充
医院信息系统可根据需要基于全民健康信息平台增加健康档案调阅功能和病人转诊等功能。
- 服务化改造
对照应用xx市基于全民健康信息平台的死亡管理系统的服务和构件,对原系统进行相应的服务改造,以满足医院信息系统与xx市基于全民健康信息平台的死亡管理系统交换共享需求。
(五)风险识别
风险识别与控制是项目跟踪与监控的重要目的之一,跟踪项目过程必须具备两点要素:
找出潜在的问题以预防他们发生
在出现严重危害前,准备好修复计划
本项目将运用质量体系提供方法与手段,对风险进行有效的管理。
风险识别策略
参照高风险区检查单, 定期跟踪检查这些风险项,识别本项目存在的潜在风险,列出高风险区清单
指定有经验的人员对项目风险进行评估,确定风险大小及严重性
定期跟踪高风险区的变化情况,包括风险度量值的变化
风险量化管理策略
风险管理采用量化管理,度量风险大小及严重性采用以下度量因子
风险严重性(用 LEVEL 表示):以进度延误偏差率或成本超支率为度量值
风险可能性(用 CHANCE(%)表示):以经验判断百分值为度量值
风险系数(用 RATIO 表示):指风险对项目成功实施带来的威胁性,以 RATIO = LEVEL× CHANCE(%)为度量值
风险阈值(用 THRESHOLD 表示):指对风险应该采取的戒备程度,根据风险系数值的大小,依次定义风险阈值为:警报、警戒、观察、忽略项目风险指数(用 DEFEAT 表示):指项目失败的可能性。项目风险指数为风险系数大于 IGNORE 的各项风险系数之和 DEFEAT = ∑RATIO
风险控制策略
当风险阈值为警报、警戒时,及时与风险源相关方讨论制订风险缓解计划
跟踪风险缓解计划实施情况
及时组织资源进行风险控制
风险缓解计划实施各相关方或相关人员定期进行沟通
及时通报项目组、用户方及其他相关方的上层领导,进行相关协调工作
(六)应急处置方案
(1) 应急服务目的
为妥善应对和处置平台信息安全突发事件、确保平台信息化系统的运行安全和数据安全,结合实际情况,特制定本应急服务措施。本措施主要立足防范和消除以下危害情况的出现:
平台信息化工程项目运行过程中数据库异常,导致数据丢失,系统不能正常运行;
平台信息化平台运行过程中,应用服务程序异常,导致系统异常系统不能正常运行;
平台信息化平台运行过程中,服务器间网络连接异常,导致系统异常系统不能正常运行。
(2) 危险因素分析
平台是作为应用组件部署在信息中心数据和业务两个平台,而并非单独孤立的应用系统,且该系统直接部署在生产环境中,所以引发平台潜在危险的因素主要包括:部署环境的硬件设备故障、部署软件系统故障、网络故障及平台本身的程序错误。
(3) 危险事件等级定义分类
一般故障:指系统出现轻微错误或瑕疵,具体包括:个别图片无法显示、个别信息内容出现明显错误、个别服务和功能无法正常使用等。
重大故障:指出现系统出现异常,但不影响系统日常使用,具体包括:局部页面错误、部分功能无法使用,部分信息内容出现明显错误等。
特大故障:指系统崩溃,应用服务停止,导致大规模用户无法使用系统,出现数据丢失,具体包括:系统服务无法启动、数据库无法连接、系统程序异常和数据库文件损坏等。
(4) 应急响应流程
事件报警与确认
工作人员对数据库服务器、应用系统的运行状况以及网络情况进行监测,及时发现系统的异常和网络故障,一旦发现异常情况需及时通知项目维护相关人员进行原因的排查和故障的处理;
应急服务流程
图 194
对系统进行检查
检查网络连接:需要相关网络管理人员配合检查;
检查应用服务器性能指标,检查的内容包括:Web Sphere 进程是否正常、CPU 使用
率、内存使用率;检查后台数据库服务器性能指标,检查内容包括:数据库服务器双机状态、数据库进程是否正常、数据库服务是否启动、CPU 使用率、内存使用率。
安全审计及事故分析
通过系统日志、网络设备日志、数据库访问日志等,对事件进行审计,对损失进行评估,追查事件的发生原因;
消除隐患、恢复正常运行
根据审计结果,排除系统隐患,恢复系统正常运行;
重新启动系统
启动数据库服务器->启动应用服务器;
安全报告、归档
提供故障分析报告,分析故障原因,修正预案处理流程并归档。
检查数据库服务器数据库服务是否运行正常,如数据库服务器服务未启动则启动数据库服务器数据库服务,重新启动系统;
应急事件处理流程如图下所示:
紧急事件应急响应策略清单:
紧急情况 |
预防措施 |
应急策略 |
操作失误 |
加强培训力度,掌握培训效果, 检验操作人员操作水准,提示注 意事项。 |
操作失误未造成即成结果或数据未丢 失情况下,保障数据安全,反之,协调 相关部门,进行补救。对操作人员强调 注意事项 |
配置丢失 |
培训时强调使用前配置方法和 步骤,并特别提示需在使用前按 要求操作 |
派出上门维护、培训人员重新配置,并 耐心讲解。 |
数据丢失 |
培训时强调使用过程中注意定 期备份重要数据,日常维护过程 中,上门服务人员实时备份数据 并告知客户 |
协调有关部门,进行补救,无法补救, 提交报告说明原因。 |
(5) 应急处理措施
本措施是根据有关法规和政策,结合平台建设和运行情况,加强信息化项目系统的安全运行效率,提高应对突发事件的能力,重点针对系统可能发生的重大突发事件制定的,包括领导小组、组织指挥体系及职责、预警和预防机制、应急处理程序、保障措施等,其中明确规定了在发生信息系统突发事件情况下,应急领导小组人员的相关职能和工作方法,具有一定的指导性和可操作性。
(6)应急领导小组
职责:负责定期了解外部支持人员的变动情况,及时更新其技术人员及联系方式等信息;快速响应信息系统发现的故障事件、业务部门对信息系统故障的申告;执行信息系统故障的诊断、排查和恢复操作;定期通过设备监控软件、系统运行报告等工具对信息系统的使用情况进行分析,尽早发现信息系统的异常状况,排除信息系统的隐患。
工作原则
统一领导。遇到重大信息系统异常情况,应及时向有关领导报告,以便于统一调度、
减少损失。重点突出。应急处理的重点放在运行着重要业务系统或可能导致严重事故后果的关键信息系统上。
及时反应,积极应对。出现信息系统故障时,信息系统维护人员应及时发现、及时报告、及时抢修、及时控制,积极对信息系统突发事件进行防范、监测、预警、报告、响应。
快速恢复 。信息系统管理人员在坚持快速恢复系统的原则下,利用应急预案的资源准备,采取有力措施进行故障处理,及时恢复信息系统的正常工作状态。
根据职责分工,加强团结协作,必要情况下与设备供应商以及系统集成商共同谋求问题的快速解决。
防范为主,加强监控 。经常性地做好应对信息系统突发事件的思想准备、预案准备、机制准备和工作准备,提高基础设备和重要信息系统的综合保障水平。加强对信息系统应用的日常监视,及时发现信息系统突发性事件并采取有效措施,迅速控制事件影响范围,力争将损失降到最低程度。
预警和预防机制
信息系统监测及报告
信息系统的日常管理和维护。信息系统的日常管理和维护应加强信息系统应用的监测、分析和预警工作。
建立信息系统故障事故报告制度。发生信息系统故障时,值班人员应当立即向应急处理小组领导报告,并及时进行故障处理、调查核实、保存相关证据等。
预警
在接到突发事件报告后,应当经初步核实之后,将有关情况及时向应急处理小组领应急领导小组视情况紧急程度召集协调会,决策行动方案,发布指示和实施命令等。
预防机制
各业务信息系统和重要信息系统建设要充分考虑抗毁性与灾难恢复,制定并不断完善应急处理预案。针对基础信息信息系统的突发性、大规模异常事件,各相关部门建立制度化、程序化的处理流程。
应急处理程序
信息系统突发事件分类分级的说明
根据业务信息系统突发事件的发生原因、性质和机理,业务信息系统突发事件主要分为以下三类:
攻击类事件:指信息系统因计算机病毒感染、非法入侵等导致业务中断、系统宕机、信息系统瘫痪等情况。
故障类事件:指信息系统因计算机软硬件故障、停电、人为误操作等导致业务中断、系统宕机、信息系统瘫痪等情况。
灾害类事件:指因爆炸、火灾、雷击、地震、台风等外力因素导致信息系统损毁,
造成业务中断、系统宕机、信息系统瘫痪等情况。
按照突发事件的性质、严重程度、可控性和影响范围,将其分为一般故障、严重故障、重大故障三级。
一般故障
信息系统中单个系统故障,但未影响业务系统运行,也未造成社会影响或经济损失的突发事件。
严重故障
信息系统出现故障导致公司业务中断,可能造成较大业务影响或较大经济损失的突发事件。
重大故障特指发生不可预见的灾难性事故,如火灾、水灾和地震等。
信息系统应急预案启动
根据以上定义的故障分级,当信息系统事件的要素满足启动应急预案要求时,进入相应的应急启动流程。
应急处理工作小组从业务人员或值班人员的故障申告、信息系统监控报告的故障告警中得知信息系统异常事件后,应在第一时间赶赴信息系统故障现场。应急处理工作小组针对信息系统事件做出初步的分析判断。若是电源接触不好、物理连线松动或者能在最短时间内自行解决的信息系统问题,及时按照有关操作规程进行故障处理,并报领导小组备案;否则,应急处理工作小组将故障大致定性为设备故障、线路故障、软件故障等故障之一,及时告知领导小组和受影响的相关部门,并采取措施避免事件影响范围的扩大。
应急处理工作小组向领导小组报告,在领导小组的授权后启动相应的应急预案。针对灾难事件和影响重要业务运行的重大事件,还要及时向董事会进行报告。
应急处理工作小组根据故障类型及时与外部支持人员取得联系。其中,设备故障的,可与设备供应商和集成商联系;软件故障的,可与系统集成商联系,由系统集成商进行现场或远程技术支持;线路故障的,可与运营商联系,三方密切协作力求通信线路在短
时间内恢复正常。
应急处理工作小组在上级机构或外部支持人员的配合下,充分利用应急预案的资源准备,采取有力措施进行故障处理,及时恢复信息系统的正常工作状态。
应急处理工作小组通知业务部门信息系统恢复正常,并向领导小组报告故障处理的
基本情况。重大事件形成文字资料,以书面形式向上级报告。
总结整个处理过程中出现的问题,并及时改进应急预案。
现场应急处理
如遇到预知外界因素(如定时、定点停电)影响业务信息系统系统的正常运行,将根据有关部门的通知,提前安排技术人员到实地关闭信息系统设备并进行现场维护,直至外界因素消除。
如遇到不可抗力因素(如火灾)造成的信息系统系统故障时,接到通知的值班人员要快速到达现场,果断切断相关设备配电柜的电源,积极参与消除不可抗力因素,并及时将情况上报应急处理工作小组领导。
如遇到一般故障、严重故障和重大故障,影响信息系统的正常运行,值班人员要迅速、及时地赶到现场,进行相应突发事件的应急处理。
(7)保障措施
应急演练
为提高信息系统突发事件应急响应水平,信息技术部和相关部门应定期或不定期组织应急预案演练;检验应急预案各环节之间的通信、协调、指挥等是否符合快速、高效的要求。通过演习,进一步明确应急响应各岗位责任,对预案中存在的问题和不足及时补充、完善。
人员培训
为确保本应急预案有效运行,应定期或不定期地举办不同层次、不同类型的技术讲座或研讨会,以便不同岗位的应急人员能全面熟悉并熟练掌握突发事件的应急处理知识和技能。
硬件资源保障
为了在信息系统设备发生故障时能够尽量降低业务系统的受影响程度,须为相应的核心业务信息系统提供必要的备份设备与线缆等硬件资源,并且配备与现有设备兼容的设备,确保相似或兼容的设备可以在应急情况下调配使用。这些备份设备需预先采购并保存在专门位置。
文档资料准备
包括信息系统工程文档、维护手册、操作手册、设备配置参数、拓扑图以及 IP 地址规范及分布情况等。
(8) 技术支持保障
建立预警与应急处理的技术平台,进一步提高信息系统突发事件的发现和分析能力, 从技术上逐步实现发现、预警、处理、通报等多个环节和不同的业务信息系统、系统以 及相关部门之间应急处理的联动机制。
公众信息交流
在应急预案修订、演练的前后,应利用各种信息渠道进行宣传,并不定期的利用各 种活动,宣传信息系统等突发事件的应急处理规程及其预防措施等应急常识。
系统无法登录
系统无法正常登录一般由于应用服务器与数据库服务器之间网络连接异常或数据库 服务未启动导致,现场处理措施如下:
检查应用服务器与数据库服务器之间网络连接是否正常,若应用服务器与数据库服 务器之间网络连接异常,恢复应用服务器与数据库服务器网络解决,重新启动系统;应 用程序后台服务是否运行正常;
检查数据库服务器数据库服务是否运行正常,如数据库服务器服务未启动则启动数据库 服务器数据库服务,重新启动系统;
若以上方案均无法解决系统无法登录问题,抓取并保存系统出错信息及日志文件, 简单判断异常部位,通知系统维护相关人员,保留现场,分析查找原因。
系统应用连接数据库超时
数据库连接超时,一种情况是应用服务器与数据库服务器网络连接异常;另一种情 况是系统数据源出错,现场处理措施如:
应用服务器与数据库服务器网络连接异常,排除网络连接异常故障,重启数据库服 务器和应用服务器。
以上方案无法解决系统故障时,应停止系统后台服务,防止不知情用户继续投递数 据。抓取并保存系统出错信息及日志文件,简单判断异常部位,通知系统维护相关人员, 保留现场,分析查找原因。
应用服务启动正常,却无法访问系统
如果平台应用服务启动正常,无法访问系统。 现场处理措施如下:
系统应用程序包出现故障,需重新部署平台应用程序包;系统数据源出错,需重新 配置数据源。
数据库出错导致系统无法使用
数据库出现故障系统数据文件损坏,以系统管理员用户登录在应用服务器创建新的 表空间,导入最近的一个时间点的系统数据库备份文件到新建的表空间里,重新添加部 署系统数据源,进行恢复操作。操作过程中,应停止系统后台服务,防止不知情用户继 续投递数据。
操作系统故障
应用服务器或数据库服务器系统故障,导致系统无法正常运行,需重新安装操作系 统。应用服务器操作系统故障,重新安装操作系统,重新部署满意度系统。部署完毕启 动数据库服务和应用服务。
数据库服务器操作系统故障,重新安装操作系统,以系统管理员用户登录在应用服 务器客户端,创建新的表空间,导入最近的一个时间点的系统数据库备份文件到新建的 表空间里,重新添加部署系统数据源,进行恢复操作。
预防措施
针对上门服务过程中可能遇到的各种各样的风险,我公司总结多年维护服务经验, 针对一些可能出现的情况,制定了一系列预防处理措施,举例如下:
类型 |
事件 |
预防措施 |
处理 |
应用软件 |
无法启动软件可执 行文件 |
上门人员提前准备好各 类需维护软件安装程序 |
将应用软件数据文件备 份后,重新安装 |
软件打开过程中或 运行中异常错误关 闭 |
上门人员准备好安装程 序,操作系统优化和修 补软件,查杀病毒软件 |
判断出错原因 ,备份数 据,采取相关修复措施 |
|
操作系统 |
使用者本机操作系 统异常或系统资源 占用严重 |
准备好系统检查程序及 修补程序,以及查杀病 毒软件 |
告知使用者错误原因可 能类型,提出解决方案, 经使用者认可后采取相 应措施 |
B/S 结构系统,浏览 器异常或无法下载 控件 |
准备流氓软件清理程 序、修复浏览器软件、 查杀病毒软件 |
检查浏览器选项设置,分 析原因进行修复 |
(七)风险的规避措施
对于本项目,项目风险管理组织结构的最上层是项目经理,项目经理应该负起项目 风险管理的全面责任。在风险控制和规避方面我们将根据项目实际进度和任务充分分析 和评估各个风险,重点按照风险类型、严重程度、发生概率、减缓措施等内容来考虑。 本项目中前面所分析的各种风险我们将采取下表所示的控制和规避措施:
风险类型 |
严重程度 |
发生概率 |
主要控制和减缓措施 |
技术风险 |
大 |
中 |
由专家小组进行技术和方案的论证 |
费用风险 |
中 |
中 |
建议一整套费用控制和评价机制 |
时间风险 |
中 |
中 |
科学建立并规划好项目进度计划,项目总体建设方案 必须通过专家论证后再按计划实施 |
人力风险 |
中 |
低 |
建立一整套完善的项目评价和激励机制,充分调动项 目人员的积极性 |
管理风险 |
大 |
中 |
建立一整套科学的项目管理制度 |
需求变更 |
大 |
高 |
建立起一整套严格的需求变更控制流程,切实明确需 求变更时各方应当承担的责任和风险,在设计开发过 程中尽最大可能留出需求变更的余量 |
用户配合 |
中 |
中 |
加大各方面的协调和沟通力度,切实明确各方面的职 责和分工 |
除了在项目开始建设之前对风险进行详细分析和预测外,在系统建设过程中我们将 对风险控制做到即使跟踪和控制:
对于可能影响项目成功的风险的评估在项目综合计划书的编写过程中完成。
项目组任何成员或用户都可以提出问题或发现某种风险并将它记录到《风险记录表》 中。项目经理将针对解决风险和问题多种方案组织相关人员进行讨论,并将讨论最终结 果在《风险记录表》中。
一个预料之中的风险事件发生或没发生,对实际风险事件后果的评估,对风险发生 严重程度极其发生概率的评估,以及风险控制和管理方案应进行及时的更新和调整。
- 通讯安全
如信息被窃听或篡改等,而为了使安全更有保障,整个系统会实施对网络访问的限制,
应用防火墙技术与安全监控的体系等来实现,并使信息可保障不受到不合法用户的访
问;而且其对于数据的传输可以实现加密处理,从而使信息的传递更加安全。对网络的访问权进行限制,可根据路由器及交换机等各类主要的网络设施,对其进行有效配置与应用,保障经过授权进行访问的网络口令更具安全性及可靠性。实施数据的传送,先要生成秘钥,再根据秘钥把数据做加密处理。所使用加密系统 的密钥应能够做改动,并且应可支持在传输与存储的过程中进行加密或 者解密的处置; 而数据的传送若受到第三方的改变,能经过密钥的管理来准确 知晓已被篡改的情况而且 进行及时处置。
- 访问控制策略
访问控制属于网络数据的访问中实现安全防范并进行保护最为重要的方法,其主要功能为保障各类网络资源可不受第三者的不合法应用及不正常状态的访问。该系统基本使用的是根据身份访问实施的控制策略对数据系统的安全性进防护。而应用所发布出的授权号码及口令可对访问者身份进行审核,从而可有效预防不合法的攻击。
4. 安全保密措施
基于网络物理层、网络层、系统层、应用层、管理层安全风险分析,进行各层次网络安全设计。从网络结构、访问控制、安全审计、边界完整性检查、入侵防范、恶意代码防范和网络设备防护的具体内容进行整体网络安全防护。
(1) 物理层的安全
网络的物理安全风险主要指网络周边环境和物理特性引起的网络设备和线路的不 可用,而造成网络系统的不可用。它是整个网络系统安全的前提。如:
l 设备被盗、被毁坏
l 链路老化或被有意或者无意的破坏
l 因电子辐射造成信息泄露
l 设备意外故障、停电
l 地震、火灾、水灾等自然灾害
因此,专网在网络安全考虑时,首先要考虑物理安全。例如:设备被盗、被毁坏; 设备老化、意外故障;计算机系统通过无线电辐射泄露秘密信息等。除此之外,由于专 网涉及核心密与普密两个不同的密级,因此建议利用“物理隔离 ”技术,将两个网络从 物理上隔断而保证逻辑上连通实现所谓的“信息摆渡 ”。
(2) 网络层的安全
数据传输风险分析
1、重要数据业务数据泄漏
由于在同级局域网和上下级网络数据传输线路之间存在被窃听的威胁,同时局域网络内部也存在着内部攻击行为,其中包括登录通行字和一些敏感信息,可能被侵袭者搭线窃取和篡改,造成泄密。如果没有专门的软件或硬件对数据进行控制,所有的广域网
通信都将不受限制地进行传输,因此任何一个对通信进行监测的人都可以对通信数据进行截取。这种形式的”攻击”是相对比较容易成功的, 只要使用现在可以很容易得到的“包检测”软件即可。
2、重要数据被破坏
由于目前尚无安全的数据库及个人终端安全保护措施,还不能抵御来自网络上的各种对数据库及个人终端的攻击。同时一旦不法分子针对网上传输数据作出伪造、删除、窃取、窜改等攻击,都将造成十分严重的影响和损失。存储数据对于政府机关来说极为重要,如果由于通信线路的质量原因或者人为的恶意篡改, 都将导致难以想象的后果,
这也是网络犯罪的最大特征。
(1) 网络边界风险分析
对专网中任意节点来说,其它所有网络节点都是不可信任域,都可能对该系统造成一定的安全威胁。
一方面风险来自于内部,入侵者利用 Sniffer 等嗅探程序通过网络探测、扫描网络及操作系统存在的安全漏洞,如网络 IP 地址、应用操作系统的类型、开放哪些 TCP端口号、系统保存用户名和口令等安全信息的关键文件等,并采用相应的攻击程序对内网进行攻击。
入侵者通过网络监听等先进手段获得内部网用户的用户名、口令等信息,进
而假冒内部合法身份进行非法登录,窃取内部网重要信息。
入侵者通过拒绝服务攻击使服务器超负荷工作,使服务器拒绝系统访问服务
甚至系统瘫痪。另一方面风险来自外部,有必要将公开服务器的外网及内部网络进行必要的隔离,避免网络结构信息外泄;同时还要对外网服务请求加以过滤,只允许正常通信的数据包到达相应主机,其它的请求服务在到达主机之前就应该遭到拒绝。
(3) 系统层的安全
系统级的安全风险分析主要针对专网采用的操作系统、数据库、及相关商用
产品的安全漏洞和病毒威胁进行分析。专网通常采用的操作系统本身在安全方面
考虑较少,服务器、数据库的安全级别较低,存在一些安全隐患。同时病毒也是
系统安全的主要威胁,所有这些都造成了系统安全的脆弱性。
(4) 应用层的安全
专用网络应用系统中主要存在以下安全风险:对系统的非法访问;用户提交
的业务信息被监听或修改;用户对成功提交的业务进行事后抵赖;服务系统伪装,
骗取用户口令。
由于专用网络对外提供 WWW 服务、EMAIL 服务、DNS 服务等,因此预防外网
的非法用户对服务器攻击。下面从身份认证、DNS、WWW、邮件、文件服务等几方
面分别加以详细说明:
1、身份认证漏洞
服务系统登录和主机登录使用的是静态口令,口令在一定时间内是不变的,
且在数据库中有存储记录,可重复使用。这样非法用户通过网络窃听,非法数据
库访问,穷举攻击,重放攻击等手段很容易得到这种静态口令,然后,利用口令,
可对资源非法访问和越权操作。
2、DNS 服务威胁
DNS 域名服务为互联网应用提供了极大的灵活性。几乎所有的网络应用均利
用域名服务。但是,域名服务通常为黑客提供了入侵网络的有用信息,如服务器
的 IP、操作系统信息、推导出可能的网络结构等。
同时,新发现的针对 BIND-NDS 实现的安全漏洞也开始发现,而绝大多数的
域名系统均存在类似的问题。如由于 DNS 查询使用无连接的 UDP 协议,利用可
3、WWW 服务漏洞
网站是政府对外宣传、开展业务的重要基地,也是国家政府上网工程重要组
成部分。由于其重要性,理所当然的成为黑客攻击的首选目标之一。
网站经常成为互联网用户访问政府内部资源的通道之一,如通过中间件访问
主机系统,通过数据库连接部件访问数据库,利用 CGI 访问本地文件系统或网络
系统中其它资源。Web 服务器越来越复杂,其被发现的安全漏洞越来越多。
4、电子邮件系统漏洞
电子邮件为网系统用户提供电子邮件应用。内部网用户可通过拔号或其它方
式进行电子邮件发送和接收这就存在被黑客跟踪或收到一些恶意程序、病毒程序
等,由于许多用户安全意识比较淡薄,对一些来历不明的邮件,没有警惕性,给
入侵者提供机会,给系统带来不安全因素。
(5) 管理层的安全
再安全的网络设备离不开人的管理,再好的安全策略最终要靠人来实现,因
此管理是整个网络安全中最为重要的一环,尤其是对于一个比较庞大和复杂的网
络,更是如此。因此有必要认真分析管理带来的安全风险,并采取相应安全措施。
电子政务按照国家计算机和网络的关于安全管理条例,如《计算站场地安全
要求》、《中华人民共和国计算机信息系统安全保护条例》等,制订安全管理制
度。
建立全新网络安全机制,必须深刻理解网络并能提供直接的解决方案,因此,
最可行的做法是管理制度和管理解决方案的结合。
1、安全平台模型
对于实现平台的安全建设策略,主要可以通过管理,评估,检测和防止 4 点
来概括。
其中,安全制度管理包括了管理制度与管理手段,如审计措施等;
安全技术管理是指包括设备管理、网络管理、系统管理(包括中间件)、应
用管理和用户管理等在内的综合管理系统;
安全措施分别从物理安全、网络安全、系统安全、应用安全四个层次上进行,每一安全措施根据不同的风险采取不同的应对措施。
安全体系的建立应充分地分析信息系统的特点及潜在的风险,参照国际上先
进安全体系理论以及现有的安全标准规范,尽量采用有自主知识产权和经权威部门认证的国内安全产品,构筑整体的安全保障环境。
平台的网络及应用系统建成后,特点是网络规模大、结构清晰、应用系统丰 富、安全性要求相对高。总体来说应从设施物理层安全、网络层安全、主机系统安全、应用系统安全、系统容灾、安全审计及安全管理制度等角度分析和建立安全防护体系。
物理层安全对策
保证计算机信息系统各种设备的物理安全是整个计算机信息系统安全的前提。物理安全是保护计算机网络设备、设施以及其它媒体免遭地震、水灾、火灾、环境事故以及人为操作失误或错误及各种计算机犯罪行为导致的破坏过程。主要包括以下几方面:
环境安全:对系统所在环境的安全保护,如区域保护和灾难保护;
设备安全:包括设备的防盗、防毁、防电磁信息辐射泄漏、抗电磁干扰及电源保护等;
介质安全:包括媒体数据的安全及媒体本身的安全。为保证网络的正常运行,在物理安全方面应采取如下措施:
产品保障方面:指产品采购、运输、安装等方面的安全措施。
运行安全方面:网络中的设备,特别是安全类产品在使用过程中,必须能够从生成厂家或供货单位得到迅速的技术支持服务;一些关键设备和系统,应设置备份系统。
防电磁辐射方面:所有重要涉密的设备都需安装防电磁辐射产品。
保安方面:针对防盗、防火、网络系统所有网络设备、计算机、安全设备的安全防护等方面。
(1) 网络层安全对策
基于专网互连互通的特点,从网络层次考虑,设计将网络系统设计成一个支持不同级别用户或用户群的安全网络,该网在保证系统内部网络安全的同时,还实现与互联网的安全互连。具体而言,采用下面的安全措施实现网络系统的安全。 内网与互联网门户之间信息传输的安全,可通过安全设备(网闸)实现专网与互联网之间的安全隔离。
(2) 系统层安全对策
操作系统安全
操作系统是应用软件和服务运行的公共平台,操作系统安全漏洞是网络入侵的重要 因素。因此,首先必须选择安全的操作系统平台。
对于重要的服务器系统,应该选择安全级别更高的操作系统,或者通过改造操作系 统达到 B1 级以上,即实现强制型访问控制功能;具备强制用户人证机制(比如一次性口令或基于公钥的证书认证),不在网络中明码传输口令或密钥。特 别值得注意的是,操作系统设计上的安全级别并不能保证系统在实现和配
置上的没有安全漏洞,因此,操作系统的安全必须和下文中介绍的系统安全管理手段相结合。
另外还需说明的是,除了系统管理员以外,绝大多数用户是通过运行在服务器操作系统之上的应用系统来访问信息的,因此,操作系统安全设计的目标在于防止黑客入侵系统和非授权的访问,业务信息的保密应该主要有应用系统完成。
应用软件和数据库系统安全
软件的使用需要经过有关部门的认证,从网络下载的免费软件不经过检查与批准一律不许使用。
数据库系统必须具备用户认证、基于角色或用户组、数据视图的访问控制功能,防止入侵者越过应用系统的控制直接访问数据库。
为了防止万一操作系统或应用系统被攻破,使得入侵者能够直接访问数据库, 对于机密字段,可以考虑在数据存储/读取时加密/解密。但是由于对性能和管理 的影响,数据库字段的加密一定要慎重考虑。
系统安全管理和系统病毒防范
计算机系统设计上的安全不能防止系统实现或配置中存在的漏洞。事实上,系统的漏洞多数发生在系统的实现和配置阶段。系统的安全管理主要活动包括:系统脆弱性检测与打补丁,定期扫描系统的安全漏洞,及时联系操作系统厂商和国内外安全事件协中心,弥补操作系统设计上的安全漏洞。
用户管理,包括口令调协、用户环境、授权管理等。系统服务管理和环境设置管理。
主机系统定期检查系统的审计记录,分析可能的入侵或入侵企图。在现可疑的异常 的系统状态或可疑的用户行为时,立即向管理员告警。
病毒防范是系统安全管理的一项重要内容。实时地监测、定期的扫描与杀除病毒;通过厂商及时更新病毒特征码库,跟踪最新病毒。
应用系统安全对策
应用系统面临的主要安全威胁是因非授权的数据访问而造成的信息泄密和内部人 员滥用权力、有意犯罪。应用系统安全设计的主要目标是保证信息的保密性与完整性,主要依赖认证、加密、访问控制、数字签名等安全服务来完成。应用系统主要做如下安 全设置:本地认证,登录双向身份认证(包括数字证
书验证,私钥签名验证),权限控制,数据的数字签名与认证等。
l
(3) 系统容灾对策
对于一个大型计算机网络和分布式应用系统,精确计算分配系统可靠性指标十分复杂,涉及到端系统、互联设备、物理线路等各个层次的各种实体,一般需要考虑平均无故障时间(MTBF)、平均故障时间(MTTF)、平均故障修复时间(MTTR), 和可用性(Availability)四项指标。采用最终用户可用性指标来衡量整个系统的可靠性,是一种 简便易行,便于工程测量的方法。
为了保证系统的安全可靠,除了场地、环境安全应遵循的有关标准外,建议采取以下容错容灾措施:
选用高可靠性的计算机系统和网络设备,重要的服务器系统和网络中心的关键 设备都实现了硬件或配件冗余,具备容错功能。
数据备份,配置磁带机,可对系统和重要数据定期或实时备份。
(4) 安全审计对策
安全审计是一个安全的网络必须支持的功能特性,审计是记录用户使用计算机网络系统进行所有活动的过程,它是提高安全性的重要工具。它不仅能够识别谁访问了系统,还能指出系统正被怎样地使用。对于确定是否有网络攻击的情况.
审计信息对于确定问题和攻击源很重要。同时,系统事件的记录能够更迅速和系统网络层层次的安全审计:主要利用防火墙的审计功能、网络监控与入侵检测系统来实现。
系统的安全审计:主要是利用各种操作系统和应用软件系统的审计功能实现。包括,用户访问时间、操作记录、系统运行信息、资源占用等。
对信息内容的安全审计。
采用各层次的安全审计措施是网络安全系统的重要组成部分,而对审计数据的维护是其重要内容之一。建议网络系统建立安全审计中心或审计小组,对所有各层次的审计数据进行统一处理与管理。
(5) 安全管理对策
管理性和技术性的安全措施是相辅相成的,在对技术性措施进行设计的同时,必须考虑安全管理措施。因为诸多的不安全因素恰恰反映在组织管理和人员使用方面,而这又是计算机网络安全所必须考虑的基本问题,所以应引起各计算机网络应用部门 领导的重视。
随着安全工程的规划与实施,必须建立健全一套自上而下的安全组织机构、管理有 关的规章制度与系统安全工程层次结构相对应,安全组织结构也采用分层结构。建议指 定专门机构和人员,负责全网所有日常安全管理活动,主要职责有:
l 监视系统运行和安全告警信息
l 系统各个层次审计与日志信息的常规分析
l 安全设备的常规设置与维护
l 安全策略的规划、制定与实施
l 安全事件的处理等
5. 系统访问及应用安全设计
(1) 身份鉴别
应提供专用的登录控制模块对登录用户进行身份标识和鉴别;
应提供登录失败处理功能,可采取结束会话、限制非法登录次数和自动退出等措施;
应启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能,并根据安全策略配置相关参数;
应提供用户身份标识唯一和鉴别信息复杂度检查功能,保证应用系统中不存在重复用户身份标识,身份鉴别信息不易被冒用;
应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别。
实现方式
集成身份认证系统,保证用户的合法性。系统内的每个角色有可靠的身份识别,访问权限控制,防止对信息的非法使用、调阅、修改和破坏。
信息在存储和传送过程中采取加密保护。
具有防非法修改和防静态分析等自身防护功能。
采取应用系统运行日志、应用系统操作日志、系统运行监控和故障报警等手段,加强对系统运行进行监控 提供专用的登录控制模块对登录用户进行身份标识和鉴别。包括登录认证、长时间未操作提示、错误登录提示等。利用 SESSION 技术实现当其空闲操作的时间超过规定值(通常为 l0min 以内)后,在该用户需要执行其它操作之前,对该用户重新进行身份鉴别,要求重新登录。系统提醒 SESSION(空闲操作的时间超过规定值)时间,并自动限制用户设置时间在 l0min 以内。
提供登录失败处理功能,可采取结束会话、限制非法登录次数和自动退出等措施。
系统提供设置“允许用户失败登录次数”功能,,并自动控制用户设置次数小于等于五次。并提供设置:“用户失败登录次数达到设定值时,选择操作选项,包括:1)禁止使用该程序(登录);2)延长一定时间后再允许登录,并可以设置延长的具体时间”。
提供用户身份标识唯一和鉴别信息复杂度检查功能,保证应用系统中不存在重复用户身 份标识,身份鉴别信息不易被冒用。管理员设置标识符规则(标识符规则可由用户确定,包括长度、组成等),系统自动生成标准符,标识符一经生成就不能修改和删除,管理员每次设置的标识符规则不同相同,以确保标识符的唯一性。同时,系统不提供标识符真正从系统中物理删除,只是提醒将该标识符标记为删除状态。非认证用户无法设置标识符规则和生成标识符。
(2) 访问控制
基本要求
应提供访问控制功能控制用户组/用户对系统功能和用户数据的访问; 应由授权主体配置访问控制策略,并严格限制默认用户的访问权限;
应提供访问控制功能,依据安全策略控制用户对文件、数据库表等客体的访问;
访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作;应授予不同帐户为完成各自承担任务所需的最小权限,并在它们之间形成相
互制约的关系;
应具有对重要信息资源设置敏感标记的功能;
应依据安全策略严格控制用户对有敏感标记重要信息资源的操作。
实现方式
提供访问控制功能控制用户组/用户对系统功能和用户数据的访问
由授权主体配置访问控制策略,并严格限制默认用户的访问权限,系统提供系统数据是否涉密属性设置功能,并提供强制访问涉密数据控制策略,包括无、只读、读写。
提供访问控制功能,依据安全策略控制用户对文件、数据库表等客体的访问。访问控制的覆盖范围包括与资源访问相关的主体、客体及它们之间的操作; 授予不同帐户为完成各自承担任务所需的最小权限,并在它们之间形成相互
制约的关系;利用应用支撑平台的统一用户管理服务,可以实现角色的设置及角色权限授予、回收。系统默认拥有系统管理人员(系统管理员、安全保密管理员、安全审计员),系统用户(重要、一般等)三类角色。
(3) 安全设计
基本要求
应提供覆盖到每个用户的安全审计功能,对应用系统重要安全事件进行审计;应保证无法单独中断审计进程,无法删除、修改或覆盖审计记录;
审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等;
应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。
实现方式
通过部署网络与数据库审计系统,并结合集中安全管理平台审计功能,综合实现主机安全审计要求。
安全审计范围至少覆盖应用中间件、数据库及系统本身的身份鉴别、访问控制、数据完整性、数据库维护等功能。审计记录信息包括被审计对象、时间、审计人、具体操作,能对对安全事件的事后追查提供足够的信息。
安全审计与身份鉴别、访问控制、数据完整性等安全功能的设计紧密结合, 并为下述可审计事件产生审计记录:
审计功能的启动和关闭:记录审计功能的启动和关闭时间、操作人员、是否成功、
故障编号等;
系统内用户增加、删除:记录用户增加、删除时间、操作人、操作是否成功、故障编号等;
用户权限的更改:记录用户权限更改的时间、更改人、更改值、是否成功、故障编号等;
系统管理员、系统安全员、审计员和一般操作员所实施的操作:记录操作员类型、
操作员编号、操作、操作时间、是否成功、故障编号等;
其它与系统安全有关的事件或专门定义的可审计事件:系统提供审计对象和审记事件的定义,以及审计记录信息的定义,并提供标准的开发接口,便于扩展开发。
审记系统采用松偶合设计技术,数据与采集功能独立,当审计系统出现异常时,存储的审计记录不会受到影响。系统审计记录保存周期默认大于等于六个月
(用户可以自行设置,但系统会限制其设置周期),在小于六个月时,系统不提供用户对审计记录的清空和删除功能。
(4) 完整性、保密性
基本要求
应采用约定通信会话方式的方法保证通信过程中数据的完整性; 应采用商用密码管理要求的技术保证数据完整;
应对通信过程中的完整的通信过程加密。
实现方式
采用约定通信会话方式的方法保证通信过程中数据的完整性; 采用 MD5 单向加密密码技术保证通信过程中数据的完整性;
通信双方建立连接之前,应用系统利用密码技术进行会话初始化验证;
对通信过程中的整个报文或会话过程采用 MD5 单向加密密码技术进行加密。
抗抵赖
通过 CA 数字证书,对重点监控企业提交的数据进行数字签名,保证数据的真实性, 实现抗抵赖功能。
剩余资源保护和控制
基本要求
应保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除, 无论这些信息是存放在硬盘上还是在内存中;
应保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配 给其他用户前得到完全清除;
实现方式
通过对应用系统和数据库在系统开发时的安全代码设计实现。
保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除,无 论这些信息是存放在硬盘上还是在内存中;
保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给 其他用户前得到完全清除;
当应用系统的通信双方中的一方在一段时间内未作任何响应,用户可以设置多少秒 后,另一方应能够自动结束会话;
能够对系统的最大并发会话连接数进行限制; 能够对单个帐户的多重并发会话进 行限制。
能够对一个时间段内可能的并发会话连接数进行限制
能够对一个访问帐户或一个请求进程占用的资源分配最大限额和最小限额能够对系统服务水平降低到预先规定的最小值进行检测和报警,如审计日志空间不足提醒等。
软件容错
基本要求
在故障发生时,应用系统应能够继续提供一部分功能,确保能够实施必要的措施;
应提供数据有效性检验功能,保证通过人机接口输入或通过通信接口输入的数据格 式或长度符合系统设定要求;
应提供自动保护功能,当故障发生时自动保护当前所有状态,保证系统能够进行恢复。
实现方式
在故障发生时,应用系统能够继续提供一部分功能,如非登录用户的公共功能。能够实施必要的措施
提供数据有效性检验功能,保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求;
采用集群技术和备份技术,提供自动保护功能,当故障发生时自动保护当前所有状态,保证系统能够进行恢复。
软件程序应当能够自动保护当前所有状态,保证系统能够进行恢复,例如记录故障发生时的系统状态功能(系统状态的快照),便于事后分析故障原因。
在程序开发时通过安全编程实现。
二、项目效益分析
(一)社会效益
“社会效益”是社会效果和社会利益的总称。社会效果=某一特定活动在社会内产生的影响和结果,社会利益=对社会发展有益的好处或社会成员共同获得的利益;其表达式为:社会效益=社会活动的产出量/社会活动的投入量;其文字叙述是社会效益就是指某种特定活动对社会发展所起推动作用的程度。
本项目的实施,将取得以下的社会效益:
- 有利于缓解人民群众“看病难、看病贵”问题
项目的建设旨在解决卫生机构信息基础建设规范化和信息互联互通、协同服务上,系统的建成有利于缓解人民群众“看病难,看病贵”的问题。
近年来,“看病难、看病贵”成为社会关注的焦点。造成上述问题的原因之一是卫生服务中的卫生资源分布不均衡以及信息不对称。同时卫生信息化的建设长期着眼于自身业务规范和能力建设,从服务对象角度进行整合和深化,使数据能互联互通,提高了人民群众享受卫生服务的能力。健康档案中医疗服务数据共享,减少不必要的重复检验检查和重复用药;通过支撑卫生机构之间的信息共享和协同服务,促进纵向医疗资源整合;通过为建立专业性影像会诊中心、检验中心、心电中心、病理中心提供信息平台,促进改善对医疗资源的配置效率。
- 有利于提高人民群众健康水平,提高合理、安全医疗水平
本项目建设后,可将各卫生机构内部的公共卫生资源从全市的角度进行整合,使人民群众享受到从预防疾病到治疗疾病、从日常保健到病后康复、从社区服务到专科服务的全方位、多层次、全过程的整合服务。以电子健康档案为核心的区域卫生信息化建设是国家医改方案中提出的一项重要任务,是实现人人享有基本医疗卫生服务的重要支撑。建立市民电子健康档案是社区进行社区健康诊断、健康管理,行使个性化健康服务并实施健康监测的最有效途径,其意义在国际上得到普遍共识。
同时,通过电子健康档案的建设,使卫生服务更加“以人为本”,使群众享受到个性化的卫生服务,健康档案中各类数据的综合采集和使用,能充分保障卫生服务专业的需求,使卫生服务更加能贴近居民,支撑起惠及xx市全体居民的一张卫生保护网,通过健康档案的利用,对市民健康有了充分的了解和评估,是现实社区干预,实现健康城区目标的重要依据。项目的建成更能使卫生服务具备更高的可及性,更有利于提高医疗卫生机构的服务质量、服务水平和服务效率,提高了卫生服务能力,从而提高了人民群众的健康水平。
- 有利于促进本市卫生服务水平、质量、效率的提高
xx市基于全民健康信息平台的死亡管理系统工程的建设将促进卫生业务管理模式与流程的优化创新,整体推动本市卫生服务运营效率。医疗服务方面,减少不必要的就医环节,引导合理的诊疗路径,让医务人员将精力聚焦在医疗业务本身,提高诊疗过程的效率,让患者在医院的时间减少,客观上也降低了医院的运营成本。公共卫生方面,更全面地掌握本市公共卫生的业务信息,促进公共卫生管理与服务模式的优化,推动政策机制的科学制定,增强本市公共卫生体系的整体能效,从而提升群体健康的预防控制,加快影响群体健康的环境因素的改善。药品保障方面,重点加强药品使用环节的跟踪分析,能够及时掌握全市医疗机构的药品使用数量、费用等,促进药品供应流程的优化,提高药品保障效率。综合管理方面,能够及时掌握全市卫生资源信息、市民健康信息、医疗机构运营信息、公共卫生管理信息等,缓解了传统的逐级上报机制,减少了人工核对的繁琐环节,提升了各项指标的准确性、及时性,提高综合管理决策的效率。
本项目的建设,将大大改善医疗卫生行业的服务水平,促进和保障全民健康,是关于民生的一件大事。同时,也将推动与民生有关的信息化工程在智慧城市中的建设步伐,社会公众在切实享受到智慧卫生建设成果的同时,也将对其他关乎民生的工程提出更高要求,改善市民生活的要求,不断提升管理效率,提高服务质量,使广大市民、企业切实感受到智慧城市建设带来的便捷高效,对智慧城市建设本身也是一个促进,为经济社会发展和市民生活水平提高提供有力支撑。
- 有利于保障城市公共安全
公共卫生信息化是实现公共卫生服务重要的组成部分,突发事件层出不穷,公共卫生保障任重道远,没有相互联动的信息系统的支撑,没有日常公共卫生安全各类相关因素的监测和分析,没有各类应对系统的联动处置,难以在事件发生后有效响应,更难以达到早发现、早干预、早处置的要求,将危机化解在萌芽。
- 有利于加强卫生全行业管理
卫生服务的管理需要大量的基础数据予以支撑,通过本项目的建设,可实现对卫生服务需求和供给中能力、水平和质量的实时动态监测和监管,实现多角度、多维度的分析和利用,满足对医疗卫生各类各项服务评估的需求,实现卫生管理和决策的信息化、现代化。本项目同时还提高了政府统筹规划卫生资源的能力,使卫生服务供给具备更高效的数据保障。
- 提升本市卫生信息化的整体水平并保有可持续发展能力
xx市区域卫生平台建设工程是全面建设具有xx市特色的区域卫生信息化模式的重要里程碑。
建设覆盖全市各级公立医疗机构的健康信息数据共享和交换平台,按照卫生部健康档案基本架构和数据标准,遵循“自动建档、自动更新”的原则,通过健康信息数据共享和交换平台,为市民建立涵盖个人基本信息和主要卫生服务记录的电子健康档案,提供健康档案和检验检查报告网上查询、医疗服务网上预约、健康管理咨询等服务,并支撑医院间的重复检验检查和用药智能提醒、影像会诊、预约等协同医疗服务,实现电子健康档案“记录一生、管理一生、服务一生”的目标,从而提升全市卫生信息化的水平。
通过本项目的建设,将构建xx市区域卫生信息化总体框架,为十三五乃至更长远的持续发展提供支撑。
- 促进科技自主创新,促进xx市及省信息产业的发展
本项目建设中,将引入卫生云计算的探索和试点工作。对全民健康信息平台数据中心端适当考虑利用集约化、虚拟化等云计算技术,支撑面向全市卫生服务的需求,满足不断增长的业务量的需求。同时,结合医院基于电子病历的医院信息系统改造或整合、xx市卫生健康网等的建设,将出现类似于远程健康管理、院区跟踪和监护等业态,催生物联网相关产业的发展。智慧卫生将来的发展趋势将是根据应用需求,采用先进的技术和平台,引入创新运营模式,整合网络、软件、硬件和信息资源,用于海量数据的采集、传输、处理、存储和备份等,向社会提供技术先进、灵活高效、标准统一、安全稳定、高度共享的一体化硬件设施、开发平台和软件产品服务窗口,满足日益增长的城市管理、公共服务、社区服务、产业推进、软件开发等领域的需求。
- 树立本市在区域卫生信息化整体解决能力的国内地位
从本市卫生信息化领域来看,通过项目建设,将构建本市区域卫生信息化整体框架,为后续持续发展提供支撑;将建立本市卫生信息化管理保障机制,为信息化工程的实施管理提供保障;将培养一批擅长卫生信息化的人才队伍,促进卫生信息化良好的生态发展环境。
从本市信息化发展来看,本工程将着力推进医疗卫生方面的人本化、智慧化建设,在现有医疗卫生信息化成果基础上,按照国家医药卫生事业改革的要求,建立起面向个人的健康档案全过程记录,并在此基础上,提供更为优质、安全、廉价的医疗卫生服务。这项工作对整个社会具有非常重大的影响,也可以直接让老百姓切身感受到区域卫生信息化建设所带来的实惠,使百姓能共享建设成果。因此,本工程在xx市区域卫生信息化建设中具有举足轻重的地位。
从国家卫生信息化发展来看,项目的成功建设将在全国形成示范,并带动其它地区卫生信息化的发展,并在技术框架、组织管理等方面给出重要的参照价值。
另外,xx市基于全民健康信息平台的死亡管理系统建设工程无论从涉及医疗机构范围、覆盖人群数量、资金投入规模等各方面,也是属于国内地区名列前茅的区域卫生信息化工程。工程成功建设后,必将在国内形成重大的影响,并树立本市在卫生信息化整体解决能力的地位。
在社会效益上,本项目是医疗卫生改革的重要组成部分,通过支撑医疗卫生体制改革,其优化卫生资源的配置,有效缓解“看病难、看病贵”,提高城市卫生服务水平及质量。整体提升本市卫生信息化水平,提高卫生机构管理效率。促进科技自主创新,促进xx市信息产业的发展。
(二)经济效益
1、 降低医疗卫生机构的运行成本
通过项目的建设,在各级各类卫生机构内使工作流程进一步优化,人员得以精简、工作效率得以提高、使各类卫生资源得到更合理的利用,并使卫生服务达到最优化,从而提高了服务能力,增加了服务数量,同时使管理人员决策及时、准确、更科学化,使上下级的信息流通结构更趋合理;提高卫生机构的信誉与知名度,扩大影响力,增强竞争力;提高了服务对象的满意度等。
有专家研究后发现,通过信息化后,在基层医疗卫生机构,病人就医等待时间从30分钟减少到8分钟,工作人员由原来的5人减少到3人,可以看出,大大节约了整个社会成本同时也节约了卫生行业的自身成本。
2、 减少卫生服务中不必要的浪费
项目的建设减少了过去由于信息不能共享造成的院际重复检查、重复用药等问题,直接减少了卫生资源的浪费。
在减少重复开药方面,如果按照全年医疗费用100亿元进行估算,每年至少10%的费用是重复医疗,假定通过本项目的建设可以减少50%的重复医疗,大约每年度可节约5亿元医疗费用。
项目使xx市民能充分享受到卫生现代化、信息化带来的好处,使政府投入的每一分钱能转化成卫生保健能力的提高,转化为卫生行业能力的提高,最终收益的是全体xx市市民。
3、 提高卫生服务整体运营效率
xx市基于全民健康信息平台的死亡管理系统工程的建设将促进卫生业务管理模式与流程的优化创新,整体推动本市卫生服务运营效率。
医疗服务方面,基于市民电子健康档案,可以给予临床医生智能的信息提示,减少不必要的就医环节,引导合理的诊疗路径,让医务人员将精力聚焦在医疗业务本身,提高诊疗过程的效率。提供在线调阅检验检查报告、预约等便民服务手段,让患者在医院的时间减少,客观上也降低了医院的运营成本。
公共卫生方面,实现医院、公卫、基层机构的三级联动,减少基层的重复工作,提高业务驱动的及时性。同时,更全面地掌握本市公共卫生的业务信息,促进公共卫生管理与服务模式的优化,推动政策机制的科学制定,增强本市公共卫生体系的整体能效,从而提升群体健康的预防控制,加快影响群体健康的环境因素的改善。
综合管理方面,能够及时掌握全市卫生资源信息、市民健康信息、医疗机构运营信息、公共卫生管理信息等,缓解了传统的逐级上报机制,减少了人工核对的繁琐环节,提升了各项指标的准确性、及时性,提高综合管理决策的效率。
4、 拉动信息化产业内需
国家明确了“推进信息化和工业化融合”的战略方向,把它当作推进创新国家建设的重要环节和重要任务,鼓励在信息化建设方面增加投入,政府投资的信息化项目直接的经济效益体现就是拉动了信息化产业的内需,特别是重大信息化项目,直接促进了信息化产业的发展和产业链的形成,大型信息化项目的投入不但拉动了一级市场,也拉动了二级市场和次生市场,政府信息化投资带来的回报主要体现在两个方面:为政府带来市场收入的增加和运营成本的降低,运营成本的降低一种是直接的经济效益,一种是隐形的经济效益,直接的经济效益就是通过信息化管理使人员精简、工作效率提高、减少损失等。隐形的经济效益,政府各职能部门,特别是业务部门通过信息化后,减少了差错和事故的发生,特别在卫生行业,关乎个体生命和人群健康,差错减少和避免事故将带来更进一步的经济效益。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通