医院信息系统中，HIS是出现最早、应用最广泛的系统。早期HIS系统主要功能是医院财务管理，之后陆续出现相对独立的各类子系统，如PACS、LIS等。在医院各个部门间相互协作，向数字化迈进的过程中，医院信息系统的外延也不断发展变迁。现阶段，医院信息系统从原来的以医务系统为主的信息管理系统迅速向以医嘱系统为核心的电子病历转化。医院信息系统的设计开发也在全院各科室不同需求的促进下变得越来越复杂——既要满足医院各部门的业务流程，又要集成各种不同数据源的信息，还需要一个统一的便于管理的一体化服务界面。在开发这样的综合信息系统的过程中，需要院方和厂商通力合作，也需要院内各部门的相互协同。
（一）开发计划与需求分析
在构建医院信息系统时，最核心的问题是要明确建立该系统的目的以及医院通过信息系统需要实现的功能。医院中，各不同部门间的医疗流程存在差异，对于信息系统的要求也各不相同。在制定全院信息系统开发计划时，需要不同科室、不同职务人员的整体协调合作，以此来完成覆盖医院每个部门需求，令使用者满意的开发方案。
从广义上来说，医院信息化建设的根本目的是最大限度的实现医院人、财、物管理的计算机化，实现日常医护工作、医院管理工作、医疗质量监控和仪器数据采集等方面的信息化，适合于医院进行医疗改革、信息管理、决策支持并且符合医院数字化管理的发展趋势。在这个要求的基础上，同一家医院中不同的部门都应该根据自身的实际情况，梳理出各自的目标，解析其中的共性和个性，以便汇集综合成医院信息系统建立的统一目标。
构建医院信息系统的目的和提出医院所需的功能都建立在需求分析的基础上。开发计划中，需要明确系统功能、规模以及相关的条件限制等内容。在开发过程中，使用者往往对系统的细节要求也不是十分清晰，这就需要开发者与医院用户进行详细深入的调查、研究、讨论。同时，开发负责人的业务知识水平要高于最终使用者，需要既熟悉医院业务流程、又熟悉系统开发流程的人员统筹系统开发工作。
前面提到了瀑布法、原型法以及螺旋法等系统开发管理模型。不管采用何种模式，首先都要进行需求分析，对医院业务流程中需要信息系统完成的工作流进行解析，明确最终用户对系统的使用要求。在具体进行需求分析、现状分析时，常用的方法有以下一些。
1．KJ法 KJ法是将未知的问题、未曾接触过领域的问题的相关事实、意见或设想之类的语言文字资料收集起来，并利用其内在的相互关系作成归类合并图，以便从复杂的现象中整理出思路，抓住实质，找出解决问题的途径的一种方法。
2．集体研讨法（Brainstorming） 集体研讨法或头脑风暴法的特点是让与会者敞开思想，使各种设想在相互碰撞中激起脑海的创造性风暴，其可分为直接头脑风暴和质疑头脑风暴法。前者是在专家群体决策基础上尽可能激发创造性，产生尽可能多的设想的方法；后者则是对前者提出的设想，方案逐一质疑，发行其现实可行性的方法。这是一种集体开发创造性思维的方法。
3．关联图法 又称关系图法，是用来分析事物之间“原因与结果”“目的与手段”等复杂关系的一种图表。关联图法适用于多因素交织在一起的复杂问题的分析和整理。它将众多的影响因素以一种较简单的图形来表示，易于抓住主要矛盾、找到核心问题，也有益于集思广益，迅速解决问题。
4．系统图法 是指系统寻找达到目的的手段的一种方法，它的具体做法是将把要达到的目的所需要的手段逐级深入。系统图法可以系统地掌握问题，寻找到实现目的的最佳手段，广泛应用于质量管理中，如质量管理因果图的分析、质量保证体系的建立、各种质量管理措施的开展等。
5．数据流程图法 数据流程图（data flow diagram，DFD）是一种结构化分析描述模型，用来对系统的功能需求进行建模，它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况。
6．实体-联系图法 实体-联系图，又称E-R图，提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。
医院信息系统的建设包括硬件要素、软件要素、人员培训等各种项目，而软件开发是其中所占比重最大，也是最复杂的部分。在经历了19世纪60年代之前的软件危机后，人们逐渐意识到落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重的问题。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率。因此，1968年北大西洋公约组织的计算机科学家在联邦德国的国际会议上正式提出“软件工程”，以此来研究和克服大规模、高复杂性开发要求下的软件系统设计问题。
医院信息系统设计同样需要遵循软件工程的方法来设计开发。包括以下一些流程。
（1）开发手法：过程建模。
（2）开发技术：结构化分析。
（3）开发环境：语言、工具等。
通过这样的流程，可以最大限度避免个人能力对整体系统开发的影响，达到工业化开发的质量和效率。
（二）医院信息系统规格书的设计
医院信息系统规格书是医院对厂商投标提出的具体要求，相当于需求规格说明。规格书的内容需要让厂商清晰地了解医院对信息系统建设的需求。如果规格书的要求过于模糊，会使医院的要求和厂商提供的产品之间存在差距，一旦签约，就可能对今后的开发工作造成诸多问题，甚至让开发陷于瘫痪。如果规格书的要求过于细致，同样会由于不必要的限制而阻碍了厂商的进入，对后续开发工作造成困扰。
1．医院信息系统规格书主要由以下几方面组成。
（1）概要说明。
（2）物品采购及技术参数。
（3）各种资料。
2．概要说明需要包括以下几部分。
（1）物品采购的背景和目的。
（2）采购物品及构成内容。
（3）采购种类。
（4）技术要素概要。
（5）其他。
概要说明中，还需要写入竞标条件等内容。
3．物品采购及技术参数是规格书中最重要的部分，包括以下一些要素。
（1）系统整体要求要素。
（2）硬件技术要素。
（3）软件技术要素。
（4）设置条件。
（5）开发、维护、售后体制。
其中，技术要素中需要以下资料：①医院整体图；②网络构成；③部门机器配置一览表；④电子化对象业务、开发计划概要；⑤系统导入日程安排；⑥联机一览表；⑦现有系统构成。
在此部分中，厂商也可以添加其他必要项目和资料。
规格书中，软硬件要素是最主要的部分，需要提供详细的内容。下面就这2方面具体说明。
在硬件要素中，要考虑终端和服务器2个方面。终端包括PC及各种外围设备，针对不同场合，需要不同性能特点的产品，如病房查房时需要用便携时无线设备（笔记本、PDA等）。各种设备需要有详细的设置计划和管理程序，以便整体部署和后期维护升级。服务器主要由厂商提供方案，需要根据医院的规模、从业人数、就诊量等对数据量进行评估，从而设计出符合医院需求的以服务器集群为核心的主干运算设备架设方案。
在软件要素中，规格书需要详细说明各个子系统的功能要求。这一工作主要由熟悉医院流程的领域专门人员完成。要充分调动医院各个部门的负责人，使他们在这一工作中发挥作用。软件要素是一个弹性比较大的内容，如果把讨论余地较大的部分限制过细，如必须使用何种构架、指定开发环境等，就会对后续开发工作造成不利影响。软件开发的最终目的是在硬件设备上完成医院对信息系统的要求，设计的方式就应该是以需求为导向，自顶向下、从宏观到局部的设计。因此，编码等细节总是最后考虑的内容，不需要在开始限制过多。软件要素部分也是整个开发过程的核心，工作量很大，需要较多人分担、协调完成。
（三）开发体制与开发管理
要顺利地完成一个庞大而复杂的医院信息系统，需要完善地开发体制和健全的开发管理作为保障。
软件开发队伍中有3个重要角色：产品经理、系统架构师和项目经理。
产品经理专项负责产品设计。在国内软件业中常让具体开发者确定产品设计细节，这是一种非常危险的尝试。首先，如果产品的各个设计细节由多个开发者按各自的设想确定，那么概念完整性（软件系统作为一个整体，对于使用者体现出概念上的一致性、清晰度和简洁度）就几乎一定会被破坏。其次，具体开发者往往更注重系统实现中的技术因素，而对最终使用者的需求、动机和感受都缺乏体会，因而单纯出自程序员的产品设计，总是会偏离使用者对业务和易用性的实际需要，很难获得用户的欣赏。因此，在医院信息系统开发中，需要一个具有深厚的医疗领域经验，对医院业务领域非常熟悉的人。
系统构架，是对已确定的需求的技术实现构架。与产品设计相比，系统构架设计的工作更明确，而目前该领域也已经形成了较为成熟、完善的方法论和一整套易于掌握、传授的知识。相应地，系统架构师是技术人员，主要着眼于系统的“技术实现”。其责任是最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。因此，他应该熟悉特定的开发平台、语言、工具，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。
项目控制注重的就是“管理”。它主要关注的是项目本身的进度、质量等方面。软件开发项目需要专人负责这些内容，项目控制/管理已经形成了一个专门的学科（project management），对于软件项目经理，其职责也未脱离该学科的描述，包括项目计划、进度跟踪/监控、质量保证、配置/发布/版本/变更管理、人员绩效评估等方面。
在具体的开发管理过程中，需要考虑系统开发时间、成本、质量等问题，要满足这些需求，就需要进行详尽的项目开发管理。控制项目管理的重要性已经被广泛认识了，这有助于推进技术的体系化。
项目管理构成要素包括以下9个方面：综合管理、项目范围管理、时间管理、成本管理、品质管理、组织管理、交流管理、风险管理、采购管理。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
