基于SSH的医院门诊管理系统的设计与实现计算机软件专业.doc

中文题目：基于 SSH 的医院门诊管理系统的设计与实现 外文题目：The Design and Implementation of Management System for Hospital Outpatient Based on SSH 毕业设计（论文）共 75 页（其中：外文文献及译文 6 页） 完成日期 2015 年 6 月 答辩日期 2015 年 6 月 摘 要 人类社会进入二十一世纪，医院作为一个特殊的服务行业，其发展应适应于市场经 济的发展。目前，我国的医疗体制正处于发展阶段，需要医疗市场的进一步规范信息化， 这就要求医院加强自身的管理，利用现代化的管理工具对医院的工作进行必要的管理。 本文设计并且实现了一个基于 Web 技术的医院门诊管理系统，目的是为了提高医院门诊 的工作效率和信息的准确程度，根除现行的人工管理模式存在的效率低下和人员浪费等 弊端，进而达到减支增效的目的，并且更好的服务于社会。系统主要以 Java EE 作为开发 基础，主要使用了 SSH 框架，用 MyEclipse 作为开发工具，以 MySQL 作为数据库，以 Macromedia 公司的 Dreamweaver 作为界面美化工具，使用 Java 语言开发，页面采取 JSP 动态页面开发技术。该系统界面简单，操作方便，容易维护。 关键词：医疗体制；医院门诊管理系统；人工管理模式；SSH ABSTRACT When the human entered in the society of twenty-first Century, the hospital is as a special service industries, its development should adapt the development in market economy.At present, Chinas hospital system is at a stage of development, to further standardize the need of medical market, the hospital should strengthen their own management, making the necessary management for hospital work by using modern management tools. The graduation project has designed and implemented a outpatient hospital management system based on Web technology, which is to make the degree of the work efficiency and information improved, to eradicate the shortcomings about the inefficient and the waste of staff of the existing mode of artificial management, then the quality of the medical and service would be improved, and the society will be better served. This system mainly uses JavaEE as the basis of development, its mainly use the SSH framework, its also using MyEclipse as a development tool, using MySQL as the database, using Macromedias Dreamweaver as the interface landscaping tools, using JAVA language to development, and adopting the technology of JSP dynamic web page to development. The system has a simple interface, good operation and easy maintenance. Key Words: Medical system; Hospital outpatient management system; Artificial management model; SSH 目目 录录 1 项目概述.1 1.1 现系统概述1 1.2 医院组织机构1 1.3 系统业务流程2 1.4 系统功能模块3 2 系统需求分析.5 2.1 需求陈述5 2.2 USE CASE建模7 2.2.1 定义活动者.7 2.2.2 USE CASE 图8 2.2.3 用例说明.9 3 系统架构设计.27 3.1 架构设计目标27 3.2 系统架构设计.27 3.3 系统架构类图31 4 系统详细设计.33 4.1 系统交互图33 4.1.1 系统架构类交互图33 4.1.2 活动者与模块间的交互34 4.1.3 系统协作图37 4.1.4 系统状态图39 4.1.5 系统活动图40 4.2 业务逻辑对象类设计42 4.2.1 发现业务逻辑类42 4.2.2 业务逻辑对象类图42 4.3 数据库设计43 4.3.1 E-R 图43 4.3.2 物理表结构图.44 4.4 开发环境的选择47 4.4.1 系统开发工具.47 4.4.2 数据库的选择.47 4.4.3 系统网络架构配置.47 5 编码.49 5.1 概述开发工具及编程脚本49 5.2 脚本习惯说明50 5.3 脚本51 6 测试.52 6.1 测试原则及测试方法概述52 6.2 测试项目测试用例52 6.3 软件测试结论59 6.3.1 软件能力.59 6.3.2 缺陷和限制.59 6.3.3 建议.59 6.3.4 测试结论.59 总 结.60 致 谢.61 参考文献.62 附录 A 中文译文.63 附录 B 英文原文.66 附录 C 程序清单.69 1 1 项目概述项目概述 1.1 现系统概述现系统概述 医院信息系统(Hospital Information System，HIS)在国际学术界已公认为是新兴的医学 信息学(Medical Informatics)的重要分支。美国该领域的著名教授 Morris.Collen 于 1988 年 曾著文为医院信息系统下了如下定义：利用电子计算机和通讯设备，为医院所属各部门 提供患者诊疗信息和行政管理信息的收集、存储、处理、提取和数据交换的能力，并满 足所有授权用户的功能需求。而医院门诊管理系统便是医院信息系统的一个小的分支， 是组成医院信息系统中不可缺少的一个部分。 由于我国是一个人口大国，拥有众多的患者。大多数患者渴望能够及时了解自身病 情并希望得到更好的医疗资源，这就使得患者首先要对所就医的医院师资力量、医疗资 源有所了解，因此对医院方方面面的咨询成为解决的唯一途径。但是无论是直接向医生 咨询病情还是询问医院的其他信息，都不能实时的了解想要得到的信息，并且还会造成 医生耗费宝贵的工作时间，因此就需要有一种间接的手段来满足大多数患者对就医信息 的咨询，从而缓解医生的压力并且给其他患者就医留下更多宝贵的时间。 医院门诊部管理系统是医院管理系统中重要的子系统，对医院的门诊收费有很大的 帮助，科技进步已经将人类带入了全新的信息化时代，计算机和网络已经成为人们经营 和管理各种企业不可缺少的工具，随着各种新疾病的发现，各种新药物的研发，医生的 日常工作就随之显得更加复杂，医院门诊管理系统解决了医院人员、药品、处方信息的 同步管理，也使之变的更准确、透明，既提高了工作效率，同时也带来了经济效益，能 够杜绝欠费，减少漏费现象，从根不上防止价格的误划，减少重复劳动节约人力成本， 提高工作效率，增强各项收费透明度，提高医院的管理水平和社会现象。 医院实现信息化是大势所趋，很多有经济条件的医院使用了信息管理系统。传统的 系统对中心服务器和网络的依赖性很大，需要投入大笔资金和大量人力和物力，而且随 着业务量的增加需要不断地升级软硬件设备。这样的投入对于一些资金比较紧张的中小 型医院来说是很难负担的，本课题的目标就是利用较低档的计算机硬件设备实现功能上， 性能上和稳定性都比较完善的医院门诊管理系统。 1.2 医院组织机构医院组织机构 医院组织机构如图 1-1 所示。 医院的组织机构，由急诊部门、门诊部门、住院部门组成，各个部门和科室在互相 协作下共同完成医院的相关业务。 医院组织机构 急 诊 部 门 门 诊 部 门 住 院 部 门 科 室 管 理 科 检 查 化 验 科 医 务 管 理 科 药 品 管 理 科 图 1-1 医院组织机构图 Fig 1-1 Diagram of the Hospital Organizational Structure 1.3 系统业务流程系统业务流程 业务流程图符号说明如表 1-1 所示。 表 1-1 业务流程图符号说明 Table 1-1 Service flow chart symbol explanation 符号含义符号说明 实体表示单位或个人，圈内写明单位或个 人职务的名称。 输入输出报表表示输入或输出的报表、计划、单据、 报告等，框内写明其名称 。 处理表示业务处理，框内写明处理的名称。 账册表示各种帐目、规范、定额手册、报 表积累等大量存档信息, 符号内部写 明其名称。 业务流流向线，表示信息或处理的流向。 根据调研分析及业务分析，系统共需要经过如下几个个环节来办理一项业务， 得到 整个系统的业务流程图如图 1-2 所示。 开挂号单 挂号收费员 患者 患者 患者 申请挂号 受理 诊断 递交挂号 单 受理 确认缴费 开病情诊断书 开医嘱 申请检查化验 申请病情诊断 受理开处方药 药品管理 员 申请拿药交费 确认缴费受理 查询病历单 医生 开检查化验单 患者 申请检查 化验缴费 受理 检查化 验员 开检查化验结果单 患者 医生 患者 挂号收费 员 挂号收费员 患者 受理 患者 申请取药 受理取药 图 1-2 系统流程图 Fig 1-2 The workflow of system 1.4 系统功能模块系统功能模块 本系统分系统管理员、挂号收费处、药房处、检查化验处、医生和患者 6 个用户权 限。总功能图如图 1-3 所示。 用 户 管 理 科 室 管 理 医 生 信 息 管 理 患 者 账 户 管 理 检 查 化 验 收 费 标 准 管 理 药 品 信 息 管 理 普 通 门 诊 挂 号 专 家 门 诊 挂 号 挂 号 单 查 询 检 查 化 验 单 收 费 管 理 处 方 药 收 费 管 理 处 方 药 管 理 处 方 管 理 化 验 单 管 理 检 查 化 验 单 报 告 管 理 病 历 单 查 询 诊 断 管 理 处 方 单 查 询 检 查 化 验 单 查 询 医 嘱 开 处 方 病 情 诊 断 开 检 查 单 系统管理员 药房处 挂号收费处检查化验处 系统 患者医生 图 1-3 系统功能模块 Fig 1-3 Function models of system 2 2 系统需求分析系统需求分析 2.1 需求陈述需求陈述 根据调研需求分析得知，该系统共需要 19 项业务，即：系统管理员负责的 6 项业务 有用户管理、科室管理、医生信息管理、患者账户管理、检查化验收费标准管理和药品 信息管理；挂号收费处负责的 5 项业务的有普通门诊挂号、专家门诊挂号、挂号单查询、 检查化验单收费管理和处方药收费管理；药房处负责的 1 项业务是处方药管理；检查化 验处负责的 1 项业务是检查化验报告管理；医生的负责的 3 项业务有诊断管理（包括开 检查单、病情诊断、开处方和医嘱） 、检查化验单管理和处方管理；患者的 3 项需求业务 有病历单查询、检查化验单查询和处方单查询。 每项业务具体描述如下： 1）用户管理 需要系统管理者有权限地对门诊部其他人员进行添加，并且对这些用户进行查看、 删除和修改这些操作， 2）科室管理 需要系统管理员对医院科室进行唯一的管理，根据需求，管理的内容有科室的添加， 以及对添加科室的查询和删除。 3）医生信息管理 根据业务的需求，需要管理员对医生信息进行有效的管理，需要管理的内容有所有 医生的基本信息情况的记录和对这些信息的完善。 4）患者账户管理 根据业务的需求，需要系统管理员对所有患者的账户信息进行管理，需要管理的内 容有患者账户的基本信息的查看以及对患者账户的删除。 5）检查化验收费标准管理 根据业务的需求，需要系统管理员对检查化验处的项目进行唯一的有权限的管理， 其中需要管理的业务内容有对检查化验标准的添加，并对这些添加的项目进行查询修改 和删除。 6) 药品信息管理 根据业务的需求，需要系统管理员对药品信息进行严格的管理，其中需要管理的业 务内容有对药品的添加，并对这些添加的项目进行查询修改和删除。 7) 普通门诊挂号 调研需求分析后，需要挂号收费处对普通挂号的管理，也就是群众需要在门诊部的 挂号处进行普通医生的挂号需求。 8）专家门诊挂号 调研需求分析后，需要挂号收费处对专家挂号的管理，也就是群众需要在门诊部的 挂号处进行专家医生的挂号需求。 9）挂号单查询 根据业务的需要，需要挂号处对挂号患者的挂号信息进行查询，并且需要把生成的 挂号信息交给患者，以便患者自己查询自己的相关业务信息。 10）检查化验单收费管理 根据业务的需要，需要挂号收费处对患者的检查化验项目进行收费的管理 。 11）处方药收费管理 根据业务的需要，需要挂号收费处对患者所需要的药品进行收费的管理 。 12）检查化验报告管理 调研需求分析后，根据业务的需求，需要检查化验处查看患者的检查化验情况，进 而对患者展开检查化验服务，并开出检查化验报告单。 13）处方药管理 调研需求分析后，根据业务的需求，需要处方药管理处查询患者的用药情况，进而 对患者展开药品派发服务。 14）诊断管理 调研需求分析后，根据业务的需求，需要医生对患者的病情进行诊断管理，需要管 理的业务内容有对患者病情的查看，为患者提出检查化验项目，进而确定病情，然后开 处方药，最后再对患者进行嘱咐，完成需要医生服务的业务。 15）检查化验单管理 调研需求分析后，根据业务的需求，需要医生查询患者的检查化验情况，以便确定 患者的病情，进而对患者进行科学合理的治疗和帮助。 16）处方管理 调研需求分析后，根据业务的需求，需要医生查询患者的用药情况，以便更合理的 为患者开医嘱，进而对患者进行科学合理的治疗和帮助。 17）病历单查询 根据业务的需求，患者需要对自己的病历进行查看，对自己的病情进行全面的了解， 所以需要设置患者的病历单查询业务。 18）检查化验单查询 根据业务的需求，患者需要对就医时的检查化验报告单进行查看，对自己的病情进 行全面的了解，所以需要设置患者的检查化验单查询业务。 19）处方单查询 根据业务的需求，患者需要对自己就医时开出的处方药品单进行查看，以便了解药 品的使用情况，所以需要设置患者的处方单查询业务。 2.2 Use Case建模建模 2.2.1 定义活动者定义活动者 参与者（actor）是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备 和外部系统等。由于 UML 是最近几年才在国内流行起来的，所以很多译名并没有统一， 如 actor 就有很多不同的译名，包括参与者、活动者、执行者和行动者等1。 根据系统的需求可以确定 6 个活动者，即系统管理员、挂号收费员、医生、患者、检 查化验管理员和处方药管理员。 系统管理员通过受理权限登陆系统，需要进行用户管理, 对门诊部其他人员进行添加， 并且对这些用户进行查看、删除和修改操作,对科室进行管理, 管理的内容有科室的添加， 以及对添加科室的查询和删除,对医生信息进行有效的管理，需要管理的内容有所有医生 的基本信息情况的记录和对这些信息的完善, 对所有患者的账户信息进行管理，需要管理 的内容有患者账户的基本信息的查看以及对患者账户的删除, 对检查化验处的项目进行 唯一的有权限的管理，其中需要管理的业务内容有对检查化验标准的添加，并对这些添 加的项目进行查询修改和删除，对药品信息进行严格的管理，其中需要管理的业务内容 有对药品的添加，并对这些添加的项目进行查询修改和删除。 挂号收费员需要给患者进行挂号收费业务的管理，需要挂号收费处对普通挂号进行 管理，也就是群众需要在门诊部的挂号处进行普通医生的挂号需求，相对普通挂号，还 有专家挂号，即需要挂号收费处对专家挂号的管理，也就是群众需要在门诊部的挂号处 进行专家医生的挂号需求，根据业务的需要，需要挂号处对挂号患者的挂号信息进行查 询，并且需要把生成的挂号信息交给患者，以便患者自己查询自己的相关业务信息，挂 号收费处还需要对患者的检查化验项目和处方药项目进行收费的管理 。 医生人员需要对患者办理相关的业务，首先需要对患者的病情进行诊断管理，需要 管理的业务内容有对患者病情的查看，为患者提出检查化验项目，进而确定病情，然后 开处方药，最后再对患者进行嘱咐，完成需要医生服务的业务，根据业务的需求，需要 医生查询患者的检查化验情况和用药情况，以便确定患者的病情，进而对患者进行科学 合理的治疗和帮助。 患者需要办理的业务主要有一些查询项目，患者需要对自己的病历进行查看，对自 己的病情进行全面的了解，对就医时的检查化验报告单进行查看， 根据业务的需求，患 者还需要对自己就医时开出的处方药品单进行查看。 检查化验管理员需要查看患者的检查化验情况，进而对患者展开检查化验服务，并 开出检查化验报告单。 处方药管理处需要进行患者的药品管理业务，查询患者的用药情况，进而对患者展 开药品派发服务。 2.2.2 Use Case 图图 在计算机软件系统的分析和设计中，首先需要准确地描述用户需求中的功能需求， 以便进一步确定系统中应该建立那些对象。Use Case 图是一种描述用例的可视化工具， 它用简单的图形元素表示出系统的活动者，Use Case，以及他们之间的关系，准确地表达 了活动者与系统地交互情况和系统所能提供地服务2 根据系统需求分析，结合上节系统活动者的定义分析，得到医院门诊管理系统业务 的 19 个用例如下： 1）用户管理 2）科室管理 3）医院信息管理 4）患者账户管理 5）检查化验收费标准管理 6）药品信息管理 7）普通门诊挂号 8）专家门诊挂号 9）挂号单查询 10）检查化验收费管理 11）处方药收费管理 12）诊断管理 13）检查化验报告单管理 14) 处方管理 15) 病历单查询 16）检查化验单查询 17）处方单查询 18）检查化验报告管理 19) 处方药管理 结合活动者和用例得到系统的用例图如图 2-1 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-1 系统 Use Case 图 Fig2-1 Use Case for system 2.2.3 用例说明用例说明 用户管理环节需要完成系统管理者有权限地对门诊部其他人员进行添加，并且对这 些用户进行查看、删除和修改操作，经分析得到用户管理阶段用例图如图 2-2 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-2 用户管理 Use Case 图 Fig2-2 Use Case for user management 根据如上用户管理用例图得到用户管理用例说明如表 2-1 所示。 表 2-1 用户管理用例说明 Table2-1 Use Case descriptions for user management 用例名称用户管理 用例描述 当一个新用户被添加或被查询并进行用户信息查看和修改删除 的时候是这个用例的开始。它处理一个新用户的账户建立和基 本信息的登记，以及对所有已注册用户基本信息的查看、删除、 修改等问题，但是当系统管理员完成了一个新用户的创建或对 一个已注册用户的查看、修改或删除的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件系统管理员以权限登陆进入系统 后置条件添加一个用户；删除或更新一个已注册用户 基本操作流程1)系统管理员收到一个新用户注册请求 2)系统显示添加用户界面 3)系统管理员填写新用户的注册信息 4)填写完整后提交信息 5)正确提交后自动退出注册添加页面 6)新用户添加成功 可选操作流程在添加注册途中放弃注册，退出注册页面 在按照用户名查询出需要的用户后，对该用户进行基本信息查 询，然后点击返回 在按照用户名查询出需要的用户后，对该用户进行基本信息修 改，提交后自动返回用户管理界面 在按照用户名查询出需要的用户后，对该用户进行删除操作， 用户列表进行更新，该用户从列表中消失，页面自动返回用户 管理界面 被泛化的用例无 被包含的用例无 被扩展的用例无 科室管理环节需要系统管理员对医院科室进行唯一的管理，根据需求，管理的内容 有科室的添加，以及对添加科室的查询和删除，经分析得到科室管理阶段用例图如图 2-3 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-3 科室管理 Use Case 图 Fig2-3 Use Case for department management 根据如上科室管理用例图得到科室管理用例说明如表 2-3 所示。 表 2-2 科室管理用例说明 Table2-2 Use Case descriptions for department management 用例名称科室管理 用例描述当一个科室被添加或是被查询并进行查看和删除的时候是这个用例 的开始。它处理一个新科室的基本信息的登记，以及对所有已注册 的科室的基本信息的查看和删除的问题，但是当系统管理员完成了 一个新科室的创建或对一个已注册科室的查看或删除的时候，它就 结束了 参与者系统管理员 优先级1 状态通过审查 前置条件系统管理员以权限登陆进入系统 后置条件添加一个科室；删除一个已登记科室 基本操作流程1)系统管理员收到一个新科室登记请求 2)系统显示添加科室界面 3)系统管理员填写新科室的注册信息 4)填写完整后提交信息 5)正确提交后自动退出注册添加页面 6)新用户添加成功 可选操作流程在添加途中放弃登记，退出登记页面 在按照科室名查询出需要的科室后，对该科室进行基本信息查询， 然后点击返回 在按照科室名查询出需要的用户后，对该科室进行删除操作，用户 列表进行更新，该用户从列表中消失，页面自动返回用户管理界面 被泛化的用例无 被包含的用例无 被扩展的用例无 医生信息管理环节需要管理员对医生信息进行有效的管理，需要管理的内容有所有 医生的基本信息情况的记录和对这些信息的完善操作，经分析得到医生信息管理阶段用 例图如图 2-4 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-4 医生信息管理 Use Case 图 Fig2-4 Use Case for doctor of information management 根据如上医生信息管理用例图得到医生信息管理用例说明如表 2-3 所示。 表 2-3 医生信息管理用例说明 Table2-3 Doctor of information management use case descriptions 用例名称医生信息管理 用例描述当对医生信息管理的时候是这个用例的开始。它处理医生信息按条 件查询并进行医生信息查看和医生信息查询的问题，但是当系统管 理员完成了一个医生信息的查看或完善的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件系统管理员以权限登陆进入系统 后置条件更新一个已注册医生的信息； 基本操作流程系统管理员收到一个需要完善医生信息的请求 系统显示医生信息管理界面 系统管理员查询需要完善信息的医生 找到以后填写完善该医生信息 正确提交后自动退出完善操作界面 医生信息完善填写成功 可选操作流程在添加完善信息途中放弃添加，返回添加前的页面 在按照用户名或科室名或医生级别查询出需要的用户后，对该用户 进行基本信息查询，然后点击返回，返回到医生信息管理界面 被泛化的用例无 被包含的用例无 被扩展的用例无 患者账户管理环节需要系统管理员对所有患者的账户信息进行管理，需要管理的内 容有患者账户的基本信息的查看以及对患者账户的删除，经分析得到患者账户管理阶段 用例图如图 2-5 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-5 患者账户管理 Use Case 图 Fig2-5 Use Case for the patient account management 根据如上患者账户管理用例图得到患者账户管理用例说明如表 2-3 所示。 表 2-4 患者账户管理用例说明 Table 2-4 The patient account management use case descriptions 用例名称患者账户管理 用例描述当一个患者信息被查询的时候是这个用例的开始。它处理一个患者 账户信息的查看和删除的问题，但是当系统管理员完成了一个患者 账户的查看或删除的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件系统管理员以权限登陆进入系统 后置条件可能要删除一个患者账户 基本操作流程1)系统管理员收到一个患者账户信息查询请求 2)系统显示患者账户管理界面 3)系统管理员按用户名查询患者 4)找到该患者以后，对账户信息进行查看 5)查询完成后返回患者账户管理界面 可选操作流程在按照用户名查询出需要的患者账户后，对该患者账户进行账户删 除，然后点击返回 被泛化的用例无 被包含的用例无 被扩展的用例无 检查化验收费标准管理环节需要系统管理员对检查化验处的项目进行唯一的有权限 的管理，其中需要管理的业务内容有对检查化验标准的添加，并对这些添加的项目进行 查询修改和删除，经分析得到检查化验收费标准管理阶段用例图如图 2-6 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-6 检查化验收费标准管理 Use Case 图 Fig2-6 Use Case for check test charge standard management 根据如上检查化验收费标准管理用例图得到检查化验收费标准管理用例说明如表 2-5 所示。 表 2-5 检查化验收费标准管理用例说明 Table 2-5 Check test charge standard management use case descriptions 用例名称检查化验收费标准管理 用例描述当一个新检查化验收费标准被添加或是已注册检查化验收费标准被 查询并进行查看、修改和删除的时候是这个用例的开始。它处理一 个新检查化验收费标准的基本信息的登记，以及对所有已注册的检 查化验收费标准的基本信息的查看、修改和删除的问题，但是当系 统管理员完成了一个新检查化验收费标准的创建或完成对一个已注 册检查化验收费标准的查看、修改或删除的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件系统管理员以权限登陆进入系统 后置条件添加一个用户；删除或更新一个已注册用户； 基本操作流程1)系统管理员收到一个新检查化验收费标准的登记请求 2)系统显示添加检查化验收费标准界面 3)系统管理员填写新检查化验收费标准的注册信息 4)填写完整后提交信息 5)正确提交后自动退出注册添加页面 6)新检查化验收费标准添加成功 可选操作流程在添加注册途中放弃注册，退出注册页面 在按照用检查化验收费标准名称查询出需要的检查化验收费标准后， 对该检查化验收费标准进行基本信息查询，然后点击返回 在按照检查化验收费标准名查询出需要的检查化验收费标准后，对 该检查化验收费标准进行基本信息修改，提交后自动返回检查化验 收费标准管理界面 在按照检查化验收费标准名查询出需要的检查化验收费标准后，对 该检查化验收费标准进行删除操作，检查化验收费标准列表进行更 新，该检查化验收费标准从列表中消失，页面自动返回检查化验收 费标准管理界面 被泛化的用例无 被包含的用例无 被扩展的用例无 药品信息管理环节需要系统管理员对药品信息进行严格的管理，其中需要管理的业 务内容有对药品的添加，并对这些添加的项目进行查询修改和删除，经分析得到检查化 验收费标准管理阶段用例图如图 2-7 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-7 药品信息管理 Use Case 图 Fig2-7 Use Case for drug information management 根据如上药品信息管理用例图得到药品信息管理用例说明如表 2-6 所示。 表 2-6 药品信息管理用例说明 Table 2-6 Drug information management use case descriptions 用例名称药品信息管理 用例描述当一个新药品被添加或是已注册药品被查询并进行查看、修改和删 除的时候是这个用例的开始。它处理一个药品的基本信息的登记， 以及对所有已注册的药品的基本信息的查看、修改和删除的问题， 但是当系统管理员完成了一个新药品的创建或完成对一个已注册药 品的查看、修改或删除的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件系统管理员以权限登陆进入系统 后置条件添加一个用户；删除或更新一个已注册用户； 基本操作流程1)系统管理员收到一个新药品的登记请求 2)系统显示添加药品界面 3)系统管理员填写新药品的注册信息 4)填写完整后提交信息 5)正确提交后自动退出注册添加页面 6)新药品添加成功 可选操作流程在添加注册途中放弃注册，退出注册页面 在按照用药品名称查询出需要的药品后，对该药品进行基本信息查 询，然后点击返回 在按照药品名查询出需要的药品后，对该药品进行基本信息修改， 提交后自动返回药品信息管理界面 在按照药品名查询出需要的药品后，对该药品进行删除操作，药品 列表进行更新，该药品从列表中消失，页面自动返回药品信息管理 界面 被泛化的用例无 被包含的用例无 被扩展的用例无 普通门诊挂号环节需要挂号收费处对普通挂号的管理，也就是群众需要在门诊部的 挂号处进行普通医生的挂号需求。经分析得到普通门诊挂号阶段用例图如图 2-8 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-8 普通门诊挂号 Use Case 图 Fig2-8 Use Case for general outpatient service registration 根据如上普通门诊挂号用例图得到普通门诊挂号用例说明如表 2-7 所示。 表 2-7 普通门诊挂号用例说明 Table 2-7 General outpatient service registration use case descriptions 用例名称普通门诊挂号 用例描述当一个新患者进行普通门诊挂号的时候是这个用例的开始。它处理 一个新患者的账户建立和患者基本信息的登记挂号的问题，但是当 挂号管理员完成一个新患者的挂号登记的时候，它就结束了 参与者挂号收费员 优先级1 状态通过审查 前置条件挂号收费员以权限登陆进入系统 后置条件添加一个新患者用户；挂号单增加一条患者挂号记录 基本操作流程1)挂号收费员收到一个新患者普通门诊挂号注册请求 2)系统显示普通门诊挂号界面 3)挂号收费员填写新患者的挂号注册信息 4)填写完整后提交信息 5)正确提交后自动退出挂号注册页面 6)新患者挂号单注册成功 可选操作流程在挂号注册途中放弃注册，返回挂号注册前的页面 被泛化的用例无 被包含的用例无 被扩展的用例无 专家门诊挂号环节需要挂号收费处对专家挂号的管理，也就是群众需要在门诊部的 挂号处进行专家医生的挂号需求，经分析得到专家门诊挂号阶段用例图如图 2-9 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-9 专家门诊挂号 Use Case 图 Fig2-9 Use Case for expert outpatient service registration 根据如上专家门诊挂号用例图得到专家门诊挂号用例说明如表 2-8 所示。 表 2-8 专家门诊挂号用例说明 Table 2-8 Expert outpatient service registration use case descriptions 用例名称专家门诊挂号 用例描述当一个新患者进行专家门诊挂号的时候是这个用例的开始。它处理 一个新患者的账户建立和患者基本信息的登记挂号的问题，但是当 挂号管理员完成一个新患者的挂号登记的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件挂号收费员以权限登陆进入系统 后置条件添加一个新患者用户；挂号单增加一条患者挂号记录 基本操作流程1)挂号收费员收到一个新患者专家门诊挂号注册请求 2)系统显示专家门诊挂号界面 3)挂号收费员填写新患者的挂号注册信息 4)填写完整后提交信息 5)正确提交后自动退出挂号注册页面 6)新患者挂号单注册成功 可选操作流程在挂号注册途中放弃注册，返回挂号注册前的页面 被泛化的用例无 被包含的用例无 被扩展的用例无 挂号单查询环节需要挂号处对挂号患者的挂号信息进行查询，并且需要把生成的挂 号信息交给患者，以便患者自己查询自己的相关业务信息，经分析得到挂号单查询阶段 用例图如图 2-10 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-10 挂号单查询 Use Case 图 Fig2-10 Use Case for query of registration list 根据如上挂号单查询用例图得到挂号单查询用例说明如表 2-9 所示。 表 2-9 挂号单查询用例说明 Table 2-9 Query of registration list use case descriptions 挂号单查询挂号单查询 用例描述当一个挂号单被查询的时候是这个用例的开始。它处理一个患者挂 号信息的查询的问题，但是当挂号收费员查看完需要查看的患者的 挂号信息的时候，它就结束了 参与者挂号收费员 优先级1 状态通过审查 前置条件挂号收费员以权限登陆进入系统 后置条件无 基本操作流程1)挂号收费员收到一个挂号信息查询请求 2)系统显示挂号信息查询界面 3)挂号收费员按门诊编号查找该患者的挂号记录 4)找到该条记录以后，进行查看 5)查看完成，返回到挂号信息查询界面 可选操作流程无 被泛化的用例无 被包含的用例无 被扩展的用例无 检查化验单收费管理环节需要挂号收费处对患者的检查化验项目进行收费的管理， 经分析得到检查化验单收费管理阶段用例图如图 2-11 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-11 检查化验单收费管理 Use Case 图 Fig2-11 Use Case for charge of check test list management 根据如上检查化验单收费管理用例图得到检查化验单收费管理用例说明如表 2-10 所 示。 表 2-10 检查化验单收费管理用例说明 Table 2-10 Charge of check test list management use case descriptions 用例名称检查化验单收费管理 用例描述当一个检查化验单收费单被查询的时候是这个用例的开始。它处理 一个检查化验单收费单的查询和缴费确认的问题，但是当挂号收费 员确认该检查化验收费完成的时候，它就结束了 参与者挂号收费员 优先级1 状态通过审查 前置条件挂号收费员以权限登陆进入系统 后置条件一条检查化验收费项目从检查化验单收费管理中消失 基本操作流程1)挂号收费员收到一个患者的检查化验单收费请求 2)系统显示检查化验单收费管理界面 3)挂号收费员按门诊编号查看该患者检查化验单收费信息 4)患者缴费以后，挂号收费员确认该检查化验单已收费 5)确认以后自动返回检查化验单收费管理界面，进行下一位患者 检查化验单收费缴费 可选操作流程无 被泛化的用例无 被包含的用例无 被扩展的用例无 处方药收费管理环节需要挂号收费处对患者所需要的药品进行收费的管理 ，经分析 得到处方药收费管理阶段用例图如图 2-12 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-12 处方药收费管理 Use Case 图 Fig2-12 Use Case for prescripion drug charge management 根据如上处方药收费管理用例图得到处方药收费管理用例说明如表 2-11 所示。 表 2-11 处方药收费管理用例说明 Table 2-11 Prescripion drug charge management use case descriptions 用例名称处方药收费管理 用例描述当一个处方药收费单被查询的时候是这个用例的开始。它处理一个 处方药收费单的查询和缴费确认的问题，但是当挂号收费员确认该 处方药收费完成的时候，它就结束了 参与者系统管理员 优先级1 状态通过审查 前置条件挂号收费员以权限登陆进入系统 后置条件一条检查化验收费项目从检查化验单收费管理中消失 基本操作流程1)挂号收费员收到一个患者的处方药收费单收费请求 2)系统显示处方药收费管理界面 3)挂号收费员按门诊编号查看该患者处方药单收费信息 4)患者缴费以后，挂号收费员确认该挂号收费单已收费 1)确认以后自动返回处方药收费管理界面，进行下一位患者的处 方药单缴费 可选操作流程无 被泛化的用例无 被包含的用例无 被扩展的用例无 诊断管理环节需要医生对患者的病情进行诊断管理，需要管理的业务内容有对患者 病情的查看，为患者提出检查化验项目，进而确定病情，然后开处方药，最后再对患者 进行嘱咐，完成需要医生服务的业务，经分析得到诊断管理阶段用例图如图 2-13 所示。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 图 2-13 诊断管理 Use Case 图 Fig2-13 Use Case for Diagnosis management 根据如上诊断管理用例图得到诊断管理用例说明如表 2-12 所示。 表 2-12 诊断管理用例说明 Table 2-12 Diagnosis management use case descriptions 用例名称诊断管理 用例描述当一个患者被进行诊断管理的时候是这个用例的开始。它处理一个 患者的挂号信息的查看、为患者开检查单、为患者进行病情诊断、 开处方、开医嘱的问题，但是当系统管理员完成一个患者的信息的 查看、为患者开检查单、为患者进行病情诊断、开处方、开医嘱这 一系列的操作的时候，它就结束了 参与者医生 优先级1 状态通过审查 前置条件医生以权限登陆进入系统 后置条件开检查单；开病情诊断书；开处方药；开医嘱 基本操作流程1)医生收到一个患者诊断请求 2)系统显示诊断管理界面 3)医生查看患者挂号信息 4)医生为别人开检查单 5)医生查看返回的检查报告单，为患者进行病情诊断 6)医生为患者添写诊断信息 7)医生为患者开处方药单 8)医生为患者开医嘱 9)返回诊断管理界面，进行下一位患者的诊断管理 可选操作流程当医生为患者开检查单的途中放弃添加，直接返回开检查单管理 当医生删除为患者开的某条检查化验项目的时候，如果该项目已经 交费，则提示无法删除，如果没有完成交费，则可以删除 当医生为患者开处方单的途中放弃添加，直接返回开处方单管理 当医生删除为患者开的某条处方药项目的时候，如果该项目已经交 费，则提示无法删除，如果没有完成交费，则可以删除 当医生为患者开病情诊断的途中放弃填写，直接返回诊断管理界面 医生为患者开医嘱的途中放弃填写，直接返回诊断管理界面 被泛化的用例无 被包含的用例无 被扩展的用例无 检查化验单管理环节需要医