第二节　什么样人能设计医院信息系统

看到这一节的标题，人们会问，我们搞了几十年的医院信息系统了，怎么还向我们提出这样的问题呢？

提出这一问题的目的，就是要强调把医院信息系统设计与应用当作一个学科看待的观点，使该观点能够在本行业各项业务活动中，特别是在医院信息系统设计这一关键环节中得到贯彻落实。

至于其现实的针对性，将在后文中给出相应阐述。这里只想再次强调经典而又朴实的两句话：“科学的事要以科学的态度对待”“专业的事应由专业的人来干”。

若要设计一套高品质的医院信息系统，那么主要设计者和团队骨干就必须具备如下几项基本素养。

1．熟悉医疗业务，具有业务与技术互为驱动意识

既熟悉信息技术又熟悉医院业务，做到技术与业务紧密结合是我们这个行业的“铁律”。每个医疗IT工作者都必须牢记这一“铁律”，必须具备业务与技术互为驱动的意识。

以下几个问题，是医疗IT工作者在工作中经常遇到的问题：为什么医疗信息化发展过程中总是不断出现“围城”现象？为什么行业内生命力最强的医院信息系统或临床专业系统大都是在高等级医院里孵化出来的？为什么行业内几个被广泛接受的标准和规范都出自优秀CIO之手？为什么业内影响深远的著作大都出自医院用户群体？为什么“大数据”成果中真正融入信息系统并立见实效的反而出自人手少、投入少的医院的信息中心/大数据中心？

对这一连串问题的回答很简单，那就是因为身在医院的IT工作者更深谙医疗和医疗管理各项业务，他们的“业务与技术互为驱动”的意识更强。观察行业内那些专家，几乎每个都是在医院环境中摸爬滚打出来的。再看那些创业失败或产品研发不成功者，他们普遍缺少在行业内的亲力亲为、经验积累和深入思考。以下用行业内较早时期的一个小型研发团队的成长经历来加深对这一条要求的理解。

在“军字一号”医院信息系统研发之初，有些人曾认为解放军总医院的“计算机室做不出好的系统”，理由是“这些人不熟悉医疗业务。”

研发团队（计算机室）听到这些说法后觉得那些人说的是一个真理：不熟悉医院业务就做不出好的系统。于是，该研发团队在原有设计要求的基础上又明文列出了这样一条规则：无论设计人员承担哪一部分的设计任务，都必须首先到现场“体验生活”，熟悉业务，熟悉操作，与使用者交朋友，之后才能开始书写设计文档。例如，承担“护士工作站”设计的设计人员，按照这一规定，分别去内科病区和外科病区各实习了一周，观察医护人员每天都在干什么、怎么干；做出系统原型后又请来两位熟悉业务的护士反复试用，请她们挑毛病、提意见。经过这样一番磨炼，系统顺利推向了应用。时至今日，尽管“护士工作站”有了很多的发展，但基本架构还是当初设计的那一套。还有一位承担计价收费设计的设计人员做得更为出色。他接到任务后，首先仔细考察收费处的业务操作和业务流程，并看出了这套业务的核心是“凭证”；进而又深入研究收费结算的整个业务管理；最后创造出至今仍被多家医院沿用的“卫生经济业务管理”业务模型。在整个业务模型和业务流程（需求分析文档）书写过程中，他曾多次征求使用者的意见，其中包括著名的医院财务管理专家的意见。由于这位同志调研认真，虚心请教，对整个业务的分析综合工作做得深入，使原来认为研发团队做不出好系统的人的态度发生了转变，心服口服地说：“我现在完全相信他们能够做出好的系统。”

可贵的是，这些人在进入业务现场前都准备了若干问题，列出了“调研提纲”。这样做的结果是促使研发团队边调研、边思考，加深了对业务的理解，提高了调研效率。

由于坚持深入了解医疗和管理业务，并深入体会“业务与技术互为驱动”的内涵，所以该研发团队在做出优秀的医院信息系统的同时，还历练出了一批行业内的优秀人才。20多年来，这个仅十几个人的研发团队中先后产生了三位大医院的信息中心主任、一位国家重点实验室主任、两位企业技术主管、两位业绩显赫的企业家和一位跨国公司资深研究员。同时，这个团队出版了至少五部本行业专业书籍，为行业贡献了三套影响广泛的标准和规范。这个团队在基础数据准备方面不断研究，他们编制的“数据结构使用手册说明”（含“数据字典”）“医嘱字典”一直在行业内广为流传。同时，他们编制的“疾病诊断和手术操作名称与代码标准应用指南”不仅使用在自行研发的信息系统中，而且经进一步整理后已由人民军医出版社正式出版，目前已经发行了数万册。

虽然这里涉及较多的是身在医院的IT工作者，但对于企业的IT工作者也具有借鉴意义。一位企业主管说过：“临床业务是医院信息化的发动机”，这反映了他对这项必备基本素养的深刻理解。

2．深刻理解用户需求，与用户同心

所有供应商无一不是将“把用户利益放在首位”挂在嘴边。可现实情况，包括“新一代”系统落地后的用户反映，又让人感觉“用户所求”和“供方所给”在一些基本点上还没有真正吻合。问题发生的根源就在于供方和需方没有真正同心。例如，用户期望“用最短的时间、以最少的操作得到所要信息。”可现实情况却是，越是新的系统就越让用户感觉“响应更慢了”，界面花哨、内容丰富都不能替代用户对“方便”的需求；用户希望建设起来的系统真正成为“自己的系统”，可现实却是，越是新系统就越脱离不了“保姆式伺候”。

为什么双方的意愿总是发生错位呢？笔者认为问题源于以下三点：一是，需方要求的是“迅速”和“解决问题”，供方想得最多的是新技术的运用及创建“新概念”，二者没有真正同心；二是，系统设计人员只注意满足“功能规范”的要求，忽视了对系统内部，特别是基础系统的精心设计；三是，系统设计人员忙于“产品交付”而忽视了测试、试用、优化、总结，以及可以上升为“技术科学”的研究，同时，现场实施人员只顾尽快“满足要求”，尽早获得“验收”，而没有全面思考如何做好“知识转移”，以使用户能够自己驾驭系统。

笔者认为，只有真正站在用户的立场，全面理解使用者的需求，倾心研发用户喜爱的产品，才能从根本上优化行业业态。在当下，把基础信息系统做好、做实，使其具有极强的生命力才是用户最根本的期望。

3．具备系统科学知识和系统工程素养

乍看起来这一基本素养的要求很高，其实人人都应该达到。《中国公民科学素质基准》就是这样要求的：

第一条，知道世界是可被认知的，能以科学的态度认识世界；

第二条，知道用系统的方法分析问题、解决问题；

第三条，具有基本的科学精神，了解科学技术研究的基本过程。

纵观行业内现存的种种问题，究其原因，都可以归结为系统的设计者和建设者缺少对“系统科学”的基本认知，缺少“系统工程”素养。

关于“系统科学”的概念，本书第一章已进行了阐述。

关于建立“系统工程”素养的必要性，我们可以借鉴钱学森院士在接受国务院和中央军委授予“国家杰出贡献科学家”和“一级英雄模范”奖章后的一段话：“‘两弹一星’工程所依据的都是成熟的理论，我只是把别人和我经过实践证明的可行的成熟技术拿过来用，这个没什么了不起，系统工程与‘总体设计部’思想才是我一生追求的。”由此可可见这项基本素养的重要性了。

在经过一二十年的高速发展之后的今天，我国医疗IT事业特别需要借用钱学森院士的“系统工程与‘总体设计部’思想”进行逆向思考。

为了理解这项基本素养的重要性，下面讲述任何人都不愿见到但确实发生过的一件事。

两位青年创业者既有宝贵的医疗专家资源，也有可观的创业资金支持，在“互联网+”的启发下，他们认为通过互联网将专家组成一个协同会诊群体，开展网上协同会诊，就可以造福百姓，他们开发的系统一定会有可观的市场。于是他们便招聘了一批IT精英，建立专家库、编制软件，研制了一个“远程专家协同会诊平台”。

系统制作成后看似是一个不错的产品，但真正推向应用时问题就暴露出来了：开展这项业务，无法避免与医院信息系统建立多项连接。因为患者以往的资料都在医院，在会诊过程中很可能还需要再做某些检查、检验，而这些检查、检验需要在医院完成，与此相关的计价和收费，也需要与医院信息系统建立连接。因为在设计该系统时只考虑了“核心业务”，没有考虑这些在运行环境中会遇到的问题，他们在与HIS供应商洽谈对接时，对方提出的问题包括：设计和改造这么多接口的工作谁来做？所需费用谁来承担？遗憾的是他们在研发之初没有想到这些问题。

如果他们学过一点“系统学”知识，那么当我们提到系统学的几个要点之后，他们就不会说：“你们怎么不早提醒我们？如果早知道这些就没有今天的被动了！”

4．熟悉基础软件及开发工具的原理和运用

这一基本素养对于我国大多数医疗IT从业者似乎已不是主要问题，但将这一基本素养用得好、用得精就不那么简单了，需要既熟悉基础软件的开发原理，又能结合业务实际做出恰当选择。

对于数据库和操作系统的选择，作为一个系统设计师必须做到的是，在可选的范围内，首先对它们的操作效率、支持能力、成熟程度、安全性、稳定性及易操作性等进行全面的比较，然后才能做出选择。

对于开发工具的选择，作为一个系统设计师必须做到的是，在可选的范围内，用常用的典型例题，对它们的方便性、易用性、开发效率，特别是数据库的操作效率等各项指标性要求逐项测试，全面比较之后才能做出选择。

因此，在一个系统里，在保证设置要求得以实现的前提下，开发工具的种类越少越好，以便于用户掌握及维护。

本书第七章“应用架构分析与设计”将对此展开进一步论述。此外，《“军字一号”点滴回望》一书的“系统设计，一诺千金”“‘精品’意识”等章节的相关内容。

5．运用系统工程方法，优化软件研发组织管理

我国军工产品的研发不仅技术突破快而且成功率高的原因是与我军的“双指挥”模式有关的，“双指挥”模式是指既注重技术的突破创新，也注重组织管理的加强，对系统工程方法的运用非常重视。

反观我们的行业，我曾询问过多位本行业的研发骨干：“你们公司的人力成本有没有降低的空间？”他们一致的回答是：“有，软件研发和工程组织管理两方面都有，而且空间很大！”看来我们要向军工系统学习了。我们行业的软件研发的组织，哪些方面最该改进呢？我认为，以下两个方面的改进最有针对性。

一方面，必须以系统整体观安排研发任务。如果是一套新系统，则必须首先分析和确定它在整体中的地位。例如，面对一项局部的研发任务/产品，必须首先考虑它属于整体中哪个分/子系统，它与整体、与其他分/子系统有何关联、如何关联，沿用哪些基础数据和成熟技术，与哪些要求统一起来……考虑清楚这些事关全局的问题之后才能决定任务的安排——挂在某个相应团队门下，还是单独设立一个部门。这样做有助建立企业自己的“产品树”，而不是“产品堆”。这就是系统工程方法中的“规划”和“设计”。

另一方面，利用系统工程方法指导产品研发。这里需要强调经常被人们忽略的几个环节。一是，对研发的作品一定要严格测试。按正规要求，首先需要自测试，然后需要交由他人测试，测试的依据是系统设计需求，测试的环境要仿真。二是，坚持试用，在试用过程中不仅要“纠错”，更要检验是否达到了“两个最优”（技术路线最优，最终效果最优）。

如果对每个任务/产品的研发都坚持上述方法和步骤，那么研发的成功率和产品的成熟度定会大幅提升。