精华内容
下载资源
问答
  • 基于Ensemble的医院信息系统集成平台研究与探索
  • 智慧医疗解决居民“看病难、就医贵”和“三长一短”的医疗问题,使居民获得优质的医疗卫生服务、完整详实的健康档案信息和全生命周期的自我健康医疗管理,形成“小病在社区,大病进医院,康复回社区,健康进家庭”的...
  • word文件,90页,智慧医院信息系统集成平台建设方案,精品一级
  • 109基于Ensemble的医院信息系统集成平台研究与探索.pdf
  • 智慧医院信息系统集成平台建设方案
  • 智慧医院信息系统集成平台建设方案.pdf
  • 智慧医院信息系统集成平台建设方案.docx
  • 智慧方案
  • 【数据中心建设】92页智慧医院信息系统集成平台建设方案.doc
  • 按照最新《国家医疗健康信息医院卫生信息互联互通标准化成熟度测评方案(2017年版)》编写的医院信息系统集成方案,可用于互联互通成熟度测评建设
  • 智慧医院信息系统集成平台建设方案
  • 通过建设一个规范的系统集成平台,在IHE、DICOM、HL7等国际标准的基础上,制定覆盖医疗所有业务流程的系统集成规范,开发基于规范的系统集成平台,为遗留的、当前的以及将来的系统提供了一个统一且标准的数据交换和...
  • 1. 医院集成平台的核心本质到底是什么,如何规避风险? 分享一: 集成平台本质核心内容以SOA为服务架构,采用松耦合方式,达成消息服务标准化、数据字典标准化,满足业务需求。 结合电子病历评级、HIMMIS评级...

    1. 医院集成平台的核心本质到底是什么,如何规避风险? 

    医疗行业的系统集成相较其他行业起步较晚,采用的是总线式的集成方案。企业通常围绕集成引擎与医疗信息行业特有的信息交换标准(HL7、DICOM、IHE等)与信息内容标准(ICD、SNOMED、LONIC、C-DRGs、卫生信息数据元等)形成解决方案。

    医疗行业的集成平台主要集中解决系统集成、数据集成、公共服务集成的问题。并且在建立数据中心的基础上,集成平台还提供数据分析服务,提供医院信息平台所必须的数据交换管道与数据标准化核心能力。

    集成的方式总体分为以下两类:

    第一类,基于标准协议的集成。这种方式简单借鉴了国外现有医疗行业的协议和规范。其特点在于,基本上不使用适配器,所有的信息系统都需要改造,平台基本只起到消息路由的功能。因此,各个系统可能都需要进行现场改造,改造成本和风险相对较高。

    第二类,通过面向服务对业务和数据进行抽象与封装,这是目前比较成熟的方案。跟第一种方案类似,使用适配器,利用其现有信息系统接口能力连接各个系统,但其目标是尽量不改造或者是少改造业务系统,根据现有临床业务,对临床信息系统的服务在平台上进行封装,以保障安全、稳定的连接。

    一个独立的集成平台,通常包含的模块有:集成引擎、统一身份认证、公共服务管理、患者主索引管理、主数据管理、元数据管理、数据中心、统一患者视图与综合辅助决策分析系统。

     

    • 分享一:

    集成平台本质核心内容以SOA为服务架构,采用松耦合方式,达成消息服务标准化、数据字典标准化,满足业务需求。

    结合电子病历评级、HIMMIS评级、互联互通评测等业务需求,优化流程,提升信息化应用水平。建设集成平台不应该站在数据仓库或CDA业务需求来考虑,应该考虑平台整体信息化需求,突出重点,稳步推进系统实施。通过集成平台建设实践,集成平台将会降低HIS、EMR系统依赖性,从降低相关接口费用成本,同时新上线系统的基础服务可以复用,只需要考虑新增业务需求接口内容。集成平台采用多负载(如:F5、MQ集群)。针对推送推送失败内容,采用记录本地日志,启动重发机制(3次),若一直未成功具体分析接口数据内容。

    • 分享二:

    (1)集成平台的核心本质是为了数据交换和信息共享。随着信息化建设的不断建设,医院系统越来越多,操作系统、数据库不统一,各个系统之间的数据接口也越来越多,使医疗数据交换和信息共享的难度越来越大。

    (2)集成平台不是为了建设数据仓库,数据仓库只是建设集成平台用到的一个建设工具或者是方法。

    (3)集成平台并不是集中处理业务,所有业务还是基于原有的业务信息系统进行处理,集成平台只是一个打通这些不同业务信息系统数据的通道,让各个系统的数据能够互通,避免“信息孤岛”问题。

    目前医院的信息系统,包括HIS、LIS、CIS、NIS、EMR、PACS、RIS等,这些系统分布在不同的部门,形成了相对独立的部门级应用系统,而且系统供应商众多,软件架构多样,通信协议不一致,数据结构也千差万别,数据库系统多样而复杂,从而阻碍了信息的有效共享和交换。

    (4)集成平台建设,把分散的、异构的各个子系统的信息集成在一个信息共享的平台上,解决信息共享和交流问题,有效地实现医院信息系统一体化,方便医院部门内部和不同部门之间的交流和共享。

    如果业务系统信息交换失败,那么只是不能进行数据交换了,原有的业务系统还可以正常运转。不会受到太多的影响,后期数据可以修复后重新同步。

    2. 现在医院伙伴如何解决医疗影像的数据存储?

    热数据(主要指近两年,调阅较频繁)购买存储,安置医院机房,冷数据(历史数据)影像云存储。

    3. 医院信息中心在没上数据中心前,缺乏数据的主索引,如何协调统计不同厂商直接因为数据接口不规范产生的报表与HIS不一致问题?

    一般以各业务部门要求口径为准,没有技术手段统一。在医院上新系统前,由信息中心主导自上而下,先建立起院内的标准规范体系,以此体系来规范各系统开发厂商的开发行为,保证院内数据接口的规范性及标准型性。

    4. 关于智慧医院无线物联网建设,具体应用在哪些方面?

    目前集中在提升患者就医体验的自助机、诊间支付、病区结算等流程改变。

    5. 建议所有报表查询都尽量走CDR吗?

    在CDR数据采集实时的前提下,建议统计查询需求尽量由CDR承担。

    6. 系统间数据通讯是否可以都走平台,是否稳定安全。接口改造过程是否有特别难点?

    集成平台目前主要用于院内HIS与各医技系统检查申请-报告的信息交互,较为稳定,医技系统厂商众 多,标准化接口平台有优势,个性化接口需要HIS、平台、医技厂商三方改造。

    7. 医院集成平台建设前需要做哪些准备工作?是否都准备好?

    • 分享一:

    建设集成平台是对整个医院信息化体系架构的大幅度调整,其动作之大不亚于换HIS,领导的支持、预算的评估和资金到位很关键,而预算评估也不仅仅是评估购买集成平台软件的部分,而需要有硬件和安全产品的配套。

    • 分享二:

    集成的平台从系统层面来看是架设在整个业务系统之上的数据汇集层,以患者为中心串起所有的业务系统的数据流,在考虑整体硬件和安全产品配套的同时,还需要考虑数据同步对业务系统的影响,不要形成新的单点故障;框定预算时,也需要将个业务系统的数据接口、系统改造等预算资金考虑到位。

    • 分享三:

    (1)前期要做大量的论证,通过参观考察、查看文献资料,邀请专家等多种方式对平台产品进行对比,同时要摸查清楚自己医院信息化的问题是否可以用平台解决。

    (2)论证结果要得到领导的认可,资金要准备到位,同时相关技术人员储备也要开始。

    (3)硬件和安全设备预算要提前考虑在内,要估算采购的时间,提前做好准备。

    (4)各系统厂商改造能力的评估和费用评估,预留改造费用,做好协调准备。

    (5)对院内职工也要做适当的宣传。

    • 分享四:

    个人建议,集成平台建设前,需要考虑以下几个问题。

    (1)集成平台是否真的需要上,如果医院自己的信息系统还没有建设好,那么过急的部署集成平台,只会增加医院信息系统的使用和管理的复杂度。

    (2)选择合适的集成平台开发商。首先必须得了解院方的系统,各种数据标准和接口,对集成平台的开发能力等等,这些都是选择合适的集成商的标准。

    (3)梳理好医院现有数据。对现有系统的数据情况、关联关系,接口情况和数据访问关系等一系列情况进行梳理,在建设集成平台前,必须要自己掌握现有系统现状,才能更好的完成集成平台建设。

    (4)建设周期长,占用资金大,在建设之前必须做好人力和物力的准备

    (5)现有硬件资源是否满足集成平台需求,这部分也需要自摸家底,及时调整现有设备和架构,以满足集成平台建设。

    8. 目前有以电子病历为核心的医院建设和以数据中心为核心的医院建设,医院应如何选择?

    电子病历是数据中心的基础,只有高成熟度的电子病历才能保证患者就诊流程的闭环管理,数据质量从源头得到保障,为数据中心所用。

    两者并不冲突,电子病历数据已成为医院信息化建设的重点,这从管理部门对电子病历评级要求的重视程度上可以看出,因此医院信息化建设将围绕患者为中心来建立,数据中心建设的重点也应是电子病历及其周边业务的相关数据。

    9. 未来医院信息系统建设是否类似中台,全都是流程化自定义?

    应该不会,医院流程有其特殊性和专业性。在现今各医院,业务系统基本已经成熟,医院数据中台的更多的作用是通过对数据进行采集、计算、存储、加工,同时统一标准和口径,在数据统一之后,对数据进行解耦和分层,形成标准数据存储,使数据包含的业务信息能够沉淀下来,形成数据即服务的能力。

    10. 数据中心在实际业务中是否适用?都在说科研,可是科研对医院业务来说,只是小众。大众化的应用还是在临床,数据中心在临床应用中,有那些功能是医生比较喜欢的?

    部分注重临床管理的科主任,对于科室运营情况,绩效状况等较为感兴趣,临床一线往往承担大量上级主管部门的数据采集需求,这是数据中心可以为临床一线减负的地方。

    11. 检验、检查科室对数据分析也是有需求的,我们的检验科就很希望和其他医院有数据上的交流。先不谈数据交流,数据中心能在检验、检查的实际业务中发挥什么作用?

    检验检查科室往往只拥有自身科室的系统,只有少部分HIS相关数据,数据中心主要还是提供一个患者全流程数据,提供科室管理,科研所需相关数据。

    帮助串联起完整的就诊数据,关联其他业务系统的数据,以患者为中心将检验和检查业务数据整合到患者的就诊数据集中,同时也为检验检查业务提供个性化的决策支持。

    展开全文
  • 一、背景介绍基础集成平台是信息系统的基础设施环境,为各应用...在新一代医院信息系统(NGHIS)中,基础集成平台是医院内部各业务系统赖以运行的基础环境,没有基础集成平台,应用系统将无法完成用户身份认证和资源...

    一、背景介绍

    基础集成平台是信息系统的基础设施环境,为各应用系统提供公共基础设施(如ESB、消息中间件等),将各系统的通用基础服务功能(如用户管理、授权管理、配置管理等)从业务系统剥离出来,使得业务系统聚焦于业务流程和业务功能,实现更好的可管理性和用户体验。

    在新一代医院信息系统(NGHIS)中,基础集成平台是医院内部各业务系统赖以运行的基础环境,没有基础集成平台,应用系统将无法完成用户身份认证和资源访问控制。基础集成平台向应用系统开放用户认证、资源访问授权等服务接口,也可以通过医院服务总线与各业务系统之间保持松耦合关系;健康医疗云平台也需要通过基础集成平台实现统一用户认证、统一授权管理和统一配置管理。

    二、系统结构设计

    (一)NGHIS总体结构

    基础集成平台是医院基础信息平台和健康医疗云平台的重要基础设施,无论是医院端的应用系统还是云端的互联网平台,都需要基础集成平台提供用户认证、授权管理等基础服务。医院端应用主要存在三种形态:第一种是在院内安装部署数据库的松耦合系统(NGHIS,Next Generation HIS),完全基于院内局域网处理所有业务;第二种采用云+端结合的方式,在医院内部部署的简洁型HIS(CHIS,Compact HIS)作为应急系统,与云端服务协同配合使用,当广域网故障无法访问云端时,应急系统仍然可以满足医院的应急业务应用需要(包括挂号、收费、发药、医嘱处方处理、病历书写打印等);第三种是完全使用瘦客户端访问云端应用服务及数据的轻便型HIS(PHIS,PortableHIS),云端不可访问时暂停所有系统操作。


    图1 新一代医院信息系统总体结构

    (二)基础集成平台架构

    基础集成平台是不区分行业特性的通用应用软件基础设施,主要包括统一认证授权(UAA)、统一配置管理(UCM)、统一消息管理(UMM)、统一用户中心(UCM)和单点登录(SSO),基础集成平台单点登录推荐使用耶鲁大学的开源CAS,也可以使用其他第三方SSO系统。基于统一认证的用户账户信息,对外提供符合OpenID规范的用户认证服务(OpenID Provider),并分别针对C/S和B/S应用封装用户认证及权限管理的开发库(AA-Lib),统一认证中心的用户账户信息,通过用户账户复制(UAR)系统实现与外部第三方用户数据库(包括微软AD域用户和LDAP用户)的用户数据同步。社会组织模型管理提供一个简约的社会组织关系数据维护,主要包括法人及其组织架构、自然人、网格化社会组织结构等基础数据的管理与维护。


    图2 基础集成平台系统结构

    三、系统功能设计

    (一)统一认证授权(UAA)

    统一认证授权系统负责企业信息化应用的组织架构、用户账户、应用系统、用户授权等基础管理功能。

    统一认证授权系统设置系统管理员、机构管理员、应用管理员、授权管理员、客服员等用户角色。系统管理员负责平台全局性的基础数据维护,包括岗位信息维护、应用信息维护、顶级机构创建等。机构管理员负责下级机构创建、机构岗位设置(包括机构岗位目录、岗位员额编制、岗位权限等)、机构用户管理(包括用户创建、用户冻结、用户权限设置)等。应用管理员负责其所管辖应用系统的数据初始化(资源维护、角色维护、角色可访问资源设置等)、应用权限分配(机构应用角色、机构岗位角色、用户组角色)、应用授权查询(查询特定应用资源的权限分配情况,包括什么角色能够访问该资源、哪些机构具有该资源的访问权限、哪些机构岗位拥有该资源的访问权限、哪些用户拥有该资源的访问权限)等。授权管理员负责其所辖机构的权限分配管理工作,包括为机构岗位分配应用角色和对机构所属用户进行权限管理。客服员负责系统日常使用的用户授权运维,包括重置用户密码、用户权限查询、用户账户冻结及冻结用户重新激活等操作。

    1、系统管理

    系统管理是系统管理员用于维护平台公共基础信息的功能,主要包括岗位维护、机构维护和应用维护。

    图3 系统管理功能结构

    (1)岗位维护

    岗位是全系统共享的全局岗位,各机构只能从全局岗位中选取本机构启用的岗位,不能自行增加岗位名称,以保持岗位名称的一致性。

    岗位维护功能包括岗位的新增、修改,岗位名称一旦增加,就不允许删除,可以设置为禁用状态,禁用状态的岗位,不能被机构选取,但不影响已经启用该岗位的机构正常使用。

    (2)机构维护

    系统管理员的机构及机构岗位维护功能,包括新增顶级机构、机构信息修改和机构岗位设置,子机构的创建一般由机构管理员负责,系统管理员也可以通过组织管理功能创建子机构。

    创建顶级机构时,需要同步创建或指定一个机构管理员,由该机构管理员通过使用组织管理功能维护该顶级机构的下属机构维护和用户管理。

    (3)应用维护

    维护各应用系统的基本信息及其对应的应用管理员,应用管理员负责其所管理应用的基础数据维护和应用授权管理。

    2、组织管理

    组织管理是机构管理员用于对其所属机构的组织机构和用户进行管理的主要界面,功能包括子机构创建、机构信息修改、机构岗位设置以及用户管理。机构管理员只能管理其所属机构及下属机构的机构信息及用户信息。

    图4 组织管理功能结构

    (1)机构维护

    机构维护包括子机构新增、机构信息修改以及机构岗位管理。机构管理员只能维护其所属机构及下属机构的机构信息。

    l  子机构新增:机构管理员可以其所属机构的任意节点创建子机构,机构信息原则上不允许删除,不再启用的机构可以设置为禁用状态。

    l  机构信息修改:修改机构的基本信息。

    l  机构岗位设置:设置管辖机构启用哪些岗位,启用岗位的编制数量等,并维护各岗位的权限,当用户启用企业级授权体系时,用户所拥有的应用操作权限,将取决于该用户所处的岗位,用户的权限将随着岗位的变动而自然变动,减轻IT运维的权限管理工作。需要特别授予或特别限制的权限,由授权管理员针对用户进行个别设置。

    (2)用户管理

    用户管理功能主要用于管理用户账户及其权限,包括创建用户、用户冻结、用户激活、重置密码、用户权限设置等。

    l  用户账户新增:为尚未创建用户的员工创建用于身份认证的账户。机构管理员无权增加员工信息,员工信息需要统一用户中心或者人力资源管理系统进行维护。

    l  用户密码重置:重置某一用户的登录密码,用户密码被重置后,系统向用户发送一个随机的验证授权码,用户使用该验证授权码重新设置其登录密码。

    l  用户冻结:将正常的账号设置为冻结状态,被冻结的用户将不允许登录,冻结的用户被激活以后可以正常使用系统。

    l  用户激活:对被冻结的用户进行激活,以便该用户可以重新登录系统。

    l  用户权限设置:根据用户采用的授权体系,进入配套的界面对用户的权限进行维护设置。

    3、应用管理

    应用管理功能是应用管理员维护应用信息和分配应用权限的主要操作功能界面。当部署的应用系统数量较多时,一个应用管理员难以管理所有的应用系统,因此系统管理员在注册登记应用系统时,为应用系统指派了应用管理员。应用管理员通过应用管理功能,只能看到系统管理员为其分配的应用,并对这些应用系统的基础信息(包括应用资源、角色、角色可访问资源等)和应用权限分配进行管理。应用管理员无权注册应用,只能对系统管理员为其指派的应用进行管理。

    图5 应用管理功能结构

    (1)应用修改

    修改应用系统的基本信息(如版本信息、部署时间、运行状态等)。

    (2)资源维护

    维护应用系统的资源,包括新增、删除、修改等。

    (3)角色维护

    维护应用系统的角色信息,以及角色可访问的应用资源。

    (4)应用授权

    将应用系统的角色授予机构、机构岗位或用户组。应用管理员可以直接将应用角色授予各机构岗位及用户组,也可以只将应用角色分配到机构,再由机构管理员或授权管理员将机构所拥有的应用权限授权到岗位、用户组或用户。

    (5)授权查询

    对应用资源或角色的授权情况进行查询,便于了解应用是否存在授权安全风险,如敏感资源访问权限是否约束度不高的岗位、用户组或用户。

    4、授权管理

    授权管理是授权管理员日常授权管理工作的主要功能界面,包括设置或调整岗位权限和用户授权工作。授权管理员无权创建用户,只能对所属机构及其下属机构的用户进行权限管理。

    图6 授权管理功能结构

    (1)岗位权限管理

    维护授权管理员所属机构及其下属机构的岗位权限信息,为机构岗位增加授予应用角色,可供选择的应用角色来源于应用管理员给该机构授予的应用角色,或者撤销某一机构岗位已经拥有的应用角色。

    (2)用户授权管理

    根据用户账户信息中设定的授权体系,调出相应的授权管理功能,完成用户权限设定。

    l  企业授权体系:企业授权体系采用岗位授权方案,对机构岗位的权限进行统一设定以后,调入相关岗位的人员自然拥有相应岗位的权限,岗位变动时,权限亦随之变动。为了增加灵活性,可以对用户单独进行特例授权或特殊限权,被特例授权的用户,除了拥有岗位的所有权限外,还额外增加特例授权的权限;被特殊限权的用户,将失去指定限制的权限,哪怕其岗位拥有该权限或者特例授权该权限。当组织规模较大,或者组织比较健全时,适合采用企业授权体系。

    l  标准授权体系:标准授权体系采用用户组授权方案,对用户组统一进行授权后,将用户归入一个或多个用户组,让用户具有其所属用户组的所有操作权限。标准授权体系适用于能够将用户归类到数量不多的分组的应用场景,且只能有一个系统维护人员,若需要将系统管理任务逐级分解到不同的人员,也建议使用企业授权体系。当用户分类特别复杂时,建议采用企业授权体系。

    l  简易授权体系:简易授权体系直接对每个用户授予应用角色,适用于系统维护人员单一,用户数量较少的场合,如员工数量很少的组织。

    5、用户服务

    服务人员为了解答信息系统使用者日常操作过程中出现的与授权相关问题,需要使用该功能获取必要的数据支撑,并协助用户进行一些不影响系统安全的操作(如用户密码重置)。

    图7 用户服务功能结构

    (1)用户权限查询

    查询用户所拥有的权限,包括授权权限、委托权限、受托权限,以及当使用企业授权管理体系时的特例授权和特殊限权。

    (2)应用授权查询

    对应用资源或角色的授权情况进行查询,便于了解应用是否存在授权安全风险,如敏感资源访问权限是否约束度不高的岗位、用户组或用户。

    (3)用户密码重置

    重置某一用户的登录密码,用户密码被重置后,系统向用户发送一个随机的验证授权码,用户使用该验证授权码重新设置其登录密码。

    (4)用户账户冻结

    将正常的账号设置为冻结状态,被冻结的用户将不允许登录,冻结的用户被激活以后可以正常使用系统。

    (5)冻结账户激活

    对被冻结的用户进行激活,以便该用户可以重新登录系统。

    6、个人中心

    个人中心是面向已经通过认证的登录人提供的针对其个人账户的信息维护及常用操作,包括重置密码、修改登录密码、个人外部账号维护、个人联系信息维护、值班签到签退、权限委托等。

    图8 个人中心功能结构

    (1)登录密码重置

    由于忘记密码,个人申请密码重置。系统向该账户的密码保护手机或邮箱发送验证码,用户通过特定的密码重置界面,输入新的登录密码和验证码,若验证码验证有效,则将该用户的登录密码设置为新密码。密码重置申请也可以由管理员或客服人员发起,由用户在有效期内进行重置。

    (2)修改登录密码

    为了提高账户的安全性,建议定期修改账户的登录密码。修改登录密码需要验证当前密码,只有当前登录密码验证通过后,才能将该用户的登录密码修改为新密码。

    (3)个人外部账户

    维护登录账户对应的员工的外部账户信息,如远程医疗账户、电视电话会议账户等。

    (4)个人联系信息

    维护登录账户对应的员工的联系信息。

    (5)值班签到

    签到到选定的轮值岗位,将个人设置为该岗位的在岗值班人员。

    (6)值班签退

    从在岗的轮值岗位签退。

    (7)权限委托

    将个人所拥有的部分或全部权限,委托给其他人员,在委托有效期内,受委托人将具有委托人授予的委托权限,以便在委托人不在岗时,受委托人可以处理本该由委托人处理的事务,避免业务因委托人的不在岗而受到耽误。

    (8)受托权限

    查询个人所拥有的受委托权限。

    (二)统一配置管理(UCM)

    统一配置管理系统用于统一对各应用系统的可配置参数进行集中管理,以便通过单一功能入口管理各类应用系统的可配置参数。应用的可配置参数项,采用键值对存储,同一配置参数项的值,可以在应用(全局)级、机构级和个人(用户)级进行设置,个人配置值优先于机构配置值,机构配置值优先于应用(全局)配置值。也就是说,如果某个配置参数在个人配置项下有定义,则优先取个人配置项的值,否则如果机构配置项下有定义,则取机构配置项的值,最后再取应用配置项下的值,如果都没有定义,则取默认值。

    应用可配置参数采用类似于Windows注册表的结构存储,具体实现可以采用网络文件、数据库、LDAP等多种形式。

    图9 统一配置管理需求用例

    1.配置服务管理

    设置应用系统存取配置参数的服务地址。应用系统启动时,或运行过程中,将从配置的服务地址存取配置参数。

    2.配置导入导出

    将配置服务中各配置项下的参数值导出到文件,或从文件导入到配置服务中。导出、导入时,应该让用户选择导入导出的机构及个人。

    3.应用配置详情

    显示应用的可配置参数列表详情,以及机构配置项、个人配置项下的各参数设定值。

    (三)统一用户中心(UUC)

    统一用户中心为基础集成平台的员工管理中心,通过统一用户中心集中管理组织架构和职员。一般作为尚未部署人力资源管理系统的机构进行人力资源管理的工具,主要功能包括员工管理和值班管理等。

    1.员工管理

    员工管理功能包括岗位编制维护、员工账户管理、员工信息维护、员工岗位设置和人事异动业务。

    图10 员工管理功能结构

     

    (1)岗位编制维护

    设置各机构岗位的编制数量,维护岗位职责和岗位技能要求。

    (2)员工账户管理

    为尚未创建用户账户的员工创建用于信息系统进行用户身份认证的用户账户,设置用户账户的基本信息(如用户授权体系、是否默认账户、是否自动同步岗位信息等),或者冻结用户账户、激活已冻结账户、重置用户密码等。

    (3)员工信息维护

    维护员工信息,包括从人力资源系统同步员工信息或者从外部文件导入员工信息、员工信息新增、基本信息修改、联系信息维护、外部账号维护等。

    l  人力资源同步:采用信息接口的方式,从人力资源系统获取用户信息,用户刷新本平台的用户信息,对于已从人力资源系统消失的员工,标志为禁用(离职)而不作删除。

    l  员工信息新增:手工录入新员工的信息,创建员工基本档案,以便为员工创建其认证账户,只有系统管理员和机构管理员才能通过组织管理凭空(即没有员工资料档案)创建认证用户账户,员工管理员创建的用户认证账户,前提是存着该账户对应的员工。

    l  基本信息修改:修改员工的基本信息,包括姓名、性别、身份证件信息等。

    l  联系信息维护:维护员工的各种方式的联系信息,如手机、座机、办公电话、电子邮箱、即时消息号码等。

    l  外部账号维护:维护员工使用的外部账户,如电视电话会议账号及其他第三方平台的账号。

    (4)员工岗位设置

    维护员工的工作岗位,当员工的工作岗位发生变化时,若其认证账户设置了自动同步岗位,则该认证账户的岗位将与员工的岗位保持同步。这样,如果该用户使用企业授权体系,那么其权限自然随着人事岗位的变动而自然变动,不再需要IT运维部门参与人事变动的信息维护,减少IT运维工作量。

    (5)人事异动业务

    人事异动业务实现简单的可追溯的员工信息动向,包括员工入职、员工离职和员工调岗等。通过人事异动业务驱动员工信息、员工状态的变化,避免直接使用系统维护功能维护员工岗位。人事异动业务建议采用制单-审核分离原则,形成相互监督制约的机制,防范员工授权错误的风险。

    2.值班管理

    在一些行业(尤其是医疗服务行业、安全保卫部门等)中,存在值班制度,在非工作时间及节假日安排人员轮流履行特定岗位职责。为了在外部业务协同中让对方更容易寻址、定位到相关岗位的值班人员(尤其使用网络视频呼叫、电话呼叫等方式),将值班岗位设置为特殊的人员,为其设置固定的呼叫联络方式,这样不管如何安排轮值,外部都可以轻易地与其取得联系。

    图11 值班管理功能结构

    (1)轮值岗位维护

    维护组织机构的值班岗位及其相关联系信息、外部账户信息等,功能类似员工信息维护。

    (2)值班签到签退

    当值班人员不通过个人中心进行值班签到、签退时,通过此功能集中设置组织机构各轮值岗位的人员在岗及离岗状态及时间。

    (3)值班岗位查询

    查询各轮值岗位的在岗情况及值班人员信息。

    (四)统一消息管理(UMM)

    统一消息管理为认证用户提供统一消息收发接口,支持手机短消息、即时消息、电子邮件等消息类型,并可以支持多个消息网关,系统根据消息接收人的目标地址,自动选择最优的目标消息网关发送。

    图12 统一消息系统需求用例

    1.消息系统控制台

    消息控制台是消息管理员用户配置消息系统、监控系统消息收发情况的主要功能界面。

    (1)消息接口配置

    配置消息系统的消息网关及其路由规则。

    (2)收发消息查询

    查询、监控消息系统的消息收发情况,能够根据特定条件(如发生人、接受人、时间段、内容等)查询消息收发记录。

    2.系统收发统计

    统计消息系统的消息收发情况,包括全系统和特定用户在指定时间段的统计数据。

    3.个人消息

    个人消息是登录人个人消息及消息业务的总入口,对个人消息进行归类,系统默认将已经编制但尚未发出的消息归入草稿箱,将收到的消息归入收件箱,将已经发出的消息归入发件箱,已经删除的消息归入垃圾箱(回收站),允许用户自行创建新的归类,并自由将消息在不同分类之间(草稿箱除外)移动。

    (1)草稿箱

    用户编写的消息,在尚未发送之前,默认存储在草稿箱中。通过草稿箱可以调出消息,继续修改,直至发送或删除。

    (2)收件箱

    用户收到的所有各类消息,自动保存到收件箱。

    (3)发件箱

    已经成功发送的消息,自动保存到发件箱。

    (4)垃圾箱

    删除的消息,保存在垃圾箱。系统在个人消息存储容量不足时,将自动清理垃圾箱,将消息彻底删除以便释放其占用的存储空间;系统也会定时清理垃圾箱,哪怕存储空间充足,消息在垃圾箱中存储一定时间后也被彻底删除以释放空间。

    (五)用户账户复制(UAR)

    为了更好地兼容多种应用环境,统一用户认证(UAA)中心的用户账户信息,可以与第三方账户数据库实施自动同步。在UAA和第三方账户数据系统分别安装部署账户同步器,将其中一边设置成源账户中心,另一边设置为目标账户中心。账户同步器将订阅源账户中心的账户变动事件,或者定期查询源账户中心的变动账户信息,并将这些账户变动事件发送给目标账户中心的同步器。目标账户中心的账户同步器收到源账户中心发送的消息后,将对本地的目标账户中心相关账户信息进行设置,保持目标账户中心的账户信息与源账户中心同步。目标账户中心同步器也可以主动向源账户中心的同步器发送账户查询请求,获取源账户中心的账户信息并同步到本地目标账户中心。

    第三方用户账户中心类型主要考虑支持常见的微软AD域用户数据库和LDAP用户数据库,其他类型的用户账户中心,根据需要进行定制化接口开发。

    图13 用户账户复制需求用例

    (六)单点登录系统(SSO)

    单点登录(SSO)系统允许用户只登录一次,就可以在不同的应用系统之间实现免重复登录的用户身份识别,基础集成平台使用耶鲁大学开发的中央认证系统CAS(Central Authentication System)作为单点登录系统。

    在CAS系统中,用户使用身份证明(Credential,比如用户名密码、个人数字证书等)在CAS登录,CAS生成用户总票据(TGT,TicketGranting Ticket),用户拥有这个TGT就可以证明其已经在CAS登录过。

    当用户访问某个受保护的应用资源时,在B/S应用中,这个访问请求被应用服务器的过滤器拦截,用来判断该Session是否有用户信息或者有CAS颁发的访问该资源的授权(即服务票据ST, Service Ticket)。如果Session中已经有用户信息,则表明用户已经通过该应用的身份认证而允许其访问;如果Session中没有用户信息,但是有服务票据ST,则拦截器(调用CAS Client)向CAS申请对ST进行验证,如果ST验证有效,就返回用户信息并记录在Session中,实现用户在该应用的身份认证。如果既没有用户信息,也没有服务票据ST,表明用户尚未登录,拦截器将浏览器重定向到CAS的登录页面进行用户登录,登录成功后,CAS生成用户总票据TGT,并使用TGT和原访问的目标应用生成针对目标应用的服务票据(ST),再将用户浏览器重定向到原访问的目标资源,同时将ST作为参数传递给应用服务,应用服务器的过滤器再次拦截请求,此时发现有了ST,即向CAS申请对ST进行验证,完成应用的用户认证,并在Session中记录用户信息。

    C/S应用系统的客户端由于无法像B/S应用的Web端那样嵌入拦截过滤器实现单点登录,这就要求C/S应用程序在启动时接收服务票据ST,并主动向CAS申请对ST进行验证,验证通过返回登录的用户信息,完成对用户的身份认证。

    如果C/S应用程序在启动时,没有接收到服务票据ST,应从命令行参数获取用户身份证明(用户名密码、数字证书等),或者打开用户身份证明输入窗口,通过用户身份证明向CAS申请认证,或者打开CAS的登录页面实现用户登录。C/S应用的用户登录完成后,应通过服务接口向CAS申请获取用户总票据TGT,以便能够让C/S应用程序使用TGT向CAS申请访问其他应用程序的服务票据ST,将ST作为参数传递给其他兼容CAS单点登录的应用,实现C/S应用程序之间以及C/S与B/S应用程序之间的单点登录。

    (七)统一认证授权编程接口(AA-Lib)

    为了方便应用程序身份认证的功能开发,需要向开发人员提供基础集成平台的用户认证编程接口。编程接口主要提供Windows环境的DLL和Java、Php等编程语言的开发包。编程接口主要包括用户认证、用户信息获取、用户角色获取、用户资源获取和用户权限判定等,同时也提供用于向基础集成平台更新应用资源及角色的工具类接口,包括更新应用资源、更新应用角色和更新角色资源。

    在统一认证授权管理方案中,应用程序要在一些对用户权限敏感的功能点,对当前用户是否拥有特定权限进行判定检查,检查当前用户是否有权访问特定资源,或者检查用户是否拥有特定角色,所需的资源或角色可以编码在用户程序代码或界面资源中,如果用户拥有相应的角色,或者被授予访问该资源,就允许用户继续访问,否则拒绝用户访问。

    1.身份认证

    根据用户身份证明向基础集成平台申请用户身份认证,认证成功则返回用户总票据(TGT)以及简要的用户信息(用户ID、用户名称、真实名称、员工ID、所属机构等),输入参数包括:用户身份证明、认证服务器地址、特殊附加信息等。

    2.票据验证

    验证TGT或者ST的有效性,如果验证有效,则返回用户授权Token以及简要的用户信息(用户ID、用户名称、真实名称、员工ID、机构ID等),输入参数包括:票据、AppID。

    3.用户信息

    根据用户授权Token获得用户信息(如机构信息、岗位信息等),或者查询一些不常使用的用户信息项,输入参数包括:Token、机构ID、选项。

    4.用户角色

    根据用户授权Token获得用户的角色列表,输入参数包括:Token、AppID。

    5.用户资源

    根据用户授权Token获得用户可访问的资源列表,输入参数包括:Token、机构ID、AppID。

    6.角色判定

    根据用户授权Token判定用户是否拥有某几种角色,输入参数包括:Token、机构ID、AppID、角色集合。

    7.资源判定

    根据用户授权Token判定用户是否拥有某几个资源的访问权限,输入参数包括:Token、机构ID、AppID、资源集合。

    8.应用资源更新

    更新应用系统在基础集成平台注册登记的资源,输入参数包括:AppID、AppSecret、资源列表。

    9.应用角色更新

    更新应用系统在基础集成平台注册登记的角色,输入参数包括:AppID、AppSecret、角色列表。

    10.角色资源更新

    更新应用系统在基础集成平台注册登记的角色授权,输入参数包括:AppID、AppSecret、角色资源关系列表。

    (八)OpenID认证服务

    基于OpenID的标准规范,实现OpenID Provider服务,使得基础集成平台的用户账户,可以被遵循OpenID标准的外部应用或网站用于用户认证。

    建议新开发的应用程序遵循OpenID的用户认证标准,这样即便不考虑单点登录,也更有利于实现多个系统之间的集中用户管理和授权,使得应用程序可以在用户部署环境下灵活选择不同的认证服务器(需要认证服务器支持OpenID)。

    (九)社会组织模型管理(SOM)

    社会组织模型管理主要为网格化社会管理提供基础数据维护功能,主要包括社会网格化属性(行政区划、乡镇街道、社区商圈、村屯组小区等)、社会基本单元(基本物业单元、家庭等)、社会资产资源(地表地貌地物、水系、交通道路、地下管网、空间轨道等)、自然人信息和法人信息等数据库。通过自然人信息库、法人信息库和社会资产资源信息库的建设,实现更好的社会资源信息共享,以便更好地支持跨政府部门、跨行业的基础数据资源共享。

    图14 社会组织模型需求用例

    1.自然人信息库

    自然人是家庭成员、法人机构员工和社会人群管理的基础数据。通过自然人信息数据库,建立贯穿个人一生的人员主索引。

    2.法人信息库

    管理法人机构的基本信息及其分支机构(部门)、员工等数据的维护。

    3.资产资源信息库

    各类社会资产资源的基本信息及空间信息,主要包括地表地貌地物、水系、交通道路、地下管网、建筑物、设施设备等。

    4.社会网格化信息

    社会网格化信息主要包括行政区划(县区级)、乡镇街道及社区商圈、村屯组小区(道路)等社会网格关系以及基本物业单元(栋、层、单元、门号)和家庭等社会基本单元信息。

    四、数据库设计

    在数据库模型中,背景为绿色的实体,表示表的数据一旦初始化后便极少新增或修改,如代码表;背景为粉色的实体,表示表的数据会因机构规模增长或时间流逝,缓慢增长的表,这类表的数据一般与业务量没有关系,数据增长缓慢,数据变更频率低;背景为黄色的实体,表示数据会随着业务量的增长而增长,此类表数据增长速度较快,需要定期进行重建索引、分区存储等优化;背景为蓝色的实体,表示表的数据为临时数据,其中的记录最终会被删除,因此存储容量基本不会太大,但由于频繁进行删除操作,也需要定期关注存储空间碎片问题。

    作者已经针对常用的Oracle、SQLServer、MySQL等数据库生成了数据库建表脚本,并提供数据字典文档,需要的同学请从下载资源处搜索“基础集成平台”下载或向作者索取

    (一)组织机构

    图15 组织机构实体关系模型

    组织机构采用树形结构表示,每个顶级机构形成一个独立的体系,具有类似租户的特性。机构的岗位从全局的岗位名称表中选取,并根据机构规模设定岗位的人员编制熟练。各机构岗位的权限(即角色)由本机构具有管理权限的人员(机构管理员、应用管理员、授权管理员等)进行管理。用户归属某一机构,该机构为其默认的机构,即用户信息表中的机构ID。用户登录系统后,默认使用其所属机构,但可以根据从其用户岗位表中选择其他机构,切换成当前应用系统的工作机构。

    (二)用户与职员信息

    图16 用户与职员实体关系模型

    基础集成平台进行身份认证的主体信息是用户,大部分用户指代某个职员,部分用户可能是指代某个系统或设备甚至指代特殊的人群(如超级用户)。当用户信息中具有职员ID,表明该用户代表该职员。由于用户认证已经独立于应用系统,应用系统不再维护用户信息,甚至用户信息对应用系统不可见,但是职员信息是对业务系统可见的,因此,当业务系统产生的业务数据需要记录相关责任人时,应当使用其对应的职员信息,而不是用户信息。

    用户账户可以绑定手机号码、电子邮件或登录名,通过手机号码、电子邮件或登录名对用户账户进行唯一索引(数据结构参见互联网注册用户)。

    员工在系统内部用员工ID唯一标识,在外部表现上一般采用工号,员工工号在一定时间内具有唯一性,但是工号可能会被回收重复使用,比如有些单位领导的工号,一直使用固定的001、002或者666、888等特殊工号,当领导更换时,新任领导继续沿用该特殊工号。

    职员信息表中,有一类特殊的“轮值人员”,其本身不是员工,而是需要排班轮值的岗位,该岗位具有固定的联系方式和外部账户信息。引入轮值人员的概念,是为了便于外部协同单位或人员联系到当班人员,不因排班或换班而受到影响。

    (三)互联网注册用户

    图17 互联网注册用户实体关系模型

    基础集成平台支持互联网用户的注册、认证和授权管理。互联网注册的用户不属于任何机构,因此不存在与之对应的员工信息,但通过组织机构员工创建的用户账户,依然以作为互联网用户登录互联网平台。

    第三方用户是指微信、支付宝、钉钉等第三方应用平台的用户,通过OAuth授权访问本平台,此时需要将第三方用户与本地用户账户进行绑定,使用本地账户的授权访问本地应用。

    新注册的互联网用户,默认使用标准权限体系,即基于用户组的权限分配。

    (四)应用信息

    图18 应用信息实体关系模型

    应用信息表的内容包含用于授权管理的应用和用于单点登录的应用,仅用于单点登录的应用不需要维护其资源和角色,只需要维护其访问入口、认证方式、启动方式等基本内容。

    (五)社会组织模型

    社会组织模型的数据结构及系统功能,放在医疗健康云平台中设计,目前基础集成平台暂不包含社会组织模型管理。

    (六)企业授权体系

    图19 企业授权体系实体关系模型

    企业授权体系下的用户权限,由用户岗位表关联到机构岗位角色表,得到用户岗位对应的角色,再加上用户受托权限表拥有的有效期内的角色和用户独立授权表的角色,最后排除用户独立限权表的角色,就是该用户所拥有的全部角色。

    给用户授权,主要通过设置用户岗位实现,若用户具有特殊性,可以通过用户独立授权表为用户额外增加授权,通过用户独立限权表为用户排除某些权限的应用。

    用户将其拥有的部分或全部权限委托给受委托人时,同时在用户委托权限表和用户受托权限表产生数据,其中用户委托权限表中的用户ID为委托人的ID,受托权限表中的用户ID为受托人的ID。

    用户所拥有的全部应用角色可以访问的应用资源,就是该用户有权访问的资源(开放授权的资源所用用户都可访问)。

    (七)标准及简易授权体系

    图20 标准及简易授权体系实体关系模型

    标准权限体系使用用户组权限,先对用户组设置该组具有的应用角色(即用户组应用角色表),然后再将用户组授予用户,用户便具有所属用户组的相应应用角色。一个用户可以隶属于多个用户组。

    简易授权体系不采用用户组,直接对用户授予应用角色(即用户授权角色表),判断用户权限时,直接从用户授权角色表中查询该用户的应用角色。

    用户所拥有的全部应用角色可以访问的应用资源,就是该用户有权访问的资源(开放授权的资源所用用户都可访问)。

    (八)用户单点登录配置

    图21 用户应用配置实体关系模型

    单点登录集成用户桌面环境(SSO-UIDE),使用用户应用配置表获取用户配置的常用应用及其认证方式和启动参数,实现集成用户桌面环境的配置漫游。用户应用配置表的应用信息,可以是应用信息表中注册的应用(即应用ID非空的记录),也可以是用户独立配置的应用(即在应用ID为空的记录),当应用ID非空时,应用类型、认证方式、网页启动URL、本地启动命令行、自动填表配置文件等字段内容,如果用户应用配置表中为空值,则取应用信息表中的相应字段值。

    五、其他说明

    本篇主要描述基础集成平台的总体架构及设计思路,重点对最基础的统一用户中心(UUC)和统一认证授权(UAA)进行详细的功能设计和数据库结构设计。基础集成平台其他模块的详细设计方案,将在后续推出。


    展开全文
  • word文件,51页,医院信息系统集成服务平台建设方案(互联互通成熟度测评),精品一级
  • 智慧医疗是智慧城市的一个重要组成部分,是综合应用医疗物联网、数据融合传输交换、云计算、城域网等技术,通过信息技术将医疗基础设施与IT基础设施进行融合,以“医疗云数据中心”为核心,跨越原有医疗系统的时空...
  • 医院信息系统集成服务平台建设方案.doc
  • 介绍最新的智慧医院建设过程,打破信息系统壁垒,通过医疗专用esb平台,进行信息集成
  • 医院信息系统设计——基础集成平台着重介绍了了系统总体架构、系统设计思路、主要技术路线。对健康医疗云平台涉及的医院各个系统进行梳理介绍
  • 第一阶段,财务电子化模式:上世纪90年代中期,北上广的三甲医院已开始引入基于NOVEL网络+DOS操作系统+FORBASE等关系型数据库的医院信息系统,其特点是注重财务收费功能,目标是为了收费电子化; 第二阶段,医嘱...

    1、医院数据集成平台建设的背景

    国内大多数三级医院信息化起步于上世纪90年代初,至今发展有将近30年历史,主要分为四个阶段:

    第一阶段,财务电子化模式:上世纪90年代中期,北上广的三甲医院已开始引入基于NOVEL网络+DOS操作系统+FORBASE等关系型数据库的医院信息系统,其特点是注重财务收费功能,目标是为了收费电子化;

    第二阶段,医嘱电子化模式:自2000年起,由于Windows桌面技术的发展、网络关系型数据库技术的推进,大多数三甲医院陆续更换成基于百兆以太局域网+Windows操作系统+SQL Server 或Oracle的医院信息系统,由于人机界面友好度提升,医生可在系统上开立医嘱,护士可执行医嘱,这一阶段的特点是围绕着医嘱生命周期进行业务协同,同时某些专科应用系统也开始使用。

    第三阶段,电子病历模式:2005年-2008年,医院开始部署电子病历系统,起初的电子病历为狭义电子病历,即病历文书电子化,电子病历系统也只是一个特殊输入格式的文本编辑器,而病历是医疗质量的重中之重,用户对电子病历的需求越来越细化,随之提出了广义电子病历,即涵盖患者在医院所有医疗行为的数据,许多专科化的系统也应运而生,2010年开始,无线技术的普及,院内移动应用也逐渐在医院运行。

    第四阶段,集成互联模式:2012年起,集成平台的概念在上海的一些医院得以实现,主要要解决医院之前所部署的众多系统形成的“信息孤岛”问题,同时2013年起,移动互联网应用开始盛行,医院的壁垒在互联网浪潮冲击下得以逐步开放,带来了开放后系统并发访问大幅度上升,需要可支持数据集成、业务集成、大并发访问的分布式架构平台的支撑。

    国家卫计委2018年4月发布的《全国医院信息化建设标准与规范(试行)》明确了医院应用系统功能多达260多个,当前医疗健康大数据技术的兴起,特别是“互联网+医疗健康”的深入开展为病患提供越来越便捷的移动就医服务,新形式下传统点对点的院内应用系统之间、跨医疗机构应用系统之间、院内应用系统与互联网之间的数据交互和共享已不能适应医疗信息化发展与医院信息管理的需要,医疗数据共享与安全面临新的挑战。作为应对,《全国医院信息化建设标准与规范(试行)》要求三级医院必需建设医院数据集成平台,有条件的二级医院可以建设医院数据集成平台,医院根据《全国医院信息化建设标准与规范(试行)》的要求结合实际对IT基础设施和基础架构进行升级改造,以适应国家要求和业务发展需要。

    医院数据集成平台建设带来的益处:

    1、 管理可视化:为医院信息管理部门提供了共享文档与管理、CDR(临床数据中心)展现与管理、EMPI(患者主索引管理)、交互服务配置管理、服务运行状况监控管理、数据标准转换管理、平台业务基础字典管理等可视化工具,医院信息管理者可以直观的监控平台交互服务运行的状态,对异常错误日志进行跟踪与处理。这也就意味着信息管理者能够准确的快速定位问题,处理交互故障,保障医院业务持续运行。

    2、 数据标准化:按照《电子病历基本架构与数据标准》要求构建临床数据中心CDR,通过标准数据集、数据元映射、转换、清洗、存储满足国家55个共享文档CDA建设与测评的要求,对数据处理过程及数据质量进行全程可视化监控和校验,保障数据的准确性。

    3、 降低接口成本与接口开发时间:按照《国家医疗健康信息医院信息互联互通标准化成熟度测评方案(2017年版)》要求提供79个国家标准交互服务,新建业务系统接入平台必需满足国标交互服务要求,大大减少了医院大量可复用的交互服务接口开发成本和时间,减轻了医院运维人员、业务系统承建厂商的工作量。

    4、 提高工作体验:由于医院业务应用系统众多,临床医、护、技等工作人员通常需要登录多个业务系统才能完成业务工作,这就带来了大量重复操作,工作体验糟糕,平台基础组件单点登录服务将业务系统通过统一入口、统一权限管理集成在统一界面,一次登录授权多业务系统应用,从而提升临床医、护、技等工作人员的工作体验。

    5、 减少业务系统依赖:医院新建业务系统往往需要依赖HIS、EMR等业务系统提供基础数据和临床数据,这就造成了更换HIS、EMR等业务系统代价高昂,医院需要新增业务功能原有业务系统承建厂商漫天要价,平台通过为医院构建统一的CDR,业务系统所依赖的基础数据和临床数据统一从CDR获取,最大限度帮助医院减少对单一业务系统的依赖。

    基于以上业务发展的需要以及医院数据集成平台建设的收益,结合医院IT发展的趋势,某院在医院数据集成平台建设方面进行了探索和实践。

     

    2、需求分析

    2.1 业务需求分析

    1、 交互集成需求:实现基于医院服务总线(Hospital Service Bus,HSB)的异构业务系统之间的标准信息交互服务。

    2、 数据集成需求:以患者为中心构建临床数据中心CDR,为基于医院数据集成平台的应用提供数据服务,支撑医院临床诊疗、教学、科研活动和管理决策分析。

    3、 主数据构建需求:基于平台提供注册服务、患者主索引服务(EMPI)、电子病历存储和调阅服务等为业务系统提供统一服务。

    4、 可管理性需求:实现共享文档与管理、CDR展现与管理、患者主索引管理(EMPI)、交互服务配置管理、服务运行状况监控管理、数据标准转换管理和平台业务基础字典管理的可视化配置、展现与管理。

    5、 界面集成需求:实现医务人员、行政管理人员、公众服务统一门户入口,院内业务系统通过单点登录实现授权应用。

    6、 可维护性需求:实现工作站一站式部署,版本升级管理。

    2.2 互联互通测评需求分析

    为落实新医改相关工作任务,加强并持续推进卫生信息标准的制定和实施,提高跨机构、跨地域健康诊疗信息交互共享、医疗服务协同水平和信息惠民成效,国家卫计委统计信息中心发布了《国家医疗健康信息医院信息互联互通标准化成熟度测评方案(2017年版)》并组织开展国家医疗健康信息互联互通标准化成熟度测评工作。互联互通测评以卫生信息标准为核心,以信息技术为基础,以第三方测评为手段,对医院数据集成平台及应用系统建设进行全面测试与评价,促进实现互联互通和信息共享。

    互联互通测评对医院数据集成平台的要求如下:

    2.3 难点分析

    在建设数据集成平台时要充分考虑医院自身的实际情况,不能盲目上马,要做好平台及基于平台应用的深化设计,分步实施,最终实现以患者为中心的、全医疗过程的数据共享和信息流转。在建设过程中,建议考虑以下问题:

     平台建设的边界问题,明确平台需建设哪些功能、实现与哪些业务系统交互、基于平台将建设那些应用和闭环管理。

     厂商配合的问题,确认承建厂商有无同类型医院平台项目建设能力,业务应用系统承建厂商能否配合交互服务接口和闭环管理改造。

     交互接口标准的问题:医院服务总线如何选择,系统间信息交互采用哪种方式和信息交互标准。

     流程梳理的问题,需要实现哪些闭环管理业务流程,在闭环管理流程中需要哪些业务系统进行闭环节点改造,如何通过消息与业务流程结合实现互操作。

     数据梳理的问题,需要实现哪些主数据字典的统一管理、发布、订阅与更新。

     用户获得感的问题,行政管理能否通过平台建设获得管理决策分析指标,提升决策效率;医务人员能否通过平台建设获得医疗安全质量提升,随时掌握病患病情和重点医疗事件。

     

     

    3、医院数据集成平台设计

    3.1 总体设计思路

    平台实现的整体思路一句话概述为:充分利用医院已经具备的条件和资源,加之一定的改造和创新最终实现院内业务应用系统及与上级平台的互联互通。

    应充分利用医院现有信息化基础,考虑改造和建设实施时间的紧迫性,通过整合现有的医院医疗数据数据快速构建一个医院数据集成平台,其中包括按标准对现有数据中心的数据进行清洗并生成符合国家标准的共享文档、形成一个互联互通的医疗卫生业务协作网络,面向患者、管理者和医务人员提供相应的基于平台的应用。

    3.1.1 基于平台的业务整合与数据共享机制

    医院数据集成平台是一个集成各类应用系统以及日常运营的平台,实现信息的整合再利用,在此平台之上可有效整合医院内部业务应用系统,最终形成一个互联互通的医院业务协作网络。医院数据集成平台是为医疗行业特别量体定做的,支持不同异源异构系统之间的医疗数据的整合,快速实施应用程序节点部署以及各医疗子系统之间的协同通讯。在医院信息系统中的各业务系统之间,比如HIS、LIS、RIS、PACS、EMR、OA等传递和展现整个医疗过程中的相关信息。

    通过医院数据集成平台建设,一方面可以规避“点对点”式的信息共享与交换,并使得医院可以基于平台进行业务管理,对内提高管理水平,对外以统一的交互方式接入区域卫生协同网络,更好地为居民健康服务。

    3.1.2 以电子病历为核心载体的患者诊疗数据集成与共享

    电子病历是健康档案在医疗机构的特定表现方式,标准化的电子病历是区域卫生信息化和健康档案建设的关键问题。医院信息系统是从简单的收费系统发展起来的,电子病历是医院信息系统进入临床信息发展阶段的产物。在区域卫生信息化的要求下,必须达到以居民个人健康档案为主线的临床信息共享,新一代医院信息系统建设就必须以电子病历为核心,全面疏理医院的各个业务与管理流程,使之满足医院内部的信息资源共享需要,还要满足区域医疗业务协同的需要。

    以电子病历为核心载体强调以病人为中心,将病人全部的诊疗资料以统一的形式组织起来,通过医院数据集成平台以统一的方式向外展示,并使之成为电子健康档案的有机组成部分,形成以电子病历基本架构与数据标准为基础的病人诊疗数据标准化、规范化共享与利用。

    医院管理分为医疗管理与运营管理。医疗管理通过对医院诊疗活动各个方面的直接与间接管理来保障临床服务工作的质量;而针对医院人、财、物的运营管理是为医院临床工作进行后勤保障工作的,其最终目标依然是为临床服务的。医疗管理与运营管理需要同临床服务交换各类数据,以实现相应的管理目标,促进临床服务质量的改善。在这个过程中,需要交换的数据种类繁多,几乎涵盖医院信息系统的各个部分,因此基于统一的医院数据集成平台的数据交换与共享机制是实现这类需求的有效手段。

    3.1.3 通过消息驱动的医院业务流程整合与再造

    在完成数据整合的同时,医院管理与医疗服务在业务流程上也需要有机地结合起来,才能提高信息的利用价值。例如,药品从采购到患者服用是一个逻辑非常严密的过程,流程上的差错有可能最终导致医疗差错甚至是医疗事故的发生。因此,如何将医院管理与临床服务的业务流程有机地结合起来,建设这两方面工作的协同机制,是医院数据集成平台的核心目标之一。通过消息驱动的医院业务流程整合与再造,就是要在各个异构系统的不同模块之间,建立消息通道,通过统一的消息机制来控制数据的流传路径、系统权限和界面执行,消弭异构系统间的通讯障碍。

    3.1.4 面向多类用户的集成门户应用

    建立统一的Portal门户系统,实现医院的行政管理人员、医护人员和患者的协同平台。在门户集成了医院现有的业务系统应用,实现一人多角色的工作应用展现。

    3.2 总体架构设计

    平台的最终实现效果是兼容不同类型的电子病历数据集,形成医院平台的临床数据中心和运营数据中心等,在临床数据中心的基础上实现各业务应用系统间的互联互通与数据共享,医院数据集成平台系统架构图如下:

    医院数据集成平台系统架构图

    3.3 数据资源规划

    3.3.1 基础信息库

    医院信息平台的基础信息库包括患者基本信息库、医疗卫生服务人员信息库、医疗卫生机构(科室)信息、术语和字典信息库。基础信息库由医院信息平台的注册服务产生,并为这些实体提供唯一的标识。

    3.3.1.1 患者基本信息库

    患者基本信息库的主要内容可以按照原卫生部《电子病历基本架构与数据标准(试行)》的规定,包括该标准的H.02 服务对象标识、H.03 人口学、H.04 联系人、H.05 地址、H.06 通信、H.07 医保等数据组。

    3.3.1.2 医疗卫生服务人员信息库

    医疗卫生服务人员信息库的主要内容可以按照原卫生部《电子病历基本架构与数据标准(试行)》的规定,包括该标准的H.09 卫生服务者数据组。

    3.3.1.3 医疗卫生机构(科室)信息库

    医疗卫生机构(科室)信息库的主要内容可以按照原卫生部《电子病历基本架构与数据标准(试行)》的规定,包括该标准的H.08 卫生服务机构数据组。

    3.3.1.4 术语和字典库

    基于电子病历的医院信息平台的术语和字典库,支持WS 363-2011 卫生信息数据元目录、WS 364-2011 卫生信息数据元值域代码、WS XXX-2012 电子病历基本数据集、《电子病历基本架构与数据标准(试行)》等规范。还应支持GB/T 2261.1-2003 个人基本信息分类与代码 第1部分 人的性别代码、GB/T 2261.2-2003 个人基本信息与分类代码婚姻状况代码、GB/T 2261.4-2003 个人基本信息分类与代码 第4部分 从业状况(个人身份)代码、GB/T 4658-1984 文化程度代码、GB 3304-1991 中国各民族名称的罗马字母拼写法和代码、疾病分类与代码(修订版)卫办综发 [2011] 166 号、ICD-9-CM-3 手术与操作、GB/T15657—1995 中医病证分类与代码、GB/T16751.3-1997 中医临床诊疗术语治则治法部分、GB/T 2659-2000 世界各国和地区名称代码。

    3.3.2 电子病历共享文档库

    电子病历共享文档库库是医院信息平台的一个重要建设内容和组成部分,本次测评的一个重点就是对医院数据中电子病历共享文档中的电子病历共享文档进行测评。它按照国家卫计委(原卫生部)发布的《电子病历基本数据集》和《电子病历共享文档规范》要求存储来自医疗机构各业务系统的电子病历数据,每一份电子病历数据均采用二维表格式和XML文件格式两种存储格式分别存储,形成平台独立的临床数据库和电子病历共享文档库。

    信息资源库建设的最基本要求是对标准的符合性:对《电子病历基本数据集》的遵循从能够从数据语义层实现各机构数据标准统一 ,而《电子病历共享文档规范》规定了文档的架构和内容,对《电子病历共享文档规范》的遵循则进一步解决了传输与交换层的统一问题,最终为实现系统之间、平台之间、机构之间的互联互通提供了基础。

    3.3.2.1 电子病历共享文档库目录

    共享文档库用于55个标准共享文档注册后的文档索引及文档内容存储仓库,可用于业务系统对于共享文档的检索和调阅。

    电子病历共享文档库严格按照《电子病历共享文档规范》的要求建设,卫计委目前一共制定了55个电子病历共享文档。

    3.3.2.2 电子病历共享文档库内容

    电子病历是医疗机构对门诊、住院患者(或保健对象)临床诊疗和指导干预的、数字化的医疗服务工作记录。是居民个人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源。

    电子病历的主要内容由:病历概要、门(急)诊病历记录、住院病历记录、健康体检记录、转诊记录、法定医学证明及报告、医疗机构信息等七个业务域的基本医疗服务活动记录构成。列举如下:

    1、病历概要 

    病历概要的主要记录内容包括: 

    1)患者基本信息 

    包括人口学信息、社会经济学信息、亲属(联系人)信息、社会保障信息和个体生物学标识等。 

    2)基本健康信息 

    包括现病史、既往病史(如疾病史、手术史、输血史、免疫史、过敏史、用药史)、月经史、生育史、家族史、危险因素暴露史等。 

    3)卫生事件摘要

    指在医疗机构历次就诊所发生的医疗服务活动(卫生事件)摘要信息,包括卫生事件名称、类别、时间、地点、结局等信息。 

    4)医疗费用记录

    指在医疗机构历次就诊所发生的医疗费用摘要信息。 

    2、病历记录 

    按照医疗机构中医疗服务活动的职能域划分,病历记录可分为:门(急)诊 病历记录、住院病历记录和健康体检记录等三个业务域。 

    1)门(急)诊病历记录 

    主要包括门(急)诊病历、门(急)诊处方、门(急)诊治疗处置记录、门(急)诊护理记录、检查检验记录、知情告知信息等六项基本内容。其中包括的子记录分别为: 

    门(急)诊病历:分为门(急)诊病历、急诊留观病历。 

    门(急)诊处方:分为西医处方和中医处方。 

    门(急)诊治疗处置记录:指一般治疗处置记录,包括治疗记录、手术记录、麻醉记录、输血记录等。 

    门(急)诊护理记录:指护理操作记录,包括一般护理记录、特殊护理记录、手术护理记录、体温记录、出入量记录、注射输液巡视记录等。

    检查检验记录:分为检查记录和检验记录。检查记录包括超声、放射、核医学、内窥镜、病理、心电图、脑电图、肌电、胃肠动力、肺功能、睡眠呼吸监测等各类医学检查记录;检验记录包括临床血液、体液、生化、免疫、微生物、分子生物学等各类医学检验记录。 

    知情告知信息:指医疗机构需主动告知患者和/或其亲属,或需要患者(或患者亲属)签署的各种知情同意书,包括手术同意书、特殊检查及治疗同意书、特殊药品及材料使用同意书、输血同意书、病危(重)通知书等。 

    2)住院病历记录 

    主要包括住院病案首页、住院志、住院病程记录、住院医嘱、住院治疗处置记录、住院护理记录、检查检验记录、出院记录、转院记录、知情告知信息等十项基本内容。其中包括的子记录分别为:

    住院志:包括入院记录、24小时内入出院记录、24小时内入院死亡记录等。

    住院病程记录:包括首次病程记录、日常病程记录、上级查房记录、疑难病例讨论、交接班记录、转科记录、阶段小结、抢救记录、会诊记录、术前小结、术前讨论、术后首次病程记录、出院小结、死亡医学记录、死亡病例讨论记录等。 

    住院医嘱:分为长期医嘱和临时医嘱。 

    住院治疗处置记录:包括一般治疗处置记录和助产记录两部分。一般治疗处置记录,住院与门诊相同;助产记录包括待产记录、剖宫产纪录和自然分娩记录等。 

    住院护理记录:包括护理操作记录和护理评估与计划两部分。护理操作记录,住院与门诊相同;护理评估与计划包括入院评估记录、护理计划、出院评估及指导记录、一次性卫生耗材使用记录等。 

    检查检验记录和知情告知信息,住院与门诊相同。

    3)健康体检记录 

    指医疗机构开展的,以健康监测、预防保健为主要目的(非因病就诊)的一般常规健康体检记录。 

    3、转诊记录 

    指医疗机构之间进行患者转诊(转入或转出)的主要工作记录。 

    4、法定医学证明及报告 

    指医疗机构负责向服务对象签发的各类法定医学证明信息,或必须依法向有关业务部门上报的各类法定医学报告信息。主要包括:出生医学证明、死亡医学证明、传染病报告、出生缺陷儿登记等。 

    5、医疗机构信息 

    主要指负责创建、使用和保存电子病历的医疗机构法人信息。

    3.3.2.3 数据来源

    电子病历共享文档数据来源于各医院的业务系统,医疗数据采集清洗涉及与医院内部众多信息系统的对接,如:电子病历系统(门诊和住院)、HIS(医院信息管理系统)、体检系统、LIS(实验室信息管理系统)、PACS(影像传输与存储系统)、B超系统、病理系统、心电系统、手术室系统、内窥镜系统、病案系统……

    3.3.3 临床数据中心CDR

    临床数据库(CDR)在医院数据集成平台中我们称之为临床数据中心,存储以病人为中心的全程临床数据,用于病人的全视图信息共享及用于医院的临床业务监管、BI分析、科研教学支持等。

    临床数据中心包括临床数据仓库(ClinicalDataRepository,CDR)是一个整合多个来源的临床数据仓库,提供以患者和医护人员为中心的统一视图的数据库。其中CDR通过受控医学词汇表(CMV)保证所有人对临床数据语义理解的一致,以提高CDR的数据质量。在CDR中,诊疗数据是围绕患者为中心进行组织的,用于病人的全视图信息共享及用于医院的临床业务监管、BI分析、科研教学支持等。其中的诊疗数据一般包括:患者基本信息、历次就诊病史、门急诊和住院诊断、处方信息、检验结果、放射/超声/病理/内镜检查报告、医学影像、费用信息……

    3.4 基础组件服务

    3.4.1 医院服务总线

    专用于医院数据集成平台的ESB(企业服务总线)称为医院服务总线(Hospital Service Bus,HSB),HSB支持主流的开放标准和规范,提供可靠的消息传输机制,建立服务之间的通信、连接、组合和集成的服务动态松耦合机制,为基于SOA的应用系统的服务集成提供支撑。HSB从功能上可以分为总线服务管理、消息传输、域服务器、适配器服务组件。

    相对于通用的ESB,HSB的特点是在医疗信息互操作性层面上支持医院信息交换,实现了语法互操作性信息交换,乃至语义互操作性信息交换。HSB基于统一的医疗行业信息标准规范,支持HL7信息交换标准。在国内,HSB应遵循《WS/T 447-2014基于电子病历的医院信息平台技术规范》和《基于电子病历的医院信息平台建设技术解决方案(1.0版)》等标准规范,才能有效实现医院内外信息系统互联互通和信息共享。参见医院服务总线交互引擎图如下:

    医院服务总线交互引擎

    3.4.2 注册服务

    注册服务应包括对患者、医疗服务人员、医疗卫生机构(科室)、医疗卫生术语和字典的注册管理服务。平台应对这些实体提供唯一的标识。针对各类实体形成各类注册库(如患者注册库、医疗服务人员注册库、机构注册库、术语和字典注册库)。

    3.4.3 患者主索引服务

    平台建设的一个关键点是患者唯一身份识别,也就是如何将同一个人在医院不同业务系统的就诊记录关联起来,并建立统一的交叉索引机制。患者在接收医疗服务时,可以使用身份证、社保卡号、就诊卡号、健康卡号、军人证号、护照号、港澳通行证、回乡证号、学生证号、门诊流水号、住院流水号、体检流水号等各种就诊身份标志,而医院各业务系统并没有合并持不同就诊卡的患者身份的机制,因此患者身份的唯一性识别与整合是实现患者信息共享的基础。见下图:


    EMPI患者主索引服务总体框架图

    在平台建设过程中,医院可以采用国际上公认的解决患者身份唯一性问题的IHE PIX(患者身份交叉引用)规范技术框架,来实现居民/患者的身份识别,使来自于不同机构不同业务系统的患者身份能够实现交叉引用。见下图:

    患者身份交叉索引流程图

    3.4.4 ETL异构数据集成清洗服务

    在医院数据集成平台的建设中,异构数据集成是一个重点也是一个难点。医疗信息平台的建设需要与院内多个业务应用系统进行对接,而这些系统由不同开发商进行建设,采用不同的的操作系统、不同的开发环境、不同的软件体系架构、不同的数据格式等,数据来源、环境、格式极其复杂。传统的医疗整合方式一般是由医院各系统供应商对原有系统进行改造后向平台提交数据,这种方式使项目的成败极其依赖各医疗卫生机构的主观配合意愿和技术配合能力,使项目变得极其不可控。

    因此,在医院数据集成平台建设中必须突破以上瓶颈问题,从根本上改变目前平台依赖自下而上“提交”标准化数据、从而实现数据整合的传统模式,而是将主动权交给医院,由医院通过平台来决定在什么时间,提取什么数据,按什么样的标准格式转换。采取一种“自上而下、主动、及时”的集成模式,一方面由于不再需要各业务信息系统改造数据格式而大大加快项目进度,另一方面也使得未来实时数据监测成为可能。ETL异构数据抽取、清洗、装载服务过程如下图所示:

    ETL异构数据集成清洗服务

    3.4.5 电子病历存储和调阅服务

    电子病历是由医院以电子化方式创建、保存和使用的,是居民个人在医院历次就诊过程中产生和被记录的完整、详细的临床信息资源。电子病历存储服务由临床数据中心CDR来实现,电子病历调阅服务即电子病历全息浏览(360患者视图),对外提供通过统一的浏览器实现调阅服务。

    电子病历调阅服务

     

     

    4、医院数据集成平台实施难点与应对

     针对平台建设边界问题,应对措施是在医院数据集成平台上线前,通过调研对照《国家医疗健康信息医院信息互联互通标准化成熟度测评方案(2017年版)》的要求梳理建设范围,例如医院数据集成平台建设需要通过互联互通四级甲等,需满足52个标准交互服务建设、53个临床共享文档建设、连通的业务系统数据大于24个,联通的外部机构数量大于4个等等。

     针对厂商配合的问题,应对措施是在医院数据集成平台上线前召集医院所有业务系统的承建厂商负责人,确认是否能够根据《国家医疗健康信息医院信息互联互通标准化成熟度测评方案(2017年版)》按时保质完成系统接入平台的改造。

     交互接口标准的问题,应对措施是根据《国家医疗健康信息医院信息互联互通标准化成熟度测评方案(2017年版)》要求通过医院服务总线采用HL7标准实现信息交互。

     流程梳理的问题,应对措施是在医院数据集成平台上线前,通过调研梳理并确认业务闭环流程,涉及多个业务系统,梳理每个业务点的归属系统,不但要考虑当前业务点情况,而且要考虑在整个闭环流程中未来可能的业务接入点,为后期信息化升级预留接口。业务流程梳理完毕,针对每个流程中涉及的业务点,确认改造方法。

     针对数据梳理的问题,应对措施是在医院数据集成平台上线前,针对数据元、患者主数据、科室主数据、医疗人员主数据进行梳理,生成平台统一的主数据字典,在业务系统改造过程中实现主数据的发布、更新、同步、订阅等操作。

     针对用户获得感的问题,应对措施是要通过医院数据集成平台建设提升行政管理者、医务人员的参与度,为行政管理人员提供基于平台的管理决策分析(驾驶舱),为医务人员提供基于平台的电子病历全息浏览、基于手机应用的重点医疗事件提醒、基于手机应用的移动查房等提升工作体验。

     

    5、医院数据集成平台实施过程管理

    医院数据集成平台项目建设是一项复杂的工作,平台的实施过程管理主要包括项目启动和计划、项目实施、项目监控、项目结尾等四个阶段。

     项目启动和计划阶段:完成项目招标采购,组织项目建设团队,召开项目启动大会,审议项目实施计划。

     项目实施阶段:确定实施步骤,对项目范围、项目时间、项目质量、项目成本、项目测评、项目团队和项目风险进行定义与管理。

     项目监控阶段:对项目实施进程进行监督,通过巡查、检查、测试、控制、预警保障项目质量,并按项目进度计划完成。

     项目结尾阶段:医院数据集成平台项目试运行,组织项目测评与验收,评估应用效果与效率。

    5.1 项目启动和计划阶段

    医院数据集成平台建设项目的启动涉及到产品的选型、招投标采购、项目团队的组建和项目实施计划的审议,需要考虑医院各类人员(信息管理人员、业务应用人员、医院管理人员)的需求是什么、采购什么样的产品和服务、不同厂商同类项目案例产品的性价比如何、项目实施计划如何等等。

     产品的选型

    重点是甄选厂商产品是否符合医院建设需求、采用的是国外商品化集成平台还是国内自主开发集成平台、同类型医院案例有多少、产品和售后服务价格多少。

     招投标采购

    重点是招标需求和参数文件的编制,必须按照招投标管理办法的要求公平、公正、公开选取符合招标文件要求的承建厂商。

     项目团队的组建

    医院数据集成平台建设是一项复杂的系统工程,涉及到医院、承建厂商及监理单位的各种资源,因此建立一套健全有效的组织保障体系是项目管理及项目成功实施的必要条件和保障措施。在组织保障建设中应考虑以下原则: 

     项目组需要医院、承建厂商、监理单位共同参与,参见项目组织结构图。

     成立以医院院长或分管副院长为组长的项目领导小组,负责项目的领导及资源调配,参见项目领导小组人员及职责表。

     成立以信息中心主任为项目经理的项目执行小组,负责项目的实施及管理,参见项目执行小组人员及职责表。 


    项目组织结构图

    项目领导小组人员及职责:

    项目执行小组人员及职责:

     项目实施计划的审议

    项目实施计划是平台项目进入系统实施的启动阶段,是用于协调项目编制、指导项目执行和描述项目控制的文件,关键组成部分应包括项目简介或概览、如何组织项目的描述、用于项目管理的技术和过程,描述需要完成的工作内容、进度信息和预算信息。项目实施计划主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

    5.2 项目实施阶段

    随着医疗市场和IT技术的不断发展和变化、国家医院信息互联互通测评的要求,加大了医院数据集成平台项目建设的周期和复杂性。为了保证前后衔接,避免脱节和重复投资,造成人力、财力、物力的浪费,需要在项目实施中把握以下原则:

     整体规划:任何一个信息系统的建设都不可能是一蹴而就,更何况医院数据集成平台建设是一项非常庞大、复杂、长期的系统工程。需要先做一个整体的规划,无论从战略上或从战术上,从软硬件系统上都必须先进行整体的调研和规划,才能为后续的建设指明道路和打下基础。

     分步实施:医院数据集成平台建设过程是一个长期的过程,必须分成多个阶段来完成,以保证项目建设的可行性和可控性。因此必须在总体规划的指导下,对整个项目科学地划分多个实施阶段,逐步完成各项工程的建设。

     成熟先行:医院数据集成平台建设包含了各种各样的产品,而各种产品又是在不断发展和完善的。医院的业务和流程也在不断的完善过程中。因此在建设时,不能冒进和盲目跟风,需要根据医院实际情况,选择成熟实用的产品或系统,从系统的底层一步步做起,减少系统建设的风险和浪费。在项目实施阶段需要制定详细的项目计划,并按计划执行。在执行的过程中对项目进行监控,根据项目管理理论本章节从项目范围、时间、成本、质量、人力资源、沟通及风险等方面如何进行管理进行阐述,供项目建设各方参考。

    5.3 项目监控阶段

    项目监控是围绕项目实施计划,跟踪进度、成本、质量、资源,掌握各项工作现状,以便进行适当的资源调配和进度调整,确定活动的开始和结束时间,并记录实际的进度情况,在一定情况下进行路径、决策、度量、量化管理、风险等方面的分析。在实施项目的过程中,要随时对项目进行跟踪监控,以使项目按计划规定的进度、技术指标完成,并提供现阶段工作的反馈信息,以利后续阶段的顺利开展和整个项目的完成。

    5.4 项目结尾阶段

    在项目结尾阶段需要对项目进行验收,项目验收需要满足以下标准: 

     确认项目已经满足了所有需求。 

     确认项目已经通过第三方测评。

     确认已经达到所有的完工标准和退出准则。

     为满足项目或阶段的完工或退出准则所需要的活动或措施已被实施。

     验证所有的项目可交付物已经提供并被接受。项目应该提交的可交付物,参见项目交付物参考清单。

    项目交付物参考清单:




     

    6、建议和总结

    6.1 产品选型建议

    医院数据集成平台项目建设涉及面广、周期长,对医院的信息化建设影响范围广,医院应结合自身实际选择成熟的产品,目前市场上有国外商品化集成平台和国内自主开发集成平台两种供选择。优缺点如下:

     国外商品化集成平台

    优点:产品稳定性强,广泛支持HL7、DICOM、XML等国际标准,提供大量可视化流程、交互接口定义工具。

    缺点:对国内卫生规范和标准适应性低,造价及维护费用高昂,客户化开发程度低。

     国内自主开发集成平台

    优点:对国内卫生规范和标准适应性强,能够根据国内卫生标准发展快速实现标准化升级改造,造价及维护费用较低,能够提供贴身服务。

    缺点:产品开发周期较短,稳定性不及国外商品化集成平台,还需经过大量医院用户验证并进行产品迭代。

    根据国外商品化集成平台和国内自主开发集成平台的优缺点对比,选型建议如下:

     床位低于500,已建院内业务系统低于50个的医院暂不建议上线医院数据集成平台,建议建设统一的临床数据中心CDR,以实现基于临床共享文档CDA的数据交互。

     预算充裕的医院可以考虑采用国外商品化集成平台产品。

     预算有限的医院需要考虑性价比及后期的维护服务,建议采用国内自主开发集成平台。

    6.2 总结

    医院数据集成平台应医院信息化发展的实际需求而生,代表了医院信息系统IT技术的发展方向,不同厂商的产品解决方案对应于不同的医院需求,没有哪个产品最好,只有哪个产品最适合医院的实际需要同时性价比又最高,盲目地追求集成平台和顽固地拒绝集成平台都是不可取的。

     

    本文作者:吴庆斌,高级工程师;软件工程和工商管理双硕士。现任暨南大学附属第一医院信息科科长、国家医院信息互联互通标准化成熟度测评广东专家、CHIMA青年委员、广东省医院协会信息化专业委员会常委兼秘书办主任。从事医院信息化管理工作10余年,全程参与医院HIS、PACS、LIS、EMR、HRP等核心系统建设;参与编写国家级医院信息管理专著6部,参与省部级科技项目4项,发表论文6篇。

    展开全文
  • 作为应对,《全国医院信息化建设标准与规范(试行)》要求三级医院必需建设医院数据集成平台,有条件的二级医院可以建设医院数据集成平台,医院根据《全国医院信息化建设标准与规范(试行)》的要求结合实际对IT基础...
  • 提升就医体验成就健康生活 HIT 基于电子病历的医院信息平台总体架构 集成平台 基于平台的信息门户 基于平台的应用 信息资源管理 主 数 据 临床数据中心 CDR 科研数据仓库 基于主题的数据仓库 主 数 据 管 理 索 引 ...
  • 医院目前跟临床业务有关的信息系统,主要包含有:门诊/住院收费系统(HIS)、电子病历系统(EMR)、检验系统(LIS)、检查影像系统(PACS)、检查报告系统(RIS)、合理用药系统、手术麻醉系统(OSI)、心电系统...
  • 医院信息集成平台基于SOA架构,以医疗服务总线、通用适配器、消息中间件、资源目录等自主知识产品为核心,遵循医疗行业标准和集成规范,构建松耦合、易扩展的医院信息整合基础架构。 平台面向院内外应用集成、数据...
  • 基于信息集成平台的互联网医院信息系统探索.pdf
  • 基于一卡通的医院信息系统数据集成平台设计与实现_张曦.caj

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,737
精华内容 2,294
关键字:

医院信息系统集成平台