微信公众号 联系我们 关于我们 3618客服热线:020-32784919   推广热线:020-32780069
资讯
频道
当前位置:首页 > 医疗器械资讯 > 市场分析 > 是否有必要建立HIS应急系统?

是否有必要建立HIS应急系统?

文章来源:中国数字医疗网发布日期:2013-02-02浏览次数:30347

近年来,随着医院信息化重要性的提升,医院宕机事件也屡屡出现。2012年12月17日下午,北京积水潭医院HIS系统突然瘫痪,导致该院门诊挂号、收费大面积受影响;12月19日,北京友谊医院儿科系统突然升级,致使大厅系统全部瘫痪,家长携患儿等候一个多小时;12月23日,北京儿童医院内网络系统出现故障,致挂号、开处方等工作被迫暂停近三个小时……一周内北京市三家三甲医院先后出现HIS问题,导致患者就医拥挤甚至信息安全问题层出不穷,这一系列事件在医疗圈内引发了热议。HC3i论坛中有网友提出:是否能够建立必要的HIS系统安全应急方案,在网络出现故障的情况下,仍然可以完成单机收费,网络正常后再把相关数据上传到服务器。对外保障医院日常工作正常运行,患者正常就医;对内医院业务不乱不停,帐务不错,秩序不乱,措施有效,将损失减少到少,不利影响降到低?

 

赞同:建立HIS应急系统十分必要
 

allenj0928:还是很有必要,HIS突然瘫痪在医院时有发生,但一般HIS公司都会提供应急信息系统。
mouren:是的,有可能N年用不到一次,但有可能用到一次就能救急。
到处游:还是有必要的,至少我们医院是这样做的。
netbird:有好几家的HIS都可以支持单机划价收费。
rose28:只要告诉你的需求,任何一家成熟的HIS厂商都会做的。也就是所谓的应急系统。不过好还是在建立网络架构时,有容灾方案。
junxing:故障转移群集可以解决这些问题啊。 疑虑:实用性不强 各个流水号难统一

 

szpaio:HIS比较难实现,以后数据统计不好搞!

xister:电子病历有这样做的,HIS好像还没人这样!

rampike:实现这个功能应该问题不大,不过估计实用性不强。
windshine:这种应急还是不现实,到时候HIS里乱七八糟,手工记账,还需回头补录。
lemonrabbit:各个工作站的流水号如何统一是问题。
mdfy0001:功能简单,需求技术上麻烦不小。多机操作,要考虑是否重复流水号,收费项目验证问题,网络恢复数据回传及验证等等。实用性不强,不过技术难度相应要大。当然依据现状,这个还是很有必要。
honeywood:至少用B/S的都不行,用C/S的基本上都可以实现这个功能。
约翰羊:还是要考虑多机,多链路。C/S的从理论上讲是可以单机工作的。但是,由于门诊、划价收费、药房、检验等科室之间联系的密切,单机有可能无法完全满足工作上的要求。
f999:C/S的实现这个不是问题,就怕数据出问题。好引入一个验证机制,验证脱机时的数据导入后是否存在问题。

taiziyu:一般情况下,客户端的机器产生的数据也是要写到数据库中表里边的,单机先保存,然后再传,感觉实用性不大。
kilimanjaro:在网络故障情况下,仍然可以单机完成收费的?先分析清楚网络故障有几种情况,出现的概率有多大。
dongfq:大厂商的都有门诊应急收费,只能收自费,医保退费流程不好处理。
iswangwen:这东西从不考虑。计算实现了又能怎样?收完钱患者全去大夫那闹去了,大夫手工方?然后手工记账发药?怕出意外就把配用网络和电做好。
在大型医院对于非正常停机几乎是零容忍的,这时,应急服务器的启用是非常有必要的,它是为了在紧急情况下保证医院业务系统的运行,当一线系统恢复正常之后,应急服务器应该能有一个简单易行的手段将新的收费数据交还给一线系统,恢复全院业务从一线系统运行的正常状态,为医院IT系统提供后一道保险。 关于单机收费的原理

 

pzc87850627:原理是收费相关的基础数据要要更新到客户端数据库。网络恢复后上传,不会有流水号问题。问题是要建立客户端的数据库、要下载数据、上传数据。而且收费的操作会触动别的相关操作,没有实时传递数据容易出问题(数据问题、管理问题很多的)也就是说要有完整的配套措施来应对风险,但是风险出现的机遇小造成的问题大。要实行的话,在于决策层对投入产出的认识。
wangwei7558:我原来做过有单机应急,单机用的程序与实际用的是一个,不能连接到网络服务器的时候,连接本地数据库,小的内存数据库,网络恢复后数据上传。仅限于门诊收费的做起来也挺麻烦的,还涉及到平常的数据字典同步等问题。
f999:如果硬要做的话好是两套程序,两个服务器,一个瘫痪了就转用另一个。相对来说同步数据时能省事点,否则用单机很可能那个点出一想不到的问题,到时查起来会非常费劲。
Brain_01:以前做POS程序开发的时候做过类似的程序,这样要求每一个客户端有一个小点的数据库程序。当网络不通的时候,就连本机客户端的数据库。这种相对还是比较方便的。
bbzj:在供电正常情况下,即设备正常,服务器或网络不正常:应急的重点是门诊,门诊应急的重点是划价和收费。划价又以药品难,药品中草药难。收费如果全手工,对门诊量大的医院无法想象。一般检查检验仪器有单机报告系统,还没到完全无法正常运行的情况,很多即使是手工,也基本能运行。除了部分检验项目,手工报告的工作量很大。医生,我们不少医生开手工根本无所谓。所以,我们这门诊应急只要求到收费批价。应急的需求对不同的医院是不同的。


应急系统的成功案例

 

tuxiaoli:上海复高,在新华医院有过相关的实验。
zj__1977:本身技术上没有难度,北京很多医院都可以将数据同步。如北大人民医院。
金工:军卫门诊收费可以实现。
agg163:在上海、杭州的HIS厂商基本会有这样的应急系统。

bbzj :JSD的应该可以,在某医院实战过。JSD的有单机划价收费系统,某医院用过。我们这还有个公司有单机应急系统,也有医院用过,我也见过。
门诊量大于5000的医院不用应急系统得不偿失
简单算一下经济帐:一个门诊量在5000的医院,因HIS出故障导致1500人流失,按单个门诊患者药费150,检查治疗100算,医院的毛利润(不考虑人力成本)100左右。医院毛利润会损失150,000。一个应急系统一般不会高于200,000。所以不算社会效益,单经济效益在门诊量5000以上不购买这样的系统是非常失策的。如果门诊量大于5000而厂商不提供这样的应急系统而又不能开发出这样的系统,真的该换厂商了。