【医院信息系统典型故障案例解析】系统程序代码逻辑问题导致业务故障

发布时间:2019-10-25
浏览次数:

《医院信息系统典型故障案例解析》一书收集整理了53个医院信息安全典型案例,内容涉及基础设施、网络设备、主机应用系统、数据库、安全设备、虚拟化等各个方面。该书在CHIMA 2019大会发布后即受到医疗信息化同仁的一致好评。现CHIMA加印了第二版,同时在公众号发布数期典型案例,为大家分享信息安全事故经验,避免事故重现,共建医院信息安全网络。




【案例概述】


案例关键字:程序代码  逻辑问题业务故障


相信很多医院都会面临这样一个问题,某业务系统系统使用多年,系统用户都已经习惯旧系统,相对来讲运行稳定、出问题也少,但如果没有原厂维护更新,一方面会导致系统功能无法满足医院日益发展的业务需求,另一方面很可能会在某些数据库或者应用程序层面细节上有些“暗雷”,说不准哪天就会炸。小L就碰到了一个类似的问题,数据库表里面某变量字段长度到达应用程序限值导致检验系统新增病人无法新开和执行检验项目,小L在测试验证、联系厂家核实之后,确定是程序代码逻辑问题,后采取腾出未使用变量空间方法,解决故障。


【案例还原】


某日下午17点左右小L接到临床科室报告新开检验遗嘱和打印检验条码时报数据库ora-00001,此时仍处于业务高峰期,所以系统有问题业务科室往往比DBA还快一步知道出问题了,信息处电话分分钟起此彼伏响个不停。



医院检验系统与门诊、住院系统都是通过接口调用进行交互,报障电话中,有检验科直接打过来的,也有临床科室打过来的,门诊也有,全院范围受影响,该天刚巧科室小L值班,深谙服务器及数据库运维工作的小L沉着应战,根据报错直接定位问题根源是检验系统数据库故障无疑。


小L第一时间请求对检验业务系统熟悉的同事协助进行问题处理,并按照既有医院信息化故障处理流程,直接向主管领导汇报故障情形。经查询相关底层表,发现lis.patient表里int_cpi(VARCHAR(14))字段的变量值已使用到七个九,并未达到此字段长度上限,初步怀疑是此表主键出现问题,即报错里面显示的约束值,经过测试及追踪,排除主键原因;18:30左右主管领导到现场,主管领导也是dba出身,首先要求小L在数据库层面进行测试,在数据库表中将int_cpi字段最大值加一,发现即刻就有新的操作生成了新的最大值,询问临床之后得知正常的新增操作依然无法进行,怀疑是此变量字段的长度受限。这就排除了数据库背黑锅的可能性,问题肯定是应用层面上了。幸亏科室有完善的厂家应急通讯录,小L联系厂家工程师查看底层代码关于此字段变量的写法,确认做了七位长度的限制。


查询数据库所有相关表,确认patient和masthead两张业务表内有此字段,也只关联了两个触发器;进一步查询得知此字段七位长度只使用了1和9打头的变量值,其余2至8打头的七位长度变量值均未使用。


此时有两种办法解决,一个是将9打头变量值全部减去同一数值腾出新增空间,一个是修改底层源代码,将限制去掉,对比两种方法,前者迅速但存在一定关联性风险,后者稳妥但是需要更新版本,解决时间不定;主管领导果断要求小L断掉数据库监听,重启数据库,在机房现场进入数据库执行语句,将七位长度9打头int_cpi字段减去相应变量值变更为2打头,随后业务恢复正常。



【案例总结】


1. 针对所有业务系统特别是没有原厂维护或者马上面临停止维护的旧系统,自查所有业务系统变量长度设定和已使用情况;

2. 建立应急通讯录、应急演练等机制,保证数据库、服务器、应用负责人在出现故障时,能第一时间内连回医院或赶回医院应急,关键操作不能只掌握在一个人手里,应该做好应急人员互备工作;

3. 在进行故障解决时,要以不扩大影响面为前提,如果快速解决的方法会造成不可预知的风险,应选择稳妥的解决方法为好。


本文选自《医院信息系统典型故障案例解析》

主    编  傅昊阳

副主编  马丽明  贺嘉嘉  高峰


点击本链接可直接购买:《医院信息系统典型故障案例解析》




更多医疗信息相关书籍请点击查看