但这种模式还是无法真正意义上满足院方对医疗信息化高强度建设需要，虽然对第一阶段信息化安全做了提升，但是还是无法确定现有信息化建设过程中业务中断和数据丢失是否能精确有效解决，能否控制在院方的可承受的范围内，医院的事故解决的时间是和IT维护人员的责任关联在一起；为此DELL提出了第三阶段，既医疗行业IT信息化建设3.0版本，它所包含的内容丰富，是以医院信息科运维管理为出发点，以业务应用为基础，重新考虑如何能真正有效解决医疗行业第二阶段过程中所遗留的历史问题。

切 准确把脉六大难点

我们回顾医疗信息化建设的第二阶段存在哪些实质性的问题。

❶.是传统意义上的主机集群模式已经被医疗行业广泛使用，其分为双机单柜和双机双柜两种模式，安全级别逐渐递增，它给整体业务应用提高了可靠性，但还不足以真正达到院方对业务要求，其主要问题是出现在集群软件在业务发生问题切换过程中，存在很多不确定性，不是每次切换都能顺利完成，这给院方带来困惑，不用集群软件吧，出了问题没法切换，买了集群软件吧，真出了问题还不一定能切换，结果不明确。

那是否有一种模式可以明确在出了问题后，一定能接管应用呢，而且时间是控制在院方的可承受的范围内呢；

❷.是业务数据丢失，这也是医院非常痛苦的事，但又没有好的方式来实现，传统的数据备份一般只备份一些数据量不大的业务应用，而且传统的数据备份强度较弱，一般一天只备一次，出了问题，最好的结果是回朔到昨天的那个备份记录点，也许糟糕一点的要回退到周末的全备份点上，而且很多三级甲等医院的PACS非结构化数据量巨大，目前一般都几十TB的数据，五年增长到100TB在今天看来已经不是什么难事了。但从我们回访的用户看到，好一点的结果是一个月备份一次，中等的是三个月备份一次，糟糕一点的是不备份。从数据保护做的好一点的用户了解到，其实他们对自己的那个一个月备份一次结果也不寄希望，实在是无奈之举，一是不确认备份的几十TB的数据是否可用，无法验证，二是真的把这几十TB恢复回来需要多长时间啊，业务等的起吗，基本上不具备实用性，停留在形式上；

❸.是双机双柜的建设已经是IT信息化建设顶级模式了，但还是碰到了问题，一是此种模式只防物理故障，不防逻辑故障，二是如果主机和存储之间的链路不稳定，连续抖动的话，会把整个业务拖死，变成画虎不成反类犬，适得其反；

❹.是灾备建设也变得异常简单，只是将生产端的数据传递一份到灾备端即完成了所谓的灾备建设，此种模式也变得异常危险，一是如果生产端物理全部瘫痪，灾备端的数据是否有效值得商榷，二是生产端数据出现逻辑问题，也会被随之放大到灾备端，导致灾备端数据失效，两头不可用；

❺.是按照传统处理问题方法，先找原因，后处理结果的模式，往往变的异常艰难，时间控制上很不确定，难在对问题的分析判断上，往往根据每位处理问题工程师经验而定的，不确定因素太多，那是否有更好方式，不走这条路，能有效控制处理问题的时间呢，答案是有的；

❻.是当用户把以上全部建设完，整套系统的复杂度已经超出了用户可管理的范围，绝大部分需要借助外部力量来实现，这对管理上是一个巨大的风险，要借助外部力量，这对用户来说也是不可控的因素，如果借助的得体，问题可能会有效解决，如果所依赖的外部力量较弱，可能会造成严重的后果，那是否能寻找到一条简单维护，而不借助外力的方式呢，自身可以独立控制风险呢。

如上，“戴”神医已经通过望、闻、问、切四种手段，准确地诊断出了医疗行业信息化建设的症结所在。那么，“戴”神医又将开出怎样的灵丹妙药呢？我们明天继续讲述。