【毕业学位论文】（Word原稿）数字化医院门诊信息系统的设计与实现-软件工程

I 硕士学位论文 （软件工程） 数字化医院门诊信息系统 的设计与实现 研 究 生：张海娜 学号： 1121170048 所在学院：软件学院 学科门类：软件工程 学科专业：软件工程 指导教师： 朱少民 副指导教师： 王呼生 二 一 三 年 三 月 in or 2013 1121170048 字化 医院门诊信息系统 张海娜 同济大学 位论文版权使用授权书 本人完全了解同济大学关于收集、保存、使用学位论文的规定，同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有关部门或者机构送交论文的复印件和电子版；在不以赢利 为目的的前提下，学校可以适当复制论文的部分或全部内容用于学术活动。 学位论文作者签名： 年 月 日 V 同济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任由本 人承担。 学位论文作者签 名： 年 月 日 6 摘要 随着信息系统、数字化技术的加快，人们对各行各业的技术服务要求也越来越高。医院作为大众生活所不能缺少的一个重要部门，过去的手工开单的就诊流程已远远不能满足人们的需要，研究如何利用信息化手段优化就诊流程，实现医院门诊部的信息化建设，对不断提高医院的服务水平，全面建设数字化医院有着十分重要的现实意义。医院门诊信息系统 (起到关键性的作用。实践表明，门诊信息系统 的使用，能对医院资源进行有效整合，减轻门诊工作人员的劳动强度，提高医院门诊部的服务效率和服务质量，并为医院决策部门提供准确的数据，使得院方能够有效的统计分析各项医疗数据。 本文对目前医院信息系统的现状进行了分析研究，简要介绍了所选的课题背景，以及涉及到的医院相关业务和发展情况，随后进行了医院门诊信息系统的详细需求分析工作，并对所涉及到的理论基础知识做了简要的介绍，从而进一步提出了医院门诊信息系统在软件方面的总体体系架构和技术路线。全面论述了门诊信系统的设计方法和开发步骤，从客户端、 务端到应用服务端进 行了详细的结构设计。继而从数据模型、页面表现形式和业务处理逻辑止方面进行了详细设计。阐述了开发基于 B/S 架构模式的医院门诊信息管理系统的必要性，详细分析了实现 B/S 架构在开发过程中遇到的各种问题，提出了解决问题的方法和意见。采用比较流行的 E 技术，探讨了新的医院门诊管理流程，提出了一个全新的医院门诊信息系统模式 基于 E 的现代医院门诊信息系统。此管理流程的提出，解决了医疗门诊服务中挂号、收费等繁琐的问题，同时简化了医生书写病历的过程，为门诊病历的长期保存和查询提供有效的手段。 关键词 ： 体系结构 ； E； 医院信息系统 ； 门诊信息系统 ； 需求分析 ； 业务功能 7 of of a to of as a of to to to of of a in IS of of be to of of of by a of to of in of to on a , of , to By E a E it of to 8 E, 9 目录 第一章 绪论 . 11 文研究的背景及意义 . 11 文的主要 内容 . 12 文的组织结构 . 13 文创新 . 14 第二章 系统开发的理论基础和关键技术 . 15 E 的概念和体系架构 . 15 E 的概念 . 15 E 应用模型 . 15 E 应用程序组件 . 15 器 . 16 间件相关知识 . 17 架 . 18 0G 数据库 . 19 于 系统开发 . 21 例驱动的过程 . 21 架构为中心的过程 . 21 代和增量开发 . 22 结 . 22 第三章 门诊信息系统的需求分析 . 23 查用户需求 . 23 求分析方法 . 24 需求分析的基本任务 . 24 构化分析 . 24 型法 . 25 统需求分析 . 25 统总体需求 . 25 院门诊业务分析 . 26 院门诊信息系统与医院信息系统及其他系统的关系 . 27 门诊业务功能划分 . 28 门诊业务流程 . 29 诊各子系统功能用例分析 . 30 结 . 38 第四章 系统设计 . 39 10 系结构 . 39 统功能设计 . 41 统设计原则 . 42 据库设计 . 43 据库设计原则 . 43 据库表结构说明 . 44 统模块设计 . 47 统模块界面设计 . 48 统模块页面跳转逻辑 . 50 第五章 系统实现 . 51 统配置文件 . 51 置文件 . 51 置文件 . 52 置文件 . 53 置文件 . 55 置文件 57 系统部分功能模块实现代码 . 57 系统登录 . 57 病人基本信息管理 . 59 处方管理 . 62 药品入库管理 . 64 门诊诊断 . 65 第六章 测试与验证 . 67 能模块测试 . 67 统登录 . 67 人基本信息维护 . 68 号管理 . 71 方管理 . 73 品入库管理 . 76 诊诊断结果 . 79 诊收费结算 . 80 证 . 81 第七章 结论与展望 . 84 参考文献 . 86 11 第一章 绪论 文研究的背景及意义 在我国，医院信息系统 (众多信息工作者和医院工作人员的共同努力之下，经过十多年的发展，逐步形成了一套完整的医院信息系统。已经能够完成基本的医院信息共享，办公自动化，管理计算机化，传输网络化等 需具备的功能。随着信息技术的不断发展，医院信息系统也得到了长足的发展。医院信息系统在各种信息系统中属于较为复杂的一类。这是由医院自身特点所决定的，医院信 息系统具有技术的复杂性、调用资源的密集性和用户需求的多样性等特点。医院信息系统既有众多的和诊疗相关的软件，又有许多和财务、统计、物流等相关的软件，这就使得医院信息系统成为各类信息系统中较为繁杂的一类。在医院信息系统中门诊信息系统又是极为重要的一部分，它是直接为广大患者提供医疗服务的重要窗口之一，也是各个医院信息化建设的重中之重，一所医院的门诊信息化建设工作将直接影响到整个医院信息化建设的发展程度。一所医院的门诊接诊速度、能力是直接影响患者是否会选择该医院进行就医的重要因素。如何以更加现代化、科学化、规范化的 手段来加强对医院的管理，提高医院的工作效率，改进医疗质量，树立现代医院的新形象，力日强医院门诊信息化建设工作是建设数字化医院的重要课题。 为了更好的开展门诊信息建设工作，满足患者就诊时的各种需要，尽快的为每一位患者诊治疾病，缩短患者的等待时间，就必须对门诊患者的就诊流程进行优化。如何才能真正的缩短病人的就诊等待时间 ?如何才能使就诊流程得到优化。设计医院门诊信息系统就可以优化就诊流程，缩短患者就诊等待时间，为门诊医生提供快速的操作流程，使医生可以有更多的时间用于为患者诊治，而不必将更多的时间用于开具检查、检验 单等诊疗项目和处方。在打破原有的工作流程的基础上建立一套全新的门诊就诊流程，从而为医院的信息化建设起到推进性的作用。伴随日益增大的门诊病人就诊信息，需要一个更为庞大的门诊信息系统对现有的门诊信息进行全方位的管理。从病人的基本信息到就诊信息，包括详细的就诊病历，诊疗项目的申请单，检查、检验申请单和报告单，处方，门诊摆药等等诸多信息。 这些庞大的信自对门诊信息系统的性能提出了更高的要求，主要包括以下儿个方面 : (1)高度可用性 能够满足日益增长的就诊人数的需要 ； (2)安全性 能够保护患者的所有就诊信息和医院信 息系统 (数据完 12 整性。每位患者的就诊信息都是具有法律效力的，作为院方有义务对患者的就诊信息、进行合理有效的保管，防止一切信息破坏。同时，这就对医院的网络安全提出了更高的要求，医院需要对自身的数据库做好一切安全保障工作。 (3)可靠性及伸缩性 能够及时快速的处理所有的门诊业务，能够让医生所开具的各项诊疗单和处方等准确、快速的到达各个检查、检验科室、门诊药房等。 文的主要 内容 医院信启、系统 (信息化建设的发展影响之下已逐步实现了住院病人无纸化电子病历，住院病人就诊环节实现了计算机共享 资源病人所有就诊信息。门诊患者日益增多、门诊病人就诊信息没有能够及时得到信息共享，大大影响了门诊的管理工作，造成了门诊工作较为混乱的现状，人为差错屡见发生。 为了解决这些传统医疗方式的管理和效率问题，各个医院在已有医院信息化建设的基础上重点发展门诊医生工作站，实现门诊“一卡通”就诊，本论文根据现在医院发展的特点和数字化医院发展的目标，提出了一种数字化医院门诊信息系统的建设方案。课题是基于 E、 相关技术，旨在设计一种功能实用、技术先进、易于扩展和移植的数字化医院门诊信息系统。 本论文研究的主 要内容包括 : (l)对我国医院门诊业务进行分析 (2)医院门诊医生长期以来一直采用手工工作的方式，对于就诊患者的检查、检验单，处方等都是采用手工书写的方法，这样，将大量的时间浪费在了书写各种申请单以及处方之上，现有的门诊工作流程存在很多的不足和弊端，在现有的工作流程基础上明确新的门诊信息系统的业务流程。 (3)提出需求分析 。 (4)本论文在已经存在的门诊工作流程的基础上提出了最初的需求分析。 (5)论文研究了医院门诊信息系统与医院收费系统、检查系统 (检验系统 (医保系统等各系统之间的接口 ，明确医院门诊总体业务流程和业务功能划分。门诊信息系统中各个模块的功能划分，描述各个模块中的数据流向，提出了门诊信息系统具体的业务功能定义。为之后的具体设计以及程序实现提供了详细的需求分析报告。 (6)系统总体结构设计 (7)在研究医院门诊信息系统业务流程的基础上，对门诊信息系统进行总体结构设计。 13 (8)由于医院信息系统子系统众多，各个系统分散等特点采用分布式结构。本论文是采用 E 架构，利用 架， 技术实现系统的设计。 (9)门诊信息系统是医院信息系统 (最为庞大 、繁杂的一部分，本论文从 层架构出发，提出了门诊信息系统在客户端、 务端和应用服务端的详细设计方案。 (10)完成系统详细设计 。 (11)本论文需要对门诊信息、系统进行详细设计，从数据模型、数据结构到界面设计和逻辑处理等详细的设计。 (12)门诊信息系统的实现 。 (13)实现本论文所设计的门诊信息、系统，能够实际应用于各大医院的门诊部工作之中。 文的组织结构 本文首先介绍了论文研究的一些背景知识和研究该课题的意义所在，然后讲述了门诊信息系统的需求分析方法，门诊需求分析和门诊管理功能分析， 业务总流程。最后门诊信息系统的具体软件设计，包括数据库的设计，门诊各个管理模块的功能结构设计和详细设计。其具体内容安排如下 : 本论文共分为五章。 第一章是绪论，主要介绍了论文研究的一些背景知识和研究该课题的意义所在。 第二章是系统开发的基础理论和一些关键性技术，主要详细介绍 E 概念，相关理论知识，系统实现开发的关键性技术。 第三章是门诊信息系统的需求分析，讲述了门诊信息系统的需求分析方法，门诊需求分析和门诊管理功能分析，业务总流程。 第四章 是门诊信息系统的设计，基于 E 门诊信息系统的具体软件设计，包括数据库的设计，门诊各个管理模块的功能结构设计和详细设计。 第五 章是门诊 信息系统的系统实现 ， 列举了主要的系统配置文件和程序文件。 第六 章 为系统的测试与验证，列举了 7 个模块系统实现的界面截图；验证方面主要通过系统实现业务操作，最终输出准确的数据结果。 14 结论是对全篇论文的总结，论文中各部分的工作内容，对未来数字化医院的全面发展的展望。总结了本文研究的工作及未来发展前景的思考。 文创新 本文的创新点有以下几个方面 : (l)将医院门诊信息系统与 E 技术相结合，旨在开发一个系 性能更为优化的门诊信息系统软件。 (2)该系统的应用能为医院信息系统提供更为全面的门诊支持，为医院统计分析数据提供更为全面有效的数据。 15 第二章 系统开发的理论基础和关键技术 E 的概念和体系架构 E 的概念 E， 台企业版（ 是 司为企业级应用推出的标准平台。 台共分为三个主要版本 E、 E。 司在 1998 年发表 本的时候，使用了新名称 “ 台”，修改后的 为 分为标准版（ 企业版（ 2微型版（ 由此诞生。 2005 年 6 月， 会召开， 司公开 E 6。此时， 2”： 名为 E, 名为 E， 名为 E。 随着 术的发展， 台得到了迅速的发展，成为 言中最活跃的体系之一。现如今， 仅仅是指一种标准平台，它更多的表达着一种软件架构和设计思想。 一系列技术标准所组成的平台，包括： 。 E 应用模型 E 使用多层分布式的应用模型，这个多层一般是通过三层或四层来实现 : (l)客户层 :即一些运行在客户端计算机上的组件。 (2) :即一些运行在 E 服务器端的组件。 (3)业务层 :与 相同，也是运行在 务器端的组件。 (4)企业信息系统层 (是指那些运行在 务器端的软件系统。 E 应用程序组件 E 应用程序是由一定的组件构成的。 E 组件是一个封装了功能的软件单元，能够与相关的一些类和文件一起组成 E 应用程序。 16 (l)应用程序客户端和 指运行在客户计算机的组件。 (2)基于 术的组件叫 件，它们都运行在服务器。用程序、过滤器和 件监听器。 E 的 件可以是 面。在应用程序组装过程中，静态 面和 可以一起打包成 件，但这并不是 件。 (3)企业 件叫做业务组件，同样运行在服务器端。业务代码是指那些由位于业务层的企业 行的逻辑，它们能够解决或满足特定的商业领域的一些需求。会话 体 消息驱动 成了三种不同类型的企业 话 表的是客户一次短暂的会话过程，当客户所执行的会话完成后，会话 及它所包含的数据也随之消失。实体 存储在数据库表中的一行记录，即便客户已经终止或关闭了服务器，在 E 底层的会话服 务确保实体 数据被保存下来。 器 容器是 E 的运行环境，这种环境是为应用组件服务的。各个容器为相应类型的应用程序组件提供底层服务。 每种容器根据各自应用组件不同提供不同类型的服务 。 容器涉及到各个方面，为组件运行提供必要的支持。对于不同容器中相同的服务为应用组件提供的接口是相同的。 图 2E 体系结构图 17 间件相关知识 为了能够更好的解决分布异构所带来的问题，从而人们提出了中间件(概念。中间件是位于平台 (硬件和操作系统 )和应 用之间的通用服务，中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源 ； 中间件是位于客户机 /服务器的操作系统之上，其作用就是管理计算机资源和网络通讯。 如图 2示，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。 图 2间件 也许我们很难为中间件做一个严格的定义，但是中间件应该具有以下一些特点。 (1)能够满足大量应用的需要 ； (2)支持运行于多种硬件和 0S 平台 ； (3)支持分布计算，提供跨网络、硬件 和 0S 平台的透明性的应用或服务的交互功能 ； (4)支持标准的协议 ； (5)支持标准的 接口 。 中间件的分类会因为不同的角度或是不同的层次而有所不同。大致可以将其分为以下几类 : 数据访问中间件、远程过程调用中间件、消息中间件、交易中间件、对象中间件等。 中间件应该具备以下两个关键特征 :首先是基本条件，即为上层的应用层服务 ； 其次必须连接到操作系统的层面，并确保保持运行工作状态，具备了以上 18 这样两个特征才能称为中间件。 中间件能够屏蔽操作系统和网络协议的差异，为应用程序提供多种通讯机制 ； 并提供相应的平台以满足不同领域 的需要。因此，中间件为应用程序提供了一个相对稳定的高层应用环境。 架 一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 E 应用程序开发提供集成的框架 。 架的实现目标其实就是提供一个用统一的、高效的方式所构造的应用，并且还可以将单层框架以最佳组合形式相互揉和在一起建立一个连贯的体系。可以说 一个提供了更完善开发环境的一个框架，可以为象提供企业级的服务。 架是一个由 7 个已经定义良好的模块所构成的分层架构。 月这些核心容器是那些已经定义好了创建、管理和配置 方式，如 图 2示 。 图 2架的 7 个模块 19 架是由这些单独的模块 (或组件 )构成的，其中每一个模块 (或组件 )都可以单独存在，同时这些模块也可以与其他的一个或者儿个模块联合起来共同实现 架。下面将大致介绍一下其中每个模块的功能 ： 核心容器具有向 架提供用来实现它的一些基本功能的作用， 其主要组件。 用控制反转 (式可以将应用程序的依赖性规范和应用程序的配置文件与实际应用中的程序代码相互分开 。 下文实际就是一个配置文件，它的功能就是向 架提供上下文的信息。 下文大致包括如 子邮件、 、调度和校验功能等的企业服务 ； 常 象层 框架提供异常层次结构，该结构可以用来管理那些不同的数据库供应商所发出的错误信息和所发生的异常处理。 块可以很容易地使 架管理的任何对象支持 且能够通过配置管理特性。 作用就是为基于 应用程序提供上下文， 下文模块其实就是建立在应用程序上下文模块之上的模块。 块还大大简化了将那些请求参数绑定到域对象和处理多部分请求的工作 ； 架可以插入几个 架，因而向该框架提供了 对象 关系工具，其中包括 架是一个构建 用程序全功能的 现。通过使用策略接口可以生成一个高度可配置的 架，中包括了众多的视图技术，其中有 。不同的 E 服务器中可以使用不同的 架的功能， 架的大多数功能也可以应用于不受管理的环境。 核心就是能够支持不绑定于某特定 E 服务的数据访问对象和可重用业务，当然这些对象肯定是可以在不同 的 E 环境 ( 测试环境、独立应用程序之间重用。 在设计应用程序 ， 式 (例如 通常很难给出一个简单明了的框架结构。而 架却具有能够使设计工作变得更为简单的能力。软件开发工作者们可以通过使用 象层来解决针对那些复杂的框架结构的重新设设计工作。 据库 考虑到医院的门诊部和住院部每天的信息、量是非常庞大的，在使用门诊信息系统后，每天用户量也很多，随之而产生的海量的数据，从病人的基本信 20 息到就诊信息 ，病历、处方、检查、检验等等一系列和就诊相关的信息。基于这些问题的考虑，我们就需要一种支持海量数据交互处理的数据库服务器，因此选用了 据库。 以高级结构化查询语言 (基础的大型关系数据库。除了满足多用户、大事务量的海量交互处理的需求外，还具有以下特点 : 对 4 位平台的支持。支持 极大地改进了多层开发架构下的 能和可扩展能力。新的版本也借用了 作系统 对 持的优势。 在这个版本中，一个新类型的表对象被引入。该表结构对大量插入和解析数据很有益处。这个表结构对 数据处理 应用有着很好的支持。这样的应用在电信、生产应用中常常能够用到。通过使用这种优化的表结构能够对电信级的应用起到 巨大的性能改进作用。 分区 通过对哈希分区的全局索引的支持可以提供大量的并发插入的能力 。 提供了预升级检查能力，有效地减少升级错误。 去除了 很多和数据库配置有关的任务或者对其加以自动化。 新版本的数据库能够配置成使用 供的存储虚拟层（ 。自动并简化数据库的存储。 管理员 现在可以管理少数的磁盘组而无需管理数千个文件 配置磁盘组，提供数据冗余 和数据的优化分配。 上一个版本对 够进行自动化 这版本能够 对 关的参数进行调整。这意味着 需要对 2 个 内存参数 进行配置：用户可用的总的内存数量和共享区的大小。 缩短应用和数据库升级的宕机时间 ， 通过使用 据库。允许在不同版本的 产品数据库间切换。现有的联机重定义功能能够支持一步克隆所有相关的 数据库对象 ； 超大数据库的支持 ，可支持到 8E 的数据量。改进的存储、备份、恢复管理也对超大数据库有着很好的支持。分区可以支持索引组织表 ； 缩短信息 周转时间 ， 新版本的 供了加强的 能。可以方便的构建大型数据仓库和多个数据集市。一个新的变化数据捕捉的框架允许 管理员 能够轻易的捕捉并发布数据的变化。新的 能利用的是 术架构。 21 于 系统开发 一软件过程 )是一个面向对象且基于网络的程序开发方法论。遵循它的开发方法可以在进度和成本的范围内开发出高质量的软件产品。 有以下三个重要特征 :用例驱动、以架构为中心和迭代增量开发过程。 例驱动的过程 用例分析是一种需求分析的技术，需求工作流的目标即描述系统应该做什么，并使得开发人员和用户通过需求工作流就这一描述达成一定的共识。为了达到该目标，要对需要的功能和约束进行提取、组织和文档化 ； 其中尤为重要的是理解系统所解决问题的定义和范围。 分析和设计工作流将需求转化成未来系统的设计，为开发一个结构健壮的系统，并调整设计使其与实现环境相匹配，使其性能更为优化。分析设计的结果是一个设计模型和一个可选的分析模型。体系结构并不仅仅是良好设计模型的载体，同时也在系统开发中能提高被创建模型的质量。 实现工作流的目的包 括以组件的形式 (源文件、二进制文件、可执行文件 )实现类和对象 ； 以层次化的子系统形式定义代码的组织结构 ； 将开发出的组件作为单元进行测试以及集成由单个开发者 (或小组 )所产生的结果，使其成为一个可执行的系统。 架构为中心的过程 在 ，软件系统的构架是指系统重要组件的组织或结构，这些重要组件通过接口与那些不断减小的组件与接口所构成的组件进行交互。架构主要具有以下三个作用 : (1)稳定的架构。 细化阶段结束的时候，要求得到一个稳定的构架，稳定的构架是指即使未来再在系统中加入新的功能，也不会因 此而导致构架的设计大幅变化。构架是系统高层结构的设计，只要构架变化，软件的修改就是全局性的，即不仅需要写新加入功能的代码，还需要修改其它部分来配合新加入的功能 ； 这样如果在较早阶段构架能够稳定下来，未来再编写新功能的成本也就大大降低了，大致就相当于新功能实现本身的成本。 (2)构架的控制作用。 构架作为基线，指导非构架部分的设计和编码实现。 为整个软件的构架和质量关系是最为密切的，为了保证不会发生重大风险，就需要控制好构架的质量，从而保证整个软件未来的可扩展性。 22 (3)分工作用。因为构架并不包括实 现以及对算法的考虑，虽然设计构架工作量相对比较小，但是它对质量的影响却是极为巨大的，因此可以使用那些经验较为丰富的高层软件开发人员来完成构架，让相对比较年轻，经验不够丰富的人员做其它的部分，这样整体上软件的质量就可以得到相应的保证，又可以减少高层人员的工作量，降低成本。 代和增量开发 迭代是指带有己建立基准的计划和评估准则的独特活动序列，迭代生成系统的内部或外部发布版。 的每一个阶段可以进一步分解为一次迭代。一个迭代是一个完整的开发循环，它增量式的发展，从一个迭代过程到另一个迭代过程 直到成为最终系统。 迭代过程具有以下三个优点 : (l)降低了在一个增量上的开支风险。如果程序开发人员重复某一个迭代，那么即使这一迭代的开发是错误的，也只会损失这一个开发有误的迭代的花费。 (2)降低了产品无法按照既定进度进入市场的风险。在开发早期就可以确定风险，这样可以尽早的解决，不至于在开发后期才匆匆忙忙的解决。 (3)加快了整个开发工作的进度。因为开发人员清楚问题的症结所在，他们的工作会更有效率。 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段，小断细化的。囚此，迭代过程这样 的模式就会更容易的适应需求的变化。 结 本章主要是对完成论文的基础理论和一些概念进行了介绍。其中包括中间件的相关知识，概念、特点、分类。本论文是基于 E 的系统开发，着重介绍了 E 的概念和体系架构。系统开发涉及到的数据库、框架知识，最后介绍了基于 系统开发。通过本章节的内容，旨在了解系统开发的相关理论基础技术。 23 第三章 门诊信息系统的需求分析 医 院信息化是医院应用信息技术及其产品的过程，是信息技术由局部到全局、由战术层次到战略层次向医院的全面渗透，运用于流程管理、 支持医院经营管理的过程。信息化的实施从自上而下的角度说，必须与医院的制度创新、组织创新和管理创新结合；从自上而下的角度说，必须以作为医院主体的业务人员直接受益及其使用水平的逐步提高为基础。 查用户需求 本系统的最终用户为医院，我们根据从医院方面取得的图表资料、文字资料以及其他细节方面的信息，根据我们日常生活中的经验，根据我们所做的其他询问和调查，得出用户的下