郭扬帆：HIS系统上线宝典｜严控版本，谨慎升级

　　HIS系统上线稳定后，版本升级需要纳入计划。上线阶段的升级就像急诊手术，没有太多的顾虑和试错，直击病灶解决问题，但后遗性较多;上线稳定后不能再这样蛮干，临床使用人员的神经已经被折磨得很脆弱了。

　　当前HIS系统的版本控制大体分为两类：一类是全公司统一一套版本，医院个性化的需求通过参数和专用部件来实现，特点是公司的维护成本降至很低，但各医院的升级难度很大;一类是公司有一个公共版本，各医院在此版本上发展为独立版本，特点是不受其他医院需求影响，升级相对较易。在微服务架构下的HIS产品，有些融合这两种优势，可以复用部分组件，又可以满足医院个性化需求，但也可能发生结构性变化时，重新适配的难度将超级困难。世上没有一种技术可以解决所有的问题，所以人的管理才显得更为重要。

　　无论是统一版本，还是先进架构，对单体医院来讲，自家的HIS系统都是独一无二的。每一个细小功能的升级，背后可能牵扯多个不同厂家的子系统，HIS作为医院最核心的主线数据流，有牵一发而动全身的能量，此时要慎之又慎。

　　严控版本要首先从严控需求开始，需求是版本升级的源头，没有新需求自然就不会有版本升级。上线稳定后的需求，主要集中在新政策需求、新上其他子系统接口、原有功能重整优化、使用人员易用性需求等，除政策性需求有不可抗力的时间要求之外，其他都可以列入计划性排期，当然政策性需求也需要倒排工期，优先级别最高。此时使用部门的需求不会太多，要严格要求他们通过OA系统来提交需求单。原因很重要：1.防止需求随意化。此时要求需求提出者对所提需求负责，需求要达到的目的要明确，要有具体实现的内容或要求达到的效果，难以描述的最好配图表说明，流程必须经过科室主任或护士长、职能部门领导审批后，再流转到信息科;2.需求可追溯。上线期间需求满天飞，一切以解决当前的问题为主，所以很多需求记录不及时、不准确，导致漏掉一些需求没有响应，引起医护人员不满，说“我们提了一堆需求，信息科都没有去做”。现在正是补救的时机，我们必须承认之前的遗漏，但也必须强制要求新需求必须通过OA申请，以便于追溯查证;3.控制需求变更。变更需求在项目管理中也是常见现象，但必须加以控制，不然费力费时费钱。人嘴一说，往往不用负责任，叫“口说无凭”，填写OA系统的需求申请单就是正式的工作方法，所以写需求的人，会自觉考虑所写的内容是否合理、表述是否准确，况且还要上级领导审批。那么，有哪些需求变更是合理的呢?例如：新政策变化、医院新的管理要求、有新的合理需求加入、原来考虑尚有遗漏等。对于不稳定的需求内容，即业务流程都还没有理顺的需求，最好先放一放，让业务科室人工先做，形成稳定运行模式后，再考虑用信息化实现。例如：我院新成立创伤救治中心，医务科一开始就希望我们用信息化手段来管理，这里面存在大量不确定性，至今业务流程都还在调整，我们先当做一般门诊急诊流程处理，保证能接收到病人、收费、发药就可以了;再例如很多医院在推行“全院一张床”管理，这也不是信息科和信息化能够解决的问题，不然就真成为背锅侠了，我们做了一张全院床位使用情况明细查询表，完事。

　　管理好需求，是信息主任不可推卸的责任。

　　管理好单一功能应用性需求还不是本事，如何把所有应用性需求归类整合成软件修改性需求才见真功夫。这已经不是一个人的事，而是涉及此次版本需求修改波及范围内的各子系统负责的工程师和厂家，影响范围小的，2、3个人碰个头可以决议，影响大的可能要召开各子系统多部门的专题会议，来讨论程序修改方案，力求做到既照顾各方需求实现，又能让软件系统设计最优。

　　严控版本，还在于对升级内容的选择。一次升级的内容不要太多太杂，上线后验收前的升级还适用小步快跑，同一类型或模块的修改最好放在一起升级，便于在升级出现问题后可以方便回退，而不影响其他子系统运行。如果需求明确、程序员水平过硬，测试工程师严谨，一次也可以升级多个不同类型或模块的内容。对于某些需求修改动作较大的，影响其他子系统运行的，最好单独一个版本升级，也是便于及时回退。着急的需求可以单独拎出来与已经测试好的需求一起升级。不稳定的需求或尝试先改一个版本的需求，选在空闲时升级。

　　严控版本，还在于对升级时机的选择。之前章节我们也讲过升级的时机选择，在此说一些不一样的内容。政策性需求对升级有严格的时点要求，不能过早，例如：1月1日凌晨0点开始，取消药品加成，就只能在这一刻升级;为配合医院新的管理制度和流程执行，需要提前几天升级，观察效果，预留整改的时间;上线后系统运行较稳定，也可以固定某个时间点进行升级，如每周三下午4点。不建议常态下晚上升级，一是出现问题后，资源难于协调;二是第二天早晨病人较多，有隐藏的问题此时才曝露，容易造成医疗秩序混乱。例如：我们有几次自助机的程序员晚上加班干活，自己测试完成后，就更新了版本，第二天自助机开机后自动升级，然后就用不了。分析原因就是工程师没有做现场测试，忽略掉一些环节，当联系到程序员时，他还在睡觉，然后门诊病人都围在自助机前面，医院需要组织工作人员疏导病人到人工窗口取号缴费，给正常医疗秩序造成一定混乱。现在我们都禁止各公司的软件晚上升级。

　　C/S架构的产品，程序运行在本地硬盘。服务器端升级以后，客户端一般在重新登录时才会复制服务器端的升级文件包到本地，有些客户端很长时间不关机也不退出系统，造成一直使用旧版本，所以当有重大升级内容时，还要设置强制升级的策略。

　　B/S架构的产品，程序运行在服务器端，客户端通过浏览器调用，比较容易部署和更新版本。客户端只要重新访问服务器端就是最新的版本。回退版本也更容易，这是B/S架构自带的优势，但在运行速度方面稍逊于C/S架构。

　　版本回退机制。无论测试多么认真，都会有不可预知的错误出现，特别是HIS系统与N多个不同公司的子系统相关联，测试库不可能完整复制当前的生产环境。当不能通过再发布一个新版本及时解决时，为了保持医疗秩序不长时间混乱(一般30分钟以内)，就必须要回退版本，所以要记录每次升级包的内容，能够重新导回。对于新增表、字段或字段扩容，则无需回退脚本，因为对旧程序影响不大，这里也要求不能随意更改表结构的属性。

　　总之，此阶段的版本升级，重在求稳少犯错误，宁可花多一些时间，也不要引起医疗秩序混乱和临床使用人员的抱怨，最好在他们无感之中逐步感受到HIS系统越来越好用。

　　作者简介

　　郭扬帆，CHIMA委员，软件工程硕士，高级工程师，南方医科大学顺德医院信息科主任。广东省首席信息官协会医疗分会副会长，广东省卫生经济学会信息分会专家，广东省医疗信息安全专业委员会副主委，顺德医学会医学信息学分会主委等。主编著作二部《医疗卫生信息化项目管理实务》、《医院网络安全建设指引》，担任多部著作编委。1997年从事医院信息化工作，先后经历过多次甲方、乙方角色换位，积累了丰富的项目管理经验。