【吴恒专栏】那些年我们更换的HIS

来源：HIT专家网    作者：吴恒

故事发生在几周前，一家医院请我帮忙做信息化规划咨询，期间遇到一个触及灵魂的问题：换不换HIS？

从那天起，我就陷入深深的思考：为什么少有医院满意的HIS？为什么医院和HIS厂商从开始的“相看两不厌”到“眼里只有怨”？为什么作为医院基础信息系统的HIS总被寄予太多的期望？关于这个话题，有太多的“为什么”！

回望医疗信息化的那些年，医院换HIS屡见不鲜。甚至有人调侃：作为HIT人，如果没经历过HIS的更换，那么你的职业生涯是不完整的。HIS之于医院信息化的分量之重，不言而喻，医院对HIS的选择一定是慎之又慎。但是HIS上线后一段时间，就会出现这样的“双窦娥”现象：一方面医院抱怨“服务不到位，需求响应不及时，服务费接口费颇为头疼”，另一面HIS厂商诉苦“服务费不高，工作量不小，出力不讨好”。

医院与HIS厂商各说各理，似乎都正确，又似乎都片面，而且双方相互吐槽的东西都是自己的感受，无关技术，无法用标准来衡量，其实就是一种叫做“体验”的东西。这样一来，似乎说不出个所以然，那就只能另辟蹊径，找一个新的角度来分析了。

因为岗位原因，笔者这段时间重温了马克思主义哲学理论，其中有一句话很深刻，即“要善于透过现象看本质”。现象是表面的，而本质是藏在表面现象背后的、客观存在的，因此必须善于透过现象看本质。在此谨尝试运用这一思维方法，通过上、中、下三篇系列文章，分析一下医院换HIS这一行业现象级话题，本文为上篇。

现象一：服务费“三宗罪”

提起服务费，医院和HIS厂商都有倒不完的苦水，争议主要有三：一是服务费该不该收，二是服务费的收取标准，三是服务费包含的服务范围。咱们就一个一个来说说。

1.服务费该不该收

软件是一种特殊的商品，服务是其重要的组成部分之一，实施结束就意味着服务的开始。特别是在产品与服务合一的今天，收取服务费，没毛病。这一点，医院信息主管应该都认可，但怎么让医院领导层认可是个问题。如果医院信息主管的沟通能力没有问题，那么HIS厂商的服务质量背书就是关键。没有高质量的服务，信息部门向医院申请服务费会比较被动。

2.服务费的收取标准

服务费的标准没有具体的规定，业内一般是HIS系统合同价的5%-8%，不超过10%。如何确定服务费的收取标准，一般是医院和厂商进行协商，但这样给人感觉服务费的收取标准有些随意，这也引出了下一个话题：服务费包含的服务范围。

3.服务费包含的服务范围

一般来说，服务费指的是对HIS系统进行日常维护所收取的费用，但日常维护的定义和服务内容的边界比较模糊，医院与HIS厂商对此的理解有时候会很不同。

以上三个争议产生的原因是服务费与服务内容不同步，其本质是双方对“服务”的理解不同。如何避免出现这样的局面？笔者认为，应该从细化服务合同做起，一是明确服务的范围，确定服务的边界，其中最重要的一点就是明确接口费是否在服务费内；二是依据往年的服务量来确定服务费的收取标准，干多少活、收多少钱；三是建立服务质量的考核体系，根据服务质量确定服务费的最终支付比例，质量高低直接影响尾款的支付。

现象二：“需求”，又见“需求”

HIS系统在使用过程中，随着政策的改变、管理的变化、使用深度的加大，作为用户方的医院一定会产生新的需求。怎么响应需求，对于医院和厂商都是极其考验情商的问题。在需求响应中，最常见的问题有两个：需求响应延时和需求响应失控。

1.需求响应延时

需求响应有两个要素：及时性和时间预期。及时性体现了对客户的重视，时间预期体现了对需求的慎重。从提出需求到满足需要的过程中，“响应及时”不是指及时满足需求，而是对于客户的需求迅速做出反应，并给出需求满足的时间预期。如果需求不能得到及时响应，那么就会产生“需求啸叫”。医院信息部门一定会承担来自信息系统使用者的压力，也一定会把这种压力传导给HIS厂商，结果造成压力传导的连续“追尾”和相互之间的怨气积累。

2.需求响应失控

需求响应失控有两种情况，一是有些HIS厂商的实施工程师为了尽快完成验收，对于使用者提出的需求照单全收，给后期的维护履约带来极大困难；二是信息主管的需求掌控能力不足，不能过滤不合理的需求，导致需求溢出。

因此，HIS厂商的需求反馈能力和医院信息主管的需求掌控能力至关重要。需求反馈能力保证了响应的及时性，避免需求延时；需求掌控能力确定了需求的边界，避免了需求响应的失控。

需求的本质在于企业对客户的关注，通过满足客户需求，提升客户能力，帮助客户成功。借用华为对于“关注客户”的定义：较低层次的关注客户是指满足客户的需求；较高层次的关注客户是指客户驱动创新。由此，对于需求应该从三个层级来满足，一是及时响应明确的需求，给出解决方案；二是主动发现未明确表达的需求，解决客户的担忧；三是探索挖掘潜在的需求，形成产品，拓展服务，达到合作共赢。

总而言之，从需求中来、到需求中去，形成“需求→产品→需求”的良性发展闭环，方为解决之道！

现象三：HIS之“声声慢”

有的HIS系统上线运行后，少则一两年，多则三年五年，使用者就会感觉越来越慢，特别是在医嘱执行的高峰，有些医院甚至会出现数据库性能缓慢导致业务完全不可用的情况。借用李清照在“声声慢”词牌中的一句词来形容：“这次第，怎一个愁字了得”。

对于这一问题，责任感不强的HIS厂商往往会一味强调硬件资源高配化。如果医院信息主管的理念和技术不过关，肯定会在硬件上花费不菲，但这也往往只是解燃眉之急，治标不治本。HIS越用越慢的原因，有许多种情况，大体来说分以下三种：

一是HIS的系统架构在设计时的系统性不强，无法满足外部数据交换的调用，导致接口持续增多，而这些接口代码往往是以“补丁”的形式存在，其质量参差不齐，反过来影响到核心业务系统的性能。

二是业务设计时仅仅考虑满足功能，缺少长期规划和可扩展性，没有考虑使用后期数据的积累及系统并发量，没有定期进行数据治理（如归档历史数据、使用分区表等手段进行数据拆分），进而导致后期资源不足。

三是数据库没有进行周期性的运维和优化，各项参数的设置往往还停留在系统上线阶段。

在这三种情况中，第一种情况要靠HIS厂商对系统本身的设计思想进行优化，第二种情况的解决办法相对比较具体，这里着重谈一下第三种情况，即数据库的运维和性能优化。

首先，为什么要进行数据库性能优化？

数据库是一个高度协作的同步系统，任何一个环节出现问题，都有可能导致最终的业务系统性能变慢。就像车在路上跑一样，车速的快慢取决于车的性能、驾驶者的技能和心情、当时的路况和天气、其他车辆的行驶状态等。单独提升某一项指标，对于车速的影响不大，需要综合考虑进行优化。所以对于HIS系统的数据库，要定期维护和优化，以便业务系统高效平稳地运行，达到使用者所期望的响应时间。

其次，数据库性能优化应该遵循什么样的思路？

一是根据最佳实践，优化操作系统和数据库参数；二是结合SQL实际运行模型，创建最佳索引策略；三是观察数据库对象读取模型，调整数据库对象内存常驻策略，确定是否使用并行、压缩、分区等优化技术。

最后，数据库性能优化要达到的效果是什么？

一是性能优化的结果可测量、可量化；二是性能优化的大量相关性可以被量化，具有相对客观的标准；三是性能优化的改善必须可测量、可量化、具有高度严谨性。

数据库性能优化是一门严谨的科学，技术要求比较高，如果医院有这样的人才当然可以自己动手，不然最好请专业的团队来进行，让专业的人做专业的事！

（未完待续，中篇预告：《HIS更换的“危急值”与非换不可的底线》）

（数据库性能优化相关内容“搬运”了柳遵梁先生《Oracle数据库性能优化方法论和最佳实践》一书中部分文字，并得到周亮先生不吝赐教与指正。特此鸣谢！）

【作者简介】

吴恒，河南大学淮河医院党委委员、党办主任，1997年毕业于河南大学医学院临床医学专业。兼任中国研究型医院学会医疗信息化分会青年委员会副主任委员，河南省医院协会人工智能与临床大数据管理分会副秘书长、常务委员。

【责任编辑：陈曦】