0106珠海项目升级总结及映射模式分析Cache52+HIS 68升级到Cache+HIS P81文档格式.docx

0106珠海项目升级总结及映射模式分析Cache52+HIS 68升级到Cache+HIS P81文档格式.docx

《0106珠海项目升级总结及映射模式分析Cache52+HIS 68升级到Cache+HIS P81文档格式.docx》由会员分享，可在线阅读，更多相关《0106珠海项目升级总结及映射模式分析Cache52+HIS 68升级到Cache+HIS P81文档格式.docx（16页珍藏版）》请在冰豆网上搜索。

更新组织过程资产->

（归档）。

三：

总结写自己和珠海项目升级团队，为自己更好实施下一个项目做好经验积累，为感谢珠海项目升级团队。

感谢来项目现场支援的所有实施人员和开发人员和远程技术支持的人员。

感谢从西北大区支援华南区珠海项目升级的兄弟姊妹。

珠海项目成功升级离不开你们的辛勤努力，你们是最可爱最可敬的人。

1.项目信息（项目背景）

珠海市人民医院始建于上世纪50年代，历经60多年的风雨历程，目前已发展成为集医疗、教学、科研、预防保健为一体、珠海市唯一一所经卫生部评审的综合性三级甲等医院，是北京大学第三附属医院、广东省人民医院、中山大学孙逸仙纪念医院医疗技术协作医院。

珠海市人民医院信息化建设自2008年9月启动，主体信息系统是东华我们东华HIS\EMR等相关产品,围绕着建设数字化珠海市人民医院的目标开展的，分三期进行工程建设，并于2015年12月完成终验。

随着就医患者不断增长的就医需求以及国家地方政策要求，特别是新医改的战略发展及三甲医院复审对信息系统提出了新的要求，医院现有信息系统存在功能缺失，无法满足政府主管部门及医院管理的需求，难以达到电子病历较高等级评审要求，难以达到国家卫计委有关医疗信息系统互联互通等级评审要求，这些都制约着医院的发展。

为此，医院决定进行信息系统的升级改造及完善工作。

2.项目完成情况

珠海市人民医院HIS升级采用一套数据库两套应用程序的映射模式，是赵光辉赵总和公司领导提出的构思，珠海项目是第一家采用此模式升级HIS。

实施团队于2017年7月底正式入场，经过前期实施团队组建、高级用户组建（其实没有专职高级用户）、需求调研、新旧HIS差异化需求分析、与用户演示交流新版本HIS功能、测试、培训等一直到2017年12月28号门急诊和住院系统切换上线正式升级。

根据合同要求共计45个模块，HIS上线时完成了36个模块上线，剩余9个模块按计划二期完成（见附件一功能模块）。

系统上线期间整体运行平稳，上线期间也遇到多次HIS系统异常，例如Portal登陆界面内存设置较小，集成平台与第三方接口调用死循环等也都及时处理。

2.1.项目计划完成内容

上线初期，甲乙及监理三方按合同中模块排期（三方均字确认）。

合同共计45个模块，其中计划38个模块一期上线（主要是HIS主体业务），剩余7个模块二期上线，另外院方要求二期模块要在一期模块上线后3个月内全部部署完成并且能试运行。

因合同模块内容较多，不在此单独说明，模块排期详见第七章节附件。

医院计划迎接2018年的电子病历与互联互通等级评审，目标是要通过电子病历五级评审和互联互通四级甲等评审。

2.2.项目实际完成情况

根据2017年12月28号门急诊和住院系统一起上线，合同中共计45个模块其中36个模块顺利上线，有2个一期模块未能如期上线，基本完成了上线初期目标和任务。

医院计划3个月内完成二期模块上线。

珠海市人民医院于2017年年底顺利通过三级甲等医院复审。

珠海市人民医院正式于2018年3月通过中国医院竞争力星级认证，成为广东省首家通过2018版星级认证标准的五星级公立医院。

2.3.项目完成偏差分析

2017年12月28号门急诊和住院一起上线，合同中的36个模块顺利上线，新版血库系统和新版LIS系统这两个模块未能一期按时上线。

医院原来的血库是我们东华自己的CS版系统，LIS是广州惠桥。

两个模块未能如期上线原因是医院未及时采购链接检验仪器终端盒子。

数据准备培训后，检验科未能在HIS上线提交LIS基础数据。

3.映射模式实施说明

3.1.两种升级模式简单介绍

升级模式一：

新库+数据中心模式。

成功案列：

粤北人民医院、西交大口腔医院、秦皇岛市第一人民医院等。

升级模式二：

新老共库+数据映射模式，成功案列：

珠海市人民医院（2017年12月28号门急诊+住院系统同时切换），珠海市人民医院是由Cache5.2+HIS6.8升级到Cache2016+HISP8.1。

武汉三院（2017年11月份升级门诊，预计2018年上半年升级住院），武汉三院由Cache5.2+HIS6.9升级到Cache2016+HISP8.1。

3.2.映射实施步骤（映射模式搭建库简单步骤）

步骤1：

准备一套最新的老HIS测试库（40库Cache5.2+HIS6.8）。

2、搭建公司最新标准库8.1库（59库Cache2016+HISP8.1）。

步骤2：

40库和59库使用各自的app，共用一套data数据，也即共用40库的data。

停59库修改其cpf文件，其中59库的DataBase与Global映射关系见截图，详见附件。

（请重点以下两张截图中关注红线标注部分）

步骤3：

首先更新59库app、web、medsrc三个空间下的CACHE.DAT直接替换。

然后更新sys空间下的data，在59库上做一次d^GBLOCKCOPY操作。

将CACHE.DAT压缩包解压后，放到59拷贝D盘的下面目录下：

D:

\DtHealth\db\dthis\pempe（pempe新建临时文件夹），MSTSC到59服务器并登录到59的terminal做如下操作：

、app、web、medsrc四个空间

59库terminal的%SYS>

d^GBLOCKCOPY

1）Interactivecopy

2）Batchcopy

3）Exit

Option?

1

1）CopyfromDatabasetoDatabase

2）CopyfromDatabasetoNamespace

2

SourceDirectoryforCopy（?

forList）?

?

（后面操作步骤省略，详细见附件）

步骤4：

sqldbx登陆59，把SELECT*FROMinc_stkcat中INCSC_StkType字段中药品的修改为G,耗材的修改为M。

老库没这个字段，新8.1库需要这个字段，如果为空的NULL也按G或者M修改。

见图一。

步骤5：

将护士站的exportnur.gof导入59，可能会但报错，然后从40库的DATABASE--DHC-APP导入成功。

以后类似gof都先从59库的namespaces的DHC-App导入如报错，就导入40库中。

步骤6：

药品库存需要运行:

参数为库存科室的loc_dr

d##class（web.DHCST.test）.UpdateDHCINCItmLcBt（"

48,49,50,51"

）

步骤7：

供应商可用，更新供应商表的APCVM_Status字段

UPDATEAPC_VendorSETAPCVM_Status='

A'

WHEREAPCVM_Status='

Active'

步骤8：

修改40库的Potral-内存管理与设置。

见附件操作5-1。

经过以上8个步骤操作，若正常登陆59库HIS界面，则映射基本搭建完成。

接下来可以做细节方面的验证测试。

3.3.项目风险

3.3.1、映射模式之前没有成功案列；

3.3.2、前期部署完映射开始测试时，哪些表或global是两个库共用，哪些是单独分开不明确，可以说摸着石头过河，遇到问题解决问题。

3.3.3、有些配置与表新老公用，在进行映射后对新HIS进行操作后会影响老系统的业务。

3.3.4、老系统的垃圾数据影响新系统，如旧版有些药品数据存在负库存与过期库存，例如检查数据的service标记。

3.3.5、药品的定价规则无法修改，如旧版的系统的定价规则为入库进价、统一售价，在新版上线时就无法进行修改，修改后会导致药房、药库的业务表价格存空等问题。

3.3.6、入场时已和医院相关部门将模块排期商议确认完成，并提交由信息科和监理方签字。

上线前一个月信息科领导要求开始部署二期12个模块工作，此时离上线仅一个月时间，大量培训工作和测试工作已经应接不暇，突然临时增加12个二期模块的部署工作，显然是一个明确的巨大风险，因医院答复12个模块部署完初验后给公司回款，故公司领导同意了临时增加12个二期模块部署的要求，这给项目组造成了很大的压力。

3.3.7、上线前一天，公司实施团队和开发团队人员基本到岗，第三方公司人员和硬件厂家均已经到岗，万事俱备只待第二天升级。

主管医务院长组织会议，财务部、医务处、护理部、门诊部、信息科、病案室、院感科等处室领导均参加。

院长会议中明确下达通知因上线准备不充分（主要是培训不到位，培训和考核通过率低），另外2018年1月1号港澳珠大桥通车是政治任务，珠海市人民医院作为市最大三甲医院必须保证元旦当天就诊秩序正常。

我从天时地利人和三个方面举例论证说明按计划上线的优劣势，最终当场说服了院长和各位领导，改变了院长要求延期上线的决定，最终保证了2017年12月28号顺利按计划上线。

3.3.8、上线第二天，上线的微信群里集中爆发了护士站护理病历和各种护理表单问题，此时信息科和项目组压力都非常大。

信息科领导要求所有工作优先级调低，集中人员开始处理护理单据问题。

当时我拿出护理部签字过的护理病历，有理有据与信息科主任争论，签字过的单据立马完成，没有经护理部签字的科室个性化单据必须往后放。

信息科领导坚持要求必须执行他们的决议，场面一度尴尬，当时我顶住压力，要求请护理部主任来决定这事。

我坚持的原则是：

专业的人决策专业的事。

信息科是技术保障部门，协调沟通部门而非决策拍板部门，尤其不能替临床做拍板决策的事。

最终护理部主任同意我们的建议，经护理部签字的单据下班前解决，未经护理部签字认可的单据全部暂缓处理，并且当天中午护理部给全院病区发通知，未经过护理部签字的护理单据全部启用手工模式填写完成。

这样给我们上线预留了充足的时间解决临床遇到的问题。

一场有惊无险的护理病历问题得以解决。

3.4.客户满意情况说明

用户满意度从两个方面说明。

首先：

上线后的第二天，信息科吕主任召集大家开会收集上线问题。

吕主任说给此次升级上线打65分上线基本平稳过度，希望接下来的几天时间每天能增加5分。

临床科室满意度总体感觉一般。

因培训率和考核通过率仅15%左右，上线期间不会操作问题较多，尽管医院在培训前做了大量动员工作，院办发了严厉的培训考核通知要求:

考核未通过者纳入年终评优考核一票否决，考核未通过者不能开门诊并停用其门诊登陆权限并，到信息科学习一个月后根据考核情况再决定是否开通。

尽管培训期间每两天我们会把培训和考核率发邮件和微信给主管信息化副院长和信息科主任。

上线期间建立了近500医护人员上线问题反馈微信群，群里反馈的问题大部分是对系统不熟悉不会操作的问题。

根据反馈问题也明显可以看出培训考核率低的科室反馈不会操作问题较多。

事实再一次证明了培训考核不到位上线期间肯定会很艰难。

面对培训和考核不到位和医院和公司都要求必须尽快按时上线这一对矛盾体是考验项目负责人协调能力决策能力的关键时刻。

升级后的信息系统为医院顺利通过2018版五星级医院保驾护航。

其次：

春节后大概是上线后的3